A guest emails asking about the second week of October. Before you can answer, you open the Airbnb calendar, then the Booking.com extranet, then the spreadsheet or inbox where your direct bookings live. Three tabs, three logins, and at the end you still aren't fully sure, because one of them might not have refreshed yet.
That's the real job a master calendar has to do: answer "is this unit actually available?" in one look, and be right. Start by deciding which system is allowed to be the answer. The fields, rules, and daily routine below follow from that one decision.
What should a master reservation calendar actually show?
A trustworthy master calendar shows every reservation per unit with its source, dates, status, payment state, and the time each channel last synced, so you can trust it without opening an extranet.
Most calendars stop at coloured blocks on dates. That works until two blocks overlap, or a block turns out to be an owner stay, or a cancelled booking is still sitting there. Then you're back in the extranets.
Here's the minimum each entry needs. If your current setup can't show a field, write down where you'd have to go to find it. That list is your daily tab count.
| Field | Why you need it | Where it comes from |
|---|---|---|
| Unit | Stops bookings landing on the wrong room | Your own unit list |
| Source | Tells you which platform owns changes | Channel or "direct" |
| Channel reservation ID | Matches the entry to the extranet record | The OTA or your own numbering |
| Guest name | Links the dates to a real conversation | Reservation record, not iCal |
| Check-in and check-out | The dates you're selling | Reservation record or feed |
| Status | Separates confirmed, pending, cancelled | Source platform |
| Payment state | Flags unpaid direct bookings | Payment provider or OTA |
| Last sync time | Tells you how stale the view is | The tool doing the sync |
| Conflict flag | Surfaces two stays on one unit | Calculated by the calendar |
Two of those rows do most of the work. The reservation ID keeps you from treating a modified booking as a new one. The last-sync time tells you whether "free" means free, or free as of three hours ago.
Why isn't overlaying Google Calendars the same as managing inventory?
An overlay displays copies of each channel's availability, but it can't tell a reservation from a blocked night, can't write back to any channel, and refreshes on someone else's schedule.
Subscribing to each channel's iCal export in one personal calendar is the usual first attempt. It looks like a master calendar. Here's what it misses.
It mixes bookings and blocks. Airbnb's calendar sync page says its export includes nights blocked for "availability settings, preparation time, advance notice, and minimum stays," as well as booked nights. In a plain overlay, a prep-time block and a paying guest can look identical.
It isn't the inventory. Blocking a date in your personal calendar closes nothing on Airbnb or Booking.com. The channels only read each other's feeds, and Booking.com's partner guide states it currently has no sync option for Google Calendar at all.
It's slow by design. Airbnb says it updates imported calendars every 3 hours, with a manual Refresh it can only request so many times. Booking.com says updates can take up to two hours and that sync "doesn't happen in real time." Your overlay then adds its own refresh delay on top.
We infer the practical result from those documented intervals: an overlay is fine for glancing at the week, but it shouldn't be what you check before confirming a direct booking.
Which system is the source of truth for each reservation?
The platform where the guest booked owns that reservation; your master calendar mirrors it, and you make changes at the source, never only in the mirror.
This rule sounds obvious. Most calendar mess comes from breaking it. Someone shortens a stay in the master calendar, but the Airbnb reservation still runs to the original date, and the next sync puts the old dates back.
Use four rules:
- Airbnb and Booking.com bookings: change dates, cancel, or refund only in that platform. Let the change flow into the master calendar.
- Direct bookings: your booking system is the source. It creates the record, and every OTA receives it as a blocked period.
- Owner stays and maintenance: create them in one place only, the master calendar or the tool feeding it, so every channel receives one block.
- Manual blocks during an emergency: allowed anywhere, but note them and remove them once the real reservation appears on its own.
Cancellations deserve extra care. In the iCalendar standard, RFC 5545, an event can carry a STATUS of CANCELLED, and every event needs a unique UID so readers can match later changes to the original. Channels differ in how they publish a cancellation: some mark it, some simply drop the event. Airbnb also notes that nights blocked on another calendar "may or may not" be blocked on Airbnb. So after any cancellation, open the unit on each channel and confirm the dates reopened where they should, and stayed closed where they shouldn't.
How does the daily workflow change from one unit to five?
With one unit, you can check a single calendar each morning; at five units, you need fixed rules, conflict flags, and a sync-time check, because manual scanning stops catching overlaps.
The comparison below is a worked example, not a benchmark. Consider a host with one apartment on Airbnb plus direct bookings, and a host with five units across Airbnb, Booking.com, and direct.
| Task | One unit, two sources | Five units, three sources |
|---|---|---|
| Morning check | Scan one calendar | Scan by unit, then by conflict flag |
| Before confirming direct | Look at the one date range | Check sync time, then the unit row |
| Cancellation | Confirm on one channel | Confirm on every channel for that unit |
| Owner stay | Block once, check feed | Block once in master, verify each channel |
| Weekly audit | Optional | Match reservation IDs against each extranet |
The shift isn't the number of bookings. It's the number of places a single change has to arrive. One unit on two sources means two places. Five units on three sources means fifteen unit-and-channel pairs where a missed update can hide.
When this advice does not apply
If every channel connects to your system through a two-way API integration instead of iCal, reservations arrive as full records with guest and payment details, and several steps above shrink. The source-of-truth rules still hold. See channel manager vs PMS for where those roles split.
If you rent rooms inside one property as separate units, overlapping stays on the property are normal. The conflict check has to run per room, not per building.
And if you only sell on one platform, that platform's own calendar already is your master calendar. Adding another layer adds a place to be wrong.
What to do next
- List every place a reservation can be created for each unit, including your inbox and phone.
- Fill in the field table above for your current setup and mark every field you can't see.
- Write your four source-of-truth rules down and share them with anyone who edits calendars.
- After your next cancellation, check every channel for that unit and note how long the dates took to reopen.
- If you sell on three or more channels, read our multi-channel distribution guide and how to avoid double bookings before adding another.
FAQ
Can I share a master calendar with my cleaner?
Yes, but share a read-only view that shows check-in and check-out per unit. Cleaners don't need guest payment state, and they shouldn't be able to move a booking.
Should direct bookings be entered on Airbnb and Booking.com by hand?
Only if nothing syncs them. If your direct booking system publishes a feed or connects to the channels, let it block the dates, so there's one record instead of three.
How often should I compare the master calendar against each extranet?
At multiple units, a weekly check of reservation IDs per channel catches drift that daily glances miss. At one unit, a quick look after each cancellation is usually enough.
About BookBed: BookBed shows Airbnb, Booking.com, and direct bookings for all your units in one multi-unit calendar, so the daily availability check happens in one place. Changes to OTA reservations still happen in each OTA, and the plan you need depends on your unit count. See BookBed pricing
Sources
- Airbnb Help Center, "Sync your home host calendar to other websites" — Verified 2026-09-27
- Booking.com for Partners, "How to synchronize your calendars across channels" — Verified 2026-09-27
- IETF, RFC 5545 "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", UID and STATUS properties — Verified 2026-09-27
- BookBed, product capabilities and plan unit limits at /pricing and /llms-full.txt — Verified 2026-09-27