If you've worked on any document automation project, you've probably heard some version of this sentence: "we just need to extract the data from the invoice."
That sentence hides a second, harder problem. Extraction tells you what a document says. Verification tells you whether what it says is correct. Treating these as the same problem or assuming one automatically solves the other is probably the most common design mistake in invoice and document automation.
This post is about that distinction, using a real invoice verification deployment as a grounding example: Teck Sang, a Singapore-based food importer and wholesale distributor that moved from manual invoice review to an AI-driven, exception-based verification model.
The Problem With "Extraction-Complete" Thinking
Here's the trap. A team builds or buys an extraction pipeline. It reads invoices, pulls out vendor name, totals, line items, dates. It works well on a test set. The team declares the invoice problem "solved."
Then it goes to production, and the actual pain point the thing that was consuming hours of finance team time barely improves. Why? Because extraction was never the bottleneck. Verification was.
Before automation, Teck Sang's team wasn't just reading invoices. They were:
- Validating that required fields and reference numbers were present
- Cross-checking figures against supplier agreements and historical transactions
- Looking for inconsistencies, typos, or calculation errors
- Deciding which documents needed real attention versus routine sign-off
None of that is extraction. All of it is verification. And if your automation only handles the first, you've digitized the document you haven't actually removed the manual burden.
Two Different Problems, Two Different Failure Modes
It's worth being explicit about how these problems fail differently, because the failure modes shape how you should design for each.
Extraction failure looks like: wrong field values, missed line items, garbled text from a poor scan, a number assigned to the wrong field.
Verification failure looks like: a document that was extracted perfectly correctly, but the values themselves are wrong, inconsistent, or don't match what they should a price that doesn't match the supplier agreement, a quantity that's off, a required field that's technically present but nonsensical.
A system can have flawless extraction and still let bad invoices through, because extraction accuracy says nothing about whether the content of the document is actually right. This is the gap that pure OCR-plus-parsing tools consistently leave open.
Verification Requires Reference Data. Extraction Doesn't.
This is the structural reason the two problems need different architecture.
Extraction is largely self-contained given a document, produce structured fields. It doesn't need to know anything about the business beyond general document structure.
Verification is inherently relational. To verify a line item's price is correct, the system needs to compare it against something a supplier agreement, a historical price, an expected range. To verify completeness, it needs to know which fields are mandatory for this document type. Verification, unlike extraction, can't function without a connection to business-specific reference data.
Extraction:
Document → Structured Fields
(self-contained, general-purpose)
Verification:
Structured Fields + Reference Data → Pass/Fail/Exception
(requires business-specific context)
This has a direct implication for anyone architecting one of these systems: extraction can often be a fairly generic, reusable component. Verification cannot. It needs to be wired into the specific business rules, supplier agreements, and historical data of the organization deploying it.
Why "Flag Everything Equally" Doesn't Scale
A naive verification approach treats every check as equally important and every document as equally likely to have a problem. In practice, this produces one of two bad outcomes:
- Over-flagging: so many documents get sent to human review that the automation provides little real relief, defeating the point of building it
- Under-flagging: checks are loosened to reduce noise, and genuine discrepancies start slipping through undetected
The more useful framing is exception-based processing: run the full verification sequence on every document, but only surface the ones where something genuinely deviates from expected. In Teck Sang's case, this is explicitly what the system was built to do apply consistent, rigorous checks to every invoice, but direct human attention specifically to the subset that needs it, rather than distributing equal effort everywhere.
This reframes the human's role entirely. They're no longer the primary reviewer of every document. They're the decision-maker for the subset of documents the system has determined actually need a decision.
Consistency Is an Emergent Property, Not a Bolt-On
One underappreciated side effect of proper extraction/verification separation: consistency stops depending on who's doing the reviewing.
In a manual process, verification quality varies inevitably based on the reviewer's experience, attention, and time pressure that day. Once verification logic is codified and automated, every document gets checked against the same rules, every time, regardless of volume or who's "on shift." This isn't a secondary benefit bolted onto the automation. It's a direct structural consequence of moving verification logic out of individual human judgment and into a defined, repeatable system.
What "Good" Verification Output Looks Like
If verification is going to hand something off to a human, the output needs to do more than say "this invoice has a problem." A genuinely useful exception surface includes:
- What was checked (which rule or validation triggered)
- What was expected (the reference value or condition)
- What was actually found (the extracted value that deviated)
- Why it matters (context on the discrepancy's significance, where determinable)
Without this, you've just moved the triage problem from "read every invoice" to "figure out why this invoice was flagged" which is still manual work, just relocated.
Key Takeaways
- Extraction and verification are different problems solving one does not solve the other, and conflating them is a common design mistake
- Extraction is self-contained; verification is relational it needs reference data (business rules, supplier agreements, historical data) that extraction doesn't
- Exception-based processing beats uniform flagging apply full verification to everything, but only route genuine deviations to humans
- Consistency is a structural byproduct of automated verification not something you have to separately engineer for
- Exception context matters as much as detection flagging something without context just relocates the manual triage work
Closing Thought
If you're building or evaluating document automation and the pitch is "we extract the data" that's necessary, but it's answering the easier half of the question. The harder, more valuable half is: does the extracted data get checked against something meaningful, consistently, with enough context that a human reviewer isn't starting from scratch on every exception?
That's the problem worth spending your architecture time on.
Curious how others are separating extraction and verification logic in their own document pipelines drop your approach below. 👇
This post references a real deployment at Teck Sang, a Singapore-based food importer and wholesale distributor, using iNextLabs' DocsAI as part of an AI Workforce for invoice verification → inextlabs.ai
Top comments (0)