A price baseline that refuses to invent a saving

An operations team buying thousands of distinct items cannot see which prices moved against it.

A price increase on a single line is invisible at the scale a purchasing team works at. The invoice matches the order, the order was approved, and the total looks like every other week’s total. What is missing is the comparison: what this item cost the last time, from this vendor and from the alternatives, and whether the movement is a market change or a quiet reprice on one account.

The usual answer is a spreadsheet comparison built once by somebody determined, then abandoned because keeping it current costs more than the insight returns. The harder problem underneath is matching. Two catalogue entries that look like the same item frequently are not, and a comparison that pairs them produces a saving that was never available.

I specified the baseline and the confidence floor the matcher refuses below, and I ratified each release; AI agents wrote most of the code under my gates.

The source implements a pricing baseline, repricing proposals, kits, per-job bills of material, leakage checks and vendor comparisons. Repricing pairs catalogue items with purchase evidence and excludes candidate pairs below the configured confidence threshold.

I required the matching caveat: two different products can look like a saving when compared as if they were the same. An excluded candidate is a matching gap, not a saving to quote.

The baseline records what an item has actually cost, drawn from purchase evidence rather than from a catalogue list price. Repricing then pairs catalogue items with that purchase evidence to propose where a different vendor or a different line would have cost less.

The part I insisted on is the floor. Every proposed pair gets a confidence score, and anything below the configured threshold is excluded rather than shown with a caveat. A number on a page is acted on; a caveat beside it is not. An excluded candidate is a matching gap somebody could close by improving the catalogue data, not a saving anybody can bank.

The surrounding analyses use the same baseline. Kits and per-job bills of material let a cost be traced from a job back to the lines that made it up. Leakage checks look for spend that bypassed the expected path. Building each of them on one baseline is what lets a figure be reconciled rather than defended.

The portfolio source records scheduled operation and a draft specification. The inspected code implements the baseline and its dependent analyses. No realized savings have been measured, and this case study has not independently rechecked a current scheduled run.

No saving has been realized, quoted or measured, and that is the deliberate position of the work rather than a gap in the record. A system that reports a saving it cannot substantiate is worse than no system, because the figure gets repeated in a meeting and then has to be defended.

What a buyer of this work should ask for instead is the rate of matched lines, the share of spend covered by the baseline, and, after a repricing decision is actually taken, the difference between the proposed and the invoiced price. Those are measurable. None of them is claimed here.

If a number is hard to explain or trust, the reporting and reconciliation engagement traces it back to the records behind it and makes the data’s freshness visible. The record-quality work this depends on is in read-only ERP checks, and the buying controls it sits beside are in rebuilding purchasing controls during an ERP migration.