Legal Teams// definition

The obligation register: 5 attributes an entry cannot work without

In short

An obligation register is a list of commitments a business has to perform or enforce, and a line on it is only workable if it carries 5 attributes: who owes it, what triggers it, whether the deadline is absolute or relative to an event, who inside the business owns delivery, and what counts as evidence it was done. Missing any one turns the entry back into a clause summary.

Key takeaways

  • A register holds commitments to perform, not summaries of clauses; the difference is whether a line can be worked.
  • 5 attributes make an entry actionable: obligor, trigger, deadline basis, internal owner, evidence of performance.
  • Deadlines are absolute, relative to an event, or recurring, and the 3 need different fields and different alerts.
  • Conditional obligations fail silently because nothing in the estate records the trigger that should start them.

An obligation register is the list of commitments a business has to perform or enforce under its contracts. It is not a list of clauses, and the distinction is practical: a clause summary says what the agreement says, while an obligation entry tells a named person what to do, by when, and what proves they did it.

5 attributes carry that difference. An entry missing any of them is a sentence someone will have to re-read the contract to act on, which is the exact work the register was built to remove.

The 5 attributes, and what fails without each

AttributeThe question it settlesWhat fails without it
ObligorWhich party owes this, us or themOur duties and our rights sit in one list, so neither gets worked
TriggerWhat starts it: a date, an event, or a conditionThe entry exists but nothing ever fires it, and it is discovered at breach
Deadline basisAbsolute date, offset from an event, or a recurring intervalA stored date silently detaches from the event it came from
Internal ownerWhich named role performs or enforces itLegal holds a list nobody outside legal has agreed to act on
Evidence of performanceWhat closes it, and where the artefact is filedClosure records an intention, and cannot be shown to an auditor
The attribute set that makes an obligation workable

Obligor looks trivial and is not, because the counterparty on the page and the legal entity in your systems are often different records — the resolution problem in one counterparty appearing under 9 names. A duty owed by a subsidiary since sold is a different exposure from one owed by the group.

One-off, recurring and conditional are 3 different records

  • One-off. A single act with a single deadline: deliver the implementation plan within 30 days of commencement. The deadline is an offset, so the register keeps the anchor date as well as the result — why effective, execution and commencement dates cannot be one field.
  • Recurring. A repeating act on an interval: a quarterly service report, an annual insurance certificate. The entry needs a schedule and a horizon, and each occurrence its own closure and evidence — a single closed flag on the parent hides 3 missed quarters.
  • Conditional. An act owed only if something happens: notify within 5 business days of a security incident, seek consent before subcontracting. There is no date until the condition occurs, which is why this shape fails differently from the other 2.

Conditional obligations fail because nothing records the trigger

A missed one-off obligation shows up as an overdue line. A missed conditional obligation shows up as nothing at all, because the register is waiting for an event no system told it about. The failure is not in the tracking; the trigger has no observer.

  1. Name the system that would know. For each conditional obligation, write down which system of record — the incident tool, the procurement system, the payroll ledger — would first learn the condition occurred.
  2. Wire the observable ones. Where a system knows, take the event from it rather than asking a person to remember that a contractual duty attaches.
  3. Attest the rest on a cadence. Where nothing knows, turn the condition into a periodic question to the owner: has this happened since we last asked. Weaker than an event feed, far stronger than silence.
  4. Review the never-fired. A conditional obligation that has not fired since creation is either dormant or unwired, and only a person can tell which. Put that list to the owner quarterly.

What closing an entry actually requires

Closure needs a state and an artefact. The states worth distinguishing are performed, waived, superseded by amendment, and expired with the agreement — because 3 of those 4 mean the duty ended without anyone doing anything. The artefact is whatever you would produce if the counterparty said it never arrived: the report, the certificate, the sent notice.

Two upstream facts shape the entries before the register sees them. Obligations arrive from a family of documents rather than one file, so an entry has to know which instrument in the parent, the child and the amendment it belongs to. And the obligation you end up with is whichever rung was accepted, which is why fallback ladders inside a negotiation playbook map onto the register's future contents.

A register that cannot say who owes it, what starts it, who does it and what proves it was done is an index of the contract, not a record of the business.

The build implication is small and unglamorous: model the 5 attributes as required fields, model recurrence as occurrences rather than a flag, and refuse to let an entry close without an artefact reference. That is ordinary MVP and product build work. This page sits in contract lifecycle and obligations, part of legal technology software.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

What is an obligation register in contract management?

It is the list of commitments a business must perform or enforce under its contracts, held as workable entries rather than clause summaries. Each line names the party that owes the duty, what triggers it, how its deadline is derived, which internal role delivers it, and what artefact closes it. Anything less sends the reader back to the contract.

What is the difference between a recurring and a conditional obligation?

A recurring obligation has a schedule and comes due whether or not anything happens; a conditional one has no date until a triggering event occurs. They fail differently: a missed recurring obligation appears as an overdue occurrence, a missed conditional one appears as nothing, because no system told the register the condition had happened.

Why does an obligation need an owner inside the business?

Because legal negotiates the commitment and rarely performs it. Delivery sits with the team that runs the service, holds the insurance or files the report, and an entry without a named internal role is a list legal maintains and nobody has agreed to act on. Name a role rather than a person, so the entry survives the individual leaving.

What counts as evidence that an obligation was performed?

Whatever you would produce if the counterparty said it never happened: the delivered report, the insurance certificate, the acknowledgement of a notice, the signed acceptance. A closure flag without the artefact records an intention. Distinguish performed from waived, superseded and expired too, since 3 of those 4 mean nobody did anything.

  • obligation register
  • contract management
  • data model
  • compliance
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation