When a board asks a question and the finance team takes two weeks to answer it, the problem is rarely competence. It is architecture.
The question was answerable. The data existed somewhere in the system. But the system was not designed to produce the answer without manual reconstruction: extracting data from the ERP, manipulating it in a spreadsheet, cross-referencing with another system, adjusting for a consolidation entry, formatting for the board pack and reviewing for accuracy.
The two weeks were not spent answering the question. They were spent building the infrastructure to answer it, temporarily, for this one question, in a format that will not be reusable next time.
This is not a finance team problem. It is a financial reporting architecture problem. And it is endemic in Indian mid-market companies.
The Chain Where Information Is Lost
Business transaction → ERP entry → chart of accounts → sub-ledger → consolidation → accounting policy → financial statements → management reporting → board reporting
At each link in this chain, information can be lost, distorted or aggregated beyond usefulness.
Transaction entry
If the transaction is not coded correctly at entry (wrong cost centre, wrong project code, wrong customer tag, wrong product category), no amount of downstream reporting can reconstruct the information that was lost at the point of capture. The ERP contains the transaction. It does not contain the intelligence.
Chart of accounts
If the chart of accounts cannot distinguish between fixed and variable costs, or between direct and indirect costs, or between recurring and non-recurring items, the financial statements will be compliant but uninformative. The auditor will accept them. The board cannot act on them.
A chart of accounts designed around statutory requirements (which expenses go where in the P&L) rather than around management decisions (which costs are controllable, which customers are profitable, which products generate margin) produces financial statements that satisfy regulators but not decision-makers.
Consolidation
If the consolidation process relies on manual spreadsheets, the accuracy of the consolidated financial statements depends on the accuracy of the spreadsheet, the diligence of the person maintaining it and the robustness of the review process. Each of these introduces risk.
A consolidation process that is automated within the ERP or a dedicated consolidation tool produces results that are traceable, auditable and repeatable. A process that depends on an Excel file on someone’s laptop produces results that are none of these.
Management reporting
If the management report is built by extracting data from the financial statements and reformatting it for the board, the management report is a derivative product. It can only contain information that the financial statements already contain, which means it is constrained by the same limitations: the chart of accounts, the coding quality, the consolidation logic and the accounting policy choices.
A management reporting system that is designed independently, drawing directly from the ERP and operational systems, can produce information that the financial statements cannot: customer-level profitability, product-level contribution, project-level returns, business-unit-level cash flow and real-time operational metrics.
The Consequence of Bad Architecture
When the reporting architecture is weak, three things happen.
Decisions are delayed. A board that cannot get a reliable customer profitability analysis until three weeks after the quarter ends cannot act on that information in time to change the outcome of the current quarter. The information arrives as history, not as intelligence.
Decisions are wrong. A management team that cannot distinguish between fixed and variable costs in its reporting will make incorrect pricing decisions (pricing below variable cost without knowing it), incorrect investment decisions (expanding a product line that appears profitable on a fully loaded basis but has negative contribution) and incorrect resource allocation decisions (investing in the business unit that reports the highest margin but generates the least cash).
The finance team becomes a reconstruction service. Instead of providing insight, the finance team spends its time building ad hoc analyses, reconciling data across systems and formatting information for specific requests. The team’s capability is consumed by the architecture’s deficiency.
The Northrop Intervention
Northrop Management positions financial reporting architecture as a design problem, not an accounting problem.
Accounting architecture → management information architecture → decision architecture.
The design process starts with the decisions the board and management actually make: which customers to prioritise, which products to invest in, which business units to expand, where to allocate capital, how to manage cash. Then it works backward: what information is needed to make those decisions well? What data must be captured at the transaction level to produce that information? How must the chart of accounts, the cost allocation methodology and the reporting hierarchy be structured to deliver it?
The result is a financial reporting architecture that produces management information as a natural byproduct of the accounting process, rather than requiring manual reconstruction after the fact.
Ashish Chaudhary, frames the diagnostic simply: “If the board asks a question and the finance team needs two weeks to answer it, the problem is not the finance team. It is the architecture that forces them to rebuild the answer from scratch every time.”
Questions for the Boardroom
- Can our finance function produce a customer-level profitability analysis, a product-level contribution margin and a business-unit-level cash flow statement from the existing system, without manual reconstruction?
- Does our chart of accounts distinguish between fixed and variable costs, between direct and indirect costs, and between recurring and non-recurring items?
- How many manual spreadsheets are involved in our monthly consolidation and reporting process, and what would break if the person who maintains them left?
- If we redesigned our reporting architecture around the ten decisions that matter most to the board, what information would we need that we currently cannot produce?
- What is the total cost (person-hours, delay, error rate) of the manual reconstruction our finance team performs each month to produce the management pack?
Closing Implication
The quality of a company’s decisions is bounded by the quality of the information available to make them. The quality of the information is bounded by the architecture that produces it.
A company with a well-designed financial reporting architecture produces the information the board needs, at the speed the board needs it, from systems that are reliable, auditable and repeatable. A company with a poorly designed architecture produces financial statements that are technically compliant and management reports that are late, manual and unreliable.
The fix is not a better finance team. It is a better architecture. And the investment required, properly scoped, typically pays for itself within two reporting cycles through faster decisions, fewer errors and reduced manual effort.
