The Export That Disappeared: Rebuilding a Per-Booking Ledger

Platform exports expire, get deprecated, or simply stop including a column you relied on. A ledger built from the booking record survives that.

Last updated: October 19, 2026

The file you downloaded in January opens fine in March. By June, two columns are empty. By September, the report doesn't exist in the menu anymore. Nothing about your business changed that day — only the evidence did. A per-booking ledger fixes that, because it's built from the booking record while the booking is still there, one row at a time.

Key Takeaways

• An export isn't a record. It's a snapshot of a report designed to answer a question someone else chose.
• The booking is the durable unit. A row copied while the booking is open survives every change to the report around it.
• Fifteen columns cover a year. Dates, price, fee, tax, turnover cost and payout answer almost every question later.
• Reconcile monthly, not annually. Timing differences are easy in January and impossible in April.
• Never edit a source figure to force a match. Mark the row and come back to it; a tidy ledger that lies is worse than a messy one that doesn't.

What the export actually held

An export answers the question the report was built for. Usually that's a simple one: what was paid out in this period.

So it carries the payout, the period and a few identifiers. It drops what you need a year later. The guest count. The nights. The rate the guest actually saw, before any fee. The discount you gave to close a gap in the calendar. The cleaning bill that the stay triggered. The reason a Tuesday in March sold at a weekend rate.

Three failures show up most often.

The export expires. Platforms keep reports for a window, and the window is shorter than your memory of the year. The file you didn't download is gone, and the record behind it may be too.

The shape changes. A fee structure changes, a column gets renamed, a tax line splits in two. Your saved file and this year's file no longer line up, and the formula you built last year returns an error instead of a number.

The period splits a stay. A booking that checks in on the 28th and out on the 3rd lands in two reports, or in one, depending on which date the report uses. Either way, neither file shows the whole booking.

None of this is anyone's fault. It's what happens when a business keeps its evidence in someone else's report format.

Rebuilding from the booking record

Start with the unit, not the month. One booking, one row.

Fifteen columns will carry you through a year of questions:

1. Booking reference
2. Channel
3. Date booked
4. Check-in date
5. Check-out date
6. Nights
7. Guests
8. Source price, before the platform fee
9. Platform fee, as an amount
10. Tax collected and remitted
11. Cleaning cost for that turnover
12. Supplies
13. Discount you granted
14. Net payout
15. Payout date and statement reference

Add a sixteenth if you want it: a short note. Why the rate moved, what broke, which guest extended. That column is the one you'll read in two years and thank yourself for.

Five rules keep the file usable. One row per booking, never one row per night. One file per year, named by the year. Dates in ISO form, so sorting works. Numbers stored as numbers, not text. And source price and net payout in separate columns, with the difference computed by a formula rather than typed in. When the fee line moves, the formula shows it without you rewriting history.

Backfill in three sittings, newest first. Take the current quarter while the bookings are still open and the details are still in your head. Then the two quarters before it. A year of rows takes about four hours if you don't stop to fix the past.

Where the record and the report disagree, the record wins. It carries the guest count and the dates; the report carries a total. You're rebuilding the detail the total was made from.

Reconciling against payouts

The ledger is the booking-side truth. The payout statement is the bank-side truth. Once a month, put them next to each other.

Match on three things at once: the payout date, the amount and the reference. One of the three will usually disagree, and the disagreement tells you what kind of problem you have.

Timing. A stay checks out on the 28th and the payout lands on the 3rd. The month totals differ by that booking. Nothing is wrong, and nothing should be adjusted. Mark the row as timing and let next month's statement close it.

Currency. The platform converts at settlement. Your ledger holds the amount in the currency the guest paid; the statement holds what arrived. Keep both columns. Rebuilding a historical rate six months later is guesswork, and a guess in a ledger becomes a fact you can't defend.

Structure. The fee line changed mid-year, so two bookings from the same month carry different deductions. A single fee percentage column would hide exactly the change you need to see. Keep the amount, and keep the rate as a note if you want it.

The rule that matters: never overwrite a source figure to make a match. Add a status column — matched, timing, unmatched — and leave the number alone. An unmatched row after two cycles is worth a message to the channel. A row edited to fit is worth nothing at all.

Then check the month against a second source. LOCALSBNB's Home dashboard shows occupancy, average daily rate and revenue per available room per property. That's enough to catch a ledger with missing rows. If the dashboard says 214 nights sold and your rows add up to 188, you have a gap, not a rounding error.

A ledger you own

Ownership is a storage decision before it's a software decision.

Put the file in a folder you control, one file per year. Save a read-only copy at the end of each month — a PDF or a plain CSV — so a broken formula can't destroy the year. Keep one backup somewhere else, and test that it opens.

Name things plainly. ledger-2026.xlsx beats Bookings final v7 (2).xlsx every time, and it's the difference between finding a row in ten seconds and rebuilding a quarter.

If a co-host keeps the books, hand over the file and a monthly read-only copy, not your account. The ledger is the thing you need to be able to produce; access to every channel is a separate question.

What the file buys you is boring and valuable. A tax pack assembled in an afternoon. A dispute file that shows what was promised, what was charged and what was paid, in the order it happened. And pricing evidence: which channel's bookings actually cleared their turnover cost, rather than which channel looked busiest.

When a booking's rate looks wrong, go back to the source before you touch the row. LOCALSBNB's calendar shows each connected channel's source price and status beside the dates, so localsbnb.com is where you can tell whether the rate was set that way or changed after the fact.

FAQ

How far back should I rebuild?

As far as the platform still shows individual bookings. Twelve months is enough for most hosts; twenty-four is better if you've changed fee structures. Older than that, rebuild from payout statements and your own messages, and mark those rows as reconstructed.

Do I need all fifteen columns?

No. Start with six: reference, dates, channel, source price, fee and net payout. Those answer most questions. Add the rest the first time a question needs them, and you'll add them in the order they matter to your business.

What if a booking record is already gone?

Use the payout statement line and mark the row as reconstructed. Leave the fields you can't verify empty rather than guessing. An empty cell is a known gap; an invented number is a false record.

The habit costs one afternoon to start and about twenty minutes a month to keep. Pick the last quarter, copy fifteen rows, and let the file grow backwards from there. You can set the property and its channels up at localsbnb.com, and keep the ledger wherever you'll actually open it.

---

This is general guidance for hosts, not legal, tax or insurance advice. Reporting requirements, retention periods and platform terms differ by market and change over time, so check the current rules where you operate and the statements issued to you.