Loan Covenant and Financial Spreading Software: Why the Tickler Nobody Owns Costs You the Workout

Why covenant monitoring breaks the credit systems you already own

The loss you can prevent is the one you see in quarter two rather than quarter four. A manufacturer's fixed charge coverage slips below the covenant on the June statements. If you know in August, you sit down with the sponsor while there is still inventory, a receivable base and goodwill to work with. If you find out at the annual review in February, the equipment is already gone, the line is fully drawn and you are negotiating from behind.

Here is how the delay actually happens, and it is never dramatic. The borrower is required to deliver quarterly statements within 45 days. They send them at 70 days, as a PDF, to the relationship manager's inbox. He is busy, forwards it three weeks later. The analyst spreads it into the template, which takes an hour and a half because the borrower changed its chart of accounts. She tests the covenant against the definition, except the definition of adjusted EBITDA in this particular credit agreement adds back non recurring restructuring charges up to a cap and excludes a specific joint venture, which is written in a Word document in the loan file and not in the system. She calculates it the standard way, it passes, and nobody knows until the workout team reads the agreement properly a year later.

Across credit operations work we have delivered, the same three failures repeat. Statements arriving late with no consequence attached. Covenants tested against a generic ratio rather than the negotiated definition. And a tickler spreadsheet that was accurate on the day it was built and has been drifting ever since, because nobody owns it and everyone assumes someone does.

Problem 1: spreading is data entry that decides your risk rating

Spreading is the unglamorous heart of commercial credit. A borrower's financials arrive in whatever form their accountant produces, and an analyst normalises them into your standard template so that a ratio computed in one credit means the same thing as a ratio computed in another. When it is done well, the portfolio is comparable. When it drifts, your risk ratings are noise.

The drift is structural. Two analysts map the same line differently. One treats an owner distribution as a fixed charge, one does not. Personal tax returns for a guarantor get spread by whoever is free, using different conventions for K-1 income. Nothing catches it because there is no rule, only a habit.

What a build must include is the mapping as governed configuration rather than analyst judgement. A chart of accounts crosswalk per borrower, retained between periods, so the second spread of the same company is fast and consistent. Rules for the treatments your credit policy specifies, applied automatically with an override that requires a note. Document extraction does real work here, since financial statements, tax returns and their standard schedules are structured enough for a model to populate a draft spread that an analyst corrects. Expect a review step rather than full automation, and expect the correction rate to fall sharply for repeat borrowers. The value is not that it saves 40 minutes. It is that the same company spread twice produces the same numbers.

Problem 2: the covenant is prose, and a picklist cannot hold it

This is where packaged covenant modules quietly fail. They offer a library: leverage ratio, fixed charge coverage, tangible net worth, debt service coverage. You choose one, enter a threshold and a test frequency, and the system tests it. That works for a small business credit on your standard paper.

It does not work for negotiated deals, because the definitions are negotiated. Adjusted EBITDA in one agreement adds back stock compensation and one time integration costs capped at 10 percent of the base. In another it excludes an unconsolidated affiliate and includes pro forma effect of an acquisition. Fixed charges may or may not include distributions, capital lease payments, or the current portion of long term debt as defined in that agreement rather than as your template computes it. Equity cure rights can retroactively fix a breach if the sponsor injects capital within a set window. Step downs change the threshold every four quarters.

Moody's Analytics CreditLens, Abrigo, nCino and Baker Hill NextGen all track covenants competently against standard definitions, and for a community bank book of standard paper that is genuinely sufficient. The gap is expressiveness. A build lets a credit administrator author the definition as a formula referencing spread line items, with the add backs, caps, exclusions and step down schedule for that deal, and it stores the agreement section reference alongside so the test can be defended. Then the tested ratio matches the ratio your borrower's counsel would compute, which is the only ratio that matters when you send a notice.

Problem 3: the tickler nobody owns

Every credit carries reporting obligations distinct from its financial covenants: annual audited statements within 120 days, quarterly internal statements within 45, monthly borrowing base certificates, annual personal financial statements and tax returns from each guarantor, insurance certificates, compliance certificates signed by the chief financial officer. Multiply by a few hundred credits and several guarantors each, and you have thousands of dated obligations.

They live in a spreadsheet. The spreadsheet was right once. Then a loan modified, a guarantor was released, a new facility was added and nobody updated the tab. Examiners find this reliably, because it is the easiest thing in a credit file to test.

What a build should include is obligations generated from the credit structure rather than typed, so adding a facility creates its reporting requirements automatically and releasing a guarantor removes theirs. Requests go to the borrower ahead of the due date through a portal or email, with the specific document named. Receipt is recorded when the document arrives, not when someone gets to it. Escalation runs on your policy: relationship manager at seven days late, credit officer at 30, and a technical default consideration at the point your agreement specifies. The value is not the reminder. It is that late delivery becomes visible as a pattern, and a borrower who has been 60 days late four quarters running is telling you something long before the numbers do.

Problem 4: a breach is a workflow, not a flag

When a covenant fails, what happens next has legal consequences and most systems stop at a red icon. In reality a breach starts a sequence: verification that the calculation is right, a decision on whether to send a reservation of rights letter to preserve remedies, a credit officer assessment, a possible waiver or amendment with pricing, a risk rating review, and often a change in accrual status or classification that flows into regulatory reporting.

Each of those steps has an owner, a deadline and a document. Handled by email, they leave no coherent record, which matters twice: when the credit deteriorates and your remedies depend on what you preserved, and when an examiner asks how the bank responded to identified weaknesses.

A build should model the breach as a case with the calculation snapshot attached, the agreement section cited, the decision path recorded with approvals at the authority level your policy requires, generated correspondence from your own templates, and the resulting risk rating change linked back to the trigger. Waivers get expiry dates and conditions, so a covenant waived for two quarters returns to testing automatically rather than being quietly forgotten. That last detail sounds small and is one of the more common ways banks lose the protection they negotiated.

Problem 5: the portfolio view you cannot currently produce

Once spreads and covenants are structured data rather than documents, questions your credit committee has always wanted to ask become answerable in seconds. Which credits have leverage above four times and declining coverage for two consecutive quarters. What is the aggregate exposure to borrowers whose largest customer is a single retailer. How many credits in a given industry are relying on an equity cure. Which relationship managers carry the most consistently late reporters.

This is also where early warning stops being a slogan. The strongest predictors in a commercial book are usually behavioural rather than analytical: reporting delays lengthening, deposit balances falling, line utilisation creeping toward the cap, borrowing base ineligibles rising. Those signals exist in your core system and your credit file, and they are almost never joined. A build that joins them gives you a watchlist that populates itself rather than a watchlist assembled by asking relationship managers what worries them, which is a survey of optimism.

We would not build a predictive model on day one. Get the structured history first. Two years of clean spread data plus behavioural signals makes a rating migration model worth having. Before that, a model is a chart with confidence it has not earned.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A focused first release covering document intake, spreading with your templates and account crosswalks, deal specific covenant definitions with automated testing, and the reporting obligation tickler runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding a borrower portal, borrowing base certificate processing, global cash flow with guarantors and related entities, breach and waiver workflow with generated correspondence, risk rating migration and portfolio early warning runs $180,000 to $450,000 phased over 7 to 12 months.

What drives cost up specifically in credit portfolio work: the number of distinct spreading templates, since commercial and industrial, commercial real estate, agriculture and not for profit borrowers each need their own. Core system integration for balances, utilisation and deposit behaviour, which is where the early warning value sits and where every core is different. Borrowing base certificates, because ineligibility rules are per deal and the arithmetic is unforgiving. Regulatory reporting linkage, if classification and accrual status must flow to call report preparation. And the number of legal entities in your typical borrowing group, because global cash flow across ten related entities is a materially harder model than a single operating company.

What keeps cost down: starting with your commercial and industrial book, one template family, and the covenant definitions from your 50 largest exposures. That population teaches the system almost everything it needs.

Build versus buy, and when buying is the right call

Buy if your book is mostly standard paper with standard covenants, under roughly 150 covenanted credits, and your growth plan does not change that. Abrigo and Baker Hill NextGen are built for exactly that institution, they carry regulatory reporting alignment you would otherwise construct, and a custom build would be a slower route to a worse outcome. If you already run nCino as your lending platform and your covenants are conventional, use what you have before commissioning anything.

Build when two or more of these are true. Your covenant definitions are negotiated per deal and a picklist cannot express them, which is normal in private credit and in any bank doing sponsor backed or larger middle market lending. Your borrowing groups involve multiple entities and guarantors so global cash flow is the real analysis. You need behavioural early warning joining credit data to core banking activity. You are a private credit fund with limited partner reporting obligations that no bank product addresses. Or your credit policy has enough institution specific rules that you are already maintaining a shadow spreadsheet next to the vendor system, which is the clearest signal of all.

The tipping point is definitional complexity, not portfolio size. A thousand small business credits on your own standard covenants are a buying problem. Two hundred negotiated middle market deals are a building problem, because the thing you are monitoring is the agreement, and the agreements are all different.

How to choose a developer

Ask them how a credit administrator would express an adjusted EBITDA definition with a capped add back and a step down schedule, without a developer. If the answer is a configuration screen where formulas reference spread line items and the agreement section is cited alongside, they understand the domain. If the answer is a support ticket, you have bought the constraint you were trying to escape.

Ask what happens when a borrower changes its chart of accounts between periods. A good answer describes a persistent crosswalk per borrower and a review step that shows what moved. A weak answer treats every spread as a fresh mapping exercise, which is how comparability dies.

Ask what they have integrated with by name. Pulling balances, utilisation and deposit behaviour from your specific core is where early warning lives, and that is a different effort for every core platform. Vague claims about integrations hide the real weeks.

Ask how waivers expire. It is a two minute question that reveals whether they have thought about the lifecycle or only the alert. A waiver without an expiry and conditions is a permanent hole in your covenant package.

Ask who owns the code and settle it before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, and for a regulated lender that also answers the vendor concentration question an examiner will eventually ask.