DocVerify AI: Transforming ERP Document Verification with LLMs and Intelligent Matching

The problem: verification that doesn’t scale

Every services business that invoices against a contract runs the same background chore: keep the billing system honest against the paperwork. A customer’s Trade License proves who they legally are. A Service Agreement or Purchase Order says what was actually promised — equipment, frequency, price, bin counts, site addresses. The ERP system is supposed to mirror both. In practice, it drifts.

Names change after a corporate rebrand. Addresses get abbreviated inconsistently by whoever typed them in five years ago. A price negotiated last year quietly survives in the ERP after this year’s renewal changed it. None of this is dramatic on its own — but at the scale of thousands of active accounts, it adds up to real revenue leakage, audit risk, and compliance exposure, especially wherever expired trade licenses or lapsed contracts go unnoticed.

The traditional fix is a person with two monitors: one showing the ERP export, one showing a stack of PDFs, manually cross-referencing row by row. It works, but it doesn’t scale, it’s slow to onboard, and it’s only as consistent as whoever is doing it that day.

DocVerify AI automates that cross-referencing step — not by replacing judgment, but by doing the tedious matching and flagging automatically, and surfacing exactly where a human still needs to look.

Why naive automation falls short

The obvious first attempt at automating this is a keyword search: scan each PDF for the customer name, the order number, an address fragment, and call it a match. We built and shipped that version first. It’s fast, but it breaks down in exactly the situations that matter most:

Bilingual documents. Trade licenses in the UAE are routinely issued with parallel Arabic and English blocks; a purely English keyword scan misses half the page.

Scanned or rotated PDFs. Keyword search needs machine-readable text; a scanned license with no text layer returns nothing.

Legacy names and rebrands. A company that rebranded two years ago still has agreements on file under its old name — a literal string match calls that a mismatch, when it’s actually the same legal entity.

One-to-many relationships. A single customer can have many active orders, sites, and service lines, each needing to be matched against the correct row in a large pricing table — not just “this document mentions this company.”

None of these are edge cases in the documents this system actually processes — they’re the median case. So the architecture had to treat multilingual reading, legal-entity resolution, and structured comparison as first-class problems, not afterthoughts bolted onto a keyword search.

Architecture: a five-stage pipeline

DocVerify AI is built as a straight-line pipeline with a clean handoff at each stage: extraction never has to know about comparison logic, and the comparison engine never has to know how a PDF was read. That separation is what lets each stage get better independently.

Figure 1 — The DocVerify AI processing pipeline, from raw upload to explainable verdict.

A single batch upload carries the ERP export and every supporting PDF for the run — Trade Licenses, Service Agreements, Purchase Orders, Service Orders, in any mix and any order. Nothing needs to be pre-sorted or pre-labeled by the person uploading it; the system classifies each document after reading it, based on what fields it actually finds inside — a license number and issue/expiry dates read as a Trade License, a set of priced service lines reads as a Service Agreement.

Each PDF is extracted exactly once, in parallel, regardless of how many ERP rows will eventually reference it. A 200-row ERP export referencing the same twelve customer documents doesn’t mean re-reading those PDFs 200 times — it means reading them 12 times and matching every row against that shared, structured result.

Identity resolution: knowing whose document is whose

Before any field can be compared, the system has to answer a more basic question: which uploaded documents actually belong to which ERP customer? This is the identity resolution stage, and it’s deliberately built on the clean, structured customer name the extraction step already produced — not a second pass of raw-text keyword search.

Multi-signal scoring. Every candidate document is scored against an ERP row using the strongest signal available: an account code embedded in a filename, a fuzzy match against the filename itself, or a fuzzy match against the extracted customer name. Any single signal can fail independently — a renamed file, an inconsistent account code — so the engine takes the best of several rather than depending on one.

Trade License precedence. Business rule, not a coincidence of the data: the Trade License is always treated as the authoritative source for the legal customer name. Where a Service Agreement or the ERP itself uses an older or informal name, the license’s name wins for identity purposes.

Rebrand and alias resolution. Companies rename themselves. An external, editable alias table — not a hardcoded list of client names — lets the system recognize that a legacy name and a current legal name refer to the same entity, so a rebrand doesn’t manifest as a wall of false mismatches. New aliases are added as configuration, never as code changes, which is what makes the approach generalize across clients rather than being tuned to any one customer roster.

The result is a routing decision the system can defend: for every ERP row, exactly which Trade License and which Service Agreement it used, and how confident it was in that pairing — visible in the UI, not buried in a log file.

The comparison engine: weighted, explainable scoring

Once the right documents are attached to the right row, the comparison engine evaluates each field independently, using a method suited to what that field actually is — text, a number, a date, or a whole service line that needs to be located before it can be compared at all.

Prices and bin counts are numeric fields: they’re compared with a small tolerance, not a fuzzy text score, because “38” and “38.00” should agree and “38” and “55” never should, no matter how similar those strings look to a general-purpose string similarity function. Names and addresses are normalized before comparison — known synonyms, abbreviations, and transliteration variants are canonicalized so that two representations of the same road or the same company don’t register as different places or different entities. Service lines get an extra alignment step: an ERP row is matched to its single best-fitting line item in the agreement’s pricing table first, and only then compared field by field — rather than being checked against every line in the document and averaged into noise.

Figure 2 — Same verification rigor, restructured around parallel machine reading instead of sequential manual lookup.

The table below summarizes how each category of field is actually scored:

A handful of fields — issue dates, expiry dates, contact emails and names — are informational: they’re surfaced for context (an expiring license, for instance) but never on their own cause a row to fail. Keeping that distinction explicit prevents the tool from crying wolf over details that were never supposed to gate a verdict.

Confidence, not just a checkmark

A verification tool that just prints “MATCH” or “MISMATCH” is only half a tool — the person reviewing it still has to reverse-engineer why. DocVerify AI is built around explainability at two levels.

Field-level. Every comparison carries its similarity score alongside its verdict, so “MISMATCH” at 55% and “MISMATCH” at 12% read very differently to a reviewer deciding how urgently to look at it.

Row-level. When the best available service-line match itself is low-confidence — meaning the uploaded agreement may simply not cover this specific order — the row is routed to Needs Review instead of a hard Failed, and the order-specific field mismatches underneath it are marked Unverified rather than presented as confirmed errors. That distinction matters: a document genuinely not covering an order is a different problem from a document that covers it and disagrees with the ERP, and conflating the two erodes trust in every other verdict the tool produces.

This is also why Trade License precedence and alias resolution live in the comparison layer and not just in a lookup table: every normalization decision the engine makes is something a reviewer can trace back to a stated rule, not an opaque model output.

What it looks like in practice

The workflow is intentionally a single screen: upload the ERP export and every supporting PDF together, and the batch summary fills in as processing completes — total rows, how many passed, how many need review, how many failed outright, and how many had no matching document at all.

A main results table, filterable by status and searchable by order number, customer, or service — each row showing exactly which Trade License and Service Agreement file it was matched against.

A field-level comparison table, grouped by order, that expands into every individual field checked — category, the ERP value, the document value, the verdict, and the similarity score behind it.

License expiry badges (Valid / Expiring Soon / Expired) computed directly from the extracted expiry date, so compliance risk surfaces without a separate report.

A one-click CSV export of the full field-level comparison, for anyone who wants to work the results in a spreadsheet or hand them to an audit team.

None of this requires the uploader to pre-sort documents by type or to know in advance which PDF belongs to which row — that’s the whole point of doing identity resolution as its own pipeline stage rather than asking a human to do it first.

Key takeaways

Separate concerns cleanly. Extraction, identity resolution, and comparison are independent stages — each can improve without the others needing to change.

Normalize before you compare. Most “false mismatches” in messy real-world data aren’t data-quality bugs — they’re representation differences (abbreviations, rebrands, transliteration) that belong in a shared normalization layer, not scattered fuzzy-match tuning.

Match the comparison method to the data type. Numbers deserve numeric tolerance; text deserves normalized fuzzy matching; service lines deserve an alignment step before either applies.

Confidence is part of the answer, not an implementation detail. A score and a stated reason turn a verdict from “trust me” into something a reviewer can act on.

Design for the messy case, not the clean one. Bilingual, scanned, and inconsistent documents are the normal case in cross-border commercial paperwork — build for that from the start rather than retrofitting it.

What’s next

The roadmap ahead focuses on three things: expanding the alias and normalization tables from configuration rather than code so new clients onboard without engineering time; tightening service-line alignment further for very large, multi-hundred-line pricing schedules; and adding direct write-back so a confirmed correction can update the source ERP record instead of just flagging it for someone else to fix by hand.

The underlying bet is a simple one: verification work built on scanned, bilingual, inconsistently-formatted commercial paperwork is exactly the kind of task where a document-reading model paired with a disciplined, explainable rules layer outperforms either keyword search or a fully manual process — and does it in minutes instead of hours.