You're reconciling the credit card statement, and a payment to a supplier catches your eye because you're almost certain you already paid them that exact a
01/09/2026
Rule of the week: Cross-Method Duplicate
You're reconciling the credit card statement, and a payment to a supplier catches your eye because you're almost certain you already paid them that exact amount by EFT the week before. You check the bank feed. There it is — same vendor, same $2,140, different payment method entirely. Someone paid by card at the counter, and someone else (or the same someone, distracted) also ran it through the bank transfer batch. Both cleared. Neither system flagged it, because nothing in Xero or QBO cross-checks the bank feed against the credit card feed for you. They're different accounts. As far as the ledger is concerned, they're two unrelated transactions that happen to share a number.
This is the blind spot that ordinary duplicate-payment checks miss. Most duplicate detection — including the mental check most bookkeepers run — looks for the same amount paid twice by the same method: two EFTs, two card charges. A cross-method duplicate slips past that because it doesn't look like a duplicate at first glance. It looks like two different payments, because it is, technically, two different payment rails. The vendor still got paid twice.
A worked example
Say a business pays a landscaping contractor:
- 3 March — EFT for $1,860.00 to "Greenline Landscaping"
- 12 March — Credit card charge for $1,860.00 to "Greenline Landscaping"
Same amount, same vendor, nine days apart, two different payment methods. Maybe the office manager paid the invoice by bank transfer, then the same invoice was also entered as a bill and paid via the company card by someone catching up on approvals who didn't check what had already gone out. Nothing about either individual transaction looks wrong. It's only when you line the two accounts up side by side that the pattern shows.
How to find it manually
You need two exports: the bank transaction list and the credit card transaction list, for the same period, both with vendor names, amounts and dates.
- Export both to a spreadsheet with columns for date, vendor, amount, and method.
- Sort by vendor, then amount. This groups anything that might match regardless of which feed it came from.
- Scan for identical amounts against the same vendor that appear in both the bank list and the card list. Watch for near-matches too — $1,860.00 vs $1,860.50 can still be the same invoice with a surcharge added.
- Check the date gap. A same-vendor, same-amount pair three months apart is probably a recurring charge, not a duplicate. Within a week or two, it's worth opening both source documents.
- Pull the original invoice or bill for each match and confirm whether one payment covers it or both do.
This works, but it has a real cost. It takes a working knowledge of pivot tables or at least confident use of sort-and-filter, and it takes time proportional to transaction volume — a mid-size business with a few hundred vendor payments a month can easily lose an afternoon to this cross-check, and it's easy to miss a match if vendor names are spelled inconsistently between feeds ("Greenline Landscaping" vs "Greenline Landscaping Pty Ltd").
FAQ
What is a cross-method duplicate payment? It's the same amount paid to the same vendor twice, but through two different payment methods — for example once by EFT and once by credit card — within a short window, usually a week or two. It's a duplicate payment, but it's invisible to any check that only compares transactions within a single payment method.
How do you detect duplicate payments across payment methods? Manually, by exporting all payment methods to one spreadsheet, sorting by vendor and amount, and checking any same-vendor, same-amount pairs that fall within a couple of weeks of each other against their source invoices. Automated tools that read a payment method column can flag these continuously instead of at each manual check-in.
How the rule does it
DUP-006 only runs if your file has a payment method column mapped, and it only compares payment method against amount, vendor and date — it won't catch a duplicate where the vendor name was entered inconsistently across the two payments, and it can false-positive on legitimate split payments (part by card, part by bank transfer for the same larger invoice) that happen to land on a round number. Where it does apply, it flags any pair with the same amount, the same vendor, a different payment method, and a gap of 14 days or less, and raises it as a high-severity match under duplicate payments — the same check above, run continuously rather than at month-end.
Finanomaly is currently waitlisted.