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.