Data Architecture
The Report That Took Fifteen Days
Somewhere in most organisations, a team spends two weeks every month producing a report that nobody questions, nobody could rebuild from scratch, and nobody notices until the person who makes it leaves. This is not a resource problem. It is an architecture problem — and the real cost is rarely what anyone calculated.
The month-end close that requires three people and four days. The weekly management pack assembled by copying from six different systems into a spreadsheet maintained by one analyst who has been doing it for three years. The quarterly investor report built on a set of macros written years ago that nobody fully understands, held together by institutional memory and collective reluctance to touch it. Most organisations have at least one of these. Many have several.
What the process actually looks like
Export from system A. Paste into master template. Run the macro. Correct the errors the macro introduces. Cross-reference against system B. Identify the dozen records that never reconcile properly and handle them manually, as always. Format. Send to fourteen people. Wait. Receive four responses with corrections. Rebuild. Send the corrected version. This is not a description of an unusually dysfunctional organisation. It is a reasonably accurate description of how financial and operational reporting works in most mid-sized businesses.
Why it persists
The person running the process has accepted it as normal — it has always worked this way. Their manager does not know what the process actually involves, only that it delivers. No one has calculated the full cost. And the institutional knowledge embedded in the spreadsheet makes changing it feel riskier than continuing. The result is a reporting process that is expensive, fragile, structurally unauditable, and entirely dependent on one person continuing to show up.
The cost nobody calculates
The arithmetic is straightforward. Three people, four days per month, twelve months: somewhere around 144 person-days per year allocated to a process that could be automated. That is before accounting for the decision cost — management and investors receiving information fourteen days after period close, making choices on data that is structurally out of date. Add the risk cost (one resignation away from a reporting blackout) and the compliance cost in regulated environments where manual reconciliation does not satisfy modern audit trail requirements, and the real cost of the fifteen-day report is rarely what anyone estimated when they decided to keep running it.
What the architecture looks like after
The automated equivalent sources data directly from operational systems via scheduled extracts or APIs. A transformation layer — versioned, documented, testable — applies the business logic that was previously buried in macros. The output layer updates on a defined schedule, with exceptions flagged for human review. Routine production requires no human intervention. The report that took fifteen days takes four hours. Then thirty minutes. Then it runs overnight and the numbers are available when the team arrives in the morning.
The governance question that automation surfaces
When you replace a manual reporting process with an automated one, every implicit decision — the rounding rule, the edge case for cancelled contracts, the definition of "active client" — must be made explicit. This is uncomfortable. It is also the point. The manual report was hiding design decisions that should have been documented from the start. Automation does not create those decisions. It reveals them, and forces the organisation to own them rather than leaving them encoded in formulas that nobody has reviewed in four years.
The rule worth applying to every reporting process
Any data transformation that a human repeats on the same schedule, on the same data, producing the same output format, should be automated. If it cannot be automated as it stands, the data architecture needs to change until it can. Manual reporting is technical debt measured in person-days rather than code lines. It accumulates at the same rate, with the same consequences, and becomes progressively harder to address the longer it is treated as a permanent fixture rather than a design problem to be solved.
Where to start
Find the report that takes the longest to produce. Document every step, every data source, every manual intervention. That list is your project scope. In most cases, a focused four to six week engagement is enough to move from the fifteen-day report to the overnight run. The constraint is almost never technical. It is the willingness to make explicit the decisions that the spreadsheet has been quietly making for years.