By Dylan Harrocks , Founder of PMI Stack · Published 2026-09-07 · Updated 2026-09-07 · 11 min read
Spreadsheet risk is the chance that a figure produced in a workbook is wrong, or cannot be shown to be right, at the moment somebody outside the business has to rely on it. In a group built by acquisition, it is the second half of that sentence that does the damage.
The damage sits in the gap between the number on the page and the ledger it came from, and it is rarely an arithmetic error. Across a group built by acquisition, that gap repeats itself entity by entity, and the repetition is what turns spreadsheet consolidation risk into something a credit team notices.
This piece is about spreadsheet risk in lender reporting: what an outside reader is testing for when finance leads at acquisitive groups put a reporting pack in front of a credit team, an auditor, or a buyer. It covers what an outside reader is testing for, where a workbook consolidation fails that test, and what is worth fixing first.
If you want the operational version of this problem, where the close itself starts to buckle, we cover that separately in the problems with consolidating in spreadsheets . This article is about the conclusion somebody else draws from the same workbook.
What is spreadsheet risk in financial reporting? Spreadsheet risk is the risk that financial information produced outside a controlled system cannot be relied on, because the workbook that produced it has no enforced access control, no version history, and no record of who changed what. It is a recognised category of operational risk, often filed under end user computing, meaning tools built and maintained by the business rather than by IT. The common framing is error rates, and errors are real. For a group that reports to a lender, the sharper problem is evidential: a number can be entirely correct and still be unusable, because nobody can demonstrate how it was arrived at. An auditor calls this the completeness and accuracy of information produced by the entity. A credit analyst does not use that phrase, but is asking the same question when they request the supporting schedule behind a covenant calculation and get a workbook back.
Why does the way you produced a number matter to a lender? Because the person reading your pack has to decide whether they can rely on it, and reliance is a function of traceability. Your lender reads it to work out how much they can take on trust without re-performing your close, looking for enough evidence that a figure ties to something they could check if they had to.
Auditors work to an explicit version of this rule. Paragraph 9 of ISA (UK) 500 requires that when using information produced by the entity, the auditor evaluates whether it is “sufficiently reliable”, including by “obtaining audit evidence about the accuracy and completeness of the information”. The application material is blunter: such information “needs to be sufficiently complete and accurate”.
ICAEW made the same point more sharply for auditors in 2024. Where a controlled accounting system exports into a manual workbook, writes Amelia Pickard, the software's own controls “may be made redundant” once the data lands somewhere with no further oversight (ICAEW on the auditor's review of management spreadsheets, January 2024 ). Her summary of the underlying weakness is that spreadsheets “often lack a robust audit trail, making it difficult to track changes”.
That is worth sitting with if your ledgers are clean. Good source systems do not protect a number once it has been exported, adjusted and re-presented in a file.
Lenders sit outside the auditing standards and inherit the instinct anyway, because they are underwriting on numbers they did not produce.
Writing for private-equity-backed CFOs, Nilus puts the covenant version of it simply: “Every add-back, every adjustment, every input should trace to a source document,” and “Spreadsheets with hardcoded numbers fail this test” (Kalish on covenant compliance monitoring, March 2026 ). Nilus sells software in this space, so read it as an interested view. The underlying test is not controversial.
There is a second-order effect that acquisitive groups feel more than single-entity borrowers. When a figure cannot be traced quickly, the follow-up questions multiply, and every one of them lands on the same person. The credit process stretches, and it stretches at exactly the point in the calendar where you have least room to absorb it.
What does a credit team see when the consolidation is a workbook? They see an output with no attached history. Four gaps follow from that, unevenly serious.
Lineage. A consolidated revenue figure arrives as a value in a cell, and there is no automatic route back through the group mapping to the trial balances that fed it. Reconstructing that route by hand takes time a credit process rarely allows, and it still leaves the route uninspectable by anyone else.
Version history. Most groups can tell you the number they submitted last quarter. Fewer can open the workbook that produced it and get the same answer today, because the file has been edited since, and the edits were not versioned. Once a prior-period figure moves, everything downstream of it is in question.
Concentration. One person built the model, understands the manual adjustments, and knows which tabs are live. Lenders read that as key-person risk on the reporting itself, separately from key-person risk in the business.
Timing. This is the gap that gets noticed first, because it is visible from outside. A group whose consolidation depends on a workbook that only assembles once every ledger has closed will file late in the months it can least afford to. How often your numbers can refresh, and what that costs you, is the subject of real-time versus month-end consolidated reporting .
Here is the distinction that matters when you are reading your own pack:
Present and verifiable. Statutory accounts, filed and audited. A bank statement. An invoice in the accounting system with a document trail behind it.Present and plausible. A consolidated EBITDA figure with a bridge that reconciles on its face, where the reconciliation was assembled manually and cannot be re-run.Present and unverifiable. An adjustment typed straight into the consolidation with no schedule behind it. A target or budget figure that exists only in a planning file. A metric whose definition lives in one person's head.The packs we review keep turning up all three tiers in the same document, with nothing to mark where one ends and the next begins. The exposure sits there: a reader cannot tell which parts of the pack they are allowed to lean on, so they discount the parts they cannot place.
Could someone else rebuild your number without you? Usually not, and that is the test worth running before any financing conversation. Ask whether somebody other than the person who built the model could produce the same figure from the source systems, working alone. It is a harder question than “is this right”, and it is the one we run first.
When we build a client demo, we start from the client's own KPI sheet, and check a handful of their signature figures against what is on the screen before the client ever sees it. The failures we keep finding sit in the same three places, and none of them are arithmetic.
Definitions that exist in one place only. A group will have a genuine, considered revenue recognition policy, and the calculation that applies it runs offline in a month-end file because the source systems do not hold the inputs the policy needs. That is the harder problem of the two: the policy can be entirely sound and the number it produces still cannot be reproduced from the systems by anybody else.
Targets that live outside the system. Budgets and monthly targets sit in a planning workbook, so any actual-versus-budget comparison in the pack is a manual join between a system number and a file number. That comparison is often the first thing a lender looks at.
Metrics with no source at all. Occasionally an operational figure in a management pack has no underlying field anywhere. Nobody is inventing it, but it is estimated, and the estimate has hardened into a reported number over a few reporting cycles.
We hold our own builds to that test. When we stand up a client dashboard, every metric is defined once in a semantic layer, so the dashboard, the exports and the embedded assistant all read the same definition and cannot drift apart.
Where a metric has no defensible source, the build does not compute a proxy. It flags the input as manually sourced, or the metric abstains rather than displaying a figure nobody can stand behind. An abstaining tile is an uncomfortable thing to walk a client through, and it is still better than a number the client cannot defend.
The same rule is wired into the AI layer. Every figure it returns has to trace back to a query result, it does no arithmetic of its own, and where nothing can answer the question it says so instead of estimating.
The clearest signal I have had that this matters came from an owner with a private equity background, in a session where we walked through the debt and cash view. He stopped the demo and asked for screenshots to lift into a lender pack he was writing that week.
Mid demo, screenshots already in hand, he was solving one problem: putting numbers in front of a credit team and being able to stand behind them.
Which numbers in a group pack are most exposed? Five, in roughly descending order of how often they cause trouble.
Intercompany eliminations. They are manual in most workbook consolidations, they change as the group changes, and an error here overstates group revenue directly. Our guide to post-acquisition reporting consolidation covers the reconciliation work behind them.Adjusted EBITDA add-backs. The single most scrutinised line in any credit conversation, and the one most likely to be supported by a schedule that lives outside the accounts.Anything requiring a consistent chart of accounts. Comparatives across entities are only meaningful if the mapping holds, and acquisitions guarantee it drifts. Mapping the chart of accounts across acquired companies is the underlying fix.Covenant calculations. Leverage and interest cover are formulas defined in your facility agreement, not standard ratios, and the definitions are specific. We cover this in group cash flow and covenant reporting .Foreign exchange. Rate choice, rate source, and consistency between periods, small in a good year and the first thing questioned in a volatile one.How do you make a workbook consolidation defensible? You do not have to replace it this quarter. Most of the gap closes with control, not software.
Start by listing the workbooks that feed the pack, and name an owner for each. That list is usually the first time anyone in the group has seen how many separate files the reported numbers depend on.
Then write down each reported metric once, in one place, with its definition and its source system. Where the source is “a person”, say so.
That single document does more for a credit conversation than any dashboard, because it lets you answer the follow-up questions without going back into the file. Our guide to the lender reporting pack for a group built by acquisition sets out what a credit team expects to sit alongside it.
After that: version the consolidation properly so a prior period can be re-opened and re-run, keep the supporting schedule for every manual adjustment attached to the period it belongs to, and lock the inputs that should not be edited.
Then, and only then, look at what is worth automating. The right sequence is definitions first, systems second. Groups that do it the other way round automate an ambiguity and end up with the same argument at higher speed.
There is a point where control stops being enough, and it shows up as manual reconciliation that no longer fits inside the close window. In our experience what drives it is how many different systems and charts of accounts are in play, more than the entity count on its own. Multi-entity accounting consolidation sets out the system options at that point.
Where PMI Stack fits into lender reporting We build consolidated reporting for groups that have grown by acquisition. Each entity's accounting data is pulled into a warehouse the client owns, mapped to one group chart of accounts and one reporting currency, and surfaced as a dashboard with an embedded assistant. The part relevant to this article is the semantic layer underneath it, where each metric is defined once so every surface reads the same definition.
Two honest boundaries. Financial consolidation is the reliable, repeatable core of what we do; operational and CRM reporting is scoped per client, because those systems vary far more than ledgers do. We also work with your fractional CFO or finance team on the definitions, since the mapping decisions are theirs to make.
For the wider picture of what debt providers ask an acquisitive group for, see what lenders want from an acquisitive group .
Frequently asked questions Will a lender reject management accounts prepared in Excel? Rarely outright. Lenders receive borrower packs assembled in spreadsheets all the time, and they work with them.
What changes is the amount of supporting evidence they ask for, how long the process takes, and how much benefit of the doubt you get on a judgement call. The practical cost is time and terms, not refusal.
What is end user computing risk? End user computing risk covers spreadsheets and similar tools that finance teams build and maintain themselves, sitting outside whatever change control applies to the core accounting system. The concern is that a calculation only its owner can check becomes load-bearing for the group's reported numbers. It is a standard category in financial services risk frameworks and increasingly applied outside them.
Does an audit fix spreadsheet risk? No. An audit gives an opinion on the statutory accounts at a point in time, and says nothing about whether next month's consolidation can be reproduced.
Auditors test the completeness and accuracy of what you handed them, separately from the process that produced it. A group can pass its audit and still fail a lender's traceability test, because the two are checking different things.
How many entities can a spreadsheet consolidation handle? There is no fixed number, and it depends more on how different the entities are than how many there are. Two entities on the same accounting system with the same chart of accounts is straightforward at almost any size. Six entities across three systems, two currencies and four charts of accounts is hard at any size, because the pressure comes from the variety rather than the count.
What should we fix first before a refinancing? Definitions. Write down every metric in the pack with its source, then make the covenant calculations reproducible from the ledgers on the definitions in your facility agreement.
Everything else, including any system change, is downstream of that. The wider method sits in our guide to consolidated financial reporting .
The one thing to take away Every figure in your pack that cannot be traced back to a system is one your lender has to price rather than take on trust. Pricing that spreadsheet risk is what a credit team is doing while it reads your numbers, whatever the questions on the call sound like.
So do this before the next covenant test, not after it. Take the number in your last pack you would least want questioned, hand it to somebody who did not build it, and ask them to get back to the ledger. Whatever they get stuck on is your first fix, and it will tell you more about your financing readiness than any ratio on the page.
