---
title: "What is obligation extraction, and where should the obligations live?"
canonical_url: "https://cognilium.ai/blogs/what-is-obligation-extraction"
slug: "what-is-obligation-extraction"
section: "blogs"
date_published: "2026-09-11"
date_modified: "2026-09-11"
word_count: 1297
reading_time_minutes: 6
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related:
  - "https://cognilium.ai/blogs/pre-signature-or-post-signature-contract-ai"
  - "https://cognilium.ai/blogs/how-negotiated-terms-reach-a-purchase-agreement"
  - "https://cognilium.ai/blogs/where-should-contracts-live-contract-repository"
---
# What is obligation extraction, and where should the obligations live?

Pulling the promises out of a signed contract and turning each into something a system can check. Extraction is the easy half; where they live is the hard half.

## Key takeaways

- Obligation extraction produces records, not clauses — who owes what, by when, on what trigger, with a link back to the sentence.
- An obligation is only usable if its trigger exists in a system. "Promptly upon request" extracts cleanly and checks never.
- The honest output is two lists — obligations a system can watch, and obligations a person must. Returning only the first hides the second.
- In procurement the transactional obligations already have a home: the purchase agreement, which Microsoft defines as a commitment tracked across multiple orders.
- Extraction is not the hard part. Choosing the home, keeping provenance, and re-extracting after amendments are.
- An obligation in an ERP is live, enforced and fragile — an ordinary price edit can break the link that enforces it.

**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](/blogs/pre-signature-or-post-signature-contract-ai) 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](/blogs/how-negotiated-terms-reach-a-purchase-agreement).

**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](/solutions/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](https://learn.microsoft.com/en-us/dynamics365/supply-chain/procurement/purchase-agreements)

## Fact-check

**Tier summary:** 5 × T1 (all verbatim), 4 × T2 — **0 × T4.**

**No figures of ours.** Claim 3 could carry a percentage and deliberately does not — we have no measured study, and an invented share would be a `PUBLISHING-CONTRACT.md` §1 violation.

**Disclosure:** no client, no count, no measured outcome.

## Frequently asked questions

### What is actually being extracted?

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

### What makes an obligation actually usable?

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

### Where should an extracted obligation live?

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."

### What goes wrong with obligation extraction?

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.

---

Canonical HTML: https://cognilium.ai/blogs/what-is-obligation-extraction