Account Number vs Meter Number vs Service ID on a Utility Bill

Three different things, three different lifespans:

• Account number identifies the billing relationship between the utility and whoever is paying. It changes when the payer changes.
• Meter number identifies a physical device bolted to a wall. It changes when the device is replaced.
• Service point ID (also premise ID, point of delivery, service agreement ID) identifies the place being served. It almost never changes.

If you are building a time series of consumption for a building, you key on the service point, not the account number. Keying on account number is the single most common way a utility dataset silently goes wrong, because the failure looks like a real change in consumption rather than like a bug.

What each identifier actually is

Account number. A financial construct. It exists so the utility knows who to invoice and where to apply payments. One account can cover a single meter, or forty meters across twelve addresses, or a whole campus rolled into a summary bill. When a tenant moves out and a new one moves in, the utility closes one account and opens another. The wires and the meter do not move.

Meter number. Usually the serial number stamped on the device by the manufacturer, sometimes a utility-assigned asset tag. It is the number a field tech reads off the faceplate. Meters get swapped for AMI upgrades, failures, tamper events, capacity changes, and routine end-of-life replacement. When that happens the new meter has a different number, and often the register rolls back to zero.

Service point / premise ID / point of delivery. The location where the utility’s distribution system hands off to the customer’s system. This is the identifier tied to the physical connection: the transformer, the drop, the pipe stub. It survives meter swaps, tenant turnover, name changes, and account consolidations. It is also the identifier least likely to appear anywhere on the printed bill.

Internal identifiers. Most utilities carry several more that leak onto bills inconsistently: rate schedule codes, cycle/route/sequence numbers for the meter reader, contract or agreement IDs, and in gas, a separate delivery point number. These are useful as attributes. None of them are stable keys.

The cardinality that trips everyone up

One account, many meters. A grocery store on Duke Energy has one account number and three meters: main service, refrigeration house panel, and a separate meter for the fuel canopy. Three rows of usage detail, three meter numbers, one account number on the remittance stub. Sum them and you get the site; treat the account as a meter and you get a number three times too large attributed to one device.

One meter, many accounts. A retail suite on Con Edison. Tenant vacates March 31, landlord takes the space back on a house account, new tenant signs April 1. Same meter, same wires, three account numbers inside one calendar year. The meter never noticed.

One address, many service points. 400 Industrial Parkway has an electric service point for the plant, a second electric service point for the chiller yard fed from a different transformer, and a gas service point. Same street address on all three bills. If you join on address text you will fuse them into one building and produce an electric intensity figure that is nonsense.

One service point, many meters over time. Meter 1009471234 is pulled on August 14 and meter 2214598877 goes in. The service point ID is unchanged. Your consumption history should be continuous. If you keyed on meter number, you now have one site that appears to have shut down mid-year and another that appears to have opened.

That last one is why “just use the meter number” is also wrong. The meter is a better key than the account, but it is an asset, not a location. Assets get replaced.

Where each one shows up on real bills

The labels are not standardized, and the differences are not cosmetic. A parser that looks for the literal string “Meter Number” will miss half the bills it sees.

Label variants you will hit across a mixed portfolio: Account Number, Customer Account, Customer Number, Account No., Service Agreement ID, SAID, Meter Number, Meter #, Meter Serial, Meter Serial No., Device ID, Premise Number, Premise ID, Service Point ID, POD ID, Point of Delivery, ESI ID. Some of these are the same concept under different names. Some are not. “Service ID” in particular is ambiguous and means the location on one utility’s bill and the billing agreement on another’s.

Two rows in that table deserve a second look.

PG&E is the useful exception: the SAID is a genuine service-point-level identifier printed right on the bill, which makes PG&E portfolios noticeably easier to key than most. SCE is the other, and it is the clearest case in the industry of a utility drawing the distinction explicitly — it issues a Customer Account Number for billing and a separate Service Account Number for the address, meter, and rate, and tells customers so in as many words. Where a utility has done that work for you, use it.

The general rule is the opposite: the identifier you most want is the one the bill is least likely to give you.

Then there is the harder problem, which is that these formats are not fixed. Con Edison account numbers used to be 15 digits in hyphenated groups and are now 11. Any regex written against the old format stopped matching, and an archive spanning the migration contains both. This is the argument against treating a format as a rule rather than as an observation with a date attached: rate codes get renumbered, account formats get migrated, and territories that bill in CCF get moved to therms. Plan for the identifier to change and you will be right more often than the parser that assumed it wouldn’t. Which fields you can actually count on is covered in what fields to extract from a utility bill.

Worked example: four sites, two years

A portfolio of four sites. Electric only. Actual annual consumption:

Three things happened in 2024:

1. Fresno had a meter swap on August 14. Meter 1009471234 was pulled at 271,400 kWh year-to-date; meter 2214598877 recorded 158,300 kWh through December. Account number and SAID both unchanged.
2. The Manhattan tenant changed on March 31. Old account recorded 24,900 kWh; new account 78,200 kWh. Same meter, same service point.
3. Charlotte’s three accounts were restructured onto a single parent account effective June 1, at the customer’s request. Jan–May under the three old accounts: 431,700 kWh. Jun–Dec under the parent: 554,700 kWh.

Now key the same bills on account number and build a same-store year-over-year table, limited to accounts with twelve months in both years:

Same-store total: 1,101,000 in 2023, 1,131,600 in 2024. +2.8%.

Reality is -1.2%. The sign is wrong and the magnitude is off by four points, and nothing about the output looks broken. There is no error, no null, no failed parse. The report renders cleanly and the number is false. The Charlotte campus, the site that actually drove the portfolio down, dropped out of the comparison precisely because it was the site where somebody did the most work.

Keyed on service point, all four sites carry continuous history. Charlotte’s three service points come through as 612,000 → 574,300, 298,000 → 279,500, and 140,000 → 132,600, summing to the correct 986,400, regardless of how many account numbers those bills arrived under.

Fresno is the case that also kills meter-number keying: keyed on meter, that site splits into 412,600 → 271,400 (an apparent 34% collapse) and a phantom new meter with 158,300 kWh and no history.

When the bill doesn’t print a meter number

Common on consolidated bills, summary bills, and gas bills from smaller LDCs. Some bills give you an account number, a total, and nothing else.

First, try to get the identifier from somewhere other than the PDF. In rough order of reliability: the utility’s EDI 867 feed if you have one, a Green Button Download My Data export, the account’s online portal (which usually exposes premise or service point data the print stream omits), or the account rep. Ten minutes on the portal beats a permanently ambiguous key.

If none of that is available, build a surrogate key. Deterministic hash of:

surrogate_key = sha256(
  utility_id + "|" +
  account_number + "|" +
  normalized_service_address + "|" +
  commodity + "|" +
  rate_schedule
)

That key is only safe under four rules:

• Store it in a mapping table with effective start and end dates, not as a computed column. When an account number changes, you close the old row and point the new one at the same internal site ID. The mapping is data you maintain, not output you regenerate.
• Never let the key change silently. If a hash input shifts because a parser started reading the rate schedule differently, you want an exception, not a new site.
• Check billing continuity on every load: current previous-read should equal prior current-read, and service periods should abut without gaps or overlaps. A break is your signal that something underneath the key moved.
• Flag every surrogate-keyed site as lower confidence and review it when a site’s year-over-year swings more than a threshold you pick. Most silent corruption announces itself as an implausible delta first.

Address normalization is the weak point and it is genuinely tedious. “400 Industrial Pkwy Ste B”, “400 Industrial Parkway, Suite B”, and “400 INDUSTRIAL PKY STE. B” all have to collapse to one string, and the suite matters because two suites can be two service points. Do not skip suite and unit designators in normalization. That mistake merges tenants.

ESI ID, POD ID, and the markets that fixed this

Deregulated markets had to solve this, because a retail supplier switching a customer needs to identify a location independent of whichever supplier or account currently serves it.

In Texas, that is the ESI ID (Electric Service Identifier), assigned by the wires company (Oncor, CenterPoint, AEP Texas, TNMP), not by the retail provider. It is a long numeric string tied to the premise, it survives supplier switches and meter changes, and it is the key ERCOT market transactions run on. If you have Texas sites, key on ESI ID and stop thinking about it.

New York and Pennsylvania use POD ID (Point of Delivery) for the same purpose in retail access. Other restructured markets have their own equivalents under their own names. The pattern is consistent: wherever competitive supply exists, somebody was forced to define a stable location identifier, and it is usually the best key available in that market.

Regulated markets had no such forcing function. The utility knows its premise IDs perfectly well internally. It just has no reason to print them.

There is no universal standard

There is no cross-utility registry, no shared format, no API you can call to resolve an account number to a location. Any system that handles more than one utility has to maintain its own mapping layer: internal site ID, service point ID where one exists, the set of account numbers that have served it and when, the set of meter numbers that have served it and when, commodity, and utility.

That layer is the actual asset. The extraction is the easy part; correctly attaching each extracted bill to a stable site over years of account churn is the hard part, and it is a large share of why AI bill extraction fails in production even when the field-level accuracy looks fine. Downstream systems inherit the problem directly — ENERGY STAR Portfolio Manager models meters under properties, so a meter swap logged as a new meter with no history will quietly distort a score.

Build the mapping table first. Everything else is easier afterward.