Recording STR Income & Expenses Correctly

Recording is where structure becomes truth — or error

You separated the cash so it could be told apart, and you structured a chart so every report could mean something. Recording is the act that fills that structure — and it's where accurate books are either made or quietly broken. Every booking, fee, bill, and transfer becomes one or more entries in the accounts you built; do it well and the monthly close and the financial statements downstream are almost automatic, do it carelessly and you've built a tidy chart full of wrong numbers.

The trap is treating your bank and card feed as if it were the books. It isn't — and this is the same point the foundation raised, now applied to the day-to-day. A clean feed is a strong, timestamped record of the cash path: it shows that a net amount moved on a date. But a single line — "Airbnb deposit, +$2,134" — is standing in for several distinct economic events: the gross revenue you earned, the fee the platform took, maybe tax you collected, maybe a refund. Recording is the translation from what moved to what happened. Do it as transactions occur, or on a steady monthly cadence, and it's mechanical. Skip it until spring and you've signed up to reconstruct a year of bundled deposits from memory.

(This node teaches how to record; the platform-by-platform and software-specific mechanics live in the linked leaves. A note before we go further: this is educational, not legal or tax advice, and the deductibility and tax-line questions below are your tax professional's to decide.)

The payout isn't the revenue

A foundational recording habit for an STR is to record income gross, rather than treating the net platform payout as revenue. When a platform pays you, the deposit that arrives has already had the host service fee removed, and depending on the booking it can also fold in occupancy taxes, refunds, adjustments, or a security deposit. Record that net deposit as "rental income" and call it done, and you've made a single entry stand in for several — understating your income (you booked the after-fee number) and your expenses (you never recorded the fee at all), and flattening the composition your chart was built to show.

Recording it correctly takes an extra couple of minutes. Record the gross booking revenue as income, the platform fee as its own expense, any occupancy tax you're obligated to remit as a liability (not revenue), and refunds or adjustments according to what they actually reverse or represent — not reflexively "against revenue," since a refund or adjustment takes its character from the underlying event. For a simple payout containing only booking revenue and a platform fee, the net of those entries matches the deposit; when the payout also carries taxes, refunds, adjustments, or a deposit, record those components too, so that together they reconstruct the full payout. Either way, your income is now stated correctly, the platform fee is captured, and you can see what each channel actually costs. This is exactly the split the chart of accounts was designed to receive: the cleaning fee recorded to its own income line (rather than netted against the cleaner's invoice) is what later lets you see whether the fee covers the cost.

There's a clean division of labor between this stage and the next, worth stating once: recording decomposes the transaction into what actually happened; reconciliation — the monthly close — proves the decomposition is complete. This node records the components; the close (Reconcile, P40) is where you verify they add back to the cash that moved and nothing was dropped.

You don't have to do this booking by booking. From the monthly payout report, recording the gross income and platform-fee totals for the month is a good level of detail for a single property. When a month's payouts also carry taxes, refunds, adjustments, or deposits, record those components as well and reconcile the complete payout to the cash that arrived. Move to per-booking entries only if you run multiple channels or want booking-level operating detail. (The platform-by-platform mechanics — reading an Airbnb payout report, reconciling a Stripe or direct-booking processor — are covered in the linked leaves; the principle here is the same regardless of platform: the deposit is net, so record the gross.)

Record each expense to its real character

Recording expenses is mostly categorizing each cost to the account you built — with a few transactions that carry more than one character and have to be split. Many routine bills are straightforward: cleaner, utilities, supplies, and software each go to the account built for them. The ones that trip people up are the compound and non-obvious transactions:

• The mortgage payment. One cash outflow, three characters: interest is an expense (tracked apart from operating expenses, since financing sits below NOI), principal reduces the loan liability, and escrow moves cash into an asset the servicer holds. Split it using the actual figures from your statement each month — recording the whole payment as one "mortgage expense" overstates expenses and buries the equity you're building.
• Costs you paid personally. When a rental expense goes on a personal card, record the underlying rental cost to its expense account, then record the other side according to how the business treats the owner-paid amount — for example an amount due to the owner, a reimbursement, or an owner contribution, as appropriate for your entity and accounting setup. The point is that the cost is captured and the offset is classified deliberately — not skipped, and not left as an untracked "I'll remember it." An unrecorded owner-paid cost is a real expense missing from your books.
• Money you're only holding. Two quiet rules live here. Cash you collect isn't automatically income: a refundable deposit is a liability while it's refundable. And cash — or tax — that merely appeared in a booking total isn't automatically your payable: occupancy tax you're obligated to remit is a liability that clears when you remit it, but if the platform collected and remitted that tax directly, there's nothing for you to book as a host payable. Keep guest damage recoveries in their own account rather than folding them into rental income.
• Entries the bank feed never shows. Some things aren't in the feed at all. Depreciation is the clearest: in the BFC baseline workflow it isn't something the owner estimates from the bank feed — it's posted through a period-end or year-end journal entry, using the depreciation schedule and figures coordinated with your tax professional (the accounts exist from the chart; the numbers and method are Tax's). If you run accrual, accruals and prepaids also originate as recorded entries, not bank lines.

The line to hold throughout: recording is about capturing what happened; whether a given cost is deductible, and on which line it lands at filing, is Tax's decision. Record it accurately and to its true character, and you've given Tax something clean to work from.

See the entries, worked out. Every transaction above — a net platform payout, a refundable deposit, host-remitted lodging tax, a mortgage payment with escrow, an owner-paid cost, a business credit-card charge, a CapEx-clearing item, a damage recovery — is shown as a balanced set of entries in the Worked Flows tab of the STR Chart of Accounts template (the download from the previous guide). It's the executable companion to this node: the same decompositions this article describes in prose, laid out entry by entry against the exact accounts.

Keep every property visible

If you own more than one unit, the recording rule that keeps a portfolio legible is simple: every entry carries its property. In one set of books, that means tagging each transaction to the property it belongs to — in QBO that may mean Classes, Locations, or another deliberate tracking design; other systems use their own dimensions or tags — so you can produce a per-property profit-and-loss, not just a portfolio-wide blur. Without property-level tracking, a strong unit and a weak one can average into a portfolio result that obscures what each property is actually doing. (Which tracking design to use, and how to set it up for a multi-property portfolio, is covered in the linked leaf.)

Whether you should instead give each property its own set of books — separate files rather than one file with property tags — is a genuine scaling decision with its own trade-offs, and it interacts with how you've structured your entities. That decision has its own home (the Should Each STR Property Have Separate Books? hub); the recording discipline is the same either way — no entry is allowed to lose track of which property it belongs to.

Cash vs. accrual: pick a basis, and be consistent

There's one real method choice inside recording, and it's worth making on purpose rather than by accident: whether you keep the books on a cash or an accrual basis. The difference is when you recognize a dollar. At a high level, cash-basis books generally recognize income when it's received and expenses when they're paid — simple, it tracks your bank, and it's a common choice for an owner-operated STR. Accrual accounting recognizes revenue when it's earned (as the stay actually happens) and expenses when they're incurred, regardless of when cash moves — which matches revenue and costs to the period they belong to.

Short-term rentals have features that make the two diverge more than you'd expect: a guest often pays at booking for a stay that's months away, a security deposit is collected and held, an annual insurance premium is prepaid. Cash and accrual will place those in different periods — so the same year can look different depending on the basis. Neither is universally "right"; each answers a slightly different question (what hit the bank this period vs. what this period actually earned and cost).

Two things matter more than the choice itself. First, be consistent — pick one basis and apply it the same way every period, or your trends become noise. Second, the tax accounting method on your return is a Tax question: your tax professional may guide or elect the method, and changing methods later has its own tax procedure — so decide it deliberately, with them, rather than drifting into whichever the software defaulted to. (This is a method choice within recording; the deeper "one set of books or separate books per property" question is a different decision — P43.)

   RECORD WHAT HAPPENED, NOT WHAT LANDED

   WHAT LANDED                        WHAT HAPPENED  (record each part)
   ┌──────────────────────┐   decompose    Gross booking revenue
   │  + $2,134            │      ──►         (nightly · cleaning · pet — own lines)
   │  "Airbnb payout"     │              −  Platform fee            (its own expense)
   └──────────────────────┘              ±  Refunds / adjustments   (per what they represent)
        one lump on the feed             −  Occupancy tax liability (if you remit it)
                                         ±  Refundable deposit activity (a liability)
                                         ────────────────────────────────────────────
                                         =  $2,134 cash   ← the parts reconstruct the payout

   Illustrative payout; the components shown vary by platform and booking.

   Same rule elsewhere:  one mortgage payment → INTEREST + PRINCIPAL + ESCROW.
   And every entry carries its PROPERTY (class / tag) so each unit keeps its own P&L.

Read it in one line: the deposit is the cash path; record the real transactions behind it — gross revenue, the fee, any tax, refunds, deposits — each to its own account and tagged to its property, and the parts reconstruct the cash that moved.

Right-size it — sufficient detail, at a cadence you'll keep

The common failure here isn't insufficient detail; it's inconsistent recording — though too little detail is a real failure too, which is exactly why a net payout is too coarse to record as one line. The target is the pair: enough detail to keep each transaction's character, at a cadence you'll actually sustain. For a single property, recording gross income and platform fees as monthly totals from the payout report hits that pair well — accurate books, minimal effort. Per-booking detail earns its place only when you're running several channels or want booking-level operating analysis. A slightly coarser system you keep current beats a beautiful one you abandon in March. The point of recording is a set of books that's true and current, not maximal.

Your action plan

1. Record income gross, from the payout report. Enter the gross booking revenue as income and the platform fee as its own expense; record any tax, refunds, adjustments, or deposits as their own components — together they reconstruct the payout. Split meaningful streams (nightly, cleaning, pet) to their own lines.
2. Split the compound payments. Record the mortgage from the statement as interest (an expense, apart from operating expenses), principal (a loan-liability reduction), and escrow (an asset) — never one lump.
3. Record what you're only holding as liabilities. Refundable deposits, and occupancy tax you're obligated to remit; don't create a host tax payable when the platform already remitted it; keep damage recoveries in their own account.
4. Capture owner-paid and non-bank items. Record a rental cost you paid personally to its expense account with the offset classified for your setup (due-to-owner, reimbursement, or contribution); post depreciation through a period-/year-end entry from the depreciation schedule with your tax pro — don't estimate it from the bank feed.
5. Tag every entry to its property. Use Classes, Locations, or your system's tracking design so each unit has its own P&L — whatever you decide about separate books.
6. Pick a basis and a cadence, and keep them. Choose cash or accrual deliberately (with your tax pro), record on a routine you'll sustain, and apply it the same way every period.

The bottom line

Recording is the step that turns your separated accounts and structured chart into books that are actually true. The deposit that hits your bank is the cash path, not the transaction behind it — so record the gross revenue, the platform fee, any tax you owe, refunds and deposits by their character, and the loan splits, each to the account you built for it, so the parts reconstruct the cash that moved. Tag every entry to its property so no unit disappears into the blob, choose cash or accrual on purpose and hold it steady, and hand the deductibility and tax-method questions to Tax. Do it on a cadence you'll keep, and the monthly close and the reports that follow become a read, not a reconstruction. Record what happened, not what landed.

About the author

Matt Nunn is the founder of Builders Finance. He has spent two decades working with the financial side of real estate businesses, and started Builders Finance to give short-term-rental operators the financial systems, frameworks, and plain-language education that most hosting advice skips over. Builders Finance publishes educational content for STR owners; it is not legal or tax advice, entity and tax rules vary by state and situation, and it is not a substitute for guidance from your own attorney and qualified tax professional.

Continue learning

Educational information only — not individualized tax, legal, or investment advice. The worked example is an illustrative model, not a projection or a recommendation.