Short-Term Rental Bookkeeping: What Your Accountant Needs

If your accountant has ever asked why your Airbnb payout doesn't match the booking total in your PMS, you know the problem already. OTA payouts land as net amounts. The guest-paid total, the platform fee, the refund from the cancelled night: none of that is on the deposit notification. It's not on the bank statement either. You reconstruct it from three sources, and the reconstruction is what eats an afternoon every month.

Short-term rental accounting isn't conceptually complicated. It's logistically complicated. One reservation can involve a gross guest charge, an OTA fee taken before the deposit, a partial refund for a maintenance issue, and a separate Stripe charge for pool heating with its own processing fee and its own payout timeline. Multiply that across thirty reservations and you're doing real work before you think about categories.

The four numbers that describe a reservation

Every reservation's money story fits four numbers, in order.

Gross is what the guest paid. On Airbnb this includes the nightly rate, the cleaning fee, and the service charge the OTA passes to the guest. On a direct booking it's whatever you charged at checkout. This is your revenue number.

Platform and processing fees come off next. Airbnb charges hosts roughly 3 to 3.5%. VRBO's rate depends on which pricing model you're on. A direct booking through Stripe costs around 2.9% plus 30 cents. These are real costs and they matter for understanding margin, but they don't reduce your recognized revenue. They're expenses.

Refunds do reduce revenue. A cancelled stay, a compensatory credit, a prorated refund for a night cut short: money you returned to the guest means you earned less. If you recognized $1,200 and returned $400, your net revenue is $800.

Net deposited is what hit your bank: gross minus fees minus refunds. This is the number on your payout statement. Many STR operators only ever see this number, and it's the one most likely to confuse a bookkeeper who's trying to tie it back to the booking total in your PMS.

Tracking all four numbers in your ledger, rather than only the deposit amount, is the difference between records you can answer questions from and records you can only accept.

Where the gaps show up

The mismatch between a PMS and your books appears in predictable spots.

Most property management systems record the reservation value at booking. That number is the gross. But Airbnb sends you the net payout (gross minus their host fee), because the guest service fee goes to Airbnb directly, not through you. So your PMS says $1,400. Airbnb deposited $1,358. Your accountant sees neither figure and asks you to explain the difference.

Add a partial refund and now the PMS shows $1,400, Airbnb deposited $908, and a $450 credit sits in your Airbnb dashboard that may or may not have made it into the books.

Add a pool-heat charge through Stripe (different deposit timeline, different fee structure, different payout batch) and you have a fourth source of truth that wasn't designed to share data with the others. You're the integration point. For a look at how these tools fit together in a well-run operation, see a property manager's ops stack in 2026.

What the ledger should look like

A reservation-level money log fixes this. For each reservation, track: reservation ID, property, booking channel, check-in and check-out dates, gross charge, OTA fee, processing fee, refund amount, and net deposited. Add-on charges (pool heating, early check-in, EV charging) get their own rows in the same log with the same columns.

The log doesn't have to be a database. A CSV with those columns, exported monthly, is enough for a bookkeeper to work from. What it has to do is trace from the guest-paid total down to the bank deposit on every row. If a row doesn't foot, you find it before your accountant does.

Platform fees and processing fees belong in expenses, not deducted from revenue. Your gross revenue line should reflect the full guest payment before costs, the same way a retailer records the full sale price before subtracting cost of goods. Mixing fees into the revenue line makes your results hard to read and harder to compare across booking channels.

Handing it to a bookkeeper

A bookkeeper who works with short-term rentals knows the OTA structure. One who doesn't will ask you to explain it every month, or worse, categorize everything from the deposit amount and miss the fee expense entirely.

Give them the ledger, not the raw platform exports. The Airbnb payout summary is confusing even if you know it well. A clean CSV with one row per financial event, reconciled to bank deposits, is faster to import into QuickBooks or Xero than it is to explain what the payout report means.

For QuickBooks: gross revenue maps to an income account, OTA and processor fees map to a platform costs expense account (or two separate lines if you want to track them individually), refunds as contra-revenue, and the net deposit to the bank account in the cash flow view. Xero follows the same structure with slightly different labels.

If you manage properties for multiple owners, run one ledger per property. Revenue recognized to the wrong property is a client trust issue. Catch it on the statement and it's an awkward correction. Catch it after the year closes and it costs real time and money. For how the numbers from your reconciled ledger translate to what owners see each month, see what owners expect in a monthly statement.

Add-on revenue changes the shape

Pool heating, early check-in, late checkout, EV charging sessions: these are Stripe transactions, not OTA transactions. They arrive at a different time than the booking payout, carry their own Stripe fee, and may land in a different deposit batch entirely.

The temptation is to track them separately because they came from a separate source. That works until you need a per-property revenue report or an owner statement, at which point you're combining two ledgers by hand.

Put them in the same reservation-level log. Same columns, same reconciliation chain. The export looks identical. When you look at any reservation, you see the full picture: booking revenue plus add-ons, minus costs. That's what an owner wants on their statement, and it's what your accountant needs for a clean return.

What a fast close looks like

A well-maintained ledger turns the monthly close into a verification step. Check that every row reconciles to a bank deposit, confirm add-on charges matched their reservations, verify any refunds were credited correctly, and export to your bookkeeping tool. Usually under an hour.

The closes that take four hours are the ones where the ledger fell behind during the month. You're pulling reports from three platforms, cross-referencing payout IDs, hunting one deposit that doesn't match. That's a sign of what didn't get logged when it happened.

If events update the ledger as they occur (a Stripe webhook fires when a pool charge succeeds, a confirmation arrives on payout day) the close is a quick check. No archaeology.

Pomello's accounting view records each payment event at the reservation level, from gross through net, across pool heating, early check-in, late checkout, and EV charger charges, with exports formatted for QuickBooks and Xero. If you're managing multiple owners and need per-property totals tied to individual reservations, that's the shape of what you're looking for.