Symptoms
What leaders usually see
- Approvals move outside the system
- Supplier, PO, invoice and contract workarounds keep returning
- Dashboards show friction but do not assign ownership
Executive search path
S2P Transformation Advisory when Source-to-Pay needs a governed execution system.
S2P programs fail when process, data, ownership, technology and adoption are managed as separate workstreams instead of one execution system.
Diagnosis
What I diagnose
- Process taxonomy gaps
- Decision and escalation paths
- Adoption barriers between business, procurement and finance
Output
What you leave with
A clear read on the S2P system break and the route to redesign, stabilize or scale.
Definition
What Source-to-Pay actually is, once you stop drawing it
Source-to-Pay is usually drawn as a chain: identify need, source, contract, order, receive, invoice, pay. That drawing is accurate and almost useless. It describes the sequence and hides the thing that decides whether the sequence runs.
S2P is a chain of ownership transfers. At every step, something changes hands. A requirement becomes a specification. A specification becomes a negotiation. A negotiation becomes a contract. A contract becomes a catalogue entry, a purchase order, a receipt, an invoice, a payment. The process rarely fails inside a step. It fails at the seam between two of them, where the previous owner has let go and the next one has not picked up.
The structural error
Five workstreams, one system
Most S2P programmes are organised as parallel workstreams with separate leads, separate plans and separate steering. Each one is competently run. The programme still stalls, because the five are not five things.
Designed by people who will not run it, against a taxonomy that finance and the business read differently.
Supplier, material and contract master data that the process assumes is clean and the systems know is not.
Named on a slide, contested at every seam where category, business unit and shared service meet.
Configured to a design that was still moving, then treated as the reason the design cannot change.
The workstream that gets the least budget and decides the outcome. It is not training. It is whether the system is the easiest path.
Run separately, each workstream optimises against its own plan and quietly breaks the others. Run as one execution system, the five constrain each other early, which is uncomfortable and far cheaper.
Schaubild
The seven seams where S2P actually breaks
Each seam is a point where ownership transfers. Each one is where a workaround is born.
01Need to specificationThe business knows the outcome. Procurement receives a product name. The sourcing lever is already gone.
02Specification to sourcingTiming decides leverage. A late handover turns a negotiation into a confirmation.
03Sourcing to contractWhat was negotiated and what was signed drift apart when legal review has no decision date.
04Contract to catalogueThe seam almost nobody owns. Terms that never reach the buying channel are terms that never apply.
05Order to receiptGoods receipt is treated as admin. It is the control that makes the three-way match possible at all.
06Invoice to matchException volume is not an AP problem. It is the sum of every unclear decision upstream.
07Payment to insightSpend data returns to the category owner too late to change the next sourcing decision.
Read the seams in order and the pattern is visible: leakage does not start at payment. It starts at the first handover, and every later seam inherits it.
Made concrete
The symptom is where you look. The cause is upstream.
Every S2P symptom has an obvious owner and a real one. They are rarely the same. Pick a symptom to see where the cause usually sits.
Spend keeps happening outside the agreed channel.
- Blamed on
- Discipline. The usual answer is a policy reminder.
- Usually caused by
- The compliant path is slower than the non-compliant one.
- Look at
- Seam 04. Whether negotiated terms ever reached a buyable channel.
- Test
- Time the compliant path end to end. If it loses, policy will not win.
AP carries a permanent exception queue.
- Blamed on
- Suppliers, or the matching tolerance settings.
- Usually caused by
- Orders raised after the fact, and receipts booked late or not at all.
- Look at
- Seams 05 and 06 together. The match can only be as clean as the receipt.
- Test
- Split exceptions by root cause, not by supplier. The distribution names the seam.
The catalogue exists and nobody buys from it.
- Blamed on
- Change management, or the user interface.
- Usually caused by
- Content that is incomplete, stale, or priced above what the requester can find elsewhere.
- Look at
- Seam 04, and who owns catalogue content after go-live.
- Test
- Sample ten real requests. Count how many could have been fulfilled from the catalogue at all.
Negotiated value does not appear in the accounts.
- Blamed on
- Finance methodology, or the baseline.
- Usually caused by
- No owner between the signature and the budget line.
- Look at
- Seams 03, 04 and 07. Value leaks at each one and nobody is accountable across them.
- Test
- Trace one signed saving to the cost centre. The number of handovers is the answer.
This is not a diagnosis of your estate. It is the shape a diagnosis takes: symptom, assumed owner, real seam, and one test that settles it.
Sequence
Redesign, stabilise or scale. Not all three at once.
Most S2P programmes attempt all three positions simultaneously, then wonder why nothing finishes. The three need different governance, different pace and a different definition of done.
Choosing the position is the decision. Scaling an unstable model multiplies the instability, and redesigning while the current model is on fire produces neither.
System reality
The suite will enforce a model. The question is whose.
An S2P suite is not neutral. Every approval threshold, every mandatory field and every workflow branch is an operating-model decision, made once in configuration and then enforced thousands of times a day.
When the operating model is unresolved at configuration time, the implementation partner resolves it. Not out of malice, but because the project needs an answer to move. What gets frozen is a reasonable guess made by people without the mandate to make it. Undoing that later costs more than deciding it now.
Before automating
Automation, and what it does to a broken seam
Automation applied to a clean seam removes work. Applied to an unclear one, it removes the human who was quietly compensating for the ambiguity. The exception volume does not fall. It changes shape and becomes harder to trace.
The readiness question is narrow and answerable. For the decision you want to automate, is the owner named, is the threshold defined, and is the data the decision depends on trustworthy at the moment of the decision. Three yeses make automation worth doing. Anything less and you are scaling the ambiguity, faster and with less visibility than before.
Questions leaders ask first
Before the next S2P programme
Is S2P a process question or a technology question?
Neither on its own. S2P is a chain of ownership transfers that process describes and technology enforces. A process redesign that the systems do not enforce changes nothing. A system rollout without settled ownership freezes whatever ambiguity exists at configuration time.
We already have a suite. Do we need to replace it?
Usually not. Most S2P pain traces to seams the suite was never configured to hold, not to the suite itself. Establish which seam is leaking before assuming the tool is the constraint. Replacement is the most expensive way to discover the model was the problem.
Where does the biggest leakage sit?
Rarely at payment, which is where it is measured. Most leakage originates at the first two seams, when the requirement reaches procurement already specified and already timed. Everything downstream inherits that loss and then gets blamed for it.
Our adoption numbers are low. Is that a training problem?
Almost never. Adoption is a routing question. People use the path that is fastest to a working outcome. If the compliant path is slower, training makes people aware of a route they will still not take. Measure both paths end to end before designing an intervention.
Where does this start?
With one senior read of which seam is actually leaking and whether the position is redesign, stabilise or scale. That answer changes what the next twelve months should cost.
Proof
Proof before methodology.
Use the proof stack to reduce buying risk, then start with one senior diagnosis before adding another program, tool, workshop or consulting layer.
Open Proof