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

The three identifiers refer to different parts of utility service:

• Account number identifies the billing relationship with the customer responsible for payment.
• Meter number identifies the device that records consumption.
• Service point ID identifies a service location or agreement. Utilities also use names such as premise ID, point of delivery ID, and service agreement ID.

For a building-level usage history, use a location-level identifier when the utility provides one. It will usually outlast an account or meter number. If the bill does not include one, keep your own mapping from each account and meter number to an internal site ID.

What each identifier actually is

Account number. This tells the utility where to apply charges and payments. One account may cover one service or several, depending on the billing arrangement. A change in customer, ownership, or account structure can produce a new number even when service at the property continues.

Meter number. This is usually a serial number or utility asset number for the physical meter. A replacement meter normally has a new number and a new register reading.

Service point / premise ID / point of delivery. This is a utility-defined identifier tied to a service location, delivery point, or service agreement. It is often more stable than the account or meter number, but the exact meaning varies by provider. It may appear only in the utility portal or an electronic data feed rather than on the PDF.

Other numbers may appear too: rate schedule, read cycle, route, contract, or agreement ID. Store them as attributes until the utility’s documentation makes their role clear.

How the identifiers relate

One account, many meters. A commercial account might include a main electric service, a refrigeration panel, and a separate canopy meter. That is three meter-level usage rows under one account number.

One meter, several accounts over time. A tenant leaves, the landlord briefly assumes service, and a new tenant opens an account. The account number can change twice while the meter stays in place.

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 case is why the meter number is not a permanent building key. It identifies equipment, not the building.

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.

These details are documented by PG&E, SCE, Xcel Energy, and Con Edison. They are examples, not a universal format.

Across a mixed portfolio, expect labels such as Account Number, Customer Account, Account No., Service Agreement ID, SAID, Meter Number, Meter #, Meter Serial, Device ID, Premise Number, Service Point ID, POD ID, and ESI ID. Similar labels do not guarantee the same meaning. “Service ID” is especially ambiguous.

PG&E and SCE both print a billing account number and a separate service-level number. Where the utility documents that distinction, preserve both values.

Formats also change. Con Edison moved from a 15-digit account number to 11 digits during its billing-system migration. An archive can therefore contain both. Treat a length or punctuation pattern as a dated validation rule, not as the definition of the field. The broader schema is covered in what fields to extract from a utility bill.

Illustrative example: four sites, two years

The following numbers are fictional and show the effect of choosing the wrong key. The arithmetic is complete so you can reproduce the comparison.

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%.

The full portfolio changed by -1.2%, while the account-keyed same-store subset reports +2.8%. No parse fails; the declining Charlotte site falls out of the comparison after the account restructure.

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

Consolidated and summary bills may omit a meter number from the summary page. Some statements provide only an account number and service address.

First, check another source: an electronic data interchange (EDI) 867 feed, a Green Button export, the utility portal, or the account representative. The portal may expose service-level details that the PDF omits.

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.
• Do not 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 each load. Compare register reads when the bill provides them, and flag service-period gaps or overlaps for review.
• Mark surrogate-keyed sites as lower confidence. Review material year-over-year changes against the source bills.

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 IDs in the Texas retail market

Retail markets need a service identifier that is separate from the customer’s billing account.

In Texas, the transmission and distribution provider assigns an ESI ID (Electric Service Identifier). The Electric Reliability Council of Texas (ERCOT) uses ESI IDs in retail market data for meter reads, move-ins, and supplier switches. Smart Meter Texas lists the ESI ID under premise information, separately from meter details. For a Texas property, it is usually the best available service-level key. See ERCOT’s retail market page for the current transaction files.

Other markets and utilities use their own service-point or point-of-delivery identifiers. Confirm the definition before treating one as permanent.

There is no universal standard

There is no single cross-utility identifier format. A multi-utility dataset therefore needs its own mapping layer: internal site ID, documented service-point ID when available, account and meter numbers with effective dates, commodity, and utility.

The mapping layer is as important as the extraction. A field can be transcribed correctly and still be attached to the wrong site. That problem appears in AI extraction workflows and in ENERGY STAR Portfolio Manager setup, where meter data must be associated with the correct property.

Build the mapping table before loading years of bills.