How do you automate accounts payable without replacing your ERP?

Why does replacing the ERP usually not fix accounts payable?

Because the common causes of a painful AP function are rarely features the ERP is missing. They are purchase orders that never get raised, goods receipts that never get entered, approvals that sit in someone's inbox, and supplier data that has three versions of the same vendor.

A new system inherits every one of those problems, plus a migration. The teams that get the most from AP automation are usually the ones that fixed the upstream discipline first and then automated the mechanics of what remained.

There are legitimate reasons to replace an ERP. An AP backlog is seldom one of them on its own.

Which accounts payable steps can actually be automated?

Note the pattern. Everything mechanical automates. Everything requiring a question, a judgment or an authority does not — and the two steps marked as controls should never be automated even when technically possible.

Why stabilise before automating?

Because automation encodes whatever process it finds. If invoices are coded three different ways depending on who processes them, automating that produces three different codings at higher speed and with less visibility.

The sequence we use on every engagement is deliberate: take the work exactly as it runs today, run it until it is predictable, write down what actually happens as opposed to what the policy says happens, then separate the steps that need judgment from the steps that do not. Only then build.

The fastest way to automate a broken process is to first stop it being broken. Teams that skip stabilisation typically spend the time they saved on reconciling the output of their own automation.

Where do good automation candidates come from?

From the people running the process, not from a feature list. Someone who has performed the same manual step forty times in a month knows exactly which parts are mechanical, which exceptions actually recur, and which edge cases a demo never covers.

This is why we sequence the work the way we do: the team takes the process over first, runs it, and then proposes what to build. A candidate list assembled before anyone has done the work is a guess.

A practical way to generate the list: for one month, log every time someone touches an invoice after the first touch. The reasons cluster fast, and the top three clusters are your build queue.

What does an automation build actually look like?

Smaller than most people expect. The useful builds are rarely a platform; they are targeted pieces of work that remove a recurring manual step.

• Extraction and coding of invoice data into the ERP's own import format
• A duplicate check that runs before posting rather than after payment
• A matching routine that clears the straightforward majority and lists the rest
• Routing rules that send each exception type to the person who can resolve it
• Assembly of the payment file from approved records, ready for your approver
• A supplier statement reconciliation that produces a difference report instead of a spreadsheet exercise

For a worked example of the scale of return this can produce — a report that took five business days by hand and has run in forty-five minutes since — see the automation page. That example comes from a member of our delivery leadership earlier in their career at a previous employer, and is offered as an illustration of the skill set rather than as an Exordiom client outcome.

How should you measure whether it worked?

Agree the baseline before you build anything, because the most common reason automation cannot prove its value is that nobody recorded the starting position.

• Touches per invoice. The most honest measure of manual effort.
• First-pass match rate. Should climb as upstream discipline and matching improve.
• Invoice cycle time. Receipt to approved for payment.
• Exception rate by type. Tells you what to build next.
• Duplicate payments caught. Usually the fastest measurable return.

Notice what is not on that list: headcount. We do not promise headcount reduction, because what actually happens in most engagements is that the same people stop keying and start reviewing, chasing exceptions and closing earlier. Whether that becomes a headcount decision is yours, not a number we would commit to in advance.

Frequently asked questions