AP enters a vendor bill and records the payment. The bank feed imports the debit a day later. Someone reviewing the feed sees a supplier name and an amount, and adds it as a new expense. The books now carry the same cost twice, and the original payment sits on the bank reconciliation as an uncleared item that nobody can explain three months later.
A lot of QuickBooks Online clean-up work traces back to two habits: adding a transaction that already exists, and coding a new one to whatever account the vendor used last time. Automation can repeat either mistake faster than a person would, so it needs to be set up to check for the existing record first.
The rule: look for the existing record first
Every cash movement in the bank feed should end up attached to exactly one record in the books. When a feed line arrives, the first question is whether that record already exists.
Intuit documents matching downloaded bank and credit card transactions to existing QuickBooks Online records. It also notes that matching directly to a bill or invoice marks it as paid. Intuit’s bank and credit card matching guide. That second point cuts both ways. It is the right outcome when the payment really was sent or received. It is the wrong outcome when someone matches a payment to the wrong bill and leaves the correct one open.
So before confirming any match, check that the payment actually happened and which record represents it.
| What comes through the feed | What to open before acting |
|---|---|
| Vendor debit after AP paid a bill | The existing payment and the bill it covered |
| Customer deposit covering several invoices | Remittance, existing receipt, and invoice applications |
| Card charge with a supplier invoice in the AP inbox | The card record, and whether the invoice is already marked paid |
| Two ledger entries for the same amount | Payee, dates, and references to decide which one cleared |
| Bank fee with no book entry | Statement evidence and the account used for fees |
| Refund or credit from a supplier | The original bill or vendor credit it relates to |
What a duplicate does to the books
Worked example (illustrative)
A $2,400 repair bill is entered and paid by AP.
| Entry | Debit | Credit |
|---|---|---|
| Bill entered | Repairs and maintenance $2,400 | Accounts payable $2,400 |
| Bill paid | Accounts payable $2,400 | Bank $2,400 |
Net effect: expense $2,400, bank down $2,400, AP back to zero. Correct.
Now the bank line arrives and is added as a new expense instead of being matched:
| Entry | Debit | Credit |
|---|---|---|
| Feed line added as expense | Repairs and maintenance $2,400 | Bank $2,400 |
Repairs expense is now $4,800, overstated by $2,400. The book bank balance has dropped by $4,800 against $2,400 at the bank. At reconciliation, the added expense clears against the statement line, and AP’s original $2,400 payment stays uncleared. It looks like an outstanding check that never cashed.
The mirror image is worse. If AP entered the bill but never recorded the payment, and the feed line is added as an expense rather than matched to the bill, the bill stays open in the AP aging. The next payment run picks it up and pays the supplier again. That is a real duplicate payment, and you only get the money back by asking for it. The duplicate payments and vendor master controls guide covers recovery and prevention.
The card-and-invoice version
A supplier charges the company card, then emails an invoice to AP. If AP enters the invoice as a bill and the card feed line is added separately, you have two expenses and an open bill. Before creating a bill from an emailed invoice, check the card feed for the same supplier and amount within a few days. Test this in both orders: invoice first, then card charge; and card charge first, then invoice.
Give the reviewer the evidence for a match
Whether a person or a tool proposes a match, the reviewer should see the candidate record and why it fits.
- Amount matches, date differs. Compare the payment date in the books with the clearing date at the bank. A few days is normal for checks and ACH; weeks suggests a different transaction.
- One deposit, several invoices. Trace the deposit to the receipt and each invoice it was applied to. The deposit total should equal the sum of applications.
- Two records fit. Let the reviewer choose before anything changes either balance. A tool that picks the first candidate is guessing.
- No record fits. Only then add a new transaction, and code it with the steps below.
For deposits covering several customer invoices, follow the remittance, not the amount. A $9,000 deposit might be three $3,000 invoices or one $9,000 invoice from a different customer. The cash application automation guide has methods for splits and short pays.
Coding new spend correctly
When a feed line or an emailed invoice really is new, it needs an account. The usual error is repeating last month’s coding for a vendor whose charge has changed.
Watch for these patterns:
| Situation | Typical miscoding | What to check |
|---|---|---|
| Annual subscription paid upfront | Full amount to expense in one month | Whether it should go to prepaid and be expensed over the term |
| Equipment from a vendor normally coded to supplies | Expense instead of fixed assets | Your capitalization threshold and policy |
| Vendor sells both goods and services | Every bill to one account | The line items on this invoice |
| Owner or employee reimbursement | Coded as vendor expense with no receipt | Receipt, policy, and who approved |
| Sales tax on a purchase | Lumped into the expense or treated inconsistently | Confirm treatment with your tax advisor |
Worked example: a prepayment (illustrative)
In January, the company pays $12,000 for a 12-month software subscription. Coded straight to software expense, January shows $12,000 of cost and February through December show none. Coded to a prepaid asset, the entries are:
- January payment: debit Prepaid expenses $12,000, credit Bank $12,000.
- Each month, January through December: debit Software expense $1,000, credit Prepaid expenses $1,000.
After 12 months, $12,000 ÷ 12 = $1,000 a month has been expensed, and the prepaid balance is zero. If you automate coding, make sure invoices that mention a service period longer than a month go to review rather than taking the vendor’s default account. The journal entries, accruals, and prepaids guide covers automating the monthly release.
Make suggestions explain themselves
If a tool proposes coding, it should show why: “same vendor, same description as the last three bills” is a reason a reviewer can check. “Model suggested 6100” is not. Track corrections by vendor and account. A vendor that gets recoded every month needs a rule change, not another round of corrections.
Integrations: retries, missed updates, and timeouts
Anything that writes to QuickBooks Online from outside can create duplicates at the integration layer, separate from human review.
Missed or repeated notifications. Webhooks tell an integration that something changed. Intuit recommends using the ChangeDataCapture endpoint to recover potentially missed webhook events, starting from the last successfully processed event for the relevant records. Intuit’s webhook best practices. Ask any vendor how they catch up after an outage, and test it: replay a missed update and confirm the record recovers, a repeated notice leaves one record, and an older update cannot overwrite a newer status.
Timeouts on write. If a create-bill request times out, the bill may or may not exist. The integration must look for it (by vendor and invoice number, at minimum) before trying again. Ask to see this in a sandbox, not on a slide.
Who can write what. Decide which records the integration may create (draft bills, payments, receipts) and which stay manual. Keep payment release with a named person.
Test it in a sandbox company
Use a test company and three cases:
- A paid bill. Record the bill and the payment, then bring in the bank line. Confirm it matches to the existing payment and nothing new is created.
- An unapplied deposit. Bring in a deposit with a remittance listing two invoices. Confirm the receipt and both applications, and that the invoices leave the AR aging.
- A card-paid invoice. Deliver the card charge and the emailed invoice in both orders. Confirm one expense and no open bill.
After each case, check three places: the bank register, open bills or invoices, and the reconciliation result. Then time how long the team spends finding matches and fixing duplicates, before and after. For items that clear after month-end, use the bank reconciliation automation guide.
Monthly check for duplicates already in the books
- On the last bank reconciliation, review any uncleared payment older than 30 days. Each one is either a real outstanding item or the twin of an expense added from the feed.
- Sort expenses by vendor and amount for the month and look for pairs within a few days of each other.
- Compare open bills in the AP aging with card and bank charges to the same vendors.
- Review vendors whose coding was corrected more than once and fix the default or rule.
- Look for invoices covering a service period longer than one month that went straight to expense.
- Confirm the integration’s last successful sync and that no failed writes are waiting for review.