This guide lists the 20 controls auditors actually test, grouped into six categories, then explains the findings that recur, why decentralized functions struggle more than centralized ones, and how to stop preparing for audits and start being ready for them.
A procurement audit checklist is a structured list of the controls, records, and evidence an auditor examines to confirm that purchasing is authorized, competitive, contracted, received, and paid correctly. It typically covers policy compliance, approval workflows, supplier due diligence, contract compliance, savings validation, and segregation of duties.
Three things make procurement a standing audit priority. The money is large: it is the biggest controllable cost base in most companies. The decisions are discretionary: someone chooses the supplier, sets the price and approves the invoice, and each of those is a point where judgement can be wrong or bought. And the evidence is fragmented: request, approval, contract, order, receipt and invoice often live in different systems or none.
The Association of Certified Fraud Examiners’ 2026 Report to the Nations puts the median loss per occupational fraud case at about USD 104,000, with corruption schemes, which include bribery, kickbacks and conflicts of interest in purchasing, present in around 45 percent of cases.
The Association for Financial Professionals’ 2026 Payments Fraud and Control Survey found that 76 percent of US organizations faced attempted or actual payments fraud in 2025, and 74 percent were hit by business email compromise, the category that includes supplier bank-detail changes. Each of those schemes runs through a control on the list below.
Auditors organize their work programme by control objective, and the six below appear in nearly every one.
| Category | Control objective | What the auditor is really asking |
|---|---|---|
| Policy compliance | Purchases follow the company’s procurement policy | Is there a policy, does anyone follow it, and how would you know? |
| Approval workflows | Every commitment is authorized at the right level before it is made | Can a purchase be made without approval, and has it been? |
| Supplier due diligence | Suppliers are vetted, approved and monitored | Could a fake or conflicted supplier get paid? |
| Contract compliance | Purchases reference contracts and pay contracted prices | Is the company paying what it agreed, and buying from whom it agreed? |
| Savings validation | Reported savings are real and traceable | Would finance recognize this saving in the P&L? |
| Segregation of duties | No one person controls request, approval, receipt and payment | Could one person buy, receive and pay without a second pair of eyes? |
Each item is phrased as the auditor’s test. If the answer requires a search through email, count it as a finding.
The findings repeat because their causes do. Most trace to three.
| Finding | Usual root cause | What fixes it |
|---|---|---|
| Purchases without a PO, or PO raised after invoice | Manual request path; PO seen as paperwork | PO required by the system before commitment; no PO, no payment |
| Approvals missing or below required level | Limits in a document, not in the workflow | Thresholds configured in the system; email approvals not accepted |
| Supplier paid with no onboarding record | Onboarding done by whoever needed the supplier | Onboarding workflow with mandatory checks before a supplier can receive a PO |
| Invoice price above contract price | No link between contract and invoice | Contract prices stored as data; automated price match at invoice |
| Savings unsupported by evidence | Baseline undefined; savings counted at negotiation | Savings recorded against contract, PO and invoice; finance sign-off |
| One user with request, approve and receive rights | Small team, roles combined for convenience | Role design enforced in system access; compensating review where headcount is thin |
| Exceptions undocumented | Exceptions handled by phone | Exception workflow with reason and approver captured |
The first cause is manual process: wherever a step happens in email, the record is optional. The second is exception handling: policies cover the normal case and are silent on the urgent one, so urgency becomes the bypass. The third is tail spend: small purchases across many suppliers, individually beneath notice, collectively the largest population of uncontrolled transactions.
“Every override is a liability. All the company’s money flows through procurement.”
— Mauricio Dezen, VP Professional Services and Customer Success, APSentra, on the Behind Procurement LinkedIn Live
The checklist is the same in both models. The difficulty is not.
A centralized function has one policy, one system and one set of thresholds, so a control either exists or does not. Findings tend to be about coverage: the tail, the subsidiaries, the categories that bypass procurement.
A decentralized function has several of everything. The auditor tests the same control in each unit and finds it enforced in some, documented in others and absent in the rest. Findings tend to be about consistency, and the remediation is harder because it means aligning entities that chose their own processes for reasons that seemed good at the time.
Deloitte’s 2025 Global Chief Procurement Officer Survey found that 57 percent of CPOs cite siloed ways of working as their leading barrier to delivering value. From an audit perspective, a silo is a place where a control can differ, and every difference is a test the function may fail.
The practical answer for decentralized groups is a shared control layer over local execution: one approval framework, one supplier onboarding standard and one savings definition, applied through a system that each entity uses, with local flexibility on categories and suppliers. Our analysis of CFO-CPO alignment covers why finance usually has to sponsor that layer.
Preparing for an audit is what functions do when the record is not already there. Being ready is a property of the process.
Make the record a by-product, not a task. If the request, approval, order, receipt and invoice are created in one system as the work happens, the audit trail exists without anyone assembling it. If any step lives in email, someone will be reconstructing it in the week before the audit.
Test controls on the full population, continuously. Retroactive PO rate, approval compliance above threshold, invoices without a contract reference and supplier records without an onboarding check can all be measured every month on every transaction. An auditor sampling 30 transactions finds what the function should have found first.
Close exceptions inside the workflow. Urgent purchases will happen. The control is not to forbid them but to route them through an exception path that records the reason, the approver and the follow-up, so that the exception is a documented decision rather than a gap.
Reconcile savings with finance quarterly. A savings figure that finance first sees at audit time will be challenged at audit time. Agree the definition and the evidence once, then report on that basis every quarter.
Our analysis of why procurement ROI fails CFO scrutiny covers the savings side in detail; the rest of the checklist follows the same logic. The control that exists in the system needs no preparation.
Most of the 20 items reduce to one requirement: the control and the evidence of the control must be produced by the same action. A source-to-pay platform does this when it is configured to.
Approval thresholds enforced at request block the unauthorized commitment and log the authorized one. Supplier onboarding workflows refuse a PO to a supplier that has not passed the checks, and record who passed them. Contract prices held as data allow the invoice match that catches overbilling. Role-based access enforces segregation of duties without a manager remembering to. And selection rationale captured at award answers the auditor’s most common question, why this supplier, without a search.
The pattern across APSentra client cases is that the audit conversation changes shape once this is in place: from “can you find it” to “show me the exceptions”, which is the conversation a function wants to be having. Where the platform is not yet in place, our comparison of when a team needs a consultant and when it needs a better system helps decide the order.
