> **Source:** https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview
> **Site:** Leegality Knowledge Base — https://knowledge.leegality.com
> **About:** Leegality is a document execution platform covering eSigning, stamps, NeSL, workflows, and REST API integration.
> **Navigation:** Every article on this site has a plain-text version at `<article-url>.txt` (this format). To get an index of all articles with their `.txt` links, read: https://knowledge.leegality.com/llms.txt
> **AI Guide:** For instructions on how to navigate this knowledge base as an AI agent, read: https://knowledge.leegality.com/ai-readable.txt

---
# What is an Obligation?

> An obligation is a commitment that a contract creates for one of the parties. It can be a deadline, a deliverable, or a requirement. Renewal notices, data delet

An obligation is a commitment that a contract creates for one of the parties. It can be a deadline, a deliverable, or a requirement. Renewal notices, data deletion requirements, insurance certificate submissions, and audit reporting deadlines are all obligations.

The Obligations module tracks these commitments across your executed contracts. It records what each contract requires, when it falls due, and who is responsible. It then creates tasks so that someone acts before the deadline.

You can let AI find obligations in the contract text, or you can add them yourself.

<!-- ARCADE · P3 · Module orientation tour
     Show: the Obligations entry in the sidebar, then each area in turn — Dashboard, Manage, Settings, and the Processing Hub tab.
     Call out: this is a 30-second 'where things live' tour, not a task walkthrough.
-->

## How an Obligation Is Created

An obligation reaches your list in one of three ways.

| Route | What happens |
| --- | --- |
| **Automatic extraction** | When a contract reaches **Executed**, the AI reads it and flags the obligations it finds. This only runs if your organisation has turned on automatic extraction. See [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings). |
| **Manual extraction** | You run extraction on a contract yourself, without waiting for the automatic run. |
| **Manual creation** | You add the obligation yourself. See [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation). |

Automatic extraction covers contracts executed in Deal Collaboration as well as older contracts you upload into it. Each has its own setting. Your organisation can also limit automatic extraction to contracts that have not expired, in which case expired contracts are skipped.

Every obligation the AI finds shows the exact clause it came from, along with the AI's reasoning. You can check this against the contract before you rely on it.

You can then mark it as **Verified**. Verifying is optional. When you mark an AI-extracted obligation as Verified, its source changes from AI-Assisted to Verified. It is a review step, not an extra flag alongside the original value.

## Obligation Lifecycle

```mermaid
graph LR
    A["Obligation created"] --> B["Active"]
    B --> C["Task created before the due date"]
    C --> D["Completed or Expired"]
    B --> D
    D -.->|Reopen| B
```

## Obligation and Task Status

An obligation and its tasks have separate statuses. The obligation tracks the commitment. A task tracks one piece of work needed to meet it.

**Obligation status**

| Status | Meaning |
| --- | --- |
| **Active** | The commitment is still live. |
| **Completed** | Marked as met. |
| **Expired** | Marked as no longer applicable. |

You can reopen an obligation that was closed by mistake. This activity is recorded for audit purposes.

**Task status**

| Status | Meaning |
| --- | --- |
| **Pending** | Created and waiting for action. |
| **Resolved** | Completed. |
| **Breached** | Not completed within its turnaround time. |
| **Cancelled** | Withdrawn. This happens when the obligation is expired or deleted, or when an edit invalidates a task that nobody has acted on yet. |

## Tasks and Turnaround Time

Tasks are optional. You set them up on the obligation itself or on the template. Two settings control the timing, and they do different things.

- **Task creation date**: how many days before the due date the task is created.
- **TAT (Turnaround Time)**: how many days the assignee then has to complete it. A task that is not completed within this window is **Breached**.

The turnaround time cannot extend past the due date. If you need a longer turnaround time, create the task earlier.

Repeating obligations create one task for each occurrence. The creation window cannot overlap the next occurrence, so tasks from different cycles never run at the same time. Tasks from earlier cycles can still sit at different statuses.

See [Tasks and Notifications](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation#tasks--notifications) for the full configuration, including TAT breach emails and repeat reminders.

## Conflicts {#conflicts}

A conflict means that an obligation needs your attention, because its due date or task setup can no longer be trusted. Instead of acting on stale information, the module flags the obligation and waits for you to fix it.

An obligation with a conflict shows a **Conflict** badge wherever it appears, including the obligations list, a contract's own obligations panel, and the Task Conflicts count on the [Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard).

| Conflict | What it means |
| --- | --- |
| **Reference date changed** | The linked reference variable was re-extracted and its value changed. The due date and any existing tasks still use the original date. |
| **Reference variable has no value** | The linked reference variable is empty, so the due date cannot be calculated. |
| **Variable not found on document** | The linked reference variable is not available on this document. |
| **Task creation window missed** | The date on which the task should have been created has already passed. |
| **Past due date detected** | The due date that the task was set up against is now in the past. |

When you edit the obligation, the conflicts that your edit resolves are cleared. See [Finding and Fixing Conflicts](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations#finding-and-fixing-conflicts) for how to work through them.

## Related Pages

- [Obligations Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard)
- [Managing Obligations](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations)
- [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation)
- [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings)

<!-- ==================== POC REVIEW NOTES (not rendered) ====================
TONE PASS (2026-09-03). Language and sentence structure only — no facts, no
sections, no tables and no diagram content were changed. Applied after review
of Conga's CLM obligations documentation, plus a style audit of this repo's own
published Deal Collaboration pages.

What changed and why:
- Em dashes cut heavily. This section ran at 11.1 per 100 lines against 1.5
  across the repo's published DC pages — the single biggest reason the writing
  read as machine-generated. Asides are now separate sentences or clauses.
- Long sentences split. Several sentences carried two or three ideas joined by
  dashes and semicolons; each idea now gets its own sentence.
- Bold reduced to actual UI elements and status values. It was running at 41
  per 100 lines against the repo's 21, which flattened the emphasis.
- Admonition titles made plain. ":::warning[A changed reference variable needs
  review]" is now ":::caution[Important]", matching Contracts/folders.md,
  which uses ":::info[Note]".
- Editorial framing removed. Phrases like "it is worth keeping them distinct",
  "the module's way of telling you", "rather than after it" and "don't assume"
  were rewritten as direct statements.
- Second person used consistently, following Conga ("You can set", "you can
  filter", "when you edit").
- "Where Obligations Fit" entries changed from dash-appended fragments to
  "Label: sentence", which is Conga's bulleted-list pattern.
- Spelling changed to "organisation" to match the repo's existing usage.

KEPT deliberately, against Conga's style: bold UI labels and titled
admonitions. Conga uses plain text for UI elements and a bare "Note:" prefix,
but this repo bolds UI labels throughout (21 per 100 lines) and uses
":::info[Note]" blocks. Following Conga there would make Obligations
inconsistent with every other section.

Anchors preserved: "## Conflicts {#conflicts}" and the exact heading text
"Due Dates and Reference Variables", both linked from other pages.

--- CONTENT QUESTIONS (unchanged by the tone pass) ---

1. RENEWALS MODULE. The previous version of this page stated: "The Obligations
   Module replaces the standalone Renewals module. Renewals are now handled as
   one category of obligation among many, giving you recurring task cycles and
   more detailed reporting than the Renewals module supported."
   Verified: a default "Renewal" obligation category exists, seeded with
   templates (Contract Renewal Notice, Auto-Renewal Opt-Out).
   NOT verified: that Obligations replaces/deprecates the Renewals module, and
   the reporting comparison. No Renewals module or migration path found.
   -> Confirm whether the replacement claim should be restated, and whether
      existing Renewals records migrate.

2. FEATURE AVAILABILITY. Is the Obligations Module generally available, or
   gated per organisation? Affects whether this page should carry a note.

3. MANUAL EXTRACTION ENTRY POINT. Manual extraction triggering exists, but the
   UI entry point is not described here. Where does a user trigger it from?

4. RE-EXTRACTION BEHAVIOUR. Re-extraction can either add to existing
   obligations or replace them. Is this a user-facing choice, and if so where?
   Deliberately omitted until confirmed.

5. CONFLICTS PAGE. Conflicts are introduced here for the first time and are
   currently undocumented elsewhere. If they warrant their own page, this
   section should shrink to a summary and link out.

6. CONFLICT LABELS. The labels in the Conflicts table are the frontend strings
   (what a user sees). The backend uses different wording for the same
   conflicts — e.g. frontend "Reference variable has no value" vs backend
   "Reference date missing"; frontend "Task creation window missed" vs backend
   "Task creation missed". Confirm against the live UI.
   Two specific ambiguities:
   - The frontend maps BOTH its TAT conflict and its creation-window conflict
     to the same label, "Task creation window missed", while also defining
     "Past due date detected". The row here uses "Past due date detected" for
     the past-due-date case because that matches the backend message text
     ("The due date this task was set up against is in the past"), but which
     label actually renders needs checking.
   - The backend has a sixth conflict, "Due date source missing" (task
     creation configured with neither a fixed due date nor a reference
     variable). No matching frontend label was found, so it is omitted here.
     Confirm whether users ever see it.

7. REFERENCE VARIABLE SYNC — NEEDS A DECISION. The product's own UI helper
   text on the "Link due date to reference variable" toggle says the due date
   is "kept in sync automatically — if the variable changes, the due date
   updates too." The backend says terminal_due_date is "snapshotted at create
   time; variable drift surfaces as a conflict rather than auto-updating this
   field", and the conflict message tells the user "Existing tasks are still
   tied to the old due date."
   These reconcile if the due date follows the variable while already-created
   TASKS do not. The caution above is therefore worded to cover only what both
   sources agree on: tasks stay put and a conflict is raised. Confirm with
   engineering what actually happens to the due date itself.
   NOTE: an earlier draft of this page claimed the due date "updates
   automatically" — that matched the UI tooltip, so it was not invented.
========================================================================== -->