From a two-day manual close to a five-minute pipeline.
A finance team was spending two full days every month consolidating their P&L by hand. The pipeline that replaced it runs in under five minutes. The interesting part was not the automation — it was the week spent writing down rules that had never been written down.
Two days, every month, forever
[FILL: a [X]-person finance team at a [industry] company] closed their books the same way every month. Export from the source systems, paste into a master workbook, reconcile the differences by hand, rebuild the summary sheet, format it, send it.
Two days of a qualified analyst's time spent moving numbers between cells. Not analysis. Not judgement. Copying.
The direct cost was the obvious problem, but it was not the worst one. Because the close needed two clear days from a specific person, the reporting deadline moved depending on who was on leave. A process that should have been a fixed date on a calendar was in practice dependent on one individual's availability.
Three problems, in order of severity
The logic lived in one person's head
The workbook had accreted rules over several years. Mappings, exclusions, and adjustments that made sense at the time and were never documented. One person could run it confidently. Nobody else could. This was the real risk, and it was the one nobody had named.
Every run was a fresh chance to be wrong
Manual paste steps with no validation. A wrong range selection, a column shifted by one, a stale sheet not refreshed — any of these produced a plausible-looking number that would go to the board with nothing to catch it.
No audit trail
When a figure was questioned, reconstructing how it was derived meant redoing the work and hoping the same answer came out. There was no record of which source file produced which number, or what had changed since last month.
Writing down rules that were never written down
The first week produced no working code. It was spent sitting with the person who ran the close and asking, for each step, why it was done that way.
This is consistently the part that takes longest and the part that gets skipped. A workbook that has run for years contains real institutional knowledge: this cost centre gets excluded because of a restructure three years ago, that account is reclassified because of how the source system posts it, this adjustment exists because of a known timing difference. None of it is written anywhere.
Automating without extracting that knowledge first produces a pipeline that is fast and quietly wrong. The rules have to be surfaced, questioned, and documented before any of them are encoded. Several turned out to be obsolete — artefacts of a system that had since been replaced — and were removed rather than faithfully reproduced.
The pipeline
A Power Automate and Power Query pipeline, chosen because the team was inside a Microsoft 365 estate and needed something their own analysts could open and adjust after handover. A more sophisticated stack would have been technically defensible and practically worse.
Scheduled source retrieval
Exports pulled automatically from [FILL: source systems] on a schedule, with alerting when an expected file does not arrive rather than proceeding with stale data.
Rules as configuration
The consolidation and mapping logic implemented as documented, versioned rules rather than formulas embedded in cells, so they can be reviewed and changed without opening the workbook.
Validation before publication
Totals checked against control figures. If a check fails the run stops and raises a flag. It never quietly publishes a number it cannot verify — the single most important design decision in the build.
Output and notification
The finished P&L written to [FILL: destination] with the team notified, and every run logged so any figure can be traced back to the exact inputs that produced it.
Proving it before trusting it
The pipeline ran in parallel with the manual process for [FILL: X] cycles. Both outputs were compared line by line every month until they agreed exactly. Only then was the manual process retired.
Two discrepancies surfaced during that period. Both turned out to be errors in the manual process rather than the pipeline — which is common, and is a large part of why the parallel run is worth the delay.
The first question any finance person asks about automation is how they can know the numbers are right. Answering it with a demonstration rather than an assurance is what makes the handover work. Skipping this step to deliver faster is the most expensive shortcut available in this kind of project.
What actually changed
Time per close
Around 16 hours of manual work, down to a run of under five minutes. Roughly 190 hours a year returned to work that needs judgement.
Who can run it
Previously one person. Now anyone on the team, because the rules are documented and the process is not a workbook only its author understands.
Audit trail
Previously reconstructed by redoing the work. Now logged on every run, with each figure traceable to the input that produced it.
Close timing
Previously dependent on one person having two clear days. Now a fixed schedule that does not move.
What made it work
Not the tooling. The pipeline is unremarkable Power Automate and Power Query, and a competent developer could build the mechanics in days.
What made it work was the week spent documenting rules nobody had written down, and the decision to build validation that stops the process rather than letting it run to completion on data it cannot verify. In finance, a fast wrong number is worse than a slow right one, and most automation projects optimise for the wrong one of those.
The same pattern applies to reconciliation, invoice processing, and most of the data pipeline work I do. The engineering is rarely the constraint. Understanding what the existing process actually does, before replacing it, almost always is.
Common questions
Around [FILL: X] weeks end to end, of which a significant portion was not writing code. Documenting the consolidation rules that had never been written down took longer than implementing them, and the parallel validation period ran for [FILL: X] cycles before the manual process was retired.
The pipeline ran alongside the existing manual process and both outputs were compared line by line until they agreed exactly. Only then was the manual process retired. Beyond that, the pipeline validates totals against control figures on every run and stops rather than publishing a figure that fails the check.
It fails loudly. Any run that cannot validate raises a flag rather than producing output. That is a deliberate choice: a pipeline that silently publishes a wrong number is more dangerous than one that visibly stops, because the wrong number gets used.
The specifics differ but the pattern is common: a workbook that has grown over years, logic that lives in one person's head, and manual paste steps with no validation. If that describes your close, the same approach applies. A free 30-minute review will tell you whether it is worth doing in your case.
Does your close look like this?
A free 30-minute review will tell you whether your process can be automated safely, roughly what it takes, and what it would cost — before any commitment.