Energy and utilities
Pricing a single meter point correctly is already fiddly: the right supplier rate has to be matched against the site's consumption band, its settlement classification, its registers and its contract length, then loaded with standing charge and pass-through costs before an uplift is applied. Pricing a forty-site tender against six suppliers, each returning rates in a different format with a different expiry, is the job that most brokers still do by hand in a spreadsheet that someone has to rebuild every time a price book changes.
We build quotation and tender engines that treat supplier rate data as a versioned, queryable asset rather than a set of files someone downloads and pastes into a workbook. Bulk rate ingestion, uplift logic, HH and NHH pricing rules, and multi-site aggregation sit behind a single engine that a CRM, a self-serve portal or an account manager's own tender workspace can call, so the same rate is never priced two different ways by two different people on the same day.
The workflow this replaces
Below is the sequence a pricing or tender desk typically works through for a multi-site customer, repeated in full whenever a new round of supplier rates arrives.
Step 01
Each supplier on the panel sends rates in its own format: a matrix price file covering consumption bands and contract lengths, a direct quotation API call for larger sites, or a portal that has to be queried one site at a time. Someone on the pricing desk collects whatever has arrived that day or that week, aware that a stale matrix file will quietly produce a wrong quote if it is used past its expiry.
Step 02
For every meter point in the tender, the estimated annual consumption (EAC) or annual quantity (AQ) is pulled from the most recent bill or from historic half-hourly settlement data, and the site is classified as HH or NHH. NHH sites also need a profile class recorded, because it affects which register structure and which supplier rate table applies.
Step 03
The consumption figure is matched against the relevant band in each supplier's matrix, and the correct register structure — single rate, day and night, or day, night and evening-weekend — is applied depending on the site's meter type. A site on the wrong register structure produces a quote nobody can actually deliver against the meter that is fitted.
Step 04
Standing charge, and pass-through network and policy costs — Distribution Use of System (DUoS) charges, Transmission Network Use of System (TNUoS) charges, Climate Change Levy (CCL), and green levy costs such as Renewables Obligation or Feed-in Tariff contributions — are added on top of the supplier's unit rate, because a comparison that omits them understates the real cost to the customer.
Step 05
The broker's or account manager's uplift is added in pence per kilowatt hour, with the applicable figure depending on which agent originated the deal, which client relationship it sits under, and any supplier-specific policy. Getting this rule wrong either erodes margin silently or prices the customer out of a deal that should have gone through.
Step 06
Once every site in the tender has a priced option from every responding supplier, the results are aggregated into a portfolio view: total annual cost per supplier across the whole estate, contract length trade-offs, and any sites where a supplier has declined to quote or capped its exposure, which happens more often than customers expect on large HH portfolios.
Step 07
The pricing desk assembles a comparison — typically a spreadsheet or a manually formatted document — showing current cost, each supplier's proposed cost, and the savings or premium implied, then converts it into a PDF to send to the customer, a step that is often the single most time-consuming part of the whole exercise on a large tender.
Step 08
Supplier rates are only valid for a defined window, often as short as a few days on volatile wholesale pricing. If the customer takes longer to decide than the price book stays valid, the whole exercise has to be rerun from the rate collection step, and everyone involved has learned to build extra slack into deadlines to absorb this.
None of this requires new commercial judgement to automate — it requires a system that holds supplier rates, consumption data and uplift rules as structured, versioned records, so that pricing a forty-site tender is a query rather than a week of spreadsheet reconciliation.
What we build
Adapters that parse supplier matrix price files and consume supplier quotation APIs, normalising both into a single internal rate model keyed by consumption band, contract length, payment method and settlement type, so downstream pricing logic never needs to know which format a given supplier used.
Every batch of ingested rates is stored as a dated, versioned price book with an explicit expiry, and every quote generated references the exact version it was priced against, so a quote can be reconstructed and justified long after the underlying rates have changed.
Separate pricing paths for half-hourly settled sites, priced against half-hourly consumption profiles, and non-half-hourly sites, priced by profile class and estimated annual consumption, with register structure — day and night, or day, night and evening-weekend — applied automatically from the meter record.
Uplift configured per agent, per client and per supplier, with policy caps and floors, calculated at the point a quote is generated and stored immutably against that quote so later disputes over what margin was actually applied can be resolved from the record rather than from memory.
Standing charge and pass-through elements — DUoS, TNUoS, CCL and applicable green levies — held as configurable, dated components so a change in network charges or policy costs can be applied to future quotes without a code change or a manual recalculation of every open tender.
A tender workspace that groups meter points into a single exercise, tracks which suppliers have responded for which sites, flags declines and capacity limits, and rolls individual site prices up into portfolio-level totals per supplier and per contract length.
A comparison builder that generates a customer-facing document directly from priced results, showing current cost, proposed cost, and the assumptions behind each figure, removing the manual formatting step that currently consumes most of the pricing desk's time on a large tender.
A full record of which price book version, which uplift rule and which pass-through rates produced a given quote, so a supplier query, a customer complaint or an internal margin review can be answered by pulling the record rather than by asking whoever built the original spreadsheet.
Integrations
Settlement and metering data
Supplier connectivity
Document and output generation
Downstream systems
Identity and compliance
The engine is designed to sit behind whichever front end a business already uses — a broker CRM, an account manager's tender workspace, or a customer-facing portal — rather than becoming a second system of record that has to be kept in step with the first.
Data and compliance
Architecture note
The engine is built as a service distinct from any CRM or portal that consumes it, with a stable internal rate model that every supplier adapter normalises into. This means a new supplier, or a change to an existing supplier's file format, is handled by writing or amending one adapter, not by touching the pricing or comparison logic that every other supplier already relies on.
Price books are immutable once ingested. A new supplier rate file does not overwrite the previous version; it creates a new dated version, and every quote references the specific version it was priced against. This is what makes it possible to answer, months later, exactly what a customer was quoted and why, without relying on anyone's memory of what a spreadsheet said at the time.
Pricing logic for HH and NHH sites, register structures and pass-through components is expressed as configurable rules rather than hard-coded calculations, because network charges, levy rates and register conventions change on a schedule set by regulators and network operators, not by the broker's development cycle.
Tender aggregation and comparison output are built as a layer above the core pricing service, so a portfolio-level view or a customer-facing PDF is generated from the same priced results a single-site quote would use, keeping the numbers a customer sees and the numbers held in the underlying record permanently consistent.
Timeline
Weeks 1-3
Mapping of current supplier panel, rate file formats, uplift policy and the manual tender process, plus an assessment of which suppliers offer APIs versus matrix files only.
Weeks 4-8
Design of the internal rate model and build of ingestion adapters for the priority suppliers on the panel, covering both matrix file parsing and API connectivity.
Weeks 9-13
HH and NHH pricing paths, register structure handling, pass-through cost configuration, and the price book versioning and expiry mechanism.
Weeks 14-17
Uplift and commission rule configuration per agent, client and supplier, with the immutable audit trail linking every quote to the rules and price book version used.
Weeks 18-21
Multi-site tender workspace, portfolio-level aggregation, and the comparison and PDF generation module used to produce customer-facing output.
Weeks 22-25
Connection to the CRM, portal or workspace that will consume the engine, and a parallel run against live tenders to validate pricing accuracy before cutover.
Weeks 26-28
Cutover to the new engine for live quoting, monitoring of price accuracy and expiry handling, and a defined period of prioritised fixes before the managed run phase begins.
Indicative cost
Bands assume a UK broker or supplier-facing team quoting across a multi-supplier panel including both API-connected and matrix-file suppliers. A panel weighted heavily towards matrix files requires more adapter work than one dominated by APIs.
Where this sits
Questions
Matrix files are ingested and normalised into the same internal rate model used for API-connected suppliers, with parsing rules built per supplier layout because consumption bands, contract lengths and payment terms are laid out differently by every provider. Once normalised, a matrix-sourced rate and an API-returned rate are indistinguishable to the comparison and quoting logic downstream.
Yes. Uplift is configured as a set of rules rather than a single figure, so a base uplift per supplier can be adjusted per agent, overridden per client relationship, or capped by policy, with the rule that actually applied to a given quote stored against that quote permanently rather than only against the current configuration.
Settlement classification is read from the meter point record and, where available, confirmed against Elexon settlement data flows and D0052 or D0036 exchanges, because a site's HH or NHH status determines which suppliers can quote, which profile class applies, and which registers appear on the resulting comparison.
Every quote is generated against a specific version of a price book, and that version is retained alongside the quote for its full validity life. If the underlying price book has since expired or been superseded, the quote itself still shows exactly what was offered and when, which matters when a customer queries a quote months after it was issued.
Yes, because a tender exercise routinely needs to show a customer what they are paying now against what is available, and a site that has fallen out of contract is priced at the supplier's deemed or out-of-contract rate until a new contract is signed. The comparison output makes that current exposure visible rather than only showing prospective options.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us