Most audit failures aren't about fraud — they're about quietly accumulated coding mistakes that nobody caught at the time. By the time the audit arrives, the patterns are baked into a year of transactions and unwinding them is the painful part. The five mistakes below are the ones we see most often, drawn from real audit-failure post-mortems with practices using everything from spreadsheets through to fully-automated tools.
For each one I'll cover the shape of the mistake, why it survives normal review, and the queue-level fix that prevents it.
1. Duplicate coding on payment processors
The pattern: an Uber Eats transaction shows up in the bank feed as a debit. It also shows up in the Square or Stripe export as a sale. Both are coded — the sale as revenue, the bank debit as the payment-processor settlement. So far so good. But the bookkeeper, working through the bank feed independently, also codes the original bank-side transaction as an expense (because Uber Eats looks like an expense vendor). Now the revenue is doubled and the expense is fictional.
Why it survives review: The two entries are months apart in the bookkeeper's working day. The reconciliation tools match on amount, not on the underlying relationship between sale and settlement. If you only review the P&L summary, the inflated revenue offsets the fictional expense and the net looks plausible.
The queue-level fix: Build a rule that says "any transaction descriptor containing UBER EATS / DOORDASH / MENULOG / SQUARE / STRIPE / PAYPAL — flag for manual settlement review." The point is to prevent the rule engine from confidently coding it as either revenue or expense. A manual review queue with five entries a week is much cheaper than an audit failure.
2. GST split errors on mixed-supply invoices
The pattern: a single invoice contains both GST and FRE items. The most common example is a supermarket receipt — fresh food (FRE), prepared food (GST), and cleaning products (GST), all on one line in the bank feed as a $94.20 debit to Woolworths. The bookkeeper codes the whole thing as GST and overstates the input tax credit by the GST-free component.
Why it survives review: Per-transaction the dollar amount is small, but across a year of supermarket runs for a hospitality business, the cumulative over-claim is substantial. The BAS itself doesn't detect this — it just adds up what you tell it. The error only surfaces if the auditor pulls a sample of supermarket receipts and notices that 30% of the line items are GST-free.
The queue-level fix: Any vendor known to sell mixed supplies (supermarkets, hardware stores with cafés, fuel stations with retail) gets a "mixed supply — requires receipt split" flag on the coding rule. The bookkeeper either pulls the receipt and splits the line, or applies a practice-default ratio (e.g. 70% GST / 30% FRE for general supermarket runs) and accepts the audit risk knowingly rather than accidentally.
3. Unclaimed CAP — capital purchases hitting normal expense codes
The pattern: a client buys a $2,400 laptop. The bookkeeper, working through a bank feed and not seeing the asset register, codes it as a normal computer-expense line on the P&L. The expense is deductible in the year of purchase, but it should have been a capital purchase coded to G10, contributing to the asset register and depreciating over the useful life.
Why it survives review: The transaction looks like a normal computer purchase. Most coding rules for "office supplies" or "computer equipment" go to the expense P&L code, not to CAP. The error doesn't fail the BAS — both treatments are defensible — but it does mean the asset register is incomplete and the depreciation schedule for tax is wrong.
The queue-level fix: Add a dollar-threshold rule to any expense category that could plausibly contain capital purchases. Anything over $1,500 (the FY27 threshold) gets routed to a "review for CAP" queue instead of straight to an expense code. The bookkeeper sees the dollar amount and makes the call.
4. Inter-account transfers double-counted as income or expense
The pattern: the client moves $20,000 from their operating account to their savings account. Both transactions show up in the bank feed — a debit on operating, a credit on savings. The bookkeeper, processing each account separately, codes the operating-side as a "transfer" but the savings-side as a deposit hitting income.
Why it survives review: Banking-side transfers between accounts at the same bank often arrive in the feed with similar descriptors but no obvious matching reference. Reconciliation tools that scan a single account at a time miss the relationship. The error fails the audit only if the auditor pulls a year of bank statements and notices the $20,000 sitting in income that has no invoice or sales receipt behind it.
The queue-level fix: Run a cross-account transfer detector. Any debit on one account with a matching credit on another account within ±2 days and matching amount gets paired automatically and coded as a transfer (N-T) on both sides. Automated platforms can run this nightly; spreadsheet workflows need a periodic manual check.
5. PayPal / Stripe holding-account drift
The pattern: a client takes payments through Stripe. Stripe collects the customer payment, holds it for 1–2 days, then settles to the bank net of fees. So a $100 sale arrives as $97.10 in the bank ($2.90 in fees). The bookkeeper codes the $97.10 as revenue. The $2.90 of fees is never recorded.
Why it survives review: The P&L looks plausible — revenue is just slightly lower than it should be, fees are slightly lower than they should be. The error doesn't fail validation because there's no validation that catches it. It surfaces only when somebody (auditor or accountant) reconciles the Stripe dashboard against the bank-side coding and notices the gap.
The queue-level fix: Treat the payment processor as a holding account in the chart of accounts. Sales hit the holding account at gross; fees hit the holding account; the bank settlement clears the holding account. This adds one extra journal per settlement but it preserves the gross revenue and the fee separately, which is the audit-correct treatment. Most accounting platforms support this natively once the holding account is set up.
The pattern across all five
Every one of these mistakes has the same structural cause: a bookkeeper looking at one transaction at a time, in isolation, applying a coding rule that's correct for the typical case but wrong for this specific case. The "review queue" approach is the answer to all five — the rule engine flags ambiguity, the human resolves it. The cost is a small amount of human time per week; the value is no audit surprises.
If you remember one thing from this piece: review queues aren't a sign that automation isn't working. Review queues are the part of the system that's actually doing the audit-protection work. The transactions that flow through without manual intervention are the easy ones; the ones in the queue are the ones that would have been errors without you.
Build the queue. Read it every week. Most practices we see that have failed an audit had no queue at all — the rule engine was either right or wrong, and the wrong cases became audit findings.