Your Month-End Numbers Are a Data Problem, Not an Accounting One

Walk into most mid-market industrial finance functions on the eighth working day of the month and you will find the same scene. The close is still running. Last month’s numbers are nearly ready. And the operations side of the business has already moved on to problems the figures cannot yet describe.

Finance is steering by looking in the rear-view mirror. By the time the management accounts are signed off, the data they rest on is three to five weeks old. Margin has already eroded on a product line. Cash is already tied up in stock that is not moving. The CFO is making this month’s decisions on last month’s reality.

This is not a competence problem. The finance team is doing skilled work with the tools it has been given — an ERP built to record transactions, and a spreadsheet layer stitched on top to make sense of them. The problem is structural. The numbers arrive too late to change anything they describe.

And the lag compounds. Every system the business adds — a second plant, an overseas entity, a new sales channel in Dynamics 365 — adds another export, another reconciliation, another tab in the master workbook. The close does not get slower because the team got worse. It gets slower because the manual effort scales with complexity, and the business keeps getting more complex.

Here is the uncomfortable reframe. The slow close is not an accounting problem. It is a data problem wearing an accounting costume.

Most month-end delay has nothing to do with judgement or technical accounting. It is the mechanical work of pulling figures out of SAP S/4HANA or SAP ByDesign, reconciling them against subledgers, chasing accruals across email, and rebuilding the same workbook every period because the source data never lands in one place ready to use.

Industrial businesses rarely lack financial data. They lack a single version of it they can trust. The general ledger says one thing. The operations report says another. The sales pipeline in Dynamics 365 says a third. Three numbers, three owners, no reconciliation — and a finance team that spends the first week of every month deciding which one to believe.

Until that foundation is fixed, every financial analytics initiative sits on sand. You can put a polished dashboard on top, but if the data underneath is not live and not reconciled, you have built a faster way to argue about whose number is right.

For years I argued the other side of this. If you have invested in a capable ERP, the reporting module should be enough. Add a finance-focused tool — SAP Analytics Cloud, a stack of Excel templates, a report off the back of the general ledger — and you have your numbers. Buying another platform looked like solving a process problem with software.

I was half right. The tooling was rarely the binding constraint. But I underestimated how much of finance’s month was consumed by data movement — and how badly the spreadsheet layer scaled as a business added entities, currencies and systems. The ERP records transactions well. It was never designed to be the analytical layer across five source systems and three legal entities.

What changed my view was watching the same pattern across manufacturing, FMCG and packaging clients. The finance teams that broke out of the rear-view-mirror trap did not buy a better reporting tool. They fixed the data foundation underneath it first, and the reporting tool they already owned suddenly worked.

The practical shift came with Microsoft Fabric. For a finance function, the part that matters is unglamorous and decisive — one place where the general ledger, subledgers, sales and operational data land together, governed, in a form analytics can read directly.

Azure Data Factory pulls the source data on a schedule — from SAP S/4HANA, SAP ByDesign, Dynamics 365 and the operational systems that hold volume and cost. It lands in OneLake, the single store underneath Fabric. The data integration work is where the reconciliation finally happens once, rather than every month by hand.

A semantic model then defines the financial logic in one place — margin, contribution, working capital, the cash conversion cycle — so every report draws on the same definitions rather than each analyst’s private version. Direct Lake lets Power BI query that data without the overnight refresh cycle that used to make “live” a generous word. The management pack stops being a monthly artefact rebuilt by hand and becomes a view that recomputes as the underlying figures change.

None of this removes the accountant’s judgement. It removes the three weeks of plumbing that used to sit in front of the judgement.

Abstract architecture is easy to nod along to and hard to picture. So here is a working example — a financial analytics report built on the same Microsoft stack, with illustrative figures.

Move between the views — profitability, working capital, cash, and the FP&A variance against budget. Change the entity or the period and the figures, the variance commentary and the trend lines recompute. This is the shape of a finance pack when the data underneath it is live, rather than rebuilt by hand each month.

A live financial layer earns its keep on four numbers that age badly when they are reported monthly.

Gross margin by product and customer. In an industrial business, margin moves with input cost, mix and discounting — week to week, not quarter to quarter. Seeing it a month late means the erosion is already booked before anyone can price or negotiate against it.

Working capital — specifically days inventory outstanding and days sales outstanding. Cash trapped in slow-moving stock or overdue receivables is the most expensive money on a mid-market balance sheet. DIO and DSO computed live, against operational reality, show where it is trapped while you can still act.

Cash position and the cash conversion cycle. Treasury decisions made on a month-old position are guesses dressed as decisions. A live view of cash in, cash out and the cycle between them turns the guess back into a decision.

Forecast variance. Budget versus actual is only useful if you see the gap opening, not after it has closed. When the financial layer sits on the same foundation as demand forecasting and operational data, forecast accuracy stops being a finance-versus-sales argument and becomes one number everyone reads the same way.

This is where I have to be honest about the limits, because the failure modes are predictable and worth naming before you commit budget.

First, it does not fix bad master data. If your chart of accounts is inconsistent across entities, or the same customer exists under four spellings, no platform will reconcile that for you. The data integration work surfaces the mess — someone still has to clean it. Budget for that, or the live dashboard will simply show wrong numbers faster.

Second, governance is not optional. The moment finance figures are live and self-serve, definitions matter more, not less. Who owns the margin definition? Who can change the semantic model? Without that discipline, you trade three reconciliations for thirty conflicting reports — the same sprawl problem in a finance costume.

Third, this is not a two-week build. A credible financial data foundation on Microsoft Fabric is a 12 to 18-week programme for a mid-market group, longer if the source systems are messy. Anyone promising a live close in a fortnight is selling the dashboard and skipping the foundation.

For a finance leader, the question is not whether the dashboard looks good in a demo. It is whether the close gets shorter, the numbers get trusted, and the team stops spending the first week of every month rebuilding workbooks.

The return shows up in three places. The close compresses — typically by several days once the data movement is automated. The finance team’s time shifts from assembling numbers to interpreting them. And operational decisions — pricing, stock, credit — start drawing on the same figures finance reports, which ends the standing argument about whose number is correct.

There is a quieter benefit that matters more over time. When the board, the operations director and the sales lead all read from the same live numbers, finance stops being the team that explains why the report is late and becomes the team that explains what the numbers mean. That shift — from scorekeeper to advisor — is hard to buy and harder to fake, and it only happens once the data foundation can be trusted without a week of manual checking in front of it.

You are not funding a reporting refresh. You are changing where the month-end effort goes — from plumbing to judgement.

Start small and concrete. Pick the one financial number that costs you most when it arrives late — usually margin or cash — and trace it back to its sources. You will almost always find it is assembled by hand from two or three systems, which is exactly why it is slow.

Prove the foundation on that one number first. Land the relevant data in OneLake, define it once in a semantic model, and put it live in Power BI. Six weeks of first value beats a fifty-slide transformation roadmap, and it tells you honestly whether your master data is ready for the rest.

If you do not have the in-house data capability to run this, that is the case for a Fractional CDO — senior data leadership on the engagement, accountable for the foundation rather than another tool, without a permanent hire.