API for Utility Bill and Multi-Service Statement Processing (2026)

A utility bill looks like an invoice, but it behaves like a small database. One statement can carry electricity and gas together, several meters, actual and estimated readings, tiered or time-of-use rates, and a dozen charge categories, each with its own unit. This guide covers what a good extraction should return, how to process a bundled statement without losing the structure, three different ways to get utility data, how the market splits, and named options across each category.

For utilities automating their own operations (vegetation management, work orders, regulatory filings), see our document automation for utility companies guide. This piece is about the bills those utilities send.

Who This Is For

Energy, facilities, and sustainability teams collecting bills across a portfolio of sites and providers.
AP and expense teams processing utility invoices at volume.
Product teams building energy, property management, solar, or carbon accounting features that depend on bill data.
Compliance and onboarding teams using utility bills as proof of address.

Why Utility Bills and Multi-Service Statements Are Harder Than Ordinary Invoices

Utility bill data extraction is the automatic capture of structured fields, such as meter number, usage, service period, and total due, from electricity, gas, water, and telecom bills. What makes it difficult isn't reading the characters. Parseur frames it directly: utility bill processing breaks on estimated reads, multi-meter invoices, and phone photos, not on OCR itself.

Hierarchy, not a flat list. Account, service, meter, and charge category nest inside one another. Invofox describes utility bills as hierarchical, multi-supply, multi-tariff documents, where a single bill can carry electricity and gas on the same page.
Units differ by service. Usage arrives as kilowatt hours, therms or CCF, gallons or cubic meters, and gigabytes or minutes for telecom, so each needs its own typed field rather than a shared "quantity."
Estimated versus actual reads. A number on the page isn't always a measurement. Extraction has to say which kind it is, or downstream analysis treats estimates as real consumption.
Complex charge structures. Time-of-use tariffs, tiered gas rates, and water excess-use surcharges all need consistent representation.
Two different addresses. Arcadia's documentation notes that account-level billing addresses are not equivalent to service location addresses, which matters when matching a bill to a site.

What a Complete Extraction Should Return

Provider. Utility name, address, and customer service contact.
Account. Holder, account number, meter number, and the service address kept separate from the billing address.
Billing period. Start date, end date, and number of days.
A separate block for each service. Utility type, previous and current meter readings, whether the read is actual or estimated, usage with its unit, and comparison with the prior period.
Charges within each service. Generation or supply, delivery or distribution, taxes, fees, and surcharges, plus tariff detail where present.
Statement totals. Current charges, previous balance, payments received, amount due, and due date.

The key design choice is the per-service block. Shared statement-level fields (provider, account, period, totals) sit once at the top, and each service becomes its own record beneath them.

How to Handle a Bundled Statement, Step by Step

Classify first. Decide whether the document is a utility bill at all, and which type. Invofox classifies every document before extraction and flags anything that isn't a utility bill upfront, rather than silently misprocessing it.
Split by service, account, and meter. A combined statement should become separate service records before extraction, not one confused record.
Extract each service into its own record, keeping shared statement fields separate from per-service ones.
Validate across the records. Recommended checks (these are practices, not vendor claims): per-service charges should sum to the statement total, billing periods should continue from the previous bill, usage should be plausible for its unit, and estimated reads should be flagged rather than passed through.
Route exceptions to a person. Anything that fails validation or comes back with low confidence goes to review, the mechanism covered in our confidence scoring and fallback logic guide. The same reconciliation idea applies to invoices, as covered in our line-item extraction guide.

Three Ways to Get Utility Data

Extract from the Document

You send a bill (PDF, scan, or photo) to a document processing API and receive structured fields back. It works across providers and formats, including proof-of-address uploads, and it's the only option when bills arrive as documents from many sources. Quality depends entirely on the extraction and validation behind it.

Connect to the Utility Account

Utility data platforms connect to a customer's utility account with authorization and return bills, statements, meters, and usage data directly. Arcadia's platform is the largest example, combining a utility data API, hosted credential collection with multi-factor authentication, tariff and rate calculations, and webhooks. UtilityAPI and Bayou Energy are named alternatives in a competitor's comparison. The trade-offs: it requires customer authorization, and one review notes Arcadia's direct connections are strongest in the US.

Use the Utility's Own Electronic Feeds

EnergyCAP notes that bills often exist in electronic formats beyond paper, including PDF, flat files (XLSX, CSV, TXT), XML, and EDI 810. If a provider offers a structured feed, that can beat OCR entirely. These routes also combine: Arcadia itself describes connecting through direct utility integrations or bill parsing.

How the Market Splits for Document Extraction

If you choose the extraction route, the tools fall into three groups. This framing comes from Parsepoint, which sells a utility-specific platform, so read it as one vendor's view of its own category:

Generic OCR and document processing tools. Parsepoint says these deliver high character-level accuracy but low structured-field accuracy on utility data without extensive template configuration.
Document AI platforms with general-purpose extraction. Flexible, but you define what to extract and how to handle utility-specific structure yourself.
Utility-specific platforms. Built only for energy and utility bills. Parsepoint claims these extract 30 or more fields per bill, including meter-level detail, demand data, rate information, and individual charge line items, against 5 to 10 basic fields for generic tools. Treat the figures as a vendor claim and check field coverage on your own bills.

Lido's own roundup adds a useful point about provider mix: template-based parsers suit a stable set of providers with consistent formats, while organizations dealing with many or changing providers need tools that handle any layout without per-utility templates.

Named Options

1. Purpose-Built Utility Bill Extraction APIs

Invofox

Invofox offers a utility bill OCR and parsing API built around the hierarchical structure of these documents.

Multi-supply records. Extracts consumption, reading types, time-of-use tariffs, full charge breakdowns, and multi-supply records, typed and structured.
Pipeline layers. Splitting, classification, extraction, validation, and review, each designed for multi-supply, multi-tariff bills.
Estimated readings flagged explicitly, which it ties to solar installers sizing systems from consumption history.
Rate structures. Gas tiered rates and water excess-use surcharges are handled with the same structure.
Scale. It cites a typical 200-site, 15-utility footprint producing thousands of documents a month. Its "under 10 seconds" figure is vendor-stated.
Best fit: multi-site energy teams and installers that need multi-supply structure preserved.

Parseur

Parseur turns each utility bill into named fields, typically one row per bill.

Usage as value plus unit, so kilowatt hours, therms or CCF, gallons or cubic meters, and gigabytes or minutes land in their own columns.
International coverage (vendor claim). It says its engines aren't tied to a country or template, reading Australian council rates notices and UK energy statements the same way as a US bill.
Scale guidance. It publishes a piece on what breaks between 50 and 3,000 bills, naming estimated reads, multi-meter invoices, and phone photos.
Best fit: teams wanting spreadsheet-ready rows across several countries quickly.

Affinda

Affinda positions its utility bill extraction for KYC, compliance, and billing systems.

Fields. Account holder names, addresses, bill dates, amounts due, utility types, and reference numbers.
Approach. It describes combining reading order models, OCR, LLMs, and RAG, and states it works regardless of format or language (vendor claims).
Best fit: compliance-led use where the bill feeds onboarding or verification.

Matil

Matil offers a specialized model for US utility bills covering electricity, natural gas, water, and sewerage.

Fields. Provider, holder, service address, account number, meter readings, usage in kWh, therms, or gallons, prior-period comparison, charge breakdown, taxes, fees, totals, and billing period.
Access. The model is listed with private access, so availability is by request.
Best fit: US-only pipelines that want a model tuned to US bill layouts.

Koncile

Koncile offers AI OCR for energy bills and utility invoices, available as an API.

Fields. Customer name, billing address, energy consumption, total amount due, issue date, due date, and contract number, from image or PDF uploads.
Output and integration. Structured data as a spreadsheet, JSON, or database records, with API access, automatic import from email, and direct ERP synchronization.
Error detection. It says it helps detect inconsistencies or errors across large volumes of bills.
Worth confirming. Its listed fields focus on energy bills, so ask how it handles multi-service statements and per-meter detail.
Best fit: teams whose bills arrive by email and need to flow into an ERP.

2. General-Purpose Document AI

DeepRead

DeepRead is a general-purpose, schema-driven extraction API, not a utility-specific product. That matters here because you define the schema yourself, including a nested array where each service on a statement becomes its own object with usage, unit, read type, and charges.

Structured JSON shaped to your schema, so a bundled statement can map to per-service records without a fixed template.
Per-field confidence scoring. Uncertain values are flagged needs_review rather than passed downstream silently.
Async processing and webhooks for portfolio-scale batches.
Limits, stated plainly. It has no utility-bill model or published accuracy for bills, and its benchmarks cover other document types. It also doesn't connect to utility accounts, audit tariffs, or pay bills. An estimated-read indicator can be a schema field, but how reliably it's extracted is something to test on your own bills.
Testing route. The free tier covers 2,000 documents a month with no credit card, and implementation details are in the docs.

Lido

Lido describes itself as an enterprise document intelligence platform for complex utility bill layouts.

Positioning. Its roundup says it handles format diversity across providers without per-utility templates and extracts account numbers, usage data, charges, and billing periods, with API-based automation.
Read its ranking with care. Its roundup ranks Lido first, so treat the comparison as marketing and use it mainly for its provider-mix framing above.
Best fit (its own positioning): large organizations processing bills from international providers with complex rate structures.

Nanonets

Named in Lido's roundup alongside Lido as offering API-based automation for utility bills. I only have that one-line characterization, so confirm capabilities and pricing directly.

3. Adjacent Options

These fit the wider "utility bills API" need but aren't head-to-head alternatives to the extraction tools above.

Arcadia

Arcadia combines a utility data API with bill management and sustainability services, and acquired ENGIE Impact in April 2026.

Data access. Bills, statements, meters, interval usage, and tariff rates, with hosted credential collection and webhooks.
Bill management. It distinguishes utility bill management (processing and payment) from utility expense management (auditing, tariff optimization, budgeting, forecasting), and claims 300+ automated checks per bill (vendor-stated).
Best fit: portfolios that want bill data, auditing, and carbon reporting in one relationship, mainly in the US.

EnergyCAP

EnergyCAP publishes guidance on getting utility bill data into an energy and sustainability ERP without manual entry.

Formats. It lists paper, PDF, flat files, XML, and EDI 810 as common bill formats.
Best fit: facilities and energy managers who want bill data flowing into an energy management system.

Nectar

Nectar positions itself as a complete application for facility and sustainability teams rather than only an API, with ENERGY STAR sync and carbon platform exports, per its own comparison page.

Best fit: teams that want an application above the data rather than a developer API.

Didit

Didit's proof-of-address API treats the utility bill as evidence, not as a data source.

Accepted types. Electricity, water, gas, internet, phone, cable and satellite TV, trash, sewage, heating, combined utilities, and municipal services bills.
Checks. Address extraction, and issue-date extraction and validation against configured requirements, with support for multi-page documents.
Best fit: KYC onboarding where the bill confirms an address rather than feeding energy analytics.

Where This Data Ends Up: Use Cases

Bill Audit and Accounts Payable

Structured bill data lets teams check charges before paying them.

Catch wrong rates, estimated charges, and duplicate fees
Reduce late fees from bills stuck in handoffs

Portfolio Energy Management

Facilities teams track consumption across many sites and providers.

Compare usage by site and period, matching each bill to the right site using the service address, not the billing address
Common destinations named by one vendor include ENERGY STAR Portfolio Manager, energy management platforms, property management software, and ESG reporting tools

ESG and Carbon Reporting

Consumption data feeds emissions calculations and disclosure reporting.

Arcadia and Nectar both position bill data toward carbon accounting
Estimated reads need flagging so reports don't treat them as measured

Solar and Energy Installers

Proposals depend on real consumption history.

Invofox specifically ties estimated-reading flags to system sizing accuracy

KYC Proof of Address

The bill confirms where someone lives.

Address and issue date matter more than usage
Combined and municipal bills are commonly accepted types

What Breaks in Production

Estimated reads. Extraction can be perfect, and the number still not be a measurement.
Multi-meter and multi-supply statements. A model that returns one record per document loses the structure.
Phone photos. Real submissions are often skewed, cropped, or shadowed.
Non-bills in the queue. Without classification, other documents get misprocessed as bills.
Unit mistakes. Mixing therms and CCF, or gallons and cubic meters, corrupts every downstream comparison.
Absolute accuracy claims. One utility-bill OCR API's FAQ claims 100% accuracy on clean images. Treat any absolute figure as marketing and test with your own messiest bills.

Conclusion

Utility bills and multi-service statements reward structure-aware processing: classify, split by service, extract each service into its own record, and validate across them. Whether the right route is document extraction, an account-linked data platform, or a utility's electronic feed depends on where your bills come from and how many providers you cover. Within extraction, the choice between generic tools, general-purpose document AI, and utility-specific platforms comes down to how much structure you want built in versus defined yourself. Test with your own messiest examples (estimated reads, multi-meter statements, phone photos) before committing to any option.

FAQ

What makes a multi-service statement harder than a normal invoice?

It's hierarchical. One statement can hold several services, meters, tariffs, and charge categories, each with its own units, so a flat extraction that returns one record per document loses the structure.

Should I extract from bill documents or connect to utility accounts?

Extraction works across any provider and format, including uploads and photos. Account-linked platforms return data directly but need customer authorization and have strongest coverage in the US. Some providers also offer electronic feeds (XML, CSV, EDI 810) that can replace OCR.

How do the main categories of utility bill tools differ?

Generic OCR tools read text but need heavy template work to return structured fields. General-purpose document AI platforms let you define the schema yourself. Utility-specific platforms come with utility fields and structure built in. The category framing comes from a vendor, so check field coverage on your own bills.

How should estimated readings be handled?

Extract the read type alongside the number and flag estimates explicitly, so analysis, reporting, and system sizing don't treat estimates as measured consumption.

What checks catch errors in bundled statements?

Recommended checks include per-service charges summing to the statement total, billing periods continuing from the previous bill, usage being plausible for its unit, and estimated reads being flagged.

Can utility bills be used for proof of address?

Yes, many verification APIs accept them, including combined utilities and municipal bills. There, the address and issue date matter more than usage or charges.

Does DeepRead have a utility bill model?

No. It's a general-purpose, schema-driven extraction API, so you define the utility schema yourself, including a nested per-service structure. It has no published accuracy for utility bills, so test it on your own documents using the free tier first.