01
Volume arrives in files, not columns
EIEP1 as-billed and replacement RM-normalised, EIEP3 half-hour, EIEP2 aggregates, EIEP12 price notifications, Registry status. Each trader, each revision, each ICP-day.
For New Zealand EDBs
Test the price book on billed volumes.
Give the Board something that holds.
ICPLedger™ sits beside the pricing methodology and the billing system you already run. It applies your existing price book to real EIEP and Registry data so you can see whether the design holds - revenue, shock and disclosure - before the next year is locked.
Why this exists
Pricing is no longer a spreadsheet job.
From 1 April 2026, Code clause 12A.5 requires a distributor that offers a time-varying distribution plan to charge standard-contract customers on that plan - not on an anytime alternative - except where the premises has no communicating smart meter. Authority guidance treats that assignment as an ICP-level task. Export rebates, LFC phase-out and information disclosure sit on the same ICP record. Excel can hold a tariff table. It cannot run the scenarios or the disclosure extract.
02
Prices have to survive a shock test
Revenue targets, customer segmentation, Deprivation, capacity, ANZSIC and location flags all change who pays what. Boards want the scenario. Auditors want the trail.
03
The Code now prices at the ICP
Time-varying distribution charges, export rebates and connection pricing are ICP events. If the pricing model is not ICP-native, the published prices and the disclosure pack drift apart.
ICPLedger™
Don’t replace your pricing model. Validate it with real billing data.
ICPLedger™ is not a billing engine and does not replace the methodology you already publish. It takes the volumes billing already invoiced, applies the current or proposed price book, and shows implied revenue, customer shock and disclosure - so the model is tested on the same data the invoices came from.
Source
Registry + EIEP
ICP status, trader, meter configuration, price category, capacity. EIEP1 / 3 volumes the network already receives.
Unchanged
Network billing
The system that invoices retailers stays in place. ICPLedger™ does not bill.
ICPLedger™
Validate the price book
Apply today’s or next year’s prices to billed volumes. Shock, revenue and disclosure on the same ICPs.
Out
Design + reports
Working papers, EIEP12 pack, methodology evidence. Feed the next pricing year - not a second invoice run.
The loop: billed volumes inform the model; a validated price path informs the next billing year. Your existing pricing model stays the source of the prices.
+
ICP master aligned to the Registry
ICP status, trader, meter configuration, price category and capacity held against the same key the rest of the industry uses.
+
Price book and component codes
Delivery prices, TOU windows, capacity and demand charges, LFC residual and export rebates versioned by effective date - ready for EIEP12 notification.
+
Validate on billed volumes
Load the EIEP volumes already used to invoice retailers. Apply the current or proposed price book. See whether revenue, shock and disclosure still hold - without replacing the methodology or the billing stack.
+
Reporting the board can stand on
Revenue by price category, trader, GXP and customer segment. Price-shock packs. Disclosure extracts. The working papers stay attached to the numbers.
What a pricing year looks like
A closed price path in ICPLedger™ is a versioned book plus the reports that follow from it - not a saved-as copy of last year’s workbook.
Registry snapshot
ICP status · trader · meter configuration · price category · capacityEIEP1 / EIEP3 load
as-billed · RM-normalisedPrice assignment
PCC · TOU · capacity · exportImplied charges
fixed · volume · demand · rebateScenario & shock
segment · NZDep · capacityReport & disclose
revenue · ID · working papersBuilt for the work EDBs actually do
Pricing and reporting on the same spine.
EIEP1, 2, 3 and 12 as the volume source
TOUCode 12A.5 from 1 April 2026, if offered
LFCPhase-out through to 1 April 2027
DGExport rebates and injection charges
Pricing scenarios
Test tariff structures before they go to consultation. Segment by capacity, location, deprivation index, ANZSIC and behavioural response. See who is shocked, and by how much, before the EIEP12 goes out.
Pricing risk before go-live
Reconcile implied network charges to trader files and market volumes. Find missing ICP-days, wrong price codes and export treated as import before the price path is published.
Methodology working papers
Keep the published price book, the billed volumes it was tested on, and the shock and revenue evidence in one place. What goes to consultation and disclosure is the same model that was validated against last year’s invoices.
In the application
Pricing scenarios before the EIEP12 goes out.
Hold allowable revenue, assign TOU and export prices at ICP level, then see who is shocked - by price category, NZ Deprivation, capacity and ANZSIC - before the year is locked. Figures below are illustrative demo content.
Scenario workspace - FY27 delivery prices
Status quo against a TOU assignment plus LFC exit and an export rebate. Revenue is held to the target; the work is in the distribution of the change.
Proposal revenue
$22.41m
+$12k vs target
ICPs reassigned
11,842
TOU where smart meter
Shock > 10%
6.1%
of residential ICPs
DG rebate
$186k
export at peak
| Price category | ICPs | Base $/yr | Proposal $/yr | Change | Median shock |
|---|---|---|---|---|---|
| Residential TOU | 9,410 | $8.62m | $8.91m | +3.4% | +$48 |
| Residential LFC residual | 2,104 | $1.41m | $1.68m | +19.1% | +$128 |
| General / capacity | 1,882 | $9.20m | $8.97m | −2.5% | −$86 |
| Distributed generation | 890 | $0.74m | $0.55m | −25.7% | rebate |
Shock by segment
The same proposal cut by NZ Deprivation, capacity band and ANZSIC so the board can see where the LFC exit lands - and whether the TOU window is doing the work it is meant to.
| Flag | ICPs | Share of revenue | ICPs > 10% shock | Action |
|---|---|---|---|---|
| NZDep 9–10 · LFC | 614 | 2.8% | 211 | Hold residual daily charge |
| Capacity ≥ 3× average | 326 | 11.4% | 18 | Keep capacity component |
| ANZSIC agriculture | 408 | 6.1% | 44 | Shoulder window review |
| DG export · peak rebate | 890 | 2.5% | - | Pass through in EIEP1 |
Illustrative screen content for a walkthrough - not a live network extract.
Architecture on purpose
Your ICPs do not belong in someone else’s tenancy.
221b applications are deliberately local. ICPLedger™ is designed to run on hardware the EDB controls - a Windows estate, SQL Server and file shares included - with the database on the premises. A Microsoft shop does not have to stand up a new cloud tenancy to validate next year’s prices.
From Excel to a native appliance
221b’s work started as the spreadsheet an analyst could defend to a board. It became database reconciliation of tens of millions in network tariffs, then R audit scripts, then a native application. ICPLedger™ is that line of work applied to EDB pricing and reporting.
No cloud dependency
Registry extracts, EIEP files and customer-level volumes stay on the machine that processes them. There is no multi-tenant SaaS, no obligatory data residency argument, and no outage in Sydney that stops a Wellington price run.
Works in a Microsoft shop
Price books still live in Excel. Volumes still land as EIEP files. Billing still runs on the stack you already have. ICPLedger™ reads those sources, writes reports back to folders and SQL the rest of the organisation already uses - it does not ask the network to leave Windows.
People who already know the Code
Built by practitioners who have lived Registry codes, reconciliation revisions, interposed arrangements and information disclosure - not a generic utility-billing template rebadged for New Zealand.
221b Limited
Walk through a pricing year on your ICPs.
Bring a month of EIEP1, the current price book and the questions the board is asking. We will show how those files become a priced scenario and a disclosure extract - including 12A.5 TOU assignment where you offer it, and the 1 April 2026 export-rebate year.
Malcolm Souness · Director, 221b Limited
221b.co.nz
· NZBN 9429042009948