Accounts payable is where your organization’s money leaves the building on purpose — which makes it the place where money leaves the building by accident and by design, too. Nearly every classic occupational fraud runs through AP or its borders: fictitious vendors, inflated invoices, duplicate payments harvested quietly, personal purchases dressed as business ones, kickbacks priced into contracts. The ACFE’s 2024 Report to the Nations puts asset misappropriation in 89% of occupational fraud cases with a median loss of $120,000 and a median 12 months before detection — and disbursement schemes are its beating heart. Add the unglamorous error side (duplicates, wrong vendors, missed discounts, cutoff misses) and AP is the rare audit that reliably pays for itself in recovered cash.
Yet search for guidance on auditing it and you drown in fintech-vendor content written to sell automation to AP managers — not to help an internal auditor build a defensible program. This guide is the auditor’s version, end to end: how the process actually works and where the risk concentrates, a starter risk-and-control matrix, a complete 14-test program with attributes, the analytics that find real dollars, and the findings that recur — with wording that lands. It is the flagship of our How to Audit series; its sibling, how to audit journal entries, covers the other half of the disbursement-fraud universe.
This guide was rewritten in September 2026 to add what the August version left out: how to size and plan the engagement before the first test runs, a worked engagement from start to report (MidState Beverage’s accounts payable audit, which followed the analytics run written up in the AP analytics catalog), the findings written out in full five-Cs form, and the links to the templates that carry the work. The risk map, the starter matrix and the fourteen-test program are unchanged.
In this guide
- Know the terrain: the P2P flow and where risk concentrates
- Sizing and planning the engagement
- The AP risk map
- The starter RCM: ten controls that carry the process
- The 14-test program
- The analytics that find real dollars
- Worked example: MidState Beverage’s AP audit
- The findings that recur — and wording that lands
- Writing the findings in five-Cs form
- Scoping variants: small shop, big ERP, shared services
- Where to go next
Know the terrain: the P2P flow and where risk concentrates
AP is the back half of procure-to-pay: requisition → purchase order → goods receipt → invoice capture → match → approval → payment run → vendor master maintenance humming underneath all of it. Two structural facts should shape your whole audit. First, the classic three-way match (PO = receipt = invoice) only protects the spend that flows through POs — and in most organizations a large minority of spend does not: services, utilities, legal, subscriptions, one-time payments. Ask for the PO-backed percentage of spend in planning; the non-PO remainder is where approval controls carry everything and where your testing should tilt. Second, the vendor master file is the control point everyone ignores: every payment goes wherever the master says, so a weak change-control process there converts every downstream control into decoration. If you audit nothing else deeply, audit the master.
Planning inputs worth an hour each: total invoice and payment volumes by channel (EDI, portal, email, paper); spend by vendor — the concentration curve tells you where a single relationship failure hurts; the duplicate-check configuration (exact-match only is the default and the defect); the approval matrix as configured in the system versus as written in policy; and the interfaces — where invoices enter, where payments leave, and what reconciles the two. Walk one invoice of each type through the system with the AP supervisor before writing a single test; the walkthrough will rewrite half your program.
Sizing and planning the engagement
An accounts payable audit is easy to under-scope and easy to drown in, and both mistakes are made in planning. The under-scoped version tests twenty-five invoices for approval, twenty-five for match, and calls the vendor master “out of scope for this cycle”; it takes a hundred hours and finds nothing, because the money is in the master, the exceptions and the full population. The drowning version tries to run every analytic and every control test on a process with sixty thousand invoices and no hours budget, and ships a report four months late. The planning that avoids both starts with a data request and a walkthrough, and ends with a matrix and an hours budget that agree with each other. The planning memo template is the document the decisions below land in.
The data request goes out before the kick-off meeting, because the extracts take the ERP team longer than anyone admits and the population reconciliation is the first thing fieldwork does. Four tables carry the whole engagement: the invoice table (number, vendor, dates, entering user, amount, PO reference, GL account, approver, payment status), the payment table (payment, vendor, invoice references, date, amount, method, bank account paid, releasing user), the vendor master with its change history, and the employee master from HR, obtained under a documented access arrangement because it carries payroll bank details. Add the delegation of authority as at each date in the period, the workflow log, and the ERP’s configuration for match tolerances, duplicate checking and approval routing, exported rather than described. Then ask five planning questions, each worth an hour: what share of spend is PO-backed (at MidState, 71 percent of invoices but only 54 percent of spend, which is why the non-PO approval tests carried more weight than the match tests); who can change the vendor master and what evidences a change; what the duplicate check actually keys on; whether the approval matrix in the system matches the one in the policy; and where invoices enter and payments leave, by channel. Walk one invoice of each type through the system with the AP supervisor before writing a single test. The walkthrough rewrites half the program every time, and at MidState it rewrote the matrix: the RCM template guide shows the nineteen rows it started with and the twenty-three it ended with.
Hours come last, once the matrix says what will be tested. The budget below is MidState’s, for a mid-sized process with a prior analytics run to build on; a first-time audit of the same process with no analytics behind it would add sixty to eighty hours to the analytics line and take them from nowhere else, which is the honest way to say the engagement gets longer. A small organization with one AP clerk needs perhaps a third of this. The shape matters more than the total: the master and the exceptions get the deep hours, the sample-based tests get the standard hours, and reporting gets more than anyone plans for, because the AP report is the one the CFO reads line by line.
| Phase | Hours | What happens | What it produces |
|---|---|---|---|
| Planning and data request | 40 | Risk assessment refresh, data request issued, population reconciliation to the sub-ledger and the bank, delegation of authority and configuration extracts obtained, kick-off with the controller and the AP manager | Planning memo; reconciled populations; scope and objectives agreed |
| Walkthrough and matrix refresh | 24 | One invoice of each type walked through the ERP with the AP supervisor; tolerance, duplicate-check and routing configuration inspected; prior-year matrix reconciled to what was seen | Refreshed risk and control matrix; work program built from it |
| Vendor master and access | 50 | Tests 1 to 4 and 9: onboarding, bank-detail changes, vendor-employee overlap, duplicate vendors, segregation of duties from actual access | Master-file findings, usually the highest rated |
| Match, approval and exceptions | 70 | Tests 5 to 8: three-way match operation, exception queue handling, non-PO approval, split-transaction sweep; override log analysed in full | Control-operation conclusions; the override finding if there is one |
| Analytics corroboration | 40 | Hits from the analytics run triaged with the analytics auditor: duplicates confirmed to vendor statements, bank changes to requests and call-backs, employee-vendor matches to disclosures | Corroborated findings with amounts; recoveries started during fieldwork |
| Payments, cutoff and reconciliations | 40 | Tests 10 to 14: payment-run release, manual payments, cutoff and unrecorded liabilities, credits and discounts, monthly reconciliations | Detective-layer conclusions; leakage figures |
| Reporting and validation | 56 | Findings drafted in five-Cs form, root causes tested with the process owner, management responses, issue log entries, audit committee summary, file review | Report; issue log; committee one-pager |
| Total | 320 | Audit manager 40 hours of planning and review, staff auditor 200, analytics auditor 80 |
Two sequencing rules protect the budget. Run the full-population analytics before selecting any sample, so that the hits become judgmental selections and the samples cover what the analytics cannot see; a sample of twenty-five drawn at random from sixty thousand invoices is a statement about the population’s average, and the average invoice is fine. And test the vendor master and the access model first, because their results change how much reliance the match and approval tests can take: if anyone can create a vendor and pay it, the elegance of the three-way match is beside the point. The work program guide covers how the tests below turn into steps with attributes, and the sampling memo template records the selections so that a reviewer can reperform them.
The AP risk map
| # | Risk | Where it lives | Error or fraud? |
|---|---|---|---|
| R1 | Fictitious vendor — payments to an entity that exists only on paper | Vendor master + onboarding | Fraud |
| R2 | Payment redirection — legitimate vendor, criminal’s bank account (BEC) | Vendor master changes | Fraud |
| R3 | Duplicate payments — same obligation paid twice | Invoice capture + matching | Mostly error, harvestable as fraud |
| R4 | Inflated or false invoicing — overbilling, phantom line items, kickbacks | Matching + approval | Fraud (often with insider) |
| R5 | Unauthorized purchases — real goods, no authority, personal benefit | Requisition + approval | Both |
| R6 | Split transactions — purchases sliced to duck approval thresholds | Approval routing | Policy abuse |
| R7 | Cutoff and completeness — unrecorded liabilities, expenses in wrong period | Accrual process | Error (or earnings management) |
| R8 | Segregation failures — one person can create a vendor and pay it | Access model | Enabler of everything above |
| R9 | Payment-run integrity — manual payments, run tampering, stale approvals | Disbursement | Both |
| R10 | Credits, discounts, and terms leakage — missed credits, lost early-pay discounts, wrong terms | Vendor terms + processing | Value leakage |
Use the map to argue scope with yourself: R1, R2, and R8 can each be tested through the vendor master and access model in a week and cover the catastrophic scenarios; R3 and R10 are where the recoverable dollars hide; R7 matters enormously at year-end and barely mid-cycle. A tiered engagement that goes deep on the master, the match, and the analytics — and lighter elsewhere — beats uniform shallow coverage of all ten every time.
The starter RCM: ten controls that carry the process
| Ctrl | Control (condensed) | Type / frequency | Answers risk |
|---|---|---|---|
| C1 | Vendor onboarding requires independent verification (tax ID, bank, address, sanctions screen) before first payment | Preventive / each vendor | R1 |
| C2 | Bank-detail changes require callback to a known contact via independently sourced number, evidenced in workflow | Preventive / each change | R2 |
| C3 | Three-way match with tolerances; exceptions worked from a queue with disposition codes | Preventive-detective / each invoice | R3, R4 |
| C4 | System-enforced approval matrix by amount and category; no self-approval; delegation logged | Preventive / each invoice | R5, R6 |
| C5 | Duplicate-payment check with normalized (fuzzy) matching at invoice entry and pre-payment run | Preventive / each invoice | R3 |
| C6 | SoD ruleset: vendor-create, invoice-entry, payment-release mutually exclusive; conflicts monitored | Preventive / continuous | R8 |
| C7 | Payment run reviewed and released by treasury under dual control; manual/urgent payments separately approved and trended | Preventive / each run | R9 |
| C8 | Month-end accrual analysis: open receipts, recurring-spend gaps, post-close invoice review | Detective / monthly | R7 |
| C9 | Vendor master hygiene review: dormant vendors deactivated, duplicates merged, changes report reviewed | Detective / quarterly | R1, R2, R3 |
| C10 | AP-to-GL and bank reconciliation, timely, with aged-item escalation | Detective / monthly | R9, R7 |
This is deliberately a starter matrix — load it into our free RCM Workbench, then adjust to what the walkthrough actually shows: in ERP-mature shops C3–C5 are configuration (test the config once, not samples of outcomes); in smaller shops they are people (test the samples). The map from risk to control to test is the audit — everything after this table is execution.
The 14-test program
Each test names its objective, population, and core attributes. Sample sizes follow standard attribute parameters — the derivation and the decision grid live in our sample-size guide; selection should be seeded and reperformable (mySampler exports the memo). Tests marked ▲ are full-population analytics, not samples — run them before selecting any sample, because their hits become your judgmental selections.
- Vendor onboarding diligence. Population: vendors created in period. Sample 25. Attributes: independent verification of tax ID and bank; sanctions/watchlist screen; business justification; approver independent of requestor. The kill shot: re-perform the verification yourself for five — does the vendor exist at that address, and does the tax ID belong to it?
- Bank-detail change callbacks. Population: master changes touching payment instructions. Sample 25 (or all, if fewer). Attributes: callback to a known contact via an independently sourced number, performed before the change took effect, evidenced. Accept no “the requestor confirmed by email” — that is the fraud, not the control.
- ▲ Vendor-employee overlap. Full master vs. HR file on bank account, address, tax ID, phone. Every hit is either a ghost vendor, an undeclared conflict, or an explainable employee-vendor (relocation reimbursements) — disposition all three ways in writing.
- ▲ Duplicate vendors. Normalized-name and same-bank-account matching across the master. Duplicates are not hygiene trivia; they are the machine that defeats exact-match duplicate checking.
- Three-way match operation. Sample 25 PO-backed invoices. Attributes: match performed within tolerance; quantity and price agree to PO and receipt; exceptions dispositioned with codes by someone independent of the buyer.
- Match-exception queue handling. Sample 25 from the exception queue itself. Attributes: aged within SLA; override rationale documented; overrides not concentrated in one user (if they are, you have found your next test).
- Non-PO invoice approval. Sample 25 non-PO invoices. Attributes: approver authorized for amount and category per matrix; approval preceded payment; no self-approval including via delegation.
- ▲ Split-transaction sweep. Same vendor + same requestor + amounts summing just under a threshold within a short window. Test the pattern’s disposition, not just its existence — some splits are innocent calendar accidents; clusters are not.
- SoD conflict testing. Pull actual access (not the policy): who holds vendor-create with invoice-entry, or invoice-entry with payment-release? For every conflict, test whether the mitigating monitoring control actually ran on that user’s transactions.
- Payment-run release. Sample 10 runs. Attributes: run reviewed against register; dual control at release; totals reconciled to bank; changes after approval re-approved.
- Manual and urgent payments. All of them if volume permits, sample 25 if not. Attributes: justification, elevated approval, subsequent regularization (invoice attached, PO retro-fitted). Manual payments are where discipline goes to die; trend the volume monthly — a rising line is a finding by itself.
- Cutoff and unrecorded liabilities. Post-period-end invoice review (30–45 days), open receipts aging, recurring-vendor gap check (a vendor that bills every month but is missing one). Attributes: liabilities recorded in the proper period; accrual methodology applied consistently.
- Credits and discounts recovery. ▲ Sweep for unapplied credit memos and computed early-pay discounts lost versus terms. This test funds the audit: report the dollars.
- Reconciliation discipline. All 12 monthly AP-to-GL and bank recs. Attributes: timely, reviewed, aged items escalated — the detective net under everything above (and a workpaper structured exactly like our model testing file).
The analytics that find real dollars
AP is the best analytics terrain in the audit universe: complete digital populations, clear money outcomes, and patterns fraudsters cannot avoid leaving. The starter catalog — logic stated plainly enough to build in SQL or even Excel:
| Analytic | Logic | What a hit means |
|---|---|---|
| Near-duplicate payments | Normalize invoice numbers (strip non-alphanumerics, leading zeros); match on vendor + amount + ~date window; then relax one field at a time (same amount + number, different vendor record → the duplicate-vendor route) | Recoverable cash; C5 design gap |
| Vendor-employee match | Bank, address, tax ID, phone against HR master (include inactive employees) | Ghost vendor or conflict |
| Threshold hugging | Histogram of invoice amounts; spike just below approval tiers; drill into vendor-requestor pairs living there | Split purchases; matrix gaming |
| Round-amount concentration | Share of invoices at round thousands by vendor vs. population baseline | Estimated or fabricated billing |
| Weekend and off-hours entry | Invoice/payment creation timestamps outside business pattern, by user | Circumvention window; ties to the JE risk-scoring criteria |
| Dormant vendor reactivation | No activity 18+ months, then payment — especially with a bank change in between | Classic takeover pattern |
| Sequential invoice numbers | Vendor whose invoice numbers to you are nearly consecutive over months | You are their only customer — fictitious-vendor tell |
| Benford / leading-digit screen | First-digit distribution by vendor vs. expectation, flag outliers for review | Screening signal only — never a finding by itself |
Two disciplines keep analytics honest. Validate completeness before believing any of it — tie the invoice extract to the GL and the payment file to the bank, or your “full population” is a partial one wearing a costume. And disposition every hit in writing, even the boring ones: the analytic that found $286,000 of duplicates at MidState is persuasive precisely because its 1,940 raw hits were triaged to 63 and the false positives were counted and cleared, not waved off, which is also what makes the model AP report read as evidence rather than assertion.
Worked example: MidState Beverage’s accounts payable audit
MidState Beverage is the three-state drinks distributor used across this site: twelve depots raising requisitions, two acquired distributors migrated onto a 2013-vintage ERP eighteen months before the audit, a six-person audit function, and an analytics auditor who had just completed the function’s first full AP analytics run. That run, covered test by test in the AP analytics catalog, took 180 hours and produced nine findings on its own. The accounts payable audit that followed in the FY27 plan had a different job: to test whether the controls the matrix described actually operated, to corroborate the analytics hits into findings management could not argue with, and to say something the run could not, which is whether the process was designed to catch the next problem rather than just this one. The population was the same: 61,400 invoices totalling 148 million dollars over fourteen months, 3,140 active vendors, 58,900 payments, reconciled to the sub-ledger and the bank within 2,100 dollars. The table gives the fourteen tests, what each found, and where it went.
| Test | Population and sample | What it found | Where it went |
|---|---|---|---|
| 1. Vendor onboarding diligence | 214 vendors created in the period; sample 25; verification reperformed for 5 | Six of 25 had no independent verification of bank details before first payment; three had no sanctions screen. All five reperformed vendors existed at the stated address. | Finding, Medium; combined with the bank-detail finding as a single vendor-master finding in the report |
| 2. Bank-detail change call-backs | 46 bank-detail changes; all tested | 31 of 46 lacked evidence of a call-back to a known contact; 14 of those preceded a large payment within ten days. One was a business email compromise attempt the bank had stopped. | Finding, High |
| 3. Vendor-employee overlap | Full master against HR (1,400 current, 312 terminated) | Two bank-account matches: a disclosed spouse-owned cleaning contractor, and an undisclosed trucking vendor owned by a depot manager. | Disclosed match cleared with the conflicts register; undisclosed vendor referred under the allegation protocol and kept out of the report |
| 4. Duplicate vendors | Full master, normalised name, tax ID and bank account | 188 duplicate vendor records, almost all created by the migration of the acquired distributors; 29 of the 41 confirmed duplicate payments ran through them. | Finding, High, with the duplicate-payment finding |
| 5. Three-way match operation | Configuration inspected; one transaction per match scenario; sample 25 PO-backed invoices | Tolerance 5 percent or 250 dollars, unchanged since 2019 and wider than the prior-year matrix said. Match operated as configured in all scenarios. 1,860 invoices in three depots were dated before the PO that “authorised” them. | Match effective; retrospective POs raised as a purchasing finding, Medium |
| 6. Match-exception and override handling | 37,400 overrides in fourteen months, mostly route-cash adjustment items; full population | 1,412 overrides approved by the user who entered them. The routing rule allowed self-approval on that item type. | Finding, High; cross-referenced as finding F2 of the route cash audit, where it originated |
| 7. Non-PO invoice approval | Sample 25 non-PO invoices; full-population band analysis against the delegation of authority | Three approvals by users whose limit at the date was below the amount, because the workflow used an outdated delegation table. Invoices clustered just under the 5,000-dollar depot limit at 3.4 times the expected frequency in two depots. | Finding, Medium |
| 8. Split-transaction sweep | Full population, same vendor and requester within seven days | 31 split invoices from one fleet maintenance vendor, all from one depot. | Combined with test 7 in the approval-limit finding |
| 9. Segregation of duties | Actual access extracted, not the policy | Nine users held vendor-create with invoice-entry, six in the acquired distributors’ AP teams; the compensating monthly review had not run since the migration. Two approvals were made through a shared depot login after the named user’s termination. | Finding, High; shared login cross-referenced to the ERP user access audit |
| 10. Payment-run release | Sample 10 runs | Dual control evidenced in all ten; one run’s totals reconciled to the bank a day late. | No finding; observation to the treasury manager |
| 11. Manual and urgent payments | 210 payments outside the run; all reviewed | 40 to vendors, the rest treasury items (tax, debt service) that should have been excluded by design. Vendor manual payments carried elevated approval in 34 of 40. | Finding, Low; treasury items excluded from the next analytics run |
| 12. Cutoff and unrecorded liabilities | 45-day post-close review; open receipts aging; recurring-vendor gap check | No material unrecorded liabilities. Two carriers with a missing month, both accrued. | No finding |
| 13. Credits, discounts and terms | Full population of credit memos; contract terms for the ten largest vendors | Eleven unapplied credit memos, all small, applied during fieldwork. One carrier’s fuel surcharge had risen from 6 to 11 percent of its spend, outside the contract: 38,000 dollars recovered. | Finding, Low |
| 14. Reconciliation discipline | All 12 monthly AP-to-GL and bank reconciliations | All performed and reviewed; three reviewed after the tenth business day; aged items escalated. | No finding; timeliness observation |
The report carried eight findings, four of them High, and an overall rating of Needs Improvement, which the CFO disputed for a week and then accepted when the duplicate recoveries started arriving: 241,000 dollars of the 286,000 dollars confirmed came back from vendors within the quarter, and the fuel surcharge recovery took the quarter’s total to 279,000 dollars, more than the analytics auditor’s annual cost. The referred matter, the depot manager’s undisclosed trucking vendor, never appeared in the report at all; it went to the general counsel under the eight-step protocol in the CFE guide on the day the match was confirmed, and the report’s vendor-master finding was worded so that it did not depend on it. That separation is worth copying. A finding that rests on a suspected fraud cannot be discussed with management until the investigation allows it, and a report that waits for an investigation is a report that ships in the wrong quarter.
Three things about the engagement generalise. The analytics run and the control tests found different things, and each was necessary: the run found the money (duplicates, surcharge, splits), the control tests found the design failures behind it (the check switched off in the migration, the routing rule, the outdated delegation table, the review that stopped running), and only the second set produces actions that prevent next year’s version of the first. The walkthrough was worth more than any single test: the tolerance discrepancy, the fact that the duplicate check keyed on exact matches, and the migration’s vendor duplication all surfaced in the two days spent with the AP supervisor and the ERP analyst before testing began. And the highest-rated findings all lived in the acquired distributors, whose data was the messiest and whose exclusion “for this cycle” had been proposed in planning. The messy part of the population is where the findings are, which is why the risk assessment should treat a recent migration as a trigger rather than an excuse.
The findings that recur — and wording that lands
Five findings account for most AP reports ever written. Exact-match-only duplicate checking (“the system check matches only exact invoice number, vendor, and amount; near-match logic applied to the period’s 61,400 invoices identified 41 duplicate payments totalling $286,000 that no control flagged”). Unverified bank changes (“31 of 46 bank-detail changes lacked callback verification to a known contact — the primary defense against payment-redirection fraud”). SoD conflicts with dead mitigations (“7 users hold vendor-create and invoice-entry; the compensating review designed to monitor their activity has not operated since the 2024 reorganization”). Manual-payment drift (“manual payments rose from 2% to 9% of disbursements over the period, concentrated in one business unit, without the elevated approvals policy requires”). Stale exception queues (“38% of match exceptions aged past the 10-day SLA; $2.1M in invoices paid on override with no documented rationale”). Every one follows the condition-criteria-cause-consequence-action chain from our 5 C’s masterclass — numerators, denominators, named policies, causes that survive the five whys.
Writing the findings: three of MidState’s, in full five-Cs form
The one-line versions in the previous section are how findings are remembered; the five-Cs versions are how they are accepted. The difference is that each element is written so that the process owner can disagree with a fact rather than a tone: the condition carries a numerator and a denominator, the criteria name a policy or a standard, the cause is the one that survived the “why” questions in the validation meeting, the consequence is stated in the organisation’s own money and risk, and the action names an owner and a date. The table gives three of MidState’s findings written that way, following the five Cs guide; the root cause analysis guide covers the cause step, which is the one most often skipped.
| Element | Duplicate-payment control (High) | Bank-detail changes (High) | Override routing (High) |
|---|---|---|---|
| Condition | The ERP’s duplicate-invoice check was switched off during the migration of the two acquired distributors and was not re-enabled. Fuzzy matching across 61,400 invoices identified 41 confirmed duplicate payments totalling 286,000 dollars, 29 of them through 188 duplicate vendor records created by the migration. | 31 of 46 vendor bank-detail changes in the period had no evidence of call-back verification to a contact obtained independently of the request; 14 preceded a payment of more than 25,000 dollars within ten days. One change was a business email compromise attempt stopped by the bank, not by the control. | The approval workflow permitted the user who entered a route-cash adjustment item to approve the override that released it. 1,412 of 37,400 overrides in the period were self-approved, concentrated in four depots. |
| Criteria | AP procedure 4.2 requires system duplicate checking on entry and before each payment run; the migration plan required all AP controls to be confirmed active at go-live. | Treasury policy 7 requires call-back verification of every payment-instruction change before it takes effect, using contact details held on file. | The delegation of authority and the segregation-of-duties standard prohibit self-approval of any item that releases cash or adjusts a cash position. |
| Cause | The go-live checklist covered data migration but not control configuration; no one owned re-enabling the check, and the vendor-master merge that would have removed the duplicates was deferred and never scheduled. | The call-back was performed by whichever clerk received the request, evidenced in personal mailboxes, and never reviewed; the monthly change report was produced but not signed off, so the absence of evidence was invisible. | The routing rule for route-cash items was built for speed during the depot roll-out and exempted from the self-approval block that applies to invoices; the exemption was never revisited. |
| Consequence | 286,000 dollars paid twice, of which 241,000 dollars has been recovered; continuing exposure at roughly 20,000 dollars a month until the check is restored; a duplicate-vendor population that also defeats the exact-match check once restored. | Direct exposure to payment-diversion fraud on a spend base of 148 million dollars; the attempt the bank stopped would have diverted 62,000 dollars. The control that policy relies on cannot currently be shown to operate. | Cash adjustments of 1.9 million dollars released without independent review in the period; the condition the route cash audit found, and the enabling failure behind it. |
| Action and owner | Controller: re-enable the duplicate check with normalised matching (30 days); merge the 188 duplicate vendor records (90 days); add control configuration to the migration checklist for the pending third acquisition. Internal audit: re-run the duplicate family monthly until the merge is complete. | Treasury manager: move call-back evidence to the vendor record with a mandatory field (60 days); AP manager: sign off the monthly change report against the evidence (immediate); internal audit: retest at 90 days. | ERP owner: remove the exemption so the self-approval block applies to all item types (14 days); depot finance: review the 1,412 items for recoverable amounts (60 days, reported through the route cash action plan). |
Notice what each cause is not. It is not “the control did not operate”, which is the condition restated, and it is not “staff were not aware of the policy”, which is the cause that produces a training action and the same finding next year. The migration checklist, the mailbox, and the roll-out exemption are causes that name a decision, and a decision can be reversed. Notice also that every consequence carries a number the CFO can check, and that the actions are split between the fix, the clean-up and the prevention of the next occurrence, with different owners and dates for each. Findings written this way go into the issue log as three or four actions rather than one, and the report template shows where they sit in the document.
Scoping variants: small shop, big ERP, shared services
Small organization (one AP clerk, controller approval): SoD is structurally impossible, so shift weight to detective controls — the owner or CFO’s payment-run review, the bank reconciliation, and your own analytics run across everything; tests 1–4 and 12–14 are the whole audit. Mature ERP: tests 5–7 become configuration testing — evidence the tolerance settings, matrix tables, and duplicate-check rules once, test change control over configuration, and spend the recovered budget on analytics depth. Shared services or BPO: the program above still applies, but layer the third-party dimension — who tests the provider’s controls, what the SOC report actually covers, and whether contractual SLAs match your policy’s control expectations; from September 2026 that layer has a mandatory baseline in the IIA’s Third-Party Topical Requirement.
Where to go next
Audit AP with the structure it deserves, master first, match second, analytics across everything, and it repays you like no other engagement: real dollars recovered, fraud doors closed, and findings whose consequences write themselves. The program above is a complete starting position; tune it with the walkthrough, size it with the sampling grid, build the file like the model workpaper, and report it like Report B in the report examples. The vendor master deserves its own engagement every few years, and the vendor master audit guide is that engagement; the procurement side of the same process, from tender to contract, is in the procurement audit guide. And when someone wants to steal without touching AP’s controls at all, the general ledger is where they go, which is why how to audit journal entries is the next guide in the series.
Related guides
- The accounts payable analytics catalog — the forty tests, and MidState’s first run in full
- How to audit the vendor master — the control point this guide says to audit first
- Risk and control matrix template — with MidState’s AP matrix rebuilt row by row
- The engagement planning memo template — where the scope and hours decisions are recorded
- How to write an audit work program — turning the fourteen tests into steps with attributes
- Audit sample sizes: 25, 40, 60 — the sampling grid the program relies on
- Audit sampling memo template — recording selections so they can be reperformed
- Audit workpaper example — the file structure for a control test
- Segregation of duties — the access-model test in depth
- ERP segregation-of-duties analysis — extracting actual access rather than the policy
- Fraud red flags — what the analytics hits look like from the fraud side
- The CFE guide — including the eight-step allegation protocol used for the referred matter
- The five Cs of audit findings — the structure the findings table follows
- Root cause analysis for audit findings — getting from condition to a cause that can be fixed
- Audit issue log template — where the actions go
- How to audit journal entries — the other half of the disbursement-fraud universe
- How to audit procurement — the front half of procure-to-pay
- The Third-Party Topical Requirement — the mandatory baseline for the shared-services and BPO variant
- All fieldwork and testing guides and all fraud risk guides
- How to audit accounts receivable — the mirror-image process on the revenue side, with Brightwater’s worked engagement
- How to audit inventory — counts, costing and shrink, with MidState’s twelve-depot engagement
- How to audit cash management and bank reconciliations — where the payment run meets the bank statement
- How to audit payment operations and wire transfers — the release controls after the invoice is approved
- Procurement fraud schemes — bid rigging, kickbacks and phantom vendors, and how each one reaches accounts payable
- How to Audit Procure-to-Pay End to End — the integrated P2P audit with a worked engagement.
- How to Audit Order-to-Cash End to End — the integrated O2C audit with a worked engagement.
- How to Audit Account Reconciliations as a Program — the standard, the tests and a worked engagement.
Leave a Reply