Utility invoice processing without purchase orders: a matching model that works

Most accounts payable controls assume a purchase order exists. An invoice arrives, the system finds the PO, compares quantity and price, checks the receipt, and pays if the three agree. Utility invoices break that assumption on every line. There is no PO, the quantity is whatever the meter recorded, the price is a tariff the provider set, and the invoice arrives every month whether or not anyone ordered anything.

So AP teams do one of two things. They raise blanket POs that approve any amount up to a cap, which is a control in name only, or they route every utility invoice to a facilities person who eyeballs it, which stops scaling past a few dozen accounts. Neither catches a wrong rate class or an estimated read carried forward for three months.

The fix is a different match, not a weaker one. This article defines a utility three-way match (invoice against meter reads, tariff and account master) plus two continuity checks, then covers tolerance design, exception categories, GL posting and what to measure. The surrounding workflow of coding, approvals, accruals and cycle time is covered in automating utility invoice AP.

Why the standard match fails on utility invoices

A PO-based match works because the buyer fixed the quantity and price before the goods arrived. On a utility invoice, both are unknown until the bill lands. Usage depends on weather, occupancy and equipment. Price depends on a tariff with tiers, time-of-use periods, demand charges, riders and taxes that change on the regulator's schedule, not yours. Format varies as well: almost 3,000 electric distribution utilities were operating in the United States in 2017, each designing its own invoice, and every Canadian province adds its own providers and layouts.

A blanket PO cannot catch any of this. It answers one question (is the total under the cap?) and the errors that cost money are all under the cap: a demand charge computed on the wrong interval, a rate class that should have changed when the tenant left, a prior balance billed twice. The control has to test the invoice against the things that actually determine it.

The utility three-way match, defined

Replace the PO, receipt and invoice legs with three references that exist for every utility account whether or not anyone raised a PO.

Each leg is independent. An invoice can pass identity and price and fail usage because the read was estimated. That independence is what makes the exception useful: the reason is already known when a person sees it, so the review is a decision rather than an investigation. Interval data strengthens the usage leg considerably. Green Button data is offered by utilities in nearly all 50 US states and two Canadian provinces, at 5-minute, hourly, daily or monthly intervals depending on the provider, so the billed demand can be tested against the meter's own record rather than against last month's guess.

Two continuity checks the PO world never needed

Utility invoices form a chain. Each one starts where the last ended, and each may carry the prior balance forward. Two checks cover that. Period continuity: the service period on this invoice should start the day after the previous one ended, on the same meter. A gap means a missing bill (and a missing accrual); an overlap means a duplicate or a rebill. Prior-balance handling: the previous balance shown on this invoice should equal the last invoice total less payments applied. If it does not, a payment was misapplied, a late fee was added, or a correction was issued that nobody recorded.

Neither check has a PO analogue, and both catch errors that a total-only review cannot. They are also the checks most often skipped, because they need the previous invoice and the payment history in structured form, which a scanned image in the AP system does not give you.

Tolerance design: what to auto-approve and what to route

Tolerances turn the match from a pass or fail gate into a routing rule. Set them per leg, and set them from your own history rather than a default.

• Identity: no tolerance. Any mismatch routes. An invoice for an unknown account is never auto-approved.
• Usage: compare to the same period last year and to the trailing average, weather-adjusted where you have degree days. Auto-approve inside a band derived from that account's own variance; route outside it, and always route an estimated read.
• Price: recompute the charges from the versioned tariff. Auto-approve when the recomputed total is within a small absolute and percentage threshold; route any rate class change, new rider, or period where the tariff version changed.
• Continuity: no tolerance on gaps or overlaps; a small absolute tolerance on prior balance to absorb rounding, nothing more.

The common mistake is one portfolio-wide percentage. A 10 percent band is meaningless on a seasonal gas account and far too loose on a flat-load data room. Derive the band per account from its own history, review it once a year, and keep the derivation visible so an auditor can see why an invoice was auto-approved.

Exception categories worth defining

Route exceptions by category, not only by leg, because the category decides who resolves it and how. Data exceptions (unreadable field, missing meter read, unknown account) go back to the data team or the provider. Billing exceptions (rate class, misapplied rider, arithmetic, duplicate) go to whoever handles disputes with the provider. Operational exceptions (usage outside the band with a valid read) go to facilities, because the invoice is probably right and the building is wrong. Continuity exceptions (gap, overlap, prior-balance mismatch) go to AP, because they are usually payment or accrual problems.

Keep the categories few and record a resolution code on each, because the resolution history is what lets you tighten the tolerances later. The individual validation rules behind each leg are set out in automated utility invoice validation, and the manual version of the same checks, for an annual review, is in how to audit commercial utility bills.

How the match feeds GL coding and ERP posting

A matched invoice carries more than a total. It carries the site, meter, commodity, service period and each charge component, all validated. That is exactly what coding needs. Delivery and commodity charges can post to different accounts, taxes to their own, and the service period drives the accrual split across months without anyone opening the PDF. Allocation across cost centers or tenants uses the validated usage rather than a percentage of the total, which is the basis for chargebacks that hold up. Posting the structured, matched record rather than a scanned image is the pattern described in integrating utility data with ERP and accounting systems.

The sequence matters. Match first, then code, then post. Teams that code first and match later end up reversing entries every time an exception is upheld, which is the month-end pain the model is supposed to remove.

What to measure

Three measures tell you whether the model is working, and general AP benchmarks give a sense of scale. Ardent Partners' 2024 State of ePayables research, as summarized by Bottomline, reports that best-in-class AP teams have an invoice exception rate of 9 percent compared to 22 percent for all others, that they process an invoice in 3.1 days compared to 17.4 days for all others, and that only 32.6 percent of B2B invoices move through straight-through processing. The 2025 edition, as summarized by Medius, puts organizations using advanced automation at 2.9 days per invoice against an industry average of 8.2 days.

Those are all-invoice figures; utility invoices will run higher on exceptions until the tolerances are tuned. Track exception rate by leg and category (a rising usage-leg rate is a building problem, a rising price-leg rate is a tariff-maintenance problem), touchless rate (invoices posted with no human touch), and cycle time from receipt to posting. Add one utility-specific measure: dollars recovered or avoided from price-leg exceptions, because that is the number that justifies the model to the CFO.

MartinAI performs this match as the data lands. It reads every field on every bill, ties it to your account and site master, recomputes the charges from the tariff, compares usage to reads and history, checks period continuity and prior balance, and hands your ERP a coded, validated record with the exceptions already classified. The AP team sees the exceptions, with evidence attached, and nothing else.