AI for invoice processing in retail: matching millions of lines to what actually turned up

Retail accounts payable is not a document problem. It is a reconciliation problem in a document costume.

The invoice is usually the cleanest artefact in the chain. It arrives as structured EDI from your larger suppliers, already coded and carrying line detail. What it is matched against is the mess: a purchase order raised by a replenishment system in cases, a goods received note keyed at a distribution centre against a clock, and a paper delivery note signed at a store back door, two crates struck through because they came in short.

So the interesting work is not extracting fields. It is deciding, at line level and across tens of thousands of invoices a week, whether the quantity billed entered the business, whether the price billed was the price agreed on the day of delivery, and whether the difference is worth stopping a payment over.

What actually arrives, and in what shape

Any design starts with an inventory of inbound formats, because retail AP runs four or five channels at once and each fails differently.

EDI invoices from your top suppliers are structured, high volume, and where most of your spend sits. They are also where silent mismatches hide, because nothing looks wrong on the face of the document. The failure is a case quantity that disagrees with the pack configuration on your item master, or an invoice against a purchase order amended after it was sent.

PDF invoices arrive into a shared mailbox, sometimes one per message, sometimes forty in a monthly statement attachment, sometimes as a covering email with the detail in a spreadsheet. The agent splits the attachment, decides which pages belong to which invoice, and recognises that page four is a continuation rather than a new document.

Supplier portals hold invoices never sent to you at all. Someone has to log in, download and reconcile against what was expected.

Scanned paper is the residue: small local suppliers, produce merchants, and every proof of delivery signed at a store. These are photographs of thermal paper taken in bad light, carrying handwriting that is the only record of what the store actually accepted.

Goods received data comes from different systems again, warehouse management in the distribution centre and store systems for direct delivery, in different units and on a different clock.

Three way matching when the receipt is a signature on a pad

The textbook three way match assumes a purchase order, a receipt and an invoice describing the same thing in the same units. Retail rarely obliges.

Units, packs and the case conversion trap

The purchase order is in cases. The goods received note may be in cases, outers, layers or pallets. The invoice is in whatever the supplier bills in, which may be units if they changed a pack size and did not tell you. An agent doing this properly holds the item master pack hierarchy, normalises to a base unit before comparing, and flags the conversion as a likely cause when quantities disagree by exactly a case factor.

Short shipments, over deliveries and the tolerance question

Short shipments are routine, so the question is never whether quantities differ but what the rule is: pay as delivered, pay as invoiced and claim later, or hold. Where the receipt is lower than the invoice, the agent either raises a debit or price adjusts the line down, per the rule for that supplier and category, then writes the adjustment back to the ERP with the receipt reference attached.

Over deliveries are harder. One accepted and sold is a cost you owe, one refused at the gate is not, and the only evidence distinguishing them is often a biro annotation on the delivery note.

Catch weight and weight based goods

Meat, fish, cheese and produce billed by weight break the arithmetic entirely. You ordered twelve cases, received twelve cases, and the invoice is for 143.6 kilograms at a price per kilogram. The match has to run on weight against the weighed receipt, not case count, with a tolerance reflecting natural variation and shrinkage in transit. The agent needs to know which lines are catch weight before it starts, which means reading the item master, not inferring it.

Price file mismatches, promotions and funding

Quantity disputes are visible. Price disputes quietly cost money for a year.

The invoiced price has to be checked against the cost in force for that item, supplier and delivery date, which is not always the price on the purchase order, because cost changes and promotional periods move independently of when the order was raised.

The common patterns are worth naming. A cost increase applied before its effective date. A promotional cost that should have applied and did not, so you paid full list during a deal period. Off invoice allowances missing, so a deduction that belonged on the face of the invoice now has to be claimed retrospectively. A price taken from the wrong band when you buy across territories or banners.

The agent reads the price file, resolves the price in force at the receipt date, recalculates the extended line value, and where it differs writes a claim with the source of the agreed cost attached. The valuable output is the pattern rather than the claim: one supplier short by a few pence on one line every week is a bigger number than any single held invoice.

Rebates, deductions and chargebacks

Money in retail flows both ways, and the terms behind volume rebates, retrospective discounts, listing fees, marketing contributions and promotional funding often sit outside the ERP, in spreadsheets owned by the commercial team.

Two things follow. Deductions need to reconcile to a term somebody can point at, or the query inbox fills with challenges you cannot answer. And when a chargeback is disputed, the agent should assemble the case file: the term, the calculation, the receipts, the delivery note image and the claim reference, so a person spends two minutes on it rather than twenty.

Chargebacks for service failure, late delivery, incomplete pallets and non compliant labelling are a further category. They originate in operational systems, land on the supplier account as debits, then collide with invoices at payment run time.

Direct store delivery, freight and tax

Direct store delivery invoices never touch a central purchase order. A bread or soft drinks supplier delivers, the manager signs, and the invoice has to be matched against a store level receipt that may only exist as paper or a handheld scan. The agent matches invoice to proof of delivery to store receipt, checks price against agreed cost, and routes anything unmatched to the store rather than head office, because only the store knows what came in.

Freight and haulage appear both as separate carrier invoices and as lines on supplier invoices, and the test is whether the delivery terms make carriage yours at all. A delivered price with a haulage line added is a double charge, trivially checkable once the terms are readable.

Tax treatment is unglamorous and expensive to get wrong. Zero rated and standard rated goods sit on the same grocery invoice, self billing has its own rules, and multi territory operations add registration numbers, reverse charge lines and currency. The agent validates the tax code per line against the item rather than accepting the supplier's coding, and escalates what it cannot reconcile instead of posting a guess.

The payment run and the query inbox

What the agent writes back decides whether any of this is useful. For a clean match it posts the invoice against the purchase order and receipt, codes it, and releases it to the payment proposal. For an exception it writes a block with an actionable reason code, the line at fault, and the evidence beside it. For a difference within tolerance it adjusts and posts rather than holding, because a queue of penny differences is how teams stop trusting the system.

The query inbox is the other half of the job. Most of what lands there is answerable from data the agent already holds: whether an invoice was received, where it sits, why it was blocked, what was deducted against which claim, and when it pays. Drafting those replies for review clears the routine traffic and leaves the real disputes to people who can settle them.

Where AI fails here

Bad master data defeats this completely. If pack hierarchies are wrong, supplier records are duplicated across banners, or cost prices reach the ERP on a weekly job from a spreadsheet, the agent produces confident matches against the wrong reference and you are worse off than with a human who knew to be suspicious. Most of the effort here is data readiness, better said before a project than during one.

Missing receipts cannot be inferred. Where a store never keyed a delivery, or the goods received note was raised days later in a batch, there is nothing to match against. The agent can flag the absent receipt and chase it. It cannot decide the goods arrived.

Handwriting on delivery notes has a real error rate. A struck through line and a pencilled quantity is often ambiguous even to the person holding the paper. Any system reading these should surface its uncertainty rather than posting a number and moving on, because a wrong quantity read confidently is worse than a flagged one.

Trading terms held informally stay out of reach. Verbal agreements between a buyer and a supplier, side letters and funding promised over a call are real commitments that exist nowhere machine readable, and an agent enforcing only written terms raises claims the commercial team then withdraws.

Relationship judgement stays human. Whether to block payment to the supplier of a critical line during a shortage, or absorb a modest overcharge rather than reopen a negotiation, is a trading decision. The agent finds and evidences the difference. Someone else decides what to do about it.

Where to start

Run it retrospectively first. Take a quarter of paid invoices for one category and have the agent rematch them against the receipts and price files in force at the time. Nothing is at risk, the recoveries are real money, and the exception patterns tell you which of your own processes generate the noise.

Then pick the narrowest live scope with the highest volume, usually distribution centre EDI invoices for a few large ambient suppliers, and leave everything else on the existing process until the match logic has earned trust. Catch weight, direct store delivery and paper come later, because each needs evidence the first phase teaches you to collect.

Adopt AI Partners builds these against the systems and trading terms you already have.