A utility ERP selection holds up when it scores four areas with 8 to 12 requirements each and weights them by utility type before the first demo. The four areas are enterprise asset management and work management, meter-to-cash and the customer information system, regulatory reporting, and field service with a mobile workforce. ERP Research puts a mid-size distribution utility implementation at 12 to 18 months and a large investor-owned utility at 18 to 36 months. A selection that misses a requirement therefore costs a year, not a sprint.
The single biggest decision is whether billing is inside the ERP scope at all. Settle that first, because it changes which vendors can bid and how many programs you are really running.
The four areas carry different risk, so they get different numbers of requirements
The scoring model below has 40 requirements split across four areas. Asset and work management and meter-to-cash get the most, because they touch the most people and the most legacy data. Regulatory reporting gets fewer requirements, but each one is pass or fail for an investor-owned utility. Field service gets the fewest, because the market has largely converged on what a mobile work order does, and the differences show up in scheduling and offline behavior.
Three requirements decide more selections than the other 37 combined, in this site's judgment, and the right default is to treat them as gates. The first is the capital versus O&M split posted from the work order to plant-in-service. It is where asset management meets rate base, and a weak product there forces manual month-end journal entries for the life of the system.
The second is the rate engine run against the utility's own tariffs. A tariff the engine cannot express becomes custom code in the one place where an error reaches every customer. The third is a chart of accounts native to FERC, RUS, or GASB. Reclassifying accounts after go-live is costly, and every Form 1 schedule is built from that chart.
Vendors tend to show the capital-split and chart-of-accounts requirements on clean sample data and the rate engine on a flat residential rate. That is why the demo script later in this article loads the utility's own data instead.
Area 1: asset management and work management, 12 requirements
This area is where IFS Cloud, Oracle Utilities Work and Asset Cloud Service, and SAP S/4HANA asset management compete most directly. Oracle's product page says it ships with more than 225 predefined visualizations and prebuilt integrations to ERP and GIS (Oracle). IFS positions asset lifecycle, scheduling, and field service as one native platform (IFS blog). The requirements below are written so that each can be shown in a demo with your data.
| # | Requirement | Why it matters for a utility | Demo evidence |
|---|---|---|---|
| A1 | Linear and point asset hierarchy (mains, feeders, poles, meters, pumps) with GIS feature ID on each record | Utility networks are linear; manufacturing-style asset trees break on a 40-mile main | Load 500 of your assets from GIS, show a pole-to-transformer-to-meter path |
| A2 | Compatible units (CU) for construction estimating | Distribution work is estimated in CUs, not hours and parts | Build a service drop from your CU library |
| A3 | Capital versus O&M split on a work order, posting to plant-in-service on close | Rate base depends on it; FERC and state commissions audit it | Close one capital and one O&M order, show the GL and continuing property record |
| A4 | Preventive maintenance by meter, time, and condition triggers | Substation and pump station schedules | Create a transformer PM on oil test results |
| A5 | Asset condition and risk scoring with repair-versus-replace output | Feeds the capital plan and asset management plans | Rank 50 assets by risk, show the replacement list |
| A6 | Capital program and project hierarchy with budget, commitment, actual | Multi-year capital improvement programs | Show a program with 10 projects and roll-up |
| A7 | Materials reservation and issue from storeroom to work order, with returns | Crew trucks and storm stock | Reserve, issue, return, and check inventory |
| A8 | Contractor work orders and unit-price invoicing | Much distribution work is outsourced | Create a contractor order, receive, match invoice |
| A9 | Outage and emergency work orders created from OMS or SCADA events | Storm response | Receive an OMS event via API, create work |
| A10 | Vegetation, inspection, and compliance work programs | Regulatory inspection cycles | Set a 5-year inspection cycle, show overdue list |
| A11 | Asset retirement and salvage with unitization | Plant accounting and depreciation | Retire an asset, post salvage and removal cost |
| A12 | Integration to GIS with bidirectional edits | GIS is the asset register of record at most utilities | Edit in GIS, see it in ERP within one cycle |
Area 2: meter-to-cash and the customer information system, 12 requirements
Meter-to-cash is the area where ERP vendors differ most in what is native. SAP's training material lays out its process as ten steps from creating a meter reading order through posting payment, inside S/4HANA Utilities (SAP Learning). Ferranti, a Dynamics 365 partner, states plainly that Dynamics 365 is "not suitable for utility billing out of the box" (Ferranti). It says the platform lacks meter data management, a consumption rate engine, and a data model for supply points.
That is honest and useful. It tells you that for Dynamics 365 and IFS Cloud, this area scores a partner or a separate product, and the partner belongs in the demo room. Infor's billing module sits inside CloudSuite Public Sector, so confirm in the demo that it is the same suite and not a separately licensed product.
| # | Requirement | Why it matters for a utility | Demo evidence |
|---|---|---|---|
| M1 | Premise, service point, device, and contract data model | Billing follows the meter, not the customer | Move out one customer, move in another, bill both correctly |
| M2 | Rate engine for block, seasonal, demand, time-of-use, and net metering tariffs | Tariff complexity is the whole job | Bill your three most complex rate schedules against last year's actual reads |
| M3 | Meter data management or interface to AMI head-end, with validation, estimation, and editing | Interval data volumes | Load one month of interval data for 1,000 meters, show estimation |
| M4 | Multi-service billing on one bill (electric, water, sewer, gas, stormwater, broadband) | Municipal and cooperative combined utilities | Produce one bill with four services and two taxing districts |
| M5 | Exception handling for implausible reads and outsorted bills | Where billing staff spend their day | Show the outsort queue and release workflow |
| M6 | Payment channels, payment plans, deposits, and budget billing | Collections and customer service | Set up a 12-month budget bill and a payment arrangement |
| M7 | Credit and collections with disconnect rules that honor state commission notice periods and medical holds | Regulatory penalties for wrongful disconnect | Run a collections cycle with a protected customer |
| M8 | Customer self-service portal and mobile app | Call volume reduction | Customer views usage, pays, starts service |
| M9 | Field order generation from CIS (connect, disconnect, re-read) | Links billing to field service | Create a disconnect, dispatch it, complete it, bill the fee |
| M10 | Unbilled revenue and revenue by rate class to the general ledger | Month-end close and rate case support | Show unbilled accrual and GL posting by FERC account |
| M11 | Regulatory and program billing: riders, surcharges, assistance programs, DER credits | Programs change every rate case | Add a rider mid-cycle and prorate |
| M12 | Market messaging for deregulated markets (where applicable) | Retail choice states | Process a supplier switch |
Area 3: regulatory reporting, 8 requirements
The hard requirement here is the FERC Uniform System of Accounts. ERP Research's utilities page warns that rate case data needs should shape chart-of-accounts design because reclassifying accounts after go-live is costly, and it rates IFS Cloud weak on FERC accounting while placing SAP strongest on regulatory accounting. Municipal utilities under GASB and cooperatives under RUS accounting have lighter versions of the same need, so the weight falls but the requirements stay.
| # | Requirement | Why it matters for a utility | Demo evidence |
|---|---|---|---|
| R1 | Chart of accounts native to FERC USoA (or RUS and GASB equivalents) with sub-ledgers mapping to it | Form 1 schedules are built from these accounts | Post 20 transactions, produce a trial balance in FERC account order |
| R2 | Plant accounting: continuing property records, unitization, group depreciation, CWIP and AFUDC | Rate base calculation | Run month-end depreciation on one plant account, show AFUDC |
| R3 | Allocation engine for shared services across jurisdictions, affiliates, and services | Multi-state and combined utilities | Allocate one month of IT cost by an approved factor |
| R4 | Cost-of-service and rate case data extraction by account, function, and customer class | Rate case filing | Produce a test-year expense schedule |
| R5 | Audit trail, role-based access, and segregation of duties that satisfy NERC CIP and SOX | CIP audits and external audit | Show a change log for a vendor master edit |
| R6 | Regulatory assets and liabilities tracking with amortization schedules | Deferred accounting orders | Create a regulatory asset and amortize |
| R7 | Report pack for FERC Form 1, Form 3-Q, state commission annual reports, EIA forms | Filing deadlines | Generate a Form 1 schedule from live data |
| R8 | Fund accounting and encumbrances (municipal) or patronage capital accounting (cooperative) | Public and member ownership | Encumber a purchase order; allocate patronage capital |
Area 4: field service and mobile workforce, 8 requirements
In this site's judgment, field service has moved from a differentiator to a baseline over the last decade, but the scheduling engine and offline behavior still separate products. IFS lists workforce planning and scheduling as its most detailed utility claim, including grouping jobs with planned maintenance. Oracle sells Oracle Field Service as a separate product. For SAP and Microsoft, mobile work comes from their own separate field service products.
| # | Requirement | Why it matters for a utility | Demo evidence |
|---|---|---|---|
| F1 | Crew-based scheduling (not single technician) with skills, equipment, and territory | Line crews work in twos and threes with a bucket truck | Schedule a 3-person crew with a digger derrick |
| F2 | Offline mobile with full work order, asset history, and map | Rural service territories | Pull the network cable, complete an order, sync |
| F3 | Storm mode: bulk reassignment, mutual aid crews, damage assessment | Major event restoration | Reassign 200 orders to 20 foreign crews |
| F4 | Time capture by work order and crew member feeding payroll and capital labor | Capital labor is rate base | Enter crew time, show it on the work order and in payroll |
| F5 | Safety: job briefing, lockout tagout, permits attached to the order | OSHA and internal safety | Block completion until briefing is signed |
| F6 | Meter and device exchange from the mobile device updating CIS and EAM | Links billing, assets, and field | Swap a meter in the field, bill the next cycle correctly |
| F7 | Customer appointment windows and notifications | Service orders and new connects | Book a 2-hour window, send a text |
| F8 | GIS map on the device with asset selection and redlining | Field edits to the network | Redline a pole move, route it to GIS |
Weights move with the regulator and the commodity
The same 40 requirements get different weights at an investor-owned electric utility, a municipal water system, and a rural electric cooperative. The table below is the default this site recommends, not a survey finding. The logic is simple. Investor-owned utilities live and die by rate base and FERC filings, so regulatory reporting carries 30%. Municipals and cooperatives rarely file Form 1, but they bill many services and answer directly to members or a council, so meter-to-cash rises. Water utilities carry the heaviest linear asset burden per customer, so asset management rises and regulatory reporting falls.
| Utility type | Asset and work mgmt | Meter-to-cash and CIS | Regulatory reporting | Field service and mobile |
|---|---|---|---|---|
| Investor-owned electric | 30% | 20% | 30% | 20% |
| Investor-owned gas | 35% | 15% | 30% | 20% |
| Municipal electric | 30% | 30% | 15% | 25% |
| Municipal water and wastewater | 35% | 30% | 10% | 25% |
| Combined municipal (electric, water, gas) | 25% | 35% | 15% | 25% |
| Electric cooperative (distribution) | 25% | 35% | 15% | 25% |
| Generation and transmission cooperative | 40% | 5% | 35% | 20% |
Two adjustments apply. If billing is out of scope, redistribute the meter-to-cash weight to the other three areas in proportion and score only the integration requirements M9 and M10. If the utility is a NERC-registered entity with bulk electric system assets, treat R5 as a gate rather than a weighted score.
Native versus partner-delivered, by area
Naming vendors here is only to show where a capability comes from, which changes how you contract and who shows up in the demo. Each of these vendors is the right answer somewhere.
SAP fits a large utility that wants billing and ERP from one vendor and can afford the program. Oracle fits a utility already on Oracle Utilities products, or one that wants Fusion finance with separate utility applications. IFS Cloud fits an asset-heavy distribution utility that keeps billing elsewhere. Infor fits a municipal utility that wants public-sector financials and a billing module in one suite. Dynamics 365 fits a municipal or cooperative utility in the Microsoft stack that is comfortable with a billing ISV.
| Vendor | Asset and work mgmt | Meter-to-cash | Regulatory reporting | Field service and mobile |
|---|---|---|---|---|
| SAP S/4HANA | Native (asset management) | Native (S/4HANA Utilities, IS-U heritage since 1998) | Native chart; FERC mapping is configuration; rated strongest | Separate SAP field service product |
| Oracle Fusion Cloud ERP plus Oracle Utilities | Separate Oracle product (Work and Asset Cloud Service) | Separate Oracle product (Customer Cloud Service) | Native financials; utility apps sold separately | Separate Oracle product (Oracle Field Service) |
| IFS Cloud | Native, its strongest area | Not offered; partner CIS required | Partner configuration for FERC; rated weak here | Native scheduling and mobile |
| Infor CloudSuite | Partner since 2021 (HxGN EAM, formerly Infor EAM) | Native module in CloudSuite Public Sector | Public-sector financials native; FERC depth trails SAP and Oracle | Via EAM partner |
| Microsoft Dynamics 365 | Asset management module in Supply Chain; test depth on linear assets | Partner ISV (MECOMS 365, UMAX) | Native ledger; FERC and rate case via configuration or partner | Separate Microsoft product (Dynamics 365 Field Service) |
| NISC iVUE (cooperatives) | Native work orders and asset management | Native CC&B | RUS accounting native | Native mobile workforce |
The contracting rule that follows: every cell marked partner or separate product needs its own statement of work, its own support terms, and a named party responsible for the integration. The Infor EAM divestiture is a due-diligence item, and the same scrutiny applies to any ISV on Dynamics 365.
Script each demo around your data, not the vendor's
A utility demo scripted by the vendor shows a clean residential customer on a flat rate and a pole replacement with two parts. Your demo should load your three hardest rate schedules, 500 assets from your GIS, one storm week of work orders, and one month of your general ledger in FERC account order. Send the data three weeks ahead and tell every vendor the same thing.
Score each requirement 0 (not shown), 1 (shown with a workaround or partner), 2 (shown native with your data). Multiply by the area weight.
For Area 1, the script is a single capital job from estimate to plant-in-service. Estimate with compatible units, reserve materials, dispatch a crew, capture time, close the order, and show the continuing property record and the GL. For Area 2, the script is one billing cycle for 1,000 of your accounts using last year's actual reads. Include the outsort queue, one collections case with a protected customer, and the revenue posting by account.
For Area 3, the script is a month-end close that produces a trial balance in FERC order, one allocation run, and one Form 1 schedule. For Area 4, the script is a storm day: 200 orders, 20 crews including mutual aid, offline completion, and time to payroll. A vendor that cannot run these four scripts with your data in a two-day demo is telling you something about the implementation.
The billing-versus-ERP boundary is the first decision, not the last
Utilities run two systems that each want to be the center: the ERP, which owns money and assets, and the CIS, which owns customers and meters. The boundary between them decides the vendor list. The integration architecture with CIS, GIS, OMS, and SCADA should be settled before vendor selection. There are three workable patterns.
Pattern one keeps billing out of the ERP program. The utility keeps its CIS (Oracle Customer Care and Billing, SAP IS-U, NISC, Cayenta, UMAX, or a municipal product) and selects ERP for finance, assets, work, and supply chain. The meter-to-cash area shrinks to integration requirements. This opens the field to IFS Cloud, Infor, and Dynamics 365 and keeps the program to one go-live.
Pattern two replaces both from one vendor, which in practice means SAP, Oracle with its Utilities applications, Infor for a municipal, or NISC for a cooperative. It is one contract but usually two go-lives. Pattern three replaces the CIS first and the ERP second, which is common when the billing system is the one in crisis. Itineris puts a medium to large water CIS replacement at 8 to 18 months, so a utility on pattern three is planning a three to four year roadmap.
Consider a 300,000-customer municipal electric and water utility replacing a 20-year-old CIS and a Dynamics GP ledger. Microsoft ends GP technical support and regulatory updates at the end of 2029, and the CIS vendor has stopped shipping tariff changes, so both have to go. Pattern three, CIS first, looks like this. Suppose selection for both runs together and ends in January 2027.
The CIS program takes 14 months, inside the 8 to 18 months Itineris quotes, and goes live in March 2028. It costs $2.5 million, near the top of that vendor's $500,000 to $3 million range, because two services bill on one statement. The ERP build starts in June 2027, once the CIS design is frozen, so the same finance team is not in two design rooms. It takes 16 months, within ERP Research's 12 to 18 for a mid-size utility, and goes live in October 2028, ahead of the 2029 GP deadline.
The gap is the seven months from March to October 2028 when the new CIS posts revenue to the old GP ledger. Suppose the revenue posting and field order interfaces cost $150,000 to build and test against one ledger. Pattern three builds them twice, once to GP and once to the new ERP. The gap therefore costs about $150,000 plus seven months of support on an interface that will be thrown away.
Pattern two, both systems on one date in October 2028, saves that $150,000. It also leaves the failing CIS in place seven months longer and puts two cutovers on one weekend. For this utility the $150,000 is cheap insurance, because the bill is what the council hears about. The right default is to sequence by which legacy system fails first, and to pay for the duplicate interface rather than stretch the system in crisis.
Plan go-live around the rate case and the filing calendar
FERC Form 1 is due April 18 and Form 3-Q within 60 days of each quarter end. A general rate case test year and filing adds a second calendar, and a go-live inside either one puts the new chart of accounts under regulatory review before it has closed a quarter. The practical window for an investor-owned utility is a go-live in the third quarter, after the Form 1 and Q1 3-Q are filed and before year-end close, with the chart of accounts mapped and tested against the prior year's Form 1.
Take an investor-owned electric utility that files FERC Form 1 and plans a general rate case on a calendar 2028 test year, to be filed in the second quarter of 2029. The filing calendar fixes three dates. Form 1 for 2027 is due April 18, 2028, Form 1 for 2028 is due April 18, 2029, and each Form 3-Q is due 60 days after the end of the first three quarters.
A go-live on July 1, 2028 splits the test year across two charts of accounts, so every test-year expense schedule carries a reclassification that commission staff will question. A go-live on January 1, 2028 keeps the test year on one chart. But the first quarter ever closed on the new system is then also the first quarter of the test year.
The go-live that fits is July 1, 2027. Q3 and Q4 2027 close on the new system, and the Q3 3-Q filing, due in late November, proves the chart before year-end. The 2027 Form 1 is a mixed year and needs one reconciliation, filed by April 18, 2028. The full 2028 test year then runs on one tested chart, and its Form 1 is filed April 18, 2029, before the rate case goes in.
Municipal utilities have a fiscal-year and budget-adoption calendar instead, and cooperatives have RUS annual reporting and the annual meeting. The rule is the same: name the filing you will not disturb, and work the cutover date backward from it.