Why P2P is where ERP programmes are won or lost

Finance modules get the executive attention. Procure-to-Pay is where the actual behaviour change happens — and where most training budgets are spent too late.

Steering committees spend most of their time on Record-to-Report: is the Chart of Accounts right, will month-end close on time, does the auditor sign off the new control environment. All fair, and all necessary. But if you want to know whether an ERP programme will actually land well with the wider organisation, look at Procure-to-Pay instead.

It's the module everyone touches

R2R involves finance teams. P2P involves everyone who ever raises a requisition, approves an invoice, or chases a supplier — which, in most organisations, is a much larger and much less system-literate population. That's exactly why P2P training tends to get compressed into the final weeks before go-live, when it should start much earlier.

On the programmes I've run, the P2P workstream is consistently where the gap between "configured correctly" and "actually used correctly" shows up first, because it's the module with the most day-to-day human contact.

Old habits don't disappear, they hide

If the new system makes a workaround even slightly harder than the old one, people don't raise a ticket, they quietly find another way round it — a spreadsheet, an email approval, a call to a colleague who knows the trick. Weeks later, this shows up as unexplained data gaps or duplicate spend, and by then it's much harder to trace back to a training or process gap that could have been closed at go-live.

What tends to work

Start P2P training earlier than feels necessary, and build it around real scenarios from the business rather than generic system walkthroughs. Give super-users in each department real authority to raise issues, not just a title. And treat the first eight weeks after go-live as part of the training plan, not as a wind-down — because that's when the exceptions the demo never showed you finally turn up.