Financial process automation: mapping the process before you automate it
Financial process automation should begin with a map of what actually happens, not what the procedure document says — the two differ in almost every finance function, and automating the documented version encodes a process nobody follows. Map by tracing one real transaction end to end, count the handoffs and the re-keying, then decide per step whether to delete it, simplify it, or automate it. A significant share of steps in a typical finance process exist only to compensate for an earlier step and disappear when that one is fixed.
The documented process is not the process
Every finance function has a procedure document. Almost none describe what happens. The gap is not negligence — it is accumulation. Someone worked around a system limitation in 2019, the workaround became the method, and the document was never touched.
Automating from the document produces a system that nobody recognises and everybody bypasses. Automating from the real process, with its workarounds visible, at least starts from the truth — and frequently makes it obvious that half the workarounds can simply be deleted.
How to map it in an afternoon
Formal process mapping methodologies are thorough and rarely finished. A cruder approach usually finds the same problems in a fraction of the time.
- Pick one real transaction that completed last month. A specific invoice, not a representative one.
- Trace it. Every system it touched, every person who handled it, every time a number was typed that already existed somewhere else.
- Count three things: handoffs between people, re-keying events, and waiting periods longer than a day.
- For each step, ask which of three things it is: value-adding, a control, or compensation for an earlier failure. Be honest about the third category.
- Delete what you can, simplify what you cannot delete, and only then consider automating what survives.
The re-keying count is the number that predicts the automation payback. A process with seven re-keying events has seven opportunities for a transposition error and seven places where integration pays for itself.
Controls are not overhead
The most common automation error in finance is treating a control as friction to be removed. Segregation of duties, approval thresholds and review steps look like delay on a process map, and they are — deliberately.
The correct move is to automate around a control rather than through it. An approval that took two days because the approver did not know it was waiting should take two hours; it should not take zero, because then nobody approved anything.
A useful test before removing any step: if this step did not exist, what would have to go wrong for anyone to notice? If the answer is "nothing, for months", it was a real control and it stays.
Where the time actually goes
Timing a finance process usually produces a distribution that surprises the people inside it. The activity that feels most burdensome is rarely the one consuming the most elapsed time.
| Stage | Typical elapsed share | Mechanical? |
|---|---|---|
| Waiting for source data | Largest single block | No — a dependency problem |
| Extracting and reformatting | Substantial | Yes — the clearest automation target |
| Calculating and checking | Moderate | Yes — belongs in code |
| Writing commentary | Moderate | Partly — draft yes, judgement no |
| Review and revision | Small but critical | No — keep it human |
Common questions
What is financial process automation?
Redesigning and then automating the sequence of steps a finance task passes through — extraction, calculation, checking, reporting and review — rather than automating a single tool in isolation. The redesign is the part that produces most of the benefit.
How do you map a finance process?
Trace one real completed transaction end to end, recording every system, handoff, re-keying event and delay. Then classify each step as value-adding, a control, or compensation for an earlier problem, and remove the third category before automating anything.
Why do finance automation projects fail?
Most commonly because they automate the documented process instead of the real one, or because they start with the most irritating process rather than the most repetitive. The first produces a system people bypass; the second produces a system that breaks on every exception.
Should controls be automated too?
Controls should be made faster, not removed. Automating around a control — so the approver is notified immediately rather than discovering the item days later — preserves the control while removing the delay that made it feel like friction.