The obligations, price terms and dates buried in a signed contract are what someone is supposed to act on, and usually nobody does. Contract intelligence is the layer that extracts those terms from the PDFs, resolves each one to the right vendor and its spend, and watches the deadlines so a renewal or a price step stops surprising finance.
Most companies already have the contracts. They sit in a shared drive, in the CLM system, attached to emails, in three formats and four naming conventions. Nobody rereads them. The MSA signed two years ago has an annual price escalator tied to an index, a 90-day termination notice window, and a volume tier that quietly changed your effective rate last quarter. All of that is knowable. None of it is visible unless a person opens the file and reads to page eleven. The work is turning a static archive into something that answers questions and raises its hand before a deadline.
Extraction is only as good as the clause taxonomy
The first mistake teams make is treating this as a document-summarisation problem. Summaries are unaccountable. You cannot reconcile a paragraph of prose against a general ledger, and you cannot set an alert on a vibe. What you need is structured extraction against a defined schema, and the schema comes before the model.
We start by fixing a clause taxonomy: the specific clause types that carry money, risk or a date. For a procurement portfolio that is usually twenty to thirty types.
- Renewal and termination: auto-renewal flag, renewal term, notice period, notice method, effective and expiry dates.
- Pricing: base rate, currency, escalation mechanism and its cap, volume tiers, most-favoured-nation clauses, payment terms.
- Obligations: SLAs and their credits, minimum commitments, exclusivity, data-processing and audit rights.
- Liability and exit: caps, indemnities, assignment on change of control, governing law.
Each field has a type, a source span in the document, and a confidence score. The source span matters more than the value. When the system says the notice period is 90 days, it points to the sentence it read that from, so a person can confirm it in two seconds instead of reopening the contract. That span is the audit trail. Without it you have a number with no lineage, and no controller will sign off on that.
Extraction runs per document, but the taxonomy is what you grade against. We build an eval set of contracts read and annotated by hand, and we score every field type separately. A model that nails governing law and misses escalation caps is a bad model for a finance use case, because the caps are where the money is. Aggregate accuracy hides exactly the failures that cost you.
Entity resolution is where the portfolio becomes queryable
A single extracted contract is a curiosity. The portfolio only becomes useful once you can query it, and that means resolving every document to the entities finance already tracks.
The same vendor appears as “Acme Corp”, “Acme Corporation Ltd” and “ACME (EMEA)” across three contracts, and none of those strings match the name in the ERP vendor master. Entity resolution links the counterparty in the contract to the vendor record that carries the spend, the payment terms and the purchase orders. Until that link exists, you cannot answer the question that actually matters: what are we contractually committed to with this supplier, and what have we spent against it.
Contracts also form hierarchies. A master agreement governs statements of work and amendments that each override specific terms. An amendment signed last March may have changed the price and left everything else untouched, so the current effective term is the master text as modified by every amendment in sequence. The system has to reconstruct that lineage and compute the current state, not extract each document in isolation. Point-in-time correctness applies here the same way it does in a feature store: the price in force on the invoice date is what matters for a three-way match, not the price in the latest amendment.
Once resolution and hierarchy are in place, the portfolio answers real questions. Which contracts renew in the next 60 days. Which carry an uncapped escalation clause. Where total minimum commitment exceeds forecast usage. Which vendors have MFN clauses we might be breaching by giving someone else a better rate.
Monitoring turns extraction into something that pays for itself
Extraction is a one-time act per document. Monitoring is continuous, and it is where the layer earns its keep. Two mechanisms run on top of the extracted data.
The first is a renewal and obligation calendar. Every date-bearing clause becomes an entry with a lead time derived from its notice period. A contract with a 90-day termination window surfaces at day 120, giving procurement room to decide and renegotiate rather than discovering the auto-renewal after it fired. Obligations with recurring deadlines, like quarterly reporting or an annual audit right, generate their own recurring alerts.
The second is drift detection against reality. The contract says the escalation is capped at 4%. The invoice this quarter reflects 6%. That gap is a monitoring alert, produced by the same reconciliation logic that sits under invoice matching, pointed at the contract terms as the source of truth. When the extracted price schedule and the actual charges diverge, someone hears about it inside the quarter instead of at the annual true-up.
Both mechanisms live or die on the false-positive budget. An alerting system that cries wolf gets muted in a week, and a muted alert is worse than none because it creates the illusion of coverage. We tune thresholds and confidence gates so the calendar surfaces what is genuinely actionable, and we route low-confidence extractions to a person before they ever become an alert. Judge the system by outcomes, not clause counts: how many renewals were handled on time, and how many price errors were caught before they were paid.
FAQ
Do we need a clause taxonomy before starting extraction?
Yes. The taxonomy is the schema the whole system is graded against, so define the twenty or thirty clause types that carry money or obligation first, then extract to that. Extracting free-form and organising later produces fields nobody can reconcile.
How accurate does clause extraction need to be to trust the renewal calendar?
The renewal date and notice-period fields need to be near-exact because a missed notice window auto-renews a contract you meant to exit. Track those two fields separately from the rest and hold them to a tighter accuracy bar, with human confirmation on anything the model flags as low-confidence.
Can one model handle both procurement contracts and customer agreements?
The extraction backbone is shared, but the clause taxonomy and the downstream actions differ enough that we treat them as separate eval sets. A price-escalation clause means something different when you are the buyer than when you are the seller.