Audit & Controls

Internal Audit Red Flags in Procure-to-Pay

An end-to-end audit guide covering vendor master data, purchasing, receipt, invoicing, payment, analytics and root-cause reporting.

By Liakat Hossain · Updated 2026-07-10 · 5 min read · Original educational content

Key takeaways

  • Procure-to-pay risk begins before the invoice—during vendor onboarding, demand approval and purchase-order creation.
  • Strong audit work combines document testing with data analytics and process observation.
  • Duplicate payments, bank-detail changes, split purchases, aged GR/IR items and manual overrides deserve priority.
  • Findings should identify the root cause, financial exposure, responsible owner and sustainable corrective action.

The procure-to-pay cycle moves cash from the organization to suppliers. It includes vendor creation, requisition, approval, purchase order, receipt, invoice processing, payment and accounting. Because several functions participate, control gaps can remain hidden between departments. A risk-based audit should follow the complete transaction rather than review each function in isolation.

1. Vendor onboarding and master-data risks

Weak vendor controls can enable fictitious suppliers, conflicts of interest, duplicate records or payments to unauthorized bank accounts. The audit should verify independent approval, legal and tax documentation, bank verification and screening against existing employees or related parties.

  • Multiple vendors using the same bank account, address, phone number or tax identifier.
  • Vendor created and first payment processed by the same user or within an unusually short period.
  • Frequent bank-detail changes immediately before payment runs.
  • Inactive vendors reactivated without documented business need.
  • Free-text or one-time vendors used for recurring purchases.

2. Requisition and purchase-order red flags

The purchase requisition should demonstrate a legitimate business need, budget availability and appropriate approval. Purchase orders should be created before commitment and should reflect agreed quantity, price, specification, delivery terms and payment terms.

Red flagPossible riskAudit response
Purchase order created after invoice dateRetrospective approval or bypass of procurement.Measure frequency, value and responsible users; inspect justification.
Repeated orders just below approval limitsSplit purchasing to avoid authority thresholds.Aggregate by requester, vendor, date and category.
Single-source purchase without supportOverpricing, favoritism or conflict of interest.Review waiver approval, market evidence and related-party indicators.
Price changes after approvalUnauthorized commercial modification.Compare original, revised and invoiced price with change logs.

3. Goods receipt and service confirmation

Payment should be supported by evidence that goods or services were received. For goods, inspect receiving records, quality acceptance and inventory posting. For services, verify deliverables, time records, milestones or responsible-manager certification. Generic statements such as “service completed” may be insufficient for material or recurring engagements.

Audit attention should focus on receipts posted by procurement staff, receipts reversed after payment, large receipts at period end, quantities above the order, and long-outstanding goods-received/invoice-received balances.

4. Invoice processing and three-way match

A three-way match compares the purchase order, receipt and supplier invoice. Tolerances should be approved, appropriate to risk and monitored. Manual release of blocked invoices should be logged and reviewed.

  • Duplicate invoice number with different punctuation, spacing or leading zeros.
  • Same amount and vendor paid within a short period.
  • Invoice date or number altered after entry.
  • Unusual round amounts or repeated amounts across vendors.
  • Invoices posted directly to expense without a purchase order where policy requires one.
  • Credit notes not matched to the original invoice.

5. Payment-run and banking risks

Payment proposals should be independently reviewed before release. The reviewer should see vendor, amount, due date, bank account, payment method, blocked items and unusual changes. Bank files should be protected from modification after approval, and the bank confirmation should reconcile to the accounting posting.

High-risk sequence: vendor bank details changed, invoice entered, payment released and vendor details changed back within a few days. This pattern should be detected through change-log analytics.

6. Accounting and period-end risks

Procure-to-pay affects expenses, inventory, assets, liabilities, tax and cash. Auditors should review account coding, capitalization, withholding taxes, foreign exchange, prepayments, accruals and cut-off. Debit vendor balances, old advances and aged GR/IR items may indicate unresolved process errors or missing liabilities.

7. Useful audit analytics

TestFields requiredPurpose
Exact and fuzzy duplicate invoicesVendor, invoice number, date, amount, currency.Identify duplicate or slightly altered invoice submissions.
Approval-limit testingRequester, approver, PO value, date, category.Identify split orders and threshold avoidance.
Vendor-employee matchBank account, phone, address, tax ID.Identify possible conflicts or fictitious vendors.
Weekend/after-hours postingsUser, timestamp, document type, amount.Focus on unusual manual activity.
Bank-change-to-payment gapVendor change log and payment date.Detect suspicious changes before payment.
PO-after-invoice ratePO creation date and invoice date.Measure retrospective purchasing.

8. Build a risk-based sample

Random sampling alone can miss significant exceptions. Combine high-value transactions, new vendors, bank changes, manual invoices, blocked-invoice releases, emergency purchases, related parties and unusual users. Trace selected items end to end and inspect system logs, not only printed documents.

9. Report root cause, not only exceptions

A finding should distinguish isolated error from systematic weakness. Common root causes include unclear policy, insufficient segregation, poorly configured tolerances, lack of training, unmonitored overrides, incomplete master data and pressure to pay urgent suppliers. Recommendations should address the cause and include an owner, target date and measurable completion evidence.

Audit fieldwork checklist

  1. Understand the process, systems, roles and approval matrix.
  2. Reconcile the vendor and payment populations to the general ledger.
  3. Review master-data creation and change controls.
  4. Test requisition, sourcing, order, receipt, invoice and payment evidence.
  5. Perform duplicate, split-order, bank-change and override analytics.
  6. Review GR/IR, vendor debit balances, advances and period-end cut-off.
  7. Quantify exposure and validate findings with process owners.
  8. Agree sustainable corrective actions and follow-up testing.

Frequently asked questions

Is a three-way match enough?

No. It is a central control, but it does not replace vendor due diligence, sourcing approval, segregation of duties, payment authorization and monitoring of overrides.

Which red flag should be tested first?

Prioritize patterns that can directly redirect cash: vendor bank changes, duplicate payments, unauthorized vendors and manual payment-file changes.

Should auditors rely on system reports?

System reports are useful only after completeness and accuracy are validated. Reconcile report totals to the ledger and understand filters, parameters and excluded records.

Conclusion

A strong procure-to-pay audit follows the transaction from business need to cash settlement. Combining control design review, end-to-end testing and targeted analytics provides better assurance than document sampling alone. The objective is to prevent unauthorized spend, detect leakage early and improve the reliability of supplier and accounting processes.

This article is original educational content based on professional finance practice. Real-project examples are anonymized, and scenario figures are identified as model outputs rather than guaranteed results.