How should a source-to-pay transformation be structured?

Source-to-pay implementations rarely fail on the demonstration. The software does what it did in the demonstration. What fails is the assumption underneath the business case: that installing a process creates the discipline the process depends on.

A platform enforces a process that exists. Where the process is inconsistent, the implementation surfaces the inconsistency as a configuration decision, and configuration decisions taken under delivery pressure default to the loosest available option so that nobody is blocked. The organisation ends up with an expensive system that permits everything it permitted before, plus a login.

Every process question deferred to configuration is answered by whoever is under the most delivery pressure that week.

There is a useful test available before any of that money is committed. A meaningful part of what the business case attributes to the platform can be done inside the systems already in place: raise the thresholds that force routine spend up a chain, close the receipting backlog, put controls around purchasing cards, and route the categories that have a contract through it. If those changes are made and compliance improves, the organisation has learned what the platform is actually for and has a baseline to measure it against. If they are made and nothing improves, that is more valuable still, because the problem was never the system.

Four things. None of them needs the platform chosen, and all of them become requirements it is chosen against.

1. 01The buying routesHow many ways there should be to buy something and what each is for: catalogue, free text requisition, call-off against a contract, expenses, purchasing card. Most organisations find they have more routes than they intended and cannot say what any of them are for. The important part is not the count. It is which route a given category is supposed to use, because that is what the system will be configured against.
2. 02Approval thresholdsWho approves what, at what value, and how many approvals a routine order should pass. Automating a long approval chain produces a fast long chain. This is the single most visible improvement available in the whole programme and it is regularly skipped, because the thresholds live in a scheme of delegation or financial regulations that a committee owns and changes on its own timetable. Start that conversation at the beginning, not at user acceptance testing. Decide as well where the hierarchy is derived from: an approval structure maintained by hand decays between transformations as people move and leave, whereas one derived from grade in the HR system maintains itself and stops the familiar problem of orders sitting with an approver who left last year.
3. 03The data modelSupplier master and which system is authoritative for it, category structure, cost centre and general ledger mapping, and the contract record. Cleaning supplier data means a deduplication rule, a policy for dormant records, and a controlled process for bank detail changes, which is a fraud control rather than a data task. This work is needed whichever platform is chosen.
4. 04What is in scopeWhich categories and which spend types go through the system at all. Attempting complete coverage from the outset is the decision that turns an implementation into a multi-year programme.

Vendors usually propose a module sequence. Volume is a better organising principle, because it puts the change in front of the users who account for most of the transactions and produces evidence early.

1. 01Foundation: data and supplier masterSupplier records to parent level, an agreed category structure, a contract register covering at least the major agreements, and the general ledger and cost centre derivation rules agreed with finance in writing. Everything after this depends on it and it is the work most often deferred to cutover, which is how go-live dates slip.
2. 02Requisition to order, with catalogue contentStart with the categories carrying the transaction volume. Content is the product from the user's point of view and it comes in different forms: hosted catalogues you load and maintain, punchout to the supplier's own site, contracted price lists, and free text against a contract. Which mix you use for a given supplier determines the effort, and the effort is consistently estimated at a fraction of what it takes.
3. 03Invoice matching and paymentMatch rates depend on order coverage, which is why this follows. Note that invoice capture, coding workflow and non-purchase-order routing deliver benefit independently of that coverage, so doing accounts payable first is a legitimate choice where finance owns the budget and wants a payback it controls. What does not work is promising a match rate before the orders exist.
4. 04Contract managementContracts loaded with owners, expiry and notice dates, connected to the buying route so that calling off against a contract is the easy path rather than a separate discipline.
5. 05Sourcing and supplier managementEvent management, evaluation and supplier performance. Valuable, used by a small number of people, and safely last.

Catalogue content is the workstream people underestimate. Integration is the one that sets the date. The finance system has its own release calendar and its own owners, and the interface build and test almost always sits on the critical path.

• Decide which system is master for the supplier record and in which direction it syncs, before configuration rather than during it.
• Agree how the general ledger code and cost centre are derived, and where tax treatment is determined: at requisition, at receipt or at invoice. Getting this wrong produces invoices that will not post, and it is discovered in the weeks after go-live when the team is least able to absorb it.
• Agree goods receipt posting and accrual reversal with finance, because they will be the ones explaining the month end.
• Treat bank detail change as a controlled process with verification, not as a data field. It is the highest fraud exposure in the whole system.
• Decide the open transaction question early: whether open orders and open invoices migrate, or are closed and re-raised. Both are defensible and the decision drives a large amount of cutover work. Quantify the open orders that have never been receipted before making that decision, because in most organisations the number is larger than anyone expects and it is three problems at once: the spend data is wrong, the accruals are wrong, and nobody is confirming that what was ordered arrived. Clearing it is worth doing whether or not the programme proceeds.
• Expect user acceptance testing to be where every deferred process decision comes back, because test scripts cannot be written against an approval matrix nobody has signed.

Supplier enablement runs alongside all of this and is worth targeting by invoice count rather than by spend. The suppliers that generate the most transactions are rarely the largest by value, and they are the ones that determine whether the automation benefit appears.

People work around a system when the workaround is faster and nothing happens when they use it. Both halves of that are design decisions rather than attitudes.

• Make the compliant route the fastest one. If a catalogue order takes several clicks and an email to the supplier takes one, the outcome is already decided.
• Cover the categories people actually buy. Adoption tracks catalogue coverage more closely than it tracks training.
• Onboard suppliers properly. A supplier who cannot receive an electronic order forces the workaround from the other end.
• Shorten the approval chain as part of the implementation rather than replicating it.
• Close the alternatives, and close the right ones. Free text requisitions are the obvious leak and rarely the real one: purchasing cards, expenses and direct invoice entry are where the spend goes when a route is closed without them being addressed.
• Measure route compliance from the first weeks and read a low figure as evidence about the design rather than about the users.

Catalogue content, supplier onboarding and contract records all decay without a named owner after go-live. That ownership belongs in the operating model rather than in the programme plan, because the programme ends and the decay does not.