P2P bottlenecks: where the process queues, and what agents drain

P2P bottlenecks are the points in the procure-to-pay cycle where transactions arrive faster than they leave – requisitions stacking up in an approver's inbox, invoices sitting in an exception hold queue, goods receipts waiting for the dock to close out its shift. Nearly all of them share one shape: many documents converging on one scarce resource, usually a person's attention. A few are scheduled batches instead, and telling the two apart decides whether a queue can be drained or only managed.

This wiki explains source-to-pay for companies where AI agents carry the operational load – investigating holds, assembling approval evidence, coding invoices – while people keep the calls that require judgment. A process map draws procure-to-pay as boxes joined by arrows; this page redraws it as a chain of queues and asks, stage by stage, which ones an agent can empty.

Most P2P bottlenecks are fan-in points

A fan-in point is any step where work produced by many people funnels to a few. Three hundred requesters raise requisitions; four approvers clear them. Eight thousand invoices arrive each month; three AP analysts investigate the ones that fail a check. The queue at a fan-in point forms even when every individual review is quick, because depth is set by the gap between arrival rate and service rate, and service rate is capped by headcount and the hours in a shift. That is why these queues deepen as transaction volume grows while the staffing plan stays flat.

A second, smaller family of bottlenecks is deliberate. The weekly payment run and the dock that posts its counts at shift end are batch cadences, chosen for control or physical practicality. Waiting there is a design decision with a reason behind it. The distinction matters for the rest of this page, because agents change the arithmetic at fan-in points and leave cadences where policy put them.

The process queues at six stages, each for its own reason

In cycle order, the waiting concentrates here:

1. Requisition approval. The approval threshold turns an executive's inbox into a process step. Take a $1,150 requisition for a torque calibration rig, raised in Ariba on a Monday: policy routes anything over $1,000 to a vice president, and the VP is traveling until Thursday. The requisition waits four days for a decision that takes ninety seconds. Requesters respond by splitting orders under the threshold or buying off-contract, so the visible queue also breeds invisible maverick spend.
2. PO creation. Buyers batch small orders to protect their week. A tail-spend buyer holding forty low-value requisitions will often cut them in one Friday session, which is efficient for the buyer and slow for everyone upstream: a requisition approved Monday becomes a purchase order Friday, and the supplier's quoted lead time starts only then. The delivery date the requester saw at checkout has slipped before the PO exists.
3. Receiving lag. Goods receipts – the ERP records confirming what physically arrived – tend to post at shift end rather than at delivery. A pallet unloaded at 9:40 a.m. becomes a system record at 6:00 p.m., or the next morning if the dock ran long. A correct invoice arriving inside that window fails its match against a receipt that does not exist yet and lands in the quantity and receipt mismatch queue as a false positive.
4. Invoice capture rework. Intake is a queue that feeds itself. A scanned PDF whose 8 reads as a 3, a missing PO reference, a supplier who merged two deliveries onto one invoice – each kicks the document back to an indexing team, and the corrected version re-enters at the back of the line. Capture rework rarely shows up in cycle-time reports because it happens before the invoice exists in the ERP.
5. Non-PO approval chases. An invoice with no purchase order behind it – legal fees, facilities repairs, a conference sponsorship – has no match to run, so someone must find a person willing to vouch for the charge. The chase fans in to approvers who live outside the AP system and answer at email speed. Coding and approval exceptions covers the harder version, where the chase includes deciding which cost center absorbs the spend.
6. The payment run. Most companies pay on a weekly batch. An invoice approved Tuesday waits for Thursday's run; an invoice that misses Thursday by an hour waits a week. This cadence exists for treasury control and bank-file logistics, and it belongs in a different category from every queue above it.

The exception hold queue is the deepest pool

Each queue above delays documents one at a time. The hold queue for invoice exceptions – invoices that failed a price, quantity, tax, or reference check and now need investigation – accumulates, because its inflow scales with transaction volume while its outflow is capped by analyst hours. The arithmetic is tighter than it looks. A company processing 8,000 invoices a month in SAP at a 14% exception rate generates about 1,120 holds; three analysts clearing twenty cases a day manage roughly 1,260 a month. That 140-case surplus is the entire margin, and one analyst's two-week vacation or a quarter-end volume spike erases it. Queues drain only when outflow exceeds inflow, and here the excess is thin enough that the queue never empties – it oscillates around a depth the team has learned to live with, while the oldest holds pass their early-payment discount windows and start drawing supplier calls.

Agents drain the P2P bottlenecks that fan in to attention

An AI agent changes the arithmetic at exactly one kind of bottleneck: the fan-in to human attention. Exception investigation is the clearest case – pulling PO history, reading the contract clause, checking how the last identical mismatch was resolved, posting the match with a documented rationale – because the work is research with a verifiable end state, and agent capacity scales with the queue rather than with a headcount plan. The same logic covers assembling approval evidence, clearing capture rework, and proposing GL codes on non-PO invoices. Manual vs automated exception resolution walks that comparison step by step.

The structural bottlenecks stay. A forklift unloads a pallet at the speed of a forklift, and no software should post a receipt for goods nobody has counted. The payment run keeps its cadence for as long as treasury wants a weekly bank file. Accountability approvals stay human because the signature itself is the control: a $250,000 capital requisition needs a named executive's judgment on the record. What agents change at these points is the preparation – the receipt discrepancy arrives at the dock supervisor already investigated, the approval arrives as a one-screen decision with the evidence attached – so the human minute goes to the decision instead of the lookup.

How do you find your own P2P bottleneck?

Measure queue depth and queue age per stage, and distrust cycle-time averages. An average invoice cycle of nine days can coexist with 300 invoices older than 45 days, because the average pools the touchless majority with the tail, and the tail always lives in one stage. Pull two numbers at each of the seven points above: the count of open items and the age of the oldest one. The stage where age keeps climbing while depth holds steady is your bottleneck, and exception aging explains why the oldest cases are also the most expensive to leave sitting. If any stage in the chain is unfamiliar, the P2P process end to end page maps the cycle these queues attach to.

Fragment builds AI agents that drain the deepest of these queues – investigating exception holds, assembling the evidence approvals wait on, coding what needs coding – inside a company's existing SAP or Ariba environment, while people keep every judgment call. See the workflows agents run or request a demo.