The report that's actually three reports arguing with each other
Ask whoever owns this report what the hard part is, and it's rarely the assembly. It's the disagreement. The ERP says one figure for a number, the spreadsheet another department maintains says something close but not identical, and a third system's version is technically correct but measures something slightly different again. None of the three is wrong, exactly — they're counting on different cutoffs, or counting a slightly different thing, and someone has to know that. In manufacturing, that often means reconciling a production count from the shop floor against a shipped-units figure from the warehouse system and a booked-revenue figure from the ERP, none of which will match on a given day for entirely ordinary reasons.
That reconciliation knowledge — which system to trust for which number, what adjustment to apply when two sources disagree, which gaps are normal and which mean something actually broke — usually lives in exactly one person's head. It was never written down because it didn't need to be; the same person built the report every cycle and just knew. That's fine until they're on leave, or they move to a different role, or the report needs to go out twice as often and there isn't time to explain the rules to someone else first.
The manual way vs. the automated way
The manual version of this report starts with someone blocking out a morning. They log into three or four systems, export whatever each one has, open a spreadsheet that has been quietly accumulating manual fixes for years — a formula patched after a one-off exception, a row hidden rather than deleted, a tab nobody remembers the purpose of — and reconcile the exports by hand, applying rules they've never had to write down because they're the only one who applies them. The report goes out later that day, later still if anything about the source systems changed since last time.
The automated version reads the same systems, on the same schedule, but does the reconciliation with the rules made explicit instead of remembered, flags anything that doesn't reconcile cleanly instead of quietly picking a number, and assembles the result without anyone retyping figures into a template. What used to take a morning is finished before the person who reads the report has caught up on email, and the logic the report runs on is written down somewhere the whole team can see it, rather than living inside one person's habits.
| Manual | Automated | |
|---|---|---|
| Data pulled from | Someone logging into each system and exporting | Read directly from each system on the same schedule |
| Reconciliation rules | Remembered by whoever built the report | Written down once, applied the same way every cycle |
| Discrepancies | Resolved by judgment call, often undocumented | Flagged for review instead of silently overwritten |
| Commentary | Written from scratch each cycle, if there's time | Drafted from what actually changed, checked by a person |
| Distribution | One format, manually reshaped for other audiences | Delivered in the format each audience already expects |
| Traceability | A figure is trusted on faith or re-derived from scratch | Every figure traces back to its source and its rule |
How a build actually works
A report automation build breaks into four steps that run in sequence every time the report fires: reconciliation, assembly, commentary, and distribution. A fifth piece — the audit trail — isn't really a step so much as a record kept of the other four, so any number in the finished report can be traced back to where it came from.
Reconciliation: deciding which system is right before anything else
Before a system can automate reconciliation, a person has to do it once, on purpose, with someone who understands why the numbers disagree in the first place. That usually means sitting down with whoever currently builds the report by hand and turning their judgment calls into explicit rules: which system is authoritative for which figure, what adjustment applies when two sources are measuring slightly different things, and what size of gap is normal versus worth a second look. The same underlying problem — reconciling figures that were never going to match exactly — shows up in automating invoice processing, where a purchase order, a goods-received note, and a supplier invoice rarely agree to the cent and something has to decide what counts as close enough.
Assembly: turning reconciled numbers into the report's shape
Once the numbers agree, or are flagged as not agreeing, assembly is largely mechanical: populating the same layout, calculating the same derived figures, applying the same formatting the report has always used. This is the part manual reports tend to get wrong the least, if only because it's the part people are most careful about. It's still worth automating, because it's the part that eats the most clock time for the least judgment in return.
Commentary: flagging what changed, not just restating what happened
A report that only restates numbers is barely more useful than the spreadsheet it was built from. The part that actually earns someone's attention is commentary: this figure moved outside its normal range, this category looks different from last cycle, this gap between two source systems is wider than usual. A system can generate that kind of flag reliably, because it's comparing against history and thresholds rather than understanding why a number moved. What it should never do is decide what the anomaly means — that interpretation, and the call on whether it's actually a problem, stays with a person. It's the same human-in-the-loop boundary worth holding anywhere a system is trusted to notice something but not to conclude anything.
Distribution: the format each audience actually wants
The finance team wants a spreadsheet they can pivot themselves. Leadership wants a few sentences and a chart. A regulator, if the report is that kind of report, wants a specific fixed layout and nothing else — a stricter problem covered separately under automating compliance reporting. A build that produces one format and asks every audience to adapt to it has only solved half the job. The fuller version produces the same underlying numbers in whatever shape each recipient already expects, delivered to wherever they already look rather than one more dashboard nobody opens.
The audit trail: so a figure can survive being challenged
Every recurring report eventually gets challenged — a number looks wrong, or just surprising, and someone asks where it came from. In a manual process the honest answer is often "let me rebuild it," because the reconciliation happened once, in someone's head, and left no trace behind. An automated build keeps a record of every step instead: which source system a figure came from, which reconciliation rule applied if the sources disagreed, and what the number looked like before and after that rule ran. That record turns "let me rebuild it" into a direct answer, which matters more than however long the original reconciliation used to take.
Two things worth checking before you automate a report
Two honest prerequisites are worth naming here, because skipping either one wastes the investment.
The first is that the numbers have to be reconcilable at all. If two systems disagree and nobody currently knows which one is right, automating the report doesn't fix that — it just runs the disagreement faster and hands it back with more apparent confidence than it deserves. That decision has to get made by a person first, even if it only has to be made once, before any build starts.
The second is worth asking honestly, and it's the one people are least inclined to ask: is the report still read? A recurring report that was genuinely useful two reorganizations ago sometimes keeps getting produced out of habit long after the person who originally asked for it has moved on, and nobody else opens it. Automating a report nobody reads is a fast way to spend money solving a problem that no longer exists. Finding that out during scoping — that a report has gone unread for months — is itself a useful result, and a legitimate outcome of asking the question before committing to a build.
What it connects to
A report automation build is only as good as its reach into the systems the report already draws from. Typically that means:
- The source systems themselves — an ERP, a CRM, point-of-sale, a production or inventory system, whatever the report currently pulls numbers from — read directly rather than through someone's manual export.
- The spreadsheet or template the report already uses, at least at first, so the output looks like what recipients already expect instead of forcing them to learn a new format on day one.
- Wherever the report gets distributed — email, a shared drive, a Slack or Teams channel, a dashboard — matched to where each audience already looks rather than a new destination they have to remember to check.
- A record of past versions of the report, so commentary has something to compare this cycle against instead of restating a number with nothing to measure it by.
None of this requires replacing the systems already in place. A custom AI agent built for this job reads from what already exists and writes the finished report to wherever people already expect to find it.