Every Booking You Already Have, In One Place

The real reason people don’t switch

Ask a host why they haven’t moved their bookings somewhere better and you’ll rarely hear “the software isn’t good enough”. You’ll hear something much more practical: I have two years of bookings in a spreadsheet, a calendar feed from a channel, and eleven reservations already confirmed for next season. I can’t start from an empty screen.

That’s a completely reasonable objection, and for most of Airflow’s life we didn’t have a good answer to it. You could forward booking emails and watch new bookings appear — which is lovely for the future and useless for the past. If you put a booking widget on your website before Airflow knew what dates were already sold, you’d double-book yourself on day one.

So we built the other half. There are now three ways to get what you already have into Airflow, and they’re designed to be used together rather than instead of each other.

Door one: the calendar you already publish

If your bookings live on a channel or a shared calendar, that system almost certainly publishes an iCal feed. Paste the URL into Airflow and it pulls it hourly.

Every event in that feed gets sorted into one of three outcomes:

Outcome	What it means	What Airflow does
Matched	The external event lines up with a booking Airflow already has	Links the two, shows it as reconciled. No duplicate.
Unmatched	The dates are sold and Airflow knew nothing about it	Blocks the dates immediately, and raises a “needs details” item
Vanished	A previously-imported event is gone from the feed	The upstream booking was cancelled, so the block is removed

The ordering matters more than it looks. Protection is instant; the detail catches up afterwards. The moment a feed is connected, every sold date is blocked, even though Airflow doesn’t yet know the guest’s name or what they paid. You can put a booking widget on your website that same afternoon without holding your breath.

One thing worth knowing before you connect: feeds are not equally generous. When we tested three live feeds side by side, the differences were stark. One channel’s reservations carried a reservation reference, which meant every single one of them matched an existing Airflow booking exactly — not fuzzily, not by date-guessing, but deterministically, and it stays matched even when the guest changes their dates. Another channel’s feed said nothing but “not available” on every event, with no reference, no guest and no distinction between a booking and a manual block. For that one, the review queue isn’t an edge case — it’s the whole path.

And if you’ve pointed Airflow at a Google Calendar that returns nothing, the usual cause is sharing: a calendar that isn’t set to show all event details publicly returns an empty file rather than an error. It looks like it worked. It didn’t.

We’ve written before about why iCal sync keeps breaking — this is the inbound half of that story.

Door two: the spreadsheet

A calendar feed knows the dates. Your spreadsheet knows the guest, the money and the note about the late arrival. So Airflow takes that too — a CSV or a Google Sheet, mapped to columns and imported in bulk.

Here’s the part we want to be straight about, because it’s the design decision the whole feature rests on:

Every imported row becomes an availability block. Nothing becomes a booking without a deliberate, separate step.

That isn’t fussiness. Consider what happens if it worked the other way. Import 200 historical stays straight into your bookings, and if you have accounting software connected, the job that raises draft invoices for uninvoiced bookings picks all 200 up within fifteen minutes and dates them today — for stays that happened years ago. A block does none of that. A block creates no booking, no draft invoice, no guest email, and costs no credits. It protects your calendar and nothing else, which is exactly what you want on the way in.

Turning those blocks into real bookings and real invoices is then something you choose, preview and do on purpose.

The bug that would have quietly ruined your calendar

The single most dangerous thing in a spreadsheet of bookings is the date format. 05/01/2026 is the 5th of January to most of the world and the 1st of May in the United States. Guess wrong and nothing errors — you simply block the wrong week, in the wrong month, silently.

So Airflow decides date order per column, never per row, using evidence from the whole file. If any row has a first component above 12, the column is day-first. If any row has a second component above 12, it’s month-first. If both appear, the file contradicts itself and gets flagged. And if neither appears anywhere in the file — every value works both ways — Airflow refuses every row and asks you, rather than picking one and hoping.

We built a dry-run harness before any of this could write to a real account, ran it against a genuine 23-booking ledger, and it found three faults in itself before production ever saw it. The best one: duplicate rows were being double-counted in the income total, showing USD 16,174 where the truth was 14,194. That’s the kind of number a host would have quoted to their accountant.

A later live test against a deliberately messy 12-row owner’s log gave: 2 blocks to create, 7 past records, 1 duplicate, 3 skipped, 2 needing more information — and it correctly flagged one row as “already in Airflow, likely the same booking”, caught an overlap between two rows in the same file, and refused a row whose checkout was before its check-in. The undo put the account back to exactly its previous state.

Honest status: the import, the column mapping, the matching and the portal screens are live. What hasn’t happened yet is a real host running a real, genuinely messy file of their own through it. If you’re that host, we’d like to hear how it goes.

Door three: you type it in

Some bookings aren’t in a feed or a file. Someone phoned. Someone messaged you on WhatsApp. A returning guest asked for the same week as last year.

So an admin can now build the same booking a guest would build at checkout — guest details, dates, number of adults and children, currency, the accommodation total, extras priced exactly the way the public checkout prices them, special requests, an agent fee, and a payment route — and send it to the guest as an offer they confirm by paying.

The status isn’t something you pick from a dropdown and hope is right. It’s derived: pending until a payment is recorded, confirmed outright if it’s a comp stay or pay-on-arrival. You can set an expiry — 24 hours, 48, 72, a week, or never — and a lapsed offer is cancelled rather than deleted, so you can still see it.

This one existed in a broken form for a while, and the failure was instructive. A housekeeping job deleted every pending, unpaid direct booking older than thirty minutes. That rule was written for anonymous website checkouts abandoned mid-payment, which is sensible. But a host’s offer is unpaid by design while the guest thinks about it — so every offer the portal ever created was destroyed half an hour after it was made, along with its payment schedule. It now only sweeps what it was meant to sweep.

Extras work on channel bookings too. If a booking came in from a channel that already collected the money, adding an airport transfer afterwards bills the guest for the transfer only — never for the stay the channel already took. There’s more on that in Sell the Airport Pickup at Checkout.

The three doors are one system

The point isn’t that there are three importers. It’s that they know about each other.

A calendar feed knows the dates and keeps them live. A spreadsheet knows the guest and the money. They are not competitors — whichever arrives first creates the block, and later evidence links to the same block rather than creating a second one over the same week. Without that, a feed event arriving after a spreadsheet import would create a duplicate block over the same dates, hourly, forever.

So a realistic first hour looks like this:

1. Connect your feeds. Every sold date is blocked within the hour. You are now safe to publish.
2. Import your spreadsheet. The guests and the money attach to the dates you already blocked.
3. Add the ones that live in your head. Phone bookings, WhatsApp bookings, the regular who always takes the first week of March.
4. Then decide what becomes a real booking with a real invoice, deliberately, in your own time.

You don’t start from zero, and you don’t have to be brave about it either.

What this doesn’t do yet

Two things we’d rather tell you than have you discover:

• The onboarding flow doesn’t yet walk a brand-new account through connecting a feed as step one. You can do all of this today, but you have to go and find it rather than being led there.
• Bulk import hasn’t yet been exercised by a human against a real, messy file — only by us, against test files and one real ledger. It’s careful software, but it isn’t battle-worn software.

Everything else above is live.

If your accounting software is already connected, read How to Import Your Airbnb Booking History into Xero before you import anything — it covers which historical bookings should become invoices and which should be left alone.

If you’re weighing up whether to move at all, The 20-Minute Problem makes the case for what all this manual handling actually costs you, and Managing Bookings from Five Platforms covers what it looks like once everything’s in one place. Or just get started and bring your calendar with you.