Procure-to-pay process: where purchases stall

A marketing manager needs a design tool by Friday. She raises a purchase request, and it waits on an approver who is on leave. On Thursday, she buys it on her company card.

The tool never goes through supplier review, so nobody asks what customer data it will hold. Finance finds the charge at month end with no receipt and guesses the code. The next year, the supplier sends its annual invoice to an inbox nobody watches. It goes unpaid until the supplier threatens to switch the account off.

Every person in that chain did what their system asked. The cost came from the handoffs between procurement, the ERP, email and chat.

This post walks through the seven parts of procure-to-pay automation, where each one breaks, and what to fix first.

What is the procure-to-pay process?

Procure-to-pay (P2P) is the process that turns a business need into a paid supplier. It covers requesting and approving the purchase, reviewing and setting up the supplier, raising the purchase order, receiving the goods, capturing and matching the invoice, and paying it. It runs across procurement, the ERP, contract tools, email and chat, and most of the delay sits in the handoffs between them.

The seven parts, and where each one breaks

1. Purchase request and approval. Someone asks for what they need, and the right people approve it, in parallel where they can. It breaks when the approver is on leave and the team buys on a card instead. Why teams buy on a card instead.
2. Supplier review. A new supplier is checked against what it will reach: data, systems, money or customers. It breaks when a tool that will hold customer data gets the same light check as a stationery supplier. Why every supplier waits for review.
3. Supplier setup and bank details. One record per supplier, shared by every system that orders from or pays it. It breaks when an emailed change of bank details is treated as a routine edit. Who owns the supplier record.
4. Purchase order and budget. The approved request becomes a purchase order, and the spend counts against the budget once it is committed. It breaks when the budget report shows only invoiced spend, so a cost center looks healthy until the invoices land. The spend your budget can’t see.
5. Invoice capture. Invoices are taken from wherever they arrive, read, and checked for duplicates before anything posts. It breaks when a resent invoice gets a new reference and both copies are paid. Why invoices still get keyed by hand.
6. Three-way match and payment. The order, the receipt and the invoice are compared line by line, and matched invoices are paid on the supplier’s terms. It breaks when nobody logs the receipt and the invoice is paid against the order alone. The receipt nobody logged.
7. Cards and expenses. Card spend is matched to receipts and coded within days of the purchase. It breaks when a receipt chased in the last week of the month gets a guessed code. The month-end guess.

Why purchases stall between systems

Approvals live in inboxes. A request that needs three approvers waits on the slowest one, and the requester can’t see where it is.

The supplier is typed in more than once. Procurement, the ERP and the payment run each hold a copy, and the copies drift apart.

Budgets count spend too late. Spend shows up when the invoice posts, weeks after the purchase order committed it.

Invoices arrive outside the system. PDFs land in shared inboxes and are typed in by hand.

Mismatches have no owner. An invoice that doesn’t match its order waits in AP while AP chases the buyer.

What to fix first

1. Fix the supplier record. Every later step reads it, so one owner and a check on bank detail changes come first.
2. Bring every invoice into one queue. Capture from every inbox, with a duplicate check before anything posts.
3. Make the receipt a required step. Without a receipt, a three-way match is a two-way match.
4. Count spend at the purchase order. Budget owners see committed spend as well as what has been invoiced.
5. Move approvals to where approvers already work. They approve in Slack or email, and the decision is written back to the procurement system.
6. Send every exception to a named owner. The buyer who raised the order gets the mismatch, with the documents attached.

Where AI agents fit

Agents do the reading and the first pass on exceptions. They read invoices that arrive as PDFs and say how sure they are, suggest codes for card spend, tell requesters where their purchase is, and summarize a mismatch for the person who owns it. Anything that commits or pays money goes to a person for approval.

How procure-to-pay differs from order-to-cash and source-to-pay

Procure-to-pay is the buy side, from purchase request to supplier payment. Order-to-cash is the sell side, from quote to cash received. The two share the ERP and the general ledger, and little else. For the sell side, see the order-to-cash process.

Source-to-pay starts earlier, with finding suppliers, running bids and negotiating the contract. Procure-to-pay starts when somebody needs to buy something.