New articleSAP IS-U to S/4HANA Utilities: choosing between conversion, greenfield and selective transition

· Meter-to-cash

Meter-to-cash on SAP IS-U and S/4HANA Utilities: the handoffs that cause most of the work

A plain walk through the meter-to-cash process on SAP IS-U and S/4HANA Utilities, from device installation to collections, and the handoffs where exceptions start.

  • Meter-to-cash
  • IS-U
  • Billing

Meter-to-cash is the chain of steps that turns a meter on a wall into money in the bank: install the device, read it, check the read, bill it, invoice it, collect the payment and follow up when the payment does not come. On SAP IS-U and S/4HANA Utilities every step is standard functionality. Most of the day-to-day work sits in the handoffs between steps, and in the interfaces to systems outside SAP.

The steps

  1. Device installation and device management: devices, registers and their installation at a premise, with the technical and billing installation in SAP.
  2. Meter reading: meter reading orders, and reads coming in from an AMI head-end or meter data management system, or from field reads.
  3. Validation and estimation: plausibility checks, and estimated reads where an actual read is missing or rejected.
  4. Billing: rate categories, rates and billing schemas turn reads into billing documents.
  5. Invoicing: billing documents become the bill, with bill print or electronic delivery.
  6. Payments: payments arrive and are cleared in FI-CA.
  7. Dunning and collections: unpaid items move through dunning, installment plans and, where it applies, collection agencies.

Where it breaks: device to read

A device exchange or a register change that is not completed correctly in SAP means the next read has nowhere valid to go. These are low in number but slow to fix, because the device, the installation and the read history all have to agree before billing can continue.

Where it breaks: read to billing

This is where most exceptions start. Reads that fail plausibility checks, reads that arrive late from the meter data system, and estimates that the customer later disputes all become clarification cases. Tuning validation rules and estimation settings, and monitoring the interface from the meter data system, does more for the backlog than working cases faster.

Where it breaks: billing to invoice

Billing documents that are outsorted, invoices that stop before print, and installations that do not bill at all are the next layer. The last one is easy to miss: an installation that is not billing does not raise an error by itself. A regular unbilled report, reviewed every cycle, is the control.

Where it breaks: invoice to cash

Once the bill is out, FI-CA takes over. Clearing rules, payment lots, returns and dunning all have their own exceptions, and they surface as customer calls if no one is watching them.

Running it as one process

In many utilities each step has a different owner: field operations for devices, a metering team for reads, billing for billing, finance for FI-CA. Exceptions get passed along rather than fixed at the step that caused them. Three things help:

  • One view of the open exceptions across the chain, by step and by age, so the backlog is visible as a whole.
  • A named owner for each interface, especially the meter data and payment files, with an alert when a file is late or fails.
  • Root-cause reviews by category: when the same exception comes back every cycle, change the rule or configuration that creates it.

None of this needs new software to start. It needs the existing reports and worklists in SAP looked at together, on a schedule, by people who can change what they find.

Discuss this with a senior consultant

Bring the details of your program. The call is with someone who has done the work.