Per-Property Reporting From One Set of Books

Why a blended P&L is worse than no P&L

One set of books with no property dimension records every property's income and expenses in one undifferentiated set of accounts — and for two properties that is actively misleading. The report shows total revenue, total expenses and total net income, for everything combined. With one property that is exactly right. With two, it is a number that averages away the only thing you needed to know.

Say the combined net income for the year is $22,000. You have no idea whether Property A made $30,000 and Property B lost $8,000, or whether the two contributed roughly equally. Those are completely different situations calling for completely different responses — sell, refinance, change the pricing, change the manager, or leave it alone — and a blended report showing $22,000 makes them look identical. The fix is not more reports. It is one more field on every transaction.

The property dimension, whatever your ledger calls it

The method is a single dimension that answers "which property is this?" on every transaction, plus one bucket for the costs that belong to all of them. Accounting systems give that dimension different names — classes, tracking categories, tags, departments, projects — and a spreadsheet gives it a column. The name does not matter and the vendor does not matter. What matters is that the field exists, that it is available on every transaction form your ledger has, and that it is populated every time.

Set it up with one value per property and one value for the portfolio. If your ledger can warn you when a transaction is saved without the dimension, turn that warning on: it is the single setting that prevents untagged transactions from quietly accumulating, and it costs nothing.

Two things not to do while setting it up. Do not build a separate set of books per property to get property-level reporting — that is a different decision with real costs, and it is answered on its own terms in Should Each Property Have Its Own Books?. And do not nest sub-values beneath each property for individual units unless your tax professional specifically asks for them; depth adds maintenance and rarely produces proportional analytical value.

Naming the properties

Name each property so that you will recognize it in a report six months from now, not so that it sorts neatly today. Two conventions work.

Location-based, which suits most operators: Scottsdale Bungalow, Sedona Cabin, Flagstaff Studio, plus Portfolio for shared costs.

Market and type, which suits a portfolio spread across markets: Phoenix / Condo, Tucson / House, Prescott / Cabin, plus Portfolio.

Avoid generic labels like "Property 1" or "Property A." They are faster to type and they defeat the purpose: a report you have to decode is a report you stop running. Create the Portfolio value at the same time as the properties, not later when the first shared cost arrives and needs somewhere to go.

Where shared costs go

Not every cost belongs to a single property, and forcing one to is how a property-level number stops meaning anything. Some costs support the whole operation and cannot be honestly attributed to one unit over another. Those go to the portfolio bucket:

• tax professional and tax preparation fees;
• bookkeeper fees;
• education, courses and books;
• software subscriptions that serve all the properties — channel management, dynamic pricing, portfolio dashboards, the accounting system itself;
• home-office expenses, where they apply;
• entity maintenance fees, such as annual LLC filings;
• general business insurance not tied to a specific property;
• professional development and industry conference costs.

Everything that can be traced to one property carries that property's tag: all of its income, including the nightly rate, cleaning fees and pet fees; the platform fees on its bookings; cleaning and turnover; repairs and maintenance; utilities, property-specific insurance and HOA dues; mortgage interest and property taxes; supplies, landscaping and outdoor maintenance.

The two behave differently in reports, by design. Run a property-level report and the portfolio costs do not appear, which is what makes the property's own operating picture readable. Run the portfolio without a filter and everything appears, which is the picture your tax professional works from — and at tax time those shared costs are allocated across the properties by a reasonable method, typically in proportion to revenue.

Every transaction, without exception

A property tag that is usually applied is not a property dimension; it is a guess with good intentions. The rule is absolute: no transaction is saved without one. That covers bank-feed transactions, manually entered expenses, journal entries and recurring transactions alike.

An untagged transaction is a transaction that belongs to no property. It appears in reports as unclassified, and it distorts every property-level report you run from that month onward — which is worse than being absent, because the report still looks complete. If your ledger offers the warn-on-save setting, that is what it is for.

Split entries need the same discipline, line by line. A platform payout recorded correctly is not one line: the gross accommodation revenue, the cleaning-fee income and the platform-fee expense are separate lines, and every one of them carries the same property tag for that booking. The decomposition itself is taught in Recording STR Income & Expenses Correctly; the rule here is simply that the tag travels with each line of it.

The side-by-side view

The dimension exists for one report: every property in its own column, on one page. A single profit-and-loss with one column per property and a total column is the view that makes a portfolio legible — which property earned the most, which carries the heaviest expense load relative to its revenue, and which is drifting away from the others month over month.

That comparison is the whole return on the tagging discipline. Individual property reports are useful and most ledgers will produce them in seconds once the dimension is populated, but they are read one at a time and the eye does not hold three of them at once. The side-by-side does the comparing for you.

The monthly read

The dimension produces data; the monthly review is what turns it into decisions. Two loops, and they answer different questions.

The property loop runs once for each property. Pull the property's report for the prior month. Compare gross revenue against the prior month and against the same month last year, because seasonality makes month-on-month alone misleading. Review total expenses and flag any category that looks unusually high or unusually low — an absent category is as informative as an inflated one. Then compute net operating income, and cash flow after the mortgage.

The portfolio loop runs once. Pull the side-by-side across every property. Rank them by net operating income for the month. Identify any property whose expenses are growing faster than its revenue, which is the earliest signal that something has changed on the ground. Then record the month's figures wherever you track them over time, so that a trend has somewhere to become visible.

Worked example — doing this in QuickBooks Online

One implementation, shown once. QuickBooks Online calls the property dimension a class, and class tracking is the feature that provides it. The steps below are specific to that product; everything above this heading is not. Menu paths move, so confirm the current ones against the product itself.

Enable the dimension: Gear icon → Account and Settings → Advanced → the Categories section → toggle Track Classes on. While you are there, toggle Warn me when a transaction isn't assigned a class, which is the warn-on-save setting described above. Save, then Done. Every transaction form — invoices, expenses, journal entries, bank-feed categorizations — now carries a Class field.

Create the values: Settings → All Lists → Classes → New, one per property plus one named Portfolio.

Run the side-by-side: Reports → Profit and Loss → Customize → under Rows/Columns select Columns → Classes → Run Report. For a single property instead, use Customize → under Filter select Class and choose the property.

(Builders Finance does not sell bookkeeping software. Where we point to a specific tool we do it on the merits and disclose any affiliate relationship, and that compensation does not determine the analysis or the recommendation — the method above reads the same whatever ledger you run it in.)

What this does not solve

A property tag creates accounting separation. It does not create legal separation. That distinction matters most for operators who have gone to the expense of separate entities: tagging transactions inside one pooled bank account does not maintain the separateness those entities depend on, however clean the reports look. Where the money actually sits is a different question from how it is labeled, and it is answered in Separate Banking and Accounts and Piercing the Corporate Veil.

The other thing it does not solve is who does the work. Tagging every transaction every month is a habit with a time cost that grows with the portfolio, and at some point delegating it is the right answer. That decision — do it yourself, buy software, or hire a bookkeeper — is its own guide: DIY, Bookkeeper, or Software for an STR?.