No major OCR vendor publishes an accuracy rate for its receipt or invoice model. Google states plainly that Document AI does not provide a metric for Accuracy, and reports precision, recall and F1 instead. AWS Textract returns a per item confidence percentage and no accuracy figure at all. Azure publishes an estimated accuracy score only for custom template models, calculated against your own training data. So every 99 percent claim in this market comes from a marketing page rather than a measured benchmark. The number that decides whether automation works is field accuracy on your own documents: how often vendor, date, sales tax and total are all correct on the same receipt. Upload one below and check the output against a document whose totals you already know.
Upload your receipts and invoices
Drop files here or click to upload
Upload failed, please try again
Up to 50 files
Uploading...
Accuracy is the first question every buyer asks and the one the market answers worst. The headline percentages that circulate in comparison posts are not wrong so much as unanchored: they measure a different unit, on different documents, than the thing you care about.
Almost every quoted accuracy rate is measured per character. Your accounting import cares about whole fields. One wrong character inside a total makes the entire total wrong, and a total that is wrong by one digit is a wrong ledger entry that reconciliation has to find weeks later.
Azure calculates its estimated accuracy score by running combinations of your own labeled training data. Vendor demo figures come from clean, flat, high resolution scans. Neither tells you how the engine behaves on a curled thermal receipt photographed on a dark desk, which is the document you actually have.
A confidence score is the model estimate of its own correctness, not a measurement of it. Azure documents that a confidence value of 0.95 means the prediction is likely correct 19 out of 20 times, and also notes that not all document fields return a confidence score at all. A confident model can still be wrong.
Rule based OCR fails loudly, returning garbled characters you can spot. A language model completes the pattern instead and hands back a clean, plausible, wrong number. Two percent silent errors is a worse operational problem than ten percent errors that announce themselves.
A useful accuracy evaluation takes an afternoon and produces a number you can defend. It measures fields rather than characters, uses your documents rather than a vendor sample, and counts the errors that survive validation rather than the errors the engine made before validation caught them.
Count how often vendor, date, subtotal, sales tax and total are all correct on the same document. This is the only rate that maps onto whether a human has to touch the document, and it is always lower than the character rate.
Line items plus sales tax should sum to the stated total. A mismatch is a reliable, free signal that something was misread, and it catches a large share of errors before anyone looks at the document.
The point of a confidence score is triage, not truth. Send the doubtful minority to a reviewer and let the rest flow through. AWS documents this directly: detections with a low confidence might need visual confirmation by a human.
Build the test set from faded thermal paper, angled phone photos, multi page invoices and anything handwritten. Every engine handles clean scans, so clean scans separate nothing.
Precision, recall, F1, character error rate and straight through processing rate are five different questions. Comparing a vendor F1 against a competitor character accuracy produces a ranking with no meaning.
Run the same document three times. A deterministic engine returns identical output. A probabilistic one can shift field names, date formats or line item splits, and an import that depends on stable columns will break on the variation.
Four steps that turn a vague impression of accuracy into a number you can put in front of a finance lead.
Pull real documents from the last three months and key the correct values by hand once. Weight the set the way your inbox is weighted, so if a third of your receipts are thermal paper, a third of the test set should be too.
Tip: Include five documents you expect to fail. Knowing where the ceiling is matters as much as knowing the average.
Write the rule down first. Is a date returned as 03/04/2026 instead of 2026-03-04 correct? Is a merchant name missing its legal suffix correct? Deciding after you see the output is how evaluations quietly become marketing.
Tip: Grade per field and per document. The per document rate is the one that predicts review workload.
Character error rate is useful for raw text extraction and misleading for structured extraction. Compute both if you like, but make the decision on the share of documents where every field you need was right.
Tip: Record which fields fail. Line items and sales tax fail far more often than merchant and total, and they are usually the fields nobody checked in the demo.
Multiply the residual error rate by your monthly volume and by the minutes it takes to find and fix one bad entry. That number, not the accuracy percentage, is what an extraction tool has to beat to be worth buying.
Tip: Compare it against the per page cost of each vendor so accuracy and price sit in the same calculation.
Mostly US teams choosing between document extraction vendors, where getting the accuracy question wrong means discovering the problem after the contract is signed.
You need a comparison methodology that survives review, not a leaderboard screenshot. The hard part is picking one metric and applying it to every candidate.
A wrong total is the one failure a ledger cannot absorb quietly. You care about how often a document reaches the books wrong, and how quickly you find out.
Hundreds of receipts a month across many clients. Every percentage point of field accuracy is measured in hours of somebody checking numbers by hand.
You need to show that the number in the ledger traces back to the document it came from, and that the uncertain cases were reviewed rather than assumed.
Last updated: August 2026. Every vendor statement below is taken from that vendor own published documentation, cited in the text.
OCR accuracy is the share of content an optical character recognition engine reads correctly, measured against a known correct transcription. The trap is the word share, because it can mean characters, words, fields or whole documents, and the four numbers can differ by tens of percentage points on the same test set. A quoted accuracy rate is meaningless until you know which unit it counted.
For business documents the unit that matters is the field. Nobody imports characters into accounting software. They import a merchant name, a date, a subtotal, a sales tax amount and a total, and a document is useful only if all of them are right at once. That is why field accuracy and document accuracy are always lower than the character accuracy printed on a vendor page, and why the gap widens as the number of fields grows.
This is the part of the market that surprises people. Of the three large cloud document platforms, not one publishes an accuracy rate for its receipt or invoice extraction. They publish confidence scores, or precision and recall, or nothing.
| Engine | What it publishes | What it does not publish |
|---|---|---|
| Google Document AI | Precision, recall and F1 against a labeled test set you supply. Precision is defined as the proportion of predictions that match the annotations in the test set; recall is the proportion of annotations that are correctly predicted. An optimal confidence threshold is chosen automatically to maximize F1. | An accuracy metric. The documentation states directly that Document AI does not provide a metric for Accuracy, because F1 handles fields that are optional or appear several times per document. |
| AWS Textract | A percentage confidence on every detected block, retrievable from the Confidence field. AWS notes that, depending on the scenario, detections with a low confidence might need visual confirmation by a human. | Any accuracy rate, benchmark or error rate for AnalyzeExpense or any other model. |
| Azure AI Document Intelligence | Per field confidence between 0 and 1, where 0.95 means the prediction is likely correct 19 out of 20 times, plus an estimated accuracy score from 0 to 100 percent for custom template models. Azure recommends you target a score of 80 percent or higher, and close to 100 percent for sensitive cases such as financial or medical records. | Accuracy for prebuilt receipt and invoice models. Azure also states that custom neural and generative models do not provide accuracy scores during training, and that not all document fields return a confidence score. |
| Tesseract | Nothing. The documentation covers input quality requirements instead, notably a 300 DPI minimum and a warning that internal image processing is sometimes insufficient. | Any accuracy figure whatsoever. |
| Vision language models | Nothing stable. Public benchmark leaderboards exist but move every few months and are run on academic document sets, not receipts. | A vendor accuracy rate for document extraction. |
The practical consequence: when a comparison article tells you a tool is 99.5 percent accurate, that figure did not come from the engine builder. It came from a marketing page, a review site repeating a marketing page, or an internal test whose method was never published. Treat it as a claim, not a measurement, and go measure it yourself.
There are five metrics in common use and they answer different questions. Picking one and applying it consistently to every candidate matters far more than which one you pick.
| Metric | Formula or definition | What it is good for | What it hides |
|---|---|---|---|
| Character error rate (CER) | (S + D + I) / N, where S, D and I are substituted, deleted and inserted characters and N is the character count of the reference text | Raw text extraction quality, comparing OCR engines on plain reading | Whether any complete field was usable. A single substituted digit is a tiny CER and a broken total |
| Word error rate (WER) | (S + D + I) / M at word level, where M is the word count of the reference | Prose documents, transcription style output | Harsher than CER by design: reading Smth for Smith is one full word error even though four of five characters were right |
| Precision | True positives / (true positives + false positives) | How often what the engine returned was actually there | Everything it failed to return at all |
| Recall | True positives / (true positives + false negatives) | How much of what was on the page the engine found | How much of what it found was junk |
| F1 score | 2 x (precision x recall) / (precision + recall), the harmonic mean of the two | A single balanced number for structured field extraction, which is why Google reports it | Which side of the trade off is failing, and how bad the failures are in dollars |
| Field or document accuracy | Share of fields, or of whole documents, where every required value was correct | Predicting how much human review you will actually pay for | Nothing important, which is why it is the one to decide on |
CER is character error rate, the count of substituted, deleted and inserted characters needed to turn the OCR output back into the correct text, divided by the number of characters in the correct text. It comes straight from Levenshtein edit distance. A CER of 0.02 means two percent of characters were wrong, and character accuracy is simply one minus CER.
One quirk catches people out: CER can exceed 100 percent. Because insertions are counted in the numerator but the denominator is the length of the reference, an engine that hallucinates extra text produces a rate above one. If the correct text is ABC and the output is ABC12345, five insertions against three reference characters gives a CER of about 167 percent. That is not a bug in the metric, it is the metric telling you the output was mostly invented, which is exactly the failure mode worth watching for with language model OCR.
At character level, 99 percent is worse than it sounds for accounting work. A total like $1,284.37 is nine characters. If character errors were spread independently, a 99 percent character accuracy would leave all nine right only about 91 percent of the time, meaning roughly one total in twelve comes back wrong. Real errors cluster rather than spread evenly, so treat this as an illustration of the arithmetic rather than a measurement, but the direction is right and the direction is the point.
| Character accuracy | Chance a 9 character total is fully correct | Roughly how often a total is wrong | Chance a 45 character receipt has no error at all |
|---|---|---|---|
| 99.0% | 91.4% | About 1 in 12 | About 64% |
| 99.5% | 95.6% | About 1 in 23 | About 80% |
| 99.9% | 99.1% | About 1 in 111 | About 96% |
Illustrative only, assuming independent character errors across the field. It shows why a character rate cannot be read as a document rate.
This is the whole argument for validation over accuracy. An engine at 99 percent characters with an arithmetic check that catches totals which do not match their line items and sales tax will beat an engine at 99.5 percent characters with no check, because the first one tells you which documents to look at and the second one does not.
The only published vendor guidance on a target comes from Azure, which recommends aiming for an estimated accuracy score of 80 percent or higher on a custom model, and close to 100 percent for sensitive cases such as financial or medical records. That is guidance for a model you train yourself, not a benchmark of a prebuilt engine, but the shape of the advice transfers: the threshold depends entirely on what a mistake costs you.
A practical rule for receipt and invoice work is to ignore the percentage and ask two questions instead. What share of documents pass straight through with no human touch, and of the documents that do not pass, does the system tell you which ones they are? A 90 percent straight through rate with reliable flagging on the other 10 percent is a working process. A 97 percent claimed accuracy with no flagging is a reconciliation problem you have not found yet.
There is no defensible single answer, and anyone who gives you one with a number attached is quoting a benchmark that has already moved or was never published. What is stable is which class of engine suits which class of document, and that has held for several years.
| Document type | Usually most accurate | Why |
|---|---|---|
| Clean, uniform, high volume scans | Traditional OCR engines | Deterministic, cheap, and there is nothing for a smarter model to add once the input is flat and legible |
| Receipts, varied merchants, thermal paper | Purpose built receipt extraction | Trained on the layouts, and validates totals against line items rather than only reading them |
| Handwriting and heavily degraded pages | Vision language models | Interpret the whole image rather than classifying characters, which is what handwriting needs |
| Fixed layout forms you control | Custom trained template models | Zone based extraction is near perfect when the layout never moves |
| Long invoices with line item tables | Structured extraction APIs | Table structure recognition consistently lags plain text recognition, so this needs a model built for tables |
If cost is part of the same decision, our breakdown of every published rate per page sits on the OCR API pricing page, and the trade offs specific to model based reading are covered on LLM OCR.
Take 50 to 100 real documents from the last three months, key the correct field values by hand once, then run every candidate engine against that same set and grade per field. Write down what counts as correct before you look at any output. The whole exercise takes an afternoon and is the only accuracy number that will still be true after you sign.
Two details make the difference between a useful test and a comfortable one. Weight the sample the way your real inbox is weighted, including the ugly documents in the proportion you actually receive them, and record which fields fail rather than only how many. Line items and sales tax fail far more often than merchant name and total, and they are the fields a demo never stresses. Our longer walkthrough of what these numbers mean for receipts specifically is in how accurate receipt OCR really is.
Receipts are the hardest common business document. Thermal paper fades within months and often arrives already unreadable in places. There is no layout standard at all, so every merchant places the tax line somewhere different. They get folded, curled and photographed at an angle in bad light rather than scanned flat. And the useful content is a table of line items, which is the part of document understanding that lags furthest behind plain text reading.
An engine that reports 99 percent on a corpus of clean scanned invoices can be meaningfully worse on a shoebox of thermal receipts, and that difference will not appear in any published figure. It is the single strongest reason to run the test on your own documents rather than trusting a comparison table, including this one. The practical answer for high volume receipt work is covered on bulk receipt scanner, and the developer path is on the receipt OCR API.
Handwriting drops accuracy again, and here the vendors are unusually explicit about the limit. AWS Textract supports handwritten recognition in English only, and Azure Document Intelligence lists 12 languages for handwritten text against more than 300 for printed. If any part of your document is filled in by hand, handwriting OCR sets out what each engine actually supports.
The reason this page publishes no accuracy percentage for ReceiptOCR is that it would be worth exactly as much as everybody else. An accuracy figure we generate on documents we choose tells you nothing about the documents you have. If accuracy cannot separate the options, compare them on what they actually return and what they cost instead, which is how our roundup of the best OCR software is organized.
What is worth stating is the design principle. Reading is done with AI because AI reads messy receipts better than rule based OCR does. Every read is then forced into a fixed schema, checked so that line items and sales tax reconcile against the stated total, and flagged for review when a field looks doubtful, with the original image kept beside the value so a reviewer can confirm it in a second. Output lands in stable columns that import into QuickBooks or Xero without a parsing step. Upload one of your own worst receipts and grade it yourself. That is the only benchmark that decides anything.
OCR accuracy is the share of content an engine reads correctly against a known correct transcription. The unit decides everything, because share can mean characters, words, fields or whole documents, and those four numbers differ widely on the same test set. For business documents, field accuracy is the one that predicts real workload.
The only published vendor target comes from Azure, which recommends an estimated accuracy score of 80 percent or higher on a custom model, and close to 100 percent for financial or medical records. For receipt work, a better question is what share of documents pass with no human touch, and whether the system flags the rest.
At character level it is weaker than it sounds. If errors were spread independently, 99 percent character accuracy would leave a nine character total fully correct only about 91 percent of the time, so roughly one total in twelve comes back wrong. Character rates cannot be read as document rates.
Five metrics are in common use: character error rate, word error rate, precision, recall and F1 score. Google Document AI reports precision, recall and F1 rather than accuracy. Field or document accuracy, meaning the share of documents where every required value was correct, is the metric that maps onto review workload.
CER is character error rate, calculated as substitutions plus deletions plus insertions divided by the character count of the correct text, derived from Levenshtein edit distance. Character accuracy is one minus CER. CER can exceed 100 percent when an engine inserts text that was never on the page.
CER counts errors per character and WER counts them per word, using the same substitutions, deletions and insertions formula. WER is harsher: reading Smth instead of Smith is a single complete word error even though four of the five characters were correct. CER suits OCR, WER suits transcription.
No single engine wins across document types. Traditional OCR is strongest on clean uniform scans, vision language models on handwriting and degraded pages, custom template models on fixed layout forms you control, and purpose built extraction APIs on receipts and invoices with line item tables.
The major cloud vendors do not. Google states that Document AI does not provide a metric for Accuracy and reports F1 instead. AWS Textract returns per item confidence and no accuracy figure. Azure publishes an estimated accuracy score only for custom template models, not for prebuilt receipt or invoice models.
No. Confidence is the model estimate of its own correctness, not a measurement. Azure documents that a confidence of 0.95 means the prediction is likely correct 19 out of 20 times, and that not all fields return a confidence score. Confidence is useful for triage, deciding what a human reviews.
Take 50 to 100 real documents, key the correct values by hand once, define what counts as correct before you look at output, then run every candidate against the same set and grade per field. Weight the sample the way your real document mix is weighted, ugly documents included.
Stop typing receipts by hand
Upload your receipts and invoices and get a clean Excel or CSV file in minutes.
Extract my receipts nowFree to try, no sign up required
Every published vendor rate per page, normalized to one billing unit.
Where language model reading beats traditional OCR, and where it fails silently.
Validated receipt fields as JSON from one REST endpoint.
AI receipt reading with the review and export layers built in.
Where OCR ends and structured document understanding begins.
