Company cars and medical cover become monthly payroll numbers in 2027.

The data has not moved. The deadline has.

Start with the arithmetic, because it is the part that decides how much work this is. Under the current process a company car value has to be right once. The tax year ends on 5 April, the P11D and P11D(b) follow, and the Class 1A payment clears by 22 July. That is a tail of roughly three and a half months, and it quietly absorbs a great deal: a fleet report that arrives late, a car swap nobody told payroll about, a medical schedule that needed chasing. One annual reconciliation cleans all of it up at once.

From 6 April 2027 that tail is gone for five benefit types. The HMRC policy paper, updated on 23 July 2026, says that from April 2027 most employers who provide medical benefit, company cars, vans, or car and van fuel will no longer be able to report them after the end of the tax year, and must calculate Income Tax and Class 1A National Insurance contributions in real time and report them through Real Time Information. From April 2028 most remaining benefits follow, excluding employer provided loans and accommodation.

The benefit data itself has not moved anywhere. Company car and fuel values still come from a fleet system or a leasing provider. Medical cover still comes from a broker or an insurer, and it still changes on joiners, leavers and renewals. What changes is that the same information now has to reach payroll before each cut off rather than before one deadline in July. HMRC says this out loud in its own preparation chapter, which asks employers to look at how third party benefit data reaches the payroll team, how quickly changes are sent, and to align that with how often payroll is run. That sentence is the whole project.

The good news is that this is a solvable operations problem with a known shape, and HMRC has made it considerably more solvable by being explicit about what it expects when the data is not there yet. That expectation is the useful part of the guidance and it is covered less than the dates are.

What the guidance says, read from the text.

The phasing was confirmed in June 2026 after HMRC engagement with employers, software developers and representative bodies. The original plan mandated everything except loans and accommodation from April 2027. The revised plan takes five benefit types first, and the interim guidance notes that the change removes 94 Real Time Information data fields for benefits from the April 2027 scope, which is a fair measure of how much smaller the first phase became. Final guidance for phase one is due to align with Autumn Budget 2026, and the secondary legislation setting the detailed scope and operational rules is to be introduced at Budget 2026. The table below works through the provisions that reach a finance or payroll owner.

Two rows deserve more room than a table cell. The first is the estimate rule, which reframes the whole exercise. The second is the divide and round down rule, which quietly decides what your monthly reconciliation can ever look like. Both are worth taking slowly.

The safe harbour is the estimate, not the exact number.

The instinct in a well run finance function is to wait for the source document. You do not accrue a number you cannot support, and you certainly do not file one. Applied to payrolled benefits, that instinct produces exactly the behaviour HMRC has said it will penalise.

Read the interim guidance on how to report a benefit in real time and the expectation is consistent throughout. If you are not sure what the value of a benefit is at the start of the tax year, you can make an estimate of the cash equivalent and adjust it later. You can use known taxable values from previous years for similar benefits where accurate information is not available. Every effort must be made to make a reasonable estimate. And then the instruction that matters most: report benefits as close to the relevant pay period as possible and not wait until the end of the year to do so.

The penalties chapter closes the loop from the other end. It states that no penalties will be charged if a reasonable estimate of the taxable value is used due to insufficient information. It also lists, among the scenarios where penalties and interest may be applied from 2028 to 2029, the incorrect use of the end of year process, giving as its example reporting all benefits in kind at the end of the year instead of during the year. Put those two sentences next to each other and the operating rule writes itself. An estimate posted on time is protected. A correct figure posted in July is not.

The same chapter is worth reading carefully on the first year, because it is widely described as a penalty free year and it is not quite that. Errors related to mandatory payrolling in RTI returns for 2027 to 2028 will not attract inaccuracy penalties unless there is evidence of deliberate non compliance, and in the next sentence, existing late filing and late payment penalties still apply. The relief is on the number, not on the date. For a team deciding where to spend its preparation budget, that is a clear signal: the deadline machinery matters more than the valuation machinery in year one.

This is genuinely good news for anyone who has looked at a fleet feed and wondered how it could possibly be monthly. It does not have to be complete. It has to be on time, reasonable, and recorded. The practical consequence is that an estimate policy is a real deliverable with a real deadline. Decide the default value for each benefit type, decide who can depart from it, and store the basis alongside the number so that it can be evidenced later. HMRC asks for records of how you accounted for each expense or benefit, kept for three years from the end of the tax year, and an estimate with its basis attached satisfies that in a way a remembered decision does not.

What the rounding rule does to your reconciliation, measured.

Now the arithmetic. For each benefit and each employee, HMRC says to identify the cash equivalent, divide it by the number of pay periods in the tax year for that employee, and round the result down to the nearest 2 decimal places. Its own example is clean: a cash equivalent of £2,100 for a monthly paid employee gives £175 in each of twelve months, and £175 times twelve is £2,100 exactly.

Most cash equivalents are not clean. Because the rule rounds down rather than to nearest, the sum of the twelve periodic amounts is always at or below the cash equivalent and never above it. A benefit worth £2,101 gives £175.08 a month, and twelve of those is £2,100.96. Four pence goes missing, and it goes missing in the same direction every time, on every line, every year. HMRC own second worked example does the same thing: a 4 weekly employee whose benefit is revised to £2,800 after £1,200 has been payrolled leaves £1,600 across seven periods, which is £228.57 each, and seven of those is £1,599.99.

The size of that gap is worth knowing before you set a tolerance, so we measured it exhaustively rather than estimating it. Taking every cash equivalent from one penny to twenty thousand pounds, two million values in all, and applying the rule at each common pay frequency, the drift has a precise shape.

A shortfall of a few pence a line is not a financial problem. It is a process problem, because it decides how many rows a monthly reconciliation hands you to investigate. To see that in practice we built a 250 line benefits register totalling £1,399,998.75 of annual cash equivalents, built the matching payroll register under the rounding rule, and ran the pair through the reconciliation tool published on this site. The two lists share no key, which is the common real case, since a fleet file is usually keyed on registration and payroll on employee number, so the engine falls back to matching on amount. The whole population is correct. Nothing is wrong with any line. The only variable is the tolerance.

The first row is the one to sit with. On a register where nothing at all is wrong, a strict match closes 20 lines out of 250 and hands you 230 exceptions. A team that meets that in the first live month will reasonably conclude the data is broken, and will spend the year chasing arithmetic. Across the whole population the actual money involved is £13.71.

The last row is the fix, and it is not a matter of judgement. The band comes from the number of pay periods, so it can be derived, written down, and approved once: eleven pence a line a year on a monthly payroll, so set the tolerance just above it. Set it per pay frequency if you run more than one, because a weekly population drifts nearly five times as far. From there, every exception the reconciliation returns is a real event, which is the only kind worth a controller time: a benefit that changed, a starter or leaver mid period, a feed that did not arrive.

There is a second reconciliation, and the important thing about it is that it will never close at all. Employers must not deduct more than 50 percent of an employee pay in tax in a pay period, which HMRC calls the overriding limit. Up to half can be deducted with the rest carried forward where possible, and anything still uncollected at the end of the year is picked up by HMRC through the P800 reconciliation, Simple Assessment or Self Assessment. So tax reported on benefits and tax collected on benefits are structurally different numbers, and the difference leaves your books entirely. Keep them as two checks with two expectations, and neither one will surprise you.

The Class 1A calendar changes shape.

Employer National Insurance on benefits is currently a single annual event, and the June 2026 Employer Bulletin describes it in the plainest possible terms: electronic payments for Class 1A declared on the P11D(b) for the tax year ended 5 April 2026 must clear into the HMRC account by 22 July 2026, using the 13 character Accounts Office reference followed by 2613, where 26 identifies the tax year and 13 identifies the payment as Class 1A. One reference, one date, one number.

From April 2027 the mandated benefits carry their Class 1A in real time through RTI alongside the Income Tax. It is worth being careful about what is settled here and what is not. The scope and the principle are settled and published. The detailed mechanics are still arriving: ICAEW reported in June 2026 that further HMRC guidance on how Class 1A will be calculated and reported in real time was still expected, including the option to pay real time Class 1A on non mandated benefits, and HMRC says final phase one guidance will align with Autumn Budget 2026. Plan the shape now and leave the mechanics loosely coupled.

What is worth modelling immediately is the 2027 to 2028 year on its own. The Class 1A for 2026 to 2027 still runs through the existing annual route and clears in July 2027, while the mandated benefits are already being reported in real time from 6 April 2027. The liability is not doubled, the timing simply overlaps once. A team that budgets employer National Insurance on benefits as a July event will find it arriving earlier in the year, and a team that models the transition year as a repeat of the prior year will get that year wrong in both directions.

ICAEW is also the clearest source on a point that catches out the teams furthest ahead. Under the existing voluntary payrolling regime, the Income Tax is collected during the tax year from the employee pay, but the employer must still report and pay any Class 1A due through the P11D(b) after the end of the tax year. An employer already payrolling voluntarily has therefore already made the employee side of this change and still has the employer National Insurance side ahead of it. That is worth saying out loud before anyone reports the project as low risk on the basis that the benefits are already in the payroll.

There is an employee side to the calendar too, and it is a communications job with a date on it. HMRC will automatically remove benefits from employee tax codes ready for the start of mandatory payrolling on 6 April 2027, but will keep the existing process of collecting underpayments from previous years, so those stay in the code. The result is that a benefit holding employee can see tax on this year benefit in the payslip and a prior year catch up in the tax code at the same time, and reasonably think they are being taxed twice. HMRC asks employers to explain this clearly and early. It is a much easier conversation in the autumn before than in the April after.

The record shape that makes a monthly cut off work.

Everything above points at the same handful of records. A benefit needs to be a thing in its own right rather than a column on an employee, because it has a source, a confirmation date, a status and a history. An estimate needs to carry its basis, because that basis is the evidence. The amount payrolled in each period needs to be stored rather than recomputed, because the recalculation rule depends on what has actually been payrolled so far. And the feed itself deserves a record, because a feed that has not arrived should be a row in a query rather than something somebody notices in week three.

# Benefits modelled so the monthly cut off has something to stand on.
# Every identifier, name and figure below is a placeholder and describes no
# real person, employer, fleet provider or insurer.

benefit_feed:                                  # the source is a modelled thing
  - feed_id: "FEED-FLEET-01"
    provider: "fleet management provider"
    covers: ["company_car", "car_fuel"]
    expected_day_of_month: 6                   # ahead of the payroll cut off
    provider_owner: "account manager, named in the contract"
    internal_owner: "reward.lead"
    last_received_on: "2027-09-06"
  - feed_id: "FEED-MEDICAL-01"
    provider: "medical cover broker"
    covers: ["medical_benefit"]
    expected_day_of_month: 8
    internal_owner: "reward.lead"
    last_received_on: "2027-08-08"              # one month late as at September

employee_benefit:                               # the benefit, not a column
  benefit_id: "BEN-88214-CAR-02"
  employee_id: "EMP-88214"
  benefit_type: "company_car"
  tax_year: "2027-28"
  pay_periods: 12                               # drives the divide and the band
  cash_equivalent: 7412.35
  value_status: "confirmed"                     # confirmed | estimated
  estimate_basis: null                          # required when estimated
  source_feed_id: "FEED-FLEET-01"
  source_confirmed_on: "2027-09-06"
  valid_from: "2027-08-01"
  valid_to: null

  # 7412.35 / 12 = 617.6958..., rounded DOWN to 617.69.
  # 617.69 x 12 = 7412.28. The register sits 7p above the payroll, for ever.
  periodic_amount: 617.69

employee_benefit_period:                        # stored, never recomputed
  - benefit_id: "BEN-88214-CAR-02"
    period: "2027-08"
    amount_payrolled: 617.69
    reported_on_fps: "2027-08-28"
  - benefit_id: "BEN-88214-CAR-02"
    period: "2027-09"
    amount_payrolled: 617.69
    reported_on_fps: "2027-09-28"

benefit_change_event:                           # a car swap, months later
  event_id: "BCE-3391"
  benefit_id: "BEN-88214-CAR-02"
  changed_on: "2027-11-14"
  cash_equivalent_from: 7412.35
  cash_equivalent_to: 8100.00
  reason: "vehicle replaced"
  first_period_carrying_new_figure: "2027-11"
  # HMRC method: revised annual figure less what has been payrolled so far,
  # spread equally over the remaining pay periods for this employee.

making_good_expectation:                        # feeds the monthly figure
  benefit_id: "BEN-88214-CAR-02"
  amount_expected: 0.00
  basis: null
  owner: "reward.lead"

reconciliation_tolerance:                       # derived, documented, stored
  pay_frequency: "monthly"
  pay_periods: 12
  tolerance_gbp: 0.12
  derivation: "cash equivalent divided by 12 rounded down to 2dp, so the annual
    shortfall per line is bounded at 11p; measured across all cash equivalents
    from 1p to 20000.00, mean 5.5p, maximum 11p. Set just above the ceiling."
  approved_by: "financial.controller"
  approved_on: "2027-03-02"

# The exception query. Run it with the payroll, not after the year end.

SELECT ref, reason FROM (
  -- a feed that has not arrived for the current period, so any figure
  -- carried this month is last month figure wearing a new date
  SELECT feed_id AS ref, 'benefit feed overdue' AS reason
    FROM benefit_feed
   WHERE last_received_on < date_trunc('month', CURRENT_DATE)
  UNION ALL
  -- an estimated value with no recorded basis, which is the one case
  -- where the estimate does not protect you
  SELECT benefit_id, 'estimated value with no basis recorded'
    FROM employee_benefit
   WHERE value_status = 'estimated' AND estimate_basis IS NULL
  UNION ALL
  -- an estimate that has been carried for long enough to be a decision
  SELECT benefit_id, 'estimated value unconfirmed for three periods'
    FROM employee_benefit
   WHERE value_status = 'estimated'
     AND source_confirmed_on < CURRENT_DATE - INTERVAL '3 months'
  UNION ALL
  -- a change event that has not yet reached a pay period
  SELECT e.event_id, 'benefit change not yet carried into payroll'
    FROM benefit_change_event e
    LEFT JOIN employee_benefit_period p
      ON p.benefit_id = e.benefit_id
     AND p.period = e.first_period_carrying_new_figure
   WHERE p.benefit_id IS NULL
  UNION ALL
  -- a benefit with no period row this month, so nothing was payrolled
  SELECT b.benefit_id, 'benefit in force with nothing payrolled this period'
    FROM employee_benefit b
    LEFT JOIN employee_benefit_period p
      ON p.benefit_id = b.benefit_id
     AND p.period = to_char(CURRENT_DATE, 'YYYY-MM')
   WHERE b.valid_to IS NULL AND p.benefit_id IS NULL
  UNION ALL
  -- the register and the payroll differ by more than the rounding band
  SELECT b.benefit_id, 'register to payroll gap outside the rounding band'
    FROM employee_benefit b
    JOIN (SELECT benefit_id, SUM(amount_payrolled) AS paid
            FROM employee_benefit_period GROUP BY benefit_id) s
      ON s.benefit_id = b.benefit_id
   WHERE ABS(b.cash_equivalent - s.paid) > 0.12
  UNION ALL
  -- an employee with a benefit and no earnings, which needs an FPS of its own
  SELECT b.employee_id, 'benefit held by an employee with no earnings'
    FROM employee_benefit b
    JOIN employee e ON e.employee_id = b.employee_id
   WHERE e.period_earnings = 0 AND b.valid_to IS NULL
) exceptions
ORDER BY reason, ref;

The exception query at the foot is the piece that repays the effort fastest. Run it alongside the payroll rather than after the year end and every one of its rows is still cheap to fix: a feed that has not landed, an estimate carried so long it has become a decision, a change event that has not reached a pay period, a benefit in force with nothing payrolled against it this month. None of these is hard to correct in the month it happens. All of them are expensive in July.

Data and integration considerations.

• The benefit is its own record with a source, not a column on the employee. Give it a type, a cash equivalent, a valid from and valid to, the source system it came from, the date that source last confirmed it, and the employee it belongs to. The source and the confirmation date are what let you answer how current any figure is without asking anybody.
• The estimate is a first class value with a basis, not a placeholder. Hold whether the current cash equivalent is confirmed or estimated, what the estimate was derived from, who set it and when. HMRC may ask for evidence of how you accounted for a benefit, and a stored basis answers that in one query.
• The periodic amount is stored, not recomputed on demand. Record what was actually payrolled in each period for each benefit. The recalculation rule needs the amount payrolled so far, and a figure that is rebuilt from current inputs cannot tell you what a past period actually carried.
• A change to a benefit is an event with a date, kept apart from the value. When the cash equivalent changed, what it changed from and to, what caused it, and which period first carried the new figure. This is what makes a mid year car swap explainable months later.
• The making good expectation lives with the benefit and has an owner. The amount expected, the basis for expecting it, who owns that expectation, and the actual amounts received against it. The monthly figure depends on it, so it cannot sit in a side agreement.
• The feed is a modelled thing. Each third party source gets a record: the provider, the benefit types it covers, the expected arrival day, the owner on both sides, and the date it last arrived. A feed that has not arrived is then a row in a query rather than a thing somebody notices late.
• The reconciliation tolerance is configuration, derived and documented. Store it per pay frequency with the reasoning attached, because the band comes from the number of pay periods. A tolerance nobody can explain gets widened under pressure until it stops being a control.
• Keep the Class 1A view separate from the Income Tax view. One is an employer liability moving into the real time cycle. The other is an employee deduction subject to the 50 percent overriding limit with a residue that leaves your books entirely. Modelling them as one number makes both harder to reconcile.

An implementation checklist that fits the time available.

There is roughly a year and a half before the first mandated payroll run. That is comfortable if the work starts with the feeds and the policy rather than with the software, because the software question is largely answered for you: payroll providers are building to HMRC specifications, with updated technical specifications expected in autumn 2026. What nobody can build for you is the arrangement by which a fleet provider tells you about a car change before your cut off.

1. List the employees holding one of the five phase one benefits, and find out today where each value comes from. Company car and fuel data usually lives in a fleet system or a leasing provider portal, and medical cover with a broker or an insurer. Write down, per feed, who sends it, in what format, on what day, and who in payroll receives it. HMRC own preparation chapter asks for exactly this, and says the flow needs to be aligned with how often payroll is run.
2. Set a benefit data cut off and publish it, the same way you publish the payroll cut off. The recalculation rule means a value that arrives after the cut off does not vanish, it gets spread across the remaining periods for that employee. That is workable and it is much easier when everybody knows the date rather than negotiating it monthly.
3. Write an estimate policy before April 2027, not after the first gap. HMRC says you can use known values from previous years for similar benefits where accurate information is not available. Decide in advance what your default estimate is for a car in a given band, for a fuel benefit and for a medical premium, who approves a departure from it, and how the basis is recorded. The guidance is clear that no penalty attaches to a reasonable estimate made because the information was not there.
4. Derive your reconciliation tolerance from the rounding rule rather than picking a round number. For a monthly payroll the drift is bounded at 11 pence per line per year, so set the tolerance just above it. Do the same per pay frequency if you run more than one, because the band scales with the number of periods.
5. Separate the reconciliation that should close from the one that never will. The benefits register against the payroll register should close inside the rounding band. Tax reported against tax collected will not, because the 50 percent overriding limit pushes the balance out to a P800, Simple Assessment or Self Assessment. Two checks, two expectations.
6. Find the people with benefits and no earnings before April 2027. A director on no salary with a company car needs an FPS showing no earnings and no tax, with the Class 1A still paid. These cases are usually few, always awkward, and much cheaper to identify in a query now than in the first live payroll run.
7. Put the making good expectation somewhere payroll can read it. If an employee is expected to contribute towards a benefit, the amount payrolled is the cash equivalent net of what they are reasonably expected to make good. That expectation belongs in the benefit record with an owner, because when it changes the monthly figure changes with it.
8. Plan the Class 1A cash calendar for 2027 to 2028 specifically. The 2026 to 2027 Class 1A still clears by 22 July 2027 under the current annual mechanism, while the mandated benefits are being reported in real time from 6 April 2027. Model that year on its own rather than assuming a flat repeat, and note that HMRC detailed guidance on real time Class 1A calculation and reporting is still arriving.
9. Build the 1 June employee statement as a report over the register, now. There is no HMRC template and none is coming, so it is your format. A report generated from the same data that fed the FPS is a half day of work. A statement assembled by hand the week before the deadline is not.
10. Brief employees in the autumn before April 2027. HMRC will remove benefits from tax codes ready for the start of mandatory payrolling, but will leave earlier year underpayments in place, so a benefit holding employee can see tax on this year benefit and a prior year catch up at the same time. HMRC asks employers to explain this clearly, and it is much better received before the first payslip than after it.

Where this goes wrong, and how to stay ahead of it.

• Reading the 2027 to 2028 easement as a penalty free year. The penalties chapter says inaccuracy penalties will not be charged unless there is evidence of deliberate non compliance, and in the same breath says existing late filing and late payment penalties still apply. The relief is on the number, not on the date. Plan for the deadline and you get the relief as a safety net rather than as a strategy.
• Assuming an employer already payrolling voluntarily is ready. Under the existing voluntary regime the Income Tax moves into the year but the Class 1A is still reported and paid through the P11D(b) after the end of the tax year. Real time Class 1A is new even for the teams furthest ahead, which is worth knowing before anyone reports the project as low risk.
• Waiting for the invoice before reporting the benefit. It is the instinct of every well run finance function and here it works against you. HMRC asks for the report when you become aware of a benefit or can estimate it, and names reporting everything at the end of the year in its list of penalisable scenarios from 2028 to 2029. Post the estimate, then correct it.
• Setting a zero tolerance reconciliation on the benefits register. The rule is divide and round down, so the payroll total sits below the register total by construction. On a 250 line register we measured a strict match closing 20 lines out of 250 with nothing actually wrong. A team that meets that in month one will spend the year chasing arithmetic instead of exceptions.
• Treating the end of year update process as the filing route. It exists to correct under and over reporting, with everything reported by 22 July and additional Class 1A payable by 19 July, or 22 July electronically. Used as a way to batch the year up, it is the specific behaviour the penalties chapter calls out.
• Leaving the third party feeds as an email arrangement. A fleet report that arrives when someone remembers, or an insurer schedule that lands on the fifteenth, was fine against an annual deadline with a three month tail. Against twelve cut offs it produces twelve recalculations. Naming an owner and a date per feed is the cheapest fix available.
• Forgetting that a partially exempt expense goes through the payroll in full. The employee then claims the deduction for the exempt part through the existing employment expense claim route. A process that nets it down before payroll produces a wrong FPS and a confused employee.
• Scoping the project to phase one and stopping. Most remaining benefits arrive in April 2028. A design that hard codes the five phase one types will be reopened in a year, while a design that treats benefit type as data will absorb the second phase quietly.

What the evidence file should contain.

HMRC asks for records of how you accounted for each expense or benefit, kept for three years from the end of the tax year they relate to. Handled as a set of records rather than as a year end exercise, that file assembles itself as a by product of running the monthly process.

• The benefit register with full history, showing each cash equivalent, its source, whether it was confirmed or estimated, and the dates each value was in force.
• The estimate policy as approved, with the date it was adopted, and the recorded basis for each estimated value actually used in a period.
• The period by period record of amounts payrolled per benefit per employee, which is what evidences the divide and round down calculation and any mid year recalculation.
• The feed register, showing for each third party source when data was expected, when it arrived, and what was done in the periods where it did not.
• The monthly reconciliation of the benefits register to the payroll register, with the tolerance used, the reasoning for that tolerance, and the exceptions that fell outside it with their resolutions.
• The separate record of tax reported against tax collected, showing the amounts restricted by the 50 percent overriding limit and carried forward or passed to HMRC end of year processes.
• The end of year benefits update, where used, showing what was corrected, the revised final FPS, and the additional Class 1A paid by the 19 or 22 July date.
• The employee statements issued by 1 June, and the record of when and how they were sent.
• The employee communications issued before April 2027 explaining the change to tax codes and the overlap with earlier year underpayments.

Questions worth asking at the next finance meeting.

• For each of the five phase one benefits, which system holds the value today, and who sends it to payroll?
• What is our benefit data cut off going to be, and has anybody outside payroll agreed to it?
• If a company car changes in month 8, how does payroll find out, and by when?
• What is our default estimate for a benefit we cannot value in time, and who approved it?
• Do we record whether a cash equivalent is confirmed or estimated, or only the number?
• What tolerance are we going to reconcile the benefits register at, and can we explain where it came from?
• Which employees receive a benefit but no earnings, and do we know how many there are?
• Have we modelled the 2027 to 2028 Class 1A cash calendar on its own, rather than as a repeat of the prior year?
• Who is building the 1 June employee statement, and against which data?
• When are we telling benefit holding employees that their take home pay is going to change, and what are we telling them about earlier year underpayments?

A yearly form becomes a monthly input, and that is manageable.

Reported as a compliance deadline, this looks like a large piece of work with a hard date on it. Read as an operations design brief, it is a small number of decisions that can all be made in the next few months. Where does each benefit value come from, and who sends it. What day does it have to arrive. What do we post when it does not arrive, and who approved that default. What tolerance do we reconcile at, and where did that number come from. Who tells employees, and when.

The single most useful thing in the guidance is the permission to be approximately right on time. HMRC asks for a reasonable estimate reported close to the pay period rather than an exact figure reported late, and it says in as many words that no penalty attaches to a reasonable estimate made because the information was not there. Most of the anxiety about monthly benefit reporting dissolves once that is understood and written into a policy.

The cheapest place to start is the reconciliation, because you can practise it this year on data you already hold. Export your current benefits register and your payroll data, put them side by side, and see what the residual actually looks like before the deadline makes it urgent. The Rivane reconciliation tool takes two lists, matches on a shared reference first and then on amount within a tolerance you set, and hands back what is left over. It is the same engine the measurements above came from, it runs in the browser, and it is free to use.

Sources

• HM Revenue and Customs, Mandatory reporting of benefits in kind in Real Time Information (RTI) from April 2027, policy paper, updated 23 July 2026. Downloaded and read directly rather than through a fetched summary. Source for the scope of the April 2027 phase (medical benefit, company cars, vans, car and van fuel), for the April 2028 extension to most remaining benefits other than employer provided loans and accommodation, for the requirement to calculate Income Tax and Class 1A National Insurance contributions in real time and report them through RTI, for the amendments to Part 11 of the Income Tax (Earnings and Pensions) Act 2003 and the Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682), for the power to modify how Schedule 24 to the Finance Act 2007 applies so that penalties are not charged for non deliberate inaccuracies for one year, and for the statement that secondary legislation setting the detailed scope and operational rules is to be introduced at Budget 2026.
• HM Revenue and Customs, Mandatory payrolling of benefits in kind and expenses, interim guidance and legislation. Read directly, chapter by chapter. Source for the divide by pay periods and round down to two decimal places rule and both of HMRC own worked examples, for the in year recalculation method, for the instruction to report on a reasonable estimate rather than wait, for the 50 percent overriding limit and what happens to the uncollected balance, for the making good treatment and the 6 July and 22 July dates, for the end of year benefits update process, for the employee statement due by 1 June, for the record keeping period of three years, for the phasing note recording the removal of 94 RTI data fields, and for the preparation chapter that asks employers to assess the information flow from third party benefit providers and align it with payroll frequency.
• HM Revenue and Customs, Mandatory payrolling of benefits in kind and expenses, the chapter on penalties and interest. Read directly. Source for the position that customers who make an error related to mandatory payrolling in their RTI returns for 2027 to 2028 will not be charged inaccuracy penalties unless there is evidence of deliberate non compliance, that existing late filing and late payment penalties still apply, that from 2028 to 2029 onwards penalties and interest apply and the listed scenarios include incorrect use of the end of year process such as reporting all benefits at the end of the year instead of during it, and that no penalties will be charged where a reasonable estimate of the taxable value is used because there was not enough information.
• HM Revenue and Customs, Mandatory payrolling of benefits in kind and expenses, the chapter on getting ready. Read directly. Source for the confirmation that employers do not need to register in order to payroll the mandated benefits, that the service to register to voluntarily payroll non mandated benefits goes live in November 2026 with a registration deadline of 5 April 2027, that HMRC will automatically remove the benefits from employee tax codes ready for 6 April 2027 while retaining underpayments from previous years in those codes, and for the explanation employers are asked to give employees about paying tax in the year a benefit is received while still catching up on earlier years.
• HM Revenue and Customs, June 2026 issue of the Employer Bulletin. Read directly. Source for the current annual Class 1A mechanism as it still operates: electronic payments for Class 1A declared on the P11D(b) for the tax year ended 5 April 2026 must clear into the HMRC account by 22 July 2026, using the 13 character Accounts Office reference followed by 2613, where 26 identifies the tax year and 13 identifies the payment as Class 1A. Also carries the June 2026 announcement that mandatory payrolling will launch in phases.
• ICAEW Insights, Plans for mandatory payrolling of benefits in kind revised, 16 June 2026. Read directly. Professional body commentary, used for two points that the HMRC pages do not state as plainly: that under the existing voluntary payrolling regime the Income Tax is collected in year but the Class 1A is still reported and paid through the P11D(b) after the end of the tax year, so an employer already payrolling voluntarily still faces a change in April 2027; and that HMRC guidance on how Class 1A will be calculated and reported in real time, including the option to pay real time Class 1A on non mandated benefits, was still expected at the time of writing.
• Rivane reconciliation tool. The two list matching engine referred to in this article, published on this site. The measurements quoted were produced by running its own published logic over a 250 line benefits register against a payroll register built under the HMRC rounding rule, at a range of amount tolerances.

A note on how this was researched. Every statement about what mandatory payrolling requires comes from HMRC published text, downloaded and read directly rather than through a fetched summary. That covers the policy paper of 23 July 2026 for the scope of each phase, the exclusions, the legislative changes and the penalty easement, and the interim guidance chapter by chapter for the calculation rule, the recalculation method, the estimate expectation, the 50 percent overriding limit, making good, the end of year update process, the employee statement, the record keeping period and the preparation steps. The ICAEW piece of 16 June 2026 is professional body commentary and is cited for two points it states more plainly than the HMRC pages do, attributed as such. The June 2026 Employer Bulletin is the source for the current annual Class 1A mechanism as it still operates. The rounding measurements were produced by applying the HMRC rule in integer pence arithmetic across all 2,000,000 cash equivalents from one penny to twenty thousand pounds at each pay frequency, and the method was validated by reproducing both of HMRC own published worked examples exactly. The reconciliation figures were produced by running the tool published on this site over a 250 line register built for the purpose, against its own payroll register under the same rule. No public posts on X are cited here. Searches surfaced no credible public post on this subject from HMRC, a professional body, a payroll provider or a named practitioner that could be verified on a rendered page, and account timelines and search on X sit behind a login the research browser did not have, so ordinary citations were preferred to an unverified excerpt. The data model and every identifier, name and figure in it are a worked example of structure and describe no real person, employer, fleet provider or insurer. Dates and details are as published at the time of writing, with final phase one guidance due to align with Autumn Budget 2026 and secondary legislation due at Budget 2026, so check the guidance before acting. Nothing here is tax advice.