Reading a P&L Properly: Anatomy of a Diagnostic: What Actually Gets Found
# Anatomy of a Diagnostic: What Actually Gets Found

Anatomy of a Diagnostic: What Actually Gets Found
The controller walked me through their monthly close process with the kind of confidence that comes from doing something the same way for three years. Revenue reconciled to the bank statement. Expenses matched the approved budget within five percent. The board got a clean P&L every month, on time, formatted exactly how they liked it.
Then I asked to see the deferred revenue schedule.
Silence. Not the kind where someone's thinking through where the file lives. The kind where the question itself doesn't make sense because the thing being asked for doesn't exist. They'd been recognizing subscription revenue on a cash basis the entire time, booking it the month it hit the bank regardless of what period it covered. Three years of monthly financials, all wrong in the same direction, and nobody had flagged it because the top-line number kept growing and the cash account balanced.
This wasn't incompetence. It was a structural gap that a standard bookkeeping process has no reason to catch, because standard bookkeeping is built to record transactions, not to interrogate whether the accounting treatment of those transactions reflects economic reality.
A diagnostic isn't about finding fraud or uncovering some dramatic hidden loss. Most of the time, what gets found is exactly this: a process that works perfectly within its own logic but is solving for the wrong thing. The monthly close was flawless. The financials were useless.
A shorter version of this post appears on LinkedIn.
What a Diagnostic Actually Is
A financial diagnostic is a structured review of how a business records, reports, and interprets its own numbers. It's not an audit, which checks compliance with a standard. It's not a reconciliation, which checks that two sets of numbers agree with each other. It's a question about whether the financial system as a whole is producing information that reflects what's actually happening in the business.
The structure matters because most financial problems don't announce themselves. They sit quietly inside a process that looks fine on the surface, producing reports that reconcile cleanly and satisfy whoever's reading them, until someone asks a question the system wasn't built to answer.
The deferred revenue problem is a clean example. The cash-basis P&L wasn't technically wrong in the sense that the numbers added up. It was wrong in the sense that it made a twelve-month subscription look like a windfall in January and made February look weaker than it was. The revenue trend the board was reading had nothing to do with how the business was actually performing. Every decision they made based on that trend, pricing, hiring, runway projections, was based on a number that didn't mean what they thought it meant.
That's what a diagnostic catches. Not the error itself, but the gap between what the system is reporting and what the business needs to know.
The Three Layers Every Diagnostic Walks Through
A diagnostic moves through three layers, and the order matters because each one depends on the integrity of the one before it.
Layer One: Transaction Recording
This is the foundation. Are transactions being recorded in the right accounts, at the right time, with the right classification? Most businesses get this mostly right because the bookkeeper or the accounting software enforces basic rules. Revenue goes in a revenue account. Expenses go in expense accounts. The chart of accounts is structured enough that things land somewhere reasonable.
But "mostly right" hides a lot. I've seen software subscriptions coded as capital expenditure because they were sold as "annual licenses" and someone decided that sounded like an asset. I've seen contractor payments split across three different expense accounts because different people were approving them and each approver had their own interpretation of what category made sense. I've seen intercompany transfers recorded as revenue because the person entering them didn't understand what "intercompany" meant.
None of these break the bookkeeping in an obvious way. The P&L still balances. The accounts still reconcile to the bank. But the categories are wrong, which means every report built on top of those categories is wrong in ways that are hard to spot unless you're looking at the underlying detail.
A diagnostic at this layer is checking whether the recording logic is internally consistent and whether it matches the economic substance of what's happening. It's not about finding mistakes. It's about finding patterns of mistakes that suggest the system is interpreting transactions in a way that doesn't match reality.
Layer Two: Reporting Structure
This is where most of the invisible problems live. The transactions might be recorded correctly, but the way they're aggregated and reported hides something important.
The classic example is gross margin. A business records revenue correctly and records cost of goods sold correctly, but they're mixing in costs that aren't directly variable with revenue, like warehouse rent or salaried operations staff, because someone decided those felt like "cost of goods" even though they don't move with volume. The gross margin number on the P&L looks reasonable, but it's not measuring what gross margin is supposed to measure, which is the unit economics of the core product. Any decision based on that number, pricing, discounting, volume targets, is based on a margin figure that doesn't isolate the thing it's supposed to isolate.
Or take timing. A business might be recognizing revenue correctly on an accrual basis but reporting it in a way that makes it impossible to see the lag between when a sale closes and when the cash arrives. The P&L shows strong revenue growth. The cash flow statement shows the bank account shrinking. Both are true, but if the reporting structure doesn't make the relationship between them visible, the founder sees growth and doesn't see the cash problem until it's acute.
A diagnostic at this layer is checking whether the reports are structured to surface the relationships that matter. Not whether the numbers are right in isolation, but whether the way they're grouped and presented makes it possible to see what's actually happening.
Layer Three: Interpretation and Use
This is the layer that determines whether the financial system is useful. The numbers might be recorded correctly and reported clearly, but if the people reading them are interpreting them wrong or making decisions based on the wrong metrics, the system isn't working.
I worked with a business that had clean financials and a well-structured P&L. The founder was obsessed with monthly revenue growth because that was the metric the board asked about. Revenue was growing at eight percent month over month, consistently, for six months. It looked like momentum.
But customer acquisition cost had doubled over the same period because they'd shifted spend toward paid channels that converted faster but brought in customers with half the lifetime value. The revenue growth was real. The unit economics were collapsing. The P&L didn't hide this, it was all there in the detail, but the founder wasn't looking at CAC or LTV because the board wasn't asking about them and the monthly reporting pack didn't surface them.
A diagnostic at this layer is checking whether the business is asking the right questions of its own numbers. Not whether the reports are accurate, but whether the decision-making process is using the reports in a way that reflects the actual dynamics of the business.
What Actually Gets Found
Most diagnostics don't find one big thing. They find a pattern of small things that add up to a structural problem.
The most common finding is a mismatch between cash and accrual reporting. A business is managing to a cash-basis P&L because that's what feels intuitive, but it's making decisions that depend on understanding accrual timing, like whether to extend payment terms to close a deal or whether the gross margin on a project justifies the upfront cost. The cash P&L doesn't answer those questions, so the decisions get made on instinct instead of on information.
The second most common finding is a classification problem that's hiding a cost trend. A business has five different accounts that all capture some version of "customer acquisition" because different people set them up at different times, and nobody's ever consolidated them into a single view. The founder looks at "Sales and Marketing" on the P&L and sees a number that's stable as a percentage of revenue. But if you pull every account that's actually funding customer acquisition, including the contractor spend that's coded under "Operations" and the software tools that are coded under "Technology", the real CAC has gone up forty percent in six months.
The third most common finding is a reporting structure that makes it impossible to see product or channel economics. A business has three revenue streams but reports them as a single line because that's how the accounting software was set up. One of the streams has twice the gross margin of the others, but the business is allocating marketing spend evenly across all three because they don't have visibility into which one is actually driving profit.
None of these are dramatic. None of them involve fraud or missing money or a financial control that's completely broken. They're all cases where the system is working exactly as designed, but the design doesn't match what the business needs to know.
The Worked Example: Subscription Revenue Recognition
Take the deferred revenue case from the opening. Here's what the diagnostic process actually looked like.
The business was selling annual subscriptions. A customer pays in January, gets twelve months of access. Under cash-basis accounting, the full payment gets recorded as revenue in January:
This makes January look strong and every other month look weak, because there's no revenue in the months where the service is actually being delivered but no cash is coming in.
Under accrual accounting, the cash payment gets recorded as deferred revenue, a liability, and then recognized monthly as the service is delivered:
The diagnostic found that the business was doing the first thing but reporting as if they were doing the second. The P&L showed "revenue" that was actually just cash timing. The trend line the board was reading had nothing to do with how many customers were being added or how much the product was being used. It was a graph of when invoices happened to get paid.
The fix wasn't complicated. Build a deferred revenue schedule, restate the historical P&L to recognize revenue monthly, and change the reporting process so that future subscriptions get recorded correctly. But the impact was significant because every decision the business had made about growth, pricing, hiring, had been based on a revenue trend that didn't exist.
This is what a diagnostic does. It doesn't find the one number that's wrong. It finds the place where the system is producing information that looks right but doesn't mean what the reader thinks it means.
Why This Matters More in Early-Stage Businesses
A large business with a finance team and external auditors has structural forcing functions that catch most of these problems. The auditors will flag deferred revenue. The FP&A team will build models that require clean data. The CFO will insist on reports that separate cash from accrual and product economics from consolidated numbers.
An early-stage business has none of that. The founder is managing the business from a P&L that the bookkeeper produces, and the bookkeeper is recording transactions the way they were taught or the way the software defaults to. Nobody's asking whether the reports are structured to answer the questions the business actually needs to answer, because there's no one whose job that is.
This is why diagnostic work matters more at the early stage than it does later. A large business can survive a reporting problem because it has enough process and oversight that someone will eventually notice. An early-stage business can make six months of decisions based on a number that doesn't mean what they think it means, and by the time the problem surfaces, the decisions are already embedded in the business.
The Practical Output
The output of a diagnostic isn't a report that says "everything is fine" or "everything is broken". It's a specific list of gaps between what the system is doing and what the business needs it to do, with a clear explanation of what each gap means in practice.
For the subscription business, the output was:
- Revenue is being recognized on a cash basis. This makes monthly revenue trends unreadable and makes it impossible to forecast accurately.
- There is no deferred revenue schedule. This means the balance sheet is understating liabilities and the P&L is overstating near-term revenue.
- The reporting structure doesn't separate new revenue from renewal revenue. This makes it impossible to see whether growth is coming from new customers or from existing customers renewing.
Each of those is a specific, fixable problem. The diagnostic doesn't fix them, it names them and explains why they matter. The business can then decide which ones to prioritize based on what decisions they're trying to make and what information they need to make those decisions well.
What Comes Next
Next week, the series shifts. We've spent four weeks inside the P&L, how to read it, where the gaps are, what a diagnostic finds. The next part moves to the question that sits behind all of this: what makes a financial system actually useful, not just accurate?
If you're running a business and you're not sure whether your financial reporting is structured to answer the questions you're actually asking, a diagnostic is worth the time. You can book thirty minutes to walk through what that looks like here: calendly.com/muhammed-adediran/30min.
Muhammed Adediran
Quantitative Finance ConsultantI run a quantitative finance consultancy providing fractional FP&A, financial modelling, and credit & risk analytics to growing businesses and lenders. See the engagements.
