Covenant Tracker vs Covenant Monitoring Software: What Actually Differs
A covenant tracker stores covenant definitions and test dates and reminds someone. Covenant monitoring software ingests the compliance certificate and the underlying financials, recomputes each tested ratio to the agreement's own definitions, and flags the breach itself. The difference is not the interface. It is whether anything computes.
Key facts
- Recomputation is an extraction problem before it is a calculation problem. YuSight measures 95.2% extraction accuracy against a manual benchmark, with every figure traced to source document and page. A system that cannot read the audited accounts cannot recompute the ratio inside them, whatever its dashboard looks like.
- Supervisors expect automation for exactly this reason. BCBS 239 Principle 3: risk data "should be aggregated on a largely automated basis so as to minimise the probability of errors," and where a bank "relies on manual processes and desktop applications (eg spreadsheets, databases)... it should have effective mitigants in place" (BIS, January 2013).
- A spreadsheet that computes a covenant ratio is not exempt from validation. SR 11-7 requires that "all model components—inputs, processing, outputs, and reports—should be subject to validation" (Federal Reserve, SR 11-7, 4 April 2011). Note: SR 11-7 was superseded on 17 April 2026 by SR 26-2 and OCC Bulletin 2026-13, which narrow the definition of a model and place generative and agentic AI outside scope. Whether this requirement still reaches your tool is the live question — see what SR 26-2 changed.
- In the UAE this is a written obligation. CBUAE Credit Risk Management Regulation C 3/2024 (in force 30 November 2024) requires that credit risk "is fully monitored, reported and managed" (Art. 11) and that institutions document "a set of criteria and early warning signals" (Art. 6.5) (CBUAE Rulebook).
What does a covenant tracker actually do?
A tracker is a calendar with a schema. Done well it holds four things per facility: the covenant text and its threshold, the test frequency and resulting test dates, the reporting deadlines that feed those tests, and a status field someone updates.
That is genuinely useful. The most common covenant failure in a mid-market book is not a miscalculated ratio — it is a test that never happened because nobody chased the management accounts. A tracker fixes that failure.
But what it produces is a record of receipt. The certificate arrived on 12 November, it says compliant, the diary item closes. The status field now holds the borrower's opinion, restated by your officer.
What does monitoring software do that a tracker cannot?
It computes. Specifically, it does five things a tracker cannot do no matter how good the interface:
- Reads the certificate as data, not as an attachment. Certified EBITDA, certified debt service, certified ratio, each as a field.
- Spreads the underlying financials the certificate was built from, so there is a second, independent set of numbers.
- Recomputes the tested ratio to the agreement's definitions — add-back caps, cash-netting limits, the debt service inclusion list — rather than to the market-standard formula. This is where the disputes live; see covenant testing for DSCR and leverage.
- Reconciles certified against recomputed and attributes the difference to a named definitional treatment, instead of leaving a gap with no explanation.
- Reports headroom, not status — how far EBITDA can fall before the binding covenant trips.
None of these are UI features. They are the presence or absence of a calculation engine and an extraction layer beneath it. A tracker with colour-coded due dates still has no opinion about whether 1.31x is the right number.
Worked example: the same certificate, both systems
A distributor with a 30 September quarterly test. Covenant: DSCR ≥ 1.25x, tested on a rolling twelve-month basis. Compliance certificate due within 45 days; it arrives on 12 November. All figures in ₹ million. The facility, the numbers and the 5% add-back cap are illustrative.
What the certificate says:
Line | Certified |
|---|---|
Reported EBITDA (LTM) | 452.0 |
Add-back: restructuring | 22.0 |
Add-back: one-off legal | 12.0 |
Covenant EBITDA | 486.0 |
Cash interest | 96.0 |
Scheduled amortisation | 276.0 |
Debt service | 372.0 |
DSCR | 486.0 ÷ 372.0 = 1.31x — compliant |
What recomputation from the accounts produces:
- Add-back cap in the agreement: 5% of EBITDA before add-backs → 5% × 452.0 = 22.6, against 34.0 claimed.
- Covenant EBITDA = 452.0 + 22.6 = 474.6
- Debt service definition includes finance-lease principal, disclosed in the lease note at 18.0 → 96.0 + 276.0 + 18.0 = 390.0
- DSCR = 474.6 ÷ 390.0 = 1.217x
Against a 1.25x covenant, that is a breach. Required EBITDA is 1.25 × 390.0 = 487.5; actual is 474.6, a shortfall of 12.9, or 2.6%.
The tracker's output: certificate received 12 Nov, on time, compliant, closed. The monitoring system's output: certified 1.31x, recomputed 1.217x, breach; delta driven by ₹11.4m of add-backs above the 5% cap and ₹18.0m of finance-lease principal excluded from certified debt service; source pages attached.
Both systems worked exactly as designed.
Capability table
Capability | Covenant tracker | Covenant monitoring software |
|---|---|---|
Store covenant text, thresholds, test frequency | Yes | Yes |
Generate test dates and reporting deadlines | Yes | Yes |
Chase and log document receipt | Yes | Yes |
Ingest the compliance certificate as structured data | Manual re-keying | Automated extraction |
Spread the underlying financial statements | No | Yes |
Recompute the ratio to the agreement's definitions | No | Yes |
Reconcile certified vs recomputed and explain the delta | No | Yes |
Headroom and sensitivity ("EBITDA can fall x% before breach") | No | Yes |
Portfolio breach rollup weighted by exposure | Counts only | By exposure and by covenant |
Every figure cited to source document and page | No | Yes |
Setup effort | Days | Weeks — definitions must be configured per facility |
Ongoing discipline required from your team | High | Moderate, but real |
Which do you need? A five-question test
Score one point per yes.
- Do more than 30 of your facilities carry a maintenance financial covenant, as opposed to reporting and affirmative undertakings only?
- Do your covenant definitions differ materially between facilities — different add-back caps, different debt service inclusions, frozen-GAAP clauses?
- Do the numbers you need arrive as documents (PDF accounts, scanned certificates) rather than as structured data from a borrower portal?
- Has anyone in the last two years found a breach that the borrower's certificate said was compliance?
- Would you struggle, today, to show an examiner the arithmetic behind a covenant test from eighteen months ago?
0–1: a tracker is the right answer. Buy the calendar, run it properly, stop there. 2–3: a tracker plus a documented recomputation procedure, with sampling — recompute every certificate for the top decile by exposure and a random 10% of the rest. 4–5: the recomputation is the job. A tracker will keep telling you that a set of numbers you never checked arrived on time.
When is a well-run tracker the better buy?
Often. This is the part vendors do not say.
Monitoring software only outperforms a tracker if someone configures the covenant definitions correctly, facility by facility. Configuration is the whole product. A bank that populates a monitoring platform with the market-standard DSCR formula for all 400 facilities has bought an expensive tracker that produces confidently wrong ratios — worse than no ratio at all, because a wrong number gets believed.
Three situations where a tracker plus process genuinely wins:
- A homogeneous book. If 380 of your 400 facilities run on three covenant templates from your own sanction format, the definitional variation that monitoring software exists to handle is not present.
- Structured inputs. In much of Indian working capital lending the operative controls are stock statements, book-debt statements and drawing power, arriving as periodic returns in a fixed format — closer to drawing power vs ratio covenants than to leveraged-loan covenant testing.
- No owner. If nobody owns recomputation as a named responsibility, software will not create the owner. It will create a backlog with a licence fee.
The honest middle ground: run the tracker for the calendar, recompute by exception and by exposure, and document the sampling rule. What is not defensible is a status column mistaken for a test.
Can a spreadsheet tracker survive an audit?
Conditionally — on the terms BCBS 239 sets for desktop applications: version control, restricted access, a change log, a named owner, independently checked formulas. And if the spreadsheet computes a ratio that feeds a risk grade, SR 11-7's validation requirement reaches it.
What kills spreadsheet trackers in examination is not the tool but the absence of the working: a cell containing 1.217 with no trail back to the lease note on page 47. That gap is identical whether the cell sits in Excel or in a purchased platform — see the covenant monitoring pillar for the full evidence chain.
FAQ
What is the difference between a covenant tracker and covenant monitoring software?
A tracker holds the covenant definitions, the test dates and a status someone updates. Monitoring software also reads the financial statements, recomputes each ratio to the agreement's own definitions and tells you whether the borrower's certified number is right. One manages the diary; the other does the arithmetic.
Does a tracker calculate the ratio?
No. Some trackers let you type a ratio into a field, and a few will divide two numbers you have already keyed in. Neither is calculation in the sense that matters, because the inputs still came from the borrower's certificate rather than from the accounts underneath it.
Can a spreadsheet tracker survive an audit?
It can, if it has version control, a named owner, restricted access, a change log and independently checked formulas. What usually fails is traceability — an examiner asks where 1.217 came from, and there is no path back to the page it was built from.
Is covenant monitoring software just a module of the LOS?
Sometimes, and that is fine if your LOS module can recompute rather than only tick. Ask the vendor to show a certified ratio and a recomputed ratio side by side on a real facility. If the demo only shows due dates and alerts, you are looking at a tracker with LOS branding. Our 2026 covenant software roundup groups the vendors on exactly this line.
How many covenants do you need before software is worth it?
There is no threshold in covenant count. The threshold is in definitional variety and document dependency. Forty facilities with forty differently-drafted add-back caps justify software; four hundred facilities on one internal template usually do not.
Does covenant monitoring replace the compliance certificate?
No. The certificate is a contractual representation signed by the borrower, and its value is that someone is on the hook for it. Recomputation sits alongside it. When the two disagree you have both a number and a conversation.
Conclusion
Three things to take away:
- The distinction is computation, not interface. A tracker records that a number arrived; monitoring software decides whether it is right. Every other difference follows from that one.
- A tracker's blind spot is where covenant losses come from — a certified ratio built on uncapped add-backs and an incomplete debt service line, accepted because it arrived on time.
- Software you will not configure is worse than a tracker you will run. Configure the definitions facility by facility, or buy the calendar and recompute by sampling. A half-configured platform is neither.
YuSight's Covenant Monitoring reads the covenant definitions from the facility agreement, computes each tested ratio from the spread financials at 95.2% extraction accuracy validated against a manual benchmark, and shows the certified figure next to the recomputed one with every input cited to its source page.
See covenant testing run automatically — book a live demo.
