Automated utility invoice validation: what it checks, and how it works

Automated utility invoice validation is the practice of running every incoming utility bill through a fixed set of rules before anyone approves it for payment. Each rule tests one thing: the arithmetic adds up, the rate applied matches the tariff the account is on, the meter reads continue from last month, the billing period does not overlap the previous one, the invoice has not been seen before. A bill that passes every rule flows on to accounts payable. A bill that fails is held as an exception, with the specific failure attached.

It sits between two other disciplines it is often confused with. A manual bill audit is a periodic, person-led review that works through an account's history and setup. Anomaly detection is a statistical layer that flags a month that looks unlike the account's own pattern. Validation is the per-invoice rules layer: it runs on every bill, every time, in the same way, and it makes the other two cheaper because the obvious errors never reach them.

The case for doing it with rules rather than by eye comes down to volume and consistency. One industry estimate holds that 15 to 20 percent of commercial energy invoices contain inaccuracies, and with almost 3,000 electric distribution utilities operating in the United States, each designing its own bill, no reviewer can hold every format's quirks in their head. A rule does not get tired in the third week of month-end close.

Where validation sits in the invoice-to-pay flow

Validation only works on structured data. A rule cannot test a subtotal it cannot see, so the sequence matters: capture the bill (PDF, portal download, EDI feed or Green Button file), extract every field into typed data, run the rules, route the exceptions, and release the rest to AP with GL coding attached. If extraction captured only the total and the due date, most of the checks below have nothing to test.

The placement is deliberate: before payment, not after. Recovering an overpayment from a utility is slow and often partial; holding a bill for a day while a tariff mismatch is resolved costs almost nothing. That is why validation belongs inside the AP automation flow, not in a quarterly review.

The checks, one by one

Arithmetic and subtotal reconciliation

The first rule is the simplest: do the line items sum to the subtotals, do the subtotals plus taxes equal the total, and does previous balance minus payments plus current charges equal the amount due. It sounds trivial, but proration is where the arithmetic goes wrong most often, especially on partial periods and rate changes mid-cycle. In one regulatory review described by Tridens, a demand-charge proration mistake overcharged a single customer by more than $500 on one bill, alongside misapplied sales taxes across the customer base.

Tariff and rate-class recomputation

The strongest check recomputes each charge from the usage and the published tariff for the account's rate class: energy blocks, delivery charges, time-of-use periods, riders. The bill's figure and the recomputed figure should agree within rounding. This catches an account left on the wrong rate class, a tariff table that did not update after a rate change, and a rider applied to a class it does not cover.

Meter-read continuity and multipliers

This bill's start read should equal last bill's end read, consumption should equal end read minus start read times the meter multiplier, and the multiplier should match the one on file for that meter. A break in the chain means a meter change, a rollover, or a read that was keyed wrong. A multiplier that changed without a meter change is almost always an error, and because it scales the whole usage figure, it is an expensive one to miss.

Billing-period continuity, gaps and overlaps

The start date of this period should follow the end date of the last one, and the period length should sit inside the expected range for the account's cycle. An overlap means the same days were billed twice. A gap means a bill is missing or a catch-up bill is coming. Period rules also stop a 45-day bill and a 20-day bill from being treated as two equal months downstream.

Duplicate invoices

Same account, same period, same amount; same invoice number; or a re-issued bill after a correction that still carries the original. Email-based intake makes it easy for both copies to reach AP. The duplicate rule is a hard stop: nothing matching an already-paid invoice on account, period and amount is released.

Estimated reads

Tridens lists estimated and missing meter reads as the first source of systematic billing errors: an estimate is issued, the correction cycle breaks, and the estimate becomes the billing record until a catch-up bill arrives. The rule flags any read coded as estimated, counts consecutive estimates on the account, and holds usage-based analysis until an actual read lands. An estimate is not wrong in itself; an estimate that nobody knows is an estimate is.

Demand and ratchet checks

For commercial and industrial accounts the demand line deserves its own rules, because demand charges can represent 30 to 60 percent of the total bill. Billed demand should equal the highest metered interval, which for most utilities is a 15-minute average, unless a ratchet is in force. A typical ratchet sets the floor at 70 to 80 percent of the highest measured demand in the prior 11 months; Envigilance reports 80 percent as the most common ratchet percentage, with an 11 or 12 month look-back. The rule recomputes expected billing demand as the greater of the metered peak and the ratchet floor from the account's own history, then compares it to what was billed, and checks the metered peak against the interval file where one exists.

Taxes, riders and regulatory charges

Tax rates should match the site's jurisdiction and the account's exemption status; riders and regulatory charges should be current and applicable to the rate class. Exemptions tend to fall off silently when an account is renumbered or a site changes hands, in amounts small enough to pass unnoticed for years.

Account-history thresholds

The last group compares usage, cost and unit cost to the same month last year and to a trailing average, weather-adjusted where degree-day data is available. This is the boundary with anomaly detection: a fixed threshold is a validation rule, a fitted model is anomaly detection. The threshold rule runs cheaply on every bill and catches the gross cases, such as a unit cost that doubled.

How exceptions are routed

A validation layer is only as good as what happens to the failures. The working pattern is two severity tiers and an owner for each check. Hard failures (arithmetic, duplicate, missing meter link) block payment until resolved. Soft failures (a history threshold, a first estimated read) flag the bill for review but can be released on a deadline so no late-payment penalty accrues while a possibly legitimate charge is investigated. Each exception record should carry:

• The rule that fired, in plain language, not a code
• The expected value and the observed value, side by side
• The source bill page, so the reviewer sees the figure in context
• The account's recent history for the same field
• An owner: AP for duplicates and arithmetic, the energy manager for tariff and demand, facilities for usage outliers
• A disposition: corrected, disputed, accepted with a note, or rule tuned

The disposition field matters more than it looks. Every accepted-with-a-note exception is evidence that a threshold is too tight; every dispute that recovers money is evidence a rule earned its keep. Reviewing dispositions monthly is how the rule set improves, and it is the record that shows what the bill errors and overcharges program actually recovered.

What it takes to set up

Four things have to exist before the rules can do real work: master data tying every account to a site, meter, multiplier and rate class; tariff tables for each rate class, kept current; a history baseline, ideally twelve months of validated bills per account, for the continuity and threshold rules to chain to; and the feedback loop above, so thresholds are tuned from dispositions rather than guessed.

How MartinAI fits

MartinAI reads every field on every bill and meter file, for any commodity and layout, and runs the checks above as part of extraction. AP receives a validated record with GL coding attached, exceptions carry the failing rule and the source page, and the same structured data feeds energy reporting and benchmarking without a second round of data entry.

Validation is not glamorous. It is a list of rules, run the same way on every invoice, with a clear owner for each failure. That is why it works: wrong bills stop before payment, right bills get paid on time, and the people who used to eyeball both get their month back.