Source to Pay Transformation: Fix the Manual Handoffs Around Your ERP

The purchase order is visible. The work before it often is not.

Source to pay transformation is often described as a large technology programme. For a complex manufacturer, a more useful starting question is: What work did people have to do before a clean purchase order appeared in ERP?

Consider a maintenance request for a replacement pump at a plant. The requester emails a photo and a part description. A buyer checks the specification, asks engineering whether a substitute is acceptable, finds out which suppliers are approved for that plant, sends an RFQ, compares lead times and freight, follows up with quality, and waits for a commercial approval. Only then does an authorised purchase order reach ERP.

ERP may record the final transaction accurately while much of the decision trail sits in mailboxes, files and personal trackers. This is the practical gap a transformation should address.

The pressure is growing. The Hackett Group's 2026 procurement study projects 8% more procurement workload in 2026 despite declines in headcount and operating budgets. That is a forecast across its study population, not a promised outcome for any particular manufacturer. It is a reason to examine where skilled teams spend time coordinating routine work.

If you need a stage-by-stage definition first, read the source-to-pay process guide for complex manufacturers. This article focuses on how to change that process in a live operation.

What should source-to-pay transformation actually change?

Transformation is more than putting existing forms on a screen. It changes how a need becomes an approved supplier decision, contract, order, receipt and payment, and how people recover when something goes wrong.

For a manufacturer with several plants, the target state should make four things easier to see: where work started, what information was used, who had authority, and what happened next. A useful transformation brief therefore covers:

• Demand: How plant, project and corporate requests enter a governed route instead of a buyer's inbox.
• Context: Whether category, plant, specification, supplier status, contract terms and budget information are available at the decision point.
• Decisions: Which rules can route work and which commercial, financial or quality decisions need a named person.
• Execution: Who collects missing data, coordinates suppliers, follows up and handles an exception.
• Record: How approved outcomes reach ERP and how the request, approval and outcome stay connected.

The objective is a completed, controlled workflow. If a new intake form still sends buyers back to email for every clarification, the coordination burden has merely moved.

Find the work outside ERP before choosing a product

Start with one recent request and reconstruct its actual journey. Ask requesters, buyers, quality, engineering, finance and the ERP team what they did, including steps that never entered a formal system.

The most revealing evidence usually comes from ordinary completed cases and the exceptions that nearly failed. For each case, record:

1. Trigger: What started the request, and in which channel?
2. Missing information: Which fields, drawings, terms or checks had to be chased?
3. Handoffs: Which people and systems were involved, and how many times did work return to an earlier step?
4. Decision: Who selected the route, supplier, price or exception treatment, and on what evidence?
5. Transaction: What was entered in ERP, by whom, and how did they know the write succeeded?
6. Exception: Where did work stall, and who could see that it had stalled?

Do this for different purchasing situations. A repeat MRO item bought from a contract is different from a new direct-material supplier, and both are different from an engineered project purchase. One universal flow can conceal the very variation the programme needs to govern.

The intake and orchestration workflow is relevant when incomplete requests and route selection consume buyer time. The ERP integration model becomes relevant when approved decisions are rekeyed or disappear between systems. Follow the work first, then select the capabilities that address it.

Score the handoffs, then pick one workflow

The first workflow should expose a real problem and still have a manageable boundary. High spend alone is a weak selection rule: a low-frequency strategic category can be too variable for a first rollout, while a frequent plant purchase can make the operating change obvious.

A practical shortlist uses five criteria. Score each candidate with actual examples and baseline data rather than workshop opinions alone:

For many manufacturers, plant demand to approved requisition is a useful first candidate. It is frequent, begins outside ERP, has identifiable policy rules and ends in a transaction the ERP team can verify. An RFQ-heavy category or supplier onboarding may be better if those are the dominant sources of delay.

Design the first workflow from request to approved outcome

Take the chosen process all the way to its authorised endpoint. A pilot that stops at a dashboard or sends the last step back to a spreadsheet cannot show whether source-to-pay execution improved.

Use the plant pump example as a design exercise. The following sequence shows what the software should coordinate and where a person must decide:

This is where sourcing and RFx should connect with procure-to-pay. An RFQ result is useful only if the approved supplier, terms and decision evidence carry forward to the buying step. The ERP remains the authoritative transaction record; the working trail remains visible around it.

Do not automate a supplier award just because quotations can be compared automatically. The software can prepare comparable options and route the decision, while people retain commercial and technical authority according to policy.

Make the controls explicit before expanding

Multi-plant source-to-pay work becomes difficult when a policy sounds uniform but authority differs by entity, plant, spend band or category. Write down those differences during the first workflow design.

The pilot should have a compact control sheet that operational teams can inspect. It should name:

• The requester, buyer, technical reviewer, quality reviewer and financial approver for each route.
• The conditions for a contract buy, competitive RFQ, single-source exception or urgent purchase.
• The approved supplier and document checks that must pass before invitation or order.
• The actions software may take, the limits on those actions and the point where it must stop.
• The system that owns each master field and the authorised ERP write-back.
• The owner and recovery step for an expired certificate, unavailable approver or rejected ERP transaction.

These controls are part of the workflow, not a policy attachment people are expected to remember. The security and AI governance approach explains why permissions, checkpoints and action evidence matter when software moves work on behalf of a team. For the system boundary, the guide to ERP and autonomous procurement covers ownership and write-back in depth.

Run a pilot that includes the difficult cases

Choose one plant or business unit, one category or request type, and a clear set of authorised users. Then run actual work through the new route. Include transactions that involve a missing specification or a supplier who cannot meet the delivery date.

Before launch, agree on the test cases that would otherwise force people back into email. A credible pilot should demonstrate at least the following:

• A complete request that follows the expected route.
• An incomplete request that returns to the requester for a specific missing item.
• An ineligible or document-expired supplier that is blocked or escalated.
• An approver who is unavailable and has an authorised delegation path.
• A commercial or quality exception that reaches the correct decision-maker.
• An ERP validation failure that remains visible until an owner resolves it.

Watch the real users perform these tasks. Requesters should understand what to provide and where to see status. Buyers should receive work with enough context to act. Approvers should see the reason for the decision and its evidence. IT should see which approved outcome was written to ERP and what failed when it was not.

A workflow-led procurement transformation can then reuse the same policy, identity and integration patterns for the next plant or category. That is more defensible than multiplying separate pilots with different rules.

Measure work completed, not screens opened

The baseline is what makes a transformation claim credible. Select a comparable period before and after the pilot, and segment results by plant, category and exception type where possible. Do not use a generic ROI promise as a substitute for your own operating data.

Measure both speed and control so a faster process has not simply skipped required reviews. The following measures give CPOs and CIOs a balanced view:

For each measure, define the start, stop, exclusions and data source before the pilot. A request can appear faster if teams stop the clock while waiting for a supplier; that would hide the delay the programme aims to solve. If a category's supplier mix or volume changes sharply, compare like with like and explain the difference.

Proconomy's source-to-pay ROI tool can help model coordination effort by category. Treat its output as a scenario built on your inputs, then validate it against observed workflow data.

What changes after the first workflow works?

Expansion should follow the connections between workflows, not a promise to deploy every module at once. When demand to requisition is stable, look at the handoff that still breaks the record.

The next step might be contract lifecycle management if approved terms fail to guide purchases, or supplier quality management if eligibility and corrective-action evidence are missing at sourcing time. A repeat-buying category may need better contract coverage; a direct-material category may need approved-source and engineering context earlier in the RFQ.

For each expansion, repeat the same discipline: establish the current path, define the decision rights, connect the approved outcome, test exceptions and measure the result. Across entities, shared policy can coexist with local approvers and thresholds. The objective is a connected operating model that people can actually follow.

Start with one handoff you can prove has changed

The first result of source-to-pay transformation should be a better completed workflow, not a longer list of features. Trace a real request from its first message to its ERP outcome. Find where information is chased, authority becomes unclear and exceptions lose their owner. Then redesign that route with visible rules, connected evidence and a baseline to test the result.

Proconomy connects intake, sourcing, supplier management and purchasing so a manufacturer can improve the handoffs without losing its ERP record or human decision rights.