What is obligation extraction, and where should the obligations live?

Obligation extraction is pulling the promises out of a signed contract and turning each one into something a system can check. Not clauses — commitments. Who owes what, to whom, by when, and on what condition.

Extraction is the easy half. The hard half is deciding where each obligation lives once you have it, and almost nobody writes about that.

What is actually being extracted?

Not text. A structured statement of something someone has to do.

A clause says: "Supplier shall deliver within thirty (30) days of Purchase Order acceptance." The obligation is different — it is a record with fields:

The difference matters because only the second form is checkable. You cannot ask a database whether a sentence was honoured. You can ask whether a delivery happened within thirty days of an acceptance date.

This is where contract intelligence stops being about reading and starts being about data.

What makes an obligation actually usable?

Four things, and most extracted obligations are missing at least one:

• A trigger that exists in a system. "Within 30 days of PO acceptance" is checkable because acceptance is a dated event in the ERP. "Promptly upon request" is not checkable by anything.
• An owner. An obligation nobody holds is a note, not a commitment.
• A measurable condition. "Commercially reasonable efforts" extracts cleanly and checks never.
• A link back to the clause. When someone disputes it in two years, the obligation has to point at the sentence it came from.

The uncomfortable finding of any extraction exercise: a large share of what a contract obligates is not mechanically checkable at all — and that is a property of how contracts are written, not a defect in the extraction.

So the useful output is two lists, not one: the obligations a system can watch, and the obligations a person has to. A product that returns only the first and calls it complete is hiding the second.

Where should an extracted obligation live?

Three candidate homes, and they are not interchangeable:

In procurement, the ERP home is the one with money attached. Microsoft's purchase agreement already is an obligation record — Microsoft describes it as "a contract that commits an organization to buy a specified quantity or amount by using multiple purchase orders over time."

That is an extracted obligation with enforcement built in. The commitment is stated, the fulfilment is tracked, and Microsoft documents four commitment types — quantity, product value, category value and plain value — which is exactly the structure an extraction exercise is trying to produce.

So for the transactional obligations, the ERP is not a place to copy them to. It is where they already belong.

What goes wrong with obligation extraction?

Four failures, and none of them is bad extraction:

• Extracting into a place nobody looks. The most common outcome. A perfect obligation register in a CLM nobody opens changes no behaviour.
• Extracting what cannot be checked and listing it as monitored. "Reasonable efforts" in a monitored list is worse than absent, because it implies coverage that does not exist.
• Losing the provenance. An obligation without a pointer to its clause cannot survive a dispute.
• Extracting once. Contracts get amended. An obligation set built at signature and never revisited describes a contract that no longer exists.

The fourth is the one that quietly invalidates the whole exercise, and it is why obligation work is post-signature and continuous rather than a project that finishes.

What does this look like inside Dynamics 365?

The transactional obligations become agreement configuration — and then they behave like configuration, which is the part legal teams do not expect.

The commitment is enforced by policy. Max is enforced means "the total quantity or amount for all order lines can't exceed the quantity or amount that is specified on the related commitment." Fulfilment is tracked: the agreement shows "the remaining amount or quantity that is required to fulfill the commitment."

And the enforcement can be switched off by an ordinary edit. Under the price-and-discount-fixed policy, "If the price is changed on the order line, the link to the commitment is broken."

So an obligation in an ERP is live, enforced and fragile. Extracting it is a start; watching that it stays attached is the actual work — and that is where negotiated terms are lost.

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.

Bring one signed supplier agreement to a 15-minute call and we will extract its obligations with you, then sort them into the ones a system can watch and the ones a person must.

Sources

• Purchase agreements — Dynamics 365 Supply Chain Management