A pragmatic roadmap to P2P automation

Key takeaways

• Procure-to-pay breaks between the steps, not inside them. Requisition approval and invoice posting already run in the ERP. The email threads that connect them do not.
• Sequence by where exceptions cluster, not by the order of the process. The document your team touches most often is the one to automate first, wherever it sits in the flow.
• The requisition stays with a person. Everything after it can run unattended with a human on the exceptions, which is what the diagram below shows.
• At Klöckner, 81% of order lines book with zero human edits, across 150 suppliers and more than 1,100 purchase order lines a week. Oatly runs around 2,500 orders a month with 80% on Autopilot.
• If your supplier base is stable and already on EDI, this roadmap has little to offer you. What it closes is the gap where communication arrives as prose.

Where procure-to-pay actually breaks

Procure-to-pay sits on the seam between procurement, finance and operations. For enterprises running SAP, Oracle or Microsoft Dynamics, it is where policy meets the working day. A requisition that looks clean in the ERP becomes an email thread, a spreadsheet tracker and an ad hoc approval as soon as a real supplier, an urgent demand or a short delivery enters the picture. The symptoms are consistent across companies: cycle times nobody can predict, stakeholders who chase status by phone, and a finance team spending month-end reconciling receipts instead of managing cash.

It is worth being precise about which part is manual, because it is not the part most roadmaps target. Approval workflows exist. Invoice posting against a purchase order exists. Payment runs are scheduled. The manual work is the connective tissue: reading the confirmation that arrived as a PDF attached to a reply-all, deciding whether a delivery date that moved by five days matters for this material, updating the line in the ERP, and remembering to ask again about the twelve purchase orders that were never acknowledged at all.

That work has a cost per document, and it is larger than most teams assume, because it is spread across payroll, rework and supervision rather than sitting in one budget line. Manual touchpoints in supply-chain processes commonly run $30–50 each once handling time and error correction are counted. A team processing a few thousand documents a month is carrying a six-figure annual cost that never appears as a line item anyone owns.

What an execution layer changes

The alternative is to treat procure-to-pay as one flow that runs on top of the systems you already have, rather than a sequence of screens people move between. An AI execution layer reads the inbound mail and its attachments, extracts the fields that matter, matches them against master data, writes the result into the ERP, and follows up with whoever owes an answer. It does not replace SAP or Oracle. It closes the distance between what the ERP has recorded and what still needs to happen.

Mechanically this is less invasive than it sounds. GeneralMind connects over a mailbox plus a lightweight API and adapts to the interfaces each system already exposes, maintaining those connections itself. There is no data migration, no new user interface for the team to learn, and no requirement to upgrade the ERP first. The people who were doing the coordination keep the exceptions, which is the part of their job that needed judgment anyway.

The division of labour is the important design decision, and it is not evenly split. The requisition is where policy, budget and intent are set, so it stays with a person. From the purchase order onward, each step is a matter of applying rules to documents, and each one can run unattended until something fails a check.

Where a procure-to-pay automation roadmap should start

The instinct is to start at the beginning of the process, and it is the wrong instinct. Requisitions are already the most governed part of procure-to-pay, and automating them buys the least. Start instead where exceptions cluster, because exception volume is what actually consumes your team's day.

In practice that means the order confirmation. It is the highest-frequency inbound document in most procurement functions, it arrives in whatever format the supplier feels like using, and every one of them has to be compared against what was ordered. It is also the step where the comparison is mechanical: price, quantity, delivery date, against the original purchase order. A team that automates confirmations first sees the change within weeks, because the volume is there every day.

The second candidate is the chase. Following up on purchase orders that were never acknowledged is pure coordination work with no judgment in it, and it is the first thing dropped when a team is busy, which is exactly when it matters. Automating the chase costs nothing in risk: the worst outcome of an unnecessary reminder is a mildly irritated supplier.

Three-way match and invoice exceptions come third, not because they are less valuable but because they depend on the two above being clean. Matching an invoice against a purchase order and a goods receipt is only reliable when the purchase order reflects what was actually agreed, including the date change the supplier sent by email in week three. Automate the match before the confirmation and you automate a comparison against stale data.

Two things belong on a stop list. Approval thresholds and policy exceptions should stay manual, because automating them hard-codes whatever your policy currently is, including the parts that are wrong. And supplier onboarding, where commercial terms are negotiated rather than processed, is not a document-handling problem at all.

Measure touch rate rather than extraction accuracy. Extraction accuracy is the number vendors quote and the one that moves least: improving field accuracy from 92% to 96% barely changes how long a document takes to clear, because typing was never the bottleneck. The question is what share of documents reach the ERP without a person opening them.

What the numbers look like in practice

Benchmarking by APQC has consistently found that full procure-to-pay automation remains a minority position, while the organisations that reach it report materially lower processing costs and shorter cycle times than their peers. That gap is the opportunity, and it has less to do with technology availability than with sequencing: most programmes automate the steps that were already cheap.

On our own deployments the pattern is consistent. A new workflow runs around 85% straight through on day one, and reaches 93–95% within a few weeks as it learns the master data, the supplier quirks and the exceptions your team treats as normal. Reaching 90% or more on Autopilot typically takes about six weeks, and roughly 60% of manual processing time is reclaimed in the first three months. These are typical figures rather than guarantees, and they depend on document volume being high enough for the system to learn quickly.

The named examples are worth more than the averages. At Klöckner, one of Europe's largest steel and metal distributors, 81% of order lines book with zero human edits, across 150 suppliers and more than 1,100 purchase order lines a week, running directly on the existing SAP install with no migration. Oatly processes around 2,500 orders a month with 80% of them on Autopilot. In both cases the team did not shrink; the volume it could absorb grew.

Where this roadmap is the wrong plan

If your inbound is already structured, stop reading. A procurement function whose top fifty suppliers all send ORDRSP IDocs over EDI has solved the problem this roadmap addresses, and an AI layer on top of clean EDI is overhead with extra steps. The gap worth closing is the long tail: the suppliers too small to onboard to EDI, who between them send most of the exceptions.

Volume matters too. Below a few hundred documents a month, the arithmetic stops working. There is not enough repetition for the system to learn quickly, and the coordination cost you are removing is a fraction of one person's week. Hiring is the cheaper answer at that size, and we will say so on the call.

Timing is the third case. If you are mid-migration to S/4HANA, wait. Automating against interfaces that are about to be replaced means paying twice, and the migration will consume the internal attention this needs anyway. Finish the move, then automate against the system you will actually keep.

The fourth case is the uncomfortable one. If the real problem is that your approval thresholds are wrong, or that three departments disagree about who owns supplier master data, automation will make the existing mess faster and harder to see. Fix the policy first. Software that executes a bad rule reliably is worse than a person who quietly works around it.

Why the timing has changed

The case for acting now is structural rather than technological. Transaction volumes are rising, stakeholders expect status without asking for it, and the labour market for experienced order-processing staff is tight in every market we sell into. Those three together make scaling by headcount progressively less available as an option, which is a different argument from automation being newly possible.

There is a control argument as well. When volumes spike or a new entity is onboarded, an autonomous flow absorbs it without a hiring cycle. When suppliers change terms, finance sees committed spend and liabilities as they move rather than after the month-end reconciliation. Under pressure on working capital, shortening cycle times without loosening controls is worth more than the headcount saving that usually gets quoted.

The teams that start deliberately get to choose which workflow goes first, which exceptions stay human and what the audit trail looks like. The teams that wait tend to start under duress, after a backlog or an audit finding, and take whatever sequence the crisis dictates. The difference between those two positions is a few months of deciding, not a difference in technology.