Why change order SLAs mislead, and what agents measure instead
A change order SLA is a service-level commitment that a change order – a formal amendment to a purchase order's price, quantity, delivery date, or terms – will be processed within a fixed window once it exists in the system, typically 24 to 72 hours from creation. Procurement teams publish change order SLAs as evidence that changes move quickly. The metric times the paperwork, and the paperwork routinely begins days or weeks after the change it records was actually agreed.
This wiki covers source-to-pay terms for operations where AI agents carry the transactional work – syncing amendments, chasing confirmations, clearing match failures – and people keep the judgment calls. A conventional glossary tells a team how to hit its processing SLA; this page explains why the SLA misleads even when every target is met, and what an agent-run change process measures in its place.
Change order SLAs start the clock at the wrong moment
The timer starts when a change order record is created in SAP or Ariba. The change itself happened earlier: in a phone call, a buyer's email, a supplier order confirmation carrying a new date. Between the agreement and the record, the change exists only in people's heads and inboxes, and the ERP keeps generating documents from data everyone involved knows is stale. Goods receipts (the records that goods physically arrived) post against superseded delivery schedules. Invoices arrive at prices the PO has never heard of. A team can hit a 48-hour SLA on one hundred percent of its change orders while the average change spent twelve days as an unrecorded verbal agreement first, doing damage the entire time. The SLA sees none of it, because measurement begins at the far end of the gap.
A green SLA can sit on top of eleven days of drift
To make the defect concrete, walk one change through a calendar. On the 3rd, a buyer and a fastener supplier agree by phone to reprice the remaining 60,000 units on a blanket purchase order (a long-running PO that releases shipments against a negotiated total) from $2.40 to $2.61 per unit, effective immediately. The supplier updates its own order entry the same day. The buyer's SAP system hears nothing.
On the 8th, the supplier invoices the first release of 15,000 units at the new price: $39,150 against a PO that still says $2.40. The three-way match (the line-level comparison of invoice, purchase order, and goods receipt) fails on an 8.75% price variance against a 2% tolerance, the variance band a company allows before requiring review, and AP opens an exception. On the 11th, a second invoice fails the same way. On the 15th, the buyer gets to the admin work and creates the change order. Shared services processes it by the 16th, comfortably inside the 48-hour SLA, and the month-end dashboard shows green. The change spent eleven full days, the 4th through the 14th, as an unrecorded agreement, and the two match failures it caused are still open in AP's queue, unattributed to any change order at all.
Per-touch change order SLAs hide the elapsed total
The second defect appears wherever a change crosses desks. Most teams scope change order SLAs per touch: the buyer has 24 hours to submit the amendment, shared services (the centralized team processing amendments for many business units) has 48 hours to process it, and supplier confirmation carries its own 48-hour target. Each clock stops when its desk finishes, and no clock runs in the handoff queues between desks. An amendment can wait two days between buyer submission and shared services pickup, and two more between processing and the confirmation chase, with every individual stage reporting green. One change can take nine elapsed days across three desks while the SLA report shows full compliance at each of them, because the metric was scoped to the desk rather than the change. The same fragmentation is a large part of why change orders overwhelm shared services: the team is measured on throughput per touch, so nobody owns elapsed time.
The clock ranks a trivial date shift and a $2M reprice identically
The third defect is prioritization. An SLA drives queues by age: the oldest item breaches first, so the oldest item gets worked first. A three-day delivery slip on an $1,800 MRO order (maintenance, repair, and operations spend) and a price change across a $2M blanket order carry the same 48-hour deadline and queue in arrival order. While the reprice waits its turn, every invoice the supplier sends matches against the superseded price and fails; the date slip, meanwhile, touches a shipment nobody downstream has scheduled against yet. Consequence lives entirely outside the metric, so effort follows the clock, and the queue's most damaging item enjoys no priority over its most harmless one.
The honest metrics start the clock when reality changes
A measurement system that actually describes change performance needs three numbers, all anchored to the event rather than the record:
- Event-to-record latency. Elapsed time from the moment reality changed – the phone agreement, the reschedule, the confirmed reprice – to the moment the system of record reflected it. In the worked case above, thirteen days, against a reported SLA of one.
- Record-sync completeness. The share of amendments that are both confirmed by the supplier and propagated into every open downstream document: PO lines, scheduled receipts, and invoices already in flight. An amendment processed internally but never confirmed, or confirmed but never reflected in an open receipt, counts as unsynced.
- Drift-caused exception share. The fraction of receiving and invoice exceptions that trace back to a change that had already happened in reality but was absent from the record when the document posted. This number connects the change process to the downstream cost it creates, which per-touch SLAs never do.
An agent shrinks the unmeasured gap toward zero
Every one of those gaps exists because formalization waits on a person remembering to do admin work after the real negotiation is over. An AI agent removes the wait by watching the places change signals first appear: supplier order confirmations, EDI acknowledgments (structured order-response messages), buyer email threads, carrier reschedules – the same signal set covered in PO amendments drift from reality. When a confirmation arrives carrying a new date or a reply thread settles on a new price, the agent drafts the amendment against the live PO, routes whatever approval the change requires, sends the supplier confirmation request, and checks open receipts and invoices for documents the change affects. Automating change orders covers the mechanics; the measurement consequence matters here. Detection at the source collapses the pre-formalization lag, the part no SLA ever measured, toward zero. Asking whether the paperwork beat a 48-hour clock stops being informative once the paperwork starts within minutes of the signal. The honest report for an agent-run change process has two lines: elapsed time from signal to fully synced record, and the share of changes the system detected on its own versus the share people had to report to it. The second number is the one a CPO should watch, because every change the system catches unprompted is a receipt failure and an invoice exception that never happened.
Fragment builds AI agents that run change orders this way inside a company's existing SAP or Ariba environment: reading confirmations and buyer threads, drafting and processing amendments, chasing supplier confirmation, and keeping open receipts and invoices matched to the terms reality actually settled on, with no rip and replace. See the workflows Fragment covers or book a demo.