P2P Internal Audit Checklist and RCM: Procure-to-Pay Controls for India
Procure-to-pay internal audit tests whether a company can buy, receive, book and pay for goods or services without unauthorised vendors, inflated invoices, duplicate payments, GST ITC errors or MSME payment exposure. A good P2P audit is not a voucher sample. It is a control test across vendor master, purchase orders, goods receipt, invoice booking, approval and payment.
For Indian companies, the P2P audit has three extra edges that global checklists often miss: GST input-tax-credit eligibility, MSMED Act payment timelines, and related-party / conflict-of-interest vendors. The checklist below is an illustrative internal-audit RCM starting point. The final control design, sample/population choice and cadence should be tailored to the entity, risk assessment and agreed internal-audit scope.
P2P RCM: core risks and controls
| Sub-process | Risk | Control | Internal audit test |
|---|---|---|---|
| Vendor onboarding | Fictitious or conflicted vendor added | Vendor creation should require PAN/GSTIN/bank validation, maker-checker approval and related-party declaration | Select all new vendors for the period. Match PAN/GSTIN/bank to documents, approval trail and related-party master |
| Vendor master changes | Bank account changed before payment | Bank changes should require independent callback or signed confirmation | Test every bank-detail change. Compare change date, approver, payment date and beneficiary bank |
| Purchase requisition | Purchase raised without budget or business need | PR approval should include department approval and budget check | Match PR to approved budget and department owner |
| Purchase order | PO bypassed or split below approval threshold | PO approval matrix should be defined by amount, vendor and item category | Identify non-PO invoices and sequential POs just below approval limits |
| Goods receipt | Payment made for goods not received | GRN or service acceptance should be required before invoice approval | Three-way match PO, GRN/service note and invoice |
| Invoice processing | Duplicate or inflated invoice booked | Invoice number, vendor, GSTIN and amount duplicate checks should run before payment | Run duplicate tests on invoice number, round amounts, same bank and same narration |
| GST ITC | ITC claimed without 2B support or blocked-credit review | 2B reconciliation and Section 17(5) review should happen before claim | Compare purchase register to GSTR-2B and blocked-credit flags |
| MSME suppliers | 43B(h) exposure missed | Udyam classification should be captured and payment ageing monitored | Test micro/small supplier invoices against 15/45-day due dates |
| Payment | Unauthorised or wrong beneficiary payment | Payment file should require maker-checker and beneficiary validation | Match bank debit to approved invoice and vendor bank master |
| Close and reporting | Old GRIR/AP balances hidden | GRIR/AP ageing should be reviewed at the cadence set in the audit plan | Age GRIR, debit balances in creditors and advances to vendors |
Fieldwork checklist
1. Vendor master
Start with the vendor master, not the invoice register. Most P2P failures begin before the first invoice is booked.
- New vendors added during the period
- Vendors with missing PAN, GSTIN, address or bank details
- Vendors sharing bank account, email, phone number or address
- Vendors created and paid within a short window
- Vendors with bank-account changes just before payment
- Vendors tagged as MSME without Udyam evidence
- Related-party vendors missing from the related-party master
Reportable observation example: 14 vendors were created during the quarter without independent bank validation. Three of those vendors were paid within seven days of creation. This weakens the vendor-onboarding control and increases risk of fictitious vendor payments.
2. Purchase order and approval
The audit question is not whether a PO exists. It is whether the PO was approved before commitment, at the right level, for the right vendor and item.
- Non-PO invoices
- POs approved after invoice date
- POs split below approval threshold
- Same vendor, same item, repeated small POs
- Purchases from non-preferred vendors without exception approval
- Emergency purchases without post-facto approval
Data test: Sort POs by creator, vendor, item and date. Look for clusters just below approval limits. This catches threshold-splitting better than a random sample.
3. GRN, service entry and three-way match
For goods, test PO to GRN to invoice. For services, replace GRN with service acceptance. Do not let service invoices bypass evidence merely because no physical goods moved.
- Invoice booked before GRN or service acceptance
- Quantity or rate variance between PO, GRN and invoice
- GRNs without invoices for more than 30/60/90 days
- Invoices without GRN or service note
- Debit balances in creditor accounts caused by advance payments
4. Invoice and duplicate payment testing
Duplicate payments rarely look identical after the first filter. Test exact and fuzzy combinations.
| Duplicate pattern | What to test |
|---|---|
| Same vendor + same invoice number | Classic duplicate invoice |
| Same amount + same date + same vendor | Reposted invoice or duplicate payment |
| Same invoice number with punctuation changes | INV-102, INV/102, 102 |
| Same bank account used by different vendors | Possible shell or shared-beneficiary risk |
| Round amount invoices near approval limits | Possible split or fabricated invoices |
5. GST and MSME overlay
For Indian P2P audit, invoice testing is incomplete unless GST and MSME are included.
- Whether GSTIN on invoice matches vendor master and GSTR-2B
- Whether ITC is available in 2B before claim
- Whether blocked credit under Section 17(5) was identified
- Whether reverse charge applies for legal, GTA, security, director services or other notified supplies
- Whether supplier is micro/small under Udyam and payment complied with MSMED Section 15
- Whether 43B(h) exposure is separately tracked for year-end tax computation
What to put in the internal audit report
A P2P observation should carry condition, criteria, cause, effect and recommendation. Avoid vague lines like "purchase process needs strengthening."
Good observation structure:
- Condition: 27 non-PO invoices worth ₹84 lakh were booked during Q2. 11 were approved after invoice booking.
- Criteria: Company procurement policy requires PO approval before vendor commitment for purchases above ₹50,000.
- Cause: Emergency-purchase override is being used without post-facto review.
- Effect: The company may commit spend without budget control, competitive vendor evaluation or appropriate approval.
- Recommendation: Configure ERP block for non-PO invoices above ₹50,000, with CFO-approved exception workflow and monthly internal-audit review.
P2P audit data fields to request
Ask for the data before fieldwork starts. A P2P RCM is much stronger when the auditor can test the full population instead of waiting for voucher pulls one by one.
| Data table | Minimum fields |
|---|---|
| Vendor master | Vendor code, legal name, PAN, GSTIN, MSME/Udyam flag, bank account, creator, creation date, approver |
| Vendor changes | Field changed, old value, new value, maker, checker, timestamp, supporting request |
| Purchase orders | PO number, vendor, item/service, quantity, rate, amount, creator, approver, approval date |
| GRN/service entry | PO link, receipt/service date, accepted quantity, rejected quantity, receiving user |
| Purchase register | Invoice number/date, vendor GSTIN, taxable value, tax, ITC flag, expense/asset ledger |
| Payments | Payment date, bank account, beneficiary account, amount, invoice reference, payment approver |
P2P internal audit FAQ
What is a P2P internal audit?
A P2P internal audit reviews the controls from vendor creation to payment: vendor onboarding, purchase approval, receipt/service acceptance, invoice booking, GST ITC, MSME ageing and payment approval.
What is the difference between P2P audit and purchase voucher checking?
Voucher checking tests selected invoices. P2P audit tests the control chain and exception population: who can create vendors, who can approve spend, whether goods/services were received, whether duplicate invoices exist and whether payments went to approved beneficiaries.
Should P2P testing be sample-based or full-population?
High-risk exception tests should be full-population wherever data is available: duplicate invoice numbers, repeated bank accounts, bank changes before payment, non-PO invoices and MSME overdue ageing. Samples still matter for document review and root-cause testing.
Related CORAA resources
- Internal Audit Software for India
- Enterprise Intelligence and Money Flow Analysis
- MSME 43B(h) Disallowance Checker
- GSTR-2B ITC Reconciliation Tracker
Sources
- ICAI Internal Audit Standards Board, Compendium of Standards on Internal Audit - as on February 2026 and listed by ICAI as applicable from 1 April 2026
- Companies Act, 2013, Section 138 and Rule 13 of the Companies (Accounts) Rules, 2014
- CBIC Tax Information Portal, CGST Act, 2017 - Section 16 and Section 17(5) for ITC eligibility and blocked credits
- MSMED Act, 2006, Section 15 and Income-tax Act, 1961, Section 43B(h)