How a negotiated saving becomes a realised one.
Finance rarely disputes that procurement negotiated something. It disputes that the number can be traced. This sets out the chain between the two, and what finance can verify at each step.
The objection, stated fairly
The finance objection to procurement software is rarely about procurement. It is that the savings figure arriving from procurement cannot be reconciled to anything in the ledger. A number is reported, finance cannot trace it to transactions, and the two functions end up negotiating about the number rather than acting on it.
That gap is structural rather than political. A saving agreed in a sourcing event is a forecast. It becomes a realised saving only if the requisition routes to the contract that carries the negotiated price, the purchase order is raised at that price, and the invoice matches. Each of those is a separate system event, and each is a place the chain can break without anyone noticing.
No reporting layer repairs a broken chain. A dashboard built on top of disconnected events produces a confident number with nothing underneath it, which is precisely what finance has learned to discount.
The five links, and what finance can verify at each
The useful question is not "what did we save?" but "at which point can I check?" There are five, and each leaves a different kind of evidence.
1. Award
The sourcing event produces a bid history and an award rationale. What finance can verify here is not the saving but the comparison the price came from — who bid, at what, and why this one was chosen. A price with no comparison behind it is an assertion; a price that beat four others in a recorded event is an observation.
2. Contract
The awarded price and terms land on a contract record. What finance can verify is that the price awarded is the price contracted. This link fails more often than people expect, usually through renegotiation after award that never makes it back into the reported number.
3. Requisition
A buyer raises a request, and it routes to that contract. This is the weakest link in most organisations, and the most consequential: a request that never reaches the negotiated agreement produces spend that looks compliant in the ledger and is not. What finance can verify is whether buying went to the contract or around it.
4. Purchase order
The order is raised at the contracted price and becomes a commitment. What finance gains here is timing — the commitment is visible before the invoice arrives, which is the difference between a forecast that reflects reality and one that is always a month behind.
5. Invoice
The invoice is matched against the order and the receipt. What finance can verify is that the price paid is the price agreed. Where the three-way match holds, the saving is no longer a claim. It is arithmetic.
Where the chain usually breaks
In our experience the failures cluster in three places, and none of them is the sourcing event everyone focuses on.
Between contract and requisition. The agreement exists and nobody buys against it, because finding it is harder than emailing a supplier directly. This is a routing problem, not a compliance problem, and treating it as the latter produces policy nobody follows.
Between award and contract. Terms move after the event — a volume commitment softens, a rebate is dropped — and the reported saving still reflects the award. The number was true once.
At the invoice. Exceptions are resolved by people under time pressure, and a price variance small enough to wave through is exactly the size that erodes a saving across a year of orders.
What this does to the number
Tying savings to a verifiable chain almost always makes the number smaller. That is the right trade, and it is worth saying plainly to whoever owns the target.
A large figure that cannot be reconciled costs credibility every time it is questioned, and it is questioned in every meeting where budget is allocated. A smaller figure that survives audit is spendable: it can be taken to a board, held against a forecast, and used to argue for the next investment. The first number wins the presentation; the second wins the argument.
What to ask your procurement team
These questions do not require a platform to answer, and the answers tell you where you stand today.
- For last quarter's reported savings, can we trace any single line from award through to a paid invoice?
- What proportion of spend in the categories we sourced actually went through the resulting contracts?
- When terms change after award, what updates the reported number?
- Are commitments visible to finance at PO, or only when the invoice arrives?
- Who resolves invoice price variances, and against what tolerance?
Where the answers are uncomfortable, the gap is usually in links three and four rather than in the negotiation itself — which is good news, because those are the links a system can close.
How procurEngine approaches this
The platform's contribution is not a better savings dashboard. It is keeping the five links connected on one data model, so the evidence exists without anyone reconstructing it: sourcing events that retain their bid history, contracts that carry the awarded terms, intake that routes requests to those contracts, and invoice matching that closes the loop.
Where your existing ERP already holds some of these links intact, it stays the system of record and we work upstream of it — see how the integration is scoped. The aim is an unbroken chain, not a replacement programme.
If you want to walk through where your own chain breaks, that is a more useful conversation than a demo. Talk to us, or read the finance view of the platform.