Every Enterprise Is Running on Two Systems. It Needs a Third.
Ask any enterprise technology leader to describe their core operational infrastructure and you will hear some version of the same answer that we have an ERP for financial transactions, and we have workflow tools that manage how work moves between people and systems.
These are, by any measure, mature and capable technologies. ERPs like SAP and Oracle have spent decades becoming extraordinarily precise at recording every financial reality. Similarly, workflow platforms have become equally sophisticated at moving approvals, contracts, and decisions through organisations with speed and accountability. While both categories are genuinely excellent at what they were designed to do, why does the c-suite still feel the pinch of missing value.
The missing value is that neither was designed to answer what is, in practice, the most consequential question in enterprise commercial governance that Is what we agreed to actually happening?
This question sits in the gap between the two systems. The ERP records what was paid. The workflow tools record that the process ran correctly. Neither one compares either of those outcomes against the terms of the underlying contract continuously, automatically, and at the scale of a modern enterprise's commercial portfolio.
Consider what a typical enterprise contract contains that neither system is watching. Pricing formulas tied to commodity indices that should adjust rates when markets move. Rebate structures with volume thresholds that trigger entitlements when the spend crosses a line. Payment terms negotiated to protect working capital. Escalation clauses that should move prices in a defined, formula-governed direction. SLA commitments with financial consequences if delivery falls short. Renewal windows that require action before a specific date or silently roll forward on unfavourable terms.
While all of this was negotiated and is legally binding, in most enterprises, none of it is being continuously monitored against what is actually happening when the contract comes into force.
Contracts sit somewhere between these two systems, mainly in a repository, correctly filed, easily retrievable, and commercially invisible to both systems processing transactions in its name.
The consequence is what practitioners have started calling post-signature leakage, the gap between the value that was negotiated and the value that was actually realised. Industry research consistently places this at 9 to 11 percent of total contract value annually. For an enterprise with $500 million in contracted supplier spend, that is $45 to $55 million per year, not lost through fraud, not lost through negligence, but lost through the structural absence of a system designed to enforce what was agreed.
The natural assumption, when this gap is surfaced, is that it should be solvable through better use of existing systems. Can the ERP not be configured to flag invoice deviations? Can the workflow tool not be extended to monitor contract terms post-signature?
The short answer is no. Not because these systems are poorly designed, but because they were designed for fundamentally different jobs. An ERP is built around transaction records. Its data model is structured around purchase orders, invoices, and payments, not around the commercial logic embedded in contract clauses. When a pricing formula says that the base rate should be multiplied by the CPI index at the time of invoice, adjusted for a volume discount at a threshold that resets quarterly, the ERP has no mechanism to evaluate that sentence. It processes the number it receives.
Workflow tools face different constraints. They are excellent at moving a contract from initiation to signature, capturing approvals, managing versions, and routing to the right stakeholders. The moment a contract is executed, it exits the workflow. Post-signature is not a phase the workflow was designed to manage, because post-signature commercial governance is a fundamentally different discipline. It requires reading what the contract says, connecting that to live transaction data, and acting continuously without human initiation.
So What Does the Third System Do?
The third system starts where the other two end, that is at the moment of signature, when a contract's commercial obligations become active. Its job is to convert unstructured contractual logic into structured, continuously monitored intelligence and to connect that intelligence to the financial and operational systems where obligations are either honoured or broken.
In practice, this means extracting the pricing formula from a contract and connecting it to a live commodity index so that every invoice can be validated against the correct formula-adjusted rate before payment is approved. It means tracking rebate thresholds against live ERP transaction volumes and surfacing entitlements when they are earned. It means monitoring SLA performance against what the contract specifies, not what someone remembers from the negotiation. It means mapping amendment chains to their prevailing language so that the rate being enforced always reflects the current agreement, not the original one.
None of this is possible with a static repository. A contract that has been digitised and made searchable has achieved phase one: it can be found. Phase two making it operable, connecting its logic to the systems that execute it requires a different architecture entirely.
I have seen this play out in practice with organisations managing large, complex supplier portfolios. One case that made the structural gap concrete: a $700 million logistics and warehousing category with 31 different payment term variants running simultaneously across the same supplier base. The ERP recorded every payment. The workflow approved every invoice. Nobody caught the inconsistency because no system was comparing contractual terms to actual transactions.
When the commercial terms were structured and compared against transaction data, the organisation discovered that standardising payment terms alone, without renegotiating a single price, unlocked over $3 million in working capital impact. The value was already negotiated. It was sitting in signed agreements. It just needed a system capable of reading those agreements and measuring whether they were being honoured.
That story is not exceptional. Variations of it play out across categories, geographies, and industries in enterprises that have excellent ERPs and mature workflow tools but no third system connecting contractual truth to financial reality.
The important point for leaders evaluating this problem is that the third system is not an add-on to either of the first two. It is not a module, a plugin, or a workflow extension. The job it does continuously reading contracts, understanding commercial logic, connecting to live data, and enforcing what was agreed requires a different data model, a different integration architecture, and a different AI capability than either the ERP or the workflow tool was built to provide.
This is not a criticism of those systems. They solved the problems they were designed for, and they solved them well. The third system solves a different problem, the one that exists between what enterprises agree to and what actually happens. And until it is in place, the first two systems will continue to do exactly what they were designed to do: record what was paid and confirm that the process ran. Without ever answering whether what was agreed was honoured.
