The gap between what’s negotiated and what’s executed

A contract is a promise about future prices. An invoice is an assertion about a past one. Between the two sits an execution layer that nobody owns. The value negotiated at signature only materialises if someone verifies, line by line, that the price that was signed is the price that was billed.

Look at what actually happens at signature. Procurement has spent months on the deal: the price grid, the indexation formula, the volume tiers, the rebate schedule, the caps on pass-through costs. The savings are computed against the previous contract and booked. The contract is filed on a SharePoint or, at best, in a CLM. Then the supplier’s billing system takes over. From that day forward, every invoice is an implementation of the contract by the counterparty’s IT department.

Savings at signature, savings realised

The savings announced and the actual savings are two different numbers, and almost every organisation reports only the first.

Between them sits a list of small facts that nobody checks: whether the grid was configured correctly in the supplier’s system, whether the indexation formula runs from the right base period, whether anyone is tracking the rebate threshold, whether the surcharge cap is actually applied. None of this is hard to verify on any given line. It just never happens systematically, because verifying it is nobody’s job.

Nobody’s job, by design

There is no fraud in this story, and no incompetence either: the two documents simply never live in the same place. The contract sits with procurement, or legal, or in a finance director’s document store. The invoice sits with accounts payable. No system holds both.

The objective functions match the filing. Procurement is measured on savings at signature. Accounts payable is measured on cycle time, exceptions cleared, invoices processed per person. Nobody’s objective function includes “was the negotiated price actually applied”. What no one is measured on, no one owns.

Why the ERP does not close it

The standard answer is that the ERP already controls invoices, and it does - though against the wrong reference. Three-way match validates purchase order, goods receipt, and invoice against each other. It confirms that what was ordered arrived, and that what arrived was billed at the purchase-order price. It checks consistency but not correctness.

The commercial agreement - the grid, the formula, the tiers - was never in the loop. The purchase-order price was entered by a person, often by copying the previous order. If it was entered from the wrong grid, every subsequent match succeeds, and the ERP enforces the error with perfect discipline.

A concrete version: a transport contract carries fourteen zone grids. At go-live, someone loads one negotiated price per lane into the ERP - the version that was averaged, once, for the master data. The fourteen grids live on in a PDF annex. From then on, every invoice matching the averaged price passes three-way match. Whether it matches the annex, no system can say.

The gap widens as contracts improve

Every negotiation lever adds a conditional: an indexation clause, a volume tier, a cap, a penalty trigger. Each one is a small piece of logic that a billing system executes on one side and a human is supposed to verify on the other, and only one side of that arrangement scales.

So the better the negotiation, the wider the gap it can leave behind. Sophistication transfers value on paper; in execution it transfers ambiguity, and ambiguity resolves, by default, in favour of whoever configures the billing system.

Perverse outcomes

Some procurement teams have read this trade-off and drawn the rational conclusion: simplify. Strip the indexation clause, flatten the tiers, give up the rebate. A simple contract surrenders value at signature, and in exchange it becomes one the team can actually control.

Across the categories we work in - fuel, equipment rental, maintenance, commercial leases, transport, interim staffing to name a few - the share of supplier spend that departs from contracted terms sits between 2 and 5%. That is what we observe, and it moves with contract complexity and invoice volume; a company buying three SKUs from two suppliers does not have this problem, and a company with four hundred framework agreements and two million invoice lines has it whether it knows or not. On $1bn of addressable spend, 2 to 5% is significant.

A measurement problem first

The instinct is to treat this as a recovery problem: find the errors, claim the money back. Recovery is downstream. The upstream fact is that no one can currently answer the question what share of last quarter’s supplier spend matched contracted terms? Revenue is measured to the cent, in real time. Contract execution is not measured at all.

Any serious answer starts by holding the contract and the invoice in the same system and recomputing each line against what was signed. Done properly, it looks like a control rather than a project: a coverage rate - what share of spend is reconciled against a contractual reference; a match rate - what share of reconciled lines priced correctly; and a deviation ledger with root causes. Numbers a finance director can put next to DSO and cash conversion, refreshed every cycle rather than every engagement. Once those numbers exist, the gap stops being an anecdote and becomes a line to manage.

Why it was never done

Capacity. Reading a two-hundred-page contract with fourteen annexes, at the rhythm of thousands of invoice lines a month, across every supplier that matters, was not a job a human team could hold - which is why the historical answer was the recovery audit: episodic, retrospective, sampling the biggest categories every three years and keeping a share of what it found.

That constraint has moved. Language models can now read contracts the way parsers read invoices - every clause, every annex, every line, every cycle. The verification that was economically impossible at invoice volume is becoming a standing control. Fakto is built on that shift.