England Guest Records and Host Duties for Short Lets

English hosts should keep a stay record for every let: dates, guest numbers, channel, and the key compliance facts for that stay, such as safety checks and guest instructions issued. Those records support registration, planning night counts where relevant, tax reporting and any council or platform inquiry, and they do so far better than bank statements or platform dashboards alone, because they are organised by property and by stay.

Guest records also involve care with personal data. Hosts collect names, contact details and sometimes identification information, and that data must be handled proportionately, kept only as long as needed for a legitimate purpose, and protected from unauthorised access. A host who keeps every guest message forever, in an unsecured inbox, is creating a data risk alongside a compliance record.

Build the routine now, as checked on 26 October 2026, so registration, planning and tax tasks draw on the same stay log rather than requiring separate reconstructions. This guide gives the routine; the registration scheme, tax rules and data rules govern the details for each property.

Record for each stay: property, start and end dates, nights, guest numbers, booking channel, guest contact route, amount charged broken down where tax requires it, taxes collected by channel or host, safety checks done at turnover, and guest instructions issued. That level of detail answers most inquiries about a single stay without further searching.

Update the log at booking and again at check out, not at month end from memory. Contemporaneous logs are credible; reconstructed logs are not, and a council, tax or platform inquiry that meets a reconstructed log will ask harder questions. A simple spreadsheet per property, updated in minutes at each turnover, is enough for most hosts.

Keep the log per property, not per portfolio, and keep it separate from marketing or guest review material. A log mixed with promotional material is harder to search and easier to misread, while a clean log per property can be filtered by date, channel or guest number in seconds.

Give guests, before arrival and in the property, the information they need: address for emergency services, check in and check out arrangements, house rules on noise, parking, waste and occupancy, safety information on alarms and escapes, and a local contact who answers. Keep copies of the information as issued, with its date, so a later dispute about what guests were told can be settled from the file.

Communicate through a channel that leaves a record, such as a platform message system or an email, for key instructions and for any problem handling. Phone calls are useful for urgent matters, but a phone call about a noise complaint or a safety fault should be followed by a short written note summarising what was agreed. That note protects both host and guest.

Handle guest personal data proportionately. Collect only what is needed for the stay, for safety, for tax or for registration, keep it securely, limit who can access it, and delete or anonymise it when its legitimate purpose ends, subject to any longer retention required by tax or registration rules. Note retention decisions in the file, so data handling is deliberate rather than accidental.

Link safety records to stays, not only to calendar dates. Note which turnover checks were done before each stay, which alarm tests were done, and any fault found and fixed. That linkage shows that safety was checked for that guest, not merely at some point in the year, and it helps if a guest later reports a fault.

Keep planning, registration, tax and lease documents in the same property file as the stay log, but in separate sections, so each system can be checked without disturbing the others. A council planning inquiry should be answered from the planning section, a tax inquiry from the tax section, and a registration inquiry from the registration section, even though all three sit in one property file.

Review records quarterly in the first year of letting, and at least annually thereafter. Check that the log is complete, that safety records are current, that guest instructions still match current rules, and that data retention is being followed. A quarterly review, taking under an hour per property, prevents the backlog that makes records unreliable.

When a council, platform or tax authority inquires, answer from the stay log and the property file, with specific dates and documents, through the official channel named in the inquiry. A specific answer, citing a stay, a check and a document, closes inquiries faster than a general assurance that the property is compliant.

If a record is missing, say so plainly and explain what can be shown instead, rather than reconstructing it as if it were contemporaneous. Honesty about a gap, with a plan to prevent recurrence, is more credible than a reconstructed record that later proves inaccurate. Note the gap and the corrective step in the file.

Do not share guest personal data beyond what the inquiry requires, and do not share other guests' data when answering about one stay. Redact or summarise where possible, and keep a note of what was shared, to whom, and when. That discipline protects guests and shows that the host handles data responsibly.

Create a stay log per English property, a guest information template per property, and a property file with planning, registration, safety, tax and lease sections. Update the log at booking and check out, review the file quarterly, and re-check GOV.UK registration guidance annually.

Records kept this way become background work, not a burden, and they turn registration, planning and tax from separate crises into routine tasks fed by the same log.