Obligation Extraction and Loan Document Review with Claude

The Short Answer

Obligation extraction is the task of reading a contract and listing every "shall," every deadline, and every trigger in a structured table so nothing is discovered after it is breached. Claude does this well on loan documents: give it the credit agreement and its schedules, ask for four tables (affirmative and negative covenants, reporting obligations, dated deadlines, and events of default), and you get a first pass with section references that you verify against the document and feed into your calendar.

This post is about the transactional side of using Claude for contracts: not "is this clause risky," but "what does my client have to do, by when, and what happens if they do not." That question is where borrowers get hurt, because a loan agreement is mostly a list of ongoing promises, and the promises are scattered across the covenants article, the definitions, the schedules, and the compliance certificate form. The extraction tables below are designed to gather them in one place.

What "Obligation Extraction" Means on a Loan Document

A credit agreement contains four kinds of obligations, and they hide in different places.

• Covenants are ongoing promises: maintain insurance, keep a leverage ratio below a threshold, do not incur debt above a basket, do not sell assets outside the ordinary course. Affirmative covenants say what the borrower must do; negative covenants say what it must not. They live in the covenants articles, but the baskets and thresholds that make them real are usually in the definitions.
• Reporting obligations are recurring deliverables: annual audited financials within a set number of days after year-end, quarterly unaudited statements, a compliance certificate with each set, an annual budget, notices of default, litigation, or material adverse change within a short window after the borrower knows. These are the obligations most often missed, because each one is small and they recur forever.
• Deadlines are fixed or triggered dates: maturity, amortization payments, mandatory prepayment on an asset sale, the deadline to deliver post-closing items (landlord waivers, insurance endorsements, perfected liens on later-acquired property), and the notice periods for drawing or prepaying.
• Events of default are the consequences: what counts as a default, which defaults have cure periods and how long, which cross-default to other debt, and what the lender can do (accelerate, terminate commitments, sweep cash).

Extracting all four into tables is the difference between a memo that says "the borrower has standard reporting covenants" and a checklist a paralegal can calendar.

The Four Extraction Tables

Ask for these in this order, in one conversation, with the credit agreement, schedules, and any amendment uploaded first. Each table has fixed columns so the output is comparable across deals and easy to verify.

Table 1: Covenants

Columns: Covenant | Affirmative or negative | What the borrower must do or not do | Threshold, basket, or ratio (with the defined term) | Section | Testing frequency. The last two columns are where extraction earns its keep. A leverage covenant is only useful if you know the defined term it references and when it is tested (quarterly, on a trailing-twelve-month basis, only when a revolver is drawn above a percentage). Ask Claude to quote the defined term exactly and cite the definition section separately from the covenant section.

Table 2: Reporting Obligations

Columns: Deliverable | Frequency | Due (days after what trigger) | To whom | Form required (attach a compliance certificate, officer's certificate, auditor's letter) | Section. This table becomes a recurring calendar. Ask Claude to flag any deliverable that depends on the borrower's fiscal year end, since the actual dates cannot be computed without it.

Table 3: Deadlines and Triggered Obligations

Columns: Obligation | Fixed date or trigger | Days after trigger | What must happen | Section | Cure or grace period. This picks up post-closing deliverables, mandatory prepayment triggers, notice periods, and the maturity and amortization schedule. Fixed dates go straight to the calendar; triggered ones become a watchlist.

Table 4: Events of Default

Columns: Event | Cure period | Cross-default (to what debt, above what amount) | Lender remedies | Section. The cross-default row matters most for a borrower with more than one facility, and the threshold amount is often defined elsewhere, so again ask Claude to cite the definition.

The Prompt (Copy This)

You are assisting a licensed attorney reviewing a loan document for
the [BORROWER / LENDER]. I have uploaded the credit agreement, its
schedules and exhibits, and [any amendments]. The borrower's fiscal
year ends [DATE or UNKNOWN].

Step 1. Inventory what you received: agreement date, parties,
facility type and amount, maturity date, and every schedule,
exhibit, or amendment referenced in the body. Mark any referenced
document you cannot find as MISSING. Do not analyze yet.

Step 2. Produce four tables.

Table 1, Covenants. Columns: Covenant | Affirmative or negative |
What the borrower must do or not do | Threshold, basket, or ratio
(quote the defined term exactly) | Covenant section | Definition
section | Testing frequency.

Table 2, Reporting obligations. Columns: Deliverable | Frequency |
Due (days after what trigger) | To whom | Required form or
certificate | Section. Flag every row whose date depends on the
fiscal year end.

Table 3, Deadlines and triggered obligations. Columns: Obligation |
Fixed date or trigger | Days after trigger | What must happen |
Section | Cure or grace period. Include maturity, amortization,
mandatory prepayments, post-closing deliverables, and notice
periods.

Table 4, Events of default. Columns: Event | Cure period |
Cross-default (which debt, threshold amount, and the definition
section) | Lender remedies | Section.

Rules:
- If the document does not address a row you would expect, write
  NOT FOUND. Do not supply a market-standard term.
- Where an amendment changes a term, show the amended term and cite
  both the original section and the amendment.
- Do not compute calendar dates. Give the trigger and the day count
  only; I will compute dates under the governing counting rules.
- Do not rate risk or recommend changes. Extraction only.

The "do not compute calendar dates" rule is deliberate. Claude does not know whether the agreement counts business days or calendar days for a given deliverable without checking the definition each time, and it does not know which holidays apply. Keeping day counts separate from dates makes the table safe to hand to whoever runs your docket.

From Extraction Table to Calendar

Tables 2 and 3 are the ones that turn into dates. The deadline extraction workflow covers the mechanics, but the loan-specific version is short:

1. Resolve the triggers. Give Claude the fiscal year end and the closing date and ask it to restate every row in Table 2 and Table 3 with a concrete anchor date, still as day counts. A row that said "within 120 days after fiscal year end" becomes "120 days after December 31."
2. Compute dates yourself. Check the agreement's definition of Business Day and the counting convention, then compute. Claude can do the arithmetic if you tell it the rule, but you confirm the rule.
3. Add internal lead times. A compliance certificate due 45 days after quarter end needs financials from the client two weeks before that. Ask Claude to add a "start work by" column at whatever lead time your practice uses.
4. Export. Ask for the final table as CSV with columns for date, obligation, section, and responsible party, and import it into whatever calendar your firm docket runs on. No automation platform is required; the CSV is the integration.

Recurring obligations get a recurring entry with an end date at maturity. Triggered obligations (mandatory prepayment on an asset sale, notice within five business days of a default) go on a watchlist rather than a calendar, with the trigger described so the client knows what to tell you about.

Where Loan Document Review Goes Wrong

• Defined terms. Nearly every number in a credit agreement is a defined term, and the definition is often a page long with its own carve-outs. Claude will sometimes report the covenant threshold without the carve-outs that make it workable. Fix: the prompt's separate definition-section column, and your own read of each definition that matters.
• Amendments. A first amendment that restates a covenant is easy to miss if it was uploaded as a separate file. Confirm in Step 1 that every amendment was received and instruct Claude to show amended terms with both citations.
• Schedules. Existing debt, existing liens, permitted investments, and material contracts live on schedules. A negative covenant that permits "Indebtedness listed on Schedule 7.01" means nothing without the schedule. NOT FOUND on a schedule is a flag to go get it.
• Business days. Notice periods and cure periods switch between business and calendar days, sometimes within the same section. Do not let a model, or a tired associate, assume.
• Which side you are on. Extraction is neutral, but the "what must happen" column reads differently for a lender tracking compliance and a borrower trying not to trip a default. State your side in the first message so the follow-up analysis is oriented correctly.

Beyond Loans: The Same Tables Work on Most Commercial Contracts

The four-table structure is not loan-specific. A supply agreement has service-level covenants, reporting (forecasts, audits), deadlines (renewal notice, price-adjustment windows), and termination triggers. A commercial lease has all four as well, which is why the lease review post uses the same NOT FOUND discipline. For a batch of incoming contracts where the question is "which of these needs a lawyer's attention this week," start with the NDA and contract triage workflow and run the full extraction only on the ones that clear triage. And if obligation tracking is a recurring part of your practice, put the prompt in a Claude Project with your firm's column preferences so it runs the same way every time; the reusable Project workflow shows how.