Tariform 
Generic OCR fails on utility bills because reading a bill and extracting one are different problems. OCR transcribes the text on the page. Extraction requires knowing what each number is — which line is a coincident demand charge, which "Energy Charge" is the pre-rate-change portion, how a label on one utility maps to the same charge on another — and proving the result ties out to the printed total. A general-purpose document AI does the reading well. It cannot do the tariff-aware part, and on a utility bill the tariff-aware part is most of the job.
This guide covers the five specific places generic OCR breaks on C&I utility bills, why each one fails silently, and what a domain-aware extraction pipeline does instead.
#OCR vs. extraction: what's the difference?
OCR (optical character recognition) converts an image of text into machine-readable text. Document AI extends this to structured key-value pairs and tables. Both work well on documents with stable schemas — invoices, tax forms, receipts — where the layout repeats and every field has a known place.
Extraction, in the utility-bill sense, is the layer above that: mapping each transcribed line to its role in the underlying tariff, handling billing patterns like estimated reads and mid-cycle rate changes, and reconciling the line items against the bill total.
| Generic OCR / document AI | Domain-aware bill extraction | |
|---|---|---|
| Output | Text and rough key-value pairs | Line items mapped to tariff components |
| Schema assumption | Stable, repeating layout | No fixed layout; one format per utility |
| Charge meaning | None — strings only | Each line mapped to a canonical component |
| Estimated reads | Treated as real reads | Recognized and flagged |
| Mid-cycle rate changes | Seen as a malformed/duplicate line | Split and pro-rated by effective date |
| Reconciliation | None | Line items tied out to printed total |
| Failure behavior | Silent — plausible wrong data | Flagged for review |
The short version: OCR is necessary but not sufficient. The gap between transcription and usable data is domain knowledge.
#Why utility bills are harder than invoices
Invoices have a schema. A utility bill does not. Three properties make C&I bills uniquely hostile to generic extraction:
- No standard format. Every utility prints its own layout, and the format changes within a single utility depending on meter type, plan, and billing-system version.
- High line-item count. A C&I bill on a time-of-use demand tariff can carry 30–50 line items — multiple TOU energy periods, coincident and non-coincident demand, ratchet adjustments, power-factor adjustments, transmission, distribution, public-benefit charges, franchise fees, and multiple taxes. (How to read a commercial utility bill breaks down what each of these is.)
- Billing artifacts. Estimated reads, true-ups, mid-cycle rate changes, and off-bill credits all distort the numbers in ways that look like errors but are normal utility behavior.
A residential bill has roughly four lines and is a fine target for generic tooling. A C&I bill is a different document class.
#The 5 reasons generic OCR fails on utility bills
Each of these fails silently — no error is thrown. The pipeline returns confident, plausible, incorrect data.
#1. One bill format per utility — and the formats change
There is no single utility-bill schema. PG&E's E-19, Con Edison's SC-9, and Duke's GS-T share charge concepts but nothing about layout, labels, or ordering. The format isn't even stable within one utility — the same tariff prints differently depending on smart-meter status, legacy plans, and billing-system migrations. A model trained on the bills it has seen fails on the format it hasn't, and fails without warning.
#2. Estimated reads
When the meter isn't read, the utility estimates usage, prints an "EST" flag, and bills the estimate. The next cycle trues up against the actual read, often with a negative adjustment. A pipeline that doesn't recognize the flag treats the estimate as real and the true-up as an anomaly — producing a baseline that drifts high in estimated months and over-corrects in true-up months.
#3. Mid-cycle rate changes
When a utility files a new tariff, the rate changes on a specific effective date. A bill spanning that date pro-rates the same charge across both rates, so one charge type prints as two lines. A generic extractor sees two "Energy Charge" lines, has no concept of tariff effective dates, and either treats the bill as malformed or blends the lines into a number that matches nothing.
#4. Line-item ambiguity across utilities
"ENERGY CHG-SUMMER-ON-PEAK" (PG&E) and "Summer On-Peak Energy" (SDG&E) are the same charge type. To a string match they are unrelated. Mapping them to one canonical tariff component is a domain problem, not a parsing problem — there is no syntactic rule connecting "PBC," "Public Purpose Programs," and "Public Benefit Charge." Without that mapping, you get a different schema per utility, which is no schema at all.
#5. Totals that don't tie out
Utility bills round at the line-item and subtotal levels, and sometimes apply off-bill credits that reduce the total without printing a line. An extractor that doesn't reconcile its line items against the printed total ships data that's off by a dollar or two and never flags it. On a C&I bill, 95% accuracy means roughly one wrong number per bill — with no way to know which one. Fine for ad copy; fatal for a pro-forma an investment committee reviews or a Scope 2 report an auditor signs.
#What domain-aware extraction does instead
The fix for all five failures is one architectural move: model the tariff the page is an instance of, then prove the result reconciles. A domain-aware pipeline:
- Models bill structure — header, line items, totals, source provenance — rather than assuming a fixed layout.
- Maps each line to a canonical tariff component, regardless of how the utility labels it.
- Recognizes billing patterns — estimated reads, mid-cycle splits, off-bill adjustments — as known cases, not anomalies.
- Reconciles line items against the printed total. Tie out to the penny → accepted. Discrepancy → flagged for review with the delta surfaced, not silently corrected.
Reconciliation can't be bolted on after a generic OCR pass — it has to be the thing the pipeline is organized around. The auditor's first question is "does this tie out?" and the architecture has to be able to answer it.
#Is an LLM enough to extract utility bills?
An LLM is a strong component of a real extraction pipeline — it reads the page and proposes structure well. It is not the whole pipeline. The trustworthy output comes from the system around it: the tariff model it maps into and the reconciliation that proves the result. A script that wraps a model and dumps JSON has the reading and none of the rest. It produces a draft. It does not produce data you can put in an audited deliverable.
This is why "we'll just use the AI" reliably fails in production but not in the demo. Ten clean bills come back clean and the problem looks solved. The 20% the model can't do — tariff mapping, estimated reads, rate-change splits, reconciliation — shows up later, on the messy bill, in front of the auditor, when the pipeline is already load-bearing.
#What Tariform does
Extract is the domain-aware pipeline described above. Utility-bill PDFs go in — digital or scanned — and line-itemized, tariff-aware, source-traceable structured data comes out. Every charge maps to its role in the source tariff. Every bill reconciles against its printed total, or it's flagged for review. Every value carries a pointer back to its source PDF line.
If you're building a pro-forma, scoping a consulting engagement, or shortening proposal turnaround, Extract is the product. Book a demo — twenty minutes, a real bill, you see the output. Prefer to try it yourself? Start a free trial — upload a real bill and see the extraction in minutes.
Operate C&I solar or storage and want to know how much each system actually saved on the bill? That's Verify — the other product on the platform, same extraction backbone.
