An invoice arrives. Does it match what we ordered, at what we agreed, from whom we expect?

The Problem

Document extraction (turning a scan into structured fields) is half the value. The other half is validating those fields against what you expect, what was ordered, what was contracted, what the supplier is supposed to charge.

In AP automation circles this is called “three-way matching”: invoice vs purchase order vs delivery receipt. Done manually, it’s the AP analyst’s daily grind, pulling up the PO, checking the line items, comparing prices, finding the receipt, approving or rejecting. At volume, it’s the bottleneck that determines how fast you can pay suppliers and how often you miss discrepancies that cost money.

Cross-validation extends naturally beyond AP. Customs declarations checked against shipping manifests. Insurance claims checked against policy terms. Healthcare prior authorizations checked against benefit schedules. Certificates checked against accredited issuers. The shape of the problem repeats: extracted document data on one side, master-of-truth records on the other, decisions waiting in between.

What the Solution Does

A validation layer that sits on top of document data extraction (or your existing extraction system) and checks every extracted document against your master systems.

1. Receive extracted data: from our extraction pipeline or your existing IDP system.
2. Identify the counterpart record: match the invoice to the PO, the claim to the policy, the certificate to the issuer. Fuzzy matching where needed.
3. Apply validation rules: price within contracted range, quantity matches PO, vendor matches supplier master, delivery within contracted window.
4. Classify discrepancies: by severity (auto-reject, route to approval, soft warning, log-only).
5. Route accordingly: auto-approve clean documents, escalate discrepancies to the right reviewer, log everything for audit.

Where It Fits

This makes sense if you…

• Process documents that should be checked against master data (invoices vs POs, claims vs policies, etc.)
• Have measurable cost from incorrect payments, missed discrepancies, or slow reconciliation
• Operate master systems that can be queried programmatically (supplier DB, contract DB, etc.)
• Have a clear definition of “what makes a document valid”, rules people can articulate
• Already run document extraction or are deploying it alongside

This is probably not the right time if you…

• Don’t have master data to validate against, there’s nothing to compare to
• Have validation rules so complex and judgment-based that no rule engine could codify them, those need human review
• Process documents in a flow where downstream systems can’t accept structured validation status
• Operate at scale below the cost of manual reconciliation (small operations: don’t bother)

Business Value

Catching real errors that humans miss. Manual reconciliation has a known error rate, analysts approve “close enough” documents at the end of long days. Automated cross-validation applies consistent rules every time. Detection rate for material discrepancies (price, quantity, vendor mismatch) reaches 95%+ in production.

Reconciliation speed. AP analysts spend the majority of their time matching documents to master data. Automated matching and validation eliminates 60-85% of that work, freeing the team to handle exceptions and higher-judgment cases.

Fraud and error detection. Vendor invoice fraud (slightly wrong amounts, slightly wrong vendor names) is caught by exact comparison against the supplier master. Time to detection drops from weeks (random audit catches it) to hours (every invoice gets checked).

Audit and compliance documentation. Every validation run is a logged decision with the rules that were applied. Audit trails for compliance reviews stop being reconstruction exercises and become queries.

How It Works

The validation pipeline below sits on top of document data extraction, that layer turns scans into structured fields; this layer compares those fields to master data.

1. Extracted-data input

Either from our extraction pipeline (preferred, tight integration) or from your existing IDP system (we adapt to whatever format).

2. Counterpart matching

The system identifies the corresponding master record. For an invoice, that’s typically the PO. Matching is sometimes obvious: the PO number on the invoice matches a PO record exactly. Sometimes it is fuzzy: the vendor name differs slightly, dates are close but not exact, no PO number is cited. We use the embedding-based fuzzy matching from our product categorization work: BERT embeddings with KNN against the master records. Confidence thresholds route ambiguous matches to human review.

3. Validation rules engine

For each field, configured rules: price within X% of contracted, quantity matches PO, vendor present in supplier master and active, delivery within contracted window, total within historical pattern for this vendor, etc.

Rules are typed and prioritized: hard-fail (auto-reject), soft-fail (route to approval), warning (log but proceed). We co-design with you during pilot, most operations have rules they articulate informally but never wrote down; codifying them is half the value.

4. Discrepancy classification

Discrepancies aren’t equal. A €5 price difference on a €500 invoice may be acceptable rounding. A €5k difference is a real problem. We classify by severity, with tunable thresholds.

5. Routing

Auto-approved documents go straight to downstream processing (payment scheduling, accounting). Discrepancies route to the appropriate reviewer with full context, extracted data, master record, the specific rule that flagged, recommended action.

6. Audit log

Every decision logged with timestamp, rule applied, reviewer (if escalated). Queryable for audit, dispute defense, fraud investigation.

Stack

BERT-based embedding for fuzzy matching (shared with product categorization), Python/FastAPI for the rules engine, PostgreSQL for the audit log, Datapipe for the data pipeline, integration via REST APIs with your master systems. LLMs (GPT-4 / Claude) optionally for natural-language reasoning on harder validation rules.

What You Need to Make This Work

Data. Access to your master systems, supplier DB, PO database, contract terms, whatever the document type validates against. Historical examples of mismatches (or near-mismatches) for testing.

Integrations. Read access to master systems. Write access to your AP / approval workflow for routing decisions. Optional: integration with audit / GRC tools for the compliance trail.

Hardware. Cloud or on-prem. Inference is lightweight; the heavy work is rule design and master-system integration.

Team. A process lead who knows the validation rules (often AP director, controller, or compliance officer). A data-systems lead for master-system integration (~20-40 hours during pilot). A pilot user group from the team that currently does manual reconciliation.

Implementation Roadmap

1. Test (3-5 weeks)

Pick one document type and one validation scenario. Co-design the rules. Run validation against a historical sample. Compare results to past manual decisions. Output: written report with detection rate, false-positive rate, and rule refinement recommendations.

2. Pilot (2-3 months)

Production deployment to one workflow. Wire up the routing for discrepancies. Build dashboards for AP / compliance teams. Tune thresholds. Output: working production deployment with documented business outcomes, go/no-go on broader rollout.

3. Production (3-6 months)

Add document types, add validation scenarios, scale to full operation. Continuous rule refinement as edge cases surface. Your team owns the rules engine; we stay on for new rule types and integration extensions.

Keep in Mind

Where it breaks:

• The rules are the value. Most operations have validation rules they articulate informally but never wrote down. Codifying them is real co-design work. A pilot runs 2-3 months partly because of this.
• Fuzzy matching is probabilistic. When the invoice’s vendor name differs slightly from the supplier master, the system makes a judgment call. Confidence thresholds determine how aggressively to auto-match vs route to review.
• Master data quality is the ceiling. If your supplier master is incomplete or out of date, the system can’t validate correctly. Sometimes the most valuable finding is “your master needs cleanup”.
• Some discrepancies require human reasoning. A “wrong vendor” might be fraud. It might also be a legitimate parent-company name change. We surface context; humans make the final call.
• Integration with master systems is real work. Read access to live data via API is the cleanest design. Read access to nightly exports is workable but stale. Read access via screen scraping is doable but fragile. Plan accordingly.
• Audit-log compliance is jurisdictional. Some regulations require specific retention or specific log formats. We adapt during pilot for compliance contexts.

FAQ

How does this compare to three-way match in commercial AP automation?

Commercial AP automation platforms (Coupa, Tipalti, etc.) do three-way match for invoice vs PO vs receipt out of the box. Our approach fits when you need custom validation rules beyond standard three-way match, integration with non-standard master systems, fully on-prem deployment, or extraction quality good enough to validate against complex contract terms. Basic PO matching is the easy case; we cover the harder ones too.

Can the system validate against contract terms (price tiers, volume discounts, etc.)?

Yes, that’s the high-value scenario where we differentiate from commercial three-way-match systems. Contract terms get codified as validation rules: “this vendor’s price for product X is one value at volumes Z to W, and another above W”. The system applies them on every invoice.

What if our master data is incomplete?

The system surfaces this. Documents that can’t be matched to any master record get routed to a separate review queue. Often the finding is “we need to update the supplier master before we can validate this”, which is a useful finding even when it’s not what the team expected.

Can it learn new validation rules from past human decisions?

Pattern-mining historical approvals to derive implicit rules is technically possible but risky: the rules people inferred from might have been wrong. We typically prefer explicit rule co-design with the process lead. Historical data validates the rules we wrote; it does not generate them.

Does this require LLM reasoning?

For most validation rules, no, they’re deterministic comparisons. For harder rules (“does this invoice describe goods that match the contract scope?”), LLMs help. We use them surgically, never as a default.

Ready to Discuss?

If you process invoices, claims, or other documents that should be cross-checked against master data and the manual reconciliation work is a real cost line, this is a relevant pilot. We’ll walk through your document types, your master systems, and your current validation process, and tell you what to expect.

Discuss your project