Why change orders overwhelm shared services, and what agents absorb

Change orders overwhelm shared services teams because the workload has three properties the shared services model handles badly: volume that multiplies with business volatility, an arrival pattern that interrupts rather than queues, and a dependence on planning context the processing team never had. A change order is the formal amendment that keeps a purchase order aligned with what the business now needs – a revised delivery date, a different quantity, an updated price. Each one is small. Taken together, the shape of the work is what breaks the team.

This wiki covers source-to-pay concepts for companies where AI agents carry the operational load and people hold the judgment calls. A typical glossary treats change order processing as a task list for a clerk; this page treats it as a physics problem – why the load behaves the way it does, and which layer of it an agent can absorb.

Change order volume multiplies exactly when the business is stressed

Invoice volume scales with order count. Change order volume scales with order count times volatility, because a single purchase order can change several times over its life – the supplier confirms a later date, the planner trims the quantity, the supplier slips again, the buyer splits the line across two shipments. Four amendments, one PO. A company holding 5,000 open PO lines through a quiet quarter might amend 2% of them in a given week. The same 5,000 lines during a supply disruption or a demand swing can see 8% or more touched, and many of those lines touched more than once.

Volatility also clusters. The weeks that generate the most change orders are the same weeks planners are rerunning MRP – the material requirements planning engine that converts demand into orders – buyers are renegotiating allocations, and suppliers are calling about capacity. The load on the shared services team peaks at the precise moment when every person that team would need to consult is hardest to reach.

The work arrives as interrupts, and a team sized for the average drowns on schedule

Invoice processing has a merciful shape: invoices batch, they queue, and most can wait a day to be worked oldest-first without anything physical going wrong. A change request is tied to a truck leaving Thursday or a production slot on Friday, so it arrives as an urgent one-off with its own deadline, and working it out of order is often the whole point. A team staffed for average weekly load will, by construction, be underwater on every volatile week – and the volatile weeks are when the change order SLAs matter most, because a confirmation that lands after the truck departs is worth nothing.

In practice, take a regional shared services center supporting three plants, with roughly 5,000 open PO lines. A normal week produces about 100 amendments, and three processors who each clear seven a day – a third of cases stall waiting on someone else – give the center around 105 per week of capacity. Comfortable. Then the primary resin supplier cuts its allocation in half and a large distributor pulls an order forward a month. That week touches 8% of open lines: 400 amendments, most raised on Monday and Tuesday. By Friday the backlog stands at 295. The following weeks bring the usual 100 new amendments against the same 105 of capacity, so the queue drains at five per week – on paper, more than a year to clear. In reality it clears a different way: amendments go stale, buyers handle changes by phone, and the records quietly stop matching the world.

The person executing the amendment was never in the planning call

Shared services processing runs on separation: the plant plans, the buyer negotiates, the center executes. For stable transactions that separation is the source of the efficiency. For change orders it is the bottleneck, because the processor keying an amendment into SAP cannot judge whether the change is safe. Can this line slip two weeks? The answer depends on safety stock, on the customer promise dates the line feeds, on whether an alternate supplier was already engaged – context that lives with the buyer and the planner. So every non-trivial change becomes a round-trip to the buyer, which is the slowest path through the busiest person, and on a volatile week that buyer is triaging the disruption itself and answering amendment queries last.

A slow formal path teaches buyers to go around it

Backlogs train behavior. Once buyers learn that the formal amendment path takes four days, they stop using it for anything urgent: they call the supplier, agree the change verbally, and promise themselves they will fix the PO later. The PO record drifts away from what was actually agreed – the pattern documented at PO amendments drift from reality – and drift manufactures downstream work. Invoices mismatch against superseded prices. Goods receipts fail against quantities that changed on a phone call. Every one of those failures lands back on the same shared services organization as a fresh exception to research. The loop feeds itself: the backlog pushes changes informal, informal changes create drift, drift generates exceptions, and the exceptions deepen the backlog that started it.

Agents absorb the change order layer that actually spikes

Watch where the hours go on those 400 amendments and most of them sit in reconciliation and transcription: reading the supplier's confirmation email, comparing it line by line to what was requested, drafting the amendment in the ERP, chasing the acknowledgment that never came, and syncing the contract or scheduling agreement so the next transaction matches. An AI agent operating across source-to-pay runs that layer continuously, and its capacity holds at 400 amendments exactly as it does at 100. The interrupt shape stops mattering, because an agent picks up the confirmation the minute it arrives rather than the day the queue reaches it. The context poverty eases too: the agent assembles the PO history, the contract terms, and the open demand signal before anyone is asked anything, so the buyer who does get pulled in receives a prepared question with the evidence attached instead of a bare request to approve. The automating change orders page walks through the mechanics.

Teams were sized for the paperwork, and the paperwork was never the job

Of the 400 amendments in that volatile week, perhaps 60 contain a call a human should make – a slip that threatens a customer commitment, a price change with contract implications, a supplier whose third revised date deserves skepticism. The other 340 are transcription with a verification step. Shared services teams were sized against all 400, which is why every volatile week finds them underwater by design. The decisions alone are a fraction of the load, and they are far less volatile than the paperwork, because a disruption multiplies the number of records to touch much faster than it multiplies the number of genuinely open questions. When agents absorb the record-keeping layer, the team's work compresses to those 60 calls, and the team finally gets to spend the volatile week on the disruption instead of on its clerical wake.

Fragment builds agents that work change orders this way inside a company's existing SAP or Ariba environment – reading confirmations, drafting amendments, chasing acknowledgments, keeping the PO record aligned with what was actually agreed, and routing buyers only the changes that need a decision. Browse the workflows Fragment runs or schedule a demo.