Is the "gross revenue" column in a PMS export really gross?

Often not. In the exports checked for this post (Hospitable, Guesty, Hostaway, OwnerRez, Lodgify, and Airbnb's own), the column labeled gross was already net of at least the platform service fee. The real guest-paid total usually sits in the same CSV under another name, such as "Total Charged to Guest," or can be rebuilt as nightly rate times nights plus guest-paid fees.

What does Schedule E Line 3 ask for?

Rents received: what the guest paid for the stay before the platform's fee, not the deposit that hit your bank. The platform's service fee goes on its own expense line, Line 8 for commissions or Line 11 for management fees, whichever your CPA uses.

Why is reporting only my Airbnb deposits wrong if net income comes out the same?

Because Line 3 and the expense lines are both short by the fee, and gross is the number the IRS can check. A platform's 1099-K reports gross payments with no adjustment for its fees, so a deposit-based Line 3 will not tie to it. Line 3 is also the ceiling on deductions under §280A(c)(5) in any year personal use makes the property a residence, and it is the revenue a lender underwrites.

How do I check my own books for the gross-vs-net problem?

Take one property and one month. Sum the PMS column labeled gross, then sum nightly rate times nights plus every guest-paid fee for the same reservations. If the second number is higher, the difference is the platform fee. It belongs on an expense line, and the higher number belongs on Line 3.

Home · Blog · Field Notes

October 4, 2026 STR TAX · BOOKKEEPING 8 min read

Nine Ways STR Books Go Wrong Silently (I Found All Nine in My Own)

I write bookkeeping software for short-term rentals. Over three days at the end of September I went through my own five properties line by line and found nine separate errors, which together overstated my 2026 revenue by more than $100,000. None of them announced themselves. Every single one was arithmetic a program could have checked and didn't.

Jordan Ueltschy · 5-property STR operator (OH, KY, FL) · founder, RentReel

Why none of them looked wrong

This is the part worth sitting with. Not one of those nine errors produced a number that looked obviously broken. Revenue was up. Margins looked healthy. Every total added correctly, because the arithmetic was fine. The inputs were wrong.

I only caught them because I know what my own properties should do in a month. I looked at one figure and thought "that cannot be right", and nine bugs fell out of that one question. A customer who does not have that instinct never asks it. They file.

The nine

Expired booking requests counted as revenue. $23,045. The importer filtered out anything whose status matched "cancelled" or "declined", which sounds thorough until you meet a status called "not accepted" and another called "checkpoint". Those are not bookings. They were sitting in Line 3.

Platform payouts counted on top of PMS gross. $74,696, and the biggest single item. Your PMS reports a booking at gross. Your bank reports the payout of that same booking, net of fees. Count both and you have invented revenue that no guest ever paid. This one is easy to create and very hard to see, because both numbers are individually correct.

Internal transfers booked as income. About $17,000 of my own money moving between my own operating accounts, recorded as if it were rent.

A vendor matched to the wrong property. A charge at Fort Sill matched a property whose short code is "LL". The substring was in the merchant name. That put $856.30 of my cousin's expenses onto my books.

An apostrophe. One LLC is spelled with an apostrophe in some exports and without it in others, so the intercompany matcher failed and those transfers were read as income.

A negative number in an income row. A software subscription of $3,265.88 was typed as revenue. Because it was negative, it quietly reduced the year's rents instead of appearing as the expense it was.

An eighteen-month window. The sync pulled a rolling period rather than whole tax years, so the first quarter of 2025 simply fell off the back. $23,772.78 of real income, missing.

Two hundred and thirty-five rows with no property. $45,726 of expenses attributed to nothing. The per-property profit looked fine. It was fine. It was also incomplete.

The same bank connected twice. A single $10,854.52 deposit arrived through two connections and was counted twice, because the provider issues a different transaction id per connection. Both copies looked legitimate because both were.

What they have in common

Every one is detectable by arithmetic. Not by judgment, not by a CPA reading your file in March. By a program, at the moment the data lands.

A property cannot be booked by two guests on the same night. A statement from a bank cannot contain only withdrawals. An income row cannot be negative. If your PMS already reported a booking at gross, the bank deposit settling it is not additional revenue. These are not opinions about accounting. They are things that cannot be true.

That is the test I ended up applying: not "does this look right" but "could this possibly be true at all".

What I did about it

RentReel now runs ten checks against your books and tells you when a number cannot be true. Overlapping stays on one property. The same booking code imported twice. Platform payouts sitting on top of the gross they settle. Negative income rows. Transactions belonging to no property. A month more than two and a half times your median. Mortgage payments with no loan terms, where principal gets deducted as interest. Missing cost basis, which quietly leaves Schedule E Line 18 at zero. The same charge arriving from two feeds. And a bank import that lands with no deposits in it at all, which is almost always a file being read backwards.

The checks never change your data. They state what cannot be true and point at the rows.

Two details matter more than the list. The first is that the checks had to be precise enough not to cry wolf. Five identical charges from the same vendor on the same day are usually real, and I have the PriceLabs invoices to prove it. A same-day turnover is not a double booking. An early fix of mine deleted two legitimate rows before I caught it, which taught me that a checker that is wrong is worse than no checker.

The second is that where the software cannot tell, it imports and flags rather than dropping. A duplicate is recoverable. A transaction that silently never arrived is not.

The one I would check first if I were you

Depreciation. Mine was reading zero across all five properties, and it is usually the largest deduction a rental produces. Not because of a bug, but because the purchase price had never been entered, and nothing in the product had ever said so out loud. The IRS reduces your basis at sale by depreciation allowed or allowable, which means an unclaimed year is not deferred. It is gone.

If you take one thing from this: open your own books and find the number you would not be able to defend. Then ask whether anything in your stack would have told you.

Mine would not have. It does now.