Salesforce Energy & Utilities Cloud: Costs and Gaps

Salesforce Energy & Utilities Cloud is published at five list prices, from USD 250 to USD 700 per user per month, billed annually, across two tiers named Core and Max. There is no Advanced tier in this vertical. Every add-on on the pricing page, including Agentforce for Energy & Utilities, carries no published price at all.

That last sentence is the one that decides your budget. The seat price is the easy half of a utilities programme, and Salesforce publishes it clearly. The parts that usually cost more than the seats, field service, ESG reporting, order management volume, integration to the billing system, are either priced on a different page or not priced anywhere.

We verified every figure below directly on Salesforce's pages on 19 October 2026. Prices change, and this vertical in particular is in the middle of a rename, so check them again before you sign anything.

What does Salesforce Energy & Utilities Cloud cost per user?

Five editions, two tiers. These are published list prices, taken from the Energy & Utilities Cloud pricing page on 19 October 2026.

The billing qualifier on every one of those cards is (Billed annually), and the page's own disclaimer reads: "This page is provided for information purposes only and subject to change." The FAQ adds only that "Most Salesforce products use annual contracts." No minimum seat count is published.

Two things are worth noticing in that table.

The first is the size of the step. Service Core to Service Max is 2.6x, and Sales & Service Core to Sales & Service Max is 2.15x. The core clouds have three rungs at 195, 395 and 550, so a buyer who outgrows the bottom tier has somewhere to land. In Energy & Utilities there is no middle rung. You are choosing between 250 and 650, which in a 400-seat contact centre is a difference of USD 1.92 million a year at list.

The second is that the euro price is set numerically equal to the dollar price, and sterling at a flat 0.8 of it. Those are list-price policy ratios rather than currency conversions. A eurozone utility is not being charged a converted US price, it is being charged a separately set one, and at any euro rate below parity it pays more in dollar terms than a US buyer for the identical SKU. We found no Salesforce page that acknowledges this, and no regional page that disagreed with any other: the /uk/, /eu/, /au/, /in/, /ca/ and /ap/ paths all serve the same table through a currency selector.

What Core and Max include at org level, from the same page: Core carries 500K Flex Credits/org/year and 20MB storage/user, Max carries 2.75M Flex Credits/org/year and 1GB storage/user, and a footnote notes that "Data 360 includes 1TB storage entitlement in the org."

Why do Salesforce's own pages give this product four different edition names?

This is the part that costs real money in a procurement cycle, and nobody writes about it.

The pricing page sells Core and Max. The product page shows the same Core and Max card headings, then says, verbatim: "Above pricing is for Enterprise Edition," followed by "Energy & Utilities Cloud is also available in Unlimited Edition." The developer documentation agrees with the product page rather than the pricing page: the Submit Meter Reads action page states its availability as "Enterprise and Unlimited Editions with Energy and Utilities Cloud." And the contract annexe, "Additional Contractual Limitations for Energy & Utilities" at Rev. 04-2022, names the base subscriptions as "Growth - Service, Growth - Sales, Growth - Sales & Service."

Four naming generations, live at the same time. There is also a stray fifth reference: the Flex Credits row on the pricing page reads "500K/org with Core 1M/org with Advanced", citing an Advanced tier that does not exist in this vertical's ladder, and the Max bullet list says "Everything in advanced plus all full suite of Agentforce for Industries".

The practical consequence is that the entitlement document your legal team will eventually rely on uses vocabulary your sales conversation does not. In our experience the fix is cheap if you do it early and expensive if you do it late: get the legacy subscription name written into the order form alongside the new SKU name, and get the entitlement table attached. We have seen a renewal argument turn entirely on which of two Salesforce pages the customer had printed.

For the record, the core clouds have finished this migration. The Service Cloud pricing page today lists Starter Suite 25, Pro Suite 100, Core 195, Advanced 395 and Max 550, with no Enterprise or Unlimited anywhere on it. Field Service has not migrated either, and still publishes an edition called Agentforce 1 Field Service at USD 650 per user per month. The rename is running vertical by vertical, and Energy & Utilities is mid-stream.

Does Energy & Utilities Cloud have a meter object? No, and that changes the architecture

Here is the finding that should reshape how a utility scopes this programme.

Salesforce's Energy and Utilities Cloud Developer Guide documents the vertical's objects, and the list is shorter than the marketing diagrams suggest. It documents ServicePoint ("Represents an entry point for services to a premises"), BillingAccount ("Represents the customer's billing controls in the backend system"), EnergyServiceAgreement, EnergyServiceAgreementItem, the usage impact objects, ApplicationFormTemplate, IndividualApplication, EntityMilestone, Location, a handful of workforce objects, and reuse of standard Account, Contact, Contract and Product2.

It documents no Meter object, no Meter Reading object, no Consumption object and no Premises object. Usage appears as fields on EnergyServiceAgreementItem, not as an entity of its own. Salesforce's conceptual data model page does list Meter, Meter Reading and Consumption as entity names, with no API names and no descriptions, and the architect diagram for E&U Customer 360 lists fourteen objects without Meter among them. Where Salesforce's own sources disagree like this, the developer guide is the one to build against.

The clearest evidence sits in the API. The Submit Meter Reads action is documented as submitting "customer-provided or field-collected meter readings to an external billing system for billing calculation", its Readings input is capped at a "Maximum of 50 items", and it names no Salesforce object as the write target.

Read that as architecture rather than as a limit. Fifty readings per call, written to an external system, with no native meter entity, means Energy & Utilities Cloud is a customer and commercial layer sitting in front of a billing and meter data system. It is not a meter data platform and it is not built to become one. A utility that budgets to land AMI interval data in Salesforce has mis-scoped the project before it starts, and that is the single most expensive misreading available in this product. Salesforce does not say this in so many words, so treat the conclusion as ours and the API documentation as the evidence.

That also explains the shape of the competitive field, which we come back to below.

What is not included, and what the unpriced add-ons actually cover

Three gaps account for most of the surprise in a utilities business case.

ESG and carbon reporting is a separate product at a separate price. Net Zero Cloud is not named anywhere on the Energy & Utilities Cloud product or pricing pages. It is sold as a single edition, Net Zero Cloud Growth, priced per org per year. And here the regional pages do disagree, which we verified within minutes of each other on 19 October 2026: the US Net Zero pricing page shows "Contact us for pricing" in every cell, while the UK page publishes a full six-currency ladder including a USD column at $ 210,000 USD/Org/Year, qualified "Billed annually; incl. 1 full CRM licence", plus five add-ons at USD 165 per user/month, USD 60,000 per org/year, USD 150 per user/month, USD 24,000 per org/year and USD 25 per user/month. If you are a US utility being told the figure is not published, the UK page publishes it.

Field service is a separate licence with a prerequisite running the other way. The Field Service pricing page states that "Field Service and Operations requires at least one (1) Service Cloud user license", that existing Service Cloud customers "require at least one (1) Dispatcher license", and that "All per user products require an annual contract." List prices are Dispatcher USD 175, Technician USD 175, Field Service Plus USD 230 and Agentforce 1 Field Service USD 650 per user per month. Contractor Plus is USD 80 per user per month or USD 32 per login, and is the only line on that page with no annual-billing label, which tells you the login model is a genuinely different buying motion rather than a discount.

Every Energy & Utilities add-on is unpriced. Agentforce for Energy & Utilities Cloud, Industry CRM for Sales with Agentforce, E&U Cloud Intelligence, Unified Voice & Messaging, Sales Planning, Programs, Incentive Compensation Management, Prompt Builder and Agentforce Flexible Agreement are all marked "Add-on" with no figure. Service Cloud Voice, Security Center, Data Detect, Salesforce Backup & Recovery, Salesforce Archive, Salesforce Contracts and Salesforce Maps Advanced are marked "Available for purchase", also with no figure.

There is one more thing worth knowing about scope, and it comes from the contract rather than the brochure. The E&U contractual limitations document entitles the base subscription to a long feature list including OmniStudio in full, asset-based ordering, multi-site quote and order capture, and "Premises, Service Point, and Service Accounts creation upon Order", with the caveat that "Not every feature is available under every base subscription type." It then names separately sold add-ons with volume caps written into them: B2B Order Management for Energy & Utilities at "(1,000 Orders/year)", B2C Order Management at "(5,000 Orders/year)", and Digital Commerce Gateway with "API Calls (10M/year)" and "Additional Cache (10GB)". Those are contractual caps, not platform limits, and for a retailer acquiring customers at volume the 5,000-order B2C cap is the one to model first.

Which Energy & Utilities limits are actually enforced?

Most of the numbers circulating as "Industries CPQ limits" come from one page, and that page disclaims itself. Salesforce's CME application constraints page says, verbatim: "The limits outlined in this topic are not hard limits." Its preface explains that the figures exist so "you can configure your Communications, Media, and Energy (CME) applications to remain within the operating limits", and that your product model, rule counts, promotions and system load "may prevent reaching these limits."

So read the preface before you design against a number. On that page:

The cart API reference values are worth reading in full, because they are not uniform: Get Cart Items 160, Add Items to Cart 650, Submit Order 470, Delete Cart Items 120. Salesforce's own guidance is to design custom journeys around the lowest value among the APIs you use, and in a quote-rework journey that is the 120 on single-row cart deletes, not the 650 you probably noticed first.

The more useful category on these pages is neither a limit nor a recommendation, though. It is behaviour documented as unsupported, which you cannot get raised and cannot choose to ignore. The Digital Commerce API usage considerations page carries dozens of these, and the cache invalidation ones are what bite in production: the cache is "unable to regenerate or recompute existing baskets if they contain configured offers", it "does not support scenarios in which a child product within the catalog hierarchy is changed to inactive", and a deactivated offer "will not be automatically removed from the response" until the cache is cleared and the Populate API Cache batch job is rerun. Salesforce also states plainly that "Cache management will require manual steps while the admin capabilities are expanded."

One honest limitation on our side: the per-edition feature matrix on the pricing page uses icons rather than text, so we can confirm that rows named CPQ, Orders Management, Product Catalog & Price Management and the Field Service rows exist, but not which editions include them. Do not take anyone's word for which tier includes CPQ, including ours. Read the matrix yourself, or get it in the order form.

What is the business case actually built on?

Utilities programmes get approved on service economics, not on CRM features, and the public statistics are better than the vendor ones.

In the United States, the EIA's Residential Utility Disconnections Report, published April 2026, records 13,447,935 electricity disconnections in 2024 against "143.0 million residential electricity customers", with October the peak month at 1,490,201 disconnections, or 1.04% of accounts. Gas disconnections ran to 1,650,511. Smart meter coverage is older data: EIA puts advanced metering at about 119 million installations, roughly 72% of electric meters, on 2022 figures, and FERC's December 2024 assessment gives "an advanced meter penetration rate of 72.3%" on the same base year.

In Great Britain the numbers are sharper still. Ofgem's State of the Market retail highlights, January 2026, reports that "around 82% of bills were issued as accurate readings", that there were "54 million bills issued to estimated readings", and that "Billing and meter reading plus customer service account for approximately 60% of all complaints". Over the same period projected domestic sector profit fell from £0.88bn in 2024 to £0.27bn in 2025, and customers in debt or arrears rose "from 3.4m to 3.6m". DESNZ's June 2026 quarterly update adds a detail that matters for any field and billing scope: of roughly 42 million smart and advanced meters installed, 3,133,000 are in traditional mode, which is to say installed, not returning smart data, and still generating manual reads.

That is the honest shape of the case. A GB retailer is being asked to fix service economics in a year its domestic margin fell by around 69%, with three million installed meters still behaving like old ones. The juxtaposition is ours. Every figure in it is the regulator's.

We looked for credible statistics on utility IT spend and CIS replacement cycles and did not find any from a government source or regulator. The market-sizing figures in circulation come from firms that publish no methodology, so we have left them out rather than dress them up.

How does this compare with Oracle, SAP and the specialists?

The interesting difference is not feature lists, it is the unit of sale.

Oracle's Utilities Cloud Service Descriptions, last updated 8 October 2026, meters Customer Cloud Service "per Billable Service Customer", with a usage limit of "A maximum number of Billable Service Customers per Month as specified in Your order", and tiers production storage by that same metric, from 250 GB up to 125,000 customers to 2,000 GB at one to two million. Batch capacity is sold the same way, at "Three (3) Batch Threads for every fifty thousand (50,000) Billable Service Customers per Month" with a minimum of six.

Those two metrics diverge enormously with the shape of your business. A 500-seat contact centre at a five million customer utility is cheap on Salesforce's metric and expensive on Oracle's. A 50-seat lean retailer with the same five million customers is the same comparison, only harder to win. We have seen both decisions go the other way from what the shortlist expected once the arithmetic was done on the real seat and customer counts, which is why we now do that arithmetic in week one rather than week ten.

Oracle also sells a named Meter Solution and a named Market Settlements Management, and Salesforce sells neither. Given what the Submit Meter Reads API does, that is a documented functional boundary on both sides rather than a competitive opinion.

On the others: SAP publishes no list price for S/4HANA Utilities, and every figure attributed to it comes from a reseller or a price aggregation site. Microsoft publishes Dynamics 365 Field Service prices but has no energy or utilities SKU on that page at all. Gentrack and Hansen publish neither prices nor a pricing model, though both publish financials: Hansen reported FY26 Energy & Utilities operating revenue of USD 202.3m and an underlying EBITDA margin of 31.0%, while Gentrack guided in May 2026 to FY26 revenue of "between $229m to $238m, lower than our previous guidance" with EBITDA "between $13.5m and $20m". Salesforce is the only vendor in the set publishing a per-seat list price for a utilities product, which is a genuine procurement advantage and also why its number is the one everyone benchmarks against.

How long does a utilities implementation take?

These are Aptivus estimates, not Salesforce figures. We could find no published Salesforce timeline or cost figure for a utilities implementation, and nobody else's is published either. Use them as a planning baseline to test real quotes against.

The variance driver is not the Salesforce configuration. It is the billing system interface, and specifically how many of the inquiry journeys your billing platform can answer synchronously. The orders we have seen slip have slipped there, every time.

A workable sequence, if you are starting now:

1. Count your seats by role and your billable customers. Model Salesforce per seat and Oracle per billable customer on the same page, before the shortlist narrows.
2. Decide whether meter data is in scope. If it is, name the system that will hold it, and keep it outside Salesforce.
3. Price the gaps separately: ESG reporting, field service seats, order volume caps, and the unpriced add-ons you will actually need.
4. Ask for the add-on price list in writing. The HTML pricing page prices none of them, and the Salesforce-wide add-on PDF is not readable by automated tools, so a human has to request it.
5. Get the legacy edition name and the entitlement table attached to the order form, given the four naming generations above.
6. Model the Core to Max step at your real seat count before you accept the bottom tier. There is no middle rung to move to.

Frequently Asked Questions

How much does Salesforce Energy & Utilities Cloud cost?

List prices published on 19 October 2026 are USD 250 per user per month for Service Core, 325 for Sales & Service Core, 650 for Service Max, 650 for Sales Max and 700 for Sales & Service Max, all billed annually. Add-ons are named on the pricing page but none carries a published price, so the seat price is a floor rather than a budget.

Does Energy & Utilities Cloud include Sales Cloud and Service Cloud?

For the Sales & Service editions, yes. Salesforce's product page states the product "also includes everything in corresponding editions of Sales Cloud and Service Cloud, Enterprise, and Unlimited Editions". That is inclusion, not a prerequisite, so you do not buy those separately. No Salesforce page we found states the equivalent for the Service-only and Sales-only SKUs.

Can Salesforce store smart meter readings?

Not as a native entity. The developer guide documents no Meter, Meter Reading or Consumption object, and the Submit Meter Reads action sends readings "to an external billing system for billing calculation" in batches capped at 50 items. Treat Energy & Utilities Cloud as the customer layer in front of your meter data and billing systems, not as a replacement for them.

Is Net Zero Cloud included with Energy & Utilities Cloud?

No. Net Zero Cloud is a separate product, not mentioned on the Energy & Utilities Cloud pages, sold per org per year. Salesforce's UK pricing page publishes USD 210,000 per org per year including one full CRM licence, while the US page currently shows "Contact us for pricing" throughout. If ESG reporting is in scope, price it as its own line.

What is the difference between Core and Max in this vertical?

Price and credits, mainly. Core carries 500,000 Flex Credits per org per year and 20MB of storage per user; Max carries 2.75 million Flex Credits and 1GB per user, and bundles the Agentforce for Industries suite that Core sells as an add-on. There is no Advanced tier here, so the step is 2.15x to 2.6x with nothing between.

Are the Industries CPQ limits hard limits?

Mostly no, and Salesforce says so. The CME application constraints page states "The limits outlined in this topic are not hard limits", which covers the 500,000 matrix rows and the bundle size of 60. The genuinely enforced figures nearby are the 10,000 record SOQL restriction on PriceListEntry__c, the cart API line-item maximums, and the 50-item cap on Submit Meter Reads.

Where to start

If your Energy & Utilities business case rests on fixing estimated billing and the complaint volume that follows it, the thing to settle first is not the edition. It is which system holds meter and usage data, because that decision sets the integration scope, and the integration scope is where these programmes actually overrun. We will model the seat arithmetic against your real role counts and map the inquiry journeys your billing platform can answer synchronously, and you will know within a fortnight whether the Core tier is sufficient. Tell us what your billing stack looks like and we will start there, or read how we scope industry cloud implementations first.