How accurately does AI read accounting documents?

Key findings

An incoming invoice is only useful for bookkeeping once its date, number, total and VAT amount have been captured correctly. Ogment reads those details from your documents so that your team checks them instead of typing them in. Which AI models do that reading, and how well, is a decision we make on evidence. This report is that evidence: every setup we ran in full, measured on the same documents against known correct answers.

One distinction runs through all of it: reading a document is not booking it. The tests measure whether information was extracted correctly. They do not measure VAT treatment, the choice of account or a bank reconciliation. Those remain your professional decisions.

of receipt and invoice totals read correctly by the most accurate setup

99.24%

of tax amounts on real receipts, best setup: the weakest result on receipts and invoices

93.18%

what the most accurate setup costs compared with our production route, on receipts and invoices

11×

of transaction dates and balances on bank statements read correctly by the most accurate setup, for transactions matched to the reference

99.99%

• The best setup is very accurate on the fields that matter most. Kimi K3 read 99.89% of document types, 99.80% of document numbers, 99.24% of totals and 99.15% of dates correctly. Our production route is within two thirds of a percentage point of it on each of those fields.
• Real receipts are where the errors are. On synthetic documents the three strongest setups (the production route, Kimi K3 and the partner model) read each of the five key fields correctly at least 99.39% of the time. On real shop and restaurant receipts, they read the tax amount correctly between 89.32% and 93.18% of the time.
• More accuracy costs a lot more. Kimi K3 costs USD 39.49 per 1’000 documents against USD 3.47 for the production route: about 11 times as much, for a gain of 0.13 to 0.63 percentage points on each of the five exact-match fields.
• A model small enough for one server in Switzerland was not good enough. Qwen3-VL-30B is cheap and its weights are open, but it read only 85.19% of tax amounts and 93.04% of document types correctly, and completed 326 of 400 bank statement files.
• Many errors are blanks, not wrong values. In the production run, 31 of 52 subtotal errors, 18 of 38 tax errors and 13 of 40 date errors were fields left empty. An empty field is visible to a reviewer; a wrong number is not.

What we tested

A setup is the pair of models that does the work: one reads each page, one extracts the accounting fields from that reading. Our production route uses a different model for each step, each with a second model as a fallback. The three challengers use one model for both steps and no fallback, so each result shows what that model does on its own. A model’s weights are the files that make up the trained model; when they are published (“open”), anyone can run the model on their own servers.

Three more models did not get a full run. Two, Qwen3.5-27B and Qwen2.5-VL-72B, could not work with our document-processing pipeline at all. Mistral Small 3.2 completed 95 documents of a 100-document trial and read 68.10% of their tax amounts correctly, which did not justify a full run.

Receipts and invoices

The first test set is 4’801 documents from three public research datasets: 1’987 real receipts from shops and restaurants in Indonesia and Malaysia, and 2’814 synthetic (computer-generated) invoices and receipts. Every document comes with reference answers. For each field, a result is the share of reference answers that the setup extracted correctly, averaged over the datasets that have a reference answer for that field, with each dataset counted equally. The real receipts are foreign, so “tax amount” means the sales or service tax printed on them, not Swiss VAT.

Three of the four setups are close. Kimi K3 is best or equal best on every row, the production route and the partner model trade places behind it, and the three are within two points of each other on every exact field. Qwen3-VL-30B is a different story: competitive on dates and document numbers, clearly behind on tax, totals and document type.

A result applies to one field at a time. 99.24% for the total means that about 99 in 100 totals were extracted correctly. It does not mean that 99.24% of documents were entirely correct, and it does not describe the share of correct accounting entries.

The pattern is the same for the three strongest setups: synthetic documents are nearly solved, real receipts are not. That matters for how to read any accuracy claim, including ours. A benchmark made only of clean, generated invoices would have shown each of the three strongest setups above 99% on each of the five exact-match fields.

Bank statements

The second test set is 400 bank statement files: 200 synthetic statements, modelled on Indian business bank statements, each as a digital PDF and as a scanned copy. A statement is a harder task than a receipt: several pages, many transactions, and every row has to be found before its fields can be right.

No setup completed every file. Beyond those twelve files, the production route failed on 6 files, Kimi K3 on 4, the partner model on 16 and Qwen3-VL-30B on 62.

On transactions that were found, the three strongest setups read dates, amounts and balances correctly at least 99.59% of the time. The differences are elsewhere. The production route confuses debits and credits more often than Kimi K3 or the partner model: 98.60% against 99.98% and 99.83%. Qwen3-VL-30B has the lowest row score, and got the statement period right on barely half of the files.

Scans cost the partner model about three points and Qwen3-VL-30B fourteen. If your clients send scans and photographs rather than bank exports, this is the table to look at.

Cost and speed

Accuracy is one side of the decision. The other is what a setup costs to run and how long a document takes.

The most accurate setup is also the most expensive by a wide margin: Kimi K3 costs 11.4 times the production route on receipts and invoices and 5.3 times on bank statements, on the usage the providers reported. For bank statements we looked at what that buys — 0.50 points more files completed, 0.36 points on the row score, 1.38 points on debit and credit — and kept the production route.

Qwen3-VL-30B is the cheapest setup on receipts and one of the two fastest. On bank statements it is neither: it is the slowest setup and costs more than the production route.

Where it goes wrong

Averages hide what an accountant most needs to know: which mistakes to expect. We went through the errors field by field. These are the patterns, with counts from the production-route run unless another setup is named.

• Tax amounts on real receipts

  The weakest result on receipts and invoices. Of the 440 real receipts with a reference tax amount, the production route got 405 right, Kimi K3 410 and the partner model 393. The receipts that go wrong typically have a missing tax line or an ambiguous zero tax; on others a digit is misread or the amount is derived wrongly. Nearly half of the production route’s tax errors, 18 of 38, are fields left empty rather than wrong amounts.

• Thousands separators and scale

  Indonesian receipts write thirty-six thousand as 36.000, and an earlier version read some of these as 36. The instructions now tell the model to read such separators consistently with the arithmetic printed on the receipt. That, with the other changes of the same round, raised correct totals on those receipts from 83.13% to 97.63%. The same ambiguity exists wherever conventions differ: 1’234.50 and 1.234,50 are the same amount.

• Dates

  The production route got 40 of 3’801 dates wrong, and left thirteen of those empty. 23 of the 40 are on scanned receipts, where the usual cause is a misread digit or a compact date that can be read in two ways; 17 are on synthetic documents.

• Document numbers

  An earlier version often returned the printed label together with the number: “Order #INV-2024-089” instead of “INV-2024-089”. That caused 19 of its 34 errors and is fixed. The 15 errors that remain are three empty fields and dropped or substituted characters.

• Receipts mistaken for invoices

  In an earlier version, 736 of the 987 receipts in one dataset were classified as invoices. After we rewrote how the two are told apart, 981 of those 987 are recognised as receipts. The chart below shows the change for each group of documents.

• Blank fields

  When the production route fails on a field, it often returns nothing rather than a wrong value: 31 of 52 subtotal errors, 18 of 38 tax errors, 13 of 40 date errors and 10 of 41 total errors were empty fields. For a reviewer this is the better kind of error, because an empty field is visible and a wrong number is not.

• Runs that do not finish

  Every model sometimes fails to return a usable result: a page-reading call times out, or the answer does not have the required structure. On receipts and invoices the production route needed 3 retries, Kimi K3 had 6 failures on the first pass and the partner model 12, and all three finished every document. Qwen3-VL-30B failed on 128 documents on the first pass and still had 46 unfinished after a retry.

• Failed files and direction on bank statements

  On bank statements the largest loss is a file that fails entirely. Among the files that complete, the production route’s main weakness is direction: it assigned debit or credit wrongly on 1.40% of the transactions it found, against 0.02% for Kimi K3.

A second look at the arithmetic

An invoice checks itself: subtotal plus tax equals the total, and the line items add up to the subtotal. After the comparison above we built that check, together with a second extraction pass, and reran the production route with both on 10 September, on a larger set of 5’301 documents that adds 500 synthetic card-payment slips (card-terminal receipts, not Swiss payment slips).

of 5’301 documents whose extracted amounts did not add up

709

subtotals changed by the second pass

232

tax amounts changed by the second pass

43

of card-payment slip totals read correctly

99.80%

This run uses a different set of documents, so its results cannot be merged into the tables above. What it shows is how often the arithmetic disagrees, and that a second pass does change values: most often the subtotal (232 documents), then the supplier address (62), the currency (60), the document number (44) and the tax amount (43). Whether each change is a correction is a separate measurement.

Could the AI run in Switzerland?

Fiduciaries ask whether the AI models themselves could run in Switzerland, and not only the storage. We looked at what that would take for the two setups whose model weights are open.

• Qwen3-VL-30B fits on one server. Its weights are 62.2 GB and fit on a single 96 GB graphics card. A server with that card lists at CHF 2’632 per month at one Swiss provider and at under CHF 2’993 at another, before operations, backup and a second server for availability. But this is the setup that read 85.19% of tax amounts correctly and completed 326 of 400 statement files.
• Kimi K3 needs a cluster. Its weights are about 1.4 TB. Sixteen graphics cards in a Swiss data centre come to about CHF 24’800 per month at list price, for a capacity we estimate at five to ten simultaneous users. That is not a basis for serving a product.
• The production route and the partner model cannot be self-hosted. Their weights are not published.

So today, among the setups we tested, the choice is between a model we could host in Switzerland and a model that is accurate enough, and we chose accuracy. Your documents are stored in Switzerland; the AI processing takes place in the European Union, on the terms described below.

Prices: Public list prices in Swiss francs, checked on 4 September 2026 for the Kimi K3 cluster and on 9 September 2026 for the single server. The capacity figures are estimates, not measurements.

How we measured

1. Documents with known answers. We used public research datasets in which each document comes with reference answers: the date, total or transactions actually on it. No client documents were used. Of the receipts and invoices, 1’987 are real receipts and 2’814 are synthetic; all bank statement files are synthetic.
2. Processing. Each setup processed every document the way the product does: each page was read, and the accounting information was extracted into defined fields such as date, document number, total and tax amount.
3. Comparison with the reference. Each extracted value was compared with the reference answer. Common differences in date format did not count as errors: 31.03.2024 and 2024-03-31 are the same date. Amounts had to match to the cent; document numbers had to match apart from spaces, punctuation and upper or lower case.
4. Counting. For each field, we counted how many reference answers were extracted correctly. Documents without a reference answer for a field were left out for that field; where a reference answer existed but nothing was extracted, it counted as an error. Because 59% of the receipts and invoices are synthetic, each score was calculated within each dataset first and the datasets were then given equal weight, so that real receipts count as much as synthetic documents.

For illustration, not a test case: If an invoice shows a total of CHF 108.10, an extracted 108.10 counts as correct, while 108.01 or 1’081.00 counts as an error.

On bank statements, an extracted row was paired with a reference row only when the two largely agreed across date, amount, balance, direction (debit or credit) and description, and the pairs had to follow the order of the statement. Date, amount and balance were then checked on the paired rows. A row read too differently to be paired does not count as a wrong amount: it lowers the row score instead, as a missed row and, if it was extracted, as an extra one.

The datasets are CORD v2 (1’000 real receipts from Indonesia), ICDAR 2019 SROIE (987 real scanned receipts from Malaysia), Invoice OCR Synthetic (2’814 synthetic invoices and receipts) and Indian Bank Statements (400 synthetic files). The first three are published under the CC BY 4.0 licence and the fourth under Apache 2.0, and we used fixed versions of each.

What this means for your review

• The results describe the test documents. The real receipts are shop and restaurant receipts from Indonesia and Malaysia, not Swiss documents. Your suppliers’ layouts, languages and scan quality can differ from what we tested.
• Part of the test data is synthetic. Document numbers were measured on synthetic documents only, and all bank statements are synthetic rather than real Swiss statements. As the results above show, synthetic documents are easier than real ones.
• One accurate field does not make a whole document correct. Each field is measured on its own.
• Scans are harder. On bank statements, results on scanned copies were up to three points lower than on the digital originals for the three strongest setups.
• Test results are not a promise. They describe these runs in September 2026, not every document, and the setup that processes your documents can change when another one does better in these tests.
• Professional judgment stays with you. The tests did not cover VAT treatment, account assignment, reconciliation or the correctness of accounting entries.

In practice: check extracted tax amounts and totals — particularly on receipts — before you rely on them, look twice at empty fields, and review statement data as you would any other input to a reconciliation.

Where your client data is processed

Your clients’ documents are confidential. Three separate questions determine what happens to them, and we answer each one separately.

• Where are the documents stored?

  In Switzerland. The documents you upload to Ogment are stored in Switzerland.

• Where does the AI processing take place?

  In the European Union only. When a document is read and its information extracted, that AI processing takes place exclusively in the EU.

• What do the AI providers keep?

  Not your document content. Under our Zero Data Retention policy, our AI providers do not retain the document content they receive or the responses they generate once processing is complete. Separately, they do not use this content to train AI models.

Zero Data Retention applies to the AI providers. It does not mean that Ogment deletes your documents: they stay stored in your Ogment workspace in Switzerland, so your team can keep working with them. And “not used for training” and “not retained” are two different commitments — we make both.