Resolving invoice exceptions across PDFs and ERP

An invoice arrives for EUR 2,400. The order and delivery record support EUR 2,000. Finance needs to know what explains the extra EUR 400, who should check it, and which records to open.

We will build a review queue that answers those questions. It reads the invoice PDF, checks the purchasing records, and prepares a short report. A person handles the exception through the company’s normal process.

All amounts in this example exclude tax, discounts and freight. The unit is each, and the currency is EUR. There is one invoice line and one order line. We will keep those limits visible rather than pretend this first version covers every invoice.

An ERP is the business system that stores orders, receipts and invoices. Comparing those three records is often called three-way matching. First check whether your ERP already does this well. If it does, use its result and improve document capture and the review screen around it.

Start with one legal entity, one ERP, purchase-order invoices, and one invoice currency. Choose a small set of suppliers. Ask finance to label sample invoices as matched, missing receipt, wrong price, duplicate, or unclear. Keep some suppliers for the final test so the reader must handle layouts it has not seen before.

Our teaching rule uses zero tolerance and no returns. Your production adapter must read net accepted receipts, returns, earlier invoices and credit notes using the ERP’s rules. A service invoice may need proof of completed work instead of a goods receipt. Give those cases their own rule.

These are starting choices, not benchmark winners. Microsoft’s current guide distinguishes standard invoice fields from highly varied documents. Test both reading routes on your suppliers. Measure the time spent correcting them, not just how tidy the JSON looks.

Save the original PDF under a generated file ID. Ask the reader for supplier name, invoice number, order reference, currency, quantity, unit price and line amount. Document Intelligence’s prebuilt-invoice model returns structured fields and line items. Its documented v4.0 API version is 2024-11-30.

Store three things together: the original text, the checked value, and its page or source region. For example, keep 20,00 beside the decimal value 20.00. If the quantity is unclear, send that field for review before doing the match. A high model confidence score does not prove the supplier billed correctly.

Resolve the supplier against the approved supplier list. Then use the order ID and line ID to fetch the order, posted receipts and earlier bills. The server must obtain the allowed company from the signed-in session. It must not accept a company ID chosen by the PDF or the model.

Keep the source system, record ID, version and read time. Match the supplier, item, unit and currency before comparing amounts. If any of those checks fail, hold the case. Similar-looking supplier names or nearby invoice numbers are suggestions for a reviewer, never an automatic match.

The invoice’s own maths is correct: 120 × 20 = 2,400. The problem is that the available order and receipt support only 100 units. No units have been billed before. The extra 20 units are worth EUR 400 at the approved price.

Check quantity and price separately. A lower price must not hide an unsupported quantity. Do not decide from a net total alone. Missing or stale receipts mean “cannot check delivery yet”; they do not justify treating the receipt as zero.

Use decimal arithmetic for money. Keep both the invoice values and the difference. Never silently replace 120 with 100 to make the invoice pass.

Now finance asks: “What do we do if some goods have not arrived?” The approved policy may call this “partial delivery” or “quantity variance.” This is where searching by meaning can help.

Keep two paths. Exact ERP records decide the numbers. Search finds the policy text that helps a reviewer act on the result. If the case already has a trusted rule ID, fetch that rule directly. Use search when the question or policy is not yet identified.

Filter by company, permissions, policy status and effective date before choosing the passages to show. Decide with finance which date governs the rule: invoice date, posting date or review date. Save that choice. The newest document is not automatically the applicable one.

Start with keyword search. Add semantic search when your test questions miss relevant clauses with different wording. Combine their ranked results, then inspect a small set of passages. No useful passage means “policy not found”; conflicting rules go to the policy owner. Neither situation changes the calculated invoice difference.

Use a durable queue: a saved list of jobs that survives a restart. In this stack, a worker can use Bull and Redis, while PostgreSQL stores the case state and completed steps. A retry must check those records before repeating work.

A direct ERP API is enough for these fixed steps. Use MCP only if the company already exposes the same narrow tools through it. An agent may help investigate an unusual case later, but it still needs a runtime that limits tools, retries and spend.

Use one intake key per company and file hash to stop repeat uploads creating repeat jobs. Check business duplicates separately using the supplier and invoice identity; two different PDFs can contain the same bill. Bound retries and service calls. Send exhausted jobs to a failed queue with a clear reason.

Put the invoice page beside the checked fields. Highlight the source region only when extraction actually supplied it. Let reviewers correct a field with a reason; keep the old value and file version in the history. Record who resolved the exception and what evidence changed.

If you later add an ERP write, show the exact proposed change first. Recheck permission and source versions when the reviewer approves. A changed order invalidates the old proposal. Use a separate write adapter and a unique action key so a retry cannot submit the same change twice.

Measure missed exceptions, false alarms, wrong field values, useful policy passages and reviewer correction time. Include provider calls, retries and human review in the cost. Compare with the current process on the same invoices. Set the acceptance limits with finance before reading the results.

Download the invoice exception lab. Unzip it, open a terminal in the extracted folder, and use Python 3.11 or later. The checker needs only Python’s standard library.

Open the synthetic PDF, compare it with fixtures/base.json, and run the command. Read the reason codes and source references in the output. Then try the supplied missing-receipt and partial-billing examples. The README names exactly which parts run locally and which connections you still need to build.

The lab treats one fixed order-line ID as the item match. The live ERP adapter must also verify the item itself. Its company selector and saved timestamps are teaching inputs, not a login system or a live connection. The example selects its rule using the stated review date.

First run beside the existing process. Let finance compare the reports without changing ERP records. Fix recurring field and matching errors. Add policy search only if it helps reviewers answer questions they could not resolve quickly. Expand suppliers and invoice types one group at a time.

The useful result is simple: a person can see what differs, which records prove it, and what to do next. The linked articles explain the technology when the reader wants that detail.