The 20-Page Spreadsheet Problem: Why Volume Isn't Visibility

May 14, 2026 · Alex Escoriaza
financial-reportingmulti-locationoperator-transitionsmall-businesspost-acquisition
The 20-Page Spreadsheet Problem: Why Volume Isn't Visibility

Your bookkeeper hands you twenty pages of Excel every month. Tabs across the bottom: P&L by location, balance sheet, trial balance, journal entries, AR detail, AP detail, payroll allocation, intercompany reconciliations. You nod. You file it. You move on.

If anyone asked, you’d say you have financial reporting.

What you actually have is a filing cabinet.

This is one of the most common patterns I see with operators who inherited or acquired a business and watched it grow faster than its accounting infrastructure. The pages keep getting longer. And somewhere around month four, you realize you can’t answer the questions a thoughtful board member would ask in five minutes.

”I Don’t Know Enough to Know”

A few months ago I came across an operator running a multi-location medical practice — seven full-time locations, twenty-five part-time sites, a corporate office. He and his brothers had inherited the business. They were medical specialists by training. They had learned to run the company “for the most part.” His exact words:

“We are quite bad at interpreting the financial spread sheets our bookkeeper makes for us… I’m being handed like 20 pages of excel spreadsheets and can’t make heads or tails of what I’m looking at half the time.”

“I’m not totally convinced our books are being done the best they can be but I don’t know enough to know.”

Thirty-some locations. Profitable overall. Some sites showing losses of thousands of dollars. And the leadership team — the people responsible for capital allocation, hiring decisions, real estate strategy — couldn’t tell you with confidence whether a given location was losing money or whether it was an artifact of how overhead was being spread around. They knew they needed someone to come in and check whether things were being allocated properly. They just didn’t know who, or what to ask for.

That second quote sticks with me. “I don’t know enough to know.” It’s an honest sentence. It’s also a dangerous one, because it describes the state most multi-location operators are in for the first eighteen months after they take the wheel.

Volume Looks Like Rigor. It Isn’t.

Here’s the trick the messy middle plays on you: if you’ve never run financial reporting before, you assume more pages means more rigor. Twenty pages feels thorough. Three pages would feel like the bookkeeper is slacking.

The opposite is closer to true.

Decision-support reporting is short on purpose. It’s compressed because the person reading it has fifteen minutes, not three hours. A good monthly package answers four questions before you ask them: Did we make money this month, where, and how does that compare to recent trend? Are our locations profitable after we account for shared costs honestly? Do we have cash to fund next month’s payroll and rent? Who owes us money and how stale is it?

Twenty pages of Excel can technically contain those answers. But buried inside cell ranges and tabs that nobody named, surrounded by reconciliation detail that exists for the bookkeeper’s workflow rather than yours, the answers don’t surface. The data exists; the visibility doesn’t.

This is the gap between a data dump and a reporting system. The bookkeeper is doing what they were hired to do — keep the books, close the month, make the trial balance tie out. That work matters. It’s not the same job as helping you run the company. Those are two different jobs, and most small businesses pay for one and assume they’re getting both.

The Spreadsheet Is Not the Problem

Here is where most people get this wrong: they see the twenty-page spreadsheet and conclude it needs to be replaced. Hire a proper analyst. Implement a real system. Start fresh.

That instinct is understandable. It is also, more often than not, the wrong move.

The twenty-page spreadsheet is not a technology problem. It is not even a reporting problem. It is a trust problem — in the original sense of the word. The previous owner trusted that spreadsheet to run the business, and there is a reason for that. That spreadsheet encoded something.

Think about what it actually contains. Every P&L exception the previous owner cared about. Every workaround for the location that runs differently from the others. Every allocation logic that seemed arbitrary until you understood the two locations share a supply closet and a part-time manager. Every customer category that gets reconciled by hand because the billing system can’t handle it. Twenty pages of Excel is not a bad report. It is a compressed record of how this particular business actually works — not how a textbook says it should work.

The formatting reflects the previous owner’s mental model. The tabs reflect their priorities. The workarounds reflect the reality they were managing around.

When you inherited the company, you inherited that spreadsheet too. The question is whether you can read it.

”Built to Just Work, Not to Scale”

The reason inherited businesses end up with twenty-page reporting packages isn’t malice. It’s drift.

The original owner knew the business in their head. They knew which location was the strong one because they drove past it every Tuesday. They knew the receivables situation because they signed every check. The bookkeeper they hired was hired to keep the books, not design the dashboard. The chart of accounts was set up for tax filing, not management visibility. The systems they put in place were built to just work, not to scale. The books closed. Taxes got filed. Banks got paid.

Then you took over. And now you’re trying to make capital allocation decisions across thirty locations using a reporting infrastructure designed to satisfy a CPA, not a CEO.

This is not your fault. It is your problem.

But here is where the problem gets misdiagnosed. Most operators assume the answer is to build something better from scratch — a clean chart of accounts, a proper BI tool, a real analyst who doesn’t use Excel. What they are describing is a system that encodes their mental model of the business. The problem is they don’t have one yet. They’ve been in the seat for eighteen months. The previous owner had thirty years.

Ripping out the spreadsheet before you understand what it contains is how you lose the institutional knowledge that was keeping the business running.

Translation, Not Replacement

The operators who navigate this transition well don’t replace the spreadsheet. They translate it.

Translation looks like this: you sit with the spreadsheet — actually sit with it, with someone who can help you read it — and you ask what each tab is tracking and why. You find the allocation logic and you ask whether it reflects operational reality or accounting convenience. You find the exceptions and you ask which ones are genuinely recurring and which ones were one-time workarounds that nobody cleaned up. You find the categories that don’t quite match what you’d expect, and you ask what the previous owner was actually trying to see.

That process is slower than buying a dashboard. It is also the only process that tells you what you actually bought.

When operators ask me what good looks like for a service business doing $5M to $25M across multiple locations, the first question I ask is not “what reporting system do you want to build?” It is “what does the reporting you inherited tell you, and what does it not tell you?” The gap between those two things is the work.

Sometimes that gap is small — the spreadsheet is reasonably legible and a few structural changes make it a real management tool. Sometimes the gap is large — the previous owner’s mental model lived in their head, not in the document, and the spreadsheet is genuinely opaque to anyone who wasn’t there. But you cannot know which situation you are in until you have read what you have.

Operators who skip the translation step and go straight to replacement often find themselves eighteen months later with a beautiful new reporting infrastructure and no institutional memory, running blind in a different direction.

What Changes When You Translate It

Your top line doesn’t move overnight, and the underlying business is the underlying business. Going from twenty pages to something legible doesn’t make a struggling location profitable.

What does change is the speed and quality of every decision you make from that point forward.

When you understand what the spreadsheet is actually tracking, you stop treating every anomalous number as a mystery and start treating it as a question with a known address. When you can see that the allocation logic is masking a real margin problem at location 3, you stop arguing about the number and start addressing the location. When you understand which exceptions are structural and which are one-time artifacts, you stop cleaning up accounting issues and start seeing the operational ones.

You stop being surprised. You stop relying on your bookkeeper’s verbal explanations of why a number looks weird. You ask better questions, your team starts producing better answers, and the conversation upgrades. That translation is also the foundation on which the metrics cascade actually gets built — once a location-level number stops being a mystery, you can push it down to the people who control it, and they can own it.

This is not a technology problem. It is a definition problem. The difference between a twenty-page data dump and a reporting system you can actually use is not the software. It is knowing what you are looking at.

The Translation Is Step Zero

Before You Build, You Have to Read: Step 0 is translating what you inherited — understanding what each tab tracks, what the allocation logic reflects, what exceptions are structural. Step 1 is building capability aimed at how the business actually runs.

Here’s what operators get wrong when they recognize this problem: they assume the path runs from “I can’t read my spreadsheet” directly to “I need a new system.” That’s skipping a step.

The translation work — sitting with what you have, understanding what it actually tracks, identifying what the previous owner compressed into those tabs — is not the destination. It’s the diagnostic. It tells you what to build.

Operators who skip it and go straight to building often find themselves eighteen months later with clean, modern infrastructure that doesn’t quite fit how the business runs. The dashboards are beautiful. The KPIs don’t match how margin actually accumulates in this business. The new system encodes their assumptions about the business rather than what the business actually does. They’ve replaced one opacity with another.

The operators who get the build right do the translation first. They understand what they have before they decide what they need. Then the real work — turning a business that runs on intuition and one-page P&Ls into one that runs on operational data — is aimed at the right thing. That is the 0-to-1 build. Translation is just what makes it land.

If you’re about to invest in analytics capability and you’re not sure what you actually need, that conversation about what you already have is where I start. Not “what do you want to build?” but “what does the business you inherited actually track, and where are the gaps?” Reach out if that’s where you are.


Alex Escoriaza helps PE-backed operators and business owners build analytics capability from the ground up — starting with what they’ve inherited, not a blank slate. If you’re not sure what you have before you decide what to build, reach out.

← Back to all posts

Ready to figure out what "good" looks like?

Take our free assessment to identify your gaps and get a personalized roadmap.