AI Agents for Document Processing: What Really Determines Accuracy

More and more organizations are trying to hand document and data processing over to AI agents: reading, extraction, classification and entry into their systems. Vendors promise 95% to 99% accuracy. Those who have tried often find that the work did not go away. It just moved from doing to checking.

And 99% is not the number that matters. The question is what happens in the remaining one percent. An error the tool flags gets checked and fixed. An error that looks correct slips quietly into the system and surfaces late, after decisions have already been built on it.

I measured exactly this on an agent I built for invoices and receipts in Hebrew. Across 138 real documents, only 0.6% of the fields were wrong without a flag. This article explains what drives that number, and why much of it is decided around the model rather than inside it.

What I measured

The measurement was taken during the build, on 138 real documents, against the decision of the accountant who reviewed each one:

67.4% of the documents went through without a correction in any field. Where a field was left empty, the agent was not sure and did not guess. 0.6% of the fields were silent errors: a wrong value that went through without a flag and was corrected during review. A field the accountant also left empty counted as correct, and an error he did not notice was not counted either.

What the research shows

Systematic studies paint a more modest picture than the sales pages. In a 2026 study on extracting financial data from English text, strong models read 89% to 95% of the fields correctly, but only 42% to 70% of the examples had every field right. Hebrew is harder for models to read to begin with: in another 2026 benchmark, Gemini Flash-Lite, a light model from Google, read 61% of Hebrew sentences almost without errors, compared with 95% in Latin script. Even OpenAI’s GPT-4.1, a much stronger model, reached only 42% in Hebrew, compared with 83% in Latin script. I found no published benchmark for extracting fields from Hebrew documents, and vendors in Israel publish percentages with no definition and no method.

Silent errors are a known problem in the research as well. Language models report high confidence even when they are wrong, so their mistakes do not stand out. A 2026 professional guide to such tools puts it simply: the tool is “wrong with complete confidence.”

These studies measure different tasks, in different languages and with a different number of fields, so they show how hard the problem is, not who won. What sets this measurement apart from the 95% to 99% on sales pages is that it comes with a definition, a method and a number for the silent errors. To me, that is the figure that matters: of the values the agent delivered, fewer than one in a hundred was wrong without a warning.

How it started

An accountant I know was complaining about his workload. When I suggested he try AI, he told me his colleagues spend a lot of time fixing mistakes made by AI agents. In his view, these tools are still not accurate enough for an office that is careful about every detail. I remembered his words when I finished a first skeleton of an agent that reads vehicle documents, such as insurance policies. I realized the same approach could serve many offices that process the same kinds of documents every month, and I applied it to an agent for invoices and receipts.

I set one red line from the start: a wrong value that looks correct must not get through. An empty field, on the other hand, catches the eye at once.

The model reads, and the layer around it decides what to trust, checks the results against rules, and marks for the user what needs a decision.

The model reads, the agent decides what to trust

The agent’s first rule: when there is no certainty, the field stays empty. That is where the empty fields in the measurement come from, and they are the price I am willing to pay to keep silent errors rare.

The model does report how sure it is of each value, but the agent does not rely on that report. In my measurements, the confidence the model reported barely predicted whether a value was correct. So every value goes through checks that do not depend on the model: the citation, the rules and a second reader.

The model returns its answer in a fixed format, and next to each value it gives the passage in the document it read the value from. A check in code verifies that the passage really contains the value, so a value the model inferred rather than read does not get through. I added this check after a failure that kept recurring: the model quoted the line that showed the VAT amount in shekels and calculated the rate from it, although the rate was not written there. The quote was real, but the value in the field did not appear in it.

I also decided not to tell the model that the check exists. A model that knows a missing quote rejects its answer may start inventing quotes, and the check would lose its value.

I measured the effect early in the build, on 39 real documents and before there was a second reader. The citation check cut the share of fields that were wrong without a flag from 4.4% to 1.3%. The documents with such an error dropped from 25.6% to 5.1%.

Checking against rules

A quote proves that the value appears in the document, not that it makes sense. Every field is also checked against its own structure and against the rules of the domain. For invoices, for example, the agent checks that the supplier’s VAT registration number is valid and that the VAT fits the document type. Each type of document has different rules, but the principle is the same: a value that fails the rules does not move on, even if the model was sure of it.

Because each field is checked separately, one field that fails does not reject the whole document. The other fields go through, and only that one waits for a decision.

A second reader, from another vendor

A document that passed the checks is read again, by a model from another vendor. A field the two models read differently stays empty and is flagged for review. In tests during the build, both models made mistakes, such as a swapped digit, but each in a different place. That is why comparing them exposes errors that either one would have delivered with confidence.

I measured what this is worth on synthetic documents, where the correct answer is known in advance. The answers for the real documents had been prepared with the help of the same model that served as the second reader, so measuring it against them would have been circular. With a single reader, 96.9% of the fields were read correctly. Even so, 6.8% of the documents let at least one wrong field through without a flag. The second reader caught 37 of 37 errors, and the silent errors in the fields it checks fell to zero. The price comes in two parts. The second reader sometimes also holds back a field that was correct, so the share of filled fields drops slightly. And it more than doubles the cost per document. In return, a value that reaches a person without a flag deserves far more trust.

The final decision belongs to a person

When the agent finishes, the readings and comparisons go back to the software that called it. For each field, the software receives the checked value, the quote and what each of the two models read. It shows the user the document next to the fields read from it, with a mark on whatever needs a decision. No document is saved before the user approves it, and only approved data goes on to the target system, for example the accounting software.

The user does not wait for each document to finish. They upload a whole folder, and the agent processes as many documents as it can in parallel. In my measurements, a folder took one to three minutes on average, depending on the number of documents and on how many of them were hard for the agent to read. The upload itself depends on the internet connection. When processing ends, the user goes through the documents one after another and approves them. The saving is in their working time: they no longer type, they check and approve.

Measuring without fooling yourself

Two cases from the build taught me not to trust a single number that sums everything up.

The first: a faulty version of the citation check showed a better number than the correct version, while in practice it rejected valid documents because of Hebrew prefix letters, such as ב or ה at the start of a word. The number improved while the agent got worse. Since then, I sort every failure into one of two kinds: a valid document that was rejected, or a wrong value that got through.

The second: during the build, I also checked the results with other models acting as judges. I went over the cases where they disagreed with the agent myself, against the documents. In most of them the judges were wrong, and specifically on Israeli tax rules: a tax invoice versus a receipt, or a VAT registration number versus a company number. Fields like these need someone who knows the rules, which is why the final decision always rests with the user.

Price versus accuracy in choosing the models

An agent that costs too much does not pay off, and an agent that is not accurate enough makes the whole investment pointless. That is why I see balancing a model’s price against its accuracy as one of the most important decisions in the build.

For the first reading, Google’s Gemini Flash-Lite was far less accurate than Flash. The newer versions of Flash did worse than version 2.5. Only Flash 3.8 beat 2.5, by a few percentage points, and only when it was given a large thinking budget and a higher limit on answer length. Under those settings the cost per document rose about fourfold, and the 2027 price list is expected to double it again. The gain is not worth the price.

For the second reader, the decision went the other way. Anthropic’s Claude Haiku was much weaker at the level of the whole document, and Opus did not improve on Sonnet, although it costs more. So I chose Sonnet, even though it costs much more than Haiku.

But this choice is not permanent. Vendors release new models, change prices and retire older ones. The combination that was the best balance this year may disappear next year, or become more expensive. I revisit the choice in two cases: when a model comes out that gives better value at a reasonable price, or when a model is retired and a replacement has to be found at the lowest possible cost. In both cases I run the same measurement on the candidates, on the same documents. As I see it, this measurement is part of maintaining the agent over its lifetime.

Writing the agent yourself, or building it on a vendor’s product

The major vendors offer tools for building agents. In some, you define the agent in natural language. Others are development kits, such as Google’s ADK, OpenAI’s Agents SDK and Anthropic’s Claude Agent SDK, which also let you build an agent without built-in tools. Even so, I wrote the agent myself, in Rust, for three reasons.

Control over costs. For an agent whose work is a constant stream of calls to a language model, tokens make up most of the cost. Every call to the model carries only the fixed instruction, the document and the answer format. There is no conversation history and there are no tool definitions, and the thinking budget is capped in code. In an agent built on a vendor’s platform, the built-in tools consume tokens themselves, and you pay for those too. On top of that come the cloud computing costs of running the agent. An agent written in Rust uses fewer computing resources and runs more efficiently, certainly compared with the Python tools common in the field. That is an additional saving, though a small one next to the saving on tokens.

Checks in code. An instruction in natural language is not a security barrier, because a document can try to get around it. Every answer is therefore checked in code, and a field that fails does not move on.

Behavior on failure. Every answer is checked against the format before it is used, the number of retries is limited, and a circuit breaker stops the calls after several failures in a row. The code itself is covered by tests.

To me, building it myself is a one-time investment that pays off over the agent’s life. It suits an agent where every document costs money, and every mistake costs more than time.

Security: the document can be the attacker

The person who uploads a document is not always the one who wrote it. A supplier can send an invoice with text that tries to give the model instructions. So the agent is built on the assumption that the document itself may try to mislead it.

• The model has no tools. It does not access the database, run commands or reach the network. Its answer is stored as data only and is never executed as a command. Even if text in a document manages to confuse the model, what comes out is a value in a field, not an action in the system, and that value goes through the same checks and the user’s approval.
• The file is checked before the model sees it. Its type is determined by its content, not its extension, and there are limits on size, processing time and memory.
• Only the system that runs the agent can call it. Every call has to prove that it comes from that system.
• Separation between clients. Each client uploads and sees only its own documents.
• Protecting the accounts and the API keys. The service account that calls the model is separate from the ones that handle other tasks, and it has a single permission: to send data to the model. Where the provider allows it, the API key is valid only from the address the agent runs from, and if usage goes over the quota, the model APIs are blocked without deleting anything.

For anyone considering an agent like this

A document-processing agent is not measured by a single percentage on a sales page. It is measured by how many errors slip through silently, and how much work is left for the user. If your organization has documents that come in every month and are typed in by hand, I would be glad to show you how an agent like this works. The agent behind these measurements is described on its own page.

Sources: Cleanlab, arXiv 2603.18014 (financial data extraction from English text, a single model pass, no human review) · GlotOCR Bench, arXiv 2604.12978 (reading Hebrew sentences versus Latin script, Gemini 3.1 Flash-Lite, 100 Hebrew sentences) · Xiong et al., ICLR 2024 (overconfidence in language models) · doctorai.co.il (a 2026 guide, in Hebrew).