Every finance leader already agrees with the headline. Standardize before you automate is not a controversial claim; it is closer to a platitude. And yet finance functions automate unstandardized processes constantly, at considerable expense, with predictable results.
The gap between agreement and behaviour is not caused by ignorance. It is caused by a definition. "Standardized" is almost never defined in terms anyone can test, so the question "are we standardized?" is answered by feel — and it is answered yes by teams who have simply been doing the same non-standard thing for a long time. A test nobody can fail is not a test.
This piece does three things: it defines standardization as four observable conditions, explains the specific mechanism by which automating without them makes the outcome worse rather than merely disappointing, and sets out what to do when commercial pressure arrives ahead of readiness.
The claim
Automating a process that is not standardized does not produce a faster version of that process. It produces a faster, more expensive, and less correctable version of its variation — and it removes the people who were absorbing that variation.
That last clause is the part that gets missed. In a manual process, human judgement is silently doing enormous amounts of exception handling. Nobody has documented it because it does not feel like work — it feels like knowing your job. When the process is automated, that absorption layer is withdrawn, and the variation it was hiding becomes visible all at once, usually at period end, usually to the controller.
What "standardized" actually means
Standardization is not documentation. A documented process can be wildly variable; a document only records one version of it. Four conditions must hold simultaneously.
| # | Condition | The test | What it looks like when absent |
|---|---|---|---|
| 1 | One way | Two people performing the task independently produce the same output from the same inputs | Every preparer has "their way"; reviewers can tell who prepared a schedule by looking at it |
| 2 | Defined inputs | The data the process consumes has an agreed source, format and cut-off | Preparers pull their own extracts; two schedules disagree and both are defensible |
| 3 | Named exceptions | The exception cases are enumerated, and each has an owner and a rule | Exceptions are handled by whoever notices; the handling is invisible to everyone else |
| 4 | Stable under absence | The process completes correctly when the most experienced person is on leave | The close survives on one person's memory; nobody says this out loud |
Condition 4 is the one worth dwelling on, because it is both the most diagnostic and the easiest to check. If your period-end close is materially harder when one specific person is away, you are not standardized — you are experienced. Those are different things, and only one of them survives automation.
The distinction matters because experience is portable to a machine only after it has been made explicit. Standardization is precisely the act of making it explicit. Automation software does not perform that act; it assumes it has already happened.
Why the failure mode is worse than "it did not help"
Three mechanisms compound, and they compound in a specific order.
First, variation becomes throughput. A manual process performs badly at scale, which acts as a brake — errors are produced slowly enough to be caught. Automation removes the brake. The same defect rate applied at machine speed produces materially more downstream work, concentrated at exactly the moment there is least capacity to absorb it.
Second, the absorption layer is withdrawn. The people who were quietly reconciling the inconsistencies are reassigned, because the business case said they would be. The variation does not go away; the compensating control does.
Third, and most expensively, the configuration inherits the variation. Where a process has three unofficial variants, the implementation must either force a single path — which is the standardization work, now being done mid-implementation by a systems integrator on day rates, without authority to make process decisions — or encode all three. Encoding all three is what usually happens, because it is the path of least resistance during a go-live. The organisation has now paid to make its variation permanent, and considerably harder to change than it was in a spreadsheet.
That third mechanism is why the rule is not merely about sequencing efficiency. Getting the order wrong does not just delay value. It converts a soft problem into a hard one.
The maturity reading
Expressed against the dilynx maturity spine, the rule is a statement about which level transition is being attempted:
| From | To | What it requires | What software contributes |
|---|---|---|---|
| L1 Manual | L2 Standardized | Process design, decisions about how work will be done, and the authority to enforce one way | Very little. This is organisational work. |
| L2 Standardized | L3 Automated | A stable process to encode, and clean inputs to feed it | This is what the software is for |
| L3 Automated | L4 Optimized | Measurement, exception analysis, continuous adjustment | Substantial |
The failure is always the same shape: an organisation at L1 buys a tool designed to move an organisation from L2 to L3. The tool is not defective and the vendor has not mis-sold — the buyer has skipped a level that no product can perform on their behalf, because it consists of decisions only they have the authority to make.
This is also why the close-acceleration path we publish sequences standardization first and ERP data integration second, before any automation stage. The order is not a preference. It is a prerequisite chain: each stage requires the previous stage's maturity to have been reached, or it delivers a fraction of its value.
What good sequencing looks like in practice
The rule is often heard as "delay everything," which is not what it says and is bad advice. Standardization is not a phase to be completed before anything else begins; it is a prerequisite that applies per process, and processes can be at different levels.
- Sequence by process, not by programme. Reconciliation may be at L2 while the close
calendar is at L1. Automate reconciliation now; standardize the calendar in parallel. A single programme-wide gate is what makes people skip the gate.
- Standardize the highest-volume variant first, not the most painful one. The painful
exception is usually rare, and designing the standard around it produces a standard that fits nothing.
- Do the exception enumeration before the vendor demo, not after. A demo against your
real exception list is a genuinely different conversation from a demo against a happy path — and it is the fastest way to find out whether a product fits.
- Give standardization an owner with authority. It fails as a documentation exercise
and succeeds as a decision-making exercise. Somebody has to be able to say "we will now all do it this way" and make it stick.
When the pressure arrives before the readiness
The uncomfortable case: the budget cycle, an audit finding, or an ERP end-of-life forces a decision before the process is ready. Three honest options, in preference order.
- Standardize inside the implementation, deliberately and with authority. Viable, but
only if process-design decisions are explicitly in scope, owned internally, and made before configuration rather than during it. This is the most common intention and the least common execution.
- Automate the stable subset. Narrow the scope to the processes that genuinely meet
the four conditions. A smaller automation that works is worth more than a broad one that encodes variation — and it builds the credibility to fund the rest.
- Defer, and capture the standardization gains that require no new spend. Moving from
L1 to L2 is largely organisational work. It is the option that looks least impressive in a board paper and most often produces the better twelve-month outcome.
Option 3 is a first-class recommendation in our decision model, not a fallback. When a hard constraint is active — a budget freeze, a headcount cap — deferring the purchase and taking the standardization gains is frequently the highest-return move available.
The honest counter-argument is that modern software absorbs variation better than this framing allows, and it is partly right.
Configurable workflow tools, and increasingly AI-assisted matching and coding, genuinely do handle a wider range of input variation than the rules engines of a decade ago. A reconciliation tool that can match on fuzzy criteria tolerates messier sub-ledger data than one requiring exact keys. Some standardization that used to be prerequisite is now absorbed. That is a real change and it would be dishonest to pretend otherwise.
Two things keep the rule intact. First, tolerance of input variation is not tolerance of process variation: a tool can absorb inconsistent data formats far more readily than it can absorb three different opinions about who approves what, which is where the expensive variation actually lives. Second, absorbed variation is not removed variation — it is variation the organisation can no longer see. A fuzzy match that silently resolves an inconsistency has also removed the signal that the inconsistency exists, which is a governance problem that arrives later and is harder to diagnose.
The strongest version of the counter-argument holds for transactional, high-volume, low-judgement processes, where absorbing input variation is most of the problem. It holds poorly for judgement-dense, control-relevant processes, where the variation is in the decisions rather than the data. Sequence accordingly rather than applying the rule uniformly.
Does this change with AI?
It changes the cost of getting it wrong, and it changes it in the wrong direction.
An automation defect is usually deterministic: it does the wrong thing consistently, which makes it findable. A model-based defect is probabilistic: it does the right thing most of the time and the wrong thing under conditions nobody has characterised. Non-standard processes generate exactly the kind of unusual inputs under which model behaviour is least predictable and least tested.
More practically: a model learns the process it is given. Trained or configured against a process with three unofficial variants, it will reproduce all three, with confidence, and without flagging that it is doing so. Automation encodes your variation; AI learns it. The second is harder to unpick than the first.
- "Standardized" means four testable conditions — one way, defined inputs, named
exceptions, and stability when your most experienced person is absent. If you cannot pass the fourth, you are experienced, not standardized.
- The failure mode is not disappointment, it is permanence. Implementation encodes
whatever variation it finds, at day rates, and makes it materially harder to change than it was in a spreadsheet.
- Deferring is a real answer. Under a hard constraint, taking the L1→L2 gains that
need no new spend often beats a purchase — and it is the option that most improves the purchase you eventually make.
Where this leaves you. The rule is only useful if you apply it per process rather than per programme. Score your close, your reconciliation and your journal-entry controls separately against the four conditions above — most finance functions find they are at different levels and can act on the stable ones immediately.