The automation maturity map
Automation is not a single technique applied evenly. Five kinds of process behave differently, fail differently and pay back differently, and most organisations are at a different level in each. Find your weakest dimension before choosing a tool.
Strategic
Transactional
Interactional
Transformational
Compliance
The decisions you face
Compliance-minimum or process redesign
Receiving and issuing conformant invoices is achievable without touching your process. Getting the cost out requires touching it. Both are legitimate; conflating them is how the budget gets spent twice.
Central platform or per-system
Central is cheaper to govern and slower to land. Per-system is the reverse. The right answer usually follows how centralised your finance function already is, not what the architecture diagram prefers.
Where exceptions go
The single most consequential design decision and the one most often left to implementation. Decide it at design stage, in writing.
…have a date on them
Most process automation is discretionary. Invoicing is not: in Germany, receiving structured electronic invoices has been mandatory for domestic B2B transactions since 1 January 2025 (Federal Republic of Germany, 2024), issuing becomes mandatory in 2027 for larger businesses and in 2028 for everyone (Bundesministerium der Finanzen, 2024), and EU cross-border transactions follow from 2030 (European Union, 2025). Invoices must conform to EN 16931, whose 2026 edition supersedes the 2017 version, so any implementation scoped now should name the edition it targets (European Committee for Standardization, 2026).
For most finance functions this is the only automation programme with a legally fixed completion date. Sequence the rest around it.
The processes this is bought as
Document and process automation is the capability. These are the named processes it is bought as, each one with a budget line and an owner:
- Order-to-cash, from order capture to cash application
- Procure-to-pay, from requisition to payment, with invoice-to-pay as its tail end taken on its own
- Hire-to-retire, the employee record from application to the retention period after someone leaves
- Enterprise asset management, the documents that make an asset register defensible
They run on the same capability and they are governed by the same rules, which is why automating a second one after the first costs a fraction of it.
What you walk away with
Four pieces of work, each of which keeps running after we leave. That is the test they were written against: an automation programme that stops when the engagement stops has produced a pilot rather than a process.
One process running end to end, and the figures off it
Documents read and classified as they arrive, routed by rule rather than by whoever notices them, validated against the record they belong to, and filed where the retention rule can reach them. One process, taken the whole way, rather than a layer of automation spread thinly over six.
It is measured before it starts and measured again after, per step, so the saving is a number from your estate rather than a number from a vendor deck. That measurement is also what makes the second process arguable: the pattern is proven on evidence you generated rather than on a promise renewed.
The first one is the expensive one. Everything after it reuses the classification, the rules and the integration work already paid for, which is why the sequence matters more than the shortlist.
Conformant invoicing built inside the process, not beside it
Receiving and issuing structured invoices that conform, with the standard edition named in the specification rather than assumed, because the edition in force will change during the life of what gets built and an implementation that never named one has no way to say whether it still complies.
The reason to build it inside the process rather than as an adapter in front of it is the first of the three decisions above. An adapter satisfies the obligation and changes nothing else, so the cost stays exactly where it was and the budget gets spent again when somebody comes back for the saving.
Receiving comes before issuing, which is the sequencing most plans get backwards. An organisation preparing only to send meets the earlier date unprepared.
Exceptions with a named home
Where a document goes when it does not match, who is accountable for clearing it, how long it may sit there, and what happens when nobody does. Written down before the build rather than discovered during it.
This is the single most consequential design decision on any automation programme and the one most often left to implementation. Unhandled, exceptions become a queue nobody owns, and a queue nobody owns is how a process that automates ninety per cent of its volume still needs the same number of people.
It is also the part an auditor asks about first, because the exception path is where the control either exists or does not.
Process logic above the applications
Rules, routing and accountability held above the systems rather than configured inside each one. When every application holds a piece of how the business runs, every change has to be negotiated with whichever system happens to contain it.
Inverted, replacing a platform becomes an ordinary commercial decision rather than a programme you cannot start, and the next system bought plugs into a defined structure instead of adding to the pile. That is what stops this work being redone in five years by somebody who inherits it.
It is the same structure the group builds for integration, governance and asset documentation. One set of rules for the estate, not a separate set shaped like an automation project.
We take one process end to end, usually supplier invoices, prove the saving on it, then use the same pattern on the next. The e-invoicing dates make the sequencing decision for you.
Document and process automation, asked plainly
What counts as document and process automation?
Invoices, personnel files, contracts and archives handled by systems rather than by people: read and classified on arrival, routed by rule, validated against the record they belong to, and filed where the retention rule can reach them.
Will this replace people?
The saving here is recovered time rather than removed headcount, and it is worth being direct about that. What goes is retrieval, rekeying and chasing. Where a client does intend to reduce headcount that is their decision and their programme, and it should not be presented as the same one.
Do we have to replace our existing systems?
No. The process logic sits above the applications rather than inside them, which is what lets a system be replaced later without the surrounding work being redone.
Why is e-invoicing treated as a deadline rather than a project?
Because the dates are set by legislation rather than by a steering committee, and the obligation to receive arrives before the obligation to send. An organisation that plans only for sending discovers the earlier date the hard way.