Beyond the Spreadsheet: Building One Data Model Across Direct Lending,Asset-Based Finance, and Private Equity

Executive summary

Despite a decade of platform investment, the operational core of most credit managers is still a spreadsheet. Excel remains the system of record for portfolios, valuations, covenant tracking, and investor reporting at a remarkable share of firms — not because teams trust it, but because nothing else has matched its flexibility in modeling the bespoke, fast-changing instruments these strategies generate. The cost of that reliance is documented and severe. Decades of research summarized by Professor Raymond Panko find that roughly 88% of spreadsheets contain at least one error, and field audits put the figure higher still. The consequences are not hypothetical: a spreadsheet error cost JPMorgan $6.2 billion in the 2012 “London Whale” episode, a missing minus sign cost Fidelity $2.6 billion, and a spreadsheet mistake drove Fannie Mae’s $1.13 billion accounting restatement.

This problem is becoming structurally worse, because credit managers are no longer running one strategy. The same firm that built a direct lending book is now also running asset-based finance (ABF) and, increasingly, private equity sleeves under one roof. ABF alone has grown to roughly $6.1 trillion and is projected to exceed $9 trillion by 2029 — larger than the syndicated loan, high-yield, and direct lending markets combined — and the largest managers are all building multi-strategy platforms to capture it. Each of these strategies has a fundamentally different data shape. A spreadsheet built for one cannot represent the others, so multi-strategy firms accumulate parallel spreadsheet estates that never reconcile.

The technical question this paper addresses is precise: what does it actually take to build a single, unified data model that can represent direct lending, ABF, and private equity in one coherent structure — without flattening the differences that make each strategy distinct? The answer is not a bigger spreadsheet or a single screen. It is a canonical data model built on a shared spine of common entities — legal entity, instrument, position, cash flow, valuation, and time — extended with strategy-specific detail through a disciplined supertype-subtype design. This paper sets out that architecture, the modeling principles behind it, and the capabilities it unlocks.

1. Why credit still runs on excel — and what it costs

Excel earned its place. It is the most flexible data tool ever built for finance: a blank grid that imposes no schema, accepts any structure, and lets an analyst model a bespoke unitranche with a custom PIK toggle in an afternoon. For instruments that are negotiated one at a time and amended unpredictably, that flexibility is genuinely valuable — which is why, by various estimates, Excel sits on roughly 90% of finance desktops and remains the system of record for critical processes at a large share of credit managers.

But the property that makes Excel flexible — the absence of any enforced structure — is the same property that makes it unreliable at scale. There is no schema to validate against, no referential integrity, no separation between data and logic, and no audit trail of who changed what and when. The research on this is unusually consistent and unusually old, which is itself the point: the risk has been known for thirty years and remains unaddressed.

Table 1 — Spreadsheet risk is documented, quantified, and decades old. The flexibility that makes Excel useful is the same flexibility that makes it unauditable.

The deeper problem is structural rather than clerical. A spreadsheet conflates three things a real data system keeps separate: the data, the logic that operates on it, and the presentation of the result. When all three live in the same grid, every copy-paste propagates logic along with data, every new period spawns a new file, and the authoritative version of any number becomes a matter of folklore. A single analyst holds the model in their head; when they leave, the institutional knowledge leaves with them. None of this is a failure of discipline. It is the inevitable consequence of using a tool with no concept of a schema to do a job that requires one.

2. The multi-strategy convergence that breaks the model

For most of the last decade, a credit manager could survive on spreadsheets because it ran essentially one strategy. That assumption no longer holds. The defining structural shift in private markets is the convergence of strategies under single platforms — and it is precisely this convergence that makes the spreadsheet model untenable.

2.1 The rise of asset-based finance

The clearest driver is the explosive growth of asset-based finance. According to KKR, the private ABF market has roughly doubled since the financial crisis to more than $6.1 trillion and is projected to exceed $9 trillion by 2029 — a market larger than the syndicated loan, high-yield bond, and direct lending markets combined. Private credit funds today supply less than 5% of that financing, leaving an enormous runway. The largest managers have responded by building dedicated ABF capability alongside their direct lending and private equity businesses: KKR, Apollo, Carlyle, Blackstone, and Sixth Street have all launched or scaled ABF strategies, frequently through multi-billion-dollar portfolio acquisitions from retreating banks.

The result is that the modern credit platform is multi-strategy by default. A single firm now routinely runs corporate direct lending, asset-based finance, and private equity or equity co-investment sleeves — three businesses with three fundamentally different data shapes, sharing capital, LPs, and increasingly the same borrowers viewed from different angles.

2.2 Why convergence multiplies the spreadsheet problem

A spreadsheet is built for a specific instrument shape. The direct lending model assumes one borrower, one facility, a covenant package, and an amortization schedule. It cannot represent a pool of fifty thousand auto loans with a borrowing base and advance rates, nor a cap table with ownership percentages and a J-curve. So each strategy gets its own spreadsheet estate, built by a different team on different assumptions, and the firm-level view — total exposure to a borrower that appears as a corporate loan in one book and as pledged collateral in another — becomes impossible to assemble. The First Brands bankruptcy of 2025, in which the same receivables were reportedly pledged to multiple lenders, is the cautionary archetype: fragmented data across strategies hides concentration that a unified model would surface immediately.

3. Three strategies, three data shapes

Building one data model across direct lending, ABF, and private equity is hard for a specific, identifiable reason: the three strategies disagree about the most basic question a data model must answer — what is the atomic unit being tracked? Until that disagreement is resolved, no unified model is possible. The table below makes the divergence explicit.

Table 2 — The three strategies disagree on the atomic unit, the entity, the cash-flow shape, and the valuation basis. A spreadsheet built for one column cannot represent the others.

Two observations follow. First, the granularity gap alone defeats a spreadsheet: a direct lending book tracks tens of borrowers, while a single ABF pool may contain hundreds of thousands of obligors whose delinquency and prepayment behavior drive the position’s value. No grid models both. Second — and this is the key to the solution — beneath the divergence there is a shared skeleton. Every strategy ultimately involves a legal entity, an instrument or position, a stream of cash flows, a valuation at a point in time, and a fund that holds it. The differences are real but they are extensions of a common core, not separate universes. That insight is what makes a unified model possible.

4. The architecture of a unified data model

A unified data model does not erase the differences between strategies; it factors them. The design pattern is well established in data engineering — a canonical core of shared entities, extended through supertype-subtype (also called generalization-specialization) modeling, so that everything strategies have in common is represented once, and everything specific to a strategy is represented as a typed extension of the common structure.

4.1 The canonical core: A shared spine

At the center sits a small set of entities that every strategy shares. These are the load-bearing tables of the entire platform, and getting their definitions right is the single most important act of the design:

• Legal entity. The canonical record of any party — borrower, obligor, portfolio company, servicer, fund, counterparty — with one master identity that persists across every strategy and through corporate events (renaming, acquisition). This is what lets the platform see a single borrower across a direct loan and an ABF collateral pool simultaneously.
• Instrument / Position. The thing held — a loan, a tranche, a pool participation, an equity stake. Modeled as a supertype with strategy-specific subtypes, so a position carries common attributes (holder, fund, acquisition date, status) plus its typed detail.
• Cash flow. Every economic event — interest, amortization, PIK accrual, capital call, distribution, waterfall payment — as a typed, dated, signed record against a position. One table represents the wildly different cash-flow shapes of all three strategies.
• Valuation. A point-in-time mark on a position, with method and basis (ASC 326 impairment, ASC 820 fair value, pool performance) captured as attributes — so cross-strategy NAV is a query, not a reconciliation.
• Fund / Vehicle. The holding structure, enabling consolidation, look-through, and LP-level reporting across every strategy a fund touches.

4.2 Strategy extensions: Specialization without fragmentation

Each strategy then extends the core with its own typed detail, attached to the shared entities rather than living in a separate system. Direct lending adds covenant definitions, amortization schedules, and margin grids to the instrument subtype. ABF adds the pool-and-obligor hierarchy, borrowing-base components, advance rates, and eligibility rules — the one-to-many explosion from a single position to hundreds of thousands of underlying assets handled as a child relationship, not a separate database. Private equity adds the cap table, ownership percentages, and valuation multiples. Because each extension hangs off the same canonical entities, a query can move fluidly from the firm-wide view down to a single obligor in a single pool without crossing a system boundary.

4.3 Time as a first-class citizen: Bitemporal design

The final architectural requirement is the one spreadsheets handle worst: time. Investment data has two independent time dimensions — when something was true in the world (a valuation as of quarter-end) and when the system learned it (the mark booked three weeks later after a restatement). A bitemporal data model records both, which is what makes it possible to answer “what did we believe our NAV was on the reporting date, given only what we knew then?” — the question every audit, every ASC 820 review, and every regulatory filing ultimately asks. A spreadsheet overwrites; a bitemporal model remembers. This is the difference between data that is merely current and data that is investment-grade.

5. Design principles: What it takes to build it right

The architecture below is a target. Reaching it reliably depends on a handful of data-engineering disciplines that distinguish a durable model from one that quietly degrades into a structured version of the spreadsheet mess it replaced.

Table 3 — The engineering disciplines that separate a durable unified model from a structured spreadsheet.

A semantic layer sits above the canonical model to make it usable. This is where strategy-specific vocabulary is reconciled to shared meaning: “leverage” in direct lending, “advance rate cushion” in ABF, and “net debt / EBITDA” at a portfolio company are different computations that a well-designed semantic layer can expose through consistent, governed definitions. The semantic layer is what lets a single LP report draw a coherent NAV from three strategies whose underlying mechanics share nothing — without forcing the analyst to know which strategy each number came from.

6. What a unified model makes possible

The return on a unified data model is not a tidier database; it is a set of capabilities that are simply unavailable when each strategy lives in its own spreadsheet. Each follows directly from the canonical core.

6.1 Cross-strategy look-through and concentration risk

When every party resolves to one master legal entity, the platform can answer the question that fragmented data cannot: what is our total exposure to this borrower, across every strategy and every fund? A corporate that appears as a direct loan, as an obligor inside an ABF pool, and as a supplier to a portfolio company is one entity in the model — so concentration that would otherwise hide across three books surfaces in a single query. In a market where the First Brands episode showed the cost of undetected cross-collateral exposure, this is not a reporting nicety; it is risk management.

6.2 Consolidated, on-demand reporting

Because valuation and cash flow are canonical, fund-level and LP-level NAV become a query against governed data rather than a quarter-end reconciliation across spreadsheet estates. A multi-strategy fund that holds direct loans, ABF participations, and equity stakes can produce a single coherent capital account because all three are valued and recorded in the same structure, with the same point-in-time discipline.

6.3 The precondition for trustworthy AI

Every credit manager now wants AI on its portfolio. But a model trained or prompted on inconsistent, ungoverned spreadsheet data inherits that inconsistency and produces confident, unverifiable output. A unified data model with lineage and bitemporal history is the substrate that makes AI defensible: the model reasons from a single source of truth where every figure traces to its origin and every historical state is preserved. The unified data model is not a competing priority to an AI strategy — it is the precondition for one.

7. Implementation considerations

For the operations and technology leaders who own this decision, a unified data model is a multi-year asset, and a few principles separate the builds that endure from those that ossify.

7.1 Model the core before the edges

The temptation is to start with the most complex strategy and its richest detail. The discipline is the opposite: define the canonical core — legal entity, instrument, position, cash flow, valuation, fund — and its identity rules first, because every strategy extension depends on them. A core defined loosely will not hold the weight of three strategies; a core defined well will absorb a fourth and fifth strategy without redesign.

7.2 Migrate strategy by strategy, not all at once

A unified model does not require migrating every strategy on day one. The durable pattern is to stand up the canonical core, migrate the highest-friction strategy first — often direct lending, where covenant monitoring is most time-sensitive — prove the model, then extend to ABF and private equity. This sequencing turns a multi-year program into a series of provable milestones, and avoids the enterprise-wide overhaul that so often stalls under its own weight.

7.3 Integrate sources rather than replace them

The unified model is the canonical layer; it does not require ripping out fund administrators, market data feeds, or document systems. Those remain as sources, connected through interfaces that map their data into the canonical structure. The objective is a single governed model of the truth, not a single application that does everything — a distinction that keeps the build tractable and preserves the infrastructure a firm has already paid for.

Conclusion

Excel persists in credit for a real reason — its flexibility is unmatched for bespoke instruments — but that same flexibility is why it cannot scale across strategies or survive an audit. As managers converge direct lending, asset-based finance, and private equity onto single platforms, the spreadsheet estate fractures into parallel, irreconcilable worlds, and the firm-level view becomes impossible to assemble. Four priorities should guide any firm building the alternative:

• Model the canonical core first. Legal entity, instrument, position, cash flow, valuation, and fund — with strict identity rules — before any strategy-specific detail.
• Extend, don’t fragment. Represent each strategy as a typed extension of the shared core, so three data shapes live in one model rather than three systems.
• Make time first-class. Bitemporal history is what makes NAV point-in-time defensible and the data investment-grade.
• Sequence intelligence last. A unified, lineage-tracked model is the precondition for AI that can be trusted; it cannot be retrofitted onto spreadsheets.

ABF’s march toward $9 trillion and the multi-strategy convergence driving it are not slowing. The firms that build a unified data model now will run every strategy from one source of truth; the firms that defer it will keep paying the spreadsheet tax — in error risk, in reconciliation, and in the cross-strategy concentration they cannot see — at exactly the moment the stakes are rising.

About Pepper

Pepper is the Operating System for Private Credit — a cloud-native platform purpose-built for alternative asset managers. Pepper unifies the entire fund management lifecycle across direct lending, asset-based finance, and private equity strategies on a single canonical data model, while integrating with the fund administrators, market data providers, and document systems a firm already uses — delivering the data clarity and operational leverage that modern multi-strategy managers require.
onpepper.com

References & further reading

Note: Research and market references are provided for the reader’s further study. Figures are drawn from the cited sources; market projections vary by source and methodology. Readers are encouraged to consult primary sources directly.

• Spreadsheet risk — R. Panko, “What We Know About Spreadsheet Errors” (University of Hawaii) — the ~88% error-rate finding and developer overconfidence studies; European Spreadsheet Risks Interest Group (EuSpRIG) — ongoing field research and the documented loss register (JPMorgan, Fidelity, Fannie Mae).
• Asset-based finance — KKR, “Asset-Based Finance: Private Credit Hidden in Plain Sight” (2025) — $6.1T market, $9T+ 2029 projection, <5% private-fund penetration; Apollo and KKR ABF platform materials.
• Multi-strategy convergence — Macfarlanes, “The growth of asset-based finance in private credit markets” (2025); industry coverage of KKR, Apollo, Carlyle, Blackstone, and Sixth Street ABF expansion.
• Cross-collateral risk — Reporting on the First Brands Group bankruptcy (2025) and the risk of receivables pledged to multiple lenders.
• Data modeling foundations — Canonical / common data models, supertype-subtype (generalization-specialization) design, bitemporal data modeling, and master data management — standard data-engineering literature.
• Private credit market data — Preqin and McKinsey private markets reports — $1.7T private credit AUM and growth context.