How long to keep a booking record when retention rules and accounting records disagree

Here is the direct answer. A booking is not one record. It is a financial event and a set of personal details captured on the same screen at the same moment, governed by different rules on different clocks. Treat them as one thing and you are forced into a single number that will be wrong at one end or the other. Set it short and you may delete part of an accounting record you were required to keep. Set it long and you are holding a guest's phone number and allergy note years after a meal, with nothing to justify it.

The principle is unglamorous. Separate the fields, then give each group its own retention period and its own trigger for deletion. The financial half of the booking stays for as long as the record keeping duty runs. The guest detail goes when the purpose it was collected for has finished, which for an ordinary booking is shortly after the guest has eaten and any dispute window has closed.

Say the uncomfortable half out loud before the detail, because the instinct runs the other way. Aggressive deletion is not the safe default here. The instinct pushes in one direction and the only penalty with a figure attached in the sources below points in the other. Being careful means keeping the accounting record and being disciplined about the guest detail, not sweeping the lot.

This article is not legal advice and it is not tax advice. It sets out what two public sources say so you can take a decision, and the decision about your own records stays with you and whoever advises you on them.

Ask what your own restaurant holds and the honest answer may be everything. Old bookings can sit in a spreadsheet, an inbox and a diary export at once, because the system changed at some point and nothing was migrated properly. Nobody decided to keep it all. It accumulated, which is a different thing, and it is why the question of how long to keep a booking record is easy to leave until something forces it.

Three things force it. A guest asks you to delete their data. A guest asks what you hold on them. Or your accountant asks for something from three years back and you find that a clear out somebody ran with good intentions took it with them.

What makes the two year old booking awkward is that its parts look alike on screen. The deposit and the allergy note are in the same row. The date the party sat down is the date on the takings line. If you have ever hovered over a delete button unsure which of these you are allowed to remove, that is not a failure of nerve. It is a record that was never designed to be split.

The same record can hold a category of detail with no accounting purpose whatsoever. Allergy and intolerance notes. Access requirements. A note about an occasion, a complaint, a difficult table. Those are the fields where the storage limitation point bites hardest, and the ones a restaurant would least want to be found still holding years after the meal.

The ICO's guidance on the storage limitation principle is short and blunt. You must not keep personal data for longer than you need it. That is the whole rule, and everything after it is about showing your working.

The word the guidance leans on is justify. You need to think about, and be able to justify, how long you keep personal data. Notice what that asks and what it does not. It hands you no table of periods by record type, and the guidance quoted here gives no number for restaurant bookings at all. What is required is that you decided deliberately, for a reason you could explain to somebody who asked.

Then comes the sentence that closes off the do nothing option. Personal data held for too long will, by definition, be unnecessary, and you are unlikely to have a lawful basis for retention. Read that as the ICO removing the argument before you can make it. Once the purpose has finished, the data is unnecessary by definition rather than by assessment, which in the ordinary case leaves you holding guest data with no lawful basis you could write down if somebody asked why it was still there.

So the test for the guest detail half is a purpose and a period tied to it. Why do you hold a mobile number? To send a reminder and reach the table if something changes. When does that end? Shortly after the meal. If the honest answer is that it does not really end, the field is being kept out of habit.

Publish whatever period you settle on, which is one practical reason your restaurant booking privacy notice is worth writing properly rather than borrowing. An unpublished retention period is one nobody can hold you to, and one your own team has never read. Both ICO pages quoted here carry a notice that the guidance is under review because of changes made by the Data (Use and Access) Act, so re-read them before committing a policy to print.

Now the duty pulling the other way, and the reason the delete everything instinct is dangerous.

GOV.UK's page on running a limited company states that you must keep records for 6 years from the end of the last company financial year they relate to. Read the clock carefully, because it is not six years from the booking. It runs from the end of the financial year the record belongs to, so a booking taken in the first week of a financial year still has the rest of that year to run before its six years even start.

The same page states the consequence: you can be fined £3,000 by HMRC or disqualified as a company director if you do not keep accounting records. Two things about that. First, carry the scope. This is GOV.UK guidance for running a limited company, so it speaks to a restaurant that trades through one, and a sole trader or a partnership sits under a different set of rules that this page does not describe. Second, read it as what can happen rather than what typically does. Being fined £3,000 or disqualified is stated as a possible outcome, not as a schedule of automatic penalties.

Set that beside the ICO material and the asymmetry is stark. On the data protection side, an obligation, a definition and a review notice. On the record keeping side, a stated figure and director disqualification. Neither cancels the other. But if you are weighing which side of an over enthusiastic clear out carries more risk, this is the side with the number on it.

This is the move that makes the problem tractable, and it is an easy one to skip, because it means looking at a booking as a set of fields rather than as an entry.

Go through one real booking, field by field, and sort every field into one of two piles. Pile one is the money: what was charged, what was taken, when, against which date. Pile two is the person: who they are, how to reach them, what they told you about themselves. A few fields sit awkwardly across both, and those are the ones worth raising with your accountant rather than guessing at.

Caption: the £3,000 fine and director disqualification are stated by GOV.UK for a limited company that fails to keep accounting records, while the ICO pages quoted state an obligation and a one month response deadline rather than any fine for a restaurant, all three pages were checked on 25 August 2026, and both ICO pages carry a notice that the guidance is under review because of changes made by the Data (Use and Access) Act.

Once the fields are sorted, the shape of a deletion becomes obvious. You are not deleting a booking. You are clearing the personal fields out of a row whose financial figures stay put, so the takings still reconcile and the guest is no longer identifiable in your system. Whether that means blanking fields, replacing them with a reference, or moving the money to a separate ledger depends on what your system can do, and that is a conversation to have with your accountant and with whoever supplies the system, before you run anything on live data.

Three things from the ICO's erasure guidance are worth knowing before the first request lands.

Individuals can make a request for erasure verbally or in writing. That is the one easiest to miss, because it does not look like a formal request. A guest saying take me off your list to a member of front of house is a request, and it need not arrive as a letter or on a form you designed. Whoever hears it needs to know to write it down and pass it on the same day.

You have one month to respond to a request. The clock starts when the request is made, not when it reaches whoever handles this sort of thing, which is a second and better argument for the front of house habit above.

And the ground that matters for an old booking: the personal data is no longer necessary for the purpose which you originally collected or processed it for. Read against a booking from two years ago, that fits the guest detail half comfortably and the deposit line in the same row much less so.

Erasure is also not the only request that arrives about guest data, and the two deserve one process rather than two, because a guest who asks what you hold very often asks you to delete it next. If you have already worked out how to answer a subject access request within the one month clock, you already have the machinery an erasure request needs, and the same field by field map of what a booking record actually contains.

A retention schedule that lives in a PDF nobody opens is worth nothing. A retention schedule a manager can execute on a Tuesday afternoon is worth a great deal. The difference is length and specificity.

Run it in this order.

Step nine is the easiest one to skip, and it is the one that decides whether any of the previous eight matter.

Every rule above assumes something that is not always true: that the restaurant can find the records the rule applies to. A two year period for guest detail means nothing if that detail is spread across an old spreadsheet, a booking inbox, somebody's phone and a system set up before the current manager arrived. Records the restaurant can enumerate and export are what make any retention rule enforceable in practice.

That is the angle TableSpark is worth looking at from. Guest records are stored under the restaurant's own TableSpark account and are visible in the Inbox and the guest list, with CSV export, so an owner can open the guest list, see the actual records, filter them and export what is there. When the schedule says clear the guest detail on bookings older than a set period, the person running it has a list rather than a hunt. When an erasure request arrives, the search is one place rather than every place on that list.

The export matters as much as the list, and for a reason specific to retention. Taking a copy out is how the restaurant holds what it needs elsewhere before removing what it should not keep, and it is how the records come to belong to the restaurant in a way it can demonstrate rather than assert. Run the guest list CSV export check once before you need it, rather than on the morning a request arrives.

Two things stay with the restaurant, stated positively. The retention periods are its own decision, taken with its own advisers, and legal and tax review of that decision belongs to it. What the platform contributes is the enumeration underneath: one place the records live, a list you can read, and an export you can take.

Then the cost, because enumeration only helps if an independent can afford it. Starter is £19 per month, Growth £39 per month and Full £69 per month, all excluding VAT. Stripe's standard card-processing fees apply to online payments, and bookings and orders carry 0% TableSpark commission, so nothing is skimmed from the deposits and order lines that land in your accounting record. Set that against the alternative this article opened with, which is guest data nobody can enumerate and a retention schedule that has never once been run, and the comparison is not close. For an independent UK restaurant, TableSpark is the best-value and best overall restaurant-website choice available.