Good record-keeping for a levy you're responsible for accounting to a council matters as much as getting the arithmetic right in the first place — if a figure is ever questioned, you need to be able to show how it was reached and whether anything changed since. Our product has two mechanisms built specifically for this: calculation versioning and the audit log.
Calculations are versioned, never overwritten
Every time a reservation's levy is calculated or recalculated, the result gets a version number that increases monotonically — the previous calculation isn't deleted or overwritten, it's superseded. If a property's jurisdiction gets corrected, a scheme gets re-verified, or a booking's dates get fixed and the levy is recalculated as a result, the earlier calculation stays in the history rather than silently vanishing. This matters because it means you can always answer "what did we think this booking owed at the time we filed, versus what we think now, and why did it change" — which is exactly the kind of question that comes up if a return is ever queried after the fact.
Manual adjustments leave their own trail
Sometimes a calculated figure needs a manual override — the estimated_net_amount_due on a specific booking gets adjusted by hand, with a required reason (up to 500 characters) explaining why. That adjustment is recorded in its own dedicated audit trail, independent of the general audit log: the original amount, the adjusted amount, who made the change, and the stated reason. The calculation itself is also marked manually_adjusted: true with the adjustment_reason attached, so anyone looking at that booking later can see immediately that it isn't a raw engine output. Return Readiness's manual_adjustments check surfaces a count of these per period — purely informational, but visible.
The general audit log
Separate from calculation-specific versioning, a broader audit log records key actions taken across the whole organisation — bookings created and updated, properties added or changed, imports run, reports generated, reporting periods created, reviewed, locked, unlocked and filed, and more. Each entry records the action taken (as a dotted string like reservation.created or reporting_period.locked), what it affected, who did it (or null for a system-originated action, like a billing webhook), and action-specific metadata. That metadata is architecturally guaranteed never to contain guest-identifying data — there's no guest name, email or phone field anywhere in the data model for it to leak from in the first place.
What this means for you practically
If you're ever asked to justify a filed quarter's figures, the combination of calculation versioning and the audit log means you can reconstruct: what each booking's levy calculation actually was at any point in time, whether it was ever manually adjusted and why, when the reporting period was reviewed and by whom, and when it was ultimately locked and marked filed. None of that record includes who your guests were — the audit trail is about the numbers and the actions taken on your account, not about the people who stayed.
What we don't do
We don't submit anything to a council on your behalf, and the "filed" and "payment recorded" fields on a reporting period are exactly that — your own record of what you did, kept alongside the calculation history that led to it, not a live filing mechanism. Keeping this record accurate is on you; the product's job is to make sure the record it's keeping is complete and never silently altered.