An invoice goes out with the wrong media pass-through on it. A client sees it before you do. Someone has to explain, someone has to credit it, and the first question in the room is almost always the same: who did this?
It is a natural question and, in my experience, the wrong one. It feels like accountability, and it is usually just the fastest available way to close a conversation. The person gets a talking-to, everyone agrees to be more careful, and the process that produced the error goes back to work unchanged, ready to produce it again next month with a different name attached.
Most of what goes wrong belongs to the system
W. Edwards Deming spent a career making a point that still has not fully landed in finance departments: the overwhelming majority of variation in an organization comes from the system, not from the individuals inside it. He put the split at roughly 94 percent system and 6 percent people, and was candid that the exact number was an estimate. The proportion is what matters.
The system, in Deming's sense, is everything management decided: how work arrives, what the sequence is, which tools people are given, how much time they get, what the standard is and whether anyone wrote it down. People operate inside that design. When the design allows an error, the error will eventually happen, and it will happen to whoever is on shift.
Which gives you a clean test. Ask whether a capable, well-intentioned person following your current process could have made the same mistake. If the answer is yes, you have a process problem, regardless of whose initials are on the invoice.
Four familiar problems, none of them people problems
These are the four I see most often in agency finance, across advertising, digital, and creative shops alike. In each one, the instinct is to name a person, and the fix is somewhere else entirely.
Timesheets come in late
Nobody enjoys timesheets, so the standard response is a reminder email with a firmer tone. Look at the design instead: entry takes eleven clicks, the project codes do not match what anyone calls the work, and nothing downstream visibly depends on it. Late timesheets are a friction problem and a feedback problem, and both are fixable without a single conversation about discipline.
WIP surprises at month-end
Unbilled work turns up three weeks after it was delivered, and the month lands differently than anyone expected. That is not a controller who missed something. That is a process with no checkpoint between delivery and billing, which means the information has nowhere to surface until the close forces it.
The invoice that went out wrong
Ask what would have had to be true for the error to be caught. If the answer is "somebody would have had to notice," you do not have a review step, you have a hope. Pass-through media and production are the most common place this bites agencies, because the numbers are large and the coding is easy to get wrong. Getting that structure right in the books removes a whole category of these.
The close keeps slipping
A close that runs long is almost never one slow person. It is a sequence with unclear dependencies, where three tasks wait on the same approval and nobody can see the queue. Publish the sequence, name the dependencies, and most of the delay resolves itself.
Blame is expensive, and the bill comes due in data
Here is the practical argument for CEOs who find all of this a little soft. A finance function runs on early, honest information. You need to hear about the underbilled project in week two, not at the close. You need the account lead to flag that the scope has drifted while there is still room to do something about it.
Blame ends that flow. People who expect to be held personally responsible for system failures learn to report problems late, quietly, or with the edges sanded off. The reporting does not stop because they stopped caring. It stops because they are managing their exposure, which is a rational thing to do. And the moment it stops, you lose the only signal that shows you where the process is weak.
So you end up paying twice: once for the original error, and again for the silence that follows it. The agencies with the cleanest numbers are almost never the ones with the strictest culture. They are the ones where telling finance about a problem early has never once gone badly for anyone.
AI does not fix a broken process, it scales one
This has been true for a long time. What changed is the speed at which a flawed process now runs.
When you automate, you encode the logic you already have. If the billing process depends on someone noticing that a number looks off, automation removes the noticing and keeps the dependency. You get the same error, more often, with less friction to slow it down and fewer people close enough to catch it. The technology is an amplifier. It has no opinion about whether the thing it is amplifying is sound.
The sequence that works is unglamorous: understand the process, fix its logic, then automate the part that is genuinely repeatable, and put a person on verifying the output rather than cleaning up behind it. That is the discipline behind the AI systems we build for agencies. We map the process first, because the alternative is buying a faster version of your current problem.
Five questions to ask before you name anyone
When something goes wrong, these five come first. They take about ten minutes and they change the conversation from who to why.
Did the person have what they needed?
The input, the approval, the access, the number from the other department. A large share of errors are simply someone doing their best with information that never arrived.
Is the standard written down?
If the correct way to do the task lives in one person's head, then the process is that person, and it will fail whenever they are on holiday.
Did the tool make the wrong thing easy?
Defaults, dropdown order, a field that accepts anything. Software quietly sets the odds on human error, and it is usually cheaper to change the software than to change the habit.
Was there time to do it properly?
Work compressed into the last afternoon of the month produces predictable mistakes. If the calendar guarantees a rush, the calendar is the cause.
Would anything have caught it?
Not "should someone have noticed," but was there an actual step where the error becomes visible before the client sees it. If there is not, add one, and put it where the cost of being wrong is highest.
Genuine performance problems do exist, and they show up as a pattern that survives all five answers: the process is clear, the tools work, the time is there, the standard is written, and the same person is still off. That is a management conversation, and it is a fair one. It is also much rarer than the number of times the question gets asked.
Common questions
What does “fix the process, not the person” mean?
It means treating a mistake as evidence about the system that produced it rather than as a verdict on the individual involved. W. Edwards Deming argued that most of the variation in any organization belongs to the system leadership designed, not to the people working inside it. If the same error can happen again to a different person, the process is the problem.
Why is blaming individuals bad for a finance function?
Because it costs you information. People who expect blame report problems late, quietly, or not at all, and a finance function runs on early, honest data. Once the reporting stops, you lose the only signal that tells you where the process is weak.
How do I tell a process problem from a performance problem?
Ask whether a capable, well-intentioned person following the current process could have made the same mistake. If yes, it is a process problem, no matter who made it. Genuine performance issues show up as a pattern that persists after the process is clear, the tools work, and the standard is written down.
What happens if you automate a broken process with AI?
You get the same errors faster and in higher volume, with less chance to catch them. Automation is an amplifier, not a corrective. Fix the logic of the process first, then automate the part that is genuinely repeatable, and keep a human verifying the output rather than cleaning up after it.
The bottom line
Treating errors as evidence rather than misconduct is not leniency. It is the more demanding standard, because it puts the work on leadership: you have to look at the design you built and change it. That is harder than a conversation about being more careful, and it is the only version that stops the error from coming back.
It is also, in the end, why we do this work the way we do. A good CFO is a systems thinker, and a system that runs on blame is one that has quietly stopped telling you the truth. Build the process and the controls properly, give people a place to see the numbers as they happen, and most of what you were about to hold someone accountable for simply stops occurring.