Invoice capture · from the workshop

Forty clarification cases are not a capture problem

6 minInvoice capture

An accounts payable clerk once walked me through how she spends her mornings. Not on accounting. On follow-up questions.

Two to three hours, every day, for a stack of incoming invoices she herself described as "perfectly normal". What stayed with me was not the number. It was how ordinary she made it sound.

The reflex at this point is always the same: you need a capture solution. They had one. A good one. Recognition was well past ninety-five percent — vendor number, invoice number, amounts, line items, all read cleanly. And still: two to three hours.

Recognition is solved. What comes after is not.

This is where most conversations about incoming invoices go wrong. They circle around recognition rates, because recognition rates are easy to measure. But what a document contains has not been an open question for years. What should happen to it — that is a completely different kind of problem.

So I started writing things down. Not the failures of recognition, but the reasons a correctly recognised invoice still ends up on someone's desk. Over forty recurring themes came together, at a single customer. Nothing exotic. Just the working day:

01Price differs from the purchase order — sometimes by two cents of rounding, sometimes by a price break nobody maintained.
02Quantity differs, because the supplier over-delivered and no tolerance is configured.
03The invoice is here, the goods receipt is not — or the other way around.
04One invoice across several orders. Or several invoices against one.
05Freight, packaging, surcharges: lines that never had an order line to begin with.
06Cash discount, payment terms, currency, tax codes — each with its own special logic.
07The vendor is ambiguous, because they exist under three different numbers.
08Partial delivery, credit note, invoice correction, duplicate.
…And another thirty-two, all with the same thing in common.

Read that list and the pattern is immediate: not one of these can be decided from the document. You need the purchase order, the goods receipt, the price break, the vendor master, the company's own tolerance rules. None of that lives in the capture solution. It lives in Dynamics 365.

Capture knows what the paper says. Only the ERP knows whether it is right.

Which is why I sit on the other side

That is exactly why we are not building capture. Excellent solutions already exist, and we are not competing with them. We are the client inside Dynamics 365 — the side that receives the recognised document and takes it where it belongs.

That sounds like a small role. It is not. This seam is precisely where it is decided whether a document occupies a person or not. Handing data over by API is two days of work. The question of what happens to an invoice that is off by 1.80 euro occupies a company for months — because the answer depends on who the supplier is, how large the amount is, and who signs when in doubt.

Four entry points, not one

We support four ways into Dynamics 365. That is not a feature list, it is an observation from thirty years: companies post differently, and they have good reasons.

Vendor invoiceSupplier invoices without an order reference — the vendor already exists in Dynamics 365.
Invoice registerSupplier invoices with an order reference, through the incoming invoice workflow.
Pending vendor invoiceInvoices in transit with an order reference — three-way match against order and goods receipt.
General ledger journalFor everything without an order: rent, insurance, telephone.

An invoice solution that knows only one of these forces the company to bend its process around the tool. That is the wrong way round.

Where this is going

The goal is not to push recognition up another two percentage points. The goal is that nine out of ten invoices never meet a human — because the clarification cases get decided beforehand: against the order, against the goods receipt, against configured tolerances, against the rules the company already has. Until now they lived only in the clerk's head.

Today2–3 hrsa day on follow-up questions and clarification
Target5–10 minonly what genuinely needs a decision

Not because the machine got smarter, but because it finally has access to the knowledge sitting next door in the ERP.

None of this is finished. It is the project I am working on right now, and I am writing from the workshop rather than the brochure. What interests me most is the list: I am past forty themes — and I am fairly sure every company knows two or three that are still missing from mine. If you have one, write to me. That is exactly what the rule set gets built from.

Talk to me about it

This post is also available in German. Auf Deutsch lesen

All posts