The Home Energy Model is set to displace SAP in England’s residential compliance workflow, shifting energy assessment from a largely static calculation to a more open, data-led process. For builders, that means rethinking software choices, roles, and evidence production across design, procurement and handover. The goal doesn’t change—prove compliance, de-risk cost and programme—but the tools, data interfaces and accountability will.
TL;DR
/>
– Treat HEM as a data pipeline, not just a replacement calculator; prioritise tools with robust interoperability and audit trails.
– Lock in responsibilities early: who models at concept, who runs compliance, who curates evidence at as-built.
– Test overheating and fabric-first options alongside services early, or risk late-stage redesigns.
– Tie software outputs to site QA so design intent (U-values, airtightness, systems) actually lands on plots.
– Value features that speed iterations and capture change history over headline licence cost.
Specifying HEM-ready energy software for UK housing projects
/> The shift from SAP to the Home Energy Model pushes energy compliance closer to digital design and procurement. Where SAP sat as a discrete consultant task, HEM expects cleaner data exchange, version control and a clearer line from design option to as-built evidence. When specifying software, builders should seek tools that are explicitly HEM-compatible or clearly positioned to integrate with the government’s HEM engine, while also supporting Part L evidence packs and, where relevant, overheating checks in line with UK practice.
Decide who owns which step. A common split is: early-stage optioneering by the design team, formal compliance runs by a qualified assessor, and as-built updates by the main contractor with assessor sign-off. Choose software that can move models between those parties without retyping data. Formats like IFC, gbXML or vendor-neutral CSVs can cut friction; the key is proving that walls, windows, systems and usage assumptions survive the handover intact.
Ask how the tool handles assumptions and updates. Electricity carbon factors, predicted occupancy and schedules move with policy; you want software that stays aligned with changing guidance without breaking your projects mid-programme. If you’re procuring MMC elements, check how the tool handles thermal bridging declarations and standard details so you’re not forced into generic defaults that harm results.
Consider the bigger picture of procurement. You may not need a full building simulation suite for typical housing, but you do need something that can test fabric-first measures, low-carbon heating, PV and ventilation as a joined-up stack. If overheating risk is live (urban sites, tight orientations), opt for a workflow where energy and overheating models share geometry to avoid duplicated effort and conflicting outputs.
# Scenario: two phases, one design freeze, and a tender clock
/> A regional contractor is bidding a 120-home scheme with timber frame on Phase 1 and traditional masonry on Phase 2. The client wants confidence that Future Homes-style targets will be met without last-minute changes to heating plant. The estimator has costed two window specs and optional PV, and the design manager is days from design freeze. The M&E consultant has run a familiar SAP tool, but the bidder’s board asks for a HEM-ready approach to de-risk Phase 2. The energy modeller can export the concept geometry, but can’t import timber frame junction data cleanly into their current software. Meanwhile, procurement needs a spec that envelope and MEP subcontractors can price against, including airtightness, ventilation sizing and controls. With the tender clock running, the team needs software that pulls the same dwelling template through concept, compliance and as-built without rework.
Interfaces, data, and risk when moving from SAP to HEM
/> The operational risk in a HEM world sits at the interfaces: between architects and assessors; between design and procurement; and between predicted performance and what lands on site. Builders should treat the energy model as a contract-adjacent deliverable, not a side spreadsheet. Write into your appointments the file formats, responsible roles, and the point in the programme when optioneering turns into a controlled model feeding procurement.
Data ownership matters. Establish who holds the master dwelling definitions and where they live, ideally in a common data environment with documented revisions. Ensure your chosen software can publish an audit trail that links each iteration to the assumptions used—especially for airtightness targets, thermal bridges, ventilation rates and system efficiencies. If your procurement team changes a product—say a different MVHR unit or window spec—the model needs to digest that change rapidly and show the effect on compliance.
Expect more threading between disciplines. Overheating checks, noise constraints, and planning conditions often drive ventilation choices, which in turn impact energy results. A split stack of tools, each redrawing the dwelling, will cause delays. Prefer workflows that share geometry and room zoning across energy and overheating assessments, or at least support reliable exchange to minimise manual rework.
On site, evidence collection must line up with model inputs. The energy software you choose should help generate schedules and plots for site teams: window U-values per house type; ventilation duty/controls; PV arrays per roof; heat pump model references; airtightness targets per plot. If you rely on defaults in the model but install something different in the field, you inherit compliance and EPC headaches at handover.
# Common mistakes
/>
– Treating HEM as a like-for-like SAP swap. The data pipeline is richer; keeping manual handovers invites inconsistency and delay.
– Buying licences without upskilling the team. Without clear ownership and training, models stall at RIBA Stage 3 and never reach procurement.
– Ignoring overheating until planning. Late geometry changes or shading strategies can unravel fabric and MEP choices already priced.
– Leaving site QA disconnected from the model. If airtightness or product swaps aren’t fed back, as-built results won’t match predicted performance.
How to measure value: beyond the licence fee
/> With budgets tight, there’s a reflex to chase the cheapest licence. Value here sits in avoided redesigns, fewer RFIs, quicker iterations, and clean evidence at completion. Benchmark tools by how fast you can clone a house type, toggle fabric and services, and re-run results across multiple plots. Look for clear, exportable evidence packs suitable for Building Control submissions and for handing to warranty providers.
Assess integration depth. Does the tool import architect geometry without mangling spaces? Can it push schedules or checklists to the site team? Does it maintain a transparent assumptions library you can share with the client? When updates land—policy tweaks, emission factors—does the vendor communicate change impacts and support migration mid-project?
Finally, test the tool live. Run a real house type through: base spec, low-carbon heat, PV add-on. Time the process, note handoffs, and capture where data falls over. That will tell you more about value than a feature matrix.
# Procurement checklist for HEM-era tools
/>
– Confirm HEM compatibility roadmap and how the tool will align with future guidance updates.
– Demand robust import/export (IFC/gbXML/CSV) and test on a live house type before purchase.
– Ensure overheating workflows can share geometry or data with energy assessments.
– Require transparent assumptions libraries and revision histories for audit purposes.
– Insist on outputs that map directly to procurement packages and site QA (U-values, airtightness, systems schedules).
– Clarify licensing across designers, assessors and contractors, including who holds the as-built model.
– Secure training and response SLAs that match programme milestones, not just sales support.
The market will reward tools that behave like traceable data pipelines rather than walled calculators. Watch for how quickly vendors align with policy updates and how well their platforms plug into design and site realities without adding friction.
FAQ
# When should a builder lock in HEM-compatible software during a project?
/> Ideally at the point you freeze house-type geometry, so optioneering and compliance can share the same model. Waiting until technical design often bakes in costly assumptions that are hard to unwind. If you’re mid-programme, pilot one or two house types to prove the workflow before scaling.
# Who should own the energy model: designer, assessor, or contractor?
/> Ownership can vary, but clarity is crucial. Many teams let the assessor run formal compliance, while designers and contractors feed geometry and product data in a controlled way. Whatever the split, name a single model custodian and define how changes are requested, approved and recorded.
# How do software choices affect subcontractor procurement?
/> The right tool can output schedules and performance targets that map to packages: windows, ventilation, PV, heating systems, airtightness. That reduces ambiguity in tender returns and helps align product submittals with the model. Poor tools force manual transposition, which increases errors and claims risk.
# Can overheating assessments be kept separate from energy modelling?
/> They can, but separation creates double handling and potential conflicts. Where possible, use workflows that share room data and solar exposure, or build a reliable export/import bridge. Agree early which model is the master for geometry to avoid diverging drawings and mismatched results.
# How should as-built changes be handled to keep compliance intact?
/> Set up a simple change control: proposed product swap or test result, model update, quick re-run, then file the revised output in the project CDE. Tie site QA (photos, certificates, test sheets) back to the specific inputs that drove the model. This keeps Building Control submissions clean and reduces disputes at handover.
