Audit of Accounts Payable: Your End-to-End Guide

You're probably staring at the same problem many finance leads have now. Your AP team pays software vendors in USD, agencies in EUR, contractors through wires, and a handful of contributors in USDC because that's how they want to be paid. The month-end close keeps moving, auditors want clean support, and somewhere in that mix are duplicate invoices, timing mismatches, and liabilities that don't sit neatly inside a bank statement.

That's why the audit of accounts payable has changed. It's still about completeness, accuracy, authorization, and cut-off. But if your company operates across fiat and crypto rails, the old playbook only gets you part of the way there. You need controls that satisfy traditional auditors and procedures that reflect how modern treasury operates.

Table of Contents

• Set the right standard
• What works and what does not

• Set the audit objective before you pull data
• Scope by risk not by convenience
• Build a scope memo your auditors can actually use

• Where losses usually hide
• What standard AP procedures miss in fiat-crypto operations

• Run the tests that actually surface errors
• Adapt the same logic for crypto workflows

• Write findings so people can act on them
• Fix the process, not just the exception
• Audit Documentation and Evidence Checklist

• Prevention beats cleanup
• What strong platform controls look like

Why Your AP Audit Matters More Than Ever

An AP audit used to feel like a backward-looking exercise. Check invoices, tie balances, answer auditor requests, move on. That mindset breaks down when the payment environment is mostly digital and the volume of transactions makes manual review unreliable.

The economic signal is clear. The global Accounts Payable Recovery Audit Service market was valued at USD 1.766 billion in 2025 and is projected to reach USD 2.06 billion by 2032, with a 7.59% CAGR, while 68.3% of all payments are now electronic through ACH, virtual cards, and wires, according to Archive Market Research on AP recovery audit services. More electronic payments mean more scale, but they also mean duplicate payments, vendor overpayments, and fraud can spread undetected if controls are loose.

For a global tech startup, that matters in practical ways:

• Cash leakage hurts twice: You lose the money first, then spend time proving where it went.
• Month-end gets distorted: Open liabilities, FX conversions, and payment timing can misstate what's owed.
• Audit pressure rises: External auditors won't accept “the transaction happened on-chain” as a substitute for a clear audit trail.
• Web3 stakeholders expect speed: They still want fast settlement, but they also want governance.

Practical rule: Treat AP audit work as treasury protection, not just financial reporting support.

That's also why many teams run focused reviews before year-end. If you need a model for a targeted quarter-close review, Disputely's Q4 audit is a useful example of how teams frame recovery and discrepancy checks around a reporting deadline instead of waiting for annual audit pain.

Set the right standard

A good audit of accounts payable answers four basic questions.

First, is every payable real? Second, was it approved properly? Third, was it recorded in the right period? Fourth, can someone else follow the evidence from purchase decision to payment settlement without guesswork?

In hybrid fiat-crypto environments, those questions don't change. The evidence does. A wire confirmation, an ACH trace, a smart contract execution log, and a blockchain transaction hash can all be part of the same liability story. If your process can't connect them, your AP ledger may look cleaner than it is.

What works and what does not

What works is a narrow definition of proof. Every payable needs source support, approval support, ledger support, and settlement support.

What doesn't work is assuming speed equals control. Near-instant settlement can reduce operational friction, but it also shortens the time available to catch the wrong vendor, the wrong wallet, the wrong amount, or the wrong accounting period.

Phase 1 Planning and Scoping Your Accounts Payable Audit

A formal AP audit should happen at least once per year, typically within a structure of Planning, Fieldwork, Reporting, and Review, with the Review phase occurring one year later to confirm that improvements were implemented. It's also a statutory requirement for public companies, as outlined in HighRadius on accounts payable audits.

The planning phase is where most AP audits either become useful or become performative. If scope is vague, the team pulls too much data, tests too little of the right population, and ends up writing findings nobody can use.

Set the audit objective before you pull data

Start with the objective, not the request list. In practice, AP audits usually fall into one of three modes:

1. Financial statement support
   The priority is completeness, cut-off, and ledger accuracy.

2. Control effectiveness review
   The priority is approval routing, segregation of duties, and vendor master integrity.

3. Recovery and leakage review
   The priority is duplicate payments, overpayments, and exception handling.

For a hybrid business, define whether crypto settlements are in scope from day one. If they are, the audit plan should explicitly include wallet-linked payables, USDC-denominated liabilities, exchange conversion records, and the handoff between AP and treasury.

If a payment changes form between invoice approval and settlement, the audit scope has to follow the transformation.

Scope by risk not by convenience

Many teams scope around whatever is easiest to export from the ERP. That's convenient, but it misses the primary risk. A stronger plan uses the same risk signals auditors use during fieldwork: risk assessment criteria, transaction size, and vendor history.

That means your scoped populations should include:

• High-value vendors: Large or strategic suppliers where an error changes reported liabilities.
• Exception-heavy vendors: Suppliers with credit notes, manual overrides, split payments, or frequent changes to instructions.
• Cross-border flows: Payments involving SWIFT, foreign exchange, or multi-entity allocations.
• Web3 counterparties: DAO contributors, contractors paid in USDC, or wallets without standard legal-entity documentation.

If your current banking setup fragments these flows across too many systems, it helps to review how teams approach fiat and crypto business account setup for integrated operations. Fragmentation is a planning problem before it becomes an audit problem.

Build a scope memo your auditors can actually use

A practical scope memo should answer these points:

• Population definition: Which entities, ledgers, wallets, and payment rails are included.
• Period covered: Exact start and end dates, plus any post-period disbursement window.
• Key assertions: Completeness, existence, accuracy, authorization, cut-off.
• Sampling approach: How you'll prioritize large items, unusual vendors, and control exceptions.
• Required evidence: Invoice, PO where applicable, receipt evidence, approvals, ledger entries, payment confirmation, and crypto settlement support if relevant.

Shorter is better. Two pages with clear boundaries beats a long planning packet nobody reads.

Uncovering Hidden Risks in Modern Payables

Month-end closes cleanly. Then two weeks later, treasury finds a USDC payout that cleared on-chain but never tied back to the vendor subledger, and audit asks why a contractor was paid to a wallet with no legal name in the master file. That is how modern AP risk shows up. Not as a single broken control, but as gaps between systems, evidence, and ownership.

Traditional AP audit programs were built for bank files, supplier statements, and invoice images. They are weaker when the payment evidence is split across ERP entries, treasury conversions, wallet approvals, and blockchain explorers. The AICPA's digital assets accounting and auditing guidance is useful here because it frames a practical point many teams miss. Once liabilities can be approved in fiat and settled in crypto, completeness and cut-off testing need different evidence than a standard check register review.

Where losses usually hide

Duplicate payments and overpayments still lead the list, but the failure pattern has changed. In hybrid finance stacks, duplicates often come from manual retries after a failed bank transfer, invoice resubmissions under a different entity name, or a crypto payment executed after the original fiat payment was already released. The ledger may show one vendor balance. Operations may have created two settlements.

Vendor and invoice fraud follows the same old logic with newer wrappers. Weak onboarding, weak change controls, and weak approval trails are still the root causes. The difference is that Web3 contributor payments often arrive with partial identity data, informal contracts, and wallet instructions passed through chat tools. That raises the chance of paying a real person through the wrong address, or paying the wrong person through a real address.

Cross-border and multi-rail payments create another class of audit trouble. The question is not only whether cash left the business. The question is whether the invoice currency, booked liability, FX rate, conversion timestamp, and settlement record all line up. Teams with high volumes of overseas supplier activity should review their business account setup for international payments because fragmented banking and treasury workflows create posting breaks that look small individually and become material over a quarter.

What standard AP procedures miss in fiat-crypto operations

Three areas deserve more audit attention than they usually get.

• USDC liabilities: The obligation may start as a USD invoice, sit in accounts payable as a fiat liability, then settle in stablecoins from a treasury wallet. Audit needs evidence for approval, valuation basis, wallet ownership, and final settlement hash.
• Crypto-to-fiat settlement chains: One supplier payment can involve a token sale, an exchange transfer, a bank receipt, and the final disbursement. If those events are not tied together, the payable can appear open, settled twice, or settled at the wrong amount.
• Pseudo-anonymous counterparties: A DAO contributor may have a signed statement of work and a verified wallet, but no tax form or standard legal-entity profile at the time of payment. That does not remove the liability. It changes the evidence package needed to support it.

I have seen finance teams pass a clean invoice approval test and still fail a payable audit because nobody documented who controlled the destination wallet or how the treasury conversion rate was selected. Auditors will ask those questions. They should.

Control design also shifts in these environments. If payment execution depends on wallet permissions, bots, scripts, or smart-contract logic, finance cannot treat engineering as a black box. Finance needs enough visibility to test who can trigger payment, who can change rules, what logs are retained, and how exceptions are reviewed. A focused technical review such as an AI code security audit can help confirm that the execution layer is not creating unauthorized or incomplete disbursements.

A payable is still a payable even when the evidence sits partly on-chain.

The hardest cases usually involve legitimate services from counterparties who do not fit a normal vendor master record. For those, the answer is not to waive controls. The answer is to replace missing documents with other defensible evidence: engagement approval, proof of service delivery, wallet verification, sanction screening where required, business purpose, and a clear link between the approved obligation and the final payment event. That standard satisfies auditors more often than teams expect, provided the file is complete and consistent.

Phase 2 Executing Core Audit Tests and Procedures

Planning identifies where risk lives. Fieldwork proves whether the control environment catches it.

The strongest AP audits rely on a small set of tests done well. Teams get into trouble when they chase every anomaly but skip the procedures that reveal whether liabilities are complete, approved, and recorded in the right period.

Run the tests that actually surface errors

Start with the classic duplicate payment test. A documented method is to import the check register into Excel, sort by vendor and amount, and flag identical transactions within a defined time window. That matters because nearly two-thirds of UK finance professionals have received duplicate invoices, and about one-third paid them, according to VJM Global's accounts payable audit guidance.

Use that test as a base, then expand it. Don't only look for exact duplicates. Also review near-matches caused by:

• Invoice number variants: One record uses INV-1002, another uses 1002.
• Entity switching: The same vendor submits the same charge to two related entities.
• Split disbursements: A payment is broken into pieces, then the full amount is paid again later.
• Currency changes: The same commercial obligation appears once in invoice currency and once in settlement currency.

Three-way matching still matters. Verify that the payment ties back to the purchase order, the goods received note, and the invoice. If your business doesn't use formal POs for every spend category, replace that with the closest approved evidence chain. The point is the same. Someone authorized the obligation, the business received the service or goods, and AP paid the agreed amount.

Field note: If a payment can't be traced from approval to settlement in one sitting, the process is too fragmented.

The other essential test is the ledger tie-out. Reconcile the AP sub-ledger to the general ledger, then trace selected balances back to journal entries and source support. Through this examination, manual adjustments, suspense postings, and end-of-period cleanups often reveal bigger issues than the invoice population itself.

A useful explainer on audit procedure flow is below.

Adapt the same logic for crypto workflows

The procedures don't disappear when crypto is involved. They need translation.

For USDC liabilities, confirm the approved obligation, the ledger entry, the wallet used for settlement, and the blockchain record showing transfer completion. If treasury converted fiat to USDC before payment, test the conversion record as part of the settlement trail.

For cut-off, review transactions close to period-end with extra care. In traditional AP audits, cutoff testing focuses on invoices received around period-end and on subsequent disbursements that may reveal unrecorded liabilities. The same principle applies to blockchain payments, but the execution time can be much faster and can cross time zones in ways that make ledger dates misleading.

For search for unrecorded liabilities, inspect post-period payments and ask a hard question: did the liability exist before period-end even if the final settlement happened later? In a hybrid environment, that means reviewing bank activity, wallet activity, exchange conversion logs, and approval queues together. Looking at only one rail won't catch the full obligation trail.

Phase 3 and 4 Reporting Remediation and Review

A weak AP audit report usually fails in the same meeting. Finance presents exceptions, operations argues that the issue was isolated, treasury says the payment still cleared, and nobody owns the fix. In a hybrid fiat-crypto environment, that failure is more expensive because one exception can affect financial reporting, wallet controls, sanctions exposure, and contributor trust at the same time.

The report has to do two jobs. It has to satisfy auditors who want a clear record of condition, cause, effect, and remediation. It also has to give operators a plan they can execute without translating audit language into real work.

Write findings so people can act on them

Useful findings are specific enough that an owner knows what to change by the end of the readout. State the failed control, the evidence reviewed, the risk created, the root cause, and the action required. Name the process owner and target date. Vague language wastes a cycle.

For a pseudo-anonymous Web3 contributor, the finding should not say that vendor procedures were incomplete. It should say that AP recorded and settled a payable supported by an invoice file and wallet address, but lacked documented business owner approval, proof of services received, and verified payout instructions. That is a validity, authorization, and misdirection-of-funds issue.

The same standard applies to USDC settlements. If the company booked a liability correctly but cannot tie the payable to the exchange conversion, wallet approval, and on-chain transfer record, report that break in the settlement trail directly. Auditors care because the evidence chain is incomplete. Operators should care because the same gap makes internal disputes and payment recovery harder.

Questions around vendor master integrity and segregation of duties still matter here. The difference is that remediation has to account for contributors who do not fit a normal supplier profile. A practical policy should define what substitute evidence is acceptable, who approves exceptions, and when crypto settlement is allowed instead of bank payment.

Fix the process, not just the exception

Good remediation works at three levels:

• Immediate correction: recover duplicate payments, book omitted liabilities, reverse unsupported entries, correct account coding, or reclassify period-end items.
• Control redesign: tighten onboarding, require retained approval evidence, separate vendor setup from payment release, and document wallet verification standards.
• Follow-up review: test the revised process after implementation and confirm the exception rate dropped.

Teams often stop after the first layer because it feels tangible. The money was recovered. The journal entry was fixed. The case was closed.

It usually is not closed. If the same control breaks again next month, the business corrected an output and left the operating model unchanged.

For Web3-heavy teams, control redesign often means setting evidence standards that fit the actual vendor base instead of pretending every payee has a conventional legal entity file. Require an internal sponsor, scope-of-work support, service acceptance evidence, verified wallet ownership, and approval captured in a retained system record. If contributor invoices originate through a structured Web3 invoicing workflow, the audit trail is easier to review because invoice intake, approvals, and payout instructions stay tied together.

Workflow design matters here. Email approvals and spreadsheet trackers create avoidable disputes during remediation because nobody can prove which version was final. Teams that want cleaner routing and retained approval history often use Wisely workflow automation to reduce unsupported exceptions before they reach the audit file.

Audit Documentation and Evidence Checklist

Review is the part many finance teams rush, especially after a difficult close. Do it anyway. Re-test remediated controls, inspect a fresh sample, and confirm the same issue does not reappear under normal operating pressure. If it does, the report was fine. The process was not.

Using Platform Controls to Simplify Audits

Most AP pain starts long before the audit. It starts when systems allow weak approvals, scattered records, and payment activity that can't be reconstructed without five exports and three Slack threads.

Prevention beats cleanup

The best finance teams design for auditability as part of day-to-day operations. That means the platform itself should preserve evidence, enforce policy, and make exceptions visible before payment leaves the business.

Workflow design matters here. If your approval chain still depends on email forwarding and spreadsheet trackers, the control exists mostly in theory. Teams that want cleaner operational discipline often look at structured approaches to workflow automation because repeatable routing and logging reduce the number of unsupported exceptions that surface later in audit testing.

What strong platform controls look like

In a hybrid fiat-crypto environment, practical controls should include:

• Role-based permissions: The person who creates or edits a vendor shouldn't be the same person who releases payment.
• Multi-level approvals: Higher-risk payments should require additional review based on amount, vendor type, or payment rail.
• Unified transaction history: Finance should be able to trace fiat and crypto activity without rebuilding the story manually.
• Spend controls on cards: Limits, merchant rules, and policy checks reduce out-of-policy spend before it hits AP.
• Conversion transparency: When a liability is settled through FX or crypto conversion, the records should show the path clearly.
• Retained evidence: Approval logs, payment status, and supporting documents should stay attached to the transaction.

For companies billing or settling across both payment worlds, Web3 invoicing workflows are especially relevant because they reduce the disconnect between invoice issuance, approval, and final settlement evidence.

The point isn't automation for its own sake. The point is making the audit of accounts payable less dependent on memory and heroics. When controls are embedded in the payment workflow, AP teams spend less time defending what happened and more time preventing the next problem.

If your company operates across fiat, crypto, and global payment rails, OneSafe gives finance teams a practical way to centralize accounts, payments, cards, approvals, and transaction records in one place. That makes audit preparation easier, strengthens day-to-day controls, and gives both auditors and Web3 stakeholders a cleaner trail from obligation to settlement.