We spent the first year of ExactCov reading high yield indentures and syndicated loan agreements, and the register we built was shaped by them. Then we started working with private credit teams and discovered that the same word, covenant, describes a different job. This post is about that difference, because it decides what a monitoring system has to be.
Two kinds of covenant, two kinds of question
An incurrence covenant restricts what the borrower may do. It is tested only when the borrower does it: incur debt, grant a lien, pay a dividend, sell an asset. Between those events there is nothing to test. The lender's question is capacity: how much room is there, and what would consume it. The answer is a computation over baskets and definitions, run on demand.
A maintenance covenant restricts what the borrower must be. Leverage below a level, coverage above a level, liquidity above a floor, tested on a fixed schedule against reported financials, whether or not the borrower does anything. The lender's question is compliance: did the test pass, by how much, and which way is it heading. The answer is a periodic calculation against a certificate, with a due date.
Cov-lite syndicated deals and bonds are almost entirely incurrence. Private credit, bilateral bank facilities and most mid-market lending are maintenance-heavy, often with an incurrence package alongside. The two segments need different registers, and they need different monitoring.
Cadence changes everything
Because maintenance covenants have a schedule, the monitoring job has a calendar, and the calendar is where most of the work is.
| Question | Incurrence | Maintenance |
|---|---|---|
| When is it tested? | When the borrower acts; often never | Every period, on a date in the agreement |
| What is the input? | The proposed transaction plus the latest financials | The compliance certificate and the accounts behind it |
| What can go wrong quietly? | Capacity is misjudged and a transaction is permitted that should not have been | The certificate is late, the test is not re-run, and the book carries a stale pass |
| What is the output? | A capacity table with citations | A pass or fail with headroom, a trend and a due date for the next one |
| What does the desk need? | An answer in an hour when the sponsor calls | A morning list of what is due, late, near and breached |
The consequence is that a private credit monitoring system is mostly a calendar with a calculation attached, whereas a syndicated loan tool is mostly a calculation with a document attached. Both need the register. Only the first needs deliverables, chase, staleness and the rest of the machinery we have written about elsewhere.
Incurrence asks "may they?". Maintenance asks "are they, still, this quarter?". The second question does not stop being asked, which is why it needs a system.
Where the two meet
They meet in private credit, which typically has one or two maintenance tests and a full incurrence package. The maintenance tests generate the cadence: quarterly certificates, due dates, headroom trends. The incurrence package generates the standing questions: capacity, permitted payments, portability. The same financials feed both. A certificate that arrives late stalls the maintenance test and also stalls every grower basket that depends on the EBITDA in it.
That is why we decided the register had to hold both kinds of covenant in one structure with one set of financial inputs, and why the calendar had to be first-class rather than an add-on. A private credit team that buys a capacity tool gets half the job. A team that buys a covenant tracker gets the other half. Neither half is the one that fails quietly for the other.
The segment we are selling into
We say this plainly because it took us a while to learn it. The teams who need monitoring most are the ones with the cadence: private credit, bank portfolio teams, fund finance and counterparty desks whose agreements test something every month or quarter. For them the register is table stakes and the calendar is the product.