What Good Financial Reporting Actually Looks Like at Scale

P&L by segment. Department-level actuals versus plan. Cash position by entity. Customer-level margin. Most mid-market companies can produce one of these on demand. Producing all of them — accurately, in near real time, without a three-day sprint — requires an architecture most companies don’t have and can’t build by adding another reporting tool on top of what they already run.

Financial reporting is where the quality of an ERP architecture becomes most visible to leadership. Every gap in the data model shows up as a report that can’t be produced, a metric that requires manual calculation, or a dashboard that’s always slightly out of date. The reporting surface is where the underlying system quality is experienced, even by people who never think about the underlying system.

What the reporting hierarchy should produce

A complete financial reporting capability for a mid-market company covers three layers. The statutory layer produces GAAP-compliant financial statements — income statement, balance sheet, statement of cash flows — at the entity level and consolidated across entities. This is table stakes; any ERP worth using produces this.

The management layer produces the reports leadership actually uses to run the business: P&L by business unit, revenue by product line, expense by department versus budget, headcount cost by function. These reports require dimensional data — the segment codes that tell the system not just what the transaction was but which part of the business it belonged to. They require that segment data to have been collected consistently at transaction time, not reconstructed afterward.

The analytical layer produces the deeper views that drive strategy: customer-level revenue and margin, product-level contribution, geographic performance, customer cohort analysis. These reports require connecting financial data to operational data — the customer’s revenue history, the product’s cost structure, the geographic attribution of both. When those data sources live in separate systems, the analytical layer is a BI project, not a reporting query.¹

Why segment data is the hardest part

The statutory reports are largely a function of account coding accuracy. If transactions are posted to the right accounts, the statutory reports are correct. The management reports require an additional layer of discipline: that every transaction carries the right segment codes, consistently, at the time it’s posted.

This is harder than it sounds. In most ERP systems, segments are fields that can be left blank or filled inconsistently. A journal entry for marketing expense might carry a department code of “Marketing” in one period and be blank in another, because different people entered the transactions and the system didn’t enforce the requirement. At the end of the period, the marketing expense total is correct but the department-level view is understated — because some of it went into the “no segment” bucket.

Enforcing segment completeness at the transaction level — requiring that P&L account entries carry all required segments before they can be posted — produces management reporting that’s reliable rather than indicative. This is a database-level constraint, not a user reminder.

The BI layer question

Many companies respond to reporting gaps by adding a BI tool. Tableau, Power BI, Looker, or a dedicated FP&A platform aggregates data from the various systems and provides a unified reporting interface. This is a real improvement over the alternative, and for companies with genuinely complex, multi-source reporting needs, it’s appropriate.

The limitation is that a BI layer can only report what the source systems provide. If the GL doesn’t carry segment data, the BI layer can’t manufacture it. If the billing system’s revenue data doesn’t match the GL’s recognition entries, the BI layer shows the discrepancy rather than resolving it. The reporting tool is downstream of the data quality problems; it can surface them more clearly but it can’t fix them.

The reporting architecture that doesn’t require a BI layer to be reliable is one where the source data is complete, consistent, and structured in a way that answers management questions directly. That’s an ERP design problem, not a reporting tool problem.

The real-time standard

The meaningful benchmark for financial reporting quality is whether the CFO can answer a question about business performance right now, without waiting for a process to run. What’s the cash position across all entities? What’s revenue month-to-date versus the same period last month? What’s the open AR balance for a specific customer? When the answer to any of these requires a report request, a batch job, or a manual pull — rather than a live query — the reporting architecture has a gap.

Sources