Orchestration Routes the Request. It Doesn't Run the Transaction.

Start with the concession, because it is earned. A procurement-orchestration layer — the intake-to-pay tier that sits above your ERP and your source-to-pay suite — solves a problem that is genuinely painful. Before it, a single request to buy something fractured into a dozen paths: a form here, a chat message there, a card swipe when the form was too slow. The orchestration layer collapses that into one front door. It asks the requester structured questions, pulls the right catalog, decides which approvals and which downstream systems the request needs to touch, and hands each leg to the system that owns it — the suite for sourcing, the contract system for terms, the ERP for the PO, the risk tool for the check.

The payoff is real and worth naming plainly: fewer maverick requests, less shadow spend, a shorter path from "I need this" to "it's ordered," and a single status view across systems that never used to talk. If your problem is that employees cannot find the front door, this is a good answer. Intake and coordinated routing reduce friction and pull spend back under policy. Nothing that follows disputes that.

Now the structural point. Read the verbs the orchestration layer actually performs: it routes, notifies, tracks, reconciles, and reports. Every one of them is a statement about where a request is — not an act that commits it. When the PO needs to become authoritative, the layer hands it to the ERP, and the ERP posts it. When a three-way match must be enforced, or segregation of duties checked, or a budget threshold held, that enforcement happens inside whichever system owns the ledger and the master data. The orchestration layer then reads the result back and lights up the status bar.

You will hear this tier described as a single workflow layer over your whole stack — one place where the process finally lives. Take the phrase seriously and it splits in two. There is a workflow of coordination — who is asked, in what order, with what visibility — and that one genuinely does live in the layer. And there is a workflow of execution — requisition becomes commitment becomes obligation becomes payment — and that one lives in the systems of record, each posting its own step under its own controls. The layer owns the first and narrates the second. Calling both "the workflow" is exactly where the seam vanishes from the slide but not from the architecture.

That seam is easy to miss because the single pane of glass makes the whole thing feel like one system. It is not one system. It is a coordinator sitting above several systems it does not own — each with its own controls, its own data model, and its own moment of commit. The layer can request that a control fire; it cannot be the control. Its authority ends at the API boundary of the system that actually posts the transaction, and everything past that boundary — the enforcement that matters most — runs on someone else's terms.

The consequence is a difference in the kind of control you actually get. Route-then-report tends to produce detective control: the request is coordinated, the PO posts in the ledger, and a spend-analytics or compliance readout later surfaces that it was off-contract, over threshold, or split into two orders to slip under an approval limit. That flag is worth having. But it arrives after the authoritative posting. The commitment already exists; you are now in remediation — chasing a reversal or a supplier conversation instead of a clean stop.

Even the preventive-looking gates have a reach problem. When the coordinator inserts an approval step before it routes the request onward, that gate lives in the coordinator — not in the system that posts. Two seams open. An action taken directly in the system of record, outside the front door, never meets the gate at all. And the gate's decision is only as binding as the downstream system chooses to honor: the coordinator asked, but the ERP is where the transaction becomes real. A control that does not sit at the moment of commit is advice, however well it is routed.

The alternative is not a better coordinator. It is to make the procurement process itself the thing that executes. On a Composable Process Fabric, source-to-pay is modelled, executed, and governed as one workflow that runs the whole arc — intake to sourcing to purchase requisition to PO to receipt to invoice to payment — as a composition of five primitives on a single runtime:

• Deterministic Workflows carry the governance inline — three-way match, segregation of duties, budget and authority thresholds, approval gates — as steps in the execution path, not as reports about it.
• Connectors are the only primitive that touches an external system, and they are what post the authoritative PO or invoice into your ERP and ledger.
• Functions do the deterministic computation, Atomic Agents — with human-in-the-loop as a first-class step — handle the judgment calls, and Intelligence Orchestration composes them, all over a Semantic Ontology so every step reads the same governed meaning of "supplier," "contract," and "commitment."

Here is why the arrangement changes the physics. The gate and the posting live in the same runtime. The Connector that commits the PO is downstream of the Deterministic Workflow step that enforces the control. A non-compliant, off-contract, or over-threshold action cannot reach the posting step — there is no path from an unapproved requisition to a committed PO, because the enforcement is not a message sent to another system and hoped upon; it is the step the transaction must clear to execute at all. The control is enforced at the moment of action, and every action leaves an immutable, per-action record as a property of how it ran — not a log assembled afterward. Supplier risk and performance are computed from that same live process state, so the readout sits on the substrate that executed the work, not on a master data set polled once the invoice already posted.

Be clear about what this does not claim. The fabric does not float above your systems by magic, and it does not replace the ERP on day one. It runs over the existing estate through governed Connectors — it integrates, deliberately and continuously. Anyone selling you zero integration is selling you the same seam under a new name.

The difference is not the number of connections. It is where the enforcement sits relative to them. In the coordinated stack, the connections carry requests and status between systems that each enforce their own controls; the strongest guarantee any single action gets is whatever the owning system happens to check at its own commit, and the coordinator's gate is advisory the moment it crosses the seam. On the fabric, the Connector is a governed primitive inside a runtime that has already enforced the control before the Connector fires. Integration becomes the last mile of a transaction that was governed the whole way — not the boundary where governance is handed off. Same estate; a different place for the control to live.

These are architectural properties of how the fabric is built, illustrated with an ordinary procurement scenario — not a benchmarked result from a named deployment. The claim is about structure: put the gate and the commit in one runtime, and "the control fired" stops being a status you report and becomes a condition of the action existing at all. That is the line between orchestrating a request and running the transaction.