Procure-to-pay: from requisition to supplier payment

Every rupee a manufacturer spends on material passes through the same journey: someone realises a thing is needed, someone approves buying it, an order goes to a supplier, the goods arrive, someone checks them, a bill turns up, and eventually the supplier is paid. Done well, that journey is a controlled chain where each step checks the one before it. Done on paper and spreadsheets, it is a series of disconnected forms where a PO can be raised without approval, goods can be received without inspection, and a supplier can be paid for a delivery that was half short. Procure-to-pay is the discipline of running that journey as one connected cycle — and a manufacturing ERP is what makes the connections real.

This guide walks the whole purchase cycle the way a manufacturing ERP runs it — each step, the document it produces, and the control it enforces. It uses the real screen names and document flow of Fast ERP Software, so it doubles as a demo script. For the wider picture — how purchase sits alongside sales, inventory, production and accounts — start with our guide to what manufacturing ERP is, and for the sales side of the business see the quote-to-cash guide.

1. What procure-to-pay actually is

Procure-to-pay — sometimes written P2P, and closely related to purchase-to-pay — is the end-to-end buying process, from the moment a need arises to the moment the supplier is paid. In a manufacturing business the need usually comes from production, and the cycle reaches into inventory and accounts before it closes. The stages are:

• Demand — a shortage surfaces, from MRP, a reorder level, or a requisition against a BOM or stock
• Purchase Estimate (PE) — the buy is estimated by category before it is formally requested
• Purchase Requisition (PR) — an internal request to buy, checked and approved
• Purchase Order (PO) — the external commitment sent to the supplier, then followed up
• Goods Receipt (GRN) — material arrives and is booked into stock against the PO
• Receipt inspection — the received material is checked: accept, reject, or accept-under-deviation
• Supplier bill — the supplier's invoice is matched to the GRN and PO and approved
• Payment — the bill posts to Tally as a purchase voucher and the payment is scheduled

As with the sales cycle, the difference an ERP makes is that each stage is a numbered, owned, dated document with a status trail, and each inherits from the one before. A goods receipt knows which PO it fulfils; a supplier bill knows which GRN it matches. Nothing is memory-dependent.

2. Where demand starts — shortage, MRP and requisition

Good purchasing is demand-driven, not panic-driven. The cycle should begin with a real, traceable signal that something is needed, and a manufacturing ERP produces those signals in several ways:

• MRP and the material plan. When a released order explodes its BOM, the planning module nets requirements against stock and open orders and surfaces what must be bought, and by when. See Production & Planning.
• Reorder levels. Items carry minimum, maximum and reorder levels on the item master; when stock falls below reorder, the item becomes a candidate for a requisition automatically rather than when someone happens to notice.
• Requisition against a BOM. A requisition can be raised directly against a Bill of Materials for a specific order — so the buy is tied to the job it serves.
• Requisition against stock. Where a top-up is needed, a requisition against current stock levels keeps replenishment tied to the real position rather than a guess.
• Requisition for rejection. When incoming material is rejected, a rejection requisition raises the replacement, so a supplier quality failure does not silently create a shortage on the floor.

Because these signals come from the same database that holds stock, BOMs and orders, the demand that starts a purchase is grounded in fact. This is the first place a patchwork fails: a standalone purchase spreadsheet has no idea what the shop floor actually needs, so buying is reactive and either over-orders (cash tied up in stock) or under-orders (a line stopped for want of a part).

3. Purchase Estimate — costing the buy by category

Before a formal request goes in, larger or recurring buys are often estimated. A Purchase Estimate (PE) lets the buyer scope the spend by category — raw material, finished goods, capital, consumables, infrastructure, maintenance, new-product development, tooling or services — so that budgeting and approval have something concrete to work from. It is the difference between "we'll need some steel" and a costed line the finance owner can weigh.

The categories matter because they route the estimate to the right owner and the right budget. Capital and tooling spend is not consumables spend, and treating them the same is how budgets quietly overrun. In Fast ERP the estimate feeds naturally into the requisition, so the scoping work is not thrown away when the formal request is raised.

4. Purchase Requisition — raise, check, approve

The Purchase Requisition (PR) is the internal request to buy, and it is the control heart of the cycle. It says: the business needs this item, in this quantity, by this date, for this reason. Crucially, it passes through a check and an approval before any commitment is made to a supplier — so buying is authorised, not assumed.

Fast ERP supports the requisition types real manufacturing needs — a standard PR, a PR against a BOM, a PR against stock, a PR for finished goods, a PR for services and a PR for rejection — and routes each through a check step and an approval step. Requisition items can be assigned to a purchase executive, followed up, and reported on as a pending queue, so nothing approved sits un-actioned and nothing un-approved slips into a purchase order. This is where segregation of duties lives: the person who needs the item is not necessarily the person who approves the spend. See Purchase for the requisition detail.

Only once a requisition is approved does it become eligible to turn into a purchase order. That ordering — request, check, approve, then order — is exactly what a spreadsheet cannot enforce, and it is the single most common gap an ERP closes on the purchase side.

5. Purchase Order and follow-up

The Purchase Order (PO) is the external commitment — the document sent to the supplier that says: supply this, at this price, by this date. Because it is built from an approved requisition, its item lines, quantities and rates inherit from work already checked, rather than being typed afresh. The PO is born as a draft and released once complete, and from that point it is a live commitment the business is tracking.

A PO is not finished when it is sent — it is finished when it is fulfilled. Fast ERP tracks each PO through follow-up and pending-PO views, showing ordered versus received quantity so a part-delivered order is visible, and an on-time-purchase report so supplier reliability is measured rather than remembered. The pending quantity — ordered minus received — is a live number, so the buyer always knows what is still owed by which supplier. See Purchase for PO follow-up and MIS.

6. Goods Receipt and receipt inspection

When material arrives, the cycle turns physical. A Goods Receipt (GRN) is posted against the purchase order: the received quantity is recorded, stock is updated on the same store engine inventory uses, and the PO's pending quantity falls accordingly. Receiving against the PO — rather than as a loose stock entry — is what keeps ordered, received and pending in agreement.

But a receipt is not the same as an acceptance. Receipt inspection checks the material against specification and records one of three outcomes:

• Accept — the material passes and is available for use
• Reject — the material fails; it can raise a rejection requisition for a replacement and a non-conformance against the supplier
• Accept-under-deviation — a conditional acceptance where a minor non-conformance is allowed through under a recorded decision, rather than being quietly ignored or quietly rejected

This inspection is part of the same quality module that runs in-process and pre-dispatch inspection, so incoming quality is one auditable record, and the accept/reject/deviation decision gates whether the received stock can actually be consumed or paid for. For an automotive supplier under IATF-16949, this incoming gate and its link to supplier NCRs is not optional. See Quality & APQP.

The control gates — check-and-approve before the PO, inspection before stock is trusted, and a three-way match before payment — are where an ERP protects the money a spreadsheet leaks.

7. Supplier bill, Tally voucher and payment

Now the purchase becomes a payable. The supplier's bill arrives, and before it is approved for payment it is matched against the goods receipt and the purchase order — a three-way check that quantity ordered, quantity received and quantity billed agree, and that the rate matches the PO. This is the single control that stops paying for goods that never arrived, paying twice against one receipt, or paying a rate that quietly crept above the agreed price.

Once the bill is approved, Fast ERP posts it to Tally ERP 9 or TallyPrime as a purchase voucher, so the statutory books reflect the purchase without re-entry, and the payment is scheduled. Advances can be adjusted against the bill, and a payment-follow-up view keeps due dates visible. Because the whole chain — PR, PO, GRN, inspection, bill, payment — lives on one database, you can always answer the questions a pile of paper cannot: what have we committed to this supplier, what have we received, what is inspected and accepted, and what do we still owe? See Accounts, GST & Finance.

8. How Fast ERP Software implements procure-to-pay

Fast ERP runs the whole cycle above with real, named screens, and with each document generated from the one before it on one SQL Server database — so the control gates are enforced, not merely encouraged.

9. Frequently asked questions