If your accounts payable problem is that somebody opens emails, downloads PDFs and types numbers into the ERP, the typing is the part you should worry about least. Reading a supplier invoice is close to a solved problem, and increasingly it is solved inside the system you already pay for.
The work that remains is validation. Does the price on this line match the purchase order, within a variance your finance team has agreed. Does the quantity match what receiving actually booked in. Is this the same invoice you paid last month under a different number. And when the answer is no, who exactly picks it up, and by when.
That is where invoice automation projects succeed or turn into a review pile with extra steps.
The join key is the purchase order number
Every check downstream hangs off one field: the purchase order number on the invoice. Get that wrong and nothing else can be evaluated, no matter how accurately the rest of the document was read.
It goes wrong in ordinary ways. The supplier omits it. The supplier quotes their own reference instead. Somebody in the business ordered without raising a purchase order at all, so there is nothing to match against. Or the supplier bills three purchase orders on one document, which is entirely legitimate and which a naive extraction will flatten into a single invoice with a single reference.
Better character recognition does not fix any of those. What fixes them is deciding, in advance, what happens in each case, and making the agent route rather than guess. An invoice with no purchase order reference is not an extraction failure. It is a procurement question with a named owner.
Match at the line, not the total
Header total matching is faster to build and it is the reason some automations pass invoices they should have caught.
Consider an invoice where the supplier has raised the unit price above the agreed rate on one line and short-shipped another. The header total can land inside tolerance while both errors sit underneath it. You have paid an unapproved price increase and paid for goods you did not receive, and the control that was supposed to catch both reported a clean match.
So the checks run per line. Supplier identity must agree across the invoice, the purchase order and the goods receipt. Unit price is compared against the purchase order. Quantity is compared against what receiving booked, not against what the order said. And line description is worth carrying as a soft check, because it catches outright substitution in the cases where the numeric fields happen to line up.
For services and subscriptions there is no goods receipt, so a two-way match against the purchase order is the correct control and pretending otherwise just generates noise. Agree with your finance team which suppliers fall into which category before you build. The receipt leg is the only check that catches an invoice for goods that never arrived, and it is the leg people quietly disable when the exception queue gets uncomfortable.
Tolerance is a business decision, not a setting
Almost every team ends up setting two thresholds together: a percentage of the line, and a flat cash floor beneath which variances pass regardless. The reason for the floor is freight, fuel surcharges and rounding, which otherwise flag a large number of lines for a trivial amount of money.
Set it too tight and you create an exception queue your accounts payable team cannot clear, at which point somebody widens it under pressure and nobody records why. Set it too loose and the control is decorative. The right number is the one your audit function has agreed and can defend, which means this conversation happens with finance before the build rather than during it.
Two refinements earn their keep. Treat high-value lines differently from low-value ones, because a small percentage of a large line is real money. And decide separately whether any invoice above a stated value always routes to a person regardless of match quality, because that is a control your auditors may want independently of the tolerance band.
Exceptions sorted by cause, each with an owner
A single queue called Exceptions is the most common way these projects fail. It fills up, it is nobody’s job, and within a month it is a second manual process.
Sort by cause instead, because each cause has a different owner and a different acceptable waiting time:
- No purchase order where one was required. Goes to the requester or to procurement, who either produce the reference or authorise a non-purchase-order path.
- Price above the purchase order beyond tolerance. Goes to procurement, who either approve the overage or ask the supplier for a corrected invoice.
- Quantity or receipt mismatch. Goes to whoever owns receiving for that site, who confirm the delivery, dispute it, or post the missing receipt.
- Possible duplicate. Stays with accounts payable, with the earlier document attached.
- Supplier not on the master file, or bank details differing from the record. Goes to whoever owns the supplier master, and it never gets automated, for reasons in the next section.
Each of those needs the source document attached and the agent’s proposed action stated, so the reviewer is making a decision rather than starting an investigation. Each needs its age visible. And the pattern of exceptions should be read monthly, because two or three causes will account for most of the volume and at least one of them is usually fixable upstream with a supplier or a purchase order policy rather than with software.
What must never be automated
Anything that creates a payment fact. Posting a bill that releases money, approving a payment run, or changing a supplier’s bank details. That last one is a well-established fraud route and it should require a person, out-of-band verification, and a record of who authorised it. An agent can notice that the details on an invoice differ from the master record and raise it loudly. It should never act on it.
The agent’s job stops at a validated draft with the evidence attached and a clear statement of what it checked. A person signs.
Switch the native features on first
If you run NetSuite, the platform’s own bill capture has moved onto a document-understanding model and there is a scripting module for extracting structured content programmatically. Other major ERPs have equivalent capability. Turn it on before you commission anything, because it will get you from a PDF in an inbox to a draft bill record with the vendor, dates, amounts and line items populated, and it is included in what you already pay.
What it will not do is decide what happens when the numbers disagree with your other systems, or route a receipt mismatch to the right warehouse supervisor, or maintain the tolerance policy your auditors agreed, or be accountable when it stops working after a release. That is the part we are usually asked for, and it sits on top of the native extraction rather than replacing it.
When to leave it alone
Handwritten documents, photographs of creased paper, and suppliers whose format changes every few months will not give you a stable automation. Nor will a supplier who sends a spreadsheet with a different column order each time.
More importantly: if your business has weak purchase order discipline, three-way matching has nothing to match against, and automating it will mostly produce exceptions caused by your own process. Fix the ordering discipline first. It is a policy conversation, it costs nothing but goodwill, and it will improve the numbers more than any software we could sell you.
And if an ERP migration is already planned, build after it. Match logic and tolerance rules are configured against a particular chart of accounts and a particular vendor master, and a migration changes both.
How we do this
We put a supervised agent on one existing workflow, inside the systems the client already runs, and anything that creates a legal, claims or payment fact waits for a person. The document version of that is on the document processing workflow page.
If you want to know whether your invoice queue is a sensible first workflow, the first step is a free thirty-minute assessment. Bring the pile, including the awkward suppliers.