Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Utility bill watcher series ~5 min read

How a bill gets matched to a meter

This is the shortest post in the series and the one that catches the most money. Matching a bill to a meter sounds like a lookup, and mostly it is. The interesting cases are the ones where it fails, because a utility bill that does not match any meter you know about is almost never an error — it is usually a supply you have been paying for and forgot you had.

Key takeaways

  • The meter number is matched against your list; it is never trusted straight off the page.
  • Three steps: exact meter number, then supplier account, then site plus utility plus period.
  • An unmatched bill is a question to a person, and it is often a supply nobody remembered.
  • A meter that stops producing bills is a louder signal than any single bill.
  • Matching is recorded, so a supplier reformatting their bill does not silently break history.

The three-step match

The three-step match from a bill to a meter on your listA vertical chain of four steps entered by a box labelled Read bill, carrying five fields and one meter-number hint. Step one asks whether the meter number matches exactly, normalised to digits only, against the meter list; a hit exits to Matched, the usual outcome. Step two asks whether the supplier account number matches, and a hit exits to Matched while recording the new meter-number format. Step three asks whether the site, utility and period identify exactly one candidate; one candidate exits to Matched provisionally, with a human asked to confirm. Step four is Unmatched, a bill for something not on your list. A note says the last box is the interesting one and usually means a supply nobody remembered.AWS ACCOUNTRead billfive fields, one hintMeter number exact?digits only, normalisedMeter listyour own tabMatchedthe usual outcomehitSupplier account?account number on the billMatchedrecord the new meter formathitSite + utility + period?one candidate onlyMatched, provisionallyask a human to confirmoneUnmatcheda bill for somethingnot on your listThe last box is the interesting one. It usually means a supply nobody remembered.
Fig 1. Matching in three steps, with a deliberate fourth outcome. An unmatched bill is not a failure of the system; it is the system finding something.
  • App integration
  • Machine learning
  • Management
  • Analytics
  • People

Why exact matching needs normalising

The same meter appears as 1200034557, 12 0003 4557, MPAN 1200034557 and occasionally with a leading profile class that is part of a different identifier entirely. Stripping everything but digits and comparing suffixes handles almost all of it. What it does not handle is a supplier who renumbers on migration, which is why step two exists.

The provisional match

Step three is the one that needs care. If a bill is for electricity, at a site you can identify from the address, for a period where you have exactly one electricity meter at that site with no bill yet, it is almost certainly that meter. Almost certainly is not certainly, so the match is made provisionally, the comparison runs, and a person is asked to confirm before the bill updates the baseline history.

What an unmatched bill usually is

  • A supply nobody remembered. An outside light circuit on its own meter, a water supply to a yard tap, a gas meter for a boiler in a unit you sublet. These get paid by direct debit for years. Finding one is frequently the single largest saving this whole system produces.
  • A property you no longer occupy. The second most common, and the most expensive. A supply at a former site that was never closed keeps billing standing charges indefinitely.
  • A genuinely new meter. A new site, a split supply, a replaced meter with a new number. Confirming it adds a row to the list, which is a fifteen-second job that somebody has to actually do.
  • Somebody else’s bill. Rare, but it happens, particularly in shared buildings. Worth catching before it is paid.

The bill that never arrives

Matching has a mirror image that most systems miss entirely: a meter on your list that has stopped producing bills. That is a louder signal than almost any single bill, and it takes a scheduled sweep rather than a reaction to an arrival.

How a meter that has stopped producing bills is detectedA horizontal row of five boxes. Expected cadence: derived from the last six bills for that meter. Overdue: no bill for one and a half times the usual gap. Check the folder: including the spam quarantine. Ask: one message per meter. Catch-up expected: the eventual bill should not be treated as a usage spike. A note says a missing bill becomes a catch-up bill and a catch-up bill is not a usage spike.A METER THAT STOPPED BILLINGExpected cadencefrom the last 6 billsOverdue1.5x the usual gapCheck the folderand the spam quarantineAskone message per meterCatch-up expecteddo not treat as a spikeA missing bill becomes a catch-up bill, and a catch-up bill is not a usage spike.
Fig 2. The sweep for meters that have gone quiet. The last stage matters: when the missing bills eventually arrive as one catch-up, that is not a spike and must not be reported as one.
  • App integration
  • Management
  • Analytics

The last stage is a small piece of state that saves a lot of noise. Once a meter is flagged overdue, the comparer knows that the next bill for it may cover a longer period, and it compares on a per-day basis rather than a per-bill one. Without that, every supplier billing hiccup produces a false alarm two months later.

Next: what the message says when something has genuinely moved.

All posts