A payout lands in the bank account. One number. Behind it, twenty reservations, and nothing that says which one is which.
An STR operator opens a spreadsheet. They pull the PMS report next to it, then the bank statement, then whatever CSV the OTA sent that week. Line by line, they start guessing. This reservation looks like it's in there. This one might be short. This one has a fee attached that nobody remembers approving.
It's not really about the hours it takes. It's that nobody in the building can say, with any real confidence, whether this month's numbers are actually right.
This isn't a spreadsheet problem. Revenue arrives in a shape nothing was built to match automatically, bulk deposits, scattered reservation data, a different format for every OTA and processor. Something has to translate that mess into an answer.
Why Booking Revenue Doesn't Match Your Bank Deposits by Itself
One Payout, 8 Reservations
A single payout from Airbnb, Booking.com, or a Stripe-processed direct booking can bundle a dozen or more reservations into one bank deposit. There's no built-in breakdown. Someone has to manually split that lump sum across the right properties, owners, and stay dates before anyone can trust an owner statement built on top of it.
At 25 units, that's a recurring annoyance, a few minutes lost every time a payout lands. At around 100 units, it's a weekly grind, enough deposits landing that someone has to set aside dedicated time just to keep matching from falling behind. At 1,000 units, it's a standing job function, someone's entire role built around decoding deposits by hand.
Deposits, Refunds, and Reservations That Change Midstream
Money doesn't arrive in tidy, matchable pieces, it arrives early, late, and rearranged. A deposit collected six months before check-in has to sit correctly tracked the whole time, not logged as paid too early and not lost waiting for the balance to land. A refund shows up weeks later as a separate, unlabeled negative amount, with no obvious link back to the booking it came from. And the reservations themselves keep moving underneath all of it, a guest extends their stay, a pet fee gets added after the fact, a rate gets adjusted, and suddenly the numbers that looked reconciled yesterday don't add up today. None of this is an edge case. Put together, it's a normal week.
What This Costs at Month-End
Owner Statements Stuck Behind One Unmatched Payout
A single unmatched deposit can hold up an entire owner statement cycle while someone tracks down where it belongs. The reason it's unmatched in the first place is usually the same: Airbnb, Stripe, Guesty Pay, Booking.com, and Whimstay all batch payouts as lump sums with no reservation-level detail, so there's nothing to tie the deposit back to the booking without someone doing it by hand. Trust accounting depends on knowing exactly which funds belong to which owner, and a misallocated payout puts that accuracy at risk, not just the schedule.
The Real Risk Is Not Knowing, Not Just Losing Time
The cost isn't only the hours spent matching. It's operating for weeks without knowing whether the numbers are actually right. And the workarounds teams build to cope prove how broken the process is. One team we work with logs into 20+ separate Airbnb accounts every day, some sitting behind an owner's own 2FA, just to pull payout data. A different operator used to manually check every single house at month-end. That's not a process, it's a band-aid. The fix isn't more people cross-checking spreadsheets. It's a system that shows the answer without anyone having to chase it down.
Introducing Topkey's Revenue Reconciliation
That's what Topkey's revenue reconciliation is built to do. It replaces the manual bank-to-PMS spreadsheet matching most operators are still doing today, one payout and one reservation report at a time. It replaces relying only on PMS-native owner statement tools that don't check themselves against what actually landed in the bank. And it replaces downloading OTA payout CSVs by hand and reconciling them line by line outside the PMS entirely.
Every reservation moves through the same basic path before it ever reaches a statement. A guest books through an OTA like Airbnb, Booking.com, Whimstay, Vrbo, etc, and the PMS records what that reservation should be worth. From there, the money either comes straight from the OTA itself or moves through a payment processor like Stripe first, before it lands in the bank. Topkey sits between all four pieces, the OTA, the PMS, the payment processor, and the bank feed, at once, which is what makes it possible to break apart bundled deposits, match every dollar back to its reservation, and flag anything that doesn't line up.
The Direct Airbnb Connection
Airbnb is the clearest example of how this works, and the hardest one to get right. Airbnb bundles multiple reservations into a single payout, and it isn't the only OTA that pays out directly, Booking.com does too. What makes Airbnb different is that there's no other way to get its data: no public export, no CSV, nothing to scrape. A direct, approved integration is the only route in, which is why Topkey built one. That connection pulls reservation, payout, and adjustment data straight from Airbnb's API, no browser extensions, no manual exports, no email parsing.
That direct connection is what makes the harder cases in this piece possible to handle at all. Damage claims, extra nights, late checkouts, refunds, and other Resolution Center activity get pulled in automatically and reconciled alongside core reservation revenue, instead of showing up as a mystery variance someone has to chase down. Airbnb revenue gets mapped to the right property, owner, and accounting period automatically, no manual tagging, which is what makes accurate property-level P&Ls and a predictable close possible in the first place.
How a Payout Becomes a Matched Reservation
From Bank Deposit to OTA Payout Record
A bank deposit arrives, visible as soon as the bank account is connected to Topkey. Getting from that deposit to a usable payout record works differently depending on where the money came from. Airbnb's connection is covered above. The other OTAs vary: Booking.com and GuestyPay pay out directly like Airbnb does, but without a direct integration yet, so its payout record comes in through a quick CSV upload instead. Whimstay also pays out directly, but doesn't share reservation-level detail, so its deposits get matched by amount and date instead of a full payout record. Vrbo doesn't pay out directly at all, its bookings move through Stripe, so that's the payout record Topkey works from. On the payment processor side, Stripe connects automatically through its own API and pulls the payout record in daily, no extra steps required.
The point for the operator is that every channel funnels into one place, so there's no logging into separate portals or juggling formats to figure out what a deposit means. However the money arrives, Topkey turns it into something matchable on your behalf.
From OTA Payout to Reservation-Level Match
The bank transaction is matched to that payout record using a payout ID, a reference code, or amount and date, depending on the channel. Each reservation inside the payout is then matched to its confirmation code, tying the dollar amount to that specific booking. Every reservation lands in one of three states, matched, partial, or unmatched. For the operator, that's the difference between a deposit being a mystery lump sum and a deposit you can trace to the exact bookings, owners, and stay dates behind it, without opening a spreadsheet. And the three states mean nothing hides in the gray area. You see at a glance what's fully accounted for, what's short, and what still needs a look, instead of assuming it all tied out and finding the gap at month-end.
What Happens to the Hard Cases
Deposits and Installment Payments
A deposit collected months before check-in is tracked as underpaid until the remaining balance arrives. It's never mistaken for a completed payment. Multiple partial payments on the same reservation, a deposit, then a balance, then a final payment, accumulate against the total automatically, with no manual tallying required. For a short-term rental property manager, that means a half-paid reservation never gets mistaken for a shortfall or double-counted as complete, no matter how many installments it takes to get there.
Refunds and Overpayments
Refunds arrive as negative payouts tied back to the original reservation, flagged as an over or underpayment instead of showing up as an unexplained shortfall. ACH returns are treated as new forward transactions rather than reversals, so the ledger keeps moving forward instead of getting unwound. Ambiguous items get the same treatment, an Airbnb Resolution Center charge, for example (for one customer these show up on 10-15% of all reservations, and the PMS doesn't help sort them out), can be included, excluded, or split right at the point of posting, instead of blocking the whole statement while someone figures it out one line item at a time. A vacation rental property manager stops burning time chasing negative numbers that don't obviously belong to anything, because every one already points back to the booking it came from.
Cancellations and Clawbacks
Airbnb will claw money back from one property's payout to cover a resolution owed on a completely different property. Some PMS platforms compound the problem by zeroing out cancelled folios entirely, leaving nothing behind to match against, and for one PM, cancelled reservations actually showed up as "revenue received." Topkey pulls payout data directly from Airbnb's API every day, capturing the actual payout-to-reservation mapping, including clawbacks like this. Cancelled reservations get marked as no payment expected instead of flagged as missing, and because reconciliation runs off actual bank transactions rather than what the PMS reports as revenue, the money trail stays visible even when the PMS goes silent. That protects the short-term rental property manager from the worst-case version of this, paying an owner on revenue that was cancelled or quietly clawed back, and only finding out after the money's gone.
Reservation Changes and Long-Dated Stays
A reservation that changes after the payout was already expected gets automatically resynced, and its status downgrades for review if the payout no longer matches what's expected. If it was already posted to a statement, removing it is a separate, deliberate step someone takes, not something that happens on its own. If a transaction arrives late for a month that's already closed, it posts automatically to the current open month as a prior-period adjustment, rather than stalling the whole close. And a stay that checks in one month but doesn't check out until months later still posts as a single line item, landing on the statement for the month it checks out, not held open before that. For a vacation rental property manager, that means a booking that shifts, arrives late, or spans months never quietly throws off a statement that already looked done.
Tax and Fee Quirks
Airbnb charges its own fee on top of tax amounts, and special offers can arrive as one unbroken amount. Topkey handles the fee-on-tax as its own negative line item ("Taxes Withheld by Airbnb") that reduces the expected payout, and lump-sum special offers reconcile at the net payout level while the original PMS breakdown stays visible on the statement. If the PMS still gets the breakdown wrong, manual line-item tools let the PM correct it. The short-term rental property manager gets a payout that reconciles to the penny without having to reverse-engineer where Airbnb's fees and discounts went.
Daily Revenue Visibility, Not a Month-End Surprise
Matched, Unmatched, Underpaid, and Overpaid, Visible Any Day
The status of every reservation updates daily, not reconstructed once a month from scratch. There can be up to a day of lag between when a deposit lands and when it gets matched, worlds apart from finding out three weeks later at month-end. Each reconciliation period shows percent complete, by reservation count and by dollar amount, so progress is visible at a glance instead of a single pass or fail state at the end. That's the real difference this makes, not finding out where you stand once a month, but watching it update day by day.
Trust Accounting That Updates as Revenue Is Matched
Once a payout is matched, funds move automatically into the correct owner's trust account, no manual ledger entry needed. When the period finalizes, the reservation posts to the owner's statement, splitting the held funds between the owner's payout and PM fees. There are two stages, match, then post, and neither one requires bridging by hand.
One Reconciliation Process, Any PMS You Run
Topkey reconciles across major PMS and payment channels, so you get the benefit without changing how you operate. Guesty, Track, Hostfully, Hostaway, Hospitable, and OwnerRez all run a regular twice-daily reservation sync straight into the matching process, full participants, not a secondary tier. Reconciliation itself pulls from both sides: your payment channels (direct Airbnb, Stripe, bank feeds) and your PMS's reservation data. Topkey connects to both, so you're covered regardless of which platforms you run.
Month-End When You Already Knew Where You Stood
What Changes for the Person Doing the Work
The bookkeeper opens the dashboard and the payouts are already matched, because the picture is updated all month instead of arriving all at once. No logging into a dozen accounts to piece together what a payout means, no guessing whether a resolution charge belongs to the PM or the owner. The two or three items that still need a human decision are flagged with a plain explanation, not buried in a spreadsheet cell waiting to be found.
What Changes at Every Scale, from 40 Units to 1,500
A 40-unit operator gets hours back, hours that used to go to logging into portals and squinting at spreadsheets. A 300-unit operator stops needing a dedicated reconciliation shift every week just to keep up with resolution charges, clawbacks, and split payments. A 1,500-unit operator finally has a team that can answer, with confidence, what's actually reconciled today, not what was reconciled three weeks ago. Owners get paid from numbers the operator already trusted, not numbers that were just finished being assembled.
A Faster Month-End Close
Owner statements draw from revenue that was already reconciled throughout the month, not chased down at the deadline. The deposits, refunds, clawbacks, and resolution charges that used to stall the whole cycle behind one unmatched line are already resolved by the time anyone opens the statement. So the month closes in hours instead of days, and not because anyone rushed or worked longer, but because most of the reconciliation happened automatically as the money came in. The short-term rental property manager just keeps an eye on it throughout the month instead of assembling it all from scratch at the deadline.
Know Where Every Dollar Stands
The point was never faster matching for its own sake. It's that a short-term rental property manager should be able to open the books on any given day and know, without a spreadsheet or a portal login, exactly what's reconciled, what's owed, and what still needs a look. Topkey turns a bank deposit into that answer automatically, so the confidence you used to earn only at month-end is just there, all month.
Schedule a demo and watch it happen with your own payouts, your own PMS, your own portfolio.
See the Topkey difference.
