We automated invoice entry. The hard part was the exceptions.

Reading a PDF invoice is solved. Deciding what to do with the one that does not match the purchase order is where the work lives.

A client was retyping roughly four hundred supplier invoices a month into their accounting system. Extraction handled the easy ninety percent within a fortnight. Then we spent as long again on the remaining forty invoices, because those are the ones that can cost you real money.

Why extraction is not the project

Modern document models read a printed or PDF invoice with field-level accuracy in the mid-nineties, and for machine-readable documents higher still. If a vendor demo impresses you, that is the part it is demonstrating. It is also the part that will not determine whether your project works.

The useful design question is not "can the machine read this", it is "what happens when the total is off by two hundred rupees". Answer that badly and you have built one of two failure modes: a queue nobody trusts, so everything gets rechecked manually and you have added a step; or a system confident enough to post wrong invoices quietly, which is worse.

Good automation makes the exceptions visible. Bad automation makes them disappear quietly.

The exception taxonomy

Before designing rules, we spend a session listing every way an invoice can fail to be routine. For most SMBs the list is short and stable:

• Price variance — the unit price differs from the purchase order.
• Quantity variance — a partial delivery, or an over-delivery nobody authorised.
• No purchase order — common for services, utilities and ad-hoc purchases, and often the largest single category.
• Suspected duplicate — the same supplier, amount and date, or a re-sent invoice with a new number.
• Unknown supplier — not in the master file, or a name that is nearly but not exactly one that is.
• Changed payment details — different bank account from the one on record.
• Tax and entity errors — wrong VAT treatment, wrong legal entity, missing VRN.
• Currency and rounding — foreign-currency invoices where the posted rate differs from the invoice rate.
• Illegible or non-standard documents — photographs of paper, statements sent instead of invoices, several invoices in one PDF.

Each of these needs an owner and an action. That is the actual specification.

Designing the decision rules

We built the rules with the finance lead, in her language, and wrote them on a whiteboard before anything was configured. Roughly:

Two design principles carried most of the weight. First, an exception must arrive with the evidence attached — the reviewer should never have to go and find the purchase order. Second, every automatic decision is logged with the rule that made it, so the finance lead can audit the machine the same way she would audit a junior.

The control that is not negotiable

A change of supplier bank details never gets applied automatically, regardless of amount, supplier history or how well the rest of the invoice matches. It goes to a person, who confirms by telephone on a number already held in the supplier record. We wrote about why in the Port Louis invoice fraud case — the attack works precisely because everything else about the document is correct.

Automating accounts payable without that rule does not just leave the risk in place. It removes the one moment of human attention that used to catch it.

How to know whether it is working

"Invoices processed" is not a measure of anything. Four numbers are:

• Touchless rate — the share posted with no human keystroke. Ardent Partners' 2025 benchmarks put the all-buyer average around 25%, with best-in-class teams at 35% and above. If your rate is low, the problem is usually PO discipline upstream, not the automation.
• Exception rate — top performers sit near 9%, against an industry average of 22%. A falling exception rate over the first three months means the rules are learning your suppliers.
• Cost per invoice — the widely cited manual figure is around US$12–13, with best-in-class automated teams near US$2.80. Treat those as direction, not as a promise: they come from larger AP functions than most Mauritian SMBs run.
• Cycle time — best-in-class teams close in about 3 days against 17 for everyone else. For our client the value was not speed for its own sake; it was catching pricing errors while the supplier still remembered the order.

A four-week rollout that finance will trust

1. Week one — observe. Run extraction in parallel with the existing manual process. Post nothing. Compare the machine's output against what the person keyed, and count the differences.
2. Week two — rules. With the finance lead, set tolerances, thresholds and the exception taxonomy above. Agree who owns each queue.
3. Week three — supervised. The machine proposes, the person approves. Every decision is visible. This is where the trust is built, and skipping it is the most common reason these projects stall.
4. Week four — live, narrowly. Turn on automatic posting for the safest category only. Widen it monthly, on evidence.

When we tell people not to automate this

If you process fewer than about eighty invoices a month, the payback is thin and the honest advice is to fix the intake process instead — one email address for invoices, a consistent file naming rule, and PO discipline. If your supplier master file is unreliable, clean it first; matching against bad reference data produces confident nonsense. And if there is no named person who will own the exception queue, do not start. The queue is the system.

This is the same argument we make about chatbots: the technology is rarely the constraint, the underlying process usually is.

What changed

The person who used to do data entry now reviews the exception queue for about twenty minutes a day and spends the rest of her time on supplier queries. That was the point. Nobody lost a job; the job got better — and the business now finds pricing discrepancies it was previously paying without noticing.

Frequently asked questions