The model misread a bill by five hundred baht. What caught it?

Part 1One bill, two answers, and equal confidence

During testing of our bill-parsing system, one monthly service bill turned out to be a problem case. The true total printed on paper was 4,851.00 baht.

The first model (a small 2B model, about two billion parameters) read it as 5,390.00 baht, off by more than five hundred baht. No error, no warning. The JSON that came back was clean and complete in every field.

Switching to a larger model (4B, about four billion parameters), this time the total came out exactly right: 4,851.00.

The point worth sitting with is not which model is better. It is this question: if you do not have the answer key the way we did, how would your system know which answer to trust? Both answers looked equally credible in every respect.

Part 2Split the work correctly: the model transcribes, code decides

The principle behind the whole design fits in one sentence: the model's job is to transcribe what is printed on the page into text. That is all. No arithmetic, no guessing, no rounding on its own. Deciding whether a given set of numbers can be trusted is entirely the job of code, which checks the same way every time and produces the same result every time.

The reason comes down to the nature of the tool. A language model answers probabilistically. On any given day it can read a 4 as a 5 with no warning sign beforehand. Arithmetic has no such off days: two plus two is four, every time. A well-designed system uses the certainty of arithmetic to keep the model's uncertainty in check.

Part 3Prove the numbers with the document's own numbers

The good news is that almost every financial document carries its own answer key. A single bill already contains numbers that must relate to each other in a chain.

• The sum of every line item must equal the subtotal.
• The subtotal plus VAT must equal the total printed at the bottom of the bill.
• The tax charged must match the stated rate (7% must actually come out to 7%).
• If there is withholding tax or a deposit, the net amount must chain through to the end.

If the numbers the model read are actually correct, this chain of relationships lines up cleanly end to end. If the model misread even one figure, the chain breaks somewhere almost immediately. The 5,390 case above was caught exactly this way: the sum of the line items did not match the reported total, so the system flagged it red for a person to check, without even needing to know what the real number was.

There is one case people often do not expect. Sometimes the model reads every figure correctly, but the numbers on the document itself do not reconcile from the source. On this same bill, once the larger model read the total correctly, the system still flagged it red, because the numbers on the paper genuinely did not add up. That is the correct outcome. A document like this needs a human to open it, not a system guessing which field to trust.

Part 4Three colors, three levels of trust

All verification results collapse into three color signals, so an accountant can decide in half a second.

1. Green every relationship checks out. Safe to post automatically.
2. Yellow readable, but with a point the system is not confident about, such as a smudged number or handwriting. Send it to a person to confirm.
3. Red numbers conflict or a key piece is missing. Must open the original document.

The heart of this split is the system's honesty. It is better for the system to say "not sure" than to be confidently wrong, because fixing a number after it has already been posted to the books costs far more than checking it before posting.

Part 5Checklist for your own system

Whichever OCR vendor or model you use, these five points apply the same way.

1. Instruct the model to transcribe numbers exactly as printed on the document. Never let it calculate anything on its own.
2. Write code that checks the relationships between the numbers in the document, at minimum the line-item sum against the total.
3. Any numbers that fail verification must never flow into the downstream system automatically. Always hold them for a person.
4. Track where the model tends to fail most often, to decide whether you need a bigger model or better source images.
5. Test against documents with a known answer key (even ten documents you verify yourself is enough to start) before trusting the system with real ones.

We believe in this enough to have built an entire system around the principle. If you want to see how it works on real bills, try it at our AI bill scanner page.

Frequently asked questions

How do you measure OCR accuracy so it can be trusted?

Measure it against a set of documents with a known answer key (ground truth verified by a human), comparing field by field, not just whether the system returned a complete answer. You should also measure separately by document type, because a cleanly printed tax invoice and a handwritten receipt live in completely different accuracy worlds.

Does a bigger model fix misread numbers?

It helps, but not completely. In our own measurements, a larger model clearly reads totals correctly more often, but it can still get it wrong on smudged documents or unusual layouts. A verification layer is therefore still necessary regardless of model size.

If the numbers on a document conflict with each other, what should the system do?

Always send it to a person to open and check. Never let the system guess which field is correct, because a document with numbers that do not reconcile could be a typo, a discount that was not shown as its own line, or an anomaly that a human needs to diagnose.

Does building a verification layer require more AI?

No. This layer is plain arithmetic code that checks the relationships between numbers (addition, subtraction, multiplication, comparison). Its strength is certainty: it checks the same way and gets the same result every time, unlike using another AI model to check the first AI's output, which only adds another layer of uncertainty on top.