Procure-to-Pay Explained (RFQ to Payment)

"Procure-to-pay" is the full chain of events between a business deciding it needs something and a supplier actually getting paid for it. Written out as a phrase it sounds like a single, obvious sequence. Lived through in a typical business, it's usually seven or eight separate steps spread across three or four different people, several of whom never talk to each other directly — a requester, a buyer, a warehouse team, and accounts payable, each holding a piece of the same transaction in a different tool.

This guide walks through that chain in order — purchase requisition, RFQ and quote comparison, purchase order, goods receipt, three-way matching, payment, and supplier performance tracking — and is deliberately specific about where each handoff tends to lose time or accuracy when it isn't connected, and what actually changes when it is.

Where It Starts: The Purchase Requisition

Every procure-to-pay cycle begins with an internal request, not an external order. A production supervisor notices raw material is running low, a project lead needs a specific component, or a facilities team needs a replacement part — and someone has to formally raise that need before anyone can go and buy it. That request is the purchase requisition, and it's the step most businesses handle worst, because it's the one with the least visible cost when it's done badly.

In a disconnected setup, a requisition is often a verbal request, a chat message, or an email with "need this by Friday" in the subject line — with no record of who approved it, what budget it falls under, or whether a near-identical request was already raised by someone else in another department the same week. None of that becomes a problem until month-end, when finance is trying to explain a spend variance and nobody can reconstruct why three separate teams ordered the same consumable in the same fortnight.

A structured requisition fixes this by capturing the request as a record from the start — item, quantity, needed-by date, cost center, and the requester — and routing it through whatever approval a business requires before a buyer is even allowed to start sourcing. That single step, done properly, is what lets a purchasing team see the full list of open requests across the business instead of reacting to whichever request reached them first.

RFQs and Comparing Supplier Quotes

Once a requisition is approved, the buyer's job is to find out what it will actually cost and from whom. For anything beyond a routine, low-value item, that means sending a request for quotation (RFQ) to two or three qualified suppliers and comparing what comes back — price, lead time, minimum order quantity, and payment terms all matter, and rarely does one supplier win on all four at once.

This is the step where a huge amount of quiet inefficiency lives. Quotes typically arrive as PDFs or emails in different formats, at different times, quoting different units or currencies, and someone has to manually transcribe all of it into a spreadsheet to compare like with like. It's tedious enough that buying teams under time pressure often skip the comparison altogether and default to whichever supplier responded first or has been used before — which quietly erodes the entire point of running an RFQ in the first place.

A connected procurement workflow logs each supplier's quote against the same RFQ record as it arrives, normalizes it into a common comparison view, and keeps the full history attached to that requisition permanently. A buyer can see, at a glance, that Supplier A is cheaper per unit but has a two-week longer lead time than Supplier B, make the call, and have a documented reason for it — instead of a decision nobody can explain three months later when someone asks why a particular supplier was chosen.

Turning a Quote Into a Purchase Order

Once a quote is accepted, it becomes a purchase order (PO) — the formal, legally binding document that commits the business to buy a specific quantity, at a specific price, by a specific date, from a specific supplier. Where the requisition was an internal request, the PO is the first document in the cycle that leaves the building.

The value of generating the PO directly from the accepted quote, rather than typing it up fresh, is easy to underestimate until you've watched it go wrong. Re-keying a quote into a separate PO template is exactly the kind of manual step where a unit price gets transposed, a quantity gets fat-fingered, or a line item from an earlier draft gets left in by accident — and because the PO is what the supplier will eventually invoice against, an error here doesn't surface until an invoice mismatches weeks later, at which point nobody remembers whether the PO or the invoice is the one that's wrong.

When a purchase order is generated straight from the accepted RFQ line items inside one system, the price, quantity and supplier details carry forward exactly as agreed, with an audit trail back to the original requisition and comparison. Larger orders can also route through an approval threshold — a PO above a set value requiring sign-off from a manager — without that approval living in a separate email thread disconnected from the order itself.

Goods Receipt: What Actually Arrived

When a supplier's delivery reaches the warehouse, someone has to record what actually arrived — not what was ordered, what arrived — against the original purchase order. This is the goods receipt note (GRN), and it's the step that keeps the rest of the cycle honest, because ordered quantity and received quantity are frequently not the same number.

Partial deliveries, over-shipments, damaged units rejected on the spot, and substitutions a supplier made without formally amending the PO are all common and all need to be recorded precisely, item by item, at the point of receipt. In a disconnected setup, this often happens on a paper delivery challan that gets filed away, with the warehouse team's only real communication to the rest of the business being a verbal "it's arrived" — no structured record of quantity variances that finance or purchasing can act on.

Recording the GRN directly against the PO inside the same system does two things at once. It updates inventory in real time, so stock levels reflect what's physically on the shelf rather than what a spreadsheet was last updated to say. And it gives the purchase order a live received-quantity figure, so a PO for 500 units that only received 480 stays visibly open for the remaining 20 instead of silently closing as if the order were complete.

Three-Way Matching: PO, GRN and Invoice

Three-way matching is the control that most directly protects a business from paying for things it didn't get. It checks that three documents agree with each other before an invoice is approved for payment: the purchase order (what was agreed), the goods receipt note (what was actually delivered), and the supplier's invoice (what's being billed). If all three line up on quantity and price, the invoice clears for payment. If they don't, it's held.

Without this check, the default failure mode is simple and common: an invoice arrives, it matches the purchase order on paper, and it gets approved and paid — without anyone re-confirming that the full quantity billed was actually received. A short delivery that was never followed up gets paid in full anyway, because the only document anyone actually looked at was the invoice. Multiply that by a few dozen purchase orders a month and it becomes real, recurring leakage that's very hard to spot after the fact, because each individual discrepancy is small.

When the PO, GRN and invoice all live in the same connected system, matching them isn't a separate manual exercise — the system already knows what was ordered and what was received, so it can flag a mismatched invoice automatically the moment it's entered, before it ever reaches an approval queue. Accounts payable spends its time resolving the small number of genuine exceptions, instead of manually re-checking every invoice against two other documents by hand just to find the handful that don't match.

It's worth being specific about what "held" means in practice — a mismatched invoice doesn't need to become a dispute. Most of the time it's a short conversation: a partial delivery the supplier already knows about, a price variance from a rate change that wasn't updated on the PO, or a quantity that's genuinely still in transit. Three-way matching doesn't create these discrepancies; it just makes sure someone looks at them before money moves, rather than after.

Accounts Payable and Payment Processing

Once an invoice clears matching, it moves into accounts payable for scheduling and payment. This stage looks straightforward on paper — pay the supplier by the due date — but it's where cash flow planning and supplier relationships actually get decided, because when and how a business pays affects both.

A disconnected AP process usually means someone maintaining a separate list of what's due and when, cross-referencing it against bank balances manually, and chasing internal approvals for payment runs over email. It's slow, and it's also opaque to the rest of the business — a purchasing team has no visibility into whether a supplier they depend on is being paid on time, until that supplier starts complaining or, worse, starts deprioritizing the business's orders.

When accounts payable sits inside the same system as the PO and GRN, a matched invoice flows straight into a payables ledger with its due date, early-payment discount terms if any, and supplier bank details already attached — no separate lookup required. Payment runs can be batched, approved through the same role-based workflow used elsewhere in the business, and reconciled against the bank statement automatically, closing the loop from a requisition raised weeks earlier to cash actually leaving the account.

Supplier Performance Tracking

The procure-to-pay cycle doesn't really end at payment — it feeds back into the next RFQ. Every purchase order carries a record of how it actually played out: was the delivery on time, was the quantity correct, did the goods pass quality inspection, did pricing match what was quoted. Tracked consistently, that history is the single best input a business has for deciding who to buy from next time.

Most businesses don't track it consistently, because doing it by hand means someone pulling delivery dates from one system, quality rejection rates from another, and pricing variance from a third, then stitching it together into a scorecard that's stale by the time it's finished. In practice, that means supplier selection ends up running on memory and habit — "we've always used them" — rather than on an actual record of how they've performed.

Because a connected system already has the PO, the GRN and the invoice for every past order, supplier performance metrics — on-time delivery rate, quantity accuracy, quality acceptance rate, price consistency — build themselves as a byproduct of running the cycle, rather than requiring separate effort. That history then becomes visible right at the point it's useful: inside the next RFQ comparison, where a buyer choosing between two similarly priced quotes can see which of the two suppliers has actually delivered reliably before.

Where the Friction Really Lives

None of the individual steps in procure-to-pay are complicated on their own — raising a request, comparing quotes, placing an order, recording a receipt, matching an invoice, paying it. The friction almost never comes from any single step; it comes from the handoffs between them, where information has to be re-typed, re-checked, or re-explained because the previous step's record lives in a different tool, or no structured record at all.

QTT-ERP's Procurement module runs requisition through to payment as one connected sequence — sharing the same supplier, item and pricing data with Inventory and Finance — so a goods receipt updates stock automatically, a matched invoice flows straight to accounts payable, and a purchasing team can see exactly where every open order stands without chasing five people for an update. If any part of this cycle sounds like where your own team loses time today, seeing it run against your actual suppliers and purchase orders is a far better test than reading about it.

Written by the QTT-ERP Team

Queen Touch Technology builds QTT-ERP, a connected ERP platform for Indian manufacturers, distributors and service businesses. This guide draws on procurement patterns we see across implementations.