A client called me last week in a panic. Their bookkeeper had flagged a $14,200 invoice from “Apex Consulting LLC” that referenced a real project number, used the correct Net 30 terms, and had a logo indistinguishable from the actual vendor. The only reason they caught it: a 30-second BQL query against their Beancount ledger returned zero prior transactions with that payee.
That near-miss sent me down a research rabbit hole, and the numbers are genuinely alarming.
The Scale of the Problem in 2026
ICAEW published new guidance in March 2026 on spotting AI-generated fake invoices. Combined with Medius research:
- 53% of finance professionals have personally witnessed deepfake invoice scam attempts
- 44% of businesses have been targeted by invoice fraud
- $1.1 billion in deepfake-related fraud losses in the US in 2025 — tripled from $360 million in 2024
- $280,000 mean loss per deepfake incident
- Voice cloning now needs only 3 seconds of audio to impersonate an executive convincingly enough to authorize a wire transfer
- AI-generated fake invoices can be produced in under 10 minutes with free tools
The “Deepfake CEO” scam is now being called the new Business Email Compromise (BEC). Attackers clone a CEO’s voice from a conference recording or YouTube video, call the AP clerk at 4:45 PM on a Friday, and say “I need you to wire $50K to this vendor before the weekend — it’s urgent and confidential.” The caller ID is spoofed. The voice is perfect. Most employees are conditioned to say yes to leadership.
Why Beancount’s Data Model Is Accidentally a Fraud Detection Tool
Here’s what struck me from a CPA compliance perspective: the best defense against invoice fraud is clean, queryable historical data. And that’s exactly what Beancount provides by default.
The bookkeeper who caught that $14,200 fake ran this:
bean-query main.beancount "SELECT date, narration, sum(position)
WHERE account ~ 'Expenses:Contractors' AND payee ~ 'Apex'
ORDER BY date DESC"
Zero results. The invoice claimed “continuation of Q4 2025 services” — a lie exposed in 30 seconds.
Compare this to the typical small business: financial records scattered across 4 bank accounts, 3 credit cards, a QuickBooks file nobody reconciled since November, and a filing cabinet. In that environment, the AP clerk says “looks legit” because verifying would take 20 minutes they don’t have at 4:45 PM on a Friday.
The Fraud Prevention Framework I’m Recommending to Clients
Based on this incident and what ICAEW is advising, I’m building a four-layer verification workflow for my Beancount clients:
Layer 1 — New Payee Detection
A pre-commit hook that queries the full ledger for any payee in a new transaction. If the payee has zero historical matches, the commit is blocked with a warning: “NEW VENDOR — requires enhanced verification before payment.”
Layer 2 — Threshold Controls
Any transaction over $5,000 requires vendor-verified: TRUE and approval: [name] metadata tags. Without them, bean-check rejects the entry. This forces a human to explicitly sign off.
Layer 3 — Historical Cross-Reference
Before paying ANY invoice, run it against the full BQL history. Check: prior transaction count with this vendor, typical payment amounts (is this invoice 3x the usual?), payment frequency (did we already pay this vendor this month?). Anomalies get flagged.
Layer 4 — Contact Verification Protocol
For flagged invoices: call the vendor at a phone number YOU have on file (not the number on the suspicious invoice). This is ICAEW’s top recommendation and it’s shockingly effective.
The Uncomfortable Test
Try this right now:
How many seconds would it take you to verify whether “Apex Consulting LLC” has ever invoiced you before?
If you’re using Beancount with clean data: 30 seconds, one BQL query.
If you’re using QuickBooks: maybe 2-5 minutes, assuming you can remember the exact vendor name and which company file to search.
If you’re using spreadsheets or paper: 20+ minutes, and you’ll probably give up and just pay it.
The speed of verification determines whether fraud succeeds. Deepfake scammers rely on urgency and friction — “pay now, verify later.” Beancount accidentally eliminates that friction.
What I Want to Discuss
From a professional liability standpoint, this keeps me up at night:
- Have you caught or missed a fraudulent invoice? What was the detection method?
- Do you run any automated checks before approving payments? Pre-commit hooks, BQL scripts, anything?
- For multi-client bookkeepers: do you have a standardized AP verification workflow, or is each client ad-hoc?
- The CPA liability question: if a client pays a deepfake invoice and their bookkeeper didn’t verify against the ledger, is the bookkeeper professionally liable? Where does the duty of care line fall?
- Has anyone built a Beancount fraud detection plugin? Something that runs anomaly detection — unusual amounts, new payees, payment pattern deviations?
The $14,200 my client almost lost is a rounding error compared to the $280K average. We’re sitting on a powerful verification tool and most of us aren’t using it for fraud prevention. That needs to change.