# Yuki — Accounting API: gotchas

> Canonical URL: https://developers.apideck.com/apis/accounting/yuki/gotchas

## GET /accounting/bank-feed-statements

Lists the bank statement files in the administration's archive, newest first, including files a
bookkeeper uploaded directly. `id` is the archive document id. `status` is `success` once Yuki has
booked the file and `pending` otherwise; Yuki never reports a rejection, so a file it could not
process, or a duplicate of an already imported period, stays `pending`.

For a statement created through this API, `bank_feed_account_id`, `start_date` and `end_date` are
the IBAN and period it was sent with. For a file uploaded by other means they are read from Yuki
once it has booked the file, and `start_date` and `end_date` are then the first and last booking
dates in it rather than the statement period; they are absent while such a file is pending.
A statement appears on the list once Yuki has picked up the uploaded file, usually within a
minute; until then read it by id. Balances and `transactions` are not included on the list;
fetch a statement by id to get them. `filter[bank_feed_account_id]` is not supported.

## POST /accounting/bank-feed-statements

`bank_feed_account_id` is the IBAN of the bank account. The statement is delivered to Yuki as a
bank file in the administration's archive, which Yuki recognises and books on its own, usually
within a minute. The response carries only `id`, the id of that archive document. Because Yuki
books the file after the response, a successful response means Yuki accepted the file, not that
the transactions are booked. Once booked, the lines appear on the
bank ledger account with their contra entries waiting in Yuki's "bank transactions to be
processed" queue for the bookkeeper to match.

The IBAN does not have to exist in Yuki beforehand: on first import Yuki links it to the bank
ledger account (or creates one), after which the accountant assigns its ledger. Because Yuki never
rejects an unknown IBAN, the API checks it first and returns a 400 when its check digits are
invalid or, for a SEPA country, its length is wrong. A typo that still forms a valid IBAN is not caught.
There is no way to list bank accounts through the API, so bank feed accounts are not supported.

A statement for the same IBAN and period as one already imported is accepted and stored, but its
transactions are silently skipped, and the response cannot tell the two cases apart — send each
period once. A period that only overlaps an imported one is not treated as a duplicate and is
booked, so avoid overlapping periods. Dates are taken as the calendar date they are written in,
offset included: `2026-06-01T00:00:00+02:00` is 1 June, and a date that does not exist returns
a 400. `start_balance` and `start_balance_credit_or_debit` are required; `end_balance` is
written to the file as the start balance plus the transactions, and a supplied `end_balance` that
does not match is rejected with a 400. Amounts are sent as positive numbers with `credit_or_debit`
carrying the direction. The statement currency is always `EUR`.

Only `description` (falling back to `reference`, then `counterparty`) is visible on the booked
lines; `source_transaction_id`, `reference` and `counterparty` are carried in the file but not
shown. `transaction_type` and `merchant_category_code` are not sent. Characters outside the
Latin-1 range are replaced with `?`, control characters are removed, and line breaks become
spaces.

A created statement can be listed and read back by its `id` to follow its `status`, which is
`pending` until Yuki has booked the file and `success` after (see those operations). Poll the
list rather than each statement: a list page costs two calls against the domain's daily
allowance (1,000 on Yuki's free tier) however many statements it holds, and a read by id three. Statements cannot be updated or deleted
through the API; removing one is a bookkeeper action in Yuki.

## GET /accounting/bank-feed-statements/{id}

`id` is the archive document id returned on create. Balances and `transactions` are read back
from the statement file stored in Yuki's archive, so a statement created through this API comes
back complete. `source_transaction_id`, `reference`, `counterparty` and `description` read back
as written to the file: cleaned as described on create and clipped to the CAMT.053 field lengths
(35 characters for `source_transaction_id` and `reference`, 140 for the others). A transaction
sent without `description` reads back with its `reference`, or else its `counterparty`, as the
description. A CAMT.053 file a bookkeeper uploaded directly is read the same way, except that a
batch line covering several payments has no `counterparty` or `reference`; any other bank file
(such as CODA or MT940) is returned with its header only.

`status` is `success` once Yuki has booked the file and `pending` otherwise, including straight
after create, before Yuki has picked the file up. Yuki never reports a rejection, so a file it
could not process, or a duplicate of an already imported period, stays `pending`. An id that is
not a bank statement in Yuki's archive returns `404`. Reading the stored file makes each read
three web service calls, and Yuki's free tier allows 1,000 calls a day per domain. To follow
`status` after a create, list statements instead: a list page is two calls however many
statements it holds. A statement not on the list yet has not been picked up and is `pending`.


[API reference](https://developers.apideck.com/apis/accounting/reference.md) · [Coverage matrix](https://developers.apideck.com/apis/accounting/coverage)