Invoice ingestion and decomposition
Invoices ingested from supplier data feeds, portal exports or PDF extraction, decomposed to line-item level and mapped to the correct MPAN or MPRN and billing period automatically.
Energy and utilities
Billing validation software
Energy invoices are complicated on purpose: a single bill can combine a commodity rate, DUoS charges banded by time of day, TNUoS, the Climate Change Levy, and a set of smaller third-party charges that shift when network operators or Ofgem update their tariffs. A portfolio of a few hundred meter points generates enough invoice volume that manual checking catches the obvious errors and misses the rest, which is where most avoidable overpayment sits.
We build billing validation platforms that decompose every invoice to MPAN or MPRN level, check each charge component against contracted rates and current network and levy tariffs, and flag discrepancies for a defined dispute workflow rather than for a spreadsheet someone works through when they have time.
The workflow this replaces
The invoice checking process a finance or energy team runs by hand today
Before validation software is built around it, a typical multi-site organisation or bureau manages invoice checking something like this, per invoice, repeated across every supplier and meter point.
Step 01
Invoices arrive in a mixture of formats
Supplier invoices arrive as PDFs, portal downloads or, less commonly, structured data feeds, and someone extracts the figures needed to check them — usually the total, sometimes the unit rate, rarely the full breakdown of network and levy charges — because extracting everything by hand from a PDF is slow.
Step 02
The total is checked against expected consumption
A rough sanity check compares the invoiced consumption against what the site is expected to use based on history, catching obvious anomalies like a doubled reading but not a correctly-quantitied invoice charged at the wrong DUoS band or an outdated levy rate.
Step 03
Rate checks are done for a sample, not every invoice
Given the volume, most teams check contracted unit rates against invoices for a sample of sites or suppliers rather than every invoice, which means systematic errors — a whole tariff band mis-applied by a supplier's billing system — can persist for months before being caught.
Step 04
Meter reads are assumed correct unless something looks wrong
Whether an invoice is built on an actual or an estimated meter read is not always visible without opening the underlying data, so estimated reads that run for several consecutive periods without a true-up are often missed until a customer or site manager queries a bill.
Step 05
A discrepancy is queried informally
When an error is found, someone emails or calls the supplier's billing team, and the query is tracked, if at all, in an inbox thread or a personal spreadsheet, with no consistent record of what was claimed, what was recovered, or how long resolution took.
Step 06
Recovered amounts are reconciled manually against expectations
When a credit note or adjustment arrives, someone checks it against the original claim, a step that is easy to skip under time pressure and that is where partial or delayed recoveries often go unnoticed.
A diligent energy or finance team can catch most of the significant errors this way. What manual checking cannot do at volume is validate every invoice against every applicable charge component, every time, which is the gap that produces the recoverable amounts a validation system is built to surface.
What we build
Modules in a typical billing validation build
MPAN/MPRN-level rate validation
Every charge component — commodity, standing charge, network, levy — checked against the contracted rate and the applicable tariff for that specific meter point, rather than validated only at invoice total level.
HH and NHH consumption checks
Half-hourly sites validated against settlement period-level consumption data where accessible, and non-half-hourly sites validated against estimated annual consumption and profile class, with the correct check applied per meter point automatically.
Network and levy charge verification
DUoS charges checked against time-of-day banding, TNUoS and CCL checked against current published rates, and any other third-party charges checked against the correct basis for that region and meter type.
Meter read validation
Read type — actual or estimated — tracked per billing period, with alerts on consecutive estimated reads and automatic reconciliation once an actual read supersedes an estimate.
Recovery claim management
Discrepancies raised as claims against the specific invoice line and meter point, tracked through a defined status workflow, with the recovered amount recorded against the original claim once resolved.
Supplier dispute workflow
A structured dispute process per supplier relationship, including submission, escalation and resolution stages, so open disputes are visible as a queue rather than as a set of email threads.
Portfolio-level reporting
Standing reports on validation exceptions, open and resolved disputes, and total recovered value, broken down by supplier, site or meter point.
Integrations
Named systems and interfaces
Metering and consumption data
ECOESXoservehalf-hourly data collectorsMPAN core and top lineMPRN
Supplier connectivity
supplier invoice data feedssupplier portalsPDF invoice extraction
Network and levy reference data
DNO/DUoS tariff schedulesNational Grid TNUoSClimate Change Levy rates
Finance
XeroSageSAPaccounts payable workflow
Identity and reporting
Microsoft Entra IDPower BIstandard export to CSV/Excel
Where invoices arrive only as PDFs from a supplier with no structured feed available, we build extraction against the specific invoice formats in use rather than assuming a data feed exists everywhere in the portfolio.
Data and compliance
Requirements written into the build
- Invoice decomposition
- Every charge line mapped to a charge type — commodity, DUoS, TNUoS, CCL, other levies — and reconciled against the meter point's contracted terms and current published network tariffs.
- Settlement classification
- Half-hourly (HH) or non-half-hourly (NHH) status recorded per meter point, determining which consumption validation logic and data source applies.
- Meter read type
- Actual, estimated or customer-submitted read status recorded per billing period, with a true-up process run when an estimate is superseded by an actual read.
- Recovery claim record
- Discrepancy amount, invoice line reference, meter point and claim status held together, with the recovered or adjusted amount recorded against the original claim on resolution.
- Dispute status workflow
- Raised, submitted to supplier, under review, escalated, resolved — tracked per dispute with timestamps, so ageing disputes are visible without manual chasing.
- Tariff reference data currency
- Network and levy tariff data refreshed on a defined schedule aligned to DNO and Ofgem publication cycles, so validation runs against current rather than stale rates.
Architecture note
How the system is put together
Invoice data is normalised into a common internal charge model at ingestion, regardless of source format, so validation logic runs against one consistent structure rather than a different rule set per supplier's invoice layout.
Rate and tariff reference data — contracted rates, DUoS bands, TNUoS and levy rates — is held as versioned reference tables separate from invoice records, so a validation run against a historical invoice always uses the rates that applied at the time, not the current ones.
The dispute workflow is modelled as a distinct process from validation itself, linked to the specific invoice line that triggered it, so a claim's full history — from the original discrepancy through to recovered amount — remains reconstructable without cross-referencing separate systems.
Where PDF extraction is required, it is treated as an adapter feeding the same normalised charge model as structured feeds, so adding a new supplier invoice format does not require changes to validation or reporting logic.
Timeline
Build phases in weeks
Discovery
Weeks 1-3
Review of current supplier invoice formats, existing checking practice, contracted rate data quality, and the tariff reference data required.
Charge model and reference data
Weeks 4-6
Design of the normalised charge model, sourcing and structuring of network and levy tariff reference data, and contracted rate migration.
Ingestion and validation engine
Weeks 7-12
Invoice ingestion from priority supplier feeds, PDF extraction where required, and the core validation logic for HH and NHH sites.
Recovery claim and dispute workflow
Weeks 13-16
Claim raising, dispute status tracking, and reconciliation of recovered amounts against original claims.
Reporting and finance integration
Weeks 17-19
Portfolio-level reporting views and integration with the finance system used for accounts payable.
Parallel run and go-live
Weeks 20-23
Running validation alongside the existing manual process to confirm accuracy, followed by cutover and a defined stabilisation period.
Indicative cost
Budget bands, not quotes
- Discovery and scoping
- £15,000 to £28,000, credited against the build.
- Core validation engine for one or two supplier formats
- £150,000 to £260,000.
- Full platform covering multiple suppliers, HH and NHH, and dispute workflow
- £260,000 to £480,000.
- PDF extraction build per additional supplier invoice format
- £8,000 to £20,000 per format.
- Managed run
- Monthly retainer against an agreed service level, priced after go-live scope is confirmed.
Bands assume a portfolio in the low hundreds of meter points across a handful of suppliers. A larger multi-supplier bureau processing thousands of invoices monthly typically sits at the upper end.
Where this sits
Related pages
Questions
Frequently asked
What level of detail does invoice validation actually check?
Validation runs at MPAN or MPRN level against the contracted unit rates, standing charges and the specific network, levy and third-party charges that apply to that meter point, rather than checking only the total invoice value. A total can look correct while a rate, a DUoS band or a levy line is wrong, and that discrepancy only shows up when the invoice is decomposed to its component charges and compared line by line.
How does the system tell the difference between an estimated read and an actual meter read?
Every consumption record carries a read type flag alongside its value, so an invoice built on an estimated read is flagged for review even if the resulting charge looks otherwise plausible, and a subsequent actual read is used to true up the estimate and check whether the earlier invoice needs to be queried.
Can the platform manage a dispute with a supplier from raise to resolution?
Yes. A dispute is logged against the specific invoice line and meter point it relates to, tracked through a defined status workflow, and closed with the recovered or adjusted amount recorded against the original discrepancy, so a portfolio-level report on open and resolved disputes is a direct query rather than a reconstruction from email threads.
Does the system handle both half-hourly and non-half-hourly sites?
Yes. Half-hourly sites are validated against settlement period-level consumption data where available, while non-half-hourly sites are validated against estimated annual consumption and meter readings, with the correct validation logic applied automatically based on each meter point's settlement classification.
How far back can a recovery claim reach?
This depends on the supplier's own terms and the type of error, and typically ranges from twelve months to several years for clear billing errors. Confirm current recovery claim time limits with your commercial or legal adviser, as these vary by supplier and by error type.
Tell us what your systems are doing wrong.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us