An agency asked us to look at why their gross margin had moved four points in a quarter with no change in rate card, staffing, or client mix. Nothing in the P&L explained it. The close was clean, the reconciliations tied, and the reporting had never been more punctual.
The cause turned out to be a rule somebody had written eighteen months earlier, when a production coordinator was coding pass-through media by hand. Her rule was roughly right and she broke it constantly, because she knew which vendors were exceptions and quietly handled them. When the coding was automated, the rule went in and the judgement did not. The automation was working perfectly. It was faithfully applying an instruction that had never actually been correct on its own.
Software has no instinct for “that looks wrong”
Every manual process contains two things: the documented rule and the undocumented correction. The correction is the part where a person looks at an invoice, notices it does not fit the pattern, and does something else. It is unglamorous, unpaid, usually invisible on any org chart, and it is holding a surprising amount of your reporting together.
Automate the rule and you remove the correction along with it. That is the whole mechanism. Not a technology failure, not a bad model, just the removal of a control that nobody had written down and therefore nobody thought to replace. The defect rate does not rise because the software is worse than the person. It rises because the person was silently patching the process and the software will not.
This is the same argument I have made about fixing the process rather than the person, run in the other direction. There, the point was that blaming an individual for a system's output wastes the information. Here, the point is that praising an individual's workaround hides it. Both end in the same place: whatever is real about your process needs to be written down before anything else happens to it.
Four agency processes that punish early automation
These are the ones we find most often, and they share a shape. In each case the rule looks simple and the exception carries the money.
Pass-through media coding
Gross versus net is not a coding convention, it is a judgement about who bears the risk on each contract, and it varies by client and sometimes by campaign. A single blanket rule will be right most of the time and wrong on your largest arrangements, which is the worst possible distribution of errors. It also moves reported revenue, so the mistake is invisible on the margin line and glaring to a lender. We go through this properly in the agency accounting guide.
Time entry and utilization
If timesheets are late, rounded, or reconstructed on Friday afternoon, automating anything downstream of them multiplies the fiction. Automated utilization dashboards are particularly dangerous here because the output looks authoritative and the input is a guess. You have not measured utilization, you have industrialised somebody's memory of last week.
Revenue recognition on retainers with scope creep
The contract says one thing, the delivery says another, and the difference is being carried informally by an account lead who knows the client will not be invoiced for it. Automate the schedule and you lock in a recognition pattern that does not match the work. The variance then arrives all at once, at year end, in front of your accountant.
Approval thresholds
Almost every agency has an approval limit that is routinely bypassed for good reasons, usually speed on a live campaign. Encoding the official limit produces a bottleneck that the team will immediately learn to route around, and now the workaround is undocumented too. Encoding the real behaviour means writing down that there is effectively no limit, which tends to end the conversation quickly and usefully.
Three questions before you build anything
You do not need a maturity model. You need three answers, and they take an afternoon.
Can somebody state the rule in one sentence without saying “usually”? The word usually is where the undocumented correction lives. Every time it appears, ask what happens in the other cases and who decides. Keep going until the hedging stops. What you have written down at that point is the actual specification.
Do two people produce the same answer from the same inputs? Give the same five transactions to two people who do the work and compare. If they disagree, you do not have a process, you have two processes with a shared job title, and automating either one will break something for somebody.
Can you describe what a wrong result looks like? If nobody can say how they would spot a bad output, then nobody will spot one. That is not an argument against automating. It is an argument for building the check at the same time as the automation rather than six months later, once the error has compounded through two quarters of reporting.
How to sequence it
The instinct after reading the above is to fix everything first. Do not. A comprehensive process overhaul ahead of any tooling is how these programmes die, slowly, in a workshop.
Scope the fix to what you are automating next
One workflow. Get its rule written, agreed, and signed off by the person who actually does it. That is usually a week of work and it is the cheapest week in the project. Everything else stays as it is until its turn comes.
Write the standard down where the automation can see it
The rule should live next to the build, in plain language, not in somebody's head or in a deck from the discovery phase. When the rule changes, and it will, you want one place to change it and an obvious trail showing that you did.
Instrument the automation, not just the output
Every automation should report on its own behaviour: how many records it handled, how many it declined, how many needed a human. A silent automation is an unmonitored one. This is why the systems we build each report their own health, and why the exception count is the number we watch rather than the throughput.
Keep a human as verifier
The person who used to make the correction is the right person to review the exceptions, and the job is genuinely better. What you must not do is leave them cleaning up after a system that runs unsupervised, which is the same task with less control and no credit. This is the difference between removing work and relocating it.
Reconcile against something outside the system
Bank, vendor statement, client purchase order, media plan. An automated process that only ever agrees with itself will drift and stay internally consistent the whole way. This is where a genuinely connected dataset earns its keep, and where the Hub does the work: four systems that normally do not talk, reconciled against each other rather than each confirming its own version.
The specification is the deliverable
Here is the part that surprises people. The most valuable output of the first month of an automation project is rarely the automation. It is the written description of how the work actually gets done, which in most agencies has never existed.
Specifying a workflow tightly enough for software to execute it is a forensic exercise. Every undocumented judgement, every informal exception, every place where two departments believe different things about the same number, has to surface, because the build cannot proceed until it does. Firms go into these projects wanting efficiency and come out holding something more useful, which is an accurate map of their own operations.
That map is worth having whether or not you build anything. It survives the person who leaves. It makes onboarding a new controller a week rather than a quarter. It is what lets you answer a lender or a buyer with confidence rather than with a spreadsheet assembled overnight. For a creative agency preparing for a raise or a sale, the written process is frequently the difference between a clean diligence and a discount.
So the framing we use is not “automate the finance function.” It is: describe it accurately, fix what the description reveals, then automate the parts that have earned it. That order is slower for about three weeks and faster for the following three years.
Common questions
Why does automating a bad process make things worse?
Because the defect stops being visible. A person doing a task badly still notices the odd thing, hesitates, and asks a question. Software does not hesitate. It applies the rule it was given to every transaction at the same speed, so a coding error that used to appear a handful of times a month now appears in every record, and nobody is holding the paperwork long enough to feel that something is off.
How do you know whether a process is ready to automate?
Three tests. Someone can state the rule in one sentence without using the word "usually." Two people who do the work independently produce the same answer from the same inputs. And you can say what a wrong result would look like. If any of the three fails, you do not have a process yet, you have a habit, and automating a habit just makes it permanent.
Should we fix our finance processes before adopting AI?
Fix the parts you are about to automate, not everything. A full process overhaul before touching any tooling is how programmes die of exhaustion. Take the single workflow you want to automate first, get its rule written down and agreed, then build. The scoping work is usually a week and it is the difference between an automation that compounds and one that has to be unwound.
Can AI help find the broken parts of a finance process?
Yes, and this is the underrated use. The act of specifying a workflow tightly enough for software to execute it surfaces every undocumented judgement call in the process. Most of the value in the first month of an automation project comes from that discovery rather than from the automation itself. You end up with a written standard, which is worth having whether or not you build the robot.
The bottom line
AI does not improve a process. It executes one, at scale, without judgement and without complaint. Whatever you hand it, you get more of. That is excellent news if the process is sound and expensive news if the soundness was coming from a person quietly correcting it every Tuesday.
None of this is a reason to wait. It is a reason to spend the first week writing down what is real, and to build the check at the same time as the build. That sequencing is most of the job, and it is the part a fractional CFO should be holding, because it is a question about controls and reporting integrity rather than about software.