OWNER WORKFLOW GUIDE
How to Avoid Duplicate Transactions When Using Plaid and QuickBooks
How to stop QuickBooks' own native bank feed from duplicating a transaction TenantPoint already reconciled and pushed through Plaid, with the exact match-vs-add habit that prevents it.
Duplicate transactions in QuickBooks almost always trace back to the same root cause: two live bank connections watching the same account, each with no idea the other exists. The fix isn't a smarter matching algorithm on either side — it's a deliberate habit of checking before you click Add, and deciding whether that account needs two feeds running on it in the first place.
1. Understand why the duplicate happens: two feeds, one account
This is a different problem from TenantPoint duplicating its own work. TenantPoint's sync to QuickBooks already guards against that — every push generates its own tracking key before it touches QuickBooks, so a retried or interrupted sync never creates a second record on TenantPoint's side. The scenario here is separate: a customer's QuickBooks company has its own native bank feed connected to the same checking account that TenantPoint is also watching through Plaid. Neither connection is aware the other exists, and neither one's dedup logic can see across to the other.
Here's how it plays out concretely. TenantPoint's Plaid feed shows an $840 debit to ABC Plumbing. Someone on the team reconciles it in TenantPoint, tags it to Work Order #482, and TenantPoint pushes it to QuickBooks as an $840 Purchase on Monday. QuickBooks' own bank feed — connected separately, refreshing on its own schedule — pulls in that same $840 line a few days later, on Friday. If the bookkeeper sees it sitting in the For Review queue and clicks Add instead of recognizing it should be Match, QuickBooks now has two separate $840 Purchases for one real payment to one real vendor.
- Two entries for the same vendor and amount, a few days apart, in the register
- A vendor's running total that's exactly double what the invoice or work order supports
- A Purchase with no property or work order tagging sitting next to one that has it
- The bank account's reconciled balance off by exactly the duplicated amount
2. Match vs. Add: check before you accept QuickBooks' bank feed suggestion
QuickBooks' own Banking screen offers two actions on anything sitting in the For Review queue: Add creates a brand-new transaction, and Match links the feed line to a transaction that already exists in the books. The $840 Purchase TenantPoint pushed on Monday already exists in QuickBooks by the time Friday's feed line shows up — the only correct action is Match, not Add.
Don't assume QuickBooks will always surface that as a suggested match on its own. Whether it offers Match depends on how closely the feed line lines up with the existing Purchase, and a few days' gap between Monday's push and Friday's feed refresh is exactly the kind of thing that can make an automatic suggestion less reliable. Treat the search as mandatory, not something to fall back on only when QuickBooks fails to suggest a match.
- Before clicking Add on the shared account, search Purchases (or Expenses) by vendor name and amount — not just today's date
- Widen the date search a few days in both directions, since Plaid and QuickBooks' own feed don't refresh on the same schedule
- If a matching entry exists, click Match even if QuickBooks didn't suggest it automatically
- If you're not sure, leave it in Review and check with whoever manages the TenantPoint sync before adding it
3. Decide whether that account needs QuickBooks' own bank feed at all
Once TenantPoint's Plaid connection is already watching an account — reconciling its transactions, tagging work orders, pushing invoices, payments, and purchases — QuickBooks' own native feed for that same account is a second, independent read of the same activity. Running both isn't a mistake in either system individually; it's the overlap itself that creates the collision risk described above.
The straightforward fix is to remove the overlap: disconnect or exclude just that specific checking account from QuickBooks' own online banking feed, and let TenantPoint's Plaid connection be the only live feed touching it. This doesn't require turning off QuickBooks' bank feed feature entirely — other accounts TenantPoint doesn't watch (payroll, an escrow account, anything outside the property operating account) can keep their own QuickBooks feed with no added risk.
- Disconnect or pause only the account TenantPoint already watches — leave unrelated accounts connected as usual
- If someone wants a raw statement for their own review, pull it from the bank's own portal instead of running a second live feed
- If the account has to stay connected in QuickBooks for another reason, treat step 2's search as a fixed part of the workflow, not optional
4. Train whoever touches QuickBooks directly on this specific risk
Neither system's own safeguards catch this, because they're not designed to see each other. TenantPoint's idempotency guarantee only stops TenantPoint from duplicating its own push on a retry — it has no visibility into a transaction a bookkeeper adds by hand through QuickBooks' separate native feed. QuickBooks, for its part, has no way to know that a transaction it's about to add already arrived through a completely different connection.
That means this has to be a documented habit, not a system setting. Anyone with QuickBooks login access — a bookkeeper, an outside accountant, a controller who logs in once a month — needs to know this specific collision exists, especially if they don't otherwise interact with TenantPoint and have no reason to know a transaction was already pushed.
- Write down which checking account(s) TenantPoint's Plaid connection watches, and share that list with anyone who has QuickBooks access
- Make 'search vendor and amount before clicking Add' the default habit on those accounts, not a one-time warning
- Walk a new bookkeeper or accountant through this on day one — it's a five-minute conversation that prevents a recurring cleanup problem
5. If a duplicate already got through
Confirm which of the two entries is the one TenantPoint pushed — check TenantPoint's Sync Activity log for the matching Purchase before deleting anything in QuickBooks. Delete the extra entry that was added manually through QuickBooks' own feed, not the one TenantPoint's sync is tracking.
Don't edit or delete the TenantPoint-linked Purchase directly in QuickBooks to try to fix this. TenantPoint detects a direct QuickBooks-side edit to a record it synced and flags it as a conflict rather than silently accepting it, and resolving that conflict means picking one of two options — accept QuickBooks' value or ignore it — which is more cleanup than simply removing the one extra manually-added entry in the first place.
- Check TenantPoint's Sync Activity log for the matching Purchase before touching anything in QuickBooks
- Delete the entry that came from QuickBooks' own bank feed's Add action, not the TenantPoint-linked one
- If you can't tell which is which, leave both and flag it rather than guessing — an incorrect deletion is harder to undo than a duplicate is to live with for a day
Frequently asked questions
Will TenantPoint automatically catch this kind of duplicate?
No. TenantPoint's idempotency guarantee only prevents TenantPoint's own push from creating a second QuickBooks record on a retry — it has no visibility into a transaction added directly through QuickBooks' separate, native bank feed. This specific collision has to be caught by a person, using the check-before-Add habit above.
Does QuickBooks' own Match suggestion catch this for me automatically?
Not reliably enough to skip the manual check. QuickBooks does try to suggest Match instead of Add when it recognizes a similar existing transaction, but whether a TenantPoint-pushed Purchase from a few days earlier actually surfaces as a suggested match can depend on how closely the dates and details line up. Search for the vendor and amount yourself rather than trusting the suggestion by default.
Does this only affect work-order expenses, or can rent and CAM be duplicated too?
The mechanism isn't specific to expenses — it applies to any account with two live feeds pointed at it. It shows up most clearly on work-order expenses because those push as a Purchase tied to one vendor and one amount, but a rent or CAM deposit on the same dual-connected checking account could in principle get added twice the same way if nobody checks first.
Should we just disconnect QuickBooks' native bank feed entirely?
Not necessarily for every account — only for the one(s) TenantPoint is already watching through Plaid. An account TenantPoint doesn't touch, like payroll or an escrow account, can keep its own QuickBooks feed without this risk.
USE THIS WITH ONE REAL PROPERTY
Stop rebuilding the operating record every month.
Start a 15-day trial, add one property, and bring the lease, rent, CAM, and tenant communication into the same workspace.