tips-record-retention

---
name: tips-record-retention
description: Tracks the three-year clock on every tip record the Employment (Allocation of Tips) Act 2023 requires an employer to keep, and answers a worker's record request inside the exact window and response time the statutory Code sets, rather than however long the business happens to keep spreadsheets. It works out whether a record can be disposed of, must still be kept, or should already exist and is missing, by the tip's own payment date rather than by a blanket retention policy copied from somewhere else. Use before you archive or delete old tip records, the moment a worker asks to see their tip history, or to find a gap before an inspection does.
---

# The three-year tip record clock, run per tip

You give this every tip record you hold, each dated, and any worker request for their records. You get back a retention date for every record, a verdict on whether each one may be disposed of yet, and a check on whether a worker's request was answered inside the Code's own rules.

## What it does

1. **Fixes the retention period exactly as the Code states it.** The statutory Code's paragraph 43 requires a record of how each qualifying tip was dealt with to be "maintained for a period of three years beginning with the date on which the tip was paid." The clock starts on the tip's own payment date, not on the date it was entered into a system or the date the business's financial year closes.
2. **Checks a worker's request against the Code's own window, not a generous or stingy guess.** Paragraph 44 allows a worker to request records covering one or more full months, starting no more than three years before the request and ending before it, and only for months during which the worker actually worked there. A request for a period before the worker's employment started, or more than three years back, falls outside what the Code requires the employer to answer.
3. **Enforces the one-request limit the Code sets.** The same paragraph allows a worker to make only one such request in any three-month period, so the skill checks the date of the last request before treating a new one as due a response.
4. **Holds the employer to the Code's own response deadline.** The Code sets a four-week "response period" for answering a worker's record request; the skill calculates that deadline from the date the request was received and flags any response that missed it.
5. **Keeps confidentiality and data protection as two separate questions.** The Code states disclosure of a tip record to the requesting worker does not breach confidentiality, but that data protection law still takes precedence, so a response is checked for whether it discloses only the requesting worker's own data, not other workers' amounts mixed into the same record.

## Then it checks

1. Every tip record has its own payment date and its own calculated retention date, three years on.
2. Any record whose retention date has passed is marked eligible for disposal, and any record still inside the three years is marked as must be kept.
3. Any worker request is checked against the full-month, three-year, employment-period rules before being treated as valid.
4. Any worker's second request inside three months of their last one is flagged, not treated as a fresh valid request.
5. Every valid request has a response date recorded and checked against the four-week deadline from the date it was received.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only. Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never dispose of a record before its calculated three-year retention date has actually passed.
- Never include another worker's individual tip amounts in a response to a different worker's request without checking the data protection position first.
- This is a working document for the owner to check against their own payroll records and for their solicitor or data protection adviser to check before any response is sent. It is not legal advice.

## Built from
- Employment Rights Act 1996, Part 2B, section 27J, as inserted by the Employment (Allocation of Tips) Act 2023 c.13, https://www.legislation.gov.uk/ukpga/2023/13, Royal Assent 2 May 2023, read 4 November 2026: the record-keeping duty and worker request mechanism, behind all five steps.
- Department for Business and Trade, "Code of Practice on Fair and Transparent Distribution of Tips", https://www.gov.uk/government/publications/distributing-tips-fairly-statutory-code-of-practice/code-of-practice-on-fair-and-transparent-distribution-of-tips-html-version, published 29 July 2024, in force 1 October 2024, read 4 November 2026: paragraphs 41 to 45 on the three-year retention period, the request window, the one-request-per-three-months limit, the four-week response period, and the confidentiality and data protection position, behind all five steps.

# tips-record-retention

## You are given
Every tip record held, with its payment date and the amount(s) allocated. Any worker record request, with the worker's name, the date the request was received, the period requested, and the date(s) the worker was actually employed at that site. Any previous request from the same worker and its date. The date any response to a request was sent.

## Produce
Write into a `./tips-record-retention-output/` folder:

1. `retention-ledger.csv` with columns: `row_ref`, `tip_payment_date`, `retention_expiry_date`, `today_date`, `disposal_status`. `row_ref` is R0001 upward. `retention_expiry_date` is exactly three years after `tip_payment_date`. `disposal_status` is `must be kept` or `eligible for disposal`.
2. `request-validity-check.csv` with columns: `worker_name`, `request_date`, `period_requested_start`, `period_requested_end`, `worker_employed_during_period`, `within_three_years`, `full_months_only`, `verdict`. The three yes/no columns are `yes` or `no`, checked only against supplied employment dates. `verdict` is exactly one of `valid request`, `invalid, period before employment`, `invalid, period more than 3 years back`, `invalid, not full months`.
3. `request-frequency-check.csv` with columns: `worker_name`, `current_request_date`, `previous_request_date`, `months_since_previous`, `verdict`. `verdict` is `allowed` or `blocked, inside 3-month limit`.
4. `response-deadline-check.csv` with columns: `worker_name`, `request_received_date`, `response_due_date`, `response_sent_date`, `days_late`. `response_due_date` is four weeks after `request_received_date`. `days_late` is `0` or negative if on time.
5. `gaps.md` - a numbered list of: any record with no `tip_payment_date` supplied; any request marked `invalid` in `request-validity-check.csv`; any request marked `blocked, inside 3-month limit`; any response in `response-deadline-check.csv` with `days_late` greater than zero; any disposal of a record whose `disposal_status` is `must be kept`.

## Rules
- Codex calculates dates and checks requests against the Code's own rules. It never decides a data protection question and never drafts the content of a response to a worker.
- Every retention date is calculated as exactly three years from the tip's payment date, never from today or from a financial year end.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write.
- Every file ends with this line: this is a working document prepared for the owner to check against their own payroll records and for their solicitor or data protection adviser to check before any response is sent. It is not legal advice.

## Return
The absolute path of each file written and the row count of each CSV. The count of records `eligible for disposal` versus `must be kept`. Every invalid or blocked request, with the reason. Every response that missed the four-week deadline, with days late. The `gaps.md` item count.