Utility bill watcher
A small system that reads each utility bill for each site as it arrives, pulls out the usage, the unit rate and the standing charge, and compares all three against your own history and your contracted rate. A bill that behaved gets filed silently. A bill that did not gets one message saying which of the three moved and by how much. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.
- 01
A utility bill watcher on AWS for a few dollars a month
The whole system on one page — a reader, a comparer and a reporter — and the decision that makes it useful: compare three numbers separately rather than one total.
- 02
How a utility bill gets read
Two lanes in, and a page that every supplier lays out differently. What makes extraction safe is that the meter number is matched against your own list and an unreadable figure stays null.
- 03
How a bill gets matched to a meter
The meter number on the page is a hint, not an answer. A three-step match against your own list, and what an unmatched bill usually turns out to be.
- 04
How a change gets reported
One message per bill, naming which of the three numbers moved. Usage sends somebody to a site, rate sends somebody to a phone, and saying which is the whole value of the message.
- 05
How the utility history builds
The row every bill writes, why an estimated reading never becomes the baseline, and the three things clean per-meter history makes possible that no single bill ever can.
- 06
What the utility bill watcher costs
About $2 a month. One Bedrock read per bill is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the utility bill watcher architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is a utility bill watcher?
- A small serverless system that reads every utility bill as it arrives, extracts the usage, the unit rate and the standing charge, and compares each against your own history for that meter and against the rate you contracted. Bills that behave are filed without a word; bills that moved produce one message naming what changed.
- Why compare three things rather than just the total?
- Because the total tells you nothing about what to do. A bill that doubled because usage doubled is an operational problem — something is running that should not be. A bill that doubled because the unit rate moved is a contract problem. The response is completely different, and a total cannot tell them apart.
- Does it need a supplier API?
- No. Bills arrive the way they already arrive — a PDF attached to an email, or a portal download dropped into a folder. Textract reads them, and the extraction is grounded by the meter list you keep, so a model matches to a known meter rather than inventing one.
- What about estimated readings?
- They are detected and handled separately. An estimated bill is compared but never used to update the baseline, because a run of estimates followed by a real reading produces a catch-up bill that would otherwise look like a crisis.
- What does it cost to run?
- A few dollars a month even across a dozen sites. Nothing is always-on. See part six.