The work
OperationsRetail

Grocery back office clerks match every supplier invoice to its delivery note by hand, and a proof of concept did it straight off the paperwork.

a large supermarket chain

A proof of concept, demonstrated on real documents. Nothing is in production.

The situation

How this used to work

Somebody at the group has to confirm that what a supplier invoiced is what the supplier actually delivered. That means putting each invoice next to its delivery note, and it is done by hand.

The shape of it is a person holding paper. They take a bundle of invoices for one store and one range of dates, open the finalisation screen, filter it down to that store and those dates, and then work through the stack in their hands looking for each document in the list on the screen. When they find it, they compare the figure on the screen to the figure on the paper and confirm it.

The dates are the part that does not survive contact with reality. A document carries the date it was issued, printed on it, and the date the goods were received, which is written on by hand with a pen onto a rubber stamp. The client's own estimate is that the receipt date has to be corrected manually around ninety percent of the time.

There is a harder problem underneath. Not every document arrives. Roughly a third do not come down the electronic channel at all, and the client was unambiguous that a system covering half the documents is not worth starting: without a way to check that everything is actually there, there is no project.

What we built

The system

A proof of concept, and the word is doing real work in that sentence. It was built to answer whether this is possible on their actual paperwork, demonstrated in April, and it is where the engagement still sits.

It reads the documents, extracts the fields, and matches in two passes. The first looks for an explicit cross-reference, where the invoice names the delivery note. The second falls back to comparing several things at once when no such reference exists.

Product descriptions are compared by overlap rather than by exact string, because a supplier's product codes and the group's product codes are two different systems that were never going to line up. It also compares quantities line by line, so a short delivery shows up as a short delivery rather than as a failed match.

The design agreed afterwards adds the check the client made a condition: a stage that confirms every document exists in at least one channel before any matching begins.

How it works

The pipeline, step by step

01 / Read

Whatever the document happens to be

Invoices, delivery notes, credit notes and return notes, as they actually arrive rather than in a clean format. In the demonstration this ran over real documents from the group's own suppliers.

02 / Match

Five fields, and the amount is not one of them

The key is the document type, the store, the supplier's tax number, the document number and the date. The monetary value is left out on purpose. It can legitimately differ between the two documents, because of a free pallet or a surcharge, and including it turns a correct match into a false negative.

03 / Compare

Descriptions overlap, they do not equal

Where there is no shared code to join on, the product descriptions are compared by how much they overlap. This is the difference between matching a real supplier's paperwork and matching a tidy example of it.

04 / Flag

A short delivery is a finding, not a failure

Quantities are checked line by line, so an invoice for more than what arrived is surfaced as a discrepancy with a draft claim letter attached to it, rather than disappearing into an unmatched pile.

05 / Stop at the database

Nothing is written into the ERP

Results go into an intermediate database the group already runs, with one added column meaning this pair was checked by the application. Writing into the ERP directly is ruled out, for licensing reasons and for a better one: an automated finalisation that throws an error inside a system we do not control is an error nobody can see. A person still performs the finalisation.

What changed

The result

On the demonstration set, seven of ten delivery notes were matched correctly to their invoices with no tuning of any kind, across six real documents and thirty seven pages. That is a demonstration on ten documents. It is not an accuracy rate, and it is stated here with its denominator attached because it is the only measured number this project has.

What it settled was feasibility, which was the question actually being asked. The architecture that followed was agreed in May and the commercial terms were negotiated close to final.

It is not running. The contract is unsigned, the data protection agreement and the confidentiality agreement are both still with the lawyers, no code repository has been opened, and no pilot has been run. This page is a record of a proof, not of a delivery.

The stack

Proof of concept

  • Next.js
  • Tailwind
  • Vercel
  • custom two-pass matcher

Matching

  • cross-reference pass
  • multi-criteria fallback
  • description overlap
  • line-level quantities

Designed, not built

  • coverage cross-check
  • intermediate SQL bridge
  • human finalisation

Status

  • proof of concept
  • contract unsigned
  • not in production

Free 30 minute call

Let's find where AI fits in your business

A 30 minute call, free, no commitment. You leave with two or three things worth building, whether or not you work with us.

Free, no commitmentYou own everything we buildNo slide deck