Utility bill and meter data extraction
Tavnit reads electricity, gas, water and waste bills and returns consumption, tariff, meter readings and charges per site. A portfolio's bills become a table you can trend — which is what both cost control and emissions reporting actually require.
Why this is painful
Anyone managing more than a handful of sites receives bills from several suppliers in several formats, and the only thing that reliably happens to them is payment. The consumption data — the part with analytical value — stays in the PDF.
Emissions reporting has made this urgent. Scope 1 and 2 reporting needs consumption in kWh by site and period, and for most organisations that data exists only as a stack of bills nobody has transcribed.
What to extract
| Field | Why it needs care |
|---|---|
| Supply address and meter number (MPAN/MPRN) | The identifier that ties a bill to a site. Addresses alone are unreliable across suppliers. |
| Billing period | Bills rarely align to calendar months, which matters when you aggregate by quarter. |
| Consumption with unit | kWh, m³ or litres. The unit is as important as the number and is not always stated the same way. |
| Meter readings and estimate flag | An estimated read is not a measurement, and treating it as one corrupts a trend. |
| Tariff and standing charge | What separates a price change from a consumption change. |
| Total charges and tax | For cost reconciliation against what was actually paid. |
What makes utility bills hard
Estimated readings are not data
Suppliers estimate when they cannot read a meter, then correct on the next actual read. A trend built without distinguishing the two shows a spike that never happened followed by a drop that never happened. Extract the estimate flag as its own field so estimates can be excluded or treated separately.
Billing periods do not align to anything
One supplier bills monthly, another every 28 days, a third quarterly, and none of them align to your reporting periods. Extract period start and end rather than a single date, so consumption can be apportioned across the periods you actually report on.
Units differ, and gas is the trap
Gas is frequently billed in cubic metres and reported in kWh, and the conversion depends on a calorific value printed on the bill. Extract the unit and the conversion factor rather than assuming, then let a unit Cleaner do the conversion — assuming a standard factor is where most emissions numbers quietly go wrong.
How the pipeline handles it
- Collections — Bills from different utilities and suppliers arrive together and get routed to the right flow automatically.
- Cleaners — Converts units to a single reporting basis and computes period-apportioned consumption.
- Buckets — Consumption by site and period as a chartable table — the format both finance and ESG reporting need.
- Email Integration — Suppliers email bills; forwarding them in builds the dataset without a data-entry project.
Common questions
- Can it handle bills from different utilities and suppliers?
- Yes. A Collection classifies each bill and routes it to the right flow, so electricity, gas and water bills are each read by the flow built for them, whatever the supplier's layout.
- Is the data usable for emissions reporting?
- It produces consumption by site and period with units captured, which is the input such reporting needs. Extract the estimate flag and the conversion factor rather than assuming a standard one — that assumption is where most emissions figures go wrong.
- Can it separate a price rise from a consumption rise?
- Extract tariff and standing charge alongside consumption, and the two become separate columns you can trend independently.
Other document types
Try it on one document
Build a flow, send a real utility bill through it, and see what comes back. Free credits to start.
Start free