In January, a 40-person UK professional services firm promoted seven employees and changed the hours of four others. The operations manager generated eleven variation letters from a single Word template, emailed them as PDFs, and chased signatures for two weeks. Three letters contained the wrong probation clause — a clause that had not applied to new starters since a TUPE transfer two years earlier. Nobody noticed until an Employment Tribunal query arrived.
The failure is not the Word template. Contract variations happen inside HRIS workflows — a manager approves a promotion in BambooHR, HR updates the record, payroll gets the new salary figure — while document generation sits entirely outside that workflow, waiting for an ops manager to spot the change, find the template, fill it in manually, and send it as a PDF. At roughly 90 minutes per variation letter across an eleven-letter batch, that is two working days spent before a single document reaches a signatory.
UK employment law requirements for contract variations: which changes trigger the written notice obligation
Section 4 of the Employment Rights Act 1996 requires employers to give written notice of any change to a written statement of employment particulars within one month of the change taking effect. The written statement covers pay, job title, hours, place of work, holiday entitlement, notice period, and pension arrangements — in other words, almost every material term an employer is likely to change.
Not every administrative adjustment triggers this obligation. A pay increase already described by a clause in the original contract ("annual cost-of-living adjustments at RPI") may not require a standalone variation letter if the mechanism was documented from day one. Some employment law commentators argue that clear payslip evidence plus a brief written summary is sufficient for minor changes, and that requiring signed variation letters for every small adjustment creates compliance fatigue. Lewis Silkin's employment team notes that courts look at the totality of evidence — not just whether a letter exists. For firms with strong payslip documentation, this is defensible.
For most UK SMEs, payslip comments are minimal and HR records inconsistent. The formal variation letter, generated automatically and tracked through signing, is the cleaner path to an auditable employment record.
The six most common variation types: salary, title, hours, location, benefits, and notice period changes
Each variation type requires different clause wording and carries distinct legal considerations. A generic template that covers all six — the most common approach at small firms — creates risk precisely because it is generic.
| Variation type | Written notice required (ERA 1996 s.4)? | Key pitfalls to address in the letter |
|---|---|---|
| Salary increase | Yes | Must reference pension auto-enrolment contribution update if new salary crosses a band threshold |
| Job title change | Yes, if the title is contractual | "Promotion" often bundles a duties change — title alone understates what changed |
| Hours change | Yes | Part-time move triggers different statutory rights; revised annual leave must be recalculated |
| Location change | Yes | Check whether existing mobility clause covers the new site; if not, this is a variation requiring consent |
| Benefits change | Yes | Specify effective date and any run-off period for outgoing benefit (e.g. healthcare provider switch-over) |
| Notice period change | Yes | Must be mutual — the letter must capture both employer and employee notice obligations explicitly |
Generating the wrong clause for the wrong variation type — or a generic letter that omits specifics — is where most post-variation disputes originate.
HRIS trigger design: firing the variation pipeline from BambooHR, Personio, or HiBob on status changes
The trigger should sit as close to the data source as possible. BambooHR, Personio, and HiBob all support outbound webhooks on field-level changes. Use a field-change event, not a nightly export — the letter should generate within minutes of the manager approving the change.
A BambooHR webhook payload for a salary change looks like this:
{
"employeeId": "1234",
"employeeNumber": "EMP-042",
"fullName": "Sarah Okonkwo",
"changeType": "salary",
"effectiveDate": "2026-11-01",
"previousValue": "42000.00",
"newValue": "46500.00",
"currency": "GBP",
"jobTitle": "Senior Account Manager",
"department": "Client Services",
"employmentType": "full-time",
"contractType": "permanent",
"tupeOrigin": false,
"lineManagerEmail": "[email protected]",
"hrContact": "[email protected]"
}
Before the LLM runs, the pipeline runs three checks. First: is tupeOrigin true? If yes, route to the legal review queue and halt generation. Second: is changeType one of the high-risk categories (hours reduction below 25 hours, changes during protected leave, notice period reduction)? If yes, flag for HR director review. Third: is effectiveDate at least 28 days from today? If not, flag for urgency — the statutory one-month notice window is already tight.
Only payloads that pass all three checks proceed to the LLM generation step. This is the routing gate that the "ugly" approach described in the final section never builds.
LLM variation letter generation: prompt architecture for legally accurate clause variation without generic boilerplate
Free-text prompts fail for variation letters for two reasons: the model improvises clause wording that sounds legally sound but is not specific to the variation type, and the model does not know what the existing contract says.
The better approach uses a versioned clause library. Each variation type has three to five pre-approved clauses, with variables — {{fullName}}, {{previousValue}}, {{newValue}}, {{effectiveDate}} — injected at render time. The LLM's role is narrow: select the correct clause, check that all variables are populated, and draft the covering paragraph in plain English.
The system prompt for a salary increase:
System: You are a UK employment document generator. Output must be factually accurate and use the approved clause text exactly as supplied. Do not improvise clause wording or add clauses not in the library.
User: Generate a variation letter using the following inputs:
- Employee: {{fullName}} ({{employeeNumber}})
- Change type: salary increase
- Previous salary: £{{previousValue}} per annum
- New salary: £{{newValue}} per annum
- Effective date: {{effectiveDate}}
- Employment type: {{employmentType}}
Use clause S-1 from the salary clause library. If the new salary crosses an auto-enrolment contribution band threshold, include clause S-1b for the pension note. Output: formal letter, UK English, no markdown, signed off by HR.
When employment law changes — as it did in 2025 — you update the clause library once and every future letter reflects the change. Without a clause library, every letter generation is an uncontrolled legal improvisation.
Legal review checkpoints: the variation types that need employment solicitor sign-off before sending
Build hard routing gates for the following scenarios. These cannot be automated end-to-end:
- TUPE-origin employees: any change to inherited terms requires legal review under TUPE Regulations 2006 reg. 4–5, because many changes are void regardless of whether the employee signs
- Hours reductions: if the move is below 25 hours/week or affects a protected part-time arrangement, check for indirect discrimination exposure before issuing the letter
- Changes during protected leave: variations sent to employees on maternity, paternity, or shared parental leave need careful timing — the employee's right to return to the same role on the same terms is protected during leave
- Notice period reductions: reducing below the ERA 1996 s.86 statutory minimum is void in any event, but the letter must be checked before it creates a misleading contractual impression
- Benefits removal after three or more consistent years: benefits paid consistently for three or more years may have become implied contractual terms and cannot be removed without fresh consent
Everything outside this list passes through the standard HR review queue without requiring a solicitor. The goal is proportionate oversight, not blanket manual processing.
E-signature and acknowledgement tracking: closing the signing loop and creating the contract amendment record
Email-as-PDF delivery has two failure modes: the employee ignores the email, and the employer has no proof of delivery. Both are solvable without significant cost.
DocuSign and Adobe Sign both support API-driven envelope creation. After letter generation, the pipeline creates a signing envelope with the employee's work email address, a 14-day deadline, and automatic reminders on day 3 and day 7. On completion, the Certificate of Completion — a timestamped record of IP address, device, and time of signing — attaches to the employee's HR record automatically.
Signing status feeds back into the HRIS via webhook. An unsigned envelope at day 14 escalates to the line manager with a flag in the HRIS record. For a unilateral variation made under an existing variation clause, the employer's obligation is to give written notice — not to obtain consent. A signed letter is better evidence, but a documented failure-to-sign with proof of delivery still meets the s.4 obligation. ACAS guidance on contract changes sets out how to handle employee objections at this stage.
For how the same signing layer handles starter documentation, see the employee onboarding document automation post.
GDPR retention rules for employment contract variation records: what to keep and for how long under UK law
Under UK GDPR and the ICO's employment records guidance, employment contract records — including variation letters and signed amendments — should be retained for the duration of employment plus six years, aligning with the Limitation Act 1980 period for simple contract claims.
The pipeline creates a retention tag on every document at generation time. Variation letters are tagged employment-contract-variation, linked to the employee record by ID, and assigned a provisional expiry. Because the termination date is unknown at generation, the expiry is recalculated at each employment status change — the final recalculation sets the six-year clock from the confirmed termination date.
Avoid retaining variation letters in an unstructured email archive with no access log. Subject access requests under UK GDPR require employers to produce employment records on demand and without unreasonable delay. An inbox search is not a compliant retrieval process. See the GDPR DSAR automation post for how to build a retrieval layer that satisfies ICO standards at SME scale.
What changed in 2025–2026: Employment Rights Act 2025 obligations on flexible working and predictable hours notices
The Employment Rights Act 2025 added two changes with direct implications for variation letter pipelines.
First, the right to request flexible working became a day-one right. Any change to working hours that results from a flexible working agreement — whether requested by the employee or offered by the employer — now requires a variation letter confirming the agreed new arrangement, including any end date, review period, or trial conditions. The pipeline must handle flexible working variations as a distinct type with its own clause set, because the wording differs from a standard hours change in ways that matter for enforcement.
Second, the Act introduced a right to predictable hours for zero-hours and variable-hours workers after 26 weeks of qualifying service. When an employer grants predictable hours in response to a statutory request under ss.27A–27B ERA as amended, the variation letter must reference the statutory right explicitly and confirm the qualifying period was met. A standard hours variation template does not satisfy this requirement — it needs its own clause variant. Firms that already automated their hours variation letters before 2025 will have stale clause libraries unless they updated them for the Act.
The net effect: the universe of events that trigger a required variation letter grew in 2025, not shrank.
Good / Bad / Ugly: three variation letter automation approaches and their Employment Tribunal compliance risk
| Approach | How it works | Tribunal compliance risk |
|---|---|---|
| Good | HRIS webhook fires on field change → routing gate checks TUPE flag and change type → clause library selection → LLM fills variables into approved clause → e-signature envelope → completion certificate filed to HR record | Low. Audit trail is complete, clause accuracy is controlled by a versioned library, high-risk variations reach a solicitor before the letter sends. |
| Bad | Nightly HRIS export → ops manager runs Word macro or fills template → emails PDF → chases signatures manually | Medium. Letter accuracy depends on template age and human attention. No delivery proof. Signature status lives in someone's inbox. Inconsistent for Tribunal disclosure. |
| Ugly | Ad-hoc LLM prompts on a per-request basis with no clause library, no HRIS integration, and no routing gate | High. LLM improvises clause wording without knowledge of what the original contract says. No flag for TUPE employees. No audit trail. The resulting letters read plausibly but may contain wording that contradicts the original contract or misapplies the 2025 Act changes. |
The "bad" approach is what most UK SMEs run today. It is not illegal — but it is fragile. A two-year-old clause error persists invisibly until a Tribunal query surfaces it.
The "ugly" approach is an increasingly common failure mode: an ops manager uses ChatGPT to draft variation letters on demand and trusts the output because the writing is fluent. Fluent is not the same as accurate. For more on where LLM clause generation helps and where it needs guardrails, see our post on LLM contract review and NDA clause extraction. For the document store and retrieval layer that underpins this pipeline, the document RAG case study covers the architecture we use in production.