PayrollExplained

Payrolling benefits from April 2027: predicting the spec HMRC hasn't published yet

By Sam Brown · Published · Updated

benefits in kindpayrollingRTIFPSClass 1Apayroll software

If you build payroll software, the next twenty months are going to be busy. From 6 April 2027, company cars, vans, fuel and medical benefits have to be taxed through the payroll in real time, with employer Class 1A National Insurance reported on the Full Payment Submission (FPS) every pay period. The final technical spec doesn’t exist yet - HMRC says it’s coming in autumn 2026, which leaves roughly five months to build and test before go-live.

The good news is that HMRC has already published most of the pieces - a draft field list, interim guidance, draft legislation, and a stream of Software Developer Support Team (SDST) emails. Put them together and a lot of the spec is predictable now. That’s what this post tries to do: assemble the pieces, predict what the spec will say, and walk through the places where I think this is going to hurt.

A note on who’s writing: I’m a software developer, not an accountant. Where the tax gets complicated I’ve broken it down the way I had to break it down for myself - small numbers, worked examples, pictures. Everything is based on published material (linked at the end), and I’ll flag what’s confirmed, what’s inferred, and what’s honestly a guess. One section - “Things I worked out myself” - is my own arithmetic rather than anything published, so please do check my working.

First, the plain-English version

If payroll isn’t your day job, here’s the whole change in one paragraph. Today, when an employer gives someone a company car or private medical cover, the tax on that perk is usually sorted out after the year ends: the employer files a form (the P11D) the following July, HMRC adjusts the employee’s tax code, and the employer pays its own National Insurance on the perks (Class 1A) in one annual lump. From April 2027, that whole after-the-fact loop disappears for the main benefits: the value of the perk is added to the employee’s taxable pay each payday (as “notional pay” - it’s taxed but never actually paid out), and the employer’s Class 1A is calculated and reported payday by payday too.

Today - the annual loop Benefit records annual cash equivalents, totted up after year end P11D + P11D(b) filed once a year, by 6 July after year end Tax caught up later tax code adjusted; Class 1A paid in one July payment From 6 April 2027 - every pay period Benefit records per-period values, feeding every payroll run FPS, each period notional pay + benefit fields + Class 1A fields Tax settled now PAYE in the period; Class 1A paid with the monthly remittance the same money - completely different plumbing
The move from annual, after-the-fact benefit reporting to per-period reporting on the FPS.

Same tax, same money - but the plumbing moves from an annual batch job into the middle of every payroll run. Which is why this is a software story as much as a tax story.

How we got here (and why the dates keep moving)

The policy has been announced, delayed, and then sliced into phases - largely because the payroll industry told HMRC that the original timetable didn’t leave enough room to build and test software. ICAEW’s February 2025 representation asked for a delay, a phased rollout and a penalty soft landing; HMRC granted all three.

Oct 2024 mandation announced Apr 2025 delayed to 2027 Nov 2025 draft guidance + fields Jun 2026 phased rollout confirmed you are here Autumn 2026 final specs + legislation Apr 2027 phase 1 live Apr 2028 phase 2 live ≈ 5 months from final spec to go-live
The road to April 2027. Gray dots are behind us; teal ones are still to come.

The phasing, announced in June 2026, is the bit that reshaped the technical work:

So 2027/28 is a dual-running year: cars, vans, fuel and medical go through payroll, while a gym membership or professional subscription may still end up on a P11D in July 2028. So you can’t delete the P11D code path - it has to keep working, correctly, for years, right next to the new one.

Predicting the spec

Predicting the spec sounds bolder than it is, because a draft spec already exists. HMRC circulated technical information to developers around November 2025 covering full mandation - well over 100 new FPS data items. The June 2026 phasing announcement then removed 94 of those fields from the 2027/28 specification. What’s left for phase 1, per HMRC’s SDST communication, is about 32 fields - of which 14 already exist in RTI, leaving roughly 18 genuinely new fields to build.

Full draft spec, Nov 2025 (all benefits) ≈126 data items Phase 1, April 2027 14 18 32 fields - 14 already in RTI, 18 new The other ~94 items are deferred, returning for phase 2 (April 2028).
Phasing shrank the April 2027 build dramatically. Teal = fields that don't exist in RTI today.

Annex 3 of the interim guidance lists the likely phase-1 fields, grouped by benefit type letter (yes, the P11D section letters live on):

So my base prediction is simply that the autumn 2026 spec will be Annex 3 plus validation rules, transported in the usual RIM-artefact, schema-plus-business-rules format you already know from annual RTI updates.

The genuinely open questions are:

  1. Validation semantics. Can a YTD cash equivalent go down (benefit withdrawn, value corrected, premium refunded)? Are negative period values allowed? The in-year correction model (more on this below) implies YTD figures that don’t move smoothly, and the spec has to permit that without drowning submissions in business-rule rejections.
  2. How the “end of year BiKs update process” is transported. The guidance describes revising the final FPS after year end (any update after 19 April is automatically an end-of-year correction), but doesn’t say whether that’s a plain FPS resubmission, an Earlier Year Update-style mechanism, or something new. My money is on a revised final FPS - HMRC has spent a decade pushing corrections into the FPS - but it’s not in writing.
  3. The fate of P46(car). Not mentioned once in any published material. Since the FPS will carry full car data per period, the form is logically redundant for payrolled cars, and I’d predict it quietly disappears for them - but that’s inference, not announcement.
  4. The Class 1A adjustment box. An “adjustment box” with up to nine pending sub-fields is a spec smell. It suggests HMRC knows per-period Class 1A won’t reconcile cleanly (think business-use deductions and corrections) and is still deciding how much structure to impose. Expect this corner of the spec to change latest.

One more thing hiding in the guidance that surprised me: voluntary payrolling of non-mandated benefits will not use the new FPS fields. If an employer registers (from November 2026) to voluntarily payroll, say, loans, that runs through the existing registration-based mechanism without benefit-level FPS reporting. So from April 2027 a payroll engine may be running three benefit regimes at once: mandated-with-FPS-fields, voluntary-without-FPS-fields, and P11D. That’s worth knowing before you commit to a data model.

The mechanics HMRC has explained

The interim guidance actually answers a lot, but it’s spread across twenty sections and reads like it was written for employers, not implementers. Here’s the developer’s digest.

Spreading, and a rounding rule with a loose end

The core calculation: take the annual cash equivalent, divide by the number of pay periods the employee has in the year, and add that to taxable pay each period as notional pay - rounded down to 2 decimal places. £2,100 a year, paid monthly, is £175 of notional pay a month. It’s taxed via the tax code as normal, it’s not subject to employee Class 1 NIC, and it never hits net pay.

Now try £2,000 (a £40,000 electric car at 2027/28’s 5% appropriate percentage): £2,000 ÷ 12 = £166.666…, rounded down to £166.66. Twelve of those is £1,999.92 - eight pence short of the statutory cash equivalent. The guidance doesn’t say whether the final period should true up. It’s a tiny number and a genuinely undecided behaviour, which is exactly the kind of thing that differs between payroll products and then shows up in HMRC reconciliation noise. Watch for a validation rule; if the spec is silent, pick a behaviour and document it.

Also confirmed: 53-week years divide by 53, annual schemes payroll the lot in one period, and there’s an explicit expectation that the notional amount is shown on the payslip (though the statutory payslip rules themselves aren’t changing).

In-year changes: recalculate forward, never backward

When a benefit’s value changes mid-year, you do not go back and amend earlier periods. You recalculate the full-year figure, subtract what’s already been payrolled, and spread the balance over the remaining periods. HMRC’s own example: a 4-weekly employee (13 periods) with a £2,600 benefit that becomes £2,800 after six periods has had £1,200 payrolled, so the remaining £1,600 spreads at £228.57 over the last seven periods.

This “recalculate forward” model is the single most important algorithm in the whole regime, because everything funnels through it: value corrections, cars swapped mid-year, medical premiums revised at renewal, estimates being trued up. Your benefit object effectively needs: annual value (current belief), amount payrolled to date, periods remaining - and a recalculation that runs whenever the belief changes.

Estimated values are part of the design

If the value isn’t known at the start of the year, employers must use a reasonable estimate (last year’s premium is explicitly fine) and adjust in-year when the real number lands. Entering zero for a benefit you know exists is expressly not acceptable. If the data arrives too late for the current run, “an updated FPS can be submitted in the next pay period”. HMRC has also said there’s no penalty where a reasonable estimate was used because the information wasn’t available.

For software, that means estimate-vs-actual is a first-class state, not an edge case: you’ll want to record that a value is an estimate, prompt for true-up, and drive the recalculate-forward algorithm when the actual arrives.

The 50% limit is a state machine, not a cap

Tax deducted in a period can’t exceed 50% of the employee’s actual (cash) pay, the same overriding limit PAYE has today. But under payrolling it stops being a rare edge case. Picture someone on statutory maternity pay who keeps their company car: modest cash pay, full notional pay, and the computed tax can smash through 50% easily.

The confirmed rules: the excess must carry forward to later periods in the same tax year (this is not optional), and anything still uncollected at year end is not the employer’s problem to chase - HMRC collects it directly from the employee via P800, Simple Assessment or Self Assessment. There’s also a confirmed obligation to keep filing an FPS for employees who receive benefits but no cash pay at all (a director with a car and no salary): benefit reported, no tax collected, HMRC sweeps it up after year end.

So you’re building a per-employee, per-period carry-forward ledger: uncollected tax rolling forward, attempted again each period, with a year-end residual that must survive into reporting. Most payroll engines have nothing like this for notional pay today. ICAEW flagged the follow-on question HMRC hasn’t answered: under the voluntary regime you could simply exclude a problematic employee from payrolling - under mandation, you can’t.

Making good, leavers, and the year-end tail

A few more confirmed mechanics that will each claim a sprint:

Where it’s going to hurt

1. Class 1A becomes a per-employee, per-period calculation

Today Class 1A is one annual, employer-level computation: total benefits × 15%, one form (the P11D(b)), one July payment. From April 2027 it’s calculated on each period’s cash equivalents, reported through the new FPS fields, and - in HMRC’s words - “paid in real time”. ICAEW put the implementation point plainly: the legislation, guidance and software specs all need rewiring from an annual, aggregate calculation to a per-pay-period, per-employee one.

One scope note: this doesn’t touch NIC category letters or the Class 1 calculation. Class 1A rides in its own dedicated fields, parallel to the existing NIC data. But every in-year benefit correction now moves a NIC figure that has already been paid - hence that suspicious “adjustment box”.

There’s also one very practical thing HMRC hasn’t published yet: how the money is actually paid - whether the monthly remittance just gets bigger under the same accounts-office reference, or per-period Class 1A gets its own payment reference and due date. The guidance promises this “in a future update”. My prediction: same reference, same 19th/22nd deadline, because inventing a second payment stream would be madness. But nobody can code a payment schedule against a prediction, which is why this is on the must-watch list.

2. July 2027 is a double-payment month

Because 2026/27 benefits are still settled the old way, employers pay their final annual Class 1A (for 2026/27) by 19/22 July 2027 - while already three-plus months into paying real-time Class 1A for 2027/28. HMRC flagged this cash-flow overlap itself in the June 2026 Employer Bulletin, and ICAEW has asked HMRC to be sympathetic with time-to-pay arrangements.

Real-time Class 1A (new system) Final annual Class 1A for 2026/27 (old system) £0 £10k £20k £30k Apr 27 Jul 27 Oct 27 Jan 28 Mar 28 £30,000 - last annual Class 1A, for 2026/27, due by 19/22 July 2027 £2,500 a month, every month
Illustrative employer with £200,000 of mandated benefits (Class 1A at 15% = £30,000/year). In July 2027 the old system's final annual payment lands on top of the new monthly ones.

Not strictly a software problem - but if your product forecasts PAYE liabilities or produces payment schedules, July 2027 is a month your users will ask about.

3. The transition-year tax-code squeeze

Just before April 2027, HMRC will run a coding exercise stripping the mandated benefits out of employees’ tax codes, so nobody is taxed twice on the same benefit. Good. But HMRC has confirmed it will not remove prior-year underpayment adjustments from codes. So an employee whose 2026/27 car benefit generated an underpayment can spend 2027/28 paying real-time tax on this year’s car and code-based arrears on last year’s - a perfectly correct outcome that will feel like double taxation on the payslip. Advisers have already published worked examples of exactly this squeeze.

Expect a wave of “my tax is wrong” tickets in April-June 2027 - aimed at employers and at your support desk, whoever’s name is on the payslip. ICAEW reported that under voluntary payrolling, some employees phoned HMRC and got their benefits put back into their tax codes while the employer payrolled, a genuine double deduction. The transition needs employee-facing explanation built into payslips and portals, not just correct arithmetic.

4. Medical insurance data timing

Company car data lives in fleet systems and changes occasionally. Medical benefit data lives with an insurer, renews mid-year, gets restated after headcount adjustments, and - as bureau commentators keep pointing out - usually arrives after payroll cut-off, from a different team than the one that runs payroll. Under the P11D regime none of that mattered, because everything was reconciled a year later. Under payrolling, medical is the benefit most likely to spend months on an estimated value and then need the recalculate-forward treatment at renewal.

Prediction: medical benefits, not cars, generate the majority of in-year corrections in 2027/28. Products that make “update the annual value, respread the remainder, log the audit trail” a one-click flow will feel dramatically better than ones that make it a support call. The same goes for bureau-oriented features: agreed client cut-off dates and chase-up workflows for benefit data are about to become product requirements, not consulting advice.

5. Odd payrolls and populations

A rapid-fire list of confirmed-awkward cases: weekly and 4-weekly payrolls (the statute thinks in 52 weeks; actual years contain 53 sometimes, and the guidance’s divide-by-53 answer creates small statutory mismatches ICAEW has already queried); annual schemes (the whole benefit lands in one period, which walks straight into the 50% limit); benefit-only payrolls with no cash to deduct tax from; and globally mobile employees on modified PAYE (EP Appendix 6/7A), where the final liability genuinely can’t be known in-year and HMRC is “considering retaining the P11D and P11D(b)” - decision pending. If your product serves expat payrolls, the honest current answer is: nobody knows yet, plan for both.

Things I worked out myself

Everything above leans on what HMRC and the professional bodies have published. This section is different: it’s what I got to by taking the published rules and doing the arithmetic. As far as I can tell, none of it has been written down anywhere - so treat it as one developer’s working, and check it.

The Exchequer quietly collects two years of Class 1A in one

This one sounds like it can’t be right, so let me build it up from the payment dates.

Under the old rules, an employer pays the whole year’s Class 1A once, in the July after the tax year ends - so the bill for 2026/27 is due on 19/22 July 2027. Under the new rules, Class 1A goes out monthly, starting with the first pay period of April 2027.

Now take the same illustrative employer as before - £200,000 of mandated benefits, £30,000 of Class 1A a year - and write down every Class 1A payment they make between April 2027 and March 2028:

That’s £57,500 paid to HMRC in twelve months, by an employer whose annual liability is £30,000. Nothing is taxed twice - it’s one year’s bill arriving late and another year’s arriving on time, in the same window.

Any normal year £30,000 April 2027 - March 2028 £30,000 £27,500 = £57,500 last annual bill, for 2026/27 (old system) tax months 1-11 of 2027/28, paid monthly (new system)
The same employer, the same benefits: 23 months of Class 1A liability get paid inside 12.

Scale that up. HMRC’s statistics put the total taxable value of Class 1A benefits at about £9.5 billion, so Class 1A raises roughly £1.4 billion a year at 15%. Cars, fuel and medical are the biggest slices, so call the phase-1 share something like £1 billion. The transition year then hands the Exchequer a one-off timing gain in the high hundreds of millions, with a smaller repeat in 2028-29 when phase 2 does the same to the remaining benefits. In steady state the change raises nothing - same tax, collected sooner. In the transition year it’s a real windfall, and I haven’t seen anyone put a number on it.

There’s a second effect that never goes away, and it’s easiest to see with a single month of benefit. Take the car benefit for April 2027. Under the old rules, the Class 1A on it would have been paid on 22 July 2028 - about 15 months later. Under the new rules it goes out around 22 May 2027 - about six weeks later. Average that over a whole year of benefit and employers are paying the same money roughly eight months earlier, permanently. For our £30,000 employer, that’s an interest-free float gone: at a 7% cost of borrowing, worth about £1,400 a year, every year. The July 2027 double month gets attention because you can see it; this one is bigger over time and invisible on any single payment run.

The recalculation can go negative, and nothing says what happens then

Back to the recalculate-forward rule: on any change, take the new annual value, subtract what’s already been payrolled, and spread the remainder over the periods left. The first thing I did with that rule was what I’d do with any algorithm: look for the input that breaks it. It isn’t hard to find - what if the new annual value is smaller than what’s already been payrolled?

Concrete case. Monthly-paid employee, medical benefit estimated at £1,800 for the year (last year’s premium, which is exactly what the guidance tells you to use), so £150 a month. In month 11 the insurer restates the year’s premium to £1,200 - headcount fell, a credit came through. At that point £1,500 has already gone through payroll:

remainder = new_annual_value - payrolled_to_date
          = 1,200 - 1,500
          = -300              // ÷ 2 remaining periods = -£150/month

The employer followed the guidance to the letter - reasonable estimate, prompt correction - and the mandated algorithm hands back negative notional pay for the last two periods, plus a year-to-date benefit figure that goes down.

Nothing published says what to do with that. As far as I can see the autumn spec has exactly two options. It can allow negative period values and falling YTDs - in which case HMRC’s systems, DWP’s systems and your reconciliation reports all have to cope with them. Or it can reject them and push every over-estimate into the end-of-year correction process instead - which contradicts the guidance’s own instruction to fix things in-year where possible. Either way, you hit this whenever an estimate turns out too high late in the year. The group most likely to hit it is leavers, whose premium refunds arrive after the P45 - the exact gap ICAEW has already flagged.

Late corrections hit much harder than early ones

The recalculate-forward rule has another property worth staring at: how hard a correction hits the payslip depends less on its size than on its date, because the rule divides the correction by the number of periods left in the year. A £1,200 true-up landing in month 1 spreads across twelve periods - £100 a month, barely noticeable. The identical £1,200 landing in month 12 has exactly one period left to go into.

£0 £400 £800 £1,200 £100 £400 £600 £1,200 M1 M3 M6 M9 M12 tax month in which the correction lands
Per-period notional-pay impact of the same £1,200 correction, by the month it lands in (monthly payroll, spread over the remaining periods). The last quarter of the tax year is where corrections bite.

The curve climbs slowly and then very fast: £400 a month if the correction lands in month 10, £600 in month 11, the whole £1,200 on one payslip in month 12 - which is also exactly where the 50% collection limit starts to bite. So cap breaches, confused-employee tickets and carry-forward activity should cluster in January-March rather than spreading evenly through the year.

This leads to a piece of practical advice I haven’t seen anywhere: it now matters when an employer’s medical scheme renews. Medical is the benefit that runs on an estimate all year and gets corrected at renewal. A scheme renewing in January gets that correction squeezed into three periods or fewer; a scheme renewing in May spreads the same correction over eleven. An employer can take most of the sting out of 2027/28 just by moving the renewal date toward the start of the tax year - and a payroll bureau could usefully record every client’s renewal month today, because that one column of data predicts which clients are going to have a rough final quarter.

Nobody has mentioned what happens to the P11D(b)

This one only shows up if you follow a single employer through the year. Say an employer gives a manager a company car and a gym membership. In 2027/28 the car is mandated, so its Class 1A goes out monthly through the FPS. The gym membership isn’t mandated until 2028, so its Class 1A is still settled the old way - annually, on a form called the P11D(b), in July 2028. Same employer, same tax, two separate channels.

The problem: today’s P11D(b) asks for Class 1A on all benefits. If the form isn’t redesigned to exclude what’s already been paid through the FPS, every employer in this position pays part of its Class 1A twice. So the form has to change - and no published document mentions a P11D(b) redesign. It doesn’t show up in the ~32-field count because it isn’t an FPS field; it’s a form owned, presumably, by a different part of HMRC than the RTI spec, which is the classic setup for a dependency getting announced late. It also means the two channels have to reconcile inside HMRC’s own systems for the first time in June-July 2028 - a date that’s about to come up again.

The real crunch is summer 2028, not April 2027

April 2027 gets all the attention, but as a delivery it’s relatively kind: a go-live on a clean slate, ~18 genuinely new fields, no legacy correction cycle running underneath it. Compare that with what the published rules stack into April-July 2028, all of it happening for the first time, all at once:

Every item on that list is a first production run, and they all land in the same quarter. If you’re planning team capacity, the shape of this project is an April 2027 go-live followed by a bigger peak twelve to fifteen months later. It’s also a big part of why I think phase 2 may slip (prediction 7).

Universal Credit is the sleeper issue

This last one crosses a departmental boundary, from HMRC into DWP. The chain has four links, and each one on its own is simple:

  1. Universal Credit tops up low household incomes, and the award shrinks as earnings rise - 55p off for every £1 earned.
  2. DWP doesn’t ask claimants what they earn. It reads earnings straight from the FPS figures employers file - the same RTI feed this whole post is about.
  3. The UC regulations (regulation 55(2)) say benefits in kind do not count as earnings for UC. Legally, a company van shouldn’t reduce anyone’s UC.
  4. Payrolling puts benefits inside taxable pay on the FPS.

So the law says “excluded” and the data feed says “included”, and somewhere in the pipeline the benefit value has to be subtracted back out. Whether DWP’s systems will do that correctly against the new 2027 fields is documented nowhere I can find, and no DWP-side change has been announced at all.

Until now this hasn’t mattered much: voluntary payrolling skews toward big employers’ company-car schemes, and company-car drivers are rarely on UC. But mandation changes who’s exposed. Around 3.1 million UC claimants are in work - 38% of the caseload, per DWP’s own statistics - and the new regime sweeps in every van driver and every employee with employer medical cover, at every employer in the country. The sums aren’t trivial either: the flat-rate van benefit is about £4,000 a year, roughly £335 a month of notional pay, and if that leaks into a UC earnings assessment the claimant loses about £184 a month. The failure mode is quiet - a chunk of money missing from a benefit award, for someone with no realistic way to trace it back to a payroll field. And when someone does ask, the question will land on the employer’s payroll team first.

The predictions, gathered up

Since this is a prediction post, let me put actual stakes in the ground:

  1. The spec lands with the Autumn Budget 2026 cycle, and it’s Annex 3 plus validation. Car block reusing the existing FPS car-data structure, per-period/YTD cash-equivalent pairs, three Class 1A fields. Confidence: high.
  2. Class 1A is paid with the normal monthly remittance, same accounts-office reference, 19th/22nd deadlines. Confidence: medium-high - HMRC has promised the detail “in a future update”.
  3. P46(car) becomes redundant for payrolled cars and is retired for them without much ceremony. Confidence: medium-high.
  4. The Class 1A adjustment fields grow - some or all of the trailed “up to 9 additional data items” appear, either at first publication or in a revision. Confidence: medium-high.
  5. The end-of-year update process is a revised final FPS, not a new submission type. Confidence: medium.
  6. The first spec under-specifies negative values and leaver corrections, and a clarifying update follows during 2027. Confidence: medium.
  7. Phase 2 slips or gets pruned. Restoring ~94 fields on a spec cycle that starts in 2027, one year after a compressed phase-1 delivery, repeats exactly the conditions that forced the first delay - and this time the build overlaps the summer-2028 pile-up described above. Confidence: medium - and I’d love to be wrong.
  8. Loans and living accommodation stay voluntary well beyond 2028. Confidence: high.
  9. The P11D(b) is redesigned for 2027/28 to exclude or net off FPS-reported Class 1A - and the change is announced later than the FPS spec, because it’s a forms change on a different track. Confidence: medium-high that the change happens; high that it arrives late.
  10. A payrolling / Universal Credit story surfaces during 2027/28 - a documented case of notional pay leaking into UC earnings assessments, most likely involving van drivers or voluntarily payrolled benefits. Confidence: medium.

And one meta-prediction: the 2027/28 penalty easement (no inaccuracy penalties except deliberate non-compliance - though late filing, late payment and interest still bite) will do a lot of load-bearing work. It is, in effect, the soft landing ICAEW asked for, and everyone’s first year will lean on it.

What to build before the spec arrives

The useful part of a five-month spec-to-go-live window is that almost everything above is buildable now, against the draft material, with the schema bolted on last:

  1. A period-level benefit model - annual value (with estimate-vs-actual state), amount payrolled to date, periods remaining, and the recalculate-forward algorithm as the single path for every change.
  2. The 50% limit carry-forward ledger - per employee, per period, with a year-end residual that survives into reporting.
  3. Class 1A per-period accumulators - period and YTD, per benefit type, with an adjustment mechanism you expect to rework once the spec lands.
  4. Correction flows - next-period FPS updates in-year; a revised-final-FPS path for the year-end tail; P60 reissue.
  5. The unglamorous features: notional pay on payslips (with wording a human can understand), the 1 June employee statement, and dual-running P11D support through at least 2028/29.
  6. Data-intake plumbing - fleet and insurer imports, bureau client cut-offs, estimate chase-ups. The tax calculation is honestly the easy bit; getting a medical premium into the system before cut-off is the product problem.

And subscribe your team to SDST’s mailing list (SDSTeam@hmrc.gov.uk) if you haven’t - the June 2026 phasing news reached developers by email before the GOV.UK pages caught up.

Sources

HMRC / GOV.UK:

Industry:

This article describes announced policy, draft guidance and draft legislation as at August 2026, plus clearly-labelled predictions. It is not tax advice, and plenty of the detail can - and probably will - change before April 2027.

Comments