OWNER WORKFLOW GUIDE
Why Your QuickBooks Bank Feed Doesn't Know Which Tenant Paid
QuickBooks Online's bank feed can suggest a category for a deposit, but it has no concept of a tenant, a lease, or a rent roll — here's exactly why that breaks down on a bundled lockbox deposit, worked through with real numbers.
QuickBooks Online's bank feed can suggest a category for a deposit before you've even opened it. What it can't do is know that the deposit is actually two tenants' money, split unevenly, for two different reasons.
1. What QuickBooks' bank feed actually sees
QuickBooks Online's bank feed pulls in whatever the bank connection behind it sends: a dollar amount, a counterparty or memo string exactly as the bank formatted it, and a date. That's the full payload for every transaction that lands in the "For Review" queue. There's no field anywhere in that feed for "which tenant," because the feed has no concept that your company file represents a building full of tenants — it only knows a chart of accounts and a history of past clicks.
The category QuickBooks proposes next to a new transaction comes from its Bank Rules feature, which pattern-matches a new transaction against ones that looked similar before — close in amount, same payee text, same account picked last time. That's a memory of what you did previously, not a check against what's actually owed today. This is the core limitation behind most QuickBooks bank feed reconciliation problems in property management: the feed is reasoning about your past behavior, never about a lease.
- Amount and a bank-supplied description string are the only real signals in the feed
- The suggested category comes from Bank Rules, built entirely from your own prior categorization choices
- No Customer, Class, or Location is attached to a transaction unless a person adds one on that specific line
- No visibility into a lease, a rent roll, or a CAM schedule — those aren't concepts the bank feed has access to
- No memory of which invoices are still open, even if you generate invoices in the same QuickBooks file
2. The $4,800 deposit that isn't what it looks like
Here's the math worked through on a realistic scenario. A lockbox deposit of $4,800 hits the operating account. QuickBooks' bank feed sees exactly one thing: "$4,800 deposit, Chase ****1122." At best, it suggests a category based on what a similar-sized deposit was coded to last time — maybe "Income," maybe a rent income account, maybe nothing if the amount doesn't closely match a prior pattern. What it has no way to see is that the $4,800 is actually two separate obligations bundled by the lockbox provider into one wire: $4,200 is Unit 3B's March rent, and the remaining $600 is a CAM true-up catch-up payment from Unit 5A, an entirely different tenant, for an entirely different lease-year reconciliation.
A property manager who clicks "Confirm" on QuickBooks' own suggested categorization gets one of two outcomes, both bad. Either the whole $4,800 gets booked to a single income account with no tenant reference at all, which means the books say revenue arrived but the rent roll has no idea Unit 3B is now paid and Unit 5A's true-up balance is now zero — or the property manager catches the problem and manually splits the deposit into two lines, every time, from memory, with nothing in QuickBooks itself to check that $4,200 and $600 are actually the correct amounts for those two tenants that month.
- $4,200 — March base rent for Unit 3B
- $600 — CAM true-up catch-up payment from Unit 5A, a different tenant on a different schedule
- QuickBooks' bank feed proposes one line, one category, no tenant reference at all
- A manual split has to be reconstructed from memory or a separate spreadsheet every time, with nothing to check it against
3. Why "categorize" isn't "reconcile" for a lockbox deposit
QuickBooks' bank feed is solving a bookkeeping problem: does this transaction land in a GL account that keeps the books balanced. That's a genuinely different question from the operational one a property manager actually needs answered: is Unit 3B now paid in full for March, and is Unit 5A's CAM true-up now cleared. A transaction can be perfectly categorized — correct account, correct date, books balance to the penny — while being completely wrong from a rent-roll standpoint, because QuickBooks' Customer field on a deposit line is just a label a person types in, not a lookup against an actual open charge.
This is exactly why a QuickBooks bank feed miscategorized deposit so often isn't caught until month-end, or until a tenant calls asking why they're being shown as delinquent when they know they paid. The bank feed has no open-charges table to check against, so it has no way to flag "$4,800 doesn't match any single tenant's expected amount" — it only knows the deposit is un-reconciled until a human tells it what it is.
- GL-correct and rent-roll-correct are two different checks — QuickBooks' bank feed only ever performs the first one
- The Customer field on a bank transaction is a typed label, not a match against an open charge
- Nothing in the bank feed compares $4,800 to what any specific tenant currently owes
- A miscategorized bundled deposit typically surfaces weeks later, as a tenant delinquency dispute rather than an immediate flag
4. What changes when the reconciliation has lease context
The reason this problem is solvable at all is that somewhere, a system knows Unit 3B owes $4,200 in March and Unit 5A owes a $600 CAM true-up — QuickBooks' bank feed just isn't that system. TenantPoint's own bank connectivity, built on Plaid, is separate from QuickBooks' native feed entirely: it connects to the same bank account independently and checks every incoming transaction against actual open tenant charges pulled from the rent roll and CAM schedule, rather than against a memorized categorization pattern.
That context changes what "automatic" can safely mean, but it doesn't make every deposit self-resolving. A transaction only auto-matches when a strong signal — like an exact amount match to one specific open charge — is corroborated by a second signal, such as the tenant's name appearing in the transaction description or a historical pattern from a prior matched deposit for that same tenant. A single signal alone, on its own, is held for a person to confirm rather than applied automatically. The $4,800 deposit above is a case in point: it doesn't cleanly match any one open charge, so it would be held for a person to split correctly against the two real charges behind it — with the rent roll and CAM schedule already in front of them, rather than reconstructed from memory.
- A separate, read-only Plaid connection to the same bank account — not a QuickBooks feature, and not dependent on whether QuickBooks is even connected
- Matches proposed against actual open tenant charges, not a learned categorization pattern
- Auto-matching requires two corroborating signals — amount alone is never enough
- A bundled or otherwise ambiguous deposit is held for a person to resolve, indefinitely, with no automatic fallback
5. What to do about it right now
If you're reconciling on QuickBooks' native bank feed alone, the fix isn't a better bank rule — bank rules match on amount and text, and a bundled or partial deposit defeats that pattern almost every time. The more durable habit is treating every deposit above a routine single-tenant rent amount as a manual-split candidate by default, and keeping a source of truth for what each tenant currently owes outside of memory, whether that's a maintained rent roll spreadsheet or a system that already tracks open charges per lease.
However you handle it day to day, the underlying issue doesn't go away on its own: QuickBooks' bank feed will keep proposing single-line categorizations for deposits that are actually several tenants' money, because it has no way to know otherwise. Matching bank transactions to tenant obligations has to happen somewhere with lease and rent-roll context — QuickBooks' own feed was never built to be that place.
- Treat any deposit larger than a single tenant's routine rent as a likely bundle, not a one-click confirm
- Keep a current, accessible record of what each tenant owes this month, separate from the bank feed's memory
- Split first, categorize second — never let QuickBooks' suggested category stand in for checking the rent roll
- Review Bank Rules periodically; a rule tuned to one tenant's flat rent will misfire the moment a different amount lands nearby
Frequently asked questions
Can I fix this with a QuickBooks bank rule for each tenant?
Only for the simplest case — one tenant, one flat rent amount, arriving on its own with nothing else bundled in. The moment a deposit combines two tenants' money, or the amount shifts because of a CAM true-up or partial payment, the rule stops matching, because Bank Rules key off amount and text patterns, not what's actually owed.
Does turning on Class or Location tracking in QuickBooks solve this?
No. Class and Location tracking organizes transactions after they're already correctly split and categorized — it's a reporting structure, not a way to know how to split a lump lockbox deposit in the first place.
If I connect a system like TenantPoint's own bank feed, will it always catch a bundled deposit automatically?
Not automatically in every case, and it shouldn't. Auto-matching only applies when a strong signal — like an exact amount match to a single open charge — is backed up by a second signal, such as the tenant's name in the description or a matching historical pattern. A deposit like the $4,800 example, which doesn't cleanly match one charge, is held for a person to resolve rather than guessed at.
Is this the same thing as the 3-way bank reconciliation process for commercial properties?
No — this is one step earlier. This is specifically about the moment a transaction lands and QuickBooks' own native feed proposes a category with no tenant context at all. The full 3-way reconciliation across your PM system, the bank, and the GL is a separate, broader process covered in its own guide.
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.