Owning automation software does not establish process maturity. The original 6 April 2021 date is retained; this article offers an unvalidated process model, not a current adoption survey. A reporting automation may coexist with a variable close. Establish the actual process baseline rather than treat an illustrative story as measured client or industry evidence. That gap between tooling owned and work changed is what a maturity model is supposed to expose. Most of them do the opposite, because they grade software rather than evidence. Model status. This is a proposed practical model, not a validated assessment instrument. Its six levels are numbered 0 to 5.
Grade the outcome, not the toolkit
A usable definition: maturity is how little human judgement is required to know whether the numbers are right. That definition rules out self-flattery, because it can be measured. Four metrics, none of which can be gamed by a purchase order: The proportion of transactions captured once, at source, in structured form. Not entered once by your team — captured once in the chain. Every re-keying is a defect. The exception rate per high-volume process. What share of items cannot complete without a human deciding something? Close duration and, more importantly, its variance. A function that closes in eight days every month is more mature than one that averages seven with a range of four to thirteen. Variance can have several causes; investigate them rather than infer undocumented dependency from this metric alone. The proportion of control evidence produced as a by-product of the process rather than assembled by a person for an auditor. Publish those four numbers monthly for a quarter and the maturity conversation resolves itself.
Six levels, defined by what the work looks like
Level zero: re-keyed. The same data is entered into more than one system by more than one person, and spreadsheets are the integration layer. Most functions have at least one high-volume process here and do not say so out loud. Level one: captured. Data enters once, at source, in a structured form — supplier invoices arriving as data, expenses captured on a phone, timesheets entered by the person who did the work. Automation exists but as point solutions. Level two: routed. Approvals and handoffs live in a system rather than in a mailbox. The status of anything is knowable without asking a person. No survey establishes the proportion of finance functions at this proposed level. Level three: continuously reconciled. Matching and reconciliation happen daily. The close becomes a review of a mostly finished picture rather than an eight-day construction project, and the variance starts to collapse. Level four: exception-managed. The routine runs without intervention and the team works a queue of exceptions. The exception taxonomy is defined, each type has an owner, and the size and ageing of the queue are managed metrics rather than a mood. Level five: self-evidencing. Controls produce their own evidence. When the auditor asks how approvals above a threshold were enforced in August, somebody runs a query instead of opening a folder.
| Proposed level | Work evidence described |
|---|---|
| 0. Re-keyed | Data copied between systems and spreadsheets. |
| 1. Captured | Structured data captured at source. |
| 2. Routed | Workflow and status recorded in a system. |
| 3. Continuously reconciled | Matching and reconciliation performed daily. |
| 4. Exception-managed | Named types, owners and ageing in an exception queue. |
| 5. Self-evidencing | Process-generated records mapped to control evidence. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Two scoring rules that make the model honest
The first: you are at the level of your weakest high-volume process, not your best pilot. A function with a beautifully automated expense flow and a payables process that runs on a shared mailbox is at level zero in payables, which is where the cost and the risk live. The second proposed rule is to check upstream data and controls before automating. The model does not establish that levels cannot be skipped or that every repair automation is the costliest approach. Any correction needs authorised, documented, tested and traceable controls. Review why a correction is needed and whether prevention or an appropriately controlled correction is suitable; the words alone do not justify a ban.
What actually moves a process up a level
Zero to one: change where data is born. Structured supplier invoices, capture at the point of receipt, self-service submission by the person with the information. Assess the return from actual capture effort, supplier onboarding and costs; no universal highest-return ranking is established. One to two: put workflow and status in a system. The test is whether you can answer "where is invoice 4471?" without messaging anyone. Two to three: move matching and reconciliation off the close. Daily bank reconciliation, daily matching, sub-ledger discipline, with accounting review of necessary adjustments and controls; no universal ban on period-end journals is implied. Three to four: build the exception taxonomy. Name every reason an item stops, count them weekly, assign each type to an owner whose job is to reduce it, and treat the top three as improvement projects rather than as workload. Four to five: map system-generated logs to your control matrix. Decide which artefact evidences which control, then make the system emit it. Any audit-preparation saving needs a baseline, scope and measured result; no several-week outcome is established.
Practical Guidance for Automation Maturity Assessment
- Measure the four metrics before discussing software. Capture-once rate, exception rate, close duration with variance, and automatically produced control evidence.
- Score process by process, and report the weakest high-volume process as your level. Group averages hide exactly where the money is.
- Review correction automations and upstream capture together. Require authorised changes, traceability and appropriate accounting controls rather than a universal ban.
- Attack close variance before close duration. Check staffing dependencies alongside other causes; prioritisation requires the actual process baseline.
- Define the exception taxonomy for your top three processes, with an owner per exception type and a weekly count.
- Decide the control evidence artefact for each key control now, while you are changing the process anyway. No universal twofold retrofit cost is established.
- Sequence the roadmap onto external deadlines you cannot move, such as invoicing and tax filing requirements, rather than around internal convenience.
- Report a touchless rate and an exception ageing figure to the audit committee. Two numbers, quarterly, is enough to keep the programme honest.
The Regional Angle
Three regional realities change where the constraint sits. The first is leave, and it is the most underrated driver of close variance in this market. A workforce assembled largely from expatriate staff takes annual leave in long consolidated blocks — three to five weeks at a time, to visit home countries, clustered around school holidays, Eid and the summer months. That means the person who performs an undocumented step in your close is predictably absent for a month, every year, and frequently more than one such person at once. Functions here do not have a generalised documentation problem so much as a seasonal one: the numbers take four days longer in July and nobody writes down why. Two practical responses follow. Map the close by step against the leave calendar and identify every step with exactly one capable performer during the July to September window. Then, when prioritising automation, weight the steps that fall in that window, because automating a step whose owner disappears for five weeks removes variance rather than just effort. The second is that the three-way match taught by the software vendors does not describe an import-driven business. For groups bringing goods in through regional ports and free zones, the documents that determine whether a payable is correct include the customs declaration, the certificate of origin, the bill of lading, the clearing agent's charges and, where trade finance is involved, the documents presented under the letter of credit. Purchase order, receipt note and invoice are three of five or six relevant artefacts, and the others typically live with the clearing agent or the bank rather than in your system. Any maturity assessment in this region should look specifically at how import documentation reaches the accounting process, because that is where re-keying concentrates and where level zero survives longest, regardless of how modern the rest of the estate looks. The third is audit evidence, which is worth more here than the maturity models imply. Groups in this region routinely run multiple legal entities across mainland jurisdictions and free zones, each with its own statutory audit, sometimes with different audit firms and always with different templates, and the evidence pack for every one of them is assembled manually by the same small team that performs the close. The work is concentrated into a few weeks and it competes directly with the period that matters most. Multi-entity evidence requests may create reusable work, but comparative payback and auditor acceptance depend on actual scope and costs. No faster-payback guarantee or universal shared-extract acceptance is established. A supplier note to close: capture at source depends on suppliers who can and will send structured data. A meaningful share of the supplier base in this market is small trading companies for whom a portal registration is a genuine barrier. Treat level zero to level one as a commercial onboarding campaign — phone calls, help in the languages your suppliers actually use, and a fallback path that still produces structured data — rather than as a deployment with a go-live date.
The objection worth taking seriously
The honest objection is that maturity models are instruments of consulting. They produce a score, the score produces a gap, and the gap produces a roadmap that tends to match the assessor's service catalogue. Worse, the levels imply a linear progression that real finance functions do not follow: a small team at level two with excellent people, clean master data and a simple business will close faster and with fewer errors than a large function at level four whose upstream data is a mess. Nobody has ever been promoted for moving from level three to level four, and the score itself has no economic meaning. All of that is fair, and the score really is worthless. If an assessment ends with a number on a slide, it has failed. What survives is the diagnostic. The four measurements are useful because they locate the binding constraint, and finance functions are consistently wrong about where theirs is. The team that believes it needs better reporting usually needs capture at source. The team that wants to automate the close usually needs daily reconciliation. The team buying more robots usually needs to fix the master data those robots are compensating for. Use the levels as a map for finding the constraint, throw the score away, and judge the programme on the same four numbers a year later.
Common Questions
What is the fastest improvement available to most finance teams?
Assess structured capture for a suitable high-volume document type. Its priority depends on the actual bottleneck and costs; this model does not establish that it is fastest for most teams or outperforms every other automation.
How long does it take to move a process up one level?
The proposed levels have no validated transition time. Scope duration from the process, controls, data and capacity rather than assert three to six months or reject every faster programme.
Do we need specialist automation software to reach level four?
Assess the actual capabilities and control requirements. This proposed model does not establish what most functions can achieve with existing tools or a universal tooling requirement.
What should we expect over the next twelve months?
Those next-year statements are unverified predictions from the retained April 2021 date, not observed outcomes. They do not validate the model or establish recruitment, regulatory or investment results.
Automation Maturity Assessment — we measure capture, exceptions, close variance and control evidence across your high-volume processes, then tell you which single constraint is holding the function back before you buy anything else.