Covenant Headroom Monitor

Covenant Headroom Monitor

When to use

Use whenever a business has debt covenants (leverage ratio, interest coverage, minimum liquidity) that need monitoring against actual or projected financials, especially replacing a covenant check that only reports pass or fail each quarter with no visibility into how much headroom is shrinking before an actual breach occurs.

What it does

Tests each covenant's actual or forecasted value against its threshold every quarter via a bundled calculator, computes headroom as a percentage, and flags the first quarter headroom drops below a stated warning threshold (not just the quarter of actual breach) — the entire point being that a lender conversation started while headroom is merely tight goes very differently than one started after an actual breach has occurred.

Method

1. State each covenant's type explicitly: maximum (leverage ratio, debt-to-EBITDA — you must stay under the threshold) or minimum (interest coverage, minimum liquidity — you must stay over the threshold). The headroom calculation direction depends on this.
2. Project or gather the actual value for each covenant, quarter by quarter, tied to the same forecast used elsewhere (rolling-forecast-builder, scenario-planning-engine) so the covenant check reflects the same view of the future as everything else.
3. Run the bundled calculator (scripts/covenant_monitor.py) to get headroom percentage per quarter per covenant, and the first quarter each covenant crosses the warning threshold and the first quarter (if any) it actually breaches.
4. Set the warning threshold meaningfully (commonly 15%) — not so tight that it fires constant false alarms, not so loose that it fires too late to act.
5. Treat the first warning-threshold quarter as the actual trigger for action, not the breach quarter. By the time an actual breach happens, the options (renegotiate terms, raise equity, cut costs urgently) are far narrower and more expensive than they would have been with a full quarter or two of lead time.
6. Run this against the downside scenario from scenario-planning-engine, not just the base case — a covenant that holds comfortably in the base case but breaches in a plausible downside is a real risk worth planning for now, not a surprise to discover later.
7. Update the covenant monitor every forecast cycle, since covenant compliance depends entirely on the underlying forecast, and a stale covenant check based on an outdated forecast can miss a real emerging risk.

Inputs

• Each covenant's type (max or min), threshold, and quarterly actual or projected values
• The warning headroom percentage to flag against
• Config saved as JSON matching the format documented at the top of scripts/covenant_monitor.py

Output format

Quarter-by-quarter table per covenant with value, headroom percentage, and OK/WARNING/BREACH status; explicit flag naming the first warning quarter and the first breach quarter if applicable, with the note that the warning quarter, not the breach quarter, is when action should start.

Example

A leverage covenant with a 3.5x maximum threshold shows headroom dropping below 15% starting in Q2, even though an actual breach isn't projected until later. Flagging Q2 as the action trigger gives the business two full quarters of lead time to start a lender conversation, explore refinancing, or take cost action, versus discovering the problem only when headroom finally reaches zero.

Common pitfalls

• Reporting only pass/fail per quarter, missing the trend of shrinking headroom that would have given earlier warning.
• Running the covenant check only against the base-case forecast, missing that a plausible downside scenario would breach it.
• Waiting until the actual breach quarter to start the lender conversation, when options are much narrower and more expensive than they would have been with earlier warning.