What P2P means in accounts payable
P2P stands for procure-to-pay, sometimes written purchase-to-pay. It is the whole journey a purchase takes through two functions that are often run separately: procurement, which decides what to buy and raises the order, and accounts payable, which receives the invoice, checks it and pays it.
The phrase P2P in AP usually points at the accounts-payable half of that journey, from the invoice landing to the payment clearing, but the two halves only work if they share the same data, the PO and the goods receipt that AP matches the invoice against.
A quick disambiguation, because the terms blur. Accounts payable is the pay side alone. Procure-to-pay is the operational cycle from requisition to payment. Source-to-pay is the wider lifecycle that adds strategic sourcing and contract management on top of P2P. This guide is about the operational P2P cycle, seen through the AP lens.
Who the P2P process matters to, and the pain that drives it
P2P touches more than the AP desk. It runs across procurement and finance, and each role feels a different part of the pain when it is manual. Find your row before the steps below.
Who you are | The pain that drives the search | What a working P2P process gives them |
|---|---|---|
AP clerk or specialist | Keying invoices by hand, chasing POs and GRNs, matching line by line, never sure which invoice is a duplicate | Capture and matching automated, so only genuine exceptions reach the desk |
AP Manager | Late payments, invoices stuck in inboxes, and no clear view of what is pending or why | A standardised workflow with touchless matching, tiered approvals and a live queue |
Finance Controller or CFO | Duplicate or fraudulent payments, weak controls, a slow close, and a cost per invoice nobody can defend | Segregation of duties, a full audit trail, three-way matching and a lower cost per invoice |
Procurement lead | Maverick spend, and POs or GRNs that never reach AP cleanly, so invoices get disputed | PO discipline and a clean handoff, so the PO and GRN that AP matches against are right |
India finance or shared-services team | GST credit stuck on GSTR-2B mismatches, TDS errors, e-invoicing gaps and MSME 45-day exposure | GSTIN and GSTR-2B checks, TDS at payment and e-invoicing built into the flow |
Finance student or professional | Needs the concept, the steps and the vocabulary, often for a role or an exam | The full cycle, the 8 and 12-step models, and the documents, explained plainly |
The P2P process step by step
Here is the full cycle in order: what each step does, who owns it, and where it tends to stall in real operations. Most finance teams work to an eight-step model; a fuller twelve-step version breaks out the sourcing work upstream, and both are below, since which one you use depends on how formal your procurement is.
Step 1: Purchase requisition
The cycle starts inside the business, not with a supplier. A department identifies a need and raises a purchase requisition, an internal request that goes for budget and manager approval before anything is ordered. Owner: the requester and their budget approver. Where it breaks: when requisitions are skipped, spend happens with no approval and lands on AP later as a non-PO invoice nobody expected.
Step 2: Purchase order
Once the requisition is approved, procurement selects a supplier and issues a purchase order, the formal document stating items, quantities, agreed unit prices and delivery terms. The PO is the reference every later step matches against. Owner: procurement or the buying team. Where it breaks: vague or missing POs, which leave AP with nothing firm to match the invoice to.
Step 3: Goods receipt (GRN)
When the goods or services arrive, the receiving team checks them against the PO for quantity and condition and records a goods receipt note. The GRN is the proof that what was ordered was actually delivered. Owner: receiving, the warehouse, or the requesting department for services. Where it breaks: no GRN, or a late one, so the invoice cannot be three-way matched and sits waiting.
Step 4: Invoice receipt and capture
The vendor sends the invoice, by email, portal or e-invoice. A working process pulls it into one intake point and captures the key fields, vendor, invoice number, GSTIN, line items, tax and totals, and checks for duplicates at entry. Owner: accounts payable. Where it breaks: a shared inbox with manual keying, where invoices get lost and the same bill is paid twice.
Step 5: Three-way matching
This is the control at the heart of P2P. AP compares the invoice against the PO and the GRN to confirm the company ordered these items, received them, and is being billed the agreed price. Within tolerance the invoice moves on untouched; outside it, the exception is routed for review. Owner: the system, with AP resolving genuine mismatches. Where it breaks: manual matching, which turns a two-second check into a twenty-minute one and does not scale past a few hundred invoices a month.
Step 6: Invoice approval
A matched invoice routes to the right approver by amount, cost centre or entity, following the delegation-of-authority matrix, with a substitute when someone is out. Owner: budget owners, and above their limit the controller or finance director. Where it breaks: an undocumented approval matrix, so anything unclear defaults upward and senior finance ends up signing routine spend.
Step 7: Payment execution
The approved invoice is scheduled and paid on its due date, by bank transfer, cheque or digital payment, timed to capture early-payment discounts where they exist, and in India with TDS withheld correctly. Owner: AP, with treasury on timing. Where it breaks: missed due dates and lost discounts, or duplicate payments when controls are weak.
Step 8: Reconciliation and recording
The payment clears the liability, the transaction posts to the ledger, and vendor statements and bank records are reconciled so nothing is missed or double-counted. Owner: finance and the controller. Where it breaks: a fragmented trail, which turns month-end close and audit into a reconstruction.
That is the eight-step model most AP teams use. Where procurement is more formal, the same cycle is often published as twelve steps, breaking out the sourcing work before the
PO:
Identify the requirement and raise a purchase requisition
Authorise and approve the requisition
Shortlist potential vendors
Request quotations (RFQ or RFP)
Select and negotiate with the vendor
Create and approve the purchase order
Receive the advance shipping notice
Record the goods receipt against the PO
Record the supplier invoice
Run the three-way match
Pay the supplier
Report, document and reconcile
The twelve-step count is not a formal standard. Publishers split or merge steps, and you will see everything from four stages to twelve, so use whichever grouping matches how formal your own procurement is.
The P2P process flowchart
The eight steps look like a straight line, and for most invoices they are. Here is the standard flow, with the exception loop that the textbook version leaves out:
The one arrow the tidy diagram hides is that loop at three-way matching. A real P2P process is not a straight line; it branches at the match, holds the exceptions on their own track, and only lets clean invoices flow straight through to payment. That branch is where the process actually lives, which is why matching, controls and the segment differences below matter more than the diagram itself.
Key documents in the P2P process
Each step produces or consumes a document, and the process only holds together if they agree. Seven matter, including the two most guides forget.
Purchase requisition. The internal request that starts the cycle and captures budget approval.
Purchase order (PO). The formal document sent to the vendor: items, quantities, prices and delivery terms.
Goods receipt note (GRN). Proof that what was ordered was actually delivered, and in what quantity.
Vendor invoice. The supplier's demand for payment, matched against the PO and the GRN.
Debit and credit notes. Adjustments for returns, short supply or rate corrections, the documents most guides skip but AP cannot.
Payment advice. Confirmation to the vendor of what was paid and against which invoices.
Bank reconciliation statement. Matches payments recorded in the ledger against what actually cleared the bank.
Three-way matching in the P2P process
Matching is the control that stops overbilling, duplicate invoices and quiet price creep before money leaves the building. Which match you run depends on what you bought.
Match type | What it compares | When to use it |
|---|---|---|
2-way | Invoice vs purchase order | Services and spend with no goods receipt |
3-way | Invoice vs PO vs goods receipt | Physical goods, the standard in P2P |
4-way | Invoice vs PO vs goods receipt vs inspection | Regulated or quality-critical goods needing a sign-off |
A strong match checks three levels of data, and getting all three right is what pushes the touchless rate up:
Header level. Vendor name and GSTIN, PO number and tax details must agree across all three documents.
Line-item level. Item code or SKU, unit of measure (pieces versus boxes) and quantities must line up, not just the totals.
Financial level. The invoice unit price must match the PO, and the extended totals, quantity times unit price, must reconcile.
If you demand an exact match on every penny, automation stalls on trivial variances. Mature teams set tolerances instead:
Price variance. Auto-approve if the invoice unit price is within a set threshold of the PO, for example 1% or a fixed cap like $10.
Quantity variance. Allow a small acceptable variance, but hold the invoice if the vendor bills for more than the GRN recorded.
Freight and miscellaneous. Decide whether shipping or handling is auto-approved when it falls under a preset cap.
Anything outside tolerance routes to an exception queue, flags the specific line that failed, and notifies the buyer, receiver or vendor, so only genuine problems reach a person.
Controls, compliance, and India tax in P2P
Three-way matching is one control; a trustworthy P2P process needs a few more. And in some countries the tax rules are part of the process, not an add-on.
The core controls
Segregation of duties. The person who raises the requisition should not also approve the PO and release the payment. Separating requisition, approval and payment is the core fraud control.
Audit trail. Every action logged automatically, so who approved what, and when, is retrievable in seconds rather than reconstructed from email threads.
Vendor master data. One clean, deduplicated vendor record with verified bank and tax details, because most duplicate and fraudulent payments trace back to a messy vendor master.
Duplicate detection. A check at capture for the same vendor and invoice number, which is where most overpayments are caught.
P2P tax compliance in India: GST, TDS and e-invoicing
In India, tax rules ride on top of every P2P step, and AP cannot treat them as an afterthought, because they decide whether the company keeps its input tax credit and stays audit-clean.
GST and input tax credit (ITC). Every vendor invoice must carry a valid GSTIN and the correct HSN or SAC code, checked before the invoice is booked. The buyer can claim credit for the GST paid, but only once the vendor has actually reported the invoice in their GSTR-1, so AP reconciles its purchase register against the auto-drafted GSTR-2B on the GST portal. A mismatch delays or forfeits the credit, which is why vendor filing becomes the buyer's problem.
TDS on vendor payments. Tax deducted at source applies to categories like contractor, professional and rent payments. AP computes and withholds it at payment time against a valid vendor PAN, pays the vendor net, deposits the TDS and issues the certificate, so the TDS logic sits inside the P2P workflow, not beside it.
E-invoicing through the IRP. In-scope B2B suppliers must register each invoice on the Invoice Registration Portal, which returns an IRN and a QR code, and only a validly registered e-invoice supports the buyer's credit. The mandatory threshold has fallen over time and sits at 5 crore of turnover at the time of writing, with a further reduction reported but worth confirming.
MSME 45-day rule. Payments to registered micro and small enterprises must generally be made within 45 days, or the expense can be disallowed, so P2P has to flag MSME vendors and prioritise them.
India tax thresholds, rates and dates change often. Treat the figures here as current at the time of writing, date-stamp this section, and link to the official GST portal or CBIC notification before publishing.
The P2P process by company size, ERP, and geography
The eight steps are the same everywhere. What changes is how formal, how automated and how compliance-heavy the process is. Find your row.
Segment | What the P2P process looks like | What automation it needs |
|---|---|---|
Enterprise (multi-entity, high volume) | Formal PO and three-way match, delegated approval hierarchies, procurement and AP as separate functions, tight SOX and audit controls, thousands of invoices a day | A deep, ERP-integrated P2P suite with touchless matching at scale and exception workflows |
Mid-market | PO discipline exists but exceptions are frequent, a handful of approvers, volume outgrowing manual capacity | Invoice capture, matching and approval automation layered on the existing ERP |
Small business | Often no PO at all, invoice-to-pay only, an owner or single bookkeeper approving, low volume | Light AP automation, or the accounting package's own bill pay, simplicity over depth |
It also changes with the system you run. On SAP, Oracle, NetSuite or Microsoft Dynamics, full requisition-to-pay is native and the process is system-enforced, so automation has to integrate deeply and respect the controls already there, feeding OCR and touchless matching into the ERP rather than replacing it. On TallyPrime, QuickBooks or Zoho Books, common in Indian SMEs, there is often little or no formal PO or GRN and AP is closer to bill entry, so automation is about capturing invoices, coding them, handling GST and TDS, and getting approval before anything hits the ledger.
And it changes with where you operate. A single-country, non-India business runs the simplest version, one currency and one tax regime. An Indian business carries GST, TDS and e-invoicing on top of every step, as covered above. A cross-border operation adds multiple currencies, foreign-exchange handling and withholding tax that differs by jurisdiction, so the process has to consolidate across entities.
Manual vs automated P2P
The reason teams automate P2P is not novelty; it is the gap between the two columns below. Baseline your own numbers first, then watch them move.
Aspect | Manual P2P | Automated P2P |
|---|---|---|
Invoice capture | Manual keying from PDFs and paper | OCR and IDP extract fields automatically |
Three-way matching | Line by line against spreadsheets | Matched within tolerance, touchless |
Reconciliation | Slow and error-prone | Automated against ledger and bank |
Spend visibility | Limited, after the fact | Real-time dashboards |
Exceptions | Every invoice treated alike | Only mismatches routed to a person |
Cost per invoice | Low tens of dollars | A few dollars or less |
Cycle time | About two weeks | A few days or less |
Cost-per-invoice and cycle-time figures are directional, drawn from AP benchmark studies; confirm against your own baseline before publishing.
Risks and best practices in the P2P process
A few failure modes cause most of the pain in a manual P2P process:
Maverick spend. Buying outside approved channels when requisition controls are weak, so spend arrives with no PO to match.
Duplicate invoices. The same bill paid twice without a capture-time check.
Delayed approvals. Invoices stuck in an inbox while an approver is out, missing discounts and due dates.
Compliance gaps. Missed GST reconciliation or TDS, which costs input tax credit or triggers penalties.
Vendor disputes. Mismatched records and late payments that strain supplier relationships.
The fixes are mostly discipline, not software:
Centralise intake. One channel for requisitions, POs and invoices, not scattered inboxes.
Hold PO discipline. Push spend through requisitions and POs so AP always has something firm to match against.
Use vendor portals. Let suppliers submit invoices and their own data, which cuts errors at source.
Set tolerances upfront. Define price, quantity and freight thresholds by category before go-live, not after.
Validate tax at source. Check GSTIN and MSME status at onboarding, not at payment.
Capture early-payment discounts. Flag discount-eligible invoices at capture and prioritise them, so the window does not close in the approval queue.
Measure the touchless rate. Track the share of invoices that complete with no human touch, and work it upward.
How to automate the P2P process
Automating P2P means turning the manual chain into a touchless one. It follows the same lifecycle a clerk would, only faster and without the keying:
Capture. Vendors send e-invoices or PDFs; OCR and intelligent document processing extract the fields and line items automatically.
Integrate. The system pulls the live PO and recorded GRN from your ERP or procurement database.
Match. Within tolerance, the invoice is auto-approved, scheduled and synced to the ledger; outside it, the exception is routed with the failing line flagged.
Comply. In India, GSTIN, GSTR-2B and TDS checks run inside the flow, not after it.
Where a team wants this run for them rather than built, Mindsprint covers the two halves of the cycle: SprintAP on the accounts-payable side, capturing invoices, running the three-way match, routing approvals and executing payment, and ProcureSprint on the procurement side, from requisition and PO through supplier management and goods receipt, so the PO and GRN that AP matches against come from the same connected system. Both are agentic and ERP-agnostic, and because Mindsprint operated this process as a finance function across entities and India's tax context before productising it, the fit is judged on real exceptions, not a clean demo.
