Most utilities on SAP IS-U or S/4HANA Utilities have a BPEM worklist that grows faster than the billing team can clear it. Implausible meter reads and outsorted bills turn into clarification cases, cases age, and bills go out late. It is tempting to point an AI tool at the whole backlog. In our experience that is the wrong starting point. The better question is which cases should never have been created, which can be closed by checks SAP already provides, and which genuinely need a person.
We think about it in three layers: prevent, close, resolve. AI and machine learning help in each one, but in different ways, and with different limits.
1. Prevent: stop low-risk cases being created
SAP S/4HANA Utilities includes embedded machine-learning scenarios that score implausible meter reads and outsorted billing documents, based on how your specialists handled similar items in the past. Items that score above a threshold can be released before BPEM creates a clarification case at all. Which scenarios are available depends on your release, so check this in your own system first.
Two practical points matter more than the model itself:
- Order the job chain. Score and release reads before the billing run, and score outsorted bills before case creation. Run it after every portion. If a scoring step fails, the chain should carry on and create cases as it does today, so a failure costs you nothing extra.
- History. The model learns from worked exceptions with a final outcome. Use enough history to cover your seasonal patterns, and get your data protection team to approve training on it, because it contains customer consumption data.
On ECC-based IS-U there is no embedded scenario, but the same idea works with a scorer running side by side on SAP BTP.
2. Close: let SAP finish cases whose object is already fixed
One detail catches teams out: the machine-learning scenarios release the meter read or the billing document, but they do not complete an existing BPEM case. Cases that are already open need an automatic solution process per case category, which checks whether the case's own object has been released and then completes the case.
This is plain configuration, not AI, and it is often the quickest win. It should never close open disputes, categories without a defined solution process, or cases whose object is missing or doesn't match. Which status values count as "released" for each case category is something to confirm in your system, not assume.
3. Resolve: an agent that recommends, and a person who decides
What remains are the cases that need judgment. This is where an AI agent earns its place: it reads the case, the billing document and the read history, suggests a likely root cause (a bad estimate, a meter rollover or swap, a missing rate, an open dispute, a final-bill credit, or a difference within tolerance), and proposes a resolution with the evidence behind it and a confidence score.
A ranked, explained worklist saves a specialist the first round of digging on every case. It does not need to make the decision to be useful.
Where AI shouldn't act on its own
The limits are the part most worth agreeing before a pilot starts. The ones we build in:
- No changes to rates, tariffs or billing configuration by the agent, ever.
- Reversals, re-reads and case routing need a named approver.
- Automatic release only for low-risk documents within a tolerance the utility sets, and only when the rules and the model agree.
- Customer segments such as large commercial accounts, net metering and protected customers are excluded from automatic release, whatever the score.
- Every recommendation, approval and action goes into an audit log.
- Machine-learning confidence can only tighten the guardrails. A high score on a dispute or a rebill is noted for the specialist, but it never approves anything.
Calibrate before anything goes live
Start in shadow mode. Run scoring for at least a full billing cycle with automatic release switched off, while specialists work cases as they do today. Then compare: of the items the model scored highly, how many did your specialists release without a later reversal or rebill? Look at that per score band and per customer segment, not as one average.
Only then pick a threshold, and have a named owner sign it off along with the excluded segments. Record your own baseline first, too: open cases by category, average handling time, reopen rate and aging. Vendor estimates are a reason to try, not a result. The improvement should be measured on your own data.
Where to start
Pull an aging and category breakdown of your current BPEM worklist. It usually shows a handful of categories that make up most of the volume. Decide, category by category, which layer each belongs to: prevent, close or resolve. That map is a better first deliverable than any model, and it makes the AI part smaller, safer and easier to approve.