What happens to a statement between the drop zone and the import file.
Five steps. One is a model reading a page, and one ends with a model suggesting categories. Everything else is code that counts, adds, compares, and writes files. The page says which is which.
Five steps, in order.
-
Pages are counted
Each PDF is opened and its pages are counted before anything else runs. The count is shown with what it will use: free pages, Pro's included pages, or credits. Nothing runs until you say so.
-
Each page is read
A text statement's pages are read as text. A scanned statement's pages go to the model as images, ten at a time. For each statement the model returns the header and every row. The header is the bank, the account mask, the period, and the printed opening and closing balances. A row is the date, description, amount, running balance where printed, check number, and page. The model is Claude Haiku 5.5 from Anthropic, called with a fixed schema so it can only answer in rows.
-
Each statement is checked
Code, not a model. The opening balance plus every row must equal the closing balance, to the cent. Where the statement prints a running balance, every row is checked against it. A statement that foots is marked. One that does not is flagged with the difference and the row most likely to be wrong.
-
The workspace is checked
Code again. Rows that appear in two overlapping statements are matched and shown as duplicates. So are rows from a statement uploaded twice. Months with no statement for an account are listed as gaps. Your rules categorize what they match. For the rest, the model suggests a category, and the suggestion is marked until you accept it.
-
Files are written
Code. The export you choose is built from the rows and validated against the destination's own rules. Those rules are columns, date format, sign, row limits, and forbidden characters. The file is offered with its validation line. A flagged statement's rows carry their flag into every file.
Ledgerfoot is independent and not affiliated with Intuit, QuickBooks, Xero, or any bank. Their names appear only to say which file format or which bank's statement is supported.
What is deterministic, and what is a model's reading.
| Step | Done by |
|---|---|
| Counting pages | Code |
| Reading a page into rows | A model, with a fixed schema |
| The balance check | Code |
| The running balance check | Code |
| Duplicates across statements | Code |
| Gaps | Code |
| Categories from your rules | Code |
| Category suggestions | A model, marked as suggestions |
| Exports and their validation | Code |
| The client summary | Code |
What the balance check catches, and what it cannot.
A misread amount, a row read twice, a row missed, a sign read backwards. Each of these moves the sum off the closing balance, and the difference points at the row. That is most of what goes wrong when a page is read. It is why the check is the product's promise.
What it cannot catch: Two misreads that cancel each other to the cent, and a wrong description with a right amount. What it cannot do: Foot a statement that prints no balances. That statement is marked "Could not foot" and its rows are exported with that note. Both limits are shown on the page, never hidden.
Scans are read as images and checked the same way.
A scanned page has no text to extract, so it goes to the model as an image. Scans read less well than text. A smudged digit or a faint minus sign can be misread. The balance check is how you know. A scanned statement that foots is as good as a typed one. One that does not is flagged with the difference, the same as any other.
How well it reads, on the statements we test it with.
Ledgerfoot is tested on fictional statements from three invented banks with different layouts, 14 months for two clients. The hard cases are placed on purpose. They include a statement that does not foot, overlapping statements, a missing month, and a check with a three-line description. They also include a foreign-currency purchase, a refund, a reversal, and a page with a header and no rows. The table below shows the last measured run. The method is on this page so you can judge it.
| Run | Statements | Rows | Rows read exactly | Statements that foot | Date |
|---|---|---|---|---|---|
| Fixture set, text statements | 70 | 1,257 | 1,257 | 69 (the 70th is the fixture printed not to foot, flagged $100.00 over) | October 21 2026 |
| Fixture set, scanned statement | 1 | 25 | 25 | 1 | October 21 2026 |
Where the statements go, in one paragraph.
Uploaded PDFs are stored encrypted at rest on Cloudflare R2 under your account. They are deleted after 30 days by default. Pages are sent to Anthropic's API to be read, under Anthropic's API terms. When Ledgerfoot has the fallback on, a page that could not be read may go to OpenAI's API under its terms. The batch page says when it was used. Nothing is used for training by Ledgerfoot. The extracted table and the checks are stored in a database encrypted at rest. They stay while your account exists. Deleting a workspace or your account deletes all of it.
See the check on one statement.
Ten pages a month are free.