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

Fri, 14 Aug 2026 00:00:00 GMT

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 330" role="img" aria-label="Diagram comparing the current annual P11D process with per-period FPS reporting from April 2027" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <text x="20" y="24" font-size="13" font-weight="600" fill="var(--text)">Today - the annual loop</text> <rect x="20" y="40" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--border)"/> <text x="120" y="66" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Benefit records</text> <text x="120" y="84" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">annual cash equivalents,</text> <text x="120" y="99" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">totted up after year end</text> <path d="M224 76 h30" stroke="var(--text-muted)" stroke-width="1.5" fill="none"/> <path d="M254 76 l-6 -4 v8 z" fill="var(--text-muted)"/> <rect x="260" y="40" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--border)"/> <text x="360" y="66" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">P11D + P11D(b)</text> <text x="360" y="84" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">filed once a year,</text> <text x="360" y="99" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">by 6 July after year end</text> <path d="M464 76 h30" stroke="var(--text-muted)" stroke-width="1.5" fill="none"/> <path d="M494 76 l-6 -4 v8 z" fill="var(--text-muted)"/> <rect x="500" y="40" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--border)"/> <text x="600" y="66" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Tax caught up later</text> <text x="600" y="84" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">tax code adjusted; Class 1A</text> <text x="600" y="99" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">paid in one July payment</text> <text x="20" y="196" font-size="13" font-weight="600" fill="var(--text)">From 6 April 2027 - every pay period</text> <rect x="20" y="212" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--border)"/> <text x="120" y="238" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Benefit records</text> <text x="120" y="256" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">per-period values,</text> <text x="120" y="271" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">feeding every payroll run</text> <path d="M224 248 h30" stroke="var(--accent)" stroke-width="1.5" fill="none"/> <path d="M254 248 l-6 -4 v8 z" fill="var(--accent)"/> <rect x="260" y="212" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--accent)"/> <text x="360" y="238" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">FPS, each period</text> <text x="360" y="256" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">notional pay + benefit fields</text> <text x="360" y="271" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">+ Class 1A fields</text> <path d="M464 248 h30" stroke="var(--accent)" stroke-width="1.5" fill="none"/> <path d="M494 248 l-6 -4 v8 z" fill="var(--accent)"/> <rect x="500" y="212" width="200" height="72" rx="8" fill="var(--bg-raised)" stroke="var(--border)"/> <text x="600" y="238" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Tax settled now</text> <text x="600" y="256" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">PAYE in the period; Class 1A</text> <text x="600" y="271" font-size="11.5" fill="var(--text-muted)" text-anchor="middle">paid with the monthly remittance</text> <text x="360" y="150" font-size="11.5" fill="var(--text-muted)" text-anchor="middle" font-style="italic">the same money - completely different plumbing</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">The move from annual, after-the-fact benefit reporting to per-period reporting on the FPS.</figcaption> </figure>

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 230" role="img" aria-label="Timeline from the October 2024 announcement to phase two in April 2028, with the current date marked in August 2026" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <line x1="40" y1="115" x2="700" y2="115" stroke="var(--border)" stroke-width="2"/> <circle cx="70" cy="115" r="6" fill="var(--text-muted)"/> <text x="70" y="76" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Oct 2024</text> <text x="70" y="92" font-size="11" fill="var(--text-muted)" text-anchor="middle">mandation announced</text> <circle cx="160" cy="115" r="6" fill="var(--text-muted)"/> <text x="160" y="145" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Apr 2025</text> <text x="160" y="161" font-size="11" fill="var(--text-muted)" text-anchor="middle">delayed to 2027</text> <circle cx="250" cy="115" r="6" fill="var(--text-muted)"/> <text x="250" y="76" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Nov 2025</text> <text x="250" y="92" font-size="11" fill="var(--text-muted)" text-anchor="middle">draft guidance + fields</text> <circle cx="340" cy="115" r="6" fill="var(--text-muted)"/> <text x="340" y="145" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Jun 2026</text> <text x="340" y="161" font-size="11" fill="var(--text-muted)" text-anchor="middle">phased rollout confirmed</text> <line x1="400" y1="52" x2="400" y2="132" stroke="var(--accent)" stroke-width="1.5" stroke-dasharray="4 4"/> <text x="400" y="42" font-size="11" font-weight="600" fill="var(--accent)" text-anchor="middle">you are here</text> <circle cx="490" cy="115" r="6" fill="var(--accent)"/> <text x="490" y="76" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Autumn 2026</text> <text x="490" y="92" font-size="11" fill="var(--text-muted)" text-anchor="middle">final specs + legislation</text> <circle cx="590" cy="115" r="6" fill="var(--accent)"/> <text x="590" y="145" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Apr 2027</text> <text x="590" y="161" font-size="11" fill="var(--text-muted)" text-anchor="middle">phase 1 live</text> <circle cx="680" cy="115" r="6" fill="var(--accent)"/> <text x="680" y="76" font-size="12" font-weight="600" fill="var(--text)" text-anchor="middle">Apr 2028</text> <text x="680" y="92" font-size="11" fill="var(--text-muted)" text-anchor="middle">phase 2 live</text> <text x="545" y="205" font-size="11" fill="var(--text-muted)" text-anchor="middle" font-style="italic">≈ 5 months from final spec to go-live</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">The road to April 2027. Gray dots are behind us; teal ones are still to come.</figcaption> </figure>

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

Phase 1, from 6 April 2027 - company cars, car fuel, vans, van fuel, employer-provided medical benefits, and taxable expenses. HMRC's line (reported by the ATT) is that this covers roughly 92% of all benefits provided in the UK.
Phase 2, from 6 April 2028 - most other benefits in kind.
Excluded for now - employment-related loans and living accommodation. These stay voluntary "until further notice", because both are genuinely awkward to value mid-year.

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 175" role="img" aria-label="Bar chart comparing about 126 data items in the full draft specification with 32 fields in phase one, of which 14 already exist and 18 are new" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <text x="20" y="28" font-size="12" fill="var(--text-muted)">Full draft spec, Nov 2025 (all benefits)</text> <rect x="20" y="38" width="560" height="22" rx="0" fill="var(--text-muted)" opacity="0.35"/> <rect x="572" y="38" width="8" height="22" rx="4" fill="var(--text-muted)" opacity="0.35"/> <text x="592" y="54" font-size="12" fill="var(--text)">≈126 data items</text> <text x="20" y="98" font-size="12" fill="var(--text-muted)">Phase 1, April 2027</text> <rect x="20" y="108" width="62" height="22" fill="var(--text-muted)" opacity="0.35"/> <text x="51" y="123" font-size="11" font-weight="600" fill="var(--text)" text-anchor="middle">14</text> <rect x="84" y="108" width="72" height="22" fill="var(--accent)"/> <rect x="150" y="108" width="10" height="22" rx="4" fill="var(--accent)"/> <text x="122" y="123" font-size="11" font-weight="600" fill="var(--bg)" text-anchor="middle">18</text> <text x="172" y="123" font-size="12" fill="var(--text)">32 fields - 14 already in RTI, 18 new</text> <text x="20" y="162" font-size="11" fill="var(--text-muted)" font-style="italic">The other ~94 items are deferred, returning for phase 2 (April 2028).</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">Phasing shrank the April 2027 build dramatically. Teal = fields that don't exist in RTI today.</figcaption> </figure>

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

Benefit Type F - cars. Make, model, date first registered, CO₂, zero-emission mileage, car identifier, an amendment indicator, calculated list price, accessories, capital contributions, private-use payments, availability and withdrawal dates, engine size, plus per-period and year-to-date cash equivalents for the car and for car fuel. If that list sounds familiar, it's because it's essentially today's optional FPS "car data" block - the 14 fields that already exist.
Benefit Type G - vans. Just per-period and YTD cash equivalents for vans and van fuel. No van-detail block.
Benefit Type I - medical. Cost or "amount foregone" (note the salary sacrifice / OpRA concept baked right into the field list), plus per-period and YTD cash equivalents.
Class 1A NIC. Three new items: Total Class 1A on BiKs (pay period), Total Class 1A on BiKs (YTD), and a Class 1A adjustment box - with HMRC on record that it's "investigating enhancements to the Class 1A adjustment fields which may introduce up to 9 additional data items".

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:

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.
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.
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.
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:

Making good: payroll the value net of what the employee is reasonably expected to reimburse (£1,000 benefit, £400 expected contribution → payroll £600). Employees have until 6 July after year end to actually pay up; employers have until 22 July to revise the final figures if they don't.
Leavers: benefits that continue after termination (a car kept for a month, medical cover running on) move from the P11D to FPS reporting, with everything reportable by 22 July after year end. What the guidance doesn't answer is ICAEW's pointed question: what happens when a value changes after the P45 - say a medical premium refund for a leaver arrives in month 11? Reporting a negative correction for someone you've already reported as leaving is exactly the kind of flow that needs spec-level support, and it isn't described anywhere yet.
Employee annual statement: employers must give each employee a statement of payrolled benefits by 1 June after year end. No prescribed format - and HMRC has said it has no plans to add benefit detail to the P60 or P45. That's a free-form document generation feature landing in your backlog.
Corrections after year end: fixable in-year via a later FPS wherever possible; after 19 April it becomes an end-of-year correction, expected to be a revision of the final FPS with extra amounts due by 19/22 July - and P60s reissued where values change. The final deadline is still marked "expected to be before 19 July", i.e. TBC.

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 265" role="img" aria-label="Column chart of an example employer's Class 1A payments from April 2027 to March 2028, showing steady monthly real-time payments of 2,500 pounds and an additional 30,000 pound annual payment for 2026 to 27 in July 2027" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <rect x="60" y="10" width="11" height="11" fill="var(--accent)"/> <text x="77" y="20" font-size="11.5" fill="var(--text-muted)">Real-time Class 1A (new system)</text> <rect x="290" y="10" width="11" height="11" fill="var(--text-muted)" opacity="0.4"/> <text x="307" y="20" font-size="11.5" fill="var(--text-muted)">Final annual Class 1A for 2026/27 (old system)</text> <line x1="60" y1="154.6" x2="700" y2="154.6" stroke="var(--border)" stroke-width="1"/> <line x1="60" y1="99.2" x2="700" y2="99.2" stroke="var(--border)" stroke-width="1"/> <line x1="60" y1="43.8" x2="700" y2="43.8" stroke="var(--border)" stroke-width="1"/> <text x="52" y="214" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£0</text> <text x="52" y="158.6" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£10k</text> <text x="52" y="103.2" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£20k</text> <text x="52" y="47.8" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£30k</text> <rect x="74.7" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="128" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="181.3" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="234.7" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="234.7" y="34" width="24" height="164.2" rx="4" fill="var(--text-muted)" opacity="0.4"/> <rect x="288" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="341.3" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="394.7" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="448" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="501.3" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="554.7" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="608" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <rect x="661.3" y="200.2" width="24" height="9.8" fill="var(--accent)"/> <line x1="60" y1="210" x2="700" y2="210" stroke="var(--border)" stroke-width="1"/> <text x="86.7" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">Apr 27</text> <text x="246.7" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">Jul 27</text> <text x="406.7" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">Oct 27</text> <text x="566.7" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">Jan 28</text> <text x="673.3" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">Mar 28</text> <line x1="262" y1="60" x2="286" y2="60" stroke="var(--text-muted)" stroke-width="1"/> <text x="292" y="57" font-size="11.5" fill="var(--text)">£30,000 - last annual Class 1A,</text> <text x="292" y="72" font-size="11.5" fill="var(--text-muted)">for 2026/27, due by 19/22 July 2027</text> <text x="470" y="185" font-size="11.5" fill="var(--text)">£2,500 a month, every month</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">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.</figcaption> </figure>

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:

£2,500 × 11 = £27,500 for tax months 1-11 of 2027/28. (Month 12 covers 6 March to 5 April 2028 and isn't due until 22 April, so it just misses the year.)
£30,000 in July 2027: the final old-style annual bill, for 2026/27.

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 185" role="img" aria-label="Two horizontal bars comparing an employer's Class 1A payments: 30,000 pounds in a normal year, versus 57,500 pounds between April 2027 and March 2028, made up of the 30,000 pound annual bill for 2026 to 27 plus 27,500 pounds of monthly real-time payments" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <text x="20" y="26" font-size="12" fill="var(--text-muted)">Any normal year</text> <rect x="20" y="34" width="323" height="22" fill="var(--text-muted)" opacity="0.35"/> <text x="351" y="50" font-size="12" fill="var(--text)">£30,000</text> <text x="20" y="100" font-size="12" fill="var(--text-muted)">April 2027 - March 2028</text> <rect x="20" y="108" width="323" height="22" fill="var(--text-muted)" opacity="0.35"/> <text x="181" y="123" font-size="11" font-weight="600" fill="var(--text)" text-anchor="middle">£30,000</text> <rect x="345" y="108" width="297" height="22" fill="var(--accent)"/> <text x="493" y="123" font-size="11" font-weight="600" fill="var(--bg)" text-anchor="middle">£27,500</text> <text x="650" y="123" font-size="12" fill="var(--text)">= £57,500</text> <rect x="20" y="152" width="11" height="11" fill="var(--text-muted)" opacity="0.35"/> <text x="37" y="161" font-size="11.5" fill="var(--text-muted)">last annual bill, for 2026/27 (old system)</text> <rect x="320" y="152" width="11" height="11" fill="var(--accent)"/> <text x="337" y="161" font-size="11.5" fill="var(--text-muted)">tax months 1-11 of 2027/28, paid monthly (new system)</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">The same employer, the same benefits: 23 months of Class 1A liability get paid inside 12.</figcaption> </figure>

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.

<figure style="margin:2rem 0"> <div style="overflow-x:auto"> <svg viewBox="0 0 720 255" role="img" aria-label="Bar chart showing the per-period impact of a 1,200 pound benefit correction depending on which tax month it lands in: 100 pounds per month if it lands in month 1, rising slowly at first, then 300 pounds in month 10, 600 pounds in month 11, and the full 1,200 pounds in month 12" style="width:100%;min-width:600px;height:auto;font-family:inherit"> <line x1="60" y1="153.3" x2="700" y2="153.3" stroke="var(--border)" stroke-width="1"/> <line x1="60" y1="96.7" x2="700" y2="96.7" stroke="var(--border)" stroke-width="1"/> <line x1="60" y1="40" x2="700" y2="40" stroke="var(--border)" stroke-width="1"/> <text x="52" y="214" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£0</text> <text x="52" y="157.3" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£400</text> <text x="52" y="100.7" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£800</text> <text x="52" y="44" font-size="10.5" fill="var(--text-muted)" text-anchor="end">£1,200</text> <rect x="70.7" y="195.8" width="32" height="14.2" fill="var(--accent)"/> <rect x="124" y="194.5" width="32" height="15.5" fill="var(--accent)"/> <rect x="177.3" y="193" width="32" height="17" fill="var(--accent)"/> <rect x="230.7" y="191.1" width="32" height="18.9" fill="var(--accent)"/> <rect x="284" y="188.7" width="32" height="21.3" fill="var(--accent)"/> <rect x="337.3" y="185.7" width="32" height="24.3" fill="var(--accent)"/> <rect x="390.7" y="181.7" width="32" height="28.3" fill="var(--accent)"/> <rect x="444" y="176" width="32" height="34" fill="var(--accent)"/> <rect x="497.3" y="167.5" width="32" height="42.5" fill="var(--accent)"/> <rect x="550.7" y="153.3" width="32" height="56.7" fill="var(--accent)"/> <rect x="604" y="125" width="32" height="85" fill="var(--accent)"/> <rect x="657.3" y="40" width="32" height="170" fill="var(--accent)"/> <text x="86.7" y="190" font-size="11" fill="var(--text)" text-anchor="middle">£100</text> <text x="566.7" y="147" font-size="11" fill="var(--text)" text-anchor="middle">£400</text> <text x="620" y="119" font-size="11" fill="var(--text)" text-anchor="middle">£600</text> <text x="673.3" y="33" font-size="11" font-weight="600" fill="var(--text)" text-anchor="middle">£1,200</text> <line x1="60" y1="210" x2="700" y2="210" stroke="var(--border)" stroke-width="1"/> <text x="86.7" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">M1</text> <text x="177.3" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">M3</text> <text x="337.3" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">M6</text> <text x="497.3" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">M9</text> <text x="673.3" y="228" font-size="10.5" fill="var(--text-muted)" text-anchor="middle">M12</text> <text x="380" y="247" font-size="11" fill="var(--text-muted)" text-anchor="middle" font-style="italic">tax month in which the correction lands</text> </svg> </div> <figcaption style="font-size:0.85rem;color:var(--text-muted)">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.</figcaption> </figure>

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:

6 April 2028: phase 2 goes live - the ~94 deferred fields return, presumably against a spec published in autumn 2027, i.e. the same compressed window as phase 1 but with five times the field count.
19 April 2028: the cutover after which every 2027/28 fix becomes an end-of-year correction - the first production run of a process whose transport mechanism still isn't specified.
1 June 2028: employee annual statements for 2027/28, a brand-new obligation, format uninvented.
6 July 2028: P11Ds for 2027/28's non-mandated benefits and the making-good deadline for payrolled ones.
19/22 July 2028: balancing Class 1A payments from the year-end update process, P11D(b) for the non-mandated channel, P60 reissues where values moved.

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:

Universal Credit tops up low household incomes, and the award shrinks as earnings rise - 55p off for every £1 earned.
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.
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.
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:

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.
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".
P46(car) becomes redundant for payrolled cars and is retired for them without much ceremony. Confidence: medium-high.
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.
The end-of-year update process is a revised final FPS, not a new submission type. Confidence: medium.
The first spec under-specifies negative values and leaver corrections, and a clarifying update follows during 2027. Confidence: medium.
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.
Loans and living accommodation stay voluntary well beyond 2028. Confidence: high.
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.
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:

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.
The 50% limit carry-forward ledger - per employee, per period, with a year-end residual that survives into reporting.
Class 1A per-period accumulators - period and YTD, per benefit type, with an adjustment mechanism you expect to rework once the spec lands.
Correction flows - next-period FPS updates in-year; a revised-final-FPS path for the year-end tail; P60 reissue.
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.
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:

Changes to reporting of benefits in kind from April 2027 (L-Day policy paper + draft legislation, July 2026)
Interim draft guidance: reporting benefits in kind in real time - especially Annex 3 (FPS fields) and the phased introduction
Technical note: mandating the reporting of benefits in kind through payroll software - an update (April 2025)
Employer Bulletin, June 2026
RTI support for software developers (spec collection)
Benefit in kind statistics commentary, July 2026 - source of the ~£9.5bn total taxable value used in the derivations
The Universal Credit Regulations 2013, regulation 55 - the benefits-in-kind exclusion from UC employed earnings
DWP: Universal Credit quarterly statistics, February 2026 - the 3.1 million in-work claimants figure

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.

Payroll Explained