Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Utility bill watcher series ~6 min read

A utility bill watcher on AWS for a few dollars a month

Utility bills are the classic small-business blind spot: too small to justify attention individually, too numerous to check, and just variable enough that a bad one looks like a normal one. A cafe with three sites gets roughly a hundred and forty utility bills a year. Nobody reads a hundred and forty bills. So the tariff that rolled onto a variable rate in March gets noticed in September, and the freezer that has been running with a failing door seal since April never gets noticed at all. This post walks through a small system that reads all of them.

man holding papers while operating a large grey industrial machine
Photo by Geraldine Lewa on Unsplash

Key takeaways

  • Bills arrive the way they already do: a PDF in an email, or a portal download in a folder.
  • Three numbers are pulled from each: usage, unit rate, and standing charge.
  • Each is compared separately — against the same period last year and against your contract.
  • Only a bill where something moved produces a message. Most produce nothing.
  • Designed on AWS for about $3 a month across a dozen sites.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: bills in, meter list as reference, three pieces inside AWSThree boxes across the top sit outside the AWS account. On the left, Bills: arriving as a PDF attached to an email or as a portal download dropped in a folder. In the middle, Meter list: the sites, the meter numbers, the contracted unit rates and the contract end dates. On the right, Whoever pays: the person who hears only about bills where something moved. Each connects by an arrow to the AWS account container below. Bills flow down into the account. The meter list feeds in to say which meter a bill belongs to and what rate was agreed. Inside the AWS account are three components in a row. On the left, the Reader, which pulls the usage, the unit rate and the standing charge out of each bill. In the middle, the Comparer, which sets each of those three against the same period last year and against the contracted rate. On the right, the Reporter, which names what moved and by how much. A note at the bottom says a bill that behaved is filed and never mentioned, and that this is most of them.AWS ACCOUNTBillsemail PDF or folderMeter listsites, rates, contractsWhoever payshears only what movedReaderusage, unit rate,standing chargeComparervs last year,vs the contractReportername what moved,and by how muchbills inwhich meter, whatrateonly what movedA bill that behaved is filed and never mentioned. That is most of them.
Fig 1. Three things outside the account, three pieces inside it. Bills arrive however they already do, the meter list says which meter and what rate was agreed, and only movement produces a message.
  • Machine learning
  • Management
  • Analytics
  • People

What you set up once (the outside)

  • A place for bills to land. A dedicated address that suppliers already email, or a folder that a portal download gets dropped into. Both are covered in Part 2. Nobody changes how bills arrive; that is the whole point.
  • A meter list. One tab: each meter number, which site it belongs to, what it supplies, the contracted unit rate and standing charge, and when the contract ends. Most small businesses do not have this written down anywhere, and building it is genuinely the hardest part of the project — and worth doing even if you build nothing else.
  • A tolerance line. How far a number has to move before it is worth mentioning. Usage swings with weather and trade, so the default is generous: twenty-five per cent against the same period last year. Rates are different — a unit rate that differs from the contract at all is worth a message, because it is either an error or a contract that rolled over.

What runs on every bill (the inside)

  • The reader. Turns a PDF into three numbers plus the meter number and the period. Utility bills are visually chaotic and vary wildly between suppliers, so this is where Textract and a model earn their keep — but the meter number is matched against your list rather than trusted from the page, and a number the reader is not confident about is left null.
  • The comparer. Three comparisons, each against two references. Usage against the same period last year for that meter, and against the previous period. Unit rate against the contract. Standing charge against the contract. Each comparison is a subtraction, and each carries the two numbers that produced it.
  • The reporter. Builds a message only when something moved past its tolerance, and the message says which of the three moved. That distinction is the entire value: “usage up 40% on last July” sends somebody to look at a freezer, and “unit rate up 62% against contract” sends somebody to phone a supplier. Those are different days.

One bill, end to end

One utility bill from arrival to filing, in five stagesA horizontal row of five boxes joined by arrows. Arrived: a PDF from any supplier. Read: three numbers and one meter number extracted. Matched: to a meter on your own list. Compared: against history and against the contract. Filed: silently, or with one message. A note says four of the five stages are silent and the fifth usually is too.ONE UTILITY BILL, END TO ENDArrivedPDF, any supplierRead3 numbers, 1 meterMatchedto a meter you knowComparedhistory and contractFiledor one messageFour of the five stages are silent. The fifth usually is too.
Fig 2. The same system as one line. The output of most bills is a row in a history table and nothing else at all.

In plain words

The electricity bill for your Hitchin site arrives on the 12th. The reader pulls out 4,180 kWh, a unit rate of 24.1p and a standing charge of 48p a day, on meter 1200034557. That meter is on your list, it is Hitchin, and the contract says 24.1p until November. Usage last July on the same meter was 3,980 kWh, so this is five per cent up — well inside the band. Every number behaves. The bill is filed, the history row is written, and nobody hears anything.

The August bill for the same meter comes in at 6,240 kWh. Same rate, same standing charge, but usage is up fifty-seven per cent on last August. One message goes out: “Hitchin electricity: usage 6,240 kWh, up 57% on Aug 2025 (3,970). Rate and standing charge unchanged.” That sentence is doing something specific — it has already ruled out the two commercial explanations, so the person reading it knows immediately that something at the site is drawing power. It turned out to be a walk-in fridge with a door that was not sealing, which had been running flat out since the middle of July.

Design rules that shaped every decision

  • Three numbers, compared separately. A total cannot distinguish an operational problem from a contract problem, and those need different people.
  • The meter list is the source of truth. A bill for a meter that is not on the list is a question, not a new meter.
  • Compare against the same period last year, not last month. Utilities are seasonal and month-on-month comparison generates constant noise.
  • An estimated reading is compared but never becomes the baseline. A run of estimates followed by a real reading produces a catch-up that would look like a crisis.
  • Rate tolerance is near zero. Usage moves for a hundred honest reasons; a unit rate that differs from the contract does not.
  • Nothing is ever paid, disputed or cancelled by the system. It reads and it tells you.

Why this shape

The reason nobody checks utility bills is not laziness; it is that checking one properly requires last year’s bill for the same meter, the contract, and ten minutes. Multiply by four utilities and three sites and it is a day a month for a saving that is usually zero. So it does not happen, and the two things that would have been caught — the tariff that rolled onto a variable rate and the equipment that started drawing double — both run for months.

The shape above makes that ten minutes cost nothing and applies it to every bill. It spends most of its effort on the boring half, which is matching a bill to the right meter and reading three numbers off a page that a different supplier lays out differently every time. The interesting half — the comparison — is three subtractions.

The next four posts walk through each piece: how a bill arrives and gets read, how it gets matched to a meter, how a change gets reported, and how the history builds into something worth looking at. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts