Supplier price creep hides in invoices nobody reads line by line

The problem

An owner-operator buys from one broadline distributor and a few specialty suppliers. Invoices arrive on paper at the back door or as PDFs in an inbox. Prices on fryer oil, proteins and dairy move from week to week. Case packs shrink while the case price stays put. Substitutions and short-ships appear as one line among dozens.

Margins in this business are thin, so a quiet increase on a high-volume item eats profit for weeks before anyone reprices the menu. Nobody compares line items because the person who would do it is also running the line.

Existing tools miss this. Full inventory and costing platforms expect recipe setup and counting discipline that a small kitchen rarely sustains. Accounting software records the invoice total, not the lines. So the check simply never happens.

Constraints

• Budget: a small monthly fee at most, and no hardware.
• Skills: the owner will photograph or forward an invoice, nothing more.
• Data: invoice layouts vary by supplier, photos are crumpled and greasy, units are inconsistent.
• Trust: one wrong alert about a supplier the owner has used for years and the tool gets ignored.
• Time: output has to be readable in a couple of minutes, once a week.
• No integrations: most distributors offer no API to a single restaurant.

System design

Intake is a forwarding email address and a phone upload. The original image or PDF is stored unchanged and every derived record points back to it.

Extraction is where a vision-capable model belongs. Reading a messy document is exactly the job deterministic code does badly. The model returns lines in a strict schema: supplier_item_code, description, pack size, unit, quantity, unit price, extended price, plus invoice total and tax. Output that fails schema validation is rejected, not repaired.

Everything after that is plain code.

• Reconciliation: quantity times unit price must equal extended price, and lines plus tax must equal the total. If the invoice does not reconcile, it goes to a review queue instead of into history.
• Item matching: the supplier item code is the key. For a new code, the model may propose a match to an existing item, and the owner confirms once. After that the mapping is a table lookup.
• Unit normalization: a conversion table turns every line into price per kilogram, litre or each.
• Detection rules: price change above an owner-set threshold, pack size change at a steady case price, and substituted item codes.
• Digest: a weekly message ranked by money impact, the price delta multiplied by typical weekly volume, each line linking to the source image.

The model reads. It never does arithmetic, sets thresholds or decides what counts as an alert.

Trade-offs

There is no recipe costing, so the system cannot report plate margin. It reports input cost movement, which is the part the owner can act on immediately.

It depends on a photo habit. Invoices that never get captured are invisible, and the digest should say how many invoices it saw so gaps are obvious.

Extraction will sometimes be wrong. Reconciliation catches most errors because a misread price rarely still sums to the printed total, and anything that slips through links to the original.

It does not dispute charges or request credits. The owner calls the rep. That keeps the system read-only and keeps its relationship with the supplier out of scope.

What I would build first

I would start with one restaurant and its main distributor. Email intake, extraction into the schema, the reconciliation check, item code history and a weekly digest of the largest changes. No dashboard.

I would backfill a couple of months of past invoices on day one so the first digest already has a baseline rather than waiting weeks for history.

The test is simple: does the owner find at least one change they did not know about and act on it, through a credit request, a supplier switch or a menu price change. If that happens within two weeks, the rest is worth building.

Let the model read the document, but let arithmetic decide whether it read it correctly.