Ask an analyst to find the leverage covenant in a credit agreement and they can usually do it in a few minutes. Ask a system to do the same thing reliably across thousands of agreements, with different drafting counsel, different templates, and different amendment histories, and the problem turns out to be substantially harder than it first appears.
Why keyword search is not enough
The obvious approach, searching for the phrase "leverage ratio," fails quickly. The actual covenant might be defined under "Total Net Leverage Ratio," "Consolidated Leverage Ratio," or a defined term unique to that agreement's drafting, cross-referenced three sections away from where the numerical threshold actually appears. A useful extraction system has to understand the structure of the document, not just match strings.
The layered structure of a credit agreement
Credit agreements are built from layers that all interact.
- A definitions section that establishes what terms mean, often stretching to fifty or more defined terms.
- Operative covenant sections that reference those definitions rather than restating them.
- Schedules and exhibits that carry the actual numerical thresholds, sometimes in a separate document entirely.
- Amendments and waivers, executed later, that modify specific sections without restating the whole agreement.
A clause is not fully understood until all four layers are reconciled, which is exactly the work a careful attorney or credit analyst does manually today.
How we approach extraction
Our approach treats clause extraction as a structured reasoning problem rather than a pattern-matching one.
- Parse the document into its logical sections, distinguishing definitions, covenants, representations, and schedules.
- Resolve defined terms to their actual definitions wherever they are referenced, building a dependency graph rather than treating each mention in isolation.
- Identify amendments that touch a given clause and apply them in chronological order to produce the current, effective version of the term.
- Attach every extracted fact to its precise source location, across the original agreement and any amendment, so a reviewer can verify the chain.
Handling ambiguity honestly
Some clauses genuinely require judgment, particularly around EBITDA add-back definitions or basket calculations that interact with several other covenants. In those cases, the system surfaces the relevant language and its interpretation rather than forcing a single confident answer, because a false sense of certainty is worse than a flagged ambiguity.
The hardest part of reading a credit agreement is not the language. It is tracking what has changed since the language was written.
Why this matters for monitoring, not just underwriting
Clause extraction pays off most visibly at closing, but it matters just as much during the life of the loan. Covenant monitoring requires knowing the current, amended threshold, not the original one, and a compliance certificate that gets checked against an outdated covenant is a real operational risk, not a theoretical one.
What good extraction unlocks downstream
Once covenants, definitions, and their amendment history exist as structured, linked data, several things become possible that were previously impractical at scale.
- Portfolio-wide covenant comparison across hundreds of loans, something no team could realistically do by hand.
- Automated flagging when a compliance certificate's calculation appears inconsistent with the current, amended covenant definition.
- Faster response when a sponsor requests a waiver, because the current terms and their history are already assembled rather than needing to be reconstructed from scratch.
The bar we hold this work to
We do not consider clause extraction solved for a document until the system can explain, with a citation, exactly why it believes a given threshold is currently in effect. That standard is harder to meet than simple extraction, and it is the only standard that matches what a credit committee actually needs.
