Supplier invoices that match the delivery actually received

The commercial problem

Invoices arrive in several email formats. Proof of delivery lives in a warehouse folder or on paper. Price discrepancies surface after the payment run rather than before it.

The finance team spends its week chasing evidence instead of managing cash and supplier relationships. Invoice status is not visible until a person rebuilds the story from emails, files and messages.

How the work runs before

1. A supplier emails an invoice to the accounts inbox.
2. An administrator downloads it and types the details into a spreadsheet.
3. They search for the purchase order in a separate purchasing sheet.
4. They message the goods in supervisor to confirm delivery, shortages and rejected produce.
5. Exceptions live in email threads. A credit note can be missed if a supplier replies on an older chain.
6. The finance manager reviews invoices before a weekly payment run, often with incomplete supporting evidence.

What makes it hard to automate safely

• A chilled delivery can be partly rejected for quality or temperature. Matching has to understand accepted quantity separately from invoiced quantity.
• Every supplier uses a different invoice layout and its own product descriptions.
• Financial commitment and supplier dispute stay with a named person.
• No write access to the accounting system and no payment initiation is delegated to software.

What we change first

The workflow was simplified before any model touched it. Purchase order references and goods received notes were standardised. Warehouse staff moved to a short exception form covering shortage, damage, temperature failure and substitution. That change alone made the evidence reliable enough to match against.

The redesigned workflow

1. An invoice enters a dedicated mailbox and lands in a review queue.
2. The model extracts supplier, invoice number, dates, line items, VAT, total, purchase order reference and payment terms.
3. The workflow compares the invoice against the purchase order and the goods received record, then assigns a match confidence and an exception reason where the three do not agree.
4. An administrator reviews the proposed fields and any mismatch. They can correct, approve or reject every proposal.
5. Clean matches move to the approval queue. A price, quantity or delivery exception opens a tracked supplier query with a draft message for a person to send.
6. The finance manager approves for payment. The approved register exports to the accounting workflow.

Where the model stops

The model reads documents, proposes a match and drafts a query. It never creates a payment, alters bank details or writes to a financial record. Low confidence and any financial exception route to a person.

What we learned

Extraction alone would not have fixed this. The real bottleneck was inconsistent delivery evidence. Standardising the goods in record made the output reliable and made the people faster. It also shows why payment authority stays separate from document processing: speed is valuable, financial control is worth more.