Utility data formats: EDI 810/867, Green Button, PDF, CSV

If you manage energy or utility spend across more than a few accounts, you already know the data does not arrive in one shape. One supplier sends a PDF, another posts a CSV, a regulator mandates Green Button, and a large industrial account trades invoices as EDI. Before any of it can be analyzed, budgeted, or reported, it has to be pulled into a single consistent structure. This article walks through the four formats you actually deal with, what each one is designed for, and where each one gets in your way.

The four formats you actually deal with

PDF and paper bills

The PDF bill is the document a supplier produces for a human to read. It carries everything (rate class, meter reads, demand, taxes, riders), but it carries it as layout, not as data. Two suppliers can present the same facts in completely different arrangements, and the same supplier can change its template without notice. PDF is the most common format and the least machine-friendly, which is why so much utility data still gets keyed by hand.

CSV and spreadsheet exports

Many portals let you export a CSV or spreadsheet. That is a step up from PDF because the values are already separated into columns, but there is no shared schema across suppliers. Column names, date formats, units and sign conventions all differ, so a CSV that loads cleanly from one account may need remapping for the next. CSV is convenient for a one-off pull and awkward as a standing feed.

Green Button XML (the ESPI standard)

Green Button is the closest thing to a real standard for consumer and commercial energy usage data. It is based on the Energy Services Provider Interface (ESPI), a data standard released by the North American Energy Standards Board (NAESB) in 2011 that defines both a common XML format for energy usage information and a protocol for exchanging it. Green Button data files use the Atom Syndication Format to wrap structured usage and customer data as XML, built from NAESB schemas, so a UsagePoint and its interval readings mean the same thing across every compliant supplier.

There are two access methods worth knowing. Download My Data lets a customer download their own XML file directly. Connect My Data uses the OAuth authorization framework so an authorized third party can pull the data automatically through an API, which is the version that matters for ongoing integrations. The underlying rules live in the NAESB REQ.21 ESPI standard, and the current ESPI version 4.0, published in December 2023, raised the minimum transport security to TLS 1.3. Adoption is broad: utilities and suppliers have committed to giving more than 60 million homes and businesses access to their own Green Button data.

EDI 810 and EDI 867

Electronic Data Interchange (EDI) is how large accounts and suppliers trade billing data machine to machine. The formats come from the Accredited Standards Committee X12, which defines and maintains transaction sets for specific business purposes. Two matter here. The EDI 810 is the invoice transaction set used to request payment between trading partners, and the EDI 867 Product Transfer and Resale Report is, in the utility context, used to communicate meter information: usage of electricity, natural gas and so on. In short, the 810 carries the charges and the 867 carries the consumption.

Why so many formats is a problem

The trouble is not any single format. It is that a real portfolio contains all of them at once, in different versions, changing over time. A PDF carries the full charge detail but no structure. A Green Button feed carries clean interval usage but often not the full financial breakdown of the invoice. An EDI 810 carries the charges and an 867 carries the usage, but they arrive separately and have to be tied back together. Reconciling across formats by hand is where the hours go and where errors creep in.

What good looks like: one clean internal model

The way out is to stop treating each format as its own project and instead map every source into one internal data model. Whether a reading arrives as a PDF line, a CSV column, a Green Button UsagePoint or an EDI segment, it should land in the same field, in the same units, tied to the same account and period. Once that is true, analysis, budgeting, cost allocation and reporting all run on one consistent structure instead of five inconsistent ones.

• Read every format into the same schema: account, meter, period, usage, demand, charges
• Normalize units, sign conventions and date ranges so records are comparable
• Tie the invoice (810 or PDF) to the usage (867 or Green Button) for the same period
• Validate each record against the tariff and against the account's own history
• Export the clean result to accounting, benchmarking and reporting tools

This is the work MartinAI is built to do. It reads the messy inputs, structures them, checks them, and hands you data you can trust, so the format a supplier happens to use stops being your problem.