Procure to pay: one process from purchase request to payment

Procure to pay is the chain from a purchase request to the payment of the supplier: request, approval, purchase order, goods receipt, invoice, match and payment. It works when every step refers to the same record, so the invoice can be checked against what was ordered and received, and the budget sees the cost when it is committed, not weeks later when the invoice is booked.

Most of the advice on procure to pay is written for companies that buy software subscriptions and services. Companies that buy materials have a harder version of the problem: partial deliveries, long lead times, quality checks at the goods receipt and prices that change between quote and invoice. That is the version this guide is about.

---

What belongs in a procure-to-pay process?

Seven steps, each with one owner and one output.

1. Request. Someone needs something: a component, a machine part, a service. The request names the item, quantity, cost centre and expected price.
2. Approval. The budget owner approves, by value and category. A 300 euro replacement part should not follow the same path as a 40,000 euro tool.
3. Purchase order. The approved request becomes an order to a supplier, with price, quantity, delivery date and payment terms.
4. Goods receipt. The warehouse or the requester confirms what actually arrived, in what quantity and condition.
5. Invoice. The supplier's invoice arrives and is linked to the order and the receipt.
6. Match and approval. Order, receipt and invoice are compared. Within tolerance, the invoice is approved for payment. Outside it, someone decides.
7. Payment. The invoice is paid on its due date, or earlier if there is a discount for early payment.

The steps are not new. What decides whether the process works is whether they are connected. If the request lives in email, the order in a spreadsheet, the receipt on a delivery note in the warehouse and the invoice in an accounting tool, then every step exists and none of them knows about the others.

Why is procure to pay harder when you buy materials?

A software subscription is ordered once, delivered at once and invoiced every month at the same price. Materials behave differently.

Deliveries arrive in parts. You order 2,000 units, 1,200 arrive in week three and the rest in week seven, and the supplier invoices each delivery separately, or once for everything, or before the second delivery has arrived. Lead times are long. A railway component or a production machine can take most of a year from order to delivery, and during that time the order is a commitment your cash plan and budget need to see. Prices move. The quote said one price, the order confirmation another, and the invoice adds a surcharge for raw materials or freight.

The goods receipt carries legal weight too. Under § 377 of the German Commercial Code (HGB), a business buyer must inspect goods promptly after delivery and report visible defects without delay. If you do not, the goods count as accepted, and you lose most of your claims against the supplier. A goods receipt that consists of someone signing the delivery note at the door does not meet that standard. A receipt step in the system, with quantity and condition recorded on the day of delivery, does.

Where does the process break when the steps sit in different tools?

It breaks in the handovers.

Between request and order, the approval is an email or a line in a chat, and the order is placed by someone who may or may not have seen it. Nobody can show later who approved what.

Between order and budget, the cost appears only when the invoice is booked. A cost centre can look fine in your budget vs actual report while three large orders are already placed and not yet invoiced. By the time the overrun is visible, the money is spent.

Between receipt and invoice, accounts payable has the invoice but not the delivery note, so they ask the warehouse by email. Partial deliveries make this worse, because someone has to work out which part of which order the invoice covers.

Between invoice and payment, approvals wait in inboxes, due dates pass and discounts for early payment expire. The supplier calls, and someone pays the invoice manually to stop the calls.

Each handover costs a few minutes. Across a few hundred invoices a month it costs days, and the bigger cost is that nobody trusts the committed spend.

What should be checked before an order is placed?

Most controls in procure to pay sit at the invoice. The ones that save money sit earlier.

• Budget. Does the cost centre have room for this order, counting orders that are already placed but not yet invoiced?
• Supplier. Is the supplier known and active, with a verified bank account and VAT ID? New suppliers should be checked once, properly, rather than at every invoice.
• Price. Does the price match the quote or the framework agreement? A price check on the order is cheaper than a dispute on the invoice.
• Splitting. Is this one of several small orders that together exceed an approval limit?

The approval itself should depend on value and category. A short chain for small, routine purchases and a longer one for large or unusual ones keeps the process quick without losing control.

What happens at the invoice stage?

If the earlier steps are linked, the invoice stage becomes a check rather than an investigation. The invoice is matched against the order and the goods receipt, line by line, as described in our guide to the three-way match. Differences within a defined tolerance pass. Larger ones go to the person who placed the order, not to whoever happens to open the email.

Since January 2025, German businesses must be able to receive structured e-invoices from domestic suppliers. That helps here: an e-invoice arrives as data, with order number and amounts in fixed fields, so matching starts without retyping. How approval routing works in detail is covered in invoice approval workflows. Approved invoices can then go out together in a batch payment run, timed to take Skonto (the early payment discount) where it is offered.

How does Agent F run procure to pay in one system?

In Agent F, procurement, inventory, payables, budgets and the general ledger share one data model. The request, the order, the receipt and the invoice are linked records, not documents in four tools.

A request is checked against the cost centre budget before it is approved, counting open orders as committed spend. If the order would take the budget over, Agent F flags it before the order goes out, so the decision happens while it can still change something. Approval chains follow your rules by value and category.

The approved request becomes a purchase order. When goods arrive, the receipt is recorded against the order, including partial deliveries, and stock is updated. When the invoice arrives, as an e-invoice or a PDF, Agent F links it to the order and receipt and suggests the match, the account, the cost centre and the VAT treatment, each with a confidence score. Clear matches go to the approver; price or quantity differences are flagged with the reason. Nothing is booked or paid without a person's approval, and each step is recorded in the immutable audit trail. Payment runs through the direct bank integration, and the bookings reach your tax advisor (Steuerberater) through the DATEV export.

To start, pick ten invoices from last month and trace each one back to its request and goods receipt. Note how many handovers needed an email. Then check how much of next month's budget is already committed in open orders that no report shows. Those two numbers tell you where your procure-to-pay process actually breaks.

Learn how Agent F works, or see it on your own purchase orders at agent-f.ai/demo.