Transformation roadmaps in payables tend to be sequenced by vendor delivery rather than by dependency, which is why they so often deliver a capable system into a process that cannot use it. Sequencing by what each step depends on, and by what each step costs, produces a shorter and less risky path, and the first two steps are usually free.
Step one, free: measure and consolidate
Time the process end to end, count how invoices arrive, and count how many have an order and a receipt behind them. Then consolidate arrival channels onto one address. This costs nothing, takes a quarter, and it tells you whether your constraint is capture, matching or approval. Skipping it is how organisations buy capture for an approval problem.
Step two, cheap: fix upstream discipline
Purchase-order coverage and reliable goods receipts set the ceiling on everything automation can do. Raising them is a policy and a habit: a threshold, a return policy for invoices without references, and making the receipt somebody's explicit job at the point of delivery. No software raises this ceiling, and every automation benefit is capped by it.
Step three onwards: the record, then capture, then payment
Put the invoice record and the approval path in place first, because everything else feeds them. Then capture, which now has somewhere to deliver. Then payment execution and any supplier portal work, which are the slowest socially and can proceed in parallel. Each step delivers on its own rather than waiting on the next.
Questions people ask about accounts payable transformation roadmap
How long should a roadmap be?
Long enough to include the free steps and short enough that somebody is accountable for each. Two or three quarters covers most of the value for a mid-sized team.
What is the most commonly skipped step?
Measuring the baseline. Without it you cannot tell whether the project worked, and you cannot tell which step to do first.
Should we appoint a project lead from finance or IT?
From finance, with IT support. The decisions that determine success are process decisions about thresholds, ownership and exceptions.