Group Bookings Across Two Units: How to Split One Reservation Cleanly
Two units and one group reads like a calendar problem and behaves like an accounting one: one payment arrives, two lots of inventory are consumed, and nobody can later say which door earned what. Three decisions settle it — which unit owns the booking, where the charge sits, and what the guest is told. This guide walks each one, including why splitting the charge across two reservations usually costs more than keeping it on one.
Two doors, one group, one payment. The split is an internal decision — the moment the guest can see it, it becomes a problem.
Last updated: September 22, 2026
A group that needs two units is the most profitable booking most small hosts get, and the one they account for worst. It arrives as one request and one payment, and it consumes two lots of inventory, which means the money trail and the inventory trail stop matching on day one. Most hosts handle it by copying the block onto the second calendar and sorting the rest out later — and the rest out never happens, because nobody can afterwards say which door earned what, who cancelled, or what a partial refund should be. This guide runs through the three decisions that prevent that: which unit owns the reservation, where the charge actually sits, and what the guest is told so that two doors read as one stay.
Key Takeaways
- Accounts before calendars. Copying the block second and accounting for it later is how reconciliation breaks.
- One unit owns it. One booking reference carries the payment, the guest count and the cancellation terms.
- The other is only blocked. A held unit should not carry a second set of terms anybody can argue about.
- Two files cost more. Whatever a channel deducts is applied per booking; splitting means being charged twice for one group.
- The guest sees one stay. One meeting point, one key sequence, one contact — never two sets of house rules.
First an accounting problem, then a calendar one
The mistake is not technical, it is about order. A group booking feels like calendar work: somebody wants both units, so you block both. But one cash inflow has just bought two inventory events, and nothing there tells you how to account for it next month, or how to absorb a change halfway through.
Three problems arrive directly out of that order:
- Attribution. One payment has to be split across two units. If no rule was written at the time, it is split by whoever is doing the books and whatever felt fair that afternoon.
- Partial changes. One couple leaves early, one family extends a night. Where the booking exists once that is a modification; where it exists twice it is two changes and possibly two cancellations.
- Cancellation arithmetic. A fee expressed as a share of one booking and one per booking produce very different numbers when only part of the group leaves.
None of this is caused by the guest. It is caused by the split being decided twice — once badly at the time of booking, then again in your accounts — instead of once, deliberately, and written down.
| Held properly: one booking, one held unit | Held twice: two bookings for one group |
|---|---|
| One payment, one set of terms, one cancellation date | Two sets of terms that can disagree about the same group |
| One unit can be released without touching the other | Releasing one half can cancel the other by accident |
| Attribution of income is a decision you made once | Attribution is decided monthly, by whoever is doing it |
| Guest has one contact and one plan | Guest has two check-ins and two sets of instructions |
Notice what is missing from that table: nothing about which unit is nicer. Those are guest questions. The three decisions below are operational, and no tool decides them for you — least of all which door owns the money.
Decision one: which unit owns the booking, and which is only blocked
Every pair of units has an asymmetry — one sleeps more, one re-sells faster at short notice. Choose the owner deliberately rather than defaulting to whichever unit was asked for first.
The owning unit carries four things: the booking reference and channel, the payment, the cancellation terms, and the guest count as far as the platform is concerned. Everything else about the group — how many are in the second apartment, which door they were given — lives in your own note on that one booking.
The second unit is not booked. It is blocked, with a reason written on it: "held for group <reference>". That single line is what stops the unit being sold from under them, and stops you later wondering why a week earned nothing. If you want that second unit visibly unavailable on the channels, block it rather than inventing a guest for it, because an invented guest brings an invented set of terms and an invented cancellation date.
Pick the owner with three questions, in order: which unit can least afford to be wrongly marked occupied afterwards; which is hardest to re-sell if the group shrinks; which carries the space the group will gather in. They map to your books, your cash and the night itself.
Decision two: where the charge sits, and why splitting usually costs more
The default is that the whole group pays through the owning unit, including nights spent in the second. Depart from it only if somebody genuinely needs two invoices; "my accountant prefers it" is not that.
There is a hard reason for the default. Channels process per booking, so their own charges land on each reservation individually and one group recorded twice carries that structure twice — verify this against the current terms of the channel taking the money. The mechanism rather than the amount is what catches hosts out, and the cost comes out of the stay you were pleased to win.
| What happens | Whole group on one booking | Split across two bookings |
|---|---|---|
| Channel processing | Applied once | Applied per booking, so twice |
| Cleaning | Charged once for two units, whatever your own rate is | Charged twice, which is either double recovery or an argument |
| Partial change | One modification | Two changes and possibly two cancellations |
| Refund arithmetic | One percentage of one number | Two percentages of two numbers, rarely the same amount |
| What the guest sees | One price for the whole group | Two prices and a reason to shop around separately |
Where separate invoices are truly needed — a company paying for two teams, families settling up — keep the split on paper and single where you can: one channel booking, the internal split documented against that reference, one note recording who paid what. Two files can disagree, and two files will.
Availability and rates for Airbnb, Booking.com, Agoda and Trip.com sit on one grid at localsbnb.com, so blocking the second unit across every channel at once is one action rather than four.
Decision three: what the guest hears, so two doors read as one stay
This is where good operators separate from busy ones, and it costs about fifteen minutes.
Write one arrival message covering both doors as a single plan: one meeting point, one key sequence, one contact number, one line about luggage, one set of quiet hours. Nothing in it should hint that the group spans two reservations. Answer honestly if asked about invoices, but do not volunteer an internal structure nobody needs.
Three details decide whether the night goes well. Name the units the way the group will — "the apartment" and "the annex", not A and B. Decide before arrival which door gets the cot, the extra towels and the parking space. And name one person responsible for both doors that night, because two entries produce double the questions and those need one answer point.
The practical test is simple. Read your arrival message as though you have never seen the building and ask whether it describes one stay or two transactions. Then check the next morning that both units appear where they should in your own view of the day — LOCALSBNB connects Claude, ChatGPT and Cursor to your property data, so one question returns today's arrivals, in-house guests and tomorrow's departures across both units, read-only, in the language your property runs in.
Keeping one calendar honest across four channels is the part worth handing to a system rather than to your memory, and that is exactly what localsbnb.com is for when a group wants the building next door as well.
FAQ
Can I just take both units as two bookings for the same dates?
You can, and it is worth knowing what that buys and costs. Two files mean two sets of terms, two assessments by the channel, and the possibility of releasing one half without noticing it affects the other. One booking plus one blocked unit is usually cleaner unless separate invoices are genuinely required.
Which unit should carry the payment?
The one you would least like to misattribute afterwards, and the one hardest to re-sell if the group shrinks. Decide it once with a rule — those two questions in that order — rather than per booking, so nobody has to remember why any particular choice was made.
Do I tell the guest their group spans two listings?
Tell them what they need, which is a door and a key sequence, not an inventory structure. If they ask about invoices or pricing split between families, answer plainly. Volunteering the mechanism before they ask solves nothing and introduces two prices into one conversation.
A group across two units is the same problem twice over: agree who owns it before you block anything, keep the charge on one file unless somebody has asked for two, and write one message in which the group never suspects it crossed a boundary. Do those three and the hardest booking becomes the easiest one on your calendar — starting with one grid that shows all four channels inside LOCALSBNB.
Channel terms for multi-unit bookings, modifications and cancellation are set by each platform and change; check the terms in force for the booking you are handling. Nothing here assumes a particular fee structure or amount.
ตรวจสอบโดย
ทีมบรรณาธิการ Localsbnb