Booking.com works differently from Airbnb commercially — commission is deducted from what the property receives rather than charged to the guest as a separate service fee — but the underlying levy question is the same: what's the actual gross accommodation charge the guest was billed, before anything is taken out?
Gross accommodation charge, not the commission-adjusted figure
Booking.com properties are typically paid the room charge minus Booking.com's commission, rather than the guest paying a visible platform fee on top. That means the figure a property "receives" from a Booking.com reservation is already net of commission — and, just as with an Airbnb net payout, that's the wrong figure to use as accommodation_amount. The levy is due on what the guest was actually charged for the accommodation, not on what you were left with after commission. If your Booking.com export or extranet report only exposes a post-commission figure for a given booking, that needs to be grossed back up (or you'll need the guest-charged total from elsewhere) before it goes into the levy calculation — we're deliberately not asserting a specific column name or report layout here, since Booking.com's extranet reporting can vary by property type and account setup; check what each column in your specific export actually represents before mapping it.
CSV/XLSX import only — no live API sync
As with Airbnb, there is no live Booking.com API connection in this product. The only way Booking.com booking data reaches your account is by exporting a CSV or XLSX file from your Booking.com extranet and importing it — either through the standard in-browser import flow, or the legacy bulk-upload path. BookingSource detection can label an import as booking_com based on recognising its header pattern, but that's purely a formatting heuristic applied to a file you've exported and uploaded yourself, not any kind of live integration or automatic sync with your Booking.com account. There's no OAuth "connect your account" flow, and none is planned within the current product as built.
The same fee rules apply
Whatever platform a booking came from, platform/commission fees and genuinely optional extras are excluded from the accommodation figure — but a mandatory cleaning or changeover charge can still form part of the levy base, and the engine needs to be able to tell which applies (see Cleaning fees and the Visitor Levy). If your Booking.com export breaks out a cleaning fee or service charge as a separate line, map it to the corresponding canonical field rather than folding it into accommodation_amount, so it can be classified rather than defaulting to a review flag.
No guest data, regardless of source
Booking.com exports commonly include guest names and contact details. As with every other import source, there's no field in our data model to receive that information — a column that looks like a guest name or contact detail simply has no canonical target it can be mapped to, and its contents are discarded rather than stored, whichever platform the export came from.
Practical checklist for a Booking.com import
- Confirm the accommodation figure you're mapping is the guest-charged gross amount, not a post-commission net figure.
- Map any separately itemised cleaning fee or service charge to its own canonical field rather than the accommodation total.
- Double-check currency — Booking.com properties sometimes display figures in a currency other than the one the booking was actually made in.
- Leave any guest-identifying columns unmapped.
- Run Return Readiness after import to catch anything flagged for review before treating the period as complete.