Skip to main content
Not every bank has an open-banking feed, and not every business wants to build an export pipeline. Every business does receive a monthly statement. Upload one to Cherry and it becomes the same thing a connected bank produces: an account, its transactions, and — once the async sweep runs — categorizations and journal entries. Nothing about the result is second-class. The rows are ordinary transactions, readable through GET /v1/transactions and correctable through PATCH /v1/transactions/{id} exactly like any other. There is no endpoint for this. A statement is a document, so you upload it the way you upload any document — through the Cherry app, or by forwarding it to your Cherry inbox address. Cherry recognizes it as a statement and takes it from there. Even when a statement’s layout is unusual enough that Cherry can’t classify the document up front, it still tries the statement pass on anything it couldn’t place — an unrecognized layout costs you nothing, and a real statement gets in.

​
What Cherry can read

Checking, savings, and credit-card statements are all supported. Cherry reads the institution, the account number (masked is fine), the currency, the statement period, the opening and closing balances, and every transaction line. Currency comes off the page. Cherry never assumes USD. An MXN statement produces MXN transactions.

​
The reconciliation gate

Cherry does not import a statement it cannot prove it read correctly. Before anything is written, it adds the transactions back to the opening balance and checks the result against the closing balance the statement prints:
  • Checking and savings: opening − (money out − money in) = closing
  • Credit card: opening + (money out − money in) = closing
If the arithmetic lands within a cent or two, the statement is imported. If it doesn’t — a missing page, an unreadable column, a row read into the wrong side — the statement is rejected whole. Nothing partial is ever imported, because a ledger missing three transactions is worse than a ledger missing a month: you can see the missing month. A rejected statement shows up in your conflicts with what Cherry expected versus what the statement said. Re-uploading a complete, legible copy is usually all it takes. The same is true of failures further down: a statement lands as one unit, or it doesn’t land at all. If anything goes wrong while it is being written, nothing from it is kept — you never end up with half a month in your books and no record of where it came from.

​
Continuity between statements

Each statement is checked against the previous one for the same account: last month’s closing balance should be this month’s opening balance. When it isn’t, Cherry still imports the statement — the numbers on that page are self-consistent — but flags the gap:
Your BBVA México ••4417 statement through 30 June closed at 12,430.10, but the next one opens at 12,100.00. A statement covering the period in between is probably missing.
That is almost always exactly what it is. Upload the missing statement and the gap closes — literally: Cherry re-checks the statement on the other side of the one you just uploaded and closes the flag itself. Order doesn’t matter. Upload February and April, and April is flagged. Upload March later and April’s flag clears, because every upload re-checks both of its neighbours rather than only looking backwards. It works the other way too: if a corrected statement changes a closing balance, the month that follows it is re-checked and flagged if it no longer joins on.

​
Uploading the same statement twice

Safe. Nothing duplicates. Cherry derives every identity from the statement’s own contents: So a re-upload resolves to the same account and the same transactions and updates them in place. This holds across sources too: if you pushed August’s rows through POST /v1/transactions and then upload August’s statement, Cherry recognizes them as the same transactions rather than booking the month twice. The one thing a re-upload does not change is the account’s opening balance, which stays anchored to the first period Cherry saw.

​
Uploading a corrected statement

Sometimes the second copy isn’t the same copy — a bank reissues a statement, or the first scan was missing a page. When Cherry already has a statement for that account and period, the new one replaces it rather than merging into it: for that period, the statement is the record. So lines the corrected copy no longer lists are removed. With one exception, and it matters:
  • Transactions nothing has happened to yet are deleted. Nothing depended on them.
  • Transactions already categorized or posted to your ledger are never deleted. Cherry keeps them and raises a conflict listing exactly which ones, because deleting a posted transaction would leave a journal entry pointing at nothing — and quietly keeping a transaction your bank says never happened would be worse. That one needs you.
This applies to transactions in that period however they got there, including rows you pushed through the API. Inside a period a statement covers, the statement wins.

​
How current your books are

Statement-fed books are current through the last statement you uploaded — not through today. That is a real difference from a connected bank feed, which lands transactions within a day. If you upload August’s statement on 5 September, Cherry’s picture of that account ends on 31 August, and anything since then is invisible to it. Categorization, statements, and the health score all reflect that boundary. Uploading each statement when it arrives keeps the lag to one month. If you need same-week accuracy, push transactions through the API between statements — the two paths dedupe against each other, so you can do both.

​
After the upload

Categorization and booking run asynchronously, usually within minutes — the same sweep that handles connected banks. Then:
Amounts follow the usual sign convention: positive is money out, negative is money in. A deposit on your statement comes back negative. To correct a categorization, PATCH it like any other transaction — Cherry remembers the correction for that merchant.