Covenant Monitoring Software: What to Look For

Covenant monitoring software keeps a record of every covenant on every loan, collects the information needed to test it, runs the test and tells the right person when a result is weak, late or in breach. It is used by credit teams at banks, credit unions and commercial lenders, and by private credit and direct lending funds that hold loans with detailed credit agreements.

The job sounds simple, but it has many moving parts. Each agreement defines its ratios a little differently. Borrowers send compliance certificates late or in different formats. Required levels change over time through step-downs and amendments. Good software holds all of this in one place, so the answer to "is this borrower in compliance, and by how much?" does not depend on one analyst's spreadsheet.

A spreadsheet and a tickler list can work for a small book of simple loans. They start to fail as the portfolio grows or the agreements get more detailed. The usual signs are missed test dates, numbers nobody can trace, and a covenant report that takes days to build before every credit committee meeting.

Start with the covenant record, not the dashboard. Automation only works when every facility has a clean record of each covenant: the definition, the required level, the test frequency, the statements the test uses and the reporting due dates. Many teams find that building this record from the signed agreements is the hardest part of the project, and the most useful.

Once the record exists, automate in the order the work happens. First the calendar: reminders to the borrower and the relationship manager before and after each due date. Then intake: a single place where certificates and financial statements arrive. Then the test: recalculating each ratio from the borrower's figures using the agreement's definitions. Then the result: headroom, trend and alerts, shown by borrower and across the portfolio. Decisions about what to do with a weak result stay with people throughout.

It also helps to begin with one group of loans, such as the largest relationships or the loans tested quarterly, and prove that the numbers match what your analysts calculate by hand before you add the rest of the book.

Whether you buy one product or connect several, covenant monitoring usually has the same layers. When you compare options, ask which layers the product covers itself and which it expects you to supply. A tool that is strong on dashboards but has no way to bring in loan data from your core system will leave your team keying balances by hand.

Certificates are where most manual effort goes, so look closely at this part. The first task is collection: the system should know which certificate is due from which borrower on which date, send reminders, record when it arrived and flag the ones that are late. Late or missing reporting is a breach in its own right and is worth tracking as carefully as the ratios.

The second task is extraction. Software that reads a certificate or a set of financial statements and pulls the figures into a structured form replaces the step where an analyst retypes numbers into Excel. Look for a page reference on each figure and a clear step where an analyst confirms the figures before they are used.

The third task is the cross-check. The borrower's certificate shows the borrower's own calculation. Good software recalculates each ratio from the underlying statements using the definitions in the credit agreement, then compares its result with the certificate. A difference does not always mean the borrower is wrong, but it should be shown and explained. Ask the vendor how the agreement's definitions are stored, how an add-back or carve-out specific to one deal is handled, and what happens when the two numbers do not match.

Pass or fail is not enough. For each covenant the software should show the required level, the latest actual result, the headroom between them and how that headroom has moved over the last several test dates. A borrower that passes with headroom shrinking for three periods in a row deserves a call before the fourth.

At the portfolio level, you should be able to ask simple questions and get an answer without building a report. Which deals are within 10% of a breach? Which borrowers have lost the most headroom since last year? Which certificates are overdue? How much exposure sits behind thin headroom, by officer, industry or risk grade? This is what people usually mean by an early warning dashboard: a ranked list that tells the team where to look first.

Check how headroom is defined, because products differ. Some show it as a percentage of the required level, some as a dollar cushion of EBITDA or cash flow, and the better ones show both. Also ask whether the system can estimate headroom between test dates from interim statements, since a year-end test alone can be many months old.

Covenants change over the life of a loan, and the software has to keep up without losing history. When an amendment resets a covenant level or changes a definition, the system should add a new version of the terms with an effective date and keep the original record. Past test periods should still show the terms that applied at the time, and the amendment document should be attached. Overwriting the old level is the most common weakness to look for.

Step-downs are scheduled changes written into the original agreement, such as a maximum leverage ratio that tightens each year. They should be stored as a schedule of required levels by test date, so each test uses the right level and the team can see ahead of time how a coming step-down will reduce headroom.

Restricted payment baskets are more common in larger, syndicated and private credit deals. A basket is an allowance, either a fixed dollar amount or a formula that grows with earnings, for things like distributions, investments or additional debt. Tracking one means keeping a running ledger of how much of the basket has been used since closing and how much is left. If your agreements contain baskets, ask to see exactly how the product records each use and what evidence it keeps.

AI is useful for the reading and arithmetic parts of covenant work. It can read a credit agreement and pull out the covenants, definitions and due dates as a draft record. It can read a compliance certificate or a set of financial statements and extract the figures. It can recalculate the ratios and point out where its result differs from the borrower's. These are slow tasks when done by hand, and they are the ones where automation saves the most time.

Some things should stay with people. Whether to waive a breach, amend a covenant, change a risk grade or move a borrower to the watch list are credit decisions with consequences for the borrower and the institution. Software can prepare the facts and route the request to the person with authority. It should not make the call.

Reliability comes down to whether you can check the output. Every figure should link to the page of the document it came from. Every extracted covenant term should be confirmed by a person before it is used for testing. Every calculation should show its inputs. If a product gives you a ratio with no way to trace it back to the source, treat that as a reason for caution, however good the demonstration looks.

Covenant monitoring produces a record that loan review, auditors and examiners will read. The software should keep, for every test, the figures used, where they came from, the definition applied, the result and who confirmed it. For every breach it should keep the cause, the decision taken, who approved it, the date and any conditions, with the waiver or amendment letter attached.

Reporting should come from the same record. Typical reports are a covenant compliance summary for credit committee, a list of breaches and waivers for the period, overdue reporting by officer, and a headroom ranking for portfolio review. If producing any of these means exporting to a spreadsheet and reformatting it, some of the manual work has only been moved, not removed.

Pricing models vary, and vendors do not always publish them. The common structures are a charge per facility or per borrower monitored, a flat platform fee that covers a band of portfolio size, a charge per user, or a mix of these. Some products charge separately for document reading, since that part costs more to run.

Ask about the costs that sit outside the license. Building the covenant records from your existing agreements, connecting to your core system, training and ongoing support can all be priced separately. Ask what happens to the price as your portfolio grows, and whether you can start with one part of the book before committing to all of it.

Use the list below when you compare products. The most useful test is to give each vendor two or three of your own agreements, including one with an amendment, along with the matching certificates, and see what comes back. A demonstration on the vendor's sample data shows the screens. A trial on your documents shows whether the numbers are right.

Aarvion Risk OS Commercial Credit tests every covenant on every facility and shows the required level, last actual, headroom and trend. It tracks breaches, waivers, compliance certificates and reporting ticklers. Facility, payment and past-due data comes from the bank's core system, and covenant results feed portfolio monitoring, annual review drafts and risk grade staleness.

AI spreads financial statements and drafts memos with figures traceable to source documents. Every AI action is checked against the bank's own credit rules, which can allow it, hold it for the right signer, block it or stop all activity, and it is recorded with who proposed it, which rule applied, who approved it and when. Decisions such as waive, amend, approve and grade stay with the bank's people. Customers start with a 90-day pilot on one workflow.