Procure-to-pay end-to-end: from requisition to payment by one AI coworker

P2P isn't one process, it's six

Open up procure-to-pay and you find six sequential processes: requisition, approval, purchase order, receipt, invoice match, payment. In most mid-market companies each piece sits with a different team, in a different system, with different people approving. The result is that lead time is set by the waits between steps, not by the work itself.

With an AI coworker covering the whole chain, the gain isn't in any single step but in removing the waits. The requisition, approval and PO happen in the same minute. The receipt is posted the moment the driver's email arrives. The match runs as soon as the invoice lands. And the payment batch is prepared for the next SEPA run, not after three days of Excel.

Step 1: the purchase requisition

A requisition almost always starts with someone on the floor who needs something via email, a form or a Teams message. The AI coworker reads that request, recognises what it relates to, links it to an existing master agreement if there is one, and creates the PR in the ERP. Missing fields (cost centre, vendor, VAT category) it fills in based on earlier requisitions from the same requester for the same kind of item.

Step 2: approval through your own matrix

Every organisation has its own approval matrix per company code, cost centre and amount. The AI coworker knows that matrix and which signature is needed where. For standard requests inside a team lead's mandate it only asks that one approval. Above a threshold it puts approvals in parallel to budget holder and director, with the right context. On overruns it waits, it doesn't push.

Step 3: purchase order with negotiated terms

Once approved, the PO is generated with the prices, lead times and conditions from the active master agreement. For ad-hoc spend the AI coworker checks against the last three comparable POs to confirm the price sits in normal range. If the quote deviates more than x percent, that lands with purchasing as a signal, not a block. The PO leaves through your standard channel (email, EDI, vendor portal) to the supplier.

Step 4: goods receipt and three-way match

On receipt the AI coworker picks up the delivery note, email or EDI message and posts the receipt against the PO. When the invoice arrives, the match runs: PO price and quantity against receipt price and quantity against invoice lines. Inside tolerance the AI posts directly through MIRO (SAP), purchase invoice (Dynamics, Exact, AFAS) or the equivalent journal in Odoo. Outside tolerance the exception route fires, with the right context for the bookkeeper.

What the match actually does in practice:

• Posts price and quantity differences inside tolerance without manual keying.
• Handles unit conversions (cases vs pieces, tonnes vs kg) when notation differs between PO and invoice.
• Links residual amounts to earlier partial deliveries on the same PO.
• Posts differences to a dedicated ledger account for analysis by purchasing.
• Full audit trail per match: which invoice line matches which PO line and which receipt line.

Step 5: preparing the payment batch

Approved invoices collect automatically into the payment batch by due date, terms, and discount thresholds (a one percent discount for paying within eight days gets picked up). The treasurer sees one screen: amount, vendor, invoice number, approval. The AI coworker exports the batch as SEPA XML the moment the treasurer signs off. Nothing goes out unexpectedly, the manual work around it disappears.

What the end of P2P paperwork actually returns

Typical results after three months in production: lead time from requisition to PO drops from seven to ten days to under one, the share of invoices posted without manual intervention rises above 90 percent, and the purchasing and finance team gets time to work on contracts and supplier management instead of data entry. Plan a Quick Scan if you'd like to know which step in your P2P chain costs the most time.