Back to blog

Human Validation vs AI in Data Extraction: How Much Accuracy Do You Actually Need?

2026-07-28โ€ข9 min read

Human Validation vs AI in Data Extraction: How Much Accuracy Do You Actually Need?

Every vendor demo ends with the same slide: *99% accuracy*. Every buyer nods. And then, three weeks into the pilot, someone in accounting finds a supplier invoice booked with the wrong VAT number and the whole conversation restarts.

The problem isn't the number. It's that "99% accuracy" is not a specification until you say per what โ€” per character, per field, per document, per batch. Those four numbers describe wildly different realities, and only one of them predicts how much human validation you actually need.

This article is about picking that number deliberately instead of inheriting it from a slide.

"99%" per field is not 99% per document

Start with arithmetic, because it settles most of the argument.

Suppose your extraction is 99% accurate per field and a typical invoice header has 10 fields you care about: supplier name, tax ID, invoice number, date, due date, net base, VAT rate, VAT amount, total, IBAN.

The chance that all ten are simultaneously right is 0.99ยนโฐ โ‰ˆ 0.904. So roughly 1 in 10 documents contains at least one wrong field โ€” even though each individual field is "99% accurate".

Now add line items. A 30-line invoice with 4 fields per line adds 120 more chances to be wrong. At 99% per field, the probability of a perfectly clean document collapses toward zero.

This is not an argument against AI extraction. It's an argument against document-level perfectionism. If you demand that every field on every document be verified by a human, you have not automated anything โ€” you have added a review step to manual data entry.

The useful question is narrower: *which fields, at what confidence, on which documents?*

What manual entry actually costs (and how accurate it really is)

Before deciding how much human validation to buy, it helps to price the alternative honestly.

Ardent Partners' 2025 accounts payable benchmarks put the average fully-loaded cost of processing one invoice at $9.40, with best-in-class organisations at $2.78. The same research reports an average exception rate of 14%, dropping to 9% among best-in-class teams. Those exceptions are largely human-generated or human-resolved.

On the accuracy side, the honest benchmark for humans is less flattering than folklore suggests. A systematic review and meta-analysis of data-processing methods in clinical research โ€” a field with far more verification discipline than a typical accounts payable inbox โ€” found manual single data entry running at roughly 0.29% error at field level, with double entry substantially lower. Clinical research operators are trained, monitored and double-checked. Your part-time admin, keying 60 supplier invoices on the last Friday of the quarter, is not operating under those conditions.

So the realistic comparison is not "flawless human vs fallible machine". It's two fallible processes with different failure shapes:

  • Humans fail randomly and quietly: a transposed digit, a skipped line, a date in the wrong format. Errors are uncorrelated and invisible until reconciliation.
  • AI fails systematically and detectably: it misreads a specific supplier's layout, or a specific low-contrast scan, and it usually *knows* it is unsure.

That second property is the whole game.

The three regimes, and why only one scales

There are effectively three ways to run document data capture.

1. Full manual. Every field typed by a person. Cost scales linearly with volume, accuracy degrades with fatigue and deadline pressure. This is the regime most gestorรญas and property managers are actually in, and it's the one that breaks in August and at quarter-end.

2. Full auto, no review. Everything the model outputs goes straight into the ERP. Fast and cheap until the first silently-wrong VAT amount reaches a filing. Defensible for low-stakes fields, indefensible for fields that feed a tax return or a payment.

3. Confidence-routed review. The extractor returns a value *and* a confidence signal. Anything above threshold flows straight through; anything below is queued for a human. Cost scales with the exception rate, not with volume.

Regime 3 is not a vendor invention โ€” it's how the underlying cloud services are designed. Amazon Textract integrates with Amazon Augmented AI precisely so that predictions falling below a confidence threshold you set are routed to human reviewers, and AWS documents two separate thresholds (identification confidence for detecting a key-value pair, qualification confidence for the text inside it). The vendor's own guidance is that you adjust these thresholds over time "to achieve the right balance between accuracy and cost-effectiveness". Nobody serious ships 100% automation. They ship a dial.

If you're still weighing the underlying technology choice rather than the review policy, the comparison in WhappScan vs Manual Entry vs Traditional OCR covers that layer, and OCR Accuracy in 2026 explains why modern models degrade differently from template-based OCR.

Decide per field, not per document

Here is the practical reframe: stop asking how accurate the system is, and start classifying your fields by what a wrong value costs.

Tier A โ€” must be right, always verify below high confidence. Fields where an error creates a legal, tax or payment consequence and is expensive to unwind:

  • Bank account / IBAN on a payment instruction
  • Tax ID (NIF/VAT number) on a deductible invoice
  • Total amount and VAT amount
  • Identity fields used for KYC or a regulatory filing

Tier B โ€” should be right, verify on anomaly. Fields where an error is annoying but self-revealing downstream:

  • Invoice number (a duplicate or a gap shows up in reconciliation)
  • Dates (an impossible due date fails a validation rule)
  • Line-item quantities and unit prices (they must sum to the total)

Tier C โ€” nice to have, never block on it. Descriptions, free-text notes, supplier address lines, reference codes used only for search. A wrong value here costs a search miss, not a fine.

The leverage is in Tier B. Most "AI errors" in invoice extraction are caught not by reading the document again, but by cheap arithmetic and cross-checks the software can run for free:

  • Does base + VAT โˆ’ withholding equal the stated total?
  • Do the line items sum to the base?
  • Is this invoice number already in the ledger for this supplier? (See How to Catch Duplicate Invoices Before You Book Them.)
  • Is this tax ID one we've seen before for this supplier name?

Every check that passes buys you the right to skip a human. Every check that fails is a *targeted* exception โ€” one field, one reason, thirty seconds of attention โ€” rather than a full document re-read.

The trap nobody prices in: automation bias

Adding a human review step feels like risk reduction. It often isn't, because of a well-documented failure mode: automation bias โ€” the tendency to over-trust an automated output, stop scrutinising it, and approve by default.

MIT Sloan Management Review has written specifically about how organisations end up rubber-stamping algorithmic recommendations: reviewers presented with confident-looking output, under time pressure, with no clear authority or incentive to disagree, learn to click approve. The paperwork records a human decision. No human decision occurred.

The practical consequences for your workflow design:

  • A review queue with 100% of documents in it is worthless. If everything needs checking, nothing gets checked. Reviewers calibrate to the base rate; when 97% of what they see is correct, they stop looking.
  • Small, rare, specific queues get real attention. "Three fields, flagged because the VAT doesn't reconcile" is reviewable. "Here is the whole invoice, please confirm" is not.
  • Show the evidence, not just the value. A reviewer who can see the cropped region of the document next to the extracted field is doing verification. One who sees only a text box is doing typing.
  • Track override rate. If your humans change the AI's answer in under 1% of reviewed items, your threshold is too conservative and you're paying for theatre. If they change it in 30%, it's too loose.

What the law actually requires (less than you fear, more than nothing)

Two regimes matter for European SMBs, and they're narrower than the average LinkedIn post implies.

GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, and requires at minimum the right to obtain human intervention, to express a point of view and to contest the decision. Case law has closed the loophole of nominal oversight: the review has to be *meaningful*, by someone with actual authority to overturn the outcome.

Crucially, extracting the fields from a document is not a decision about a person. Reading a tax ID off an invoice, or a name and document number off an ID card, is data processing โ€” it triggers all the usual GDPR duties around lawful basis, minimisation and retention (covered in How to Store Client ID Copies Without Breaking GDPR), but Article 22 bites only when the extracted data automatically *decides* something: rejecting a tenant, refusing a client, blocking a payment.

The EU AI Act requires, in Article 14, that high-risk AI systems be designed so they can be effectively overseen by natural persons โ€” who must be able to understand the system's limits, interpret its output, and disregard, override or reverse it. Note the qualifier: high-risk. Generic document data capture for accounting is not, by itself, an Annex III high-risk use. Timing is also in flux: the Annex III high-risk obligations were originally set to apply from 2 August 2026, and the Digital Omnibus agreed in 2026 defers stand-alone Annex III obligations to December 2027, subject to formal publication in the Official Journal. Transparency duties under Article 50 were not deferred.

The short version: for invoice and utility-bill extraction, the law asks for good data hygiene, not a human retyping everything. For anything that automatically decides something about a person, keep a human with real authority in the loop.

A rule of thumb you can implement this week

  1. List your fields and tier them (A/B/C as above). Ten minutes, once.
  2. Turn every arithmetic relationship you have into an automatic check. Totals, sums, VAT rates, date ordering, duplicate detection. These are free and they never get tired.
  3. Route to humans on two triggers only: low model confidence on a Tier A field, or a failed cross-check. Nothing else.
  4. Sample-audit the straight-through stream. Pull 20 random auto-approved documents a month and check them properly. This is how you learn whether your threshold is honest โ€” and it costs a fraction of reviewing everything.
  5. Move the threshold based on the override rate, not on how anxious the last error made you feel.

The target isn't 100% accuracy. It's a known and acceptable error rate, with the expensive errors structurally impossible. A team that verifies 8% of documents and audits the rest will beat a team that nominally reviews 100% and actually reads none.

If you want to see where your own documents land, you can test the extraction on a real invoice or ID before wiring anything up โ€” upload one and check the fields yourself: try the free extractor, no signup.

Need to extract data from a document right now?

Try it free in seconds โ€” no account, no card. Upload an invoice or document and get the data instantly.

Try it free