You Signed the Contract. Your POs Don't Know It.

Start with the concession, because it is real and anyone who has run a contract function can smell a strawman instantly. Before contract lifecycle management, the "contract" was a PDF in someone's inbox and a paper original in a cabinet three floors down. Terms lived in people's heads and expired without anyone noticing. The CLM layer fixed a genuine, expensive mess.

A modern repository centralizes every executed agreement in one governed store, versions the redlines, and pulls a clause library into authoring so the third draft looks like the two hundredth. It extracts obligations, effective dates, renewal windows, and price schedules into structured metadata. It fires renewal alerts before auto-renew clauses quietly re-up a bad deal. It gives legal, procurement, and finance one place to answer "what did we actually agree to." That is a large maturity gain over the cabinet-and-inbox era, and the newer AI-assisted tooling makes it faster still — reading a stack of agreements and surfacing the off-market clause, drafting the fallback language, summarizing the obligation set. None of that is marketing air. Authoring and centralizing contracts is a solved-enough problem, and the suites solved it.

Read the category's own verbs, though, and the ceiling comes into focus. The repository stores, extracts, surfaces, reminds, alerts, and — in its AI form — reads, flags, and recommends. Every one of those is an operation on a record. Not one of them is the operation that spends money. When a requisition becomes a PO, when a PO is receipted, when an invoice is matched and posted for payment — the authoritative action happens in the transaction system, and the contract is a document sitting beside that system, not a control living inside it.

That gap is architectural, not a configuration someone forgot to switch on. The enforcement point — the moment the PO commits at a price — is in a system the repository does not own. So the term can only be honored by a handoff: metadata syncs into a catalog on a schedule, an obligation reminder emails a category manager, a buyer is trusted to cross-reference the clause before they click submit. Each of those is a person or a batch job standing in for the term. Best-effort by design. The contract was negotiated as a binding control and then filed as a passive reference.

• "Stores the price schedule" — a stored price does not price the PO; the catalog does, and catalogs drift.
• "Alerts on renewal" — an alert fires at a human, who may or may not act before the term lapses and orders keep flowing against an expired agreement.
• "Extracts the volume tier" — extracted into a field, not into the logic that decides whether this order earns the tier or blows past the cap.
• "Flags the off-contract clause" — a flag is a message about an action, raised at best when the action is proposed and often only after it posted.

Faster authoring and cleaner metadata are worth having. But a term you can find quickly is still a term that has to be manually applied at the one moment it matters — the executing action.

The leakage is not exotic; it is the ordinary weather of a large procurement estate. Price creep: the negotiated rate is in the repository, but the requisition prices off a catalog or a stale rate card, and the delta rides quietly on every line. Off-contract and maverick buying: a preferred supplier and a hard-won rate exist, and the buyer routes to a familiar vendor anyway because nothing at the point of order forces the contracted one. Missed volume tiers and rebates: you committed to a tier to earn a discount and never call it because no system is counting cumulative spend against the threshold as orders execute. Expired-term ordering: the agreement lapsed, the renewal alert scrolled past, and POs keep flowing against terms that no longer exist. Clause violations: a segregation or exclusivity clause is written, signed, and then invisible to the person raising the order it prohibits.

Where does the enterprise learn about all of this? Downstream, in the spend-analytics layer — the same architecture, one system further along. Analytics reads the transactions after they posted and reports the category's familiar metrics: off-contract spend, contract-leakage, realized-versus-negotiated savings. That reporting is genuinely useful for renegotiation and for finding the next tranche of savings. But notice what it concedes about tense. You are measuring value that already leaked. The dashboard is a detective control looking back at a window it can shrink but, by construction, can never close — because the decision to spend was made in a system where the term was not a gate.

Here is the architectural move, and it is a move about where the term lives, not about a smarter reminder. In a composable process fabric, procurement is not a stack of intake forms plus approval routing plus a repository plus analytics bolted together beside the ERP. It is a single governed workflow that actually runs the process — intake to sourcing to PR to PO to receipt to invoice to pay — as a composition of five primitives on a shared semantic ontology, in one runtime, with an immutable per-action audit.

The contract is modelled on that ontology. Its price schedule, committed volume tier, effective and expiry dates, and its segregation and exclusivity clauses are not extracted into passive metadata — they are live operands in the deterministic workflow that executes the procure and pay steps. The classic three-way match extends into a contract match, enforced inline as a gate. A PO priced above the negotiated rate, routed to a supplier the exclusivity clause forbids, raised past the committed cap, or cut against a lapsed term does not get flagged for someone to chase later — it cannot execute. Where the check requires judgment rather than a rule — a genuine exception, a first-of-its-kind deviation — a human sits in the loop as a first-class step and approves or refuses before anything commits, with that decision recorded. Only a compliant action reaches the one primitive allowed to touch an external system: a governed connector posts the authoritative PO or invoice to the ERP or ledger. The audit record is a byproduct of the action having run, not a reconstruction assembled afterward.

State this as what it is — an architectural property of where enforcement sits, not a claimed outcome. Because the term is an operand in the executing step rather than a document beside it, the control is applied at the moment of action instead of surfaced after it. That is the whole difference between a contract that reminds you and a contract that governs you.

Two honest boundaries, because over-claiming is the fastest way to lose a reader who does this for a living. First, this is not zero-integration. The fabric runs over the estate you already own; connectors are how it posts to the ERP and reconciles with the systems of record. The claim is not that the estate disappears — it is that enforcement stops being distributed across systems that each own a fragment and can only report to one another.

Second, the closest thing in the market is not the repository at all — it is the orchestration layer that gives you a single front door for intake and coordinates routing across the ERP and the source-to-pay suites. That is real and valuable: one place to ask, fewer maverick requests, cleaner hand-offs. But orchestrating and reporting across systems the layer does not own is a different thing from the transaction executing on one governed fabric where the term is checked at the instant of the action. A front door that routes a request to a system where the contract is still a passive document has moved the request, not the enforcement. The gate has to be where the money commits. In the record-and-route pattern, it structurally is not — and that stays true regardless of how good the reminders, the catalogs, or the AI get, because the limit is the location of the control, not the intelligence of the alert.