The short answer: to reconcile a homestay payout, take the OTA's payout statement, match every line to a booking by confirmation code, check that the lines add up to the amount that landed in the bank, and only then record it. Done by hand this is slow and easy to get wrong. Our PMS, AntlerHub, does the matching and leaves one human click before anything is posted.
Most guides on this topic are written for US vacation-rental managers using QuickBooks. This one is written for a Malaysian operator with Airbnb, Agoda, Booking.com and a bank account that shows lines like "AIRBNB PAYMENTS" with no explanation. It describes how our own system handles it, including the parts that are less tidy than we would like.
Why is one bank credit from Airbnb so hard to match?
Because the bank sees one number and the OTA sees many bookings. As a general rule, Airbnb releases a payout around 24 hours after the scheduled check-in for stays under 28 nights, then your bank takes a few days to show it (Pass the Keys). Property-management software vendors describe the same problem: several reservations are bundled into one deposit, fees and adjustments are netted off before the money moves, and a charge on one reservation can be taken out of a different payout (VRPlatform).
Here is an invented example of what that looks like. These are not real figures, just the shape of the problem:
| Booking (confirmation code) | Net to you |
|---|---|
| Stay A | RM 1,240.50 |
| Stay B | RM 862.00 |
| Stay C | RM 1,455.90 |
| Stay D | RM 304.00 |
| Bank credit | RM 3,862.40 |
Your bank shows RM 3,862.40. Your booking list shows four stays, each with a gross price and a commission you have to work out yourself. Unless you can show which four stays make up that number, you cannot say whether any money is missing.
What does a payout statement actually contain?
It depends on the OTA, which is the second reason this is painful.
- Airbnb exports a file where a payout row is followed by the reservation rows it covers. The grouping is positional: the rows after a payout row belong to that payout.
- Agoda, Booking.com, Expedia and Ctrip/Trip.com give you a flat list, and the column names change between exports. Booking.com's payout statement and Expedia's remittance advice also arrive as PDFs.
- Dates are a trap. A date such as 07/08/2026 means 7 August to one platform and 8 July to another.
Our reader handles CSV, Excel and PDF. It finds columns by their header names rather than by position, and when a date is ambiguous it reads it the way Airbnb, Expedia and Agoda export it, then flags it instead of silently choosing. The reader never decides anything on its own: it reports what it thinks the file says, plus warnings, and a person confirms.
How do you match a statement line to a booking?
By the confirmation code first, because it is the one identifier both sides share. Our system looks the code up against the bookings already pulled in from the channel manager.
Some statements print no code. Then the fallback is guest name plus check-in date, and both must agree. If two bookings share a name and a check-in date, the line is not guessed. It is marked as unmatched with a note to link it by hand, because a wrong link quietly credits the wrong booking.
An unmatched line does not block the batch. The bank credit is real whether or not you can name every booking behind it, so the line is imported, flagged, and left findable. You can untick it if you would rather leave it out.
What if the same statement, or the same booking, shows up twice?
This happens more than people expect: you export an overlapping date range, or the OTA reissues a corrected payout under a new reference. Two protections apply.
- The transfer itself is unique. A payout is identified by the operator, the platform and the OTA's payout reference. Re-importing the same statement updates a payout that is still pending and refuses to touch one that is already posted. Where a file carries no reference (Trip.com's does not), the system builds one from the platform, the date and the amount, and checks for the same money already on the books.
- Each booking remembers which payout settled it. A line for a booking that an earlier payout already covered is labelled, so you can see it on the draft before you confirm anything.
There is one honest wrinkle. Airbnb sometimes pays a long stay in instalments across two transfers. That is legitimate, so the second instalment is still counted, but it is labelled "paid earlier" so you can tell an instalment from a duplicate. Airbnb can also list the room and a pass-through tax as separate lines inside one transfer, so the lines are added up per booking before the booking is recorded.
Which bookings are in scope?
Only the ones you tell the system to start from. Each operator has a go-live check-in date. Bookings that check in on or after it are matched, locked, and counted as money the OTA still owes you. A stay that checked in before it is still shown and recorded, but it gets no booking link and no lock.
The reason is a boundary problem. A stay that straddles the go-live date is partly old books and partly new books, and there is no agreed accounting treatment for the split. We chose to refuse the link rather than invent a rule. A new workspace defaults to the day it starts, and you can change it on the settlement screen.
What gets posted to the books?
The money that actually arrived. The entry is: debit the bank, credit a platform collection account. When the statement states the OTA's commission separately, the commission is posted as an expense and the bank line is the net.
A caveat that matters to accountants: we do not raise a receivable per reservation saying "Airbnb owes us RM X" at booking time. The OTA invoices the guest, keeps its cut and pays you net, so the only figure we can state without inventing one is what landed. If your accountant wants gross invoices per booking, that is a different design from ours.
Two practical points:
- Posting goes to Bukku, so a connected Bukku account and a mapped bank account are required. Without them the payout stays pending with an error you can read.
- Each money-in carries an OTA tag and a spreadsheet of the bookings it covers, so a year later "RM 3,862.40 from Airbnb" still answers the question "which stays?".
Agoda has one more limitation. A single Agoda payout file mixes Agoda Homes and Agoda YCS bookings with nothing to tell them apart, so settlement treats it as one "Agoda". Trip.com and Ctrip are likewise one group.
Why a draft and a confirm step, not full automation?
Because a statement file is a human artefact. People drag in the wrong tab, the wrong month, or the same file twice. So a parse produces a draft batch that you see and confirm. Only Confirm writes the payouts and journals.
Confirm returns immediately and a background job does the posting, one accounting round trip per payout. A statement can hold hundreds, and a browser tab should not be what stands between you and complete books. If the server restarts mid-run, the unposted payouts simply stay pending, and a retry job picks up anything pending or failed.
What can still go wrong?
- The file layout changes. OTAs rename columns. The reader copes with synonyms, but a genuinely new layout means a warning and a manual fix.
- A payout date is missing, usually from a PDF. You set the date the money arrived before it will post.
- The bank credit does not equal the statement. That is the point of the exercise, but it means a person has to chase the difference with the OTA.
- Bookings with no price in the system cannot be counted as money still owed. They show up in a separate count so you can fix them.
A practical routine
- Download the statement from each OTA once a week, or after each big payout.
- Upload it and read the draft: unmatched lines first, then anything labelled paid earlier or out of scope.
- Compare the draft total with the bank credit.
- Confirm. Look at the pending-settlement overview a few days later to see what each OTA still owes.
If you run 10 or more units and still do this in a spreadsheet, see our PMS vs Excel comparison, and for what happens after the money is matched, how the monthly owner statement is built. If you want this running on your own units, the AntlerHub page and its pricing are at /antlerhub.
This article describes how our software records figures. It is not accounting or tax advice; confirm how your company books OTA income and commission with your own accountant.