Residential HPWH Documentation Checklist
Residential heat pump water heater registrations rely on a consistent evidence pack. The same model names, brand names, legal entity, ratings, and control settings need to line up across test reports, drawings, manuals, certificates, data plates, and scheme forms.
EnergyAE can review partial evidence early, but modelling cannot be completed until the required documents are clear enough to support AS/NZS 4234 simulation and scheme submission.
What this applies to
This checklist applies to residential HPWH products being prepared for SRES registration through CER, VEU residential HPWH registration, ESS residential HPWH registration, or AS/NZS 4234 modelling for product comparison or pre-application review.
Documents required
| Document | Why it is needed |
|---|---|
| AS/NZS 5125.1 test report | Provides heat pump performance data for modelling. |
| Raw test data | Supports regression and quality checks on the test report. |
| AS/NZS 4692.1 tank heat loss report | Provides standing heat loss evidence for the tank. |
| Tank drawing | Provides geometry, fitting heights, element positions, and sensor locations. |
| System schematic | Shows how the heat pump, tank, pump, sensors, and pipework are arranged. |
| Installation manual | Confirms installation conditions, plumbing, settings, warranty, and product claims. |
| Data plate images | Confirms model names, electrical ratings, refrigerant, and charge. |
| AS/NZS 2712 certificate | Supports design and construction certification for scheme applications. |
| Electrical safety certificate | Supports product safety evidence. |
| Control settings or declaration | Confirms setpoints, deadbands, legionella control, and operating logic. |
Test data required
For residential HPWH modelling, the AS/NZS 5125.1 evidence normally needs the main heat-up performance test report, raw data at suitable time intervals for the required test conditions, and low-temperature performance data where frosting behaviour matters.
If the laboratory provides regression or calculation sheets separately, include those as well.
The report should show the tested model name, test conditions, water temperatures, ambient conditions, power input, heating capacity, COP, and any assumptions used in the final results.
Tank drawing requirements
The tank drawing should be an engineering drawing, not a brochure image. It should state the tank model name, internal volume, internal diameter and height, wall thickness, and insulation details if available.
The drawing should also show heights above the tank base for inlets, outlets, elements, sensors, and heat exchanger connections. For integral systems, include microchannel or wrap-around heat exchanger details where applicable.
If the tank drawing is missing fitting heights or sensor positions, the model may not represent the physical product correctly.
Control information required
EnergyAE needs the control behaviour that will apply to the product being sold, not a generic description.
Provide the heat pump setpoint, heat pump deadband, sensor used for heat pump control, and legionella control temperature and frequency.
If the product has electric boost, provide the boost setpoint and deadband. For separate systems, also provide the pump flow rate or flow control method, plus any factory settings that cannot be changed by the installer.
Common issues
Common document issues include model names that differ between the test report and certificate, manuals that show an OEM model name rather than the Australian or New Zealand market model name, and tank drawings that do not show sensor or fitting heights.
Other frequent issues are blurry data plate images, control settings in the manual that do not match the control declaration, warranty wording that does not match scheme requirements, and AS/NZS 2712 certificate schedules that do not list every model variant.
What EnergyAE needs from you
Send the documents as PDFs or clear image files. Use the product’s intended market model name in filenames where practical.
If testing has not started, confirm the target schemes before locking in test scope. A test program that works for one pathway may leave gaps for another.