Quick answer: MHCLG’s ECaaS technical documentation now lists the breaking changes coming in HEM and FHS version 1.0.0a9, with the API move from 1.0.0a7 estimated for late September 2026. The change most likely to alter how a dwelling is modelled is that
ThermalBridgingwill no longer accept a plain number — a blanket value in place of junction-by-junction data. Alongside it: rectangular MVHR ductwork gainsduct_perimeter_mm, party walls gainu_value_whole_wall, suspended ground floors gainsmart_air_bricksandvents_open_during_airtightness_test, and the window input is reworked. None of this changes what you submit today — SAP 10.3 is still the compliance route — but it tells you what HEM will want when it arrives.
What ECaaS is, and why its changelog matters
Energy Calculation as a Service (ECaaS) is the calculator service MHCLG runs to provide the Home Energy Model. It is an API: authorised bodies — in practice, the software houses whose tools you already use — build against it, and MHCLG’s own documentation states plainly that the service “will become the only valid means to e.g. confirm compliance with Part L of the Building Regulations when making reference to the Future Homes Standard.”
That is worth sitting with for a moment. Under SAP, approved software houses each implement the published methodology and BRE approves the implementation. Under HEM, there is one engine, run centrally, and every compliance calculation goes through it. Your software becomes the thing that collects the inputs and presents the answer.
Which makes the ECaaS changelog the most direct view any assessor has of where HEM is actually going. It is not a consultation or a summary. It is the field-level specification of what the calculation will ask for.
The API has been open to authorised bodies since 27 November 2024. It currently runs HEM 1.0.0a7 (specification published 27 February 2026) with the FHS wrapper 1.0.0a7 (published 9 March 2026). The documentation states that “work is ongoing to move the API to reflecting 1.0.0a9 of HEM/FHS, estimated for late September 2026.”
It is still flagged beta, and MHCLG is explicit that backwards-compatibility breaks will keep happening “as the input specifications for FHS and HEM are finalised.”
The thermal bridging change
Buried in the list of breaking changes for 1.0.0a9 is a single line:
removed possibility to provide number as a value for
ThermalBridging
In the current input specification, thermal bridging can be given either as a set of junction objects — each with its Ψ value and length — or as a single number standing in for the whole dwelling. From 1.0.0a9, the single number goes.
If you have spent any time with SAP, you will recognise the shape of this. SAP allows a default y-value (0.15 W/m²K, or 0.20 for existing dwellings) as an alternative to entering junctions individually, and that default is deliberately punitive: it is a penalty designed to make bespoke Ψ calculations the better commercial choice. Removing the blanket option from HEM goes a step further. It does not make the shortcut expensive. It removes it.
Two caveats, because this is a beta specification and it deserves to be read carefully. First, the changelog describes the input schema, not the compliance policy — it tells you what the API will accept, and it is possible the FHS wrapper still applies defaults of its own to junctions you declare but cannot evidence. Second, this is a forthcoming release with an estimated date, and MHCLG has moved HEM dates before: the launch itself slipped on 8 June 2026 to “the coming months”.
But the direction is not ambiguous, and it is the same direction Part L has been travelling since Accredited Construction Details were withdrawn in 2022. Junction-by-junction Ψ values, calculated to BS EN ISO 10211 and reported under BR 497, are becoming the only way to describe a thermal envelope. A dwelling with good fabric and no junction data will simply not be describable.
The other breaking changes worth knowing about
The 1.0.0a9 list runs long. These are the ones that touch things an assessor or a technical manager actually specifies.
MVHR ductwork changes shape. A new duct_perimeter_mm field arrives for ductwork with a rectangular cross section, and the changelog pairs it with a “new inadmissibility of internal_diameter_mm and external_diameter_mm fields for ductwork with a circular cross section”. The wording there is worth reading twice — the natural engineering reading is that diameter fields stop being accepted for rectangular duct, which is the change the new perimeter field implies, and the full release notes should settle it. Either way, the direction is the same: rectangular duct gets described by its perimeter rather than squeezed into a diameter. This lands in the same quarter as Approved Document F 2026’s expanded ductwork evidence expectations, and points the same way — the ventilation system has to be described as installed, not as a nominal system type.
Two related fields disappear from MechanicalVentilation objects: design_zone_cooling_covered_by_mech_vent and design_zone_heating_covered_by_mech_vent.
Party walls gain a whole-wall U-value. A u_value_whole_wall field is added for party wall building elements, and defined_resistance is removed as a party wall cavity type. Party wall heat loss has been a long-running argument in SAP — fully filled and sealed cavities at 0.0 W/m²K, unfilled at 0.5 — and a whole-wall U-value input suggests HEM wants the constructed reality rather than a category.
Suspended ground floors get more specific. shield_fact_location is removed and replaced by smart_air_bricks and vents_open_during_airtightness_test. That second field is an interesting one: it makes the relationship between the underfloor void and the airtightness test an explicit input rather than an assumption, which means what the test engineer did on site now has to be recorded and carried into the model.
Windows are reworked. mid_height, max_window_open_area and free_area_height are removed from transparent building elements, and the definition of window_part_list is “reworked”. Given that window opening geometry drives both purge ventilation under Part F and the useful-opening-area calculations that sit behind overheating, this one is worth watching when the release notes land in full.
Smaller removals. NumberOfSanitaryAccommodations goes. storey_of_dwelling is removed from the General object. PreHeatedWaterSource gains an init_temp field. A point-of-use hot water source must now send an efficiency value of exactly 1. The building_level_distribution_losses field is no longer required for heat interface units.
Additions on the services side. New temp_min_useful and HeatSource fields for PCM heat battery inputs, a power_limit_export field for electricity energy supplies, and heat_exchanger_surface_area and tank_is_integral for hot-water-only heat pumps with separate tanks.
Two caveats MHCLG flags itself
Worth reading, because they are candid.
Speed. “The time taken for successful FHS compliance calculations is currently in the region of 11 seconds.” MHCLG expects to improve this. For now, anyone imagining HEM as a click-and-wait experience like SAP should adjust: a half-hourly simulation over a year is not free, and iterating a specification twenty times to find the compliant combination is a different working day.
Product data. The API “currently accepts PCDB product references for boilers and heat pumps only”, with remaining product categories to follow. So the Product Characteristics Database integration that will eventually pull real product data into a calculation is partial. Everything else still needs entering by hand.
The documentation also acknowledges that “there are still a number of inaccuracies in both the core HEM implementation and the FHS wrapper”, which is exactly what a beta designation is for.
What to actually do about this
Nothing changes for a live job. SAP 10.3 remains the sole approved methodology for Future Homes Standard compliance, and Approved Document L 2026 takes effect on 24 March 2027. ECaaS is not a route you can use for a submission today.
But start building the junction library now. If the blanket thermal bridging value is going, then every standard detail in a house type needs a calculated Ψ value with a traceable model behind it — and the time to build that library is while SAP is still the compliance route and a y-value fallback still exists. Doing it under time pressure in 2027, on a plot that has already lost transitional protection, is the expensive version.
Ask your software house where they are on 1.0.0a9. They are the authorised body integrating with ECaaS. The useful question is not “when will you support HEM” but “which HEM version are you built against, and what happens to my saved models when the API moves”. Input schema breaking changes are exactly the kind of thing that invalidates stored data.
Record what the airtightness test engineer did to the underfloor vents. It sounds trivial. Under 1.0.0a9 it is an input field.
If you’d like a set of Ψ values calculated for your standard junctions — to BS EN ISO 10211, reported the way a building control body expects to see them — get in touch and we’ll tell you what we’d need from your details.
Sources: ECaaS Technical Documentation (MHCLG) · Home Energy Model: replacement for the Standard Assessment Procedure (SAP) — consultation (GOV.UK) · Energy Calculation as a Service (ECaaS) — Construction Leadership Council · The Future Homes and Buildings Standards: Building Circular 01/2026 (GOV.UK)