# What Data Does Your ERP Hold on Utilities and Energy? > Your ERP holds utility GL codes and paid amounts, but rarely the meter reads, tariff schedule or demand charge basis needed to audit the bill. Source: https://valuexpa.com/insights/what-data-does-your-erp-hold-on-utilities-and-energy Publisher: ValueXPA (https://valuexpa.com) Updated: 2026-10-22 --- Margin drift is the gap between what a vendor contract says and what the invoice actually charges. For utilities and energy spend, that gap is easy to miss because the ERP was built to pay the bill, not to test it. Most finance teams assume the ERP already holds what an audit needs: usage, rate, and contract terms. It does not. It holds a paid amount, a GL code, and a vendor name. Everything that would let you check whether that amount was correct lives somewhere else, or nowhere at all. ## Executive Summary The ERP records that a utility invoice was received, approved, and paid. It was never designed to record whether the invoice was priced correctly against the tariff schedule the utility itself filed. That distinction is the whole problem: the system of record for payment is not the system of record for the contract terms that determine whether the payment was right. What the ERP typically captures is the amount, the account code, the vendor, and a due date. What it typically does not capture is the meter number tied to that invoice, the rate class the utility applied, the demand charge calculation, or the tariff version in effect on the billing date. Those live in a PDF bill, a utility web portal, or nowhere retained at all. The fix is not a bigger ERP field set. It is treating the invoice PDF and the tariff sheet as source documents that get pulled and checked separately, on a cycle, because the ERP will not surface a rate class error on its own. ## 1. What fields does an ERP actually store for a utility invoice? **An ERP typically stores the vendor name, invoice number, invoice date, due date, total amount, and the general ledger account or cost center the charge posted to. On a good implementation it may also hold a purchase order reference and an approval trail showing who authorized payment. None of that tells you whether the amount was calculated correctly. The ERP records that a bill was paid, not what the utility's tariff said the bill should have been.** This is by design. The ERP is an accounting system, and accounting requires knowing what was spent and where it hit the books. It does not require knowing the rate schedule a regulated utility filed, because the ERP's job ends at payment, not at pricing verification. The result is a system that can tell you instantly how much you spent on electricity last quarter, broken out by facility, but cannot tell you whether any single invoice in that total was billed at the correct rate class or demand tier. Those two questions look similar from a reporting screen. They are answered by completely different documents. ## 2. Where does the meter data live, and is it tied to the invoice? **Meter data, the actual kilowatt-hours or therms consumed at a specific meter number, lives on the utility's bill and in the utility's own portal. It is rarely re-entered into the ERP as a discrete field, and when it is, it usually arrives as a single lump usage number attached to the payment line rather than a meter-by-meter, interval-level record. That means the ERP cannot answer whether usage matches the previous cycle or a sister facility without someone pulling the source.** A single facility can carry several meters: one for the main building, one for a chiller plant, one for a warehouse addition. Each meter has its own account number, rate class, and billing history with the utility. The ERP typically collapses all of that into one payable line per statement period. That collapse is where drift hides. A rate class error on one meter of three does not show up as an anomaly in the ERP total. It shows up only when someone reconciles the bill's meter-level detail against what the utility's tariff structure says that meter should be billed under. ## 3. How does the ERP code utility spend to the general ledger? **The ERP codes a utility invoice to a GL account, usually a utilities or occupancy cost line, and to whatever cost center or facility the invoice was routed to during approval. That coding answers a financial reporting question, how much did utilities cost this facility this period, but it carries none of the operational detail behind the number: no demand charge component, no power factor penalty, no fuel adjustment clause, no tariff rider.** Two invoices with identical GL coding and identical dollar totals can be built from entirely different components. One might be straight consumption at a flat rate. The other might include a demand charge, a power factor penalty, and a fuel cost adjustment stacked together. The ERP treats them the same because the GL account is the same. That is a reasonable design for financial statements. It is not a design that supports checking whether the fuel adjustment clause was applied at the rate the tariff specifies, because the GL entry does not carry the clause with it. ## 4. What rate and tariff information is missing from the ERP? **The ERP almost never holds the utility's filed tariff schedule, the rate class assigned to a given meter, the demand ratchet clause, the power factor threshold, or the effective dates for any of those terms. Tariffs are filed with a state utility commission and change on a schedule the utility controls, not one the ERP tracks. Without that document sitting next to the invoice, there is no way to confirm the bill used the rate in effect on the billing.** Riders and adjustment clauses add a further layer. Fuel cost adjustments and surcharge riders change periodically and are easy to leave stale against an older filing once nobody is re-checking the source tariff against the invoice, and the ERP has nowhere to record that the check even happened. ### A. Rate class and effective dates Utilities reclassify accounts as load or facility use changes, and a rate class correction that should have lowered a bill can go unapplied for several billing cycles because nothing in the standard payment workflow flags a class mismatch against the tariff. ### B. Demand and power factor clauses Demand charges and power factor penalties are calculated fields defined in the tariff document, not flat line items. Verifying them requires the interval data and the tariff formula side by side, neither of which the ERP retains. ## 5. Can the ERP tell you if a demand charge or surcharge is correct? **No. The ERP has no field for the demand ratchet clause, the billing demand calculation window, or the surcharge basis, so it has nothing to compare the invoiced charge against. It can flag that a line item exists and that the total changed from the prior period, but it cannot evaluate whether the charge was computed the way the tariff requires. That check has to happen against the tariff document and the interval usage data, outside the ERP entirely.** An [accessorial-style surcharge](/insights/accessorial-charge-audit-the-surcharges-nobody-validates) on a utility bill, a rider, an adjustment clause, a ratchet-driven demand charge, behaves the same way surcharges do across other spend categories: it is easy to apply, easy to leave in place, and hard to catch from a payment ledger alone. The ERP's variance reporting will catch a large dollar swing. It will not catch a surcharge that has been quietly present and correctly small every month, which is the more common failure mode. That takes someone pulling the tariff and testing the calculation directly. ## 6. What should you export from the ERP before an audit? **Export the full payables history for every utility vendor: invoice date, amount, GL code, cost center, and vendor account number, for at least twelve to eighteen months. That export tells an auditor where and how much was paid. It does not replace the source bills, so the export has to be paired with the actual utility PDFs or portal data for the same period before any rate or demand charge verification can start.** A clean export saves the first week of an audit. It lets an auditor group spend by meter account, by facility, and by vendor without re-keying anything, and it surfaces which accounts have gaps or duplicate entries worth checking first. What it will not do is substitute for the underlying bills. The rate class, the tariff version, and the demand calculation only exist in the utility's own documentation, so the export is the starting index, not the evidence. What the ERP export gives you versus what still has to come from the utility bill itself. | Data point | In the ERP export | In the utility bill | Amount paid | Yes | Yes | GL code and cost center | Yes | No | Meter number and rate class | Rarely | Yes | Tariff version and effective date | No | Yes | Demand and power factor detail | No | Yes For the wider pattern this sits inside, start with the [margin drift](/insights/indirect-spend-audit-categories) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [duplicate freight billing and the multi-carrier consolidation problem](/insights/duplicate-freight-billing-and-the-multi-carrier). ## 7. Frequently Asked Questions (People Also Ask) ### Does the ERP store the utility rate schedule anywhere? No. Rate schedules are filed by the utility with a state commission and published on the utility's own site or portal. The ERP has no field for them and no process that pulls them in automatically, so they have to be retrieved separately for each account being checked. ### Why does my ERP total not match the sum of my utility bills? It usually does match at the total level, since the ERP records the amount paid. Mismatches tend to appear when an invoice was split across cost centers, partially disputed, or paid on an estimated amount later trued up, none of which the payables ledger always shows clearly on a single line. ### Can I audit utility invoices using ERP reports alone? You can identify which vendors and facilities to prioritize, but you cannot verify pricing. That requires the underlying utility bill and the tariff in effect on the billing date, neither of which the ERP retains as structured data. ### What is a demand charge and where would I find it? A demand charge bills for the highest rate of electricity draw during a billing period, not total consumption. It appears as a line item on the utility bill itself, calculated from interval meter data the utility holds; the ERP only sees the resulting dollar figure. ### Do all facilities on one ERP account share the same rate class? Not necessarily. Rate class is assigned per meter based on load type and usage pattern, so two meters at the same facility, or the same meter over time as usage changes, can sit under different classes even though both post to the same ERP cost center. ### Should I ask the utility for meter-level interval data directly? Yes. Most utilities provide interval usage data through an online portal or on request, and it is the only source for verifying demand charges and power factor penalties, since that level of detail does not exist in the ERP or in the flat invoice PDF. ### Is a tariff rider the same thing as a surcharge? They function similarly. A rider is a tariff-approved adjustment, often for fuel cost or infrastructure recovery, added to the base rate. It is filed and regulated like the rest of the tariff, but it changes on its own schedule and is easy to leave unchecked once applied. ### How far back should I pull utility bills for an audit? Pull twelve to eighteen months where available, since rate class changes and tariff rider updates can go unnoticed for several billing cycles before they show up as a meaningful pattern rather than a one-off variance. ### Does the ERP flag a sudden jump in a utility bill? Most ERPs support basic variance thresholds on payables, which can catch a large dollar swing. They will not catch a charge that was applied incorrectly from the start and has stayed consistently present at a small, steady amount every cycle since. ### Where does industrial electricity pricing data come from if I want external context? The US Bureau of Labor Statistics publishes a Producer Price Index series for industrial electric power (WPU0543); the August 2026 reading was 346.309, up 1.1% year over year, as read on 2026-09-25. It tracks input cost movement broadly, not any single contract's rate. ### Is contract complexity quietly draining your operating margin? A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit. **[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)** ## Executive Summary The ERP records that a utility invoice was received, approved, and paid. It was never designed to record whether the invoice was priced correctly against the tariff schedule the utility itself filed. That distinction is the whole problem: the system of record for payment is not the system of record for the contract terms that determine whether the payment was right. What the ERP typically captures is the amount, the account code, the vendor, and a due date. What it typically does not capture is the meter number tied to that invoice, the rate class the utility applied, the demand charge calculation, or the tariff version in effect on the billing date. Those live in a PDF bill, a utility web portal, or nowhere retained at all. The fix is not a bigger ERP field set. It is treating the invoice PDF and the tariff sheet as source documents that get pulled and checked separately, on a cycle, because the ERP will not surface a rate class error on its own. ## 1. What fields does an ERP actually store for a utility invoice? An ERP typically stores the vendor name, invoice number, invoice date, due date, total amount, and the general ledger account or cost center the charge posted to. On a good implementation it may also hold a purchase order reference and an approval trail showing who authorized payment. None of that tells you whether the amount was calculated correctly. The ERP records that a bill was paid, not what the utility's tariff said the bill should have been. This is by design. The ERP is an accounting system, and accounting requires knowing what was spent and where it hit the books. It does not require knowing the rate schedule a regulated utility filed, because the ERP's job ends at payment, not at pricing verification. The result is a system that can tell you instantly how much you spent on electricity last quarter, broken out by facility, but cannot tell you whether any single invoice in that total was billed at the correct rate class or demand tier. Those two questions look similar from a reporting screen. They are answered by completely different documents. ## 2. Where does the meter data live, and is it tied to the invoice? Meter data, the actual kilowatt-hours or therms consumed at a specific meter number, lives on the utility's bill and in the utility's own portal. It is rarely re-entered into the ERP as a discrete field, and when it is, it usually arrives as a single lump usage number attached to the payment line rather than a meter-by-meter, interval-level record. That means the ERP cannot answer whether usage matches the previous cycle or a sister facility without someone pulling the source. A single facility can carry several meters: one for the main building, one for a chiller plant, one for a warehouse addition. Each meter has its own account number, rate class, and billing history with the utility. The ERP typically collapses all of that into one payable line per statement period. That collapse is where drift hides. A rate class error on one meter of three does not show up as an anomaly in the ERP total. It shows up only when someone reconciles the bill's meter-level detail against what the utility's tariff structure says that meter should be billed under. ## 3. How does the ERP code utility spend to the general ledger? The ERP codes a utility invoice to a GL account, usually a utilities or occupancy cost line, and to whatever cost center or facility the invoice was routed to during approval. That coding answers a financial reporting question, how much did utilities cost this facility this period, but it carries none of the operational detail behind the number: no demand charge component, no power factor penalty, no fuel adjustment clause, no tariff rider. Two invoices with identical GL coding and identical dollar totals can be built from entirely different components. One might be straight consumption at a flat rate. The other might include a demand charge, a power factor penalty, and a fuel cost adjustment stacked together. The ERP treats them the same because the GL account is the same. That is a reasonable design for financial statements. It is not a design that supports checking whether the fuel adjustment clause was applied at the rate the tariff specifies, because the GL entry does not carry the clause with it. ## 4. What rate and tariff information is missing from the ERP? The ERP almost never holds the utility's filed tariff schedule, the rate class assigned to a given meter, the demand ratchet clause, the power factor threshold, or the effective dates for any of those terms. Tariffs are filed with a state utility commission and change on a schedule the utility controls, not one the ERP tracks. Without that document sitting next to the invoice, there is no way to confirm the bill used the rate in effect on the billing. Riders and adjustment clauses add a further layer. Fuel cost adjustments and surcharge riders change periodically and are easy to leave stale against an older filing once nobody is re-checking the source tariff against the invoice, and the ERP has nowhere to record that the check even happened. ### A. Rate class and effective dates Utilities reclassify accounts as load or facility use changes, and a rate class correction that should have lowered a bill can go unapplied for several billing cycles because nothing in the standard payment workflow flags a class mismatch against the tariff. ### B. Demand and power factor clauses Demand charges and power factor penalties are calculated fields defined in the tariff document, not flat line items. Verifying them requires the interval data and the tariff formula side by side, neither of which the ERP retains. ## 5. Can the ERP tell you if a demand charge or surcharge is correct? No. The ERP has no field for the demand ratchet clause, the billing demand calculation window, or the surcharge basis, so it has nothing to compare the invoiced charge against. It can flag that a line item exists and that the total changed from the prior period, but it cannot evaluate whether the charge was computed the way the tariff requires. That check has to happen against the tariff document and the interval usage data, outside the ERP entirely. An [accessorial-style surcharge](/insights/accessorial-charge-audit-the-surcharges-nobody-validates) on a utility bill, a rider, an adjustment clause, a ratchet-driven demand charge, behaves the same way surcharges do across other spend categories: it is easy to apply, easy to leave in place, and hard to catch from a payment ledger alone. The ERP's variance reporting will catch a large dollar swing. It will not catch a surcharge that has been quietly present and correctly small every month, which is the more common failure mode. That takes someone pulling the tariff and testing the calculation directly. ## 6. What should you export from the ERP before an audit? Export the full payables history for every utility vendor: invoice date, amount, GL code, cost center, and vendor account number, for at least twelve to eighteen months. That export tells an auditor where and how much was paid. It does not replace the source bills, so the export has to be paired with the actual utility PDFs or portal data for the same period before any rate or demand charge verification can start. A clean export saves the first week of an audit. It lets an auditor group spend by meter account, by facility, and by vendor without re-keying anything, and it surfaces which accounts have gaps or duplicate entries worth checking first. What it will not do is substitute for the underlying bills. The rate class, the tariff version, and the demand calculation only exist in the utility's own documentation, so the export is the starting index, not the evidence. What the ERP export gives you versus what still has to come from the utility bill itself. | Data point | In the ERP export | In the utility bill | | --- | --- | --- | | Amount paid | Yes | Yes | | GL code and cost center | Yes | No | | Meter number and rate class | Rarely | Yes | | Tariff version and effective date | No | Yes | | Demand and power factor detail | No | Yes | For the wider pattern this sits inside, start with the [margin drift](/insights/indirect-spend-audit-categories) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [duplicate freight billing and the multi-carrier consolidation problem](/insights/duplicate-freight-billing-and-the-multi-carrier). ## Common questions ### Does the ERP store the utility rate schedule anywhere? No. Rate schedules are filed by the utility with a state commission and published on the utility's own site or portal. The ERP has no field for them and no process that pulls them in automatically, so they have to be retrieved separately for each account being checked. ### Why does my ERP total not match the sum of my utility bills? It usually does match at the total level, since the ERP records the amount paid. Mismatches tend to appear when an invoice was split across cost centers, partially disputed, or paid on an estimated amount later trued up, none of which the payables ledger always shows clearly on a single line. ### Can I audit utility invoices using ERP reports alone? You can identify which vendors and facilities to prioritize, but you cannot verify pricing. That requires the underlying utility bill and the tariff in effect on the billing date, neither of which the ERP retains as structured data. ### What is a demand charge and where would I find it? A demand charge bills for the highest rate of electricity draw during a billing period, not total consumption. It appears as a line item on the utility bill itself, calculated from interval meter data the utility holds; the ERP only sees the resulting dollar figure. ### Do all facilities on one ERP account share the same rate class? Not necessarily. Rate class is assigned per meter based on load type and usage pattern, so two meters at the same facility, or the same meter over time as usage changes, can sit under different classes even though both post to the same ERP cost center. --- ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us