AI you can defend to an auditor - Auditable covenant math, not just auditable data

AI you can defend to an auditor - Auditable covenant math, not just auditable data
TLDR

• "Auditable data" in credit means two things. Where the number came from, and how it was calculated. Most platforms only prove the first.

• A covenant ratio cannot be defended to a credit committee or LP unless you can trace the formula, the add-backs, and the source cells, not just the underlying document.

• Chronograph, Cobalt, and 73 Strings all stop at source-document linkage. None publicly addresses formula-layer transparency for FCCR, leverage ratios, or borrowing base availability.

• Lumonic's Lx language encodes the credit math itself, so every covenant calculation stays inspectable from the result back to the formula back to the source cell.

When an LP Asks Why a Covenant Is Passing

A credit committee member looks at your quarterly report and sees the fixed charge coverage ratio listed as 1.35x against a 1.25x covenant. The covenant passes. Then the LP on the committee asks a sharper question. Not "where did this EBITDA come from?" but "how was the management add-back cap applied to get to that 1.35x, and which lease treatment did you use in the denominator?"

Most monitoring platforms can answer the first question and stall on the second. Click the EBITDA figure and the platform shows you the compliance certificate it was pulled from. That trace ends at the source document. It tells you the input existed somewhere in a PDF, but it says nothing about how the inputs were assembled into the ratio.

The gap is the calculation itself. A passing FCCR depends on which add-backs were allowed, whether the add-back cap was enforced at the contractual percentage, and whether operating leases were capitalized under one accounting standard or expensed under another. Each choice moves the ratio. When the formula lives in an analyst's spreadsheet or buried in a platform's hidden logic, no one in the room can verify that the 1.35x reflects the credit agreement rather than an undocumented assumption.

Defensible covenant reporting requires two layers, not one. The first layer is data provenance, meaning every input traces back to a named cell in a source document. The second layer is calculation traceability, meaning the formula that turned those inputs into 1.35x is itself inspectable, with the add-back caps, lease treatment, and netting parameters visible as written in the agreement. Source-document linkage delivers the first layer. The rest of this page argues that credit work demands both.

What "Auditable" Actually Means in a Credit Context

A covenant ratio is auditable only when you can follow it from the result back to the formula, from the formula to each input, and from each input to the cell in the source document where it came from. Source-document linkage covers the last step. It tells you the EBITDA figure on the screen matches the figure in the compliance certificate. It says nothing about the three transformations that happen before that figure becomes a passing or failing ratio.

The transformations are where credit math gets contentious, because the same label means different things across credit agreements. Fixed charge coverage has no single definition. One agreement counts maintenance capex in fixed charges, another counts all capex, and a third nets cash interest against interest income before the ratio runs. EBITDA add-backs are capped at negotiated levels, and a borrower who reports $4M in synergy add-backs against a $2.5M cap should see the excess struck before the leverage ratio calculates. Lease treatment diverges between GAAP and IFRS, which changes whether operating leases sit above or below the EBITDA line and shifts both the numerator and the denominator. Cash netting in a borrowing base depends on which accounts qualify and whether restricted cash counts.

None of these choices is visible in a source document. They live in the formula, and the formula is auditable only when it is encoded and inspectable rather than buried in an analyst's spreadsheet or implied by a number on a dashboard.

The operational pressure comes from the compliance certificate cycle. Most credit agreements require quarterly covenant testing with delivery 45 to 60 days after period close. Inside that window you ingest the certificate, parse the borrower's reported figures, apply the add-back caps and definitional choices from the agreement, run each ratio, and confirm the result before it reaches the credit committee or an LP. When a covenant shows as passing and someone asks why, the answer has to survive scrutiny on a deadline. A traceability gap at the formula layer becomes material exactly here, because the figure checks out against the document while the calculation behind it remains unexplained.

Where the "Auditable Data" Pitch Stops Short

Chronograph's auditability claim is real, and it stops at the document. Click a metric on its private credit page and you see the borrower report it came from. One Chronograph customer describes exactly this: "click on any metric in Chronograph and instantly access its location in the corresponding source report." That answers where the number lives. It does not answer how an FCCR was calculated, which add-backs were applied to reach Adjusted EBITDA, or how borrowing base availability was derived. Chronograph's own private credit page promises to validate add-backs "against negotiated caps," but its public language describes audit trails over source, edits, and version history, never the formula that produced the ratio.

Cobalt landed in the same place more recently. FactSet's AI Doc Ingest beta, announced February 4, 2026, promises that "all extracted data is instantly traceable back to its source document through audit trails." Investment teams view extracted metrics side by side with the underlying file. That is the same source-linkage layer as Chronograph. FactSet's separate Model Context Protocol expansion describes "pre-calculated analytics" delivered through AI, but pre-calculated outputs are governed, not inspectable. You can see the result and the document. The calculation in between stays closed.

73 Strings carries a different limitation. Its audit trail grew out of equity valuation work, where the auditable object is a fair-value mark, not a covenant ratio. An add-back cap or a lease-treatment choice inside an FCCR is a different kind of math than a discounted cash flow model, and a trail built for the latter does not expose the former. The provenance is there for valuations. The credit-math formula layer is not the thing being traced.

iLEVEL sits at the floor. As a template-based platform with no extraction, its audit trail records who typed a number in and when, which is database logging, not source-document linkage. Covenant ratios get calculated outside the system, usually in Excel, so the formula never enters the platform to be audited at all. An MCP interface on top would surface manually entered figures, leaving the calculation gap exactly where it was.

Across all four, the auditable object is the same. It is the number and its document. None publicly claims the formula, the inputs, and the source cell as a single traceable chain.

What Full Covenant Auditability Requires

A covenant ratio is genuinely auditable when five things hold, and most platforms satisfy one or two of them. Use these as a buyer's checklist when you evaluate any monitoring platform, not as a list of features any single vendor happens to ship.

First, the formula definition has to be encoded and inspectable rather than implicit. If FCCR is a black-box ratio that produces a number, you cannot defend it. You need to read the actual calculation, including which line items it sums and where it caps them.

Second, every input in that formula has to point back to a source cell. A number that traces to a document is a start, but a number that traces to a named cell in the compliance certificate is the standard. The difference matters when a credit committee asks which EBITDA line fed the leverage test.

Third, the add-back methodology has to be versioned against the credit agreement. Add-back caps change as agreements get amended, and a platform that runs last year's cap on this year's figures will show a passing covenant that should fail. You want a record of which version of the methodology produced each result.

Fourth, covenant threshold step-downs have to be tracked. Leverage covenants commonly step down over the life of a facility, and a platform that tests against a stale threshold misreports compliance. The threshold in force on the test date is the one the calculation must use.

Fifth, the whole chain has to be navigable inside one platform. The moment you export to Excel to verify a number, you have left the audit trail and created a copy nobody can trace.

One requirement sits upstream of all five. The platform has to ingest compliance certificates and extract the covenant definitions from them, not just test ratios downstream of definitions an analyst typed in by hand. If the definition itself was never captured from the source, every layer built on top of it inherits the gap.

How Lumonic's Lx Delivers the Formula Layer

Lx is the language Lumonic uses to encode a covenant's actual formula, the one written into a specific credit agreement, rather than a generic ratio template applied across every borrower. When a credit agreement caps cost add-backs at 15 percent of EBITDA, treats certain leases as operating expense, and nets only unrestricted cash against debt, Lx runs that exact definition. The FCCR a credit committee sees is the FCCR the document defines, not an approximation built from a standard field set.

The difference shows up in the inputs. A generic template asks for EBITDA, adjustments, and fixed charges, then computes a ratio. Lx instead carries the borrower's own add-back caps, lease classification, and cash netting rules as part of the formula itself. Two borrowers with different agreements get two different formulas, and each formula reflects what that borrower's lender actually negotiated. The label FCCR stays the same. The math underneath does not, and Lx keeps that distinction explicit instead of hiding it inside a spreadsheet.

Source-cell traceability completes the chain. Every input that feeds an Lx formula points back to a named location in the source document, so the EBITDA figure links to the compliance certificate cell it came from, and the add-back amount links to the line item it was pulled from. Lumonic's private credit platform is built around this chain — full traceability to original files and underlying calculations, with the source always one click away. The trace covers the calculation, not just the document the number lives in.

That coverage is what answers the credit committee or LP question from the opening. When someone asks why a covenant is shown as passing, the analyst starts at the ratio result and walks backward through the formula Lx ran, into each input, and down to the source cell that supplied it. The add-back cap is visible. The lease treatment is visible. The cash netting definition is visible. None of it requires exporting to Excel or pulling up a separate model, because the formula and its inputs sit in the same platform as the result.

For a fund CFO defending a number to an auditor, that single chain is the whole point. An auditor asking how the 15 percent add-back cap was enforced gets to read the cap as Lx encoded it, then see the input it limited and the document cell that input came from. The answer is not a description of the calculation. It is the calculation, inspectable from result to formula to source, with each step accounting for the next.

No other platform in the market encodes the covenant formula at the borrower level and ties every input back to a source cell. That combination — agreement-specific math plus cell-level provenance, navigable in one platform — is what makes Lumonic's auditability claim qualitatively different from the source-linkage claims every other vendor makes.

Platform Comparison: Auditability in Credit Monitoring

Each platform on the market claims auditability, but the claim ends at different depths. The table below maps where each one stops, focusing only on whether a covenant calculation can be traced from result to formula to source cell.

Chronograph and Cobalt both stop at the same place. You can trace a number back to the document it came from, but not the formula that produced a covenant result. iLEVEL's audit trail is a spreadsheet-era concept, a log of manual entry rather than a calculation you can inspect. Lumonic is the only row where the formula itself is part of the traceable chain, which is what a credit committee actually interrogates when it asks why a covenant passes.

Who Should Demand Formula-Layer Auditability

Direct lenders running active covenant programs should treat formula-layer auditability as a baseline requirement. When you ingest compliance certificates every quarter and report covenant status to LPs, you will eventually field a question about why a ratio passed. Source-document linkage answers where the EBITDA came from. The credit committee wants to know how the add-back cap was applied, and that answer lives in the formula, not the document.

Fund CFOs and credit analysts feel this most acutely because the formula is what gets interrogated. An auditor or LP rarely disputes that a number appeared on page four of a borrower's certificate. They question the lease treatment in the FCCR or the cash netting in the leverage ratio. If your only trace stops at the source cell, you reconstruct the math by hand and hope it matches.

Private equity firms with portfolio companies carrying debt face this too, even when covenant monitoring is not their primary workflow. Most PE-owned companies operate under credit facilities with maintenance covenants, and when an LP or auditor asks how a portfolio company's leverage covenant was tested, the GP needs the same two-layer answer a direct lender does. Lumonic's private equity platform handles debt-compliance visibility for PE portfolios alongside the broader monitoring workflow, so the formula layer is available without standing up a separate credit system.

Managers graduating from spreadsheet-based covenant tracking carry the largest gap. The formula currently sits inside one analyst's Excel file, invisible to anyone who did not build it and unreviewable once that analyst leaves. Lumonic's Lx language moves that logic out of a private workbook and into an inspectable, versioned definition tied to the credit agreement. For an institutional manager defending numbers to a credit committee or an LP, that visibility is the requirement, not a convenience.

The Audit-Ready Credit Stack

Source-document linkage answers where a number came from. It cannot answer how that number was calculated, and a covenant ratio is the product of a formula, not a document. An auditable credit stack needs both layers. The source cell proves provenance, and the encoded formula proves the math.

Chronograph, Cobalt, and 73 Strings stop at the first layer. They link a metric to the report it came from, then leave the FCCR add-back caps, the lease treatment, and the borrowing base derivation outside the platform. Lumonic's Lx encodes the credit math itself, so every covenant calculation traces from result back to formula back to source cell without an export to Excel.

When a credit committee or an LP asks why a covenant is passing, you should be able to follow the full chain in one place. That is the standard. See how Lumonic encodes covenant definitions, or request a walkthrough of a specific ratio calculation against your own credit agreement.