Blog · Procurement and supply chain · Procurement
How a procurement team, or the finance team checking it, measures whether a claimed saving reached the ledger: the baseline price per item before the sourcing event, the contracted price after, the invoiced price actually paid per line, the volume that moved to the contracted supplier, savings claimed against savings realised per category and per project, the leakage between the two by cause, and the identity that ties realised savings to the difference in what was paid.
Procurement claims a twelve percent saving on a category after a sourcing event. Finance sees three percent in the ledger. Both numbers are honest and the difference is leakage that the invoice lines can explain by cause. This guide sets out the baseline, the claimed and realised figures, the four leakage causes, and the identity.
Per item, per sourcing project:
Baseline price = price paid per item in the stated period before the event, from invoices Contracted price, from the new agreement Claimed saving = (baseline − contracted) × expected volume Realised saving = Σ over invoice lines after the event of (baseline − invoiced price) × quantity
Leakage = claimed − realised, by cause.
Supplier identifiers only.
realised saving = spend at baseline prices on actual volume − actual spend, for the items in scope
If the invoice lines' saving does not equal that difference, a line is priced at neither baseline nor contract and is listed.
| Cause | Test | List |
|---|---|---|
| Volume stayed with the old supplier | Lines after the event with the old supplier | Sites and requesters buying off the new contract |
| Invoiced above contract | Invoiced price > contracted price | Lines with the variance |
| Specification changed | Item's specification version changed after the event | Items no longer comparable |
| Volume fell | Actual quantity < expected | Not a leak; a forecast miss, stated |
Category: packaging. Event: new contract, 1 March. Expected annual volume 1.2m units.
| Line | Value |
|---|---|
| Claimed saving | $480,000: baseline $2.10, contracted $1.70, on 1.2m units |
| Realised saving, invoice lines to date, annualised | $140,000 |
| Leakage | $340,000 |
| Cause | Value | Detail |
|---|---|---|
| Old supplier still used | $190,000 | Two plants, 470,000 units at $2.08 |
| Invoiced above contract | $60,000 | New supplier billing $1.82 on a third of lines |
| Specification changed | $50,000 | One item now a heavier grade at $1.95 |
| Volume fell | $40,000 | 1.05m units, not 1.2m |
Three of the four are recoverable, with owners: the two plants, the supplier's billing, and the item change. The realised figure rises as each is worked, and finance watches it rise on the ledger.
Baseline from a quote. Nothing to verify; the claim is a story.
Claimed reported to the board. Twelve percent that becomes three.
Leakage unexplained. Procurement and finance argue about a gap neither can see.
Volume miss counted as leakage. It is a forecast miss; say so.
Mapped once, the invoice lines, the sourcing projects and the item master produce claimed, realised, the leakage by cause and the identity per project and category every month. Covirage builds this from the exports as they are. The procurement page describes the setup, and the maverick spend guide covers the largest leakage cause by requester.
The price paid per item in the period before the sourcing event, from the invoice lines, stated per item and dated. Not the supplier's list price, not a quote. A baseline nobody can trace to invoices is a claim nobody can verify.
Because a savings programme reported at twelve percent that shows up as three in the ledger is a credibility problem for procurement and a budgeting problem for finance. The realised figure, with the leakage explained, is the one both can sign.
Four, from the joins: volume still bought from the old supplier, from the supplier on each line; lines invoiced above the contracted price, from the price comparison; items whose specification changed, from the item master; and volume below the claimed quantity, from the counts. Each is a list with a value and an owner.