Banking and Covenant Model
Track leverage, coverage, liquidity and covenant cure options.
Banking and Covenant Model
Track leverage, coverage, liquidity and covenant cure options.
Model architecture
- Map exact agreement definitions.
- Build compliance calculations.
- Forecast headroom monthly or quarterly.
- Model cure and waiver scenarios.
A professional model should make the decision logic visible. Inputs belong in a controlled assumption area; calculations should be formula-driven; outputs should state units, dates and scenarios; checks should be obvious and actionable.
Core inputs
- Debt agreements
- EBITDA adjustments
- Net debt definition
- Finance charges
- Minimum liquidity
Formula logic
| Relationship | Use |
|---|---|
Headroom = Covenant limit − Forecast metric for maximum tests | Model formula / relationship |
Interest coverage = Covenant EBITDA ÷ Covenant finance charges | Model formula / relationship |
Use the formulas as design relationships, not as substitutes for the accounting policy, contract definition or transaction facts relevant to the model.
Practical example
A 3.5x maximum leverage covenant with forecast leverage of 3.2x has only 0.3x headroom, which may be inadequate under a modest downside case.
How to implement
- Load the historical base and reconcile it.
- Put assumptions in dedicated cells.
- Build the schedule from operational drivers.
- Link outputs to financial statements and dashboards.
- Run base, upside and downside checks.
Control checks
- Definitions agree to agreement
- Testing date is correct
- Permitted add-backs are capped
- Restricted cash is handled correctly
- Certificates reconcile
Common modeling errors
- Using accounting EBITDA instead of covenant EBITDA
- Ignoring seasonal testing dates
- Assuming waivers
- Failing to model cure equity
- Not tracking basket usage
Practical Q&A
Should the model contain all possible detail?
No. It should contain enough detail to answer the decision question and explain material risks. Excess detail can hide the drivers.
Should a formula ever contain a hardcoded number?
Only for constants that are genuinely universal or immaterial. Business assumptions should be linked to visible input cells.
What is the minimum review standard?
Reconcile historical data, test key formulas independently, scan for hardcodes and errors, verify scenario switches, and review outputs under downside assumptions.