The monthly management pack is built the same way every month. Someone exports a sales listing, someone else copies the stock figures from another system, and a third person pastes both into a workbook with formulas that were written two years ago. The pack goes to the directors on the fifth working day. It looks professional, and it has never been wrong enough for anyone to notice.
That last sentence is the problem. The pack has never been checked in a way that could prove it right, either.
The condition: reports that are assembled, not produced
There is a difference between a report that a system produces and one that a person assembles. An assembled report depends on a sequence of manual steps: exporting, filtering, copying, pasting, adjusting and re-checking. Each step is small, and each is carried out by someone who is also doing a day job. The report is the sum of those steps, and nobody holds the whole chain in view.
Signs that a report is assembled rather than produced include:
- It takes a fixed number of days to prepare, and that number grows when someone is absent.
- The preparer can describe the steps from memory but there is no written procedure.
- A "final" version is emailed around, and later corrections arrive as a second "final".
- Adjustments are made by typing over formula results, with no record of why.
- If a number looks odd, the first check is whether someone made a slip, not whether the source changed.
The realisation: the risk is not the error, it is the invisibility
Everyone accepts that manual work produces mistakes. The more important point is that manual reporting produces mistakes that cannot be seen. A system error usually announces itself: a failed import, a mismatched total, a message on screen. A manual error looks exactly like a correct number. The pack reads smoothly, the totals add up, and a misplaced filter or a pasted range that stopped one row short does not change its appearance.
So the exposure is made of three things at once: the chance of an error, the chance that it will be undetected, and the length of time it will be relied on before anyone finds out. Directors set budgets, approve credit and commit to suppliers using the pack. The risk is carried by decisions, not by the spreadsheet.
Identification: a control and assurance gap
This is a data-integrity and reporting-assurance problem. The visible symptom is that the reporting cycle is slow and stressful. The common assumption is that the preparer needs to be more careful. The structural cause is that the process has no checks built into it, so quality depends entirely on individual attention.
Governments have faced the same issue with analytical models. HM Treasury published a review of quality assurance of the analytical models that inform government policy. It covers best practice and gives practical recommendations for making models robust and trustworthy. The context is far removed from a South African distribution business, but the principle transfers directly: if a number informs a significant decision, the way it was produced deserves the same kind of scrutiny as the decision itself.
Diagnosis: where the invisible risk comes from
An illustrative example, not a client case. A mid-sized logistics firm reports gross margin per customer each month. The workbook pulls revenue from the billing system and costs from a fuel and driver-time spreadsheet. In March, a new tariff code is added to the billing system. The workbook's lookup does not recognise it and silently returns zero costs for those jobs. Margins for the customers concerned look excellent. Two months pass before a director questions why the best-performing customer is also the one who complains most.
The mechanisms are typical:
- Information: source data changes (a new code, a renamed field, a different export layout) without the workbook being told.
- Process: there is no reconciliation back to the source system, so a missing row is not noticed.
- People: one person knows how the workbook works, so there is no independent review and nobody to catch a slip.
- Systems: there is no history of what changed, so when a figure is questioned, it cannot be traced.
Our article on when only one person knows where the report's numbers come from covers the dependency side of this in more detail, and why reporting problems often begin with data capture looks upstream.
The commercial value at stake
The value of fixing this is mostly risk reduction, decision quality and capacity. Risk, because decisions made on a wrong number can be costly and hard to reverse, and a business that cannot demonstrate how its figures were derived is harder to defend when a lender, auditor or partner asks. Decision quality, because leaders who trust the pack spend less time questioning it. Capacity, because the days spent assembling the pack can be returned to analysis.
We do not quote an error rate or a cost, because they depend entirely on the specifics of the report. What we can say is that a business cannot estimate the exposure until it can see which reports are assembled by hand, who prepares them and what they feed.
Possibility: reports that carry their own checks
The alternative is to move the repeatable parts of the report into a governed process, so that figures flow from source systems to the report without being retyped, and so that checks are part of the flow. This does not require a large platform. It requires deciding which numbers matter, where they come from and who is accountable for them.
Microsoft's documentation offers a good illustration of the ideas involved. Its endorsement feature in Fabric and Power BI describes three labels: promoted, certified and master data. A certified item has been reviewed by an authorised reviewer who confirms it meets the organisation's quality standards and can be treated as reliable and authoritative. That is a formal way of expressing something every business needs, namely a clear distinction between a number that someone has checked and one that someone has merely produced. The Power BI scorecards documentation draws a related distinction, noting that manual goals do not update automatically because they are not connected to a data source, while connected goals refresh with the underlying data. Where a figure must be entered by hand, the system at least knows it is manual.
Intervention: make the invisible visible first
- Inventory the manual reports. List each recurring report, who builds it, how long it takes and what decisions rely on it.
- Rank by consequence. Begin with the reports that feed credit, pricing, payroll, tax or board decisions.
- Add reconciliations before automation. A simple check, such as comparing the total of the report to the total in the source system, catches many slips at almost no cost.
- Write the procedure down. Even a one-page checklist lets a second person run or review the report.
- Remove the copy and paste. Connect the report to its sources so numbers flow rather than being retyped, and keep a log of changes.
- Label what is checked. Make it clear to readers which figures are system-produced, which are manual and which have been reviewed.
For the wider picture of why dashboards alone do not solve this, see why more dashboards do not automatically create better decisions.
Practical diagnostic questions
- Which report that your directors rely on is built by copying and pasting?
- When was the last time its total was reconciled to the source system?
- If the person who builds it left, how long before someone could produce it with confidence?
- Can you tell, for any figure, who changed it last and why?
The bottom line
Manual reporting creates invisible risk because its failures look like successes. The pack is on time, it reads well and it is trusted, until a decision based on it goes wrong. Making the process visible, checkable and less dependent on one person does not require a grand programme. It starts with knowing which reports are assembled by hand and what each one is used for.
Sources and further reading
- Review of quality assurance of government models (last verified 10 October 2026)
- Endorsement overview - Microsoft Fabric (last verified 10 October 2026)
- Get started with goals in Power BI - Power BI (last verified 10 October 2026)
Related Mellorca reading
- When Leadership Cannot See Bottlenecks Until Customers Complain
- When KPI Tracking Becomes a Data Collection Exercise
- The Operational Blind Spots Created by Periodic Reporting