Why nearly every accounts payable exception is created upstream, what an agent takes over in the purchasing chain, and why most companies start at the wrong end.
What is procure to pay?
Procure to pay, also called purchase to pay or P2P, is the whole process from the moment someone needs something to the moment the supplier is paid and the item is reconciled. In steps:
- Someone needs something and raises a request
- The request is approved
- A purchase order goes to the supplier
- The goods or services arrive and the receipt is booked
- The invoice arrives
- The invoice is matched against order and receipt
- The invoice is coded, approved and posted
- Payment goes out and is reconciled
Three terms get used interchangeably here. Source to pay starts a step earlier, at selecting suppliers and negotiating contracts. Procure to pay starts at the request. Order to cash is the mirror on the sales side: from order to cash received.
Steps 5 through 8 are accounts payable. That is what AI agents for accounts payable covers. This piece is about what happens before that, and why it decides how much work is left afterwards.
Where the chain breaks in practice
Per step, with what we see in practice.
| Step | What goes wrong | What we saw |
|---|---|---|
| Request | There is no request. Someone calls the supplier. | At an aviation company on Exact, purchase order approval runs entirely by phone or verbally, not in the system |
| Raising the order | The order is created afterwards, or skipped | A maintenance company on NetSuite registers and approves every invoice manually, whether or not an order exists |
| Booking the receipt | The receipt is not there when the invoice arrives | At a retail group on Dynamics, matching at line level is mandatory, so without a booked receipt it stalls |
| Invoice arrives | No reference, no order number | That same retail group retypes a tyre supplier's invoices almost entirely: "we look up that tyre, book the delivery notes, and then we can match" |
| Matching | Cent, currency and fee differences block the match | A line of 17 cents left unmatched. A payment of €20.60 that will not fit a €20 invoice because of a PayPal fee |
| Entities | The order sits on a different entity than the invoice | At a travel services company on NetSuite every group receipt has to be deleted entirely and rebuilt by hand per entity before matching can even begin |
| Approval | The thresholds live in someone's head, not in the system | "If it matches on the purchase line, you can always clear it. If it matches on supplier and amount, I want an employee to look at it every time" |
| Payment and reconciliation | One payment covers dozens of invoices | The remittance advice sits as a PDF in a separate email, and teams shuffle amounts through suspense accounts to clear currency differences |
Look at the left column. The first four rows are about things that happen before accounts payable has anything in hand. And they cause most of the rows underneath.
Why people work around the process
The reflex is to call this a discipline problem. Usually it is not.
A customer put it more sharply than we would have written it: operational urgency consistently beats the administrative purchasing process. If an aircraft is on the ground and a part is needed, that part gets ordered. The purchase order follows later, or not at all. They call it retroactive PO creation, and the administrative debt it produces lands on the accounts payable desk a week later.
This is not something that only happens at small companies who have not sorted themselves out. An international fintech with fifteen entities struggles with exactly the same thing: purchase orders created after the fact because the process up front was too slow for what had to happen.
The conclusion that counts: people work around the process because the process is too cumbersome for the pace of their work. A P2P suite that enforces compliance with another gate makes that worse rather than better. A detour simply forms around it, and the detour becomes the new reality.
What does work is removing the friction where it sits, and automating the clean-up where friction arises anyway. That is a different assignment from making the process stricter.
Six things an agent takes over in the purchasing chain
1. Turning a request into an order
The request arrives as an email, a receipt, a message or a supplier quote. An agent reads what is being ordered, from whom, at what price, and drafts an order request in the system. That makes the barrier to doing it "quickly on the side" higher than the barrier to doing it properly, and that is the only way compliance actually improves.
2. Tracking down the receipt when it was never booked
The invoice is there, the order is there, and the receipt is missing. That is the most common reason a 3-way match does not close. An agent finds the delivery note, looks in the mail of the department that accepted the goods, and asks if that does not settle it. On that last step the recipient is a colleague, not the supplier.
3. Reconstructing an order for an invoice with no reference
No order number on the invoice, or a number the supplier copied wrong. An agent finds the order itself based on supplier, amounts, items and lines, and shows how confident it is instead of pretending to know. If it cannot close the gap, the invoice goes to your team with the candidates attached.
4. Classifying differences before anyone looks at them
Not every difference is the same difference. A currency difference, a bank charge, a rounding and a genuine price deviation each call for a different action, and only the last is worth a conversation with the supplier. An agent decides which category it falls into, clears what your rule allows it to clear, and presents the rest with the reason attached.
5. Asking the budget holder what was ordered
On invoices without an order, the only person with the answer is whoever placed it. An agent asks that question, with the invoice and the line in question attached, and processes the answer itself. What happens today is usually that an AP clerk sends that email, hears nothing back, and chases it three days later.
Some companies keep this friction on purpose. One organisation deliberately does not let supplier invoices land straight in the finance mailbox, precisely to force budget holders to see their own costs and subscriptions. That is a legitimate choice, and it is worth knowing whether yours was made deliberately or simply grew that way.
6. Making visible where the chain structurally leaks
This is the step nobody has today and the one that pays off most. Which suppliers structurally invoice without an order number. Which departments do not book their receipts. Which suppliers always stall on the same kind of deviation.
That list falls out of the work the agent does anyway, because it meets every exception and knows why it arose. For a purchasing director that is a more useful report than what most P2P suites pull from their own data, because it is about where the process is not followed in practice rather than about what was registered inside the process.
P2P suites versus agents
A real P2P suite and an agent solve different problems. The distinction is not which features are in the box, but which assumption sits underneath.
| P2P suite or ERP module | AI agent on top | |
|---|---|---|
| Starting assumption | Everyone follows the process | The process is not always followed, and that is the starting point |
| Invoice without an order | Reject or block | Reconstruct the order, propose it, have it confirmed |
| Compliance | Enforce with a gate | Less friction, so the detour stops paying off |
| Missing receipt | Queue | Find it, ask the colleague, process the answer |
| Rollout | Months, migration, retrain everyone | On top of what you have, no migration |
| Exception | Queue for a person | Investigated first, then a person |
| What you can report | What happened inside the process | Where the process is not followed in practice |
This is not an argument for tearing out your P2P suite. If you have a mature purchasing process with real requests and booked receipts, that suite does exactly what it should and your work sits on the accounts payable side. If reality is messier, enforcing harder will not fix it.
Where it stops
An agent cannot create an order that was never placed. If nobody knows what was agreed, there is nothing to reconstruct. What it can do is gather the evidence and put the question to the one person who has the answer. That is real work, but it is not magic.
What your ERP does not offer, an agent cannot write into it. In a pilot on Exact, the default approver at supplier level turned out not to be readable, because Exact has no API for it. You only hit undocumented limits like that during the build. Ask about it per process step you want to automate, not in general.
We do not build the purchasing side. Claridy runs on the accounts payable side and reads your orders and receipts out of your ERP. If you want a system to manage requests, contracts and supplier selection, that is a different category and you should assess it separately.
How to start
With one number, and you can pull it today.
- Measure what share of your invoices arrives without a usable order number. That percentage decides whether you should start upstream or downstream. Under ten percent your problem is in processing. Above thirty percent it is in purchasing, and better invoice processing will not solve it.
- Count how often a match strands on a missing receipt. That is a different problem from a missing order, and it has a different fix: usually a department that does not book receipts, not a supplier doing something wrong.
- Ask why the detour exists. Wherever a step is systematically skipped, there is a reason. Usually it is pace. Fix the reason first, then the rule.
- Run the agent supervised first. Every action as a proposal, your team approves, and then you move the threshold based on what you have seen happen.
Frequently asked questions
Procure to pay is the whole chain from request to payment. Accounts payable is the payables part of it, so from the moment the invoice arrives. Most of the work in accounts payable is caused by what did or did not happen in the steps before it.
Putting the invoice next to the purchase order and the goods receipt, and checking that quantities and prices line up at line level. Without a booked receipt a 3-way match is impossible, and that is the most common reason it stalls. In more depth: 3-way matching at scale.
It depends on where your work sits. If you want to manage requests, approvals and contracts, you need a purchasing system. If your work is clearing up what comes out of purchasing, an agent on your ERP solves that faster, without a migration.
Yes, and then it matters more. On invoices without an order it comes down to coding based on supplier, history and your instructions, and to asking the budget holder. That is exactly the work rule-based software cannot handle.
That is where most chains break first. The order sits on one entity, the invoice comes from another, and the receipt was booked at group level. More on this: invoices across multiple entities in Dynamics.
Processing inside the EU, read-only where possible, and an exportable audit trail per action. The SOC 2 programme is under way and certification is coming. In more depth: is AI safe for your books.
What Claridy does on this chain sits on the procure to pay product page. On the accounts payable side: AI agents for accounts payable. On the distinction between automation, workflows and agents: AI agents for finance. On the architecture: what is a system of action for finance.
Last checked: 2026-08.