Extracting Reading Values From a Utility Meter Bill

A utility bill is one of the few documents that hands you a verification for free. Somewhere on it is a previous reading, a current reading and a consumption figure, and those three numbers are related by an equation the utility itself computed. If your extraction does not satisfy it, you misread a digit — and you know that before anybody downstream acts on the number.

What a meter block actually contains

The block is usually printed small, often on the reverse or in a summary panel labelled something like billing detail or meter information, and it holds more fields than the two obvious ones.

• Meter number, which identifies the physical device and is the key you need if the account has several. It is a string, not an integer: leading zeros are significant and some carry letters.
• Previous reading and current reading, each with its own read date. The dates matter as much as the values, because they define the service period.
• Read type, a single-letter code in most formats: an actual read taken at the meter, an estimated read computed from history, or a customer-supplied read. This one letter changes what the numbers mean and is the field extractors skip most often.
• Multiplier, sometimes printed as multiplier, constant, or a current-transformer ratio. On residential accounts it is 1 and is often not printed at all. On commercial accounts metered through instrument transformers it can be 40, 80, 200 or more.
• Consumption or billed usage, in the unit the tariff bills in: kilowatt-hours, hundred cubic feet, cubic metres, therms, gallons.
• A conversion factor on gas bills. Gas meters measure volume, gas is billed in energy, and the bill prints a thermal or BTU factor that converts one to the other.
• Demand on commercial electric accounts: a peak kilowatt figure read from the same meter but not derived from the two readings at all.

The identity that must hold

Strip away the presentation and every meter block asserts the same thing.

consumption = (current_reading - previous_reading) * multiplier

On a gas bill there is a second step, and it is the one that produces the number the tariff actually prices:

therms = ccf * thermal_factor

Both are checkable to the unit. Worked on a synthetic electric bill — every figure here is invented for the example — a previous reading of 99,412 and a current reading of 00,317 on a five-digit register with a multiplier of 1 gives a consumption of 905 kilowatt-hours, and 905 is what the bill prints. Misread the current reading as 00,817, a plausible confusion of 3 for 8 on a low-contrast scan, and the computed consumption becomes 1,405 against a printed 905. The error is 500, which is 100 times the digit position that was misread: the magnitude of the discrepancy tells you which digit to look at again, and that is a genuinely useful diagnostic to put in front of a reviewer rather than a bare mismatch flag.

Because the check is exact for electricity and water, the tolerance should be zero — this is a cross-field amount validation rule in the ordinary sense, with the unusual property that it admits no slack. Gas needs a tolerance, because the therm figure is rounded before printing and the thermal factor is itself printed to a few decimals; a tolerance of one therm, or of half a unit in the last printed place, absorbs the rounding without absorbing a misread digit.

Rollover, and why the fix is dangerous

A mechanical register has a fixed number of digits and wraps when it passes its maximum. A five-digit register goes from 99,999 to 00,000, so a subtraction of the printed values gives a large negative number. The correction is modular arithmetic against the register size:

delta = current - previous
if delta < 0:
    delta = delta + 10 ** register_digits

In the worked example above, 317 minus 99,412 is −99,095, and adding 100,000 gives 905. The correction is right, and it is also the single most dangerous line in a meter extractor, because it converts any transposition that happens to make the current reading smaller than the previous one into a large positive consumption that looks entirely plausible. Read 91,412 as 99,412 on the previous reading and the rollover rule will cheerfully manufacture eight thousand kilowatt-hours of usage.

The discipline is to apply the correction only when the result is consistent with something else. Two guards are enough in practice. First, the corrected delta must still match the printed consumption — if you are correcting a rollover and the identity then fails, you did not have a rollover, you had a misread. Second, a rollover is a rare event on a meter whose register is many digits wider than a period’s usage, so a rollover on an account whose typical monthly usage is three orders of magnitude below the register maximum deserves a review flag even when the arithmetic works.

Do not infer the register width from the printed values. A reading printed as 00,317 tells you the register has at least five digits; a reading printed as 317 with leading zeros stripped by whoever generated the PDF tells you nothing. Register width belongs in the account master data, and where it is genuinely unknown the honest extraction result is a rollover flag with the delta left unresolved.

A dropped multiplier has a signature

The most common way for the identity to fail on commercial bills is that the multiplier was not extracted, because it is printed in a separate box, in a different font, or on the tariff summary rather than the meter block. The failure has a recognisable shape: the ratio of printed consumption to computed delta is an exact integer, or an exact common ratio like 7.2, rather than a near-miss.

That distinction is worth encoding. A mismatch whose ratio is within a rounding of a plausible multiplier is a missing-field problem, and the right response is to go and look for the field, or to accept the implied multiplier and flag it for confirmation against account master data. A mismatch whose ratio is 1.55 is a digit problem. Two very different queues, distinguished by one division. The general machinery for routing those queues — thresholds, sampling, what a reviewer sees — belongs to confidence threshold review routing, extraction confidence and confidence UX; what is document-specific is that the arithmetic, not the model, is what decides which queue a bill lands in.

Cases where the identity is right to fail

• An estimate followed by an actual. When a period is estimated and the next is read at the meter, the second bill’s delta covers whatever the estimate got wrong as well as the real usage. The arithmetic still holds within each bill, but the month-to-month series is distorted, and only the read-type letter tells you that. Extract it or your consumption history is quietly wrong.
• A meter exchange mid-period. The bill then shows two meter numbers, each with its own reading pair: the old meter’s final read and the new meter’s starting read, which is usually zero or near it. Total consumption is the sum of two deltas, and the old meter’s final reading is emphatically not the new meter’s previous reading. A schema with one reading pair per bill cannot represent this at all, which is the real reason to make readings a list keyed by meter.
• Net metering. A site with generation has delivered and received registers, and often four readings rather than two. Netting them into one number before storage destroys the only data an energy analyst wants.
• Service period versus days billed. The count of days between the two read dates and the printed number of days in the period commonly differ by one, because one is an inclusive count and the other is not. Check it, but with a tolerance of one day, and do not use the discrepancy as evidence of a misread.
• A prorated period after a rate change. The meter block still reconciles; the charges split into two rate periods. That is the subject of extracting rate tiers, and the consumption figure you have just validated is its input.