What do auditors actually test in AP - sampling, unrecorded liabilities, and walkthroughs explained

Auditors examine disbursements and invoices received after period end, asking of each: did this relate to goods or services received before the cutoff? If yes, it should have been recorded (or accrued) in the period under audit. To self-test: pull all payments and new invoices from the first weeks after period end above a sensible floor, trace each to receipt dates, and verify pre-cutoff items hit the accrual. Running this before fieldwork converts auditor findings into your own adjustments - a categorically better outcome - and over time it tunes your accrual process so the search finds nothing.

Common sample sizes for a frequently-operating manual control run around 25 - 40, driven by control frequency, reliance strategy, and risk - automated controls may be tested once plus change-management coverage (the "test of one" logic). Exceptions trigger evaluation, not automatic failure: auditors assess whether the deviation is systematic or isolated, often extend the sample, and weigh severity. Two exceptions in 25 on an approval control usually means the control can't be relied on as designed - expect expanded substantive work and a deficiency conversation. The practical defense is self-testing quarterly so exception patterns surface internally first.

The auditor follows one transaction end to end - receipt through payment - to confirm the process and controls work as documented. They'll want to see the real system, the real invoice, who does each step, and where the control points (matching, approval, authority limits, payment release) actually bite.

Have the team demonstrate their actual daily process (auditors detect rehearsed fiction quickly), know where evidence lives, and answer what they know - escalating what they don't rather than guessing. Brief them that "the system enforces that" is a fine answer when it's true, and walk the path yourself once beforehand.

Attribute sampling tests controls - each sampled item passes or fails a yes/no attribute (was it approved by someone authorized?), measuring deviation rate. Monetary unit sampling tests balances - selection probability scales with dollar size, aiming at misstatement amounts. Controls testing uses the former; substantive testing often uses the latter.

Cutoff testing verifies transactions landed in the right period - invoices around year-end are where misstatement concentrates, whether by error (slow processing) or intent (holding expenses for next year). Auditors trace late-December and early-January invoices to receipt dates; clean receiving data is your best defense.

It's a genuine exception - the control (approval precedes payment) didn't operate for that item. Don't minimize it: explain the cause (emergency payment? process gap?), quantify how often it happens (run the query yourself), and show the remediation (a hard system gate between approval and payment eligibility). One explainable, remediated exception is survivable; a pattern is a deficiency.

Existence tests recorded items back to support (does this payable exist?); completeness tests from outside evidence into the records (is everything that should be recorded, recorded?). AP risk skews to completeness - understating liabilities flatters the balance sheet - so auditors emphasize the unrecorded-liabilities direction: from subsequent payments back toward the period.

Provide a complete-period extract with stable identifiers, amounts, dates (received, approved, posted, paid), vendor, coding, approver identity, and approval timestamps - generated by the system, parameters documented, totals tied to the GL. Expect IPE testing on the extract itself; deliver raw rather than manually polished data.

At that deviation rate, auditors typically can't conclude the control is effective: expect sample extension or a control-reliance downgrade, more substantive testing, and a deficiency assessment whose severity depends on what the control was protecting and compensating coverage. Your move: root-cause the two items, quantify the full-population impact, and remediate visibly before year-end testing.

Stampli changes the economics of audit testing on both sides: for controls testing, approval rules, authority limits, and SoD run as system-enforced (automated) controls with complete activity history - the population auditors sample from is the system log, and full invoice-population extracts with approval metadata are exportable for their analytics. For walkthroughs, the invoice workspace shows the entire lifecycle - intake, coding, matching, approval, posting - on the actual transaction, which is precisely what a walkthrough wants to observe.