The Pattern

The controller opens the ERP. Exports the trial balance. Opens Excel. Rebuilds the balance sheet manually — mapping accounts, adjusting for intercompany, adding eliminations, formatting for the board. The ERP has a balance sheet report. Nobody uses it. The numbers are "not quite right."

This is not an edge case. In most mid-market companies with more than one entity, the official financial statements are produced in Excel, not in the system of record. The ERP is used for transaction processing. Reporting happens outside it. The gap between these two creates a permanent reconciliation problem that consumes hours every month and introduces error at every step.

Why the Numbers Don't Match

The root cause is almost never a software deficiency. It is a data model problem. Specifically, three failures account for the majority of cases:

Chart of accounts misalignment. The chart of accounts was designed for statutory reporting — not for management reporting. Cost centers, profit centers, and segment identifiers are either missing, inconsistently applied, or encoded in free-text description fields that cannot be queried reliably. Management wants profitability by project. The chart of accounts only tracks expenses by nature. The gap is filled with Excel.

Intercompany without governance. Entity A invoices Entity B. Entity B books the expense under a different account code, in a different period, sometimes in a different currency. At consolidation, the intercompany elimination doesn't balance. Someone spends two days tracing the difference. The fix is manual. Next month, it happens again — because the process that creates the mismatch was never corrected.

No master data ownership. Customer codes are created by sales. Vendor codes are created by procurement. GL account codes are created by accounting. Nobody coordinates. The same customer appears under three codes. The same cost type is booked to different accounts depending on which entity processes it. Analytical queries produce unreliable results because the underlying classification is inconsistent.

The Compounding Cost

The direct cost is hours: the time spent every month rebuilding reports that should be generated automatically. In a typical five-entity group, this easily reaches 40–60 hours per month across the finance team — equivalent to a quarter of one full-time position devoted entirely to data reconciliation.

The indirect cost is more damaging. When management does not trust the data, they make decisions on intuition. Investment decisions are delayed while someone "checks the numbers." Cash flow surprises occur because the treasury view is assembled from three disconnected sources. Audit findings accumulate because the reconciliation trail is manual and incomplete. The cost of distrust is not measured — it is absorbed into the organization as normal operating friction.

The Fix Is Not a Dashboard

The instinct is to buy a BI tool. Power BI, Tableau, Looker — it doesn't matter. A visualization layer on top of inconsistent data produces consistent-looking inconsistency. The charts look professional. The numbers are still wrong. The problem has moved from an ugly Excel to a polished dashboard — but the data model underneath hasn't changed.

The correct sequence is: fix the data model first. Standardize the chart of accounts across all entities. Implement intercompany governance with matching rules and automated reconciliation. Define master data ownership and enforce it through system controls, not policies. Build the reporting layer last — on a foundation that produces trustworthy numbers without manual intervention.

This is architectural work, not tool selection. It requires someone who understands both the financial reporting requirements and the technical data structures that must support them. Most finance teams don't have this profile. Most IT teams don't understand the reporting requirements. The gap between the two is where data distrust is born — and where it must be resolved.