Your largest account is invoking the service credit clause. The 99.9% uptime commitment was in Section 8.2, signed nineteen months ago. Engineering had been running against 99.5%.
The customer success team escalates on a Wednesday. Your largest enterprise account is threatening to invoke the service credit provision, and they have receipts: eleven months of uptime reports showing you missed the 99.9% threshold in four separate months. Nobody on your side knew the threshold was 99.9%. Engineering had been running against an internal target of 99.5%.
The commitment was in Section 8.2 of a contract signed nineteen months ago by someone who has since left. It was never communicated to anyone who could act on it. The contract was findable. The obligation inside it was not.
This is the gap between having a contract repository and actually managing your contracts. Storage answers "what did we sign." Obligation tracking answers "what do we owe, who owes it, and when."
A contract obligation is any commitment either party takes on that requires someone to do something, refrain from doing something, or maintain a condition over time.
The definition sounds broad because it is. A single mid-sized commercial agreement typically contains somewhere between fifteen and sixty distinct obligations, most of which nobody has ever enumerated. They hide in plain sight, phrased in the passive constructions that legal drafting favors, distributed across clauses that were negotiated by different people for different reasons.
Some obligations are obvious and get tracked by default because a system already handles them. Payment terms flow into accounts payable. Delivery dates land in a project plan. These are fine.
The dangerous ones are the obligations that do not map cleanly onto an existing operational system. Nobody owns them, so nobody tracks them, so they are managed by whoever happens to remember, which works right up until that person leaves or gets busy.
It is rarely negligence. The structural reasons are consistent across organizations.
The person who negotiated the obligation is not the person who has to perform it. Legal negotiates the SLA. Engineering has to hit it. If nothing systematically bridges that handoff, the commitment stays in the document and never reaches the team that would need to change behavior.
Obligations are written as prose, not as tasks. "Supplier shall provide quarterly reporting on service levels in a form reasonably acceptable to Customer" is a recurring deliverable with a deadline, an owner, and an acceptance criterion. It is written as a sentence. Extracting the task from the sentence requires deliberate effort that nothing prompts.
The trigger is often an event rather than a date. "Notify within 30 days of any change of control" has no calendar date. It sits dormant until something happens, and by then nobody remembers the clause exists.
Amendments change obligations without changing where they live. The original SLA said 99.5%. Amendment 2 raised it to 99.9%. If the amendment is stored separately from the master, anyone consulting the master gets a confidently wrong answer.
Nothing fails loudly. A missed obligation usually produces no immediate signal at all. You discover it when the counterparty raises it, which is by definition the worst moment and the weakest negotiating position.
Sorting obligations by type is useful because each type needs a different tracking mechanism, and treating them uniformly is why most attempts fail.
Deadline obligations have a fixed date or a date computable from a known event. Renewal notice windows, reporting deadlines, insurance certificate renewals, audit rights exercisable within a stated period. These are the easiest to manage and the most expensive to miss, because the deadline passes silently and the right is gone. A calendar with owners handles these.
Performance obligations require sustained delivery against a standard. Uptime commitments, response time SLAs, support coverage hours, quality thresholds. These need continuous measurement, which means the contractual number has to be wired into whatever system already monitors performance. This is the type most likely to be missed, because the commitment lives in legal and the measurement lives in engineering or operations.
Conditional obligations trigger on an event that may never occur. Breach notification, change-of-control notice, data incident reporting, insurance claim procedures, most-favored-nation adjustments. These cannot be calendared. They have to be embedded in the process that handles the triggering event, which means the security incident runbook needs to know which contracts require notification and within what window.
Restrictive obligations constrain what you may do. Exclusivity, non-solicitation, confidentiality scope, assignment restrictions, territorial limits, non-compete provisions. These are violated by ordinary business activity conducted by people who have never read the contract. The only workable control is surfacing them at the decision point: when someone proposes hiring from a partner or entering a territory, the restriction has to appear then, not in a quarterly review.
Extraction is the unglamorous foundation. Do it badly and everything downstream is built on sand.
Read for verbs, not for clauses. Scan for shall, will, must, agrees to, is required to, shall not, may not. Modal verbs are where obligations live. This mechanical pass catches the large majority of them and takes far less time than reading for comprehension.
Capture both directions. Your obligations and theirs. Their obligations are your rights, and unexercised rights are money left on the table. Audit rights, benchmarking rights, and service credits are routinely never claimed because nobody knew they existed.
Record five fields per obligation. What is required, who owes it, when or on what trigger, what evidence proves performance, and what happens on failure. If you cannot fill the last two, you have not finished reading the clause.
Note the source location. Section number and document, including which amendment if the obligation was modified. When someone challenges an obligation in eighteen months, you need to point at the text, not at your register.
Flag anything ambiguous rather than resolving it silently. "Reasonably acceptable," "promptly," "material" and "commercially reasonable efforts" are unresolved standards. Record them as ambiguous with a note, because guessing at the interpretation and recording your guess as fact is how registers become misleading.
Do not extract every obligation from every contract. This is where obligation tracking projects die. Start with your highest-value and highest-risk agreements, plus every contract with a deadline obligation regardless of value. Comprehensive extraction across a whole portfolio is a multi-quarter effort that delivers nothing until it is finished, which means it usually is not.
The register is where extracted obligations become manageable. Minimum viable structure:
Obligation ID and description in plain language, not a quote from the contract. "Deliver quarterly service level report to Customer by the 15th of the month following quarter end" rather than the original clause text. If the register requires legal interpretation to read, the operational owners will not use it.
Source: contract, section, and amendment.
Direction: ours or theirs.
Type: deadline, performance, conditional, or restrictive.
Owner: a named role in the function that can actually perform it. Not legal, unless legal performs it. An obligation owned by legal that engineering must fulfil is an unowned obligation with paperwork.
Trigger: date, recurrence, or event.
Evidence: what artifact demonstrates performance and where it is stored. This is the field people skip and the field that matters in a dispute.
Status and last verified date.
Consequence of failure: service credit, termination right, indemnity trigger, or reputational only. This drives prioritization honestly, and it prevents a register where every item looks equally urgent.
Ownership is the single point where obligation tracking most often fails, and the failure is always the same shape: the obligation is assigned to someone who cannot act on it.
Three rules.
Assign to the function that performs, not the function that negotiated. Legal owns knowing the obligation exists. Engineering owns hitting the uptime number. Finance owns the payment schedule. Legal cannot own outcomes it does not control.
Assign to roles, never individuals. The register outlives the people in it. "Head of Platform Engineering" survives turnover. A name does not.
Confirm acceptance explicitly. An obligation assigned without the owner acknowledging it is not assigned. This sounds bureaucratic and it is the difference between a register that reflects reality and one that reflects intentions. A five-minute conversation at handoff prevents the "nobody told me the number was 99.9%" conversation later.
Lead time should match the work required, not a uniform default. A renewal notice you can send in an afternoon needs a two week warning. An obligation requiring a board decision needs a quarter. Setting every alert to 30 days means the ones needing more time fail and the ones needing less generate noise.
Escalate on silence. If an owner does not confirm action by a set point, the alert goes to their manager. Without escalation, alerts get dismissed and the system degrades to decoration within a few months.
Review performance obligations on the measurement cycle, not the contract cycle. If the SLA is measured monthly, review monthly. Discovering in a quarterly review that you missed three months is discovering it late.
Re-extract on amendment. Every amendment triggers a re-read of the affected clauses and an update to the register. This is the discipline that keeps the register from silently diverging from the contracts, and it is the one most often skipped because amendments feel minor.
Reconcile against reality quarterly. Pick a sample of obligations, ask the owner for the evidence artifact, and see whether it exists. A register nobody audits is a register nobody can rely on in a dispute.
Be honest about where you are. A spreadsheet is a legitimate starting point and a bad ending point.
Spreadsheets work when you have a small number of contracts, a stable portfolio, and one person who cares. They fail on three things predictably: they do not alert, so someone has to remember to look; they have no link back to the source text, so verification means re-reading contracts; and they go stale silently, because nothing forces an update when an amendment lands.
CLM platforms including Ironclad, Juro, LinkSquares, and Conga all offer obligation management in some form, generally as extraction into a structured register plus alerting and reporting. This is the mainstream answer if you have volume and budget, and the honest caveat is that extraction quality varies with contract complexity and unusual drafting, so plan for human review rather than assuming the extraction is authoritative. Our overview of what CLM covers puts obligation management in context with the rest of the lifecycle.
Structured document platforms including HERO approach it from the other end. Rather than extracting obligations from a static file after the fact, the obligation is a structural element of the document itself, which means it does not need to be re-extracted when an amendment changes it. This matters most when contracts are complex, heavily cross-referenced, and frequently amended, which is exactly the population where post-hoc extraction is least reliable. You can see how the structural model works on the features page.
Whichever route, the question to press vendors on is not extraction accuracy on a clean sample. It is what happens when Amendment 3 changes an obligation that Amendment 1 already changed, and whether the register reflects that automatically or requires someone to notice.
Worth reading alongside this: what makes a contract executory, since ongoing performance obligations are what put a contract in that category and what makes it matter in insolvency and assignment scenarios.
Contract management covers the full lifecycle of the agreement as a document: drafting, negotiation, execution, storage, and renewal. Obligation tracking is specifically about the commitments inside the agreement and whether they are being performed. You can have excellent contract management, meaning every agreement is findable and current, while having no idea whether you are meeting the service levels you promised. The two are related but distinct, and organizations routinely solve the first and assume it addressed the second.
It varies enormously with complexity, but a mid-sized commercial agreement commonly contains somewhere in the range of fifteen to sixty distinct obligations across both parties once you count conditional and restrictive ones. Most organizations, when they first run a structured extraction, are surprised by the count. The number is less important than the distribution: the majority are low consequence, and a small number carry termination rights, service credits, or indemnity triggers. Prioritizing by consequence rather than trying to manage all of them equally is what makes the exercise sustainable.
The function that can actually perform the obligation. Uptime commitments belong to engineering, payment terms to finance, reporting deliverables to whoever produces the report. Legal owns the register itself, meaning knowing what obligations exist and ensuring they are assigned, but legal should not own performance of obligations it does not control. Assigning everything to legal is the most common structural mistake and it guarantees the obligations are not managed, because legal has no lever to pull.
Partially, and the reliability depends heavily on how conventionally the contract is drafted. Modal verb detection and clause classification work reasonably well on standard commercial paper. They degrade on unusual drafting, heavily negotiated bespoke language, and obligations expressed across multiple cross-referenced clauses, which is precisely where the high-value obligations tend to live. Treat automated extraction as a first pass that produces a candidate list for human review, not as an authoritative register. The cost of a missed obligation is asymmetric enough to justify the review.
It depends entirely on the clause. Consequences range from nothing enforceable, through service credits and cure periods, to termination rights and indemnity triggers. This is exactly why the consequence field belongs in your register: it lets you prioritize honestly rather than treating every obligation as equally urgent. Many missed obligations are practically recoverable if caught early, particularly where a cure period applies, which is another argument for alerting well ahead of the deadline rather than at it. This is general information rather than legal advice, and specific consequences should be assessed against your actual contract terms.
You cannot calendar them, so embed them in the process that handles the triggering event. Breach notification obligations belong in the security incident runbook, listing which contracts require notice and within what window. Change-of-control notice belongs in the corporate development checklist. The register records that the obligation exists and where it is embedded, but the actual control lives in the operational process. Conditional obligations that exist only in a register and nowhere else are effectively untracked, because nobody consults a register during an incident.
Yes, and most organizations under-invest here. The counterparty's obligations are your rights, and rights that are never exercised have no value. Audit rights, benchmarking provisions, service credits, and performance reporting requirements are commonly negotiated hard and then never used, because nobody tracked that they existed. Tracking both directions also strengthens your position when a counterparty raises one of your misses, since it lets you have an informed conversation rather than a one-sided one.
HERO is a document editor for structured business documents, which means obligations, defined terms, and cross-references are real structural objects inside the contract rather than prose that has to be extracted and then kept in sync by hand. When an amendment changes a commitment, the change propagates instead of quietly diverging from your register. If you are staring at a spreadsheet you no longer trust, that is the problem we built for. Book a demo.