Every reservation is run through a fixed set of data quality checks whenever it's calculated or recalculated. None of these checks ever block or alter the underlying booking data — they only ever raise a flag for a human to look at, and, for the more serious ones, mark the reservation as requiring review before a return can be treated as ready. This guide catalogues what each check actually looks for.
The checks, and what triggers each one
| Check | Severity | What it catches |
|---|---|---|
checkout_before_checkin | Error | Check-out date isn't after check-in — an impossible stay. |
zero_or_negative_amount | Error | Accommodation amount is zero or negative. |
nights_mismatch | Warning | The recorded number of nights doesn't match the actual gap between check-in and check-out. |
suspicious_nightly_rate | Warning | The per-night rate falls outside a plausible range — by default, below £1 or above £2,000 a night. |
wrong_currency | Warning | The reservation's currency doesn't match the property's configured default currency. |
net_vs_gross_confusion | Warning | Accommodation + VAT + cleaning + extras doesn't add up to the recorded gross amount, within a small tolerance. |
vat_inconsistency | Warning | The property is VAT-registered but the reservation has no VAT amount recorded. |
overlapping_duplicate | Warning | Another reservation for the same property has overlapping check-in/check-out dates. |
unexplained_rate_change | Warning | The nightly rate deviates sharply — by default, more than 3x in either direction — from the property's recent trailing average. |
missing_booking_date | Info | No booking date recorded at all. |
scheme_boundary_crossing | Info | The stay spans a change between two scheme versions somewhere between check-in and check-out. |
cutoff_boundary | Info | The booking date falls close to the scheme's booking cutoff date — by default, within 14 days. |
Only error-severity flags — checkout_before_checkin and zero_or_negative_amount — automatically mark a reservation as requiring review. warning and info flags don't block anything on their own, but they do surface in the Return Readiness data_quality_warnings check, which is worth clearing before treating a period as genuinely ready.
The two mistakes that matter most in practice
Net-vs-gross confusion (net_vs_gross_confusion, and closely related to the wrong_currency and platform-specific gross-vs-payout issues covered in the Airbnb and Booking.com guides) is the single most consequential category of error, because it changes the levy figure itself rather than just flagging a data-hygiene issue. If your accommodation, VAT, cleaning and extras figures don't reconcile to the total you'd expect, something in the mapping or manual entry likely used a net or bundled figure where a gross, itemised one was needed.
Duplicate bookings (overlapping_duplicate) matter because a genuinely duplicated reservation doubles the levy liability shown for a period that never actually happened twice — easy to introduce with a re-import of the same file, or manual entry alongside an existing import.
How a flag actually gets resolved
A data quality flag has three possible states: open, resolved, or dismissed. Resolving one requires a human decision, recorded with an optional note explaining the resolution — there's no bulk "dismiss all" shortcut, and a flag that's genuinely been resolved or dismissed is never silently reopened by a later recalculation of the same condition; only a check that's stopped triggering entirely is cleared automatically. If the underlying condition is still true the next time the reservation is recalculated, the flag stays.
Correcting a calculation itself
Two distinct mechanisms exist depending on what actually needs fixing:
- Fix the underlying data and recalculate. If a date, amount or currency was simply entered or mapped wrong, correct it and recalculate the reservation — this produces a new calculation version (see Record-keeping), with the previous, incorrect calculation preserved in the history rather than erased.
- Manually adjust the figure itself. If the calculated amount is correct given the data but needs a deliberate override — a negotiated arrangement, a genuine one-off exception — the estimated net amount due can be manually adjusted, with a required reason. This is a different action from fixing the data: it doesn't happen if the reservation currently requires review, and it leaves its own dedicated audit trail separate from a routine recalculation.
The habit worth building
Don't wait until you're preparing a return to look at data quality flags. Checking them as bookings come in — particularly after any bulk import — catches the kind of error that's cheap to fix on one booking and expensive to untangle across a whole quarter's worth of them.