Covenant tracking software holds every covenant and reporting obligation in a bank's commercial loans, keeps the calendar of what each borrower owes and when, and flags what is late, tight or breached; the better products also recalculate each financial covenant from the borrower's statements. To set it up, a bank needs five kinds of input: each borrower's credit agreement with every amendment, consent and executed waiver; its recent compliance certificates and the financial statements delivered with them; the reporting dates the agreements set; the bank's own spreading template and credit policy; and the letter templates its legal team has approved. Software can read and test; it cannot test a definition it was never given. Botminds' Covenant Monitoring starts from a sample of a bank's own agreements and certificates, so the first thing a bank sees is its own borrowers re-tested, and the gaps in its files show up before it relies on the results.
What is covenant tracking software, and what does setup involve?
Covenant tracking software is the system of record for what each borrower has promised the bank after closing, and setup is the work of loading those promises correctly. How much work depends on what the software is meant to do. A tool that only tracks dates and status needs each covenant's limit and due date. A tool that tests needs the full agreement, every amendment and the statements, because it rebuilds each ratio under the agreement's definitions.
The difference shows in what goes wrong. A tracking-only setup can be keyed quickly from summary sheets, and it will faithfully report whatever the borrower certifies. A testing setup takes longer to gather, and in return it can find the certificate that says 1.31x when the agreement, read with its amendment, says 1.23x. Setup for either has three parts: gathering the documents, loading the obligations into a calendar, and writing the bank's credit policy down as settings.
What documents do you need to set up covenant tracking?
You need eight things for each borrower and for the bank as a whole, and the first two decide most of what the tracking can find.
The intake list for covenant tracking
- Credit agreements, with every amendment in order
Executed copies with dates. Include consents and executed waivers, so the file is complete; only amendments change the test going forward.
- The last four compliance certificates for each borrower
With the statements delivered alongside them. They show how each borrower calculates, and give the trend.
- The latest audited statements
Trailing twelve months start from the last audited year.
- Borrowing base certificates, for asset-based lines
The monthly ones, with the advance rates the agreement sets.
- Your spreading template
The bank's own line definitions, so the spread matches what credit already uses.
- Your credit policy for covenants
Tight headroom, trend, difference to report, reminder schedule, when late is an exception, who confirms, who decides waivers, minimum waiver fee.
- Letter templates approved by legal
Reminder, reservation of rights and waiver letters.
- Who to contact
Each borrower's CFO and relationship manager, for requests and reminders.
Can covenant tracking software read amendments? Why they matter most
Yes, if it is given them, and amendments matter more than any other document because the covenant test is set by the agreement as it stands on the test date, which is rarely the agreement as signed. Each amendment can add a definition, move a limit, insert a step-down or change a cure right, usually by reference to clauses in the original rather than by restating them. A covenant tracking setup that loads the original agreement and misses one amendment will test the wrong covenant, confidently, every quarter. The software has to apply amendments in date order, let the latest text win and keep the superseded text cited, so an analyst can see what changed and when.
Amendments are also the documents most likely to be scattered. The original agreement usually sits in the loan system or the credit file. Amendments, consents and waiver letters may be in the relationship manager's email, the legal team's folder or the closing binder of a deal that has since been refinanced. Gathering them is the one intake step that cannot be automated, because the agent can only read what it is given.
Why each input changes the covenant test
Every amendment
The sample borrower's First Amendment added an add-back and capped it at 10%. Without the amendment, the re-test would not have the add-back at all; with it but without its cap, the re-test would agree with an incorrect certificate.
The last four certificates
Each shows how the borrower calculates. Four quarters of them let the bank see whether a difference is new this quarter or has been there all along.
The last audited year
Trailing twelve months are built from the audited year plus the year to date, less the same period last year. An interim-only spread drifts from the audit.
Your spreading template
The bank's own line definitions decide what counts as debt, capital expenditure or a distribution. The agents spread into it, not into a template of their own.
Your credit policy
Tight headroom, the trend rule, who confirms, who decides waivers. A different setting changes which borrowers the relationship managers hear about.
How do you load existing loans into covenant tracking? Four quarters of history
Most financial covenants are tested on the trailing four quarters, so a single quarter's certificate is not enough to rebuild the test. The financial spreader builds the trailing twelve months the way an analyst would: the last audited year, plus the year to date, less the same period of the prior year. On the sample borrower that meant the 2025 audited statements, nine months of 2026 and nine months of 2025, tied to the statements to the dollar.
The last four certificates also carry information no statement does: the borrower's own method. Comparing the bank's re-test with each of them shows whether a difference is new or has been there since the definition changed. Lian and Ma note that agreements may compute EBITDA under accounting rules fixed at closing or under current rules, and that the latter, "floating GAAP", is common (Lian and Ma, NBER). A borrower that changes an accounting policy can move its covenants without any change in the business. Four quarters of certificates make that visible.
The Federal Reserve expects the statement requirements to be in policy, not invented per loan: "The lending policy also should define the financial-statement requirements for businesses and individuals at various borrowing levels. Specifically, requirements for audited, unaudited, annual, or interim balance sheets; income and cash-flow statements" (CBEM §2010.1). The set-up should load those requirements as they apply to each borrower, so the reporting calendar asks for the right package.
The inputs, where they usually live, and what is lost without them
| Input | Where it usually lives | What the agents do with it | Without it |
|---|---|---|---|
| Credit agreement and amendments | Loan system, credit file, legal, relationship manager's email | Read into a covenant register with section and page | The wrong definitions are tested, with no sign that they are wrong |
| Compliance certificates | Email, borrower portal, credit file | Compared line by line with the re-test | No way to see where the borrower and the bank differ |
| Interim and audited statements | Email, portal, spreading system | Spread into your template; trailing twelve months built | Nothing to re-test from; the certified figure is all there is |
| Borrowing base certificates | Collateral or asset-based lending team | Logged against the monthly calendar | Stale borrowing base reports go unnoticed |
| Reporting dates | The agreements, a tickler or spreadsheet | A reporting calendar with requests and reminders | Late certificates found when someone looks |
| Credit policy and templates | Credit policy manual, legal | Settings and letters | Defaults that may not match how your bank decides |
What is a borrowing base certificate, and what else should be tracked?
A borrowing base certificate is the borrower's periodic statement, usually monthly, of the receivables and inventory that secure an asset-based revolver, after the agreement's eligibility rules and advance rates, which sets how much it may borrow. Financial covenants are only part of what a borrower owes. Asset-based revolvers add these monthly certificates, and every agreement carries reporting, insurance and notice covenants. The OCC's examiner job aid grades reporting requirements by how often they let the lender watch the credit: conservative structures include "regularly required borrower certificates of compliance, financial statements, borrowing base certificates", while liberal ones show "infrequent" ones (OCC, Lending and Loan Portfolio Risk Management). Its exception table lists "Stale financial statements, tax returns, or borrowing base certificates" as credit administration exceptions.
At the fictional sample bank, 38 borrowing base certificates fall due monthly, the next on Friday 20 November, alongside 12 monthly statement packages and 168 quarterly certificates. Six non-financial covenant exceptions were open in the third quarter, among them an expired property insurance policy. Loading those obligations at set-up means the calendar carries them all, not only the quarterly test.
One borrower, with its documents and timeline in one place
How long does covenant tracking software take to implement? Start on a sample
Implementation time is set by document gathering, not by the software: reading is fast, at 153 pages in 21 seconds on the sample borrower, while finding every executed amendment can take weeks in a bank whose files are scattered. That is why the sensible order is a sample first. A bank does not need the whole book loaded to learn whether covenant tracking works on its files. A sample of borrowers chosen for difficulty shows more in a week than the whole book loaded carelessly. The comparison below is how we would stage it.
Starting on a sample, then loading the book
Minimum to start, on a sample: A sample that includes borrowers with amendments, recent breaches, waivers and tight headroom.
Full set-up, the whole book: Every borrower with financial or reporting covenants.
Minimum to start, on a sample: Each sample borrower's agreement and every amendment.
Full set-up, the whole book: The same for every borrower, with a routine for new amendments as they are signed.
Minimum to start, on a sample: The last four certificates and the statements behind them.
Full set-up, the whole book: Eight quarters where available, for trends and a back-test.
Minimum to start, on a sample: Your tight-headroom threshold, trend rule and approvers; the solution's defaults for the rest.
Full set-up, the whole book: Every setting reviewed by credit administration and the chief credit officer.
Minimum to start, on a sample: Your reservation-of-rights template.
Full set-up, the whole book: All reminder, reservation-of-rights and waiver templates, approved by legal.
Minimum to start, on a sample: Documents as files.
Full set-up, the whole book: Your borrower portal and email for requests, reminders and arrivals; your spreading template.
The sample stage doubles as the accuracy test. Re-testing the sample's past quarters, and reading every disagreement, is how a bank finds out whether the agents read its agreements correctly, and whether its own past tests did; re-testing eight quarters of certificates sets out the method.
Covenant tracking in Excel vs software: what moves out of the workbook
Excel can track covenants; what it cannot do is keep the definitions current, prove when a test was run, or chase a borrower. Most covenant desks start from a workbook per borrower or one book-wide tracker, and the weaknesses are structural rather than a matter of care.
The first is the definition. A workbook encodes the agreement as it was understood when the workbook was built; an amendment changes the bank's test only when someone opens the file and rebuilds the formula, and nothing in the spreadsheet says whether that happened. The second is evidence. A cell holds a ratio but not where it came from, who checked it or when, which is what an examiner sampling the covenant tracking report will ask. The third is time. In the sample bank's by-hand year, the median certificate waited 19 days to be tested, because every package had to be keyed before any covenant could be recalculated.
What should move to software is the calendar, the reading of the agreement, the spread, the recalculation and the exception queue. What should stay with people is everything that is a judgment: confirming a breach, granting an extension, deciding a waiver. A workbook may still be the right tool for a book of a dozen covenant borrowers; past that, the question is how many of the bank's tests are really the borrower's certified figures typed in.
Your credit policy, loaded as settings
The last input is the bank's judgment, written down. Covenant Monitoring treats the credit policy as settings rather than code: how tight is tight headroom, how many quarters make a trend, how large a difference from the certificate to report, the reminder schedule, when a late certificate becomes an exception, who confirms a result, who decides waivers, amendments and ratings of 6 or worse, and the minimum waiver fee. One setting is fixed by policy: covenants are always tested under the agreement's own definitions, latest amendment first.
The credit policy, as settings on the audit trail
Setting them is a conversation between credit administration and the chief credit officer, and it is the right moment to write down choices that by hand were habits. How close to the limit is too close covers the headroom and trend settings, and the waiver policy covers who decides and what a waiver must record. To run Covenant Monitoring on a sample of your own agreements and certificates, start from the solution page.
Questions people ask
What are the requirements for covenant tracking software?
At minimum: a register of every covenant and reporting obligation, each cited to the agreement; a calendar with reminders and a late list; recalculation of financial covenants from the statements; headroom and trend; an exception queue with owners and stages; and versioned settings with an audit trail. Ask also who confirms results, and whether the bank can test it on its own closed quarters first.
Do we need to replace our spreading system or loan system?
No. The agents spread into the bank's own template and work from the documents and systems it already uses, such as the borrower portal and email for requests and arrivals. What changes is that the test is rebuilt from the documents each quarter rather than carried in a workbook.
Who should own covenant tracking setup at a bank?
Credit administration, with the chief credit officer signing off the settings and legal approving the letter templates. Relationship managers help most with the hardest step, finding executed amendments and waiver letters that never reached the credit file.
Should waivers and consents be loaded, or only amendments?
All of them, so the file is complete and the history is visible, but only amendments change the covenant test going forward. A waiver excuses one breach for one period; the next quarter is tested at the original level unless an amendment says otherwise.
What happens to new amendments after go-live?
They need a routine: every executed amendment goes to the system before the next test date, and the register is rebuilt with the new text winning and the old text still cited. The most common failure after setup is an amendment signed in the relationship team that never reaches the covenant desk.