The common AI bookkeeping software problems are duplicate feed entries, wrong supplier or category rules, incorrect VAT or sales-tax codes, missed split transactions and false matches. Fix them by tracing the bank line to its source document and ledger entry, correcting the rule or match, then reconciling the account and checking the affected report before automation resumes.
Do not repair a month by changing a suggested category in isolation. A bank feed, an invoice or bill, a receipt capture tool and a payment processor can describe the same event. If the bookkeeper cannot tell whether the line is new money, a transfer, a settlement or a duplicate, pause posting and reconstruct the transaction. A polished AI suggestion is still only a suggestion.
Duplicate feeds: stop the second entry at the source
Duplicate transactions arise when a bank connection imports a line already entered manually, a second connection overlaps the same account, a CSV upload repeats a date range, or a payment integration has already created the record. The fix depends on where the duplicate exists. If the bank line is waiting for review and an existing bill payment or receipt is in the ledger, match it rather than create a new expense or income item. Intuit's duplicate-transaction guidance names adding a downloaded line instead of matching it as one cause, alongside reconnecting an account and importing a file that overlaps the bank feed.
First compare bank account, posting date, gross amount, reference and counterparty. Search the ledger for the same value within a sensible date window, then inspect any receipt, bill or payment processor record. If two feed connections point to the same account, stop one connection after documenting which feed is authoritative. If a CSV import overlaps a live feed, identify the exact overlap and exclude only confirmed duplicate feed rows. Do not delete a legitimate refund merely because it shares an amount with a purchase.
An illustrative example: a $480 supplier bill is entered on Monday and paid on Wednesday. The bank imports the Wednesday debit. The AI proposes “office expenses”, which would add a second $480 expense. The bookkeeper instead matches the debit to the existing bill payment. The check is that the supplier balance is cleared once, the bank debit appears once, and the expense account has one $480 cost. If the ledger already contains both expense entries, reverse the incorrect one under the practice's correction policy and rerun the reconciliation.
The same Intuit article recommends turning off auto-add on bank rules so downloaded lines land in the For review tab first. It also gives two cautions worth copying into the practice manual: exclude a duplicate that is still awaiting review rather than deleting it, because QuickBooks downloads a deleted bank line again; and repair a broken bank sign-in rather than disconnecting and reconnecting the account, which downloads past transactions again. Turning off auto-add is a useful containment step while a feed problem is investigated. The rule is not “exclude every equal amount”; the test is whether the accounting event already exists. For a broader monthly matching method, see reconciliation differences and repairs.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowWrong supplier rules: narrow the condition and retest history
A broad rule such as “description contains STAR” might classify a software subscription, a travel purchase and a transfer to a similarly named account under one supplier. An AI suggestion can reinforce the error if it learns from earlier miscoded entries. Open the rule, inspect its conditions and priority, and test it against recent unreviewed transactions before changing live posting. Intuit's bank-rule instructions describe a Test Rule button and up to five conditions per rule, each on Description, Bank text or Amount and set to Contains, Doesn't contain or Is exactly; the page notes that options vary with the company settings turned on, so check your own account screen. Bank text is exactly what the bank sends, while Description is a simplified version, and Intuit lists a rule written against the wrong one as a reason rules fail to apply.
Fix the rule with the narrowest reliable evidence: exact merchant text or reference pattern, direction of money, account and perhaps a range of amounts. A changing amount should not be used as an exact condition if the supplier bills by usage. A one-off merchant should not have a permanent rule merely to save a click. Turn off automatic posting until the revised rule has been tested on both positive and negative examples. Then search historical entries affected by the old rule, because changing the rule may not repair the past.
An illustrative before-and-after: the old condition “memo contains CLOUD” puts five monthly charges into software subscriptions, but two are storage hardware paid through a marketplace with “cloud” in the payment description. The corrected rule uses the supplier's full payee identifier plus the recurring service reference. The bookkeeper tests seven historical lines: five should match, two should not. The check is that the two hardware purchases are recoded with their source invoices, while the next imported service charge waits in review and receives the expected suggestion.
Keep a rule register with the rule name, owner, business purpose, exact matching conditions, sample lines used to test, date changed and exception count. This can be a simple sheet. It helps when a supplier changes its payment descriptor or an employee asks why a transaction was coded a certain way. AI can propose candidate rules from repeated transactions, but a person should decide whether the pattern is stable enough. The bank-rule tutorial covers initial rule setup; this repair process starts when a rule has already caused damage.
Tax coding: compare the document, not the merchant name
VAT and sales-tax treatment may depend on the transaction, document, seller, customer and applicable rules. A repeated merchant name is not a reliable tax decision. One supplier can sell taxable and exempt items, issue a credit, or bill for services with different treatment. When a suggested code looks wrong, hold the transaction, open the invoice or receipt, identify the actual items and tax shown, and ask the practice's qualified tax adviser where the treatment is uncertain. Do not make a definitive tax decision from a model's explanation.
A small practice should make the review step concrete. Compare the gross amount with the document's net, tax and total; check the document date and supplier identity; then inspect the ledger code and relevant tax report. If the document has no usable tax detail, request a proper document or record the item as unresolved under the practice's policy. A model can extract candidate amounts, but the reviewer must confirm that it did not read a delivery charge, tip or unrelated subtotal as tax.
Illustrative error: a $110 bill has a $100 service charge and $10 tax shown separately. A capture tool proposes a zero-tax expense because the previous bill from that supplier was exempt. The bookkeeper corrects the current document's line and code after checking the applicable treatment. The verification is not simply that the bank reconciles to $110; it will reconcile even with the wrong code. The check is that the tax report reflects the supported amount and the document attached to the entry shows the same split. Ask a tax professional to resolve the legal classification if it is disputed.
Another illustrative trap is a credit note. The model sees the supplier and proposes the same positive tax code as the original purchase, while the credit should reverse the relevant amount. The bookkeeper links the credit to the original invoice, confirms the sign and period, and checks both the supplier balance and tax report. Do not let a rule turn every negative bank line into revenue; refunds and credits can have different accounting paths.
Split transactions: make the parts add back to the bank line
A single bank debit may cover several categories: equipment, a service, delivery and tax, or personal and business portions. If AI assigns the whole amount to the most common category, the bank reconciliation can still pass while the management reports are wrong. Split the entry using the source document, then check that all parts add exactly to the bank total. Intuit's bank-rule page says a rule can split a transaction between categories by percentage or amount. That suits a fixed allocation such as a shared subscription; a mixed purchase whose parts change each time should be split from its invoice, not by a standing percentage.
For an illustrative $275 purchase, the invoice shows $180 of tools, $70 of supplies and $25 of delivery. If the whole $275 is posted as supplies, the bank matches but the tools account is understated by $180. The corrected split allocates $180, $70 and $25 to the proper accounts under the practice's chart. The reviewer checks the sum, source document and expense report. If the amounts also contain tax, the split needs to follow the document's tax treatment, not a guessed percentage.
A more awkward example is a payment processor settlement. The bank receives $940, while customer payments total $1,000 and fees are $60. Treating $940 as sales understates revenue; treating $1,000 as a new deposit duplicates cash. Reconcile the processor statement: gross receipts $1,000 less fees $60 equals bank settlement $940. Check the processor clearing account reaches the expected balance after timing differences. The detailed method belongs to payout reconciliation, but the repair principle is the same: the bank amount is the end of a chain, not the whole transaction.
False matches: verify identity before accepting a green tick
A match suggestion may be plausible because amount and date are close, while the real payment belongs to another bill or customer. Before approving, compare the account, payee, invoice number, amount, date and payment method. Be especially careful with repeated amounts such as monthly retainers. A false match can close the wrong receivable and leave the real one open, producing an apparently tidy bank screen and a misleading ageing report.
Illustrative case: two clients each owe $750. The bank description carries one client's reference, but AI proposes the other open invoice because it is older. The bookkeeper rejects the suggestion, matches the receipt to the reference on the bank line and checks both customer ledgers. The rejected invoice remains outstanding. If the bank reference is ambiguous, ask for remittance advice before marking either invoice paid. An unexplained “match confidence” score cannot substitute for that evidence.
Another false match is a transfer between two accounts recorded as a supplier payment. The bank debit and corresponding credit should appear on opposite sides of the transfer. If AI creates an expense for the debit and income for the credit, profit is distorted even though both bank balances reconcile. Check the two account statements and the transfer reference, then pair the sides under the software's transfer workflow. The verification is that neither side appears in income or expense and both bank reconciliations remain correct.
One month's recovery for a small practice
Here is an illustrative worked example with numbers. A four-person bookkeeping practice reviews one wholesale distributor's month. There are 420 imported bank lines, 38 receipt images, 24 supplier bills and two payment-processor settlements. The owner sees an unexpected $2,200 rise in software expenses and a tax-report difference. Rather than reclassify all 420 lines, the team freezes auto-posting for the affected account, exports the transaction list and works from the bank statement plus source documents.
The team finds six duplicated $300 supplier payments from an overlapping CSV import, creating $1,800 of false expense. It finds four $100 hardware purchases misclassified as software by a broad merchant rule, explaining the remaining $400 in the software variance. It also finds two $110 invoices with the wrong tax code and one $940 processor settlement recorded as revenue without gross receipts or fees. These are illustrative findings designed to show the diagnosis, not a typical error rate.
Repair order matters. First the bookkeeper confirms each duplicate against the imported feed and existing bill payment, then excludes or reverses only the incorrect entries. Next the rule owner narrows the supplier rule and retests it on the ten relevant lines. Then the reviewer corrects the four hardware entries using invoices. The two tax-coded items go to a qualified reviewer, and the processor settlement is reconstructed from the processor report. Only after the corrected ledger is reviewed does auto-posting resume for the tested rule.
The team allocates an illustrative 5 hours: 45 minutes to freeze and export, 90 minutes to trace duplicates, 60 minutes to repair the rule and history, 75 minutes for tax and settlement review, and 30 minutes for final checks. That is internal planning time, not a promise that software saves five hours. The practice records how many entries were changed and who approved each correction. If the same error returns next month, the fix was incomplete even if this month's books now balance.
The final checks are separate: bank reconciliation equals the statement; supplier balances and customer ageing are sensible; software and hardware accounts reflect the supported documents; the tax report agrees with corrected coding; the processor clearing account is explained; and a sample of the next feed import follows the revised rule. A bank reconciliation alone is necessary but insufficient, because a transaction can be matched to the bank and still be posted to the wrong account or tax code.
Build a repair ticket that can be closed objectively
Use one ticket per root cause, with affected client, account, period, source evidence, incorrect behaviour, corrected rule or entry, historical search range, approver and verification result. A filled-in illustrative ticket might say: “Rule R-12 applied to hardware and subscription lines. Disabled automatic posting. Changed condition from CLOUD to full supplier service reference. Tested five true matches and two false matches. Corrected two historical hardware entries. Reviewer checked next import and expense report.” The ticket is closed only after the next import behaves correctly.
Record a stop condition for each automation. Duplicate import: stop when overlapping date ranges appear. Supplier rule: stop when an unexpected merchant or amount pattern appears. Tax extraction: stop when document total and extracted amounts differ. Split settlement: stop when gross less fees does not equal the bank receipt. Matching: stop when the reference or counterparty does not agree. These are observable checks a junior bookkeeper can follow; “trust AI if confidence is high” is not a control.
If a vendor advertises automatic reconciliation or intelligent categorisation, test it on the practice's own awkward transactions before enabling unattended posting. Use a small set containing a duplicate, credit, transfer, two equal-value invoices, a mixed purchase and a processor settlement. Score the tool on correct decisions and whether it exposes evidence for a reviewer, not merely the number of lines it clears. The bookkeeping agent review-boundaries tutorial addresses autonomy; this page gives the repair route after a specific error appears.
Document extraction: check the fields against the original
Optical character recognition and AI extraction can turn a photographed receipt into a plausible but wrong document. A faded “8” may become “3”; a delivery date may be read as the invoice date; the total from a previous page may be attached to the current supplier. The fix is to open the image beside the proposed entry and check supplier, document number, date, currency, line values, tax and total. Where the image is unreadable, ask for a better copy instead of correcting the value from a bank line alone. The bank line proves payment, not the composition of the bill.
An illustrative receipt shows a $38 service charge and a $12 delivery fee, total $50. The extractor proposes $38 as the total because the bottom of the photo is cropped. A bank payment of $50 reveals a mismatch, but it does not prove that the missing $12 was delivery; the bookkeeper needs the complete receipt. The check after replacement is that the attached image, extracted fields, posted expense and bank payment all agree. Record why the first capture was rejected, because repeated cropping may indicate a staff process problem rather than a model problem.
Watch for document-number collisions too. Two suppliers can use “INV-101”, and one supplier can resend a corrected invoice with the same number. A duplicate-detection tool may reject a legitimate document or accept the same bill twice under slightly different names. Compare supplier identity and amount, then inspect whether the corrected invoice explicitly supersedes the first. Mark the rejected version so it cannot be approved later by another team member. A count of “duplicates prevented” is not evidence that every rejection was correct.
Closed periods: repair through the approved correction route
When a bad suggestion is discovered after a reporting period has been closed, avoid quietly editing the historical entry. Check who received the previous report, whether a return or client decision relied on it, and what correction method the practice uses. A qualified accountant or tax adviser should approve material prior-period or tax changes. The automation rule can be fixed immediately for future lines, while the historical accounting correction follows a separate reviewed route. This preserves the trail from original error to corrected position.
For an illustrative example, a $600 expense is discovered in the wrong account after monthly management figures were sent. Moving it between expense accounts may leave total profit unchanged, but it changes the client's category comparison. The practice logs the proposed reclassification, gets approval, posts the correction in the permitted period and issues a revised report if the client needs one. The check is that both the corrected account balance and the report version are identifiable. A silent edit would leave the client comparing two different numbers without an explanation.
When the classification affects filed returns, client advice or prior periods, involve a qualified accountant or tax adviser and follow the practice's correction procedure. Keep the original document, the wrong entry, the corrected entry and the reason for change. A useful AI system makes those links easier to inspect. It does not remove the bookkeeper's duty to understand what entered the ledger and why.
Further reads
- Bookkeeping AI Reviews: How to Test a Tool on Your Own Client Files — Test a candidate tool against your own client records.
- AI Powered Bookkeeping Platform: How a Practice Chooses One — Choose a platform around practice controls.
- AI in Bookkeeping and Tax: The Year-End Handoff to Your Preparer — Prepare a checked handoff from corrected books.
- Double (Formerly Keeper): AI Bookkeeping Features and Cost per Client — What Double charges per client on Core, Plus and Scale, which AI features each tier adds, and a 40-client monthly bill worked through line by line.
- AI Bookkeeping in Canada: GST/HST Coding and Remittance Checks — A bookkeeper's review routine for GST/HST coding and payroll remittances: formulas for the maths, AI for the judgement calls, CRA pages for the dates.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Intuit QuickBooks help: Fix duplicate transactions in QuickBooks Online bank feeds; Intuit QuickBooks help: Set up bank rules to categorise online banking transactions in QuickBooks Online.