TL;DR
Two different products sold under one name. Pre-signature reads a draft against your rules; post-signature watches what you agreed. Most teams buy the first.
They are two different products sold under one name. Pre-signature reads a draft against your rules before you sign. Post-signature watches what you already agreed and tells you when reality drifts from it.
Most teams buy the first and discover they needed the second.
What is the split, exactly?
It is a split by when the money is at risk, and the two halves share almost no machinery.
| Pre-signature | Post-signature | |
|---|---|---|
| The question | "Should we agree to this?" | "Are we doing what we agreed?" |
| The input | a draft, and your playbook | a signed set of obligations, and live transactions |
| Runs | once per contract | continuously, for the life of the agreement |
| Fails by | approving a bad clause | never noticing a breach |
| Sold as | contract review · redlining · playbook review | obligation management · contract intelligence · CLM |
The vocabulary is the trap. Vendors on both sides call it contract intelligence, so a buyer comparing two products may be comparing a reader and a monitor as though they were rivals.
Ask which question the product answers. That single question sorts the market in a minute.
What does pre-signature actually do?
Reads a draft against your rules and reports the gaps. That is playbook-driven contract review — the clause is measured against your standard position, your fallback and your red line, and a reviewer decides.
Its value is concentrated in one moment and it is genuinely high: the cheapest time to fix a term is before anyone signs it. Its limitation is the same fact. Once signed, it has nothing left to say. The document is filed and the system's job is finished.
This is what almost every "AI contract review" product is, and it is what we ship — Paralegent AI is a pre-signature reader, in production today, and one of Cognilium's AI optimization apps for Microsoft Dynamics 365. We build these on request against a customer's own playbook.
And it is not the half most procurement teams are actually losing money on.
What does post-signature do that pre-signature cannot?
Watch the record. And in procurement, the record is the ERP — which is where the interesting failures live.
Microsoft's purchase agreement is a live commitment, not a filed document. It carries the operative terms, and Microsoft is explicit that they reach the transaction:
"Information from the terms for the agreement, such as the payment terms, delivery terms, and delivery address, is then copied to the header of the PO… the prices and discounts from the purchase agreement are used for those lines."
So the agreement is doing work every time somebody buys something. And it can stop doing that work silently:
"If the price is changed on the order line, the link to the commitment is broken. If the link is broken, the order line doesn't contribute to the fulfillment of the commitment."
No error. No alert. The volume you promised in exchange for the discount simply stops accumulating.
That is a post-signature failure and no pre-signature review can see it. The contract was read correctly. Months later, an ordinary price edit detached it.
So which do you need?
Answer one question: what has actually cost us money in the last two years?
- A term we should never have agreed to → pre-signature. The review is the fix.
- A term we agreed and then did not get → post-signature. Reading the draft again changes nothing.
- We do not know → post-signature, and start by reading your own agreements. Not knowing is itself the post-signature answer.
The honest pattern we see: teams buy pre-signature because it demonstrates well — you can watch it find a bad clause in a meeting — and their real leakage is a renewal nobody tracked, a rebate nobody claimed, or a discount tier nobody accumulated toward.
Neither half is the wrong purchase. Buying the wrong one first is the expensive part.
Can one system do both?
Parts of it, and the parts that do not transfer are the parts that matter.
The reading machinery is genuinely shared. Clause identification, playbook matching and risk scoring work the same whether the document is a draft or an executed agreement. A pre-signature reader pointed at a signed contract will extract obligations perfectly well.
What does not transfer is everything after extraction:
- Post-signature needs to run forever, on a schedule, against changing transactions. Pre-signature runs once and stops. That is a different operational shape, not a bigger version of the same one.
- Post-signature needs write access to nothing and read access to everything — orders, invoices, receipts, price changes. Pre-signature needs a document and a playbook.
- Post-signature alerts a person about something already true. Pre-signature advises a person about something not yet agreed. One is monitoring; the other is review.
So the honest answer: extraction is shared, monitoring is a second build. A vendor claiming one product covers both is usually selling the reader and calling the extracted obligations a monitor.
Why does the ERP decide which half matters?
Because it holds the obligations that have money attached, and it enforces them on rules a legal team never sees.
Microsoft's own agreement policies are the clearest illustration. Max is enforced caps the total against the commitment. The price and discount is fixed policy breaks the link on an edit. And an agreement can be attached only at order creation — "You can't select a purchase agreement after the PO has been created."
Those are contract terms living as configuration. They govern quietly, they are changed by people who have never read the contract, and they are invisible to any product that treats a contract as a document.
Post-signature contract intelligence in an ERP means watching the record, not re-reading the file — and it is the half almost nobody publishes about.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.
Not sure which half you need? Bring two years of contract problems to a 15-minute call and we will sort them into pre- and post-signature with you. The answer is often not what people expect.
Sources
Sources and fact-check
| # | § | Claim | Tier | Source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The pre/post split, and that both are marketed as contract intelligence | T2 — ours, a market reading | _research/2026-09-09/01-RESEARCH-A… §2, nine SERPs read | PASS |
| 2 | 2 | Pre-signature reads a draft against playbook rules and stops at signature | T2 — ours + capability | Paralegant_TECHNICAL_PROFILE.md §1 | PASS |
| 3 | 2 | Paralegent AI is a pre-signature reader, in production | T2 — capability. Founder-locked canon for status | /dynamics-365/optimizers; 04-positioning-now.md | PASS |
| 4 | 3 | The copied-terms passage, quoted whole | T1 — verbatim | purchase-agreements (ms.date 2026-09-08), fetched 2026-09-10 | PASS — load-bearing |
| 5 | 3 | The broken-commitment-link passage, quoted whole | T1 — verbatim | Same page, Policies for purchase agreements | PASS — load-bearing |
| 6 | 3 | No error is raised | T2 — ours, bounded: Microsoft documents the link breaking and documents no error. Stated as behaviour | Same policy | PASS |
| 7 | 4 | Buy against loss history; the pattern we see | T2 — ours, deliberately unquantified. No client, no count | Internal definition | PASS |
| 7b | 4a | Extraction machinery transfers between the halves; monitoring does not | T2 — ours, an architectural argument | Internal definition; profile §1 | PASS |
| 8 | 5 | Max is enforced; price-and-discount-fixed; attachment only at PO creation | T1 — verbatim ×3 | Same page | PASS — load-bearing |
| 9 | 5 | Contract terms live as configuration, changed by people who never read the contract | T2 — ours, an argument | Internal definition | PASS |
Tier summary: 5 × T1 (all verbatim), 5 × T2 — 0 × T4.
Absence claims: one, row 6, bounded to the fetched page and phrased as observed behaviour rather than as a claim about Microsoft's complete documentation.
Disclosure: no client, no count, no measured outcome. "In production today" is founder-locked canon.
