How Accountants Use AI to Spot Errors in Client Books

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How Accountants Use AI to Spot Errors in Client Books.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How Accountants Use AI to Spot Errors in Client Books.

Run the same automated checks on every client file before a person reviews it. Review tools such as Dext's Data Health checks or QuickBooks' Transaction Review flag duplicates, miscoding, wrong tax codes and unreconciled items; a general AI assistant can then read an exported ledger and explain the odd entries. A qualified reviewer still decides what's wrong and posts the corrections.

Split the work by what each tool is good at. Rules and formulas are reliable at counting, matching and comparing thousands of rows. Language models are good at reading descriptions, spotting that "laptop for shop office" doesn't belong in office supplies, and explaining a pattern in plain words, but they are weak at arithmetic across a big table (the reasons are in why AI is bad at maths). Let formulas find the candidates and let the model help you read them.

Follow me on Instagram@sagnikteaches

Nine errors worth hunting, and the test that finds each

ErrorHow it shows upTest that finds itBest run by
Duplicate bills or paymentsSame supplier, same amount, a few days apartMatch contact, amount and date windowReview tool or formula
Miscoded expenseDescription doesn't fit the accountRead description against account nameAI assistant
Wrong tax codeOne supplier coded with different tax codesCount tax codes per supplierReview tool or formula
Supplier spread across accountsOne supplier in three expense accountsCount accounts per supplierFormula, then AI to explain
Capital items expensedEquipment in repairs or sundriesAmount over your threshold plus descriptionFormula plus AI
Unreconciled or suspense itemsOld unmatched bank lines, suspense balanceAge of unreconciled itemsLedger or review tool
Cut-off errorsInvoice dated in one period for work in anotherCompare invoice date with description or periodAI assistant, sampled
Round-sum manual journalsJournals of exactly $5,000Amount divisible by 100 above a floorFormula
Personal spending through the businessSupermarket, streaming, holiday merchantsMerchant keywords on business cardsFormula plus AI

Three ways to run the checks: add-on, ledger or DIY

A dedicated review add-on. Dext's Data Health & Insights add-on, available on its Practice Essentials and Practice Advanced plans (existing Dext Precision users also get it), connects to clients' Xero or QuickBooks Online files, syncs daily and flags issues such as unreconciled bank transactions, duplicate or missing contacts, overdue invoices and bills, and incorrect tax coding. Its duplicate check compares contact, date and value. Practice plans are priced per client per month with a ten-client minimum, and the figures appear only once you choose your country or start a trial, so get a quote for your client count.

Connect on LinkedInSagnik Bhattacharya

Your ledger's own tools. If your clients are on QuickBooks Online, Transaction Review sits inside Books Close in Intuit Accountant Suite and is built to find uncategorised transactions, anomalies and coding errors, with anomaly checks you can customise. Xero and other ledgers have their own review features that change often; the trade-offs are compared in Xero vs QuickBooks AI.

Subscribe on YouTube@codingliquids

The do-it-yourself route. Export the ledger, add a handful of formula columns, and ask a business-plan AI assistant to read the flagged rows. No new subscription, full control of the rules, more setup time. It's also the best way to learn which checks matter for your client mix before paying per client for a tool.

Most practices end up with a review add-on for the monthly clients and the DIY route for year-end files and the occasional client on an unsupported ledger.

The DIY route, step by step

  1. Export the general ledger detail for the period as CSV: date, contact, account, amount, tax code, reference, description.
  2. Pseudonymise individuals. Replace employee and owner names in payee fields with codes (EMP-01, OWNER). Business supplier names can usually stay if you're on a business plan with training off, because the miscoding test needs them.
  3. Add flag columns with formulas (examples below, assuming A is date, B contact, C account, D amount, F tax code).
  4. Filter to flagged rows plus a random 5% sample of unflagged ones, so the AI also reads ordinary entries.
  5. Ask the AI to explain, not to fix.

Step 2 is where the slips happen, because names hide in more than one column. On an illustrative physiotherapy clinic's export, the bookkeeper replaced every name in the Contact column and uploaded the file. The Description column still carried 14 names: mileage claims ("Mileage Feb, [employee's full name] to home visits") and, worse, patient refunds ("Refund [patient's full name], cancelled course"). Refund lines on a clinic ledger point to someone's treatment, which is exactly the data you don't want in an upload. The fix is a routine, not more care: run the replacement across every text column, then search the finished file for the client's staff list and for words such as "refund" and "reimburse", and overwrite those descriptions with a neutral label such as "Customer refund".

The step 3 formulas:

Duplicate (same contact and amount within 7 days):
=IF(COUNTIFS(B:B,B2,D:D,D2,A:A,">="&(A2-7),A:A,"<="&(A2+7))>1,"DUP","")

Mixed tax codes for one supplier:
=IF(COUNTIFS(B:B,B2,F:F,"<>"&F2)>0,"MIXED_TAX","")

Supplier used in more than one account (Excel 365):
=IF(COUNTA(UNIQUE(FILTER(C:C,B:B=B2)))>1,"MULTI_ACCOUNT","")

Round sum on manual journals of $500 or more:
=IF(AND(D2>=500,MOD(D2,100)=0),"ROUND","")

Then the prompt:

You are assisting a qualified accountant reviewing a client's ledger.
The attached CSV has one row per transaction, with flag columns added by
formulas (DUP, MIXED_TAX, MULTI_ACCOUNT, ROUND).
For each flagged group, grouped by supplier:
- say which flags apply
- give the most likely innocent explanation and the most likely error
- say what document or question would settle it
Then read every description against its account name and list rows
where the description suggests a different account.
Do not recalculate totals. Do not propose journals.

Run against a toy shop client's December ledger, the reply might read like this (illustrative, trimmed):

Supplier S-014 (DUP)
- Two payments of $1,240.00 on 3 and 5 December.
- Innocent: two separate stock orders of the same value.
- Error: the same invoice entered from both the emailed and paper copy.
- Settle it: December supplier statement.

Supplier S-022 (MULTI_ACCOUNT)
- 11 entries to Repairs and Maintenance, 1 to Equipment ($2,860,
  "display cabinet"). The Equipment entry looks correct.

Description review
- Row 318 "Laptop for shop office", $1,150, Office Supplies:
  should be capitalised under your policy.
- Row 402 "Monthly subscription - unit 4", Rent: likely miscoded.

Three things to correct in that reading. S-014 is the useful find: the statement showed one invoice, entered twice. Row 318 is right to raise, but the model doesn't know the client's capitalisation threshold, so "should be capitalised under your policy" is a guess dressed as a conclusion; you apply the threshold. Row 402 is wrong: "unit 4" is a storage unit billed as a subscription, and Rent was correct. The model can't know that, which is why it suggests and you decide.

Checks that need each client's own thresholds and word lists

Two rows of the nine-error table depend on facts about the client, and a generic rule gives poor results on both.

Personal spending. A keyword flag on the description column (supermarket, streaming, school, pet, holiday) is a start, but the list has to fit the business. For an illustrative café client, supermarket spending is mostly legitimate: milk and bread top-ups when a delivery falls short. Flagging every supermarket line produced 23 flags a quarter and one real find. Narrowing the rule to supermarket spends over $150, or on days the café is closed, cut that to three flags, and one of the three was the owner's weekly family shop on the business card. Keep the word list and its exceptions on the client's file, so the next reviewer doesn't start from scratch.

Capital items. A per-row amount test misses purchases split across lines. An illustrative design studio bought six desks at $320 each on one supplier bill, posted as six lines of $320 to Office Supplies. With a $1,000 capitalisation threshold, not one row crossed it, yet the bill totalled $1,920. Test the bill instead of the row, by summing on the reference column (column E in this layout): =IF(SUMIFS(D:D,E:E,E2)>=1000,"CAPEX?",""). The threshold itself comes from the client's policy, so put it in the prompt as a fact rather than letting the model assume one.

Sampling for cut-off errors at the year end

Cut-off is the one check in the table the model does largely on its own, because the evidence is in the wording. Take the invoices dated in the fortnight either side of the year end and ask:

The client's year ends 31 March. Below are all purchase invoices dated
18 March to 14 April, with supplier code, amount and description.
List only invoices where words in the description point to a different
period from the invoice date. For each, quote those words and rate
your confidence as high, medium or low. Do not adjust anything.

For a small building contractor client, the reply might read (illustrative):

- 2 Apr, S-031, $4,800, "Kitchen refit stage 2, works completed
  w/e 28 March". Belongs to March. High.
- 4 Apr, S-009, $620, "March scaffold hire". Belongs to March. High.
- 29 Mar, S-017, $1,150, "Annual software licence Apr-Mar". Covers
  the new year: possible prepayment. Medium.
- 10 Apr, S-040, $95, "Delivery". No period indicated. Low.

The first two are accruals worth $5,420 between them. The third is the right question, but you need the licence terms to answer it. The fourth broke the prompt's own rule, since nothing in "Delivery" points anywhere; delete it and move on. The larger gap is the invoices this method can't read at all: bills described only as "Works as quoted" or "Invoice 1043" say nothing about timing. For those, open a sample of the actual documents, because a clean AI list here only means the descriptions were uninformative.

The supplier-to-account check most reviews skip

Duplicates get all the attention, but the most revealing single test is counting how many accounts each supplier has been coded to. A supplier that should be a single line of cost of sales, spread across Purchases, Sundries and Repairs, tells you the bank rules or the bookkeeper's habits have drifted.

Take a members' club client. The drinks wholesaler appeared under Bar Purchases 36 times, Sundry Expenses 4 times and Repairs twice in a year. The four Sundry entries were bar stock bought during a staff changeover, when a new volunteer treasurer had been coding by hand; the two Repairs entries were for a replaced cellar cooler, which the wholesaler had supplied, and were correct. Fixing the four moved $1,900 back into bar purchases and changed the bar's gross margin figure that the committee watches every month.

What automated checks can't see

  • Things that were never entered. Every check above looks at transactions that exist. A missing month of the card-machine fee or rent is invisible to them. Build a simple "expected recurring costs" list per client and ask which months are empty.
  • Business events you haven't been told about. A new van, a loan from a director, a grant. The ledger can look clean and be incomplete.
  • Close judgement calls. Capital or revenue, which period an accrual belongs to: the tools can flag, only a professional can decide.
  • Fraud designed to look normal. Small, regular, plausibly coded payments to a new supplier pass most rules. For that angle, catching duplicate invoices and payment fraud with AI goes further.

The completeness test is the easiest to set up. For the members' club, the expected list was short: bar stock weekly, the drinks wholesaler's cellar service quarterly, insurance annually, the card terminal fee monthly, cleaning contractor monthly, and the fruit machine rental monthly. A supplier-by-month pivot of the year's ledger, read against that list (the AI can write the pivot steps for you, but let the spreadsheet do the counting), showed the card terminal fee missing for February to April. The provider had switched to taking it from a different account, which nobody had added to the bank feeds. No duplicate or coding check would ever have caught that.

Plant five errors to prove the checks catch them

Before trusting a new set of formulas on live clients, test it on a copy of a ledger you've already reviewed. Plant known errors, run the checks, and count what comes back. On a copy of the toy shop file, an illustrative test planted five: one bill entered twice, two lines from one supplier moved to a different tax code, a $1,400 till recoded to Sundries, a $3,000 manual journal, and a rent payment moved to Office Supplies.

Four came back flagged. The duplicate didn't, and the reason is common in real files: the planted copy used the supplier's second contact record, one created as "Ltd" and the other as "Limited" by two different bookkeepers. The COUNTIFS duplicate test matches the contact exactly, so it saw two suppliers. The fix is a second, looser duplicate test on amount and a seven-day window alone, ignoring the contact. It raises more innocent flags, but it catches contact variants, and it's the same reason review add-ons flag duplicate contacts as a separate issue. Rerun the planted test after any change to the formulas, and keep the planted copy for that purpose.

From 31 flags to 6 corrections

The first month of any check produces too many flags. Here's the illustrative toy shop December file before and after triage:

FlagRaisedReal errorsWhy the rest were innocent
DUP122Repeat stock orders of identical value in the busy season
MIXED_TAX51Suppliers selling both standard and exempt items
MULTI_ACCOUNT61Legitimate split between stock and equipment
ROUND40Agreed monthly transfers to savings
Description review42One storage-unit "subscription", one gift-card float

Six real errors: two double-entered bills, one supplier on the wrong tax code for three months, one laptop to capitalise, one personal purchase on the business card, and one bank line parked in suspense since October. Triage took 40 minutes. Next month, adding the regular stock suppliers to an exclusion list for the duplicate check and allowing mixed codes for the two suppliers that genuinely sell both kinds of item cut the flags roughly in half.

What it adds up to in a 45-client practice

Consider an illustrative three-person bookkeeping practice with 45 monthly clients. Before any checks, the month-end review averaged 50 minutes a client, about 37 hours a month, and most errors surfaced at year-end when they were expensive to unpick. With a review add-on on the monthly clients and the formula route for five clients on an unsupported ledger, review time settles at around 25 minutes a client after the thresholds are tuned: roughly 18 hours back each month.

The bigger change is timing. An error found in the month it happened is a two-minute fix and an easy client conversation. The same error found eleven months later is a recoding exercise, a revised tax figure and an awkward email. Track three numbers: flags raised per client, the share that turned out to be real errors, and year-end adjustments per client. If year-end adjustments fall, the checks are working.

Expect a poor ratio in the first month (in the toy shop file above it was roughly four innocent flags for every real one) and budget two or three hours of tuning per client type.

A review log that proves the check happened

If a client later disputes a figure, or your own quality review asks how a file was checked, you want a record rather than a memory. One row per client per period is enough:

ClientPeriodFlagsCorrectedDismissed, with reasonReviewer
Toy shopDecember31625: repeat stock orders, mixed-rate suppliers, agreed transfersSenior bookkeeper, 8 Jan
Members' clubYear to March18414: legitimate split coding, recurring subscriptionsPartner, 22 Apr

In Dext, dismissed items stop counting towards the client's health score, which makes dismissing without a reason tempting. Require a reason every time.

On client data: use AI tools only on business plans that don't train on your content, keep individuals' names out of exports, and say in your engagement letter that you use software, including AI tools, to review records. Whether it's safe for accountants to use ChatGPT with client data covers the settings to check, and for bank-feed matching specifically, automating bank reconciliation and checking the matches picks up where this leaves off.

Further reads

Sources: Dext Help Centre (Data Health and Insights, duplicate transactions check, practice plans); Intuit QuickBooks help (Books Close and Transaction Review in Intuit Accountant Suite).

Want error checks running on every client file?

On a 1:1 call we'll look at how your practice reviews client books today, choose between a review add-on and a do-it-yourself check, and set thresholds that cut false alarms.

Book a 1:1 call with me