QuickBooks Classes vs. Locations for Commercial Real Estate Properties

1. What Class and Location actually do in QuickBooks Online

Neither one replaces the chart of accounts — they cut across it. Here's the gap they exist to close: you own a strip center. Georgia Power hits the bank for $1,422. QuickBooks knows you spent $1,422. What it doesn't know on its own is the property, the expense category, whether that $1,422 belongs in CAM, which period it belongs to, or which operating event caused it. Class and Location are the two built-in tags QuickBooks Online gives you to bolt that context onto a transaction after the fact.

Both come out of the same shared pool on QuickBooks Online Plus — a combined 40-item limit covered in Section 3 — and they don't behave identically across transaction types. Invoice and Payment let you set Class or Location once, at the transaction header. Purchase does not for Class; Class only lives on each line, while Location still applies at the header even on a Purchase. That distinction, covered fully in Section 4, is the one piece of this decision almost nobody writing about Class vs. Location has actually had to build against.

2. The two real options, and why they're not interchangeable

QuickBooks Online allows exactly one Location per transaction, set at the header. It allows multiple Classes on one transaction, one per line, and Class also supports parent/child nesting (Property > Building) that Location doesn't. Those two mechanical differences, not general bookkeeping opinion, are what should decide which one carries "property" for you.

If every transaction you'll ever record genuinely belongs to exactly one property — the overwhelmingly common case for a single vendor invoice or a tenant payment — Location is the simpler, more consistent choice: it stays at the header on every transaction type, including a Purchase, so there's never a per-line tagging step to remember. Class becomes the better fit for whatever varies WITHIN a transaction, like expense category on a multi-line vendor bill, precisely because it's designed to be set per line. Used the other way around — Class carrying the property — every line of every Purchase needs the property tag set individually, since Class has no header-level shortcut on that transaction type.

• Location: one per transaction, header-level, on every transaction type including Purchase — the simpler choice when a transaction always belongs to one property
• Class: multiple per transaction (line-level), nests (Property > Building), but has NO header-level field on a Purchase — every line needs it set separately
• A single vendor invoice that legitimately spans two properties needs two transactions if you're using Location for property, since only one Location is allowed per transaction
• This is a mechanical QuickBooks constraint, not a general 'best practice' opinion — confirmed directly against QuickBooks Online's own transaction behavior

3. The math nobody runs: the 40-item cap against a real growing portfolio

Here's the math worked through on a realistic portfolio: a 12-property strip-mall owner sets up 12 Locations, one per property — 12 of 40 slots used, 28 to spare. Then, wanting expense-type visibility (CAM-recoverable, non-CAM operating, capital) without restructuring the chart of accounts, the owner adds 8 Classes for expense category, applied per line as needed. That's 12 + 8 = 20 combined items — well under the cap, with real headroom to add more categories or grow the portfolio toward 30 properties before the 40-item ceiling becomes a live concern.

Run the same portfolio the other way — Class per property instead — and the math gets worse, not better, once Purchases enter the picture: a 3-line Purchase for one repair job (parts, labor, disposal fee) needs the same property Class chosen on all three lines individually, since Class has no header shortcut on that transaction type. The item count doesn't change, but the per-transaction data-entry burden does, and a missed line doesn't throw an error — it just posts with no property tag attached, silently absent from whatever per-property report you're relying on until someone notices the gap.

• 12 properties as Locations + 8 expense-category Classes = 20 of 40 combined slots used, with real room to grow
• The same 12 properties as Classes instead still uses only 12 slots — the cap math isn't the problem with Class for property
• The real cost of Class-for-property shows up per transaction, not at setup: every line of every Purchase needs it set individually
• A missed line on a multi-line Purchase doesn't error out — it posts untagged and quietly falls out of per-property reporting

4. The Purchase transaction's header has no Class field — and that changes what's practical

This is the nuance TenantPoint's own integration had to solve directly, because it's the one that pushes reconciled, work-order-linked bank expenses into QuickBooks as a Purchase. Confirmed against QuickBooks' own API behavior: a Purchase's ClassRef lives only on each line item, never on the transaction header, while its DepartmentRef (Location) does apply at the header, the same as it does on an Invoice or a Payment. There's no "set Class once at the top and every line inherits it" shortcut for a Purchase — whoever enters or automates that transaction has to choose Class line by line, every single time, while Location only ever needs to be set once regardless of transaction type.

That's the deciding factor, not a stylistic preference: if Location already has the header-level consistency Class lacks specifically on Purchase transactions, using Location for property and reserving Class for whatever varies within a transaction (expense category, cost type) avoids the per-line re-entry risk entirely. TenantPoint's own setup wizard offers both tracking modes — Class or Location — for exactly this reason: which one fits depends on whether a portfolio needs Class's per-line flexibility badly enough to accept the Purchase-specific line-level tagging that comes with it.

• Invoice and Payment: Class/Location both set once, at the transaction header
• Purchase: Location still applies at the header; Class only applies per line, with no header-level fallback
• A 3-line Purchase (parts, labor, disposal) needs a property Class chosen 3 times if Class carries property — Location would only need setting once
• TenantPoint's setup wizard supports both tracking modes; this asymmetry is the concrete reason to default toward Location for property unless per-line nesting is worth the added data entry

5. The scheme that scales: Location per property, Class for whatever varies per line

Location for property, Class for expense category, is the structure with the least ongoing friction: property tagging happens once per transaction regardless of type, expense-category tagging happens where it naturally varies (per line), and the combined 40-item budget stretches further because most portfolios need far fewer distinct expense categories than distinct properties.

TenantPoint's own setup wizard is built around this same tradeoff, because it had to be: tracking mode is chosen once during setup — Class, Location, or none — with a warning if the combined count you're about to create would exceed the 40-item cap. Whichever mode is chosen, an unmapped category or an ambiguous work order is held for a person to resolve rather than guessed at; the tracking-mode choice affects how the data is tagged, not whether ambiguous cases get resolved safely.

• Default to Location for property unless you specifically need Class's parent/child nesting for buildings or units within a property
• Use Class for whatever genuinely varies within a single transaction, like expense category on a multi-line Purchase
• Count combined active Classes and Locations against the 40-item cap before finalizing either scheme, especially with growth plans in view
• Revisit the scheme before onboarding a property that would push the combined count past 40, not after QuickBooks refuses to create a new one