Skip to main content
Agentic Architecture Skills.
Start hereUse casesArchitectureIntelligence ladderKnowledge & memoryResearchSkills
Worked examples

Resolve billing exceptions without deciding hardship

How an energy retailer clears implausible meter reads and held bills today. How agents can run the same work, with a rule or a specialist approving every change. A water variant is included.

By Murali SidLinkedInPublished Updated

A meter read fails a check, or a bill fails a check in the bill run. The case lands on an exception list. A billing exception specialist works out whether the read is wrong or the use is real. Then the specialist releases, corrects or holds the bill. In Australia and New Zealand, the energy retailer owns this list. The retailer is the one that bills the household. Agents can gather the evidence and propose a resolution. A fixed rule or a specialist still approves every change to a bill. Anything about hardship goes to a trained person.

The systems involved

This work touches nine of the fourteen layers. The table names the systems at an energy retailer and at a water utility. Vendors in brackets are examples, not a claim about any one company. The utilities page shows the full estate.

How it runs today

This is the process at an energy retailer on smart meters in Australia's National Electricity Market. It is typical industry practice, not a survey of one retailer. Steps 1 to 3 happen at the metering provider. The retailer's work starts at step 4.

  1. The meter collects use. The metering provider's smart meter head-end collects 5 or 30 minute reads. They arrive over mesh radio or cellular, several times a day (typical, unsourced).
  2. Gaps are filled. The meter data provider checks the reads in its own meter data system. It substitutes or estimates bad or missing data under AEMO's metering rules. Substituted values carry a quality flag.
  3. Meter data is sent. The meter data provider sends a NEM12 meter data file inside a B2B meter data notification. It travels over AEMO's B2B e-Hub, usually as a daily batch (typical).
  4. Reads are loaded and checked. A batch job loads the file into the retailer's CIS. Reads above or below set limits are held as implausible.
  5. The bill run holds failures. The overnight bill run holds any bill that fails a check. Examples are a bill that is too high, negative or zero, a tariff mismatch, or a missing read. The CIS creates a case. In SAP the list is a BPEM worklist, and the app is called "Resolve Implausible Meter Readings" [vendor].
  6. The specialist picks up the case. A billing exception specialist opens it from the CIS worklist. The screen shows the reason code, the account, the amount and past bills.
  7. The specialist investigates. Read history comes from the CIS and meter data screens. Meter, tariff and network details come from MSATS web screens. Contact notes come from the CRM. A spreadsheet tracks open queries.
  8. The specialist asks for data or a new read. A request to provide or verify meter data goes to the meter data provider. A special read order goes to the distributor or metering coordinator, and may carry a fee. Both go through the B2B gateway. Answers take days (typical, unsourced).
  9. Wrong standing data is fixed. The specialist or market operations sends a change request or an email to the party that owns the data.
  10. The specialist decides. The specialist releases the bill, corrects it, uses an estimate, or keeps holding it. A team lead approves above a set amount (typical).
  11. The customer is checked first. Before a high bill goes out, the specialist checks the account. It looks for a payment plan, a hardship flag, life support or an open complaint. Any of these goes to the hardship or complaints team, by CRM task or email.
  12. The customer is told. The specialist or the contact centre sends a high-bill letter or SMS. A large catch-up bill gets a phone call.
  13. The backlog is reported. The billing operations manager reads the warehouse dashboards. They show the backlog by age, accounts not billed on time, and unbilled revenue at month end.
Swimlane of the billing exception process at an energy retailer today. Three lanes are systems: the metering provider, the market and the billing system. Four lanes are people: a team lead, the hardship or complaints team, the specialist and the operations manager. Steps 1 and 2 sit with the metering provider: reads are collected and gaps estimated. Step 3 sends a NEM12 file through the market. Steps 4 and 5 sit in the billing system: reads are checked and the bill run holds a bill. Steps 6 to 12 sit with the specialist. The specialist picks up the case, checks several screens, requests data or a read, and fixes standing data. Requests and data changes go out through the market. At step 10 the specialist releases, corrects or holds the bill. A team lead approves above a set amount. At step 11 the specialist checks for hardship. The hardship or complaints team decides those cases. At step 12 the customer is told. At step 13 the operations manager reports the backlog.
Billing exceptions today: who does whatToday a specialist joins six screens by hand. The approvals sit with a team lead and the hardship team.Open image at full size ↗

Handoffs

The meter data provider hands data to retailer billing. Billing sends queries to market operations, and from there to the distributor or metering coordinator. Billing hands protected customers to the hardship team. Billing hands customer contact to the contact centre. Billing hands unbilled revenue to finance at month end.

Reporting

  • A warehouse dashboard of the backlog by age and reason.
  • An estimate of unbilled revenue for the month-end close.
  • Compliance. A retailer must bill small customers regularly. It can recover undercharged amounts only for a limited period.
  • Quarterly retail performance data for the Australian Energy Regulator (AER), on hardship, payment plans and disconnections. The AER published a January to March 2026 update.
  • Complaints to the energy ombudsmen, such as EWON in New South Wales and EWOV in Victoria.

Cycle time and volumes

  • No Australian or New Zealand figure was found.
  • Germany has measured figures. Westnetz resolves 90 percent of meter reading exceptions automatically. EWE checks about 50,000 photo reads a month at 99.5 percent accuracy. Both come from a consultancy summary citing PwC (innobu, 26 September 2026).
  • Stadtwerke Muenchen saw exceptions between market parties rise almost tenfold after Germany moved to 24-hour supplier switching (same source).
  • Typical, unsourced: a small share of reads and bills fall out of each run. Most cases clear in one to three days. Cases waiting on another market party can run for weeks.

Pain points

  • Work done by switching between six screens: the CIS, meter data, MSATS, the B2B gateway, the CRM and email.
  • Waiting on other market parties, and duplicate requests when nobody can see an open one.
  • Standing data that does not match between the retailer, MSATS and the distributor.
  • Old unbilled accounts that turn into a compliance issue.
  • Know-how held by a few specialists.
  • The risk of a large catch-up bill reaching a customer in hardship.

The water and New Zealand variants

A water utility owns the whole process. There is no market in between, so steps 1 to 3 change. A meter reader, often a contractor, reads mechanical meters with a handheld device. The read file is loaded daily. A suspect read becomes a re-read order to the reading contractor, sent through the field or work system. Water rules add leak allowances and the split between owner and tenant charges (typical, unsourced). Digital meters are arriving and will bring interval data.

In New Zealand, retailers are called traders. The metering provider sends data to the retailer. The retailer sends billing volumes to the distributor as EIEP1 files by 5pm on the 5th of each month. EIEP files are the standard data files between New Zealand market parties. They move through the Electricity Authority's registry file hub over SFTP, a secure file transfer.

How agents run it

The design starts from what the billing system already does. SAP S/4HANA Utilities scores each held read and bill with a release confidence. The utility sets whether the system releases on that score or only proposes a release [vendor]. The agent adds the investigation a specialist does next. The model never releases a bill.

  1. Notice a new case. Agent. It reads an event when the CIS creates a case, sent through the integration bus. Where no event exists, it polls the worklist API. It writes nothing.
  2. Check for protected customers first. A fixed rule, which the agent calls as a tool. The model's judgement plays no part. The rule reads hardship, payment plan, life support, complaint, ombudsman and disconnection flags through the CIS and CRM APIs. It writes a case note: "protected, routed to a person". Routing is a rule, so no approval is needed.
  3. Hand protected cases to a person. Hardship or complaints officer. The officer reads the agent's evidence summary in the CRM case. The officer decides everything and records it in the CRM.
  4. Gather evidence. Agent. It reads interval data, quality flags and meter events through the meter data API. It reads bills, read history, device changes and the release confidence through the CIS API. It gets MSATS standing data through a meter identifier lookup or a report. It uses RPA on MSATS screens only where no API exists. It reads CRM notes. It writes an evidence pack on the case.
  5. Propose a resolution. Agent. It compares the evidence pack with past specialist decisions, kept as a reference set. It writes one proposal on the case: accept, correct, estimate, request data, request a read, or hold. Each proposal carries a confidence level.
  6. Draft market requests. Agent. It writes a draft B2B message into the gateway's outbound queue. A fixed rule approves fee-free data requests. A specialist approves fee-bearing orders, such as a special read.
  7. Release plausible cases. A fixed rule inside the CIS, not the agent. The rule reads the proposal, the confidence and a set of hard limits. The limits are a cap on the bill change, no protected flag, and no back-billing beyond the legal limit. If all pass, the CIS releases the bill. A random sample of releases is checked.
  8. Approve the rest. Specialist. The specialist reads the proposal and evidence in the CIS worklist and decides there. A team lead approves above a money limit.
  9. Draft the customer message. Agent. It reads the bill, the use history and the cause. It writes a draft in the CRM. A template rule or a person sends it.
  10. Check a sample. QA lead. The lead reviews a sample of released cases. The result is stored with each case.
  11. Report. Agent, then operations manager. The agent reads the warehouse and case outcomes and drafts the BI dashboard. A person signs any regulatory number.
Swimlane of the billing exception process with an agent. Three lanes are people: operations manager and QA lead, hardship or complaints officer, and specialist and team lead. Four lanes are the billing system, fixed rules, the B2B gateway and the evidence store. The agent has its own lane. A read or bill fails a check in the billing system. Step 1: the agent notices the case. Step 2: a fixed rule checks for protected customers. Step 3: if protected, a hardship or complaints officer decides. Steps 4 and 5: the agent gathers evidence and proposes a resolution. Step 6: the agent drafts a market request into the B2B gateway queue. A fixed rule approves fee-free requests and a specialist approves fee-bearing orders. Step 7: a fixed rule releases plausible cases. Step 8: a specialist approves the rest. Step 9: the agent drafts the customer message, and a person or template rule sends it. Step 10: a QA lead checks a sample. Step 11: the agent drafts the report and the manager signs. The evidence store sits outside the agent. It holds traces, case history, the B2B message log and QA results.
Billing exceptions with agents: who does whatThe model never releases a bill. A fixed rule or a person approves every change, and protected customers go straight to a person.Open image at full size ↗

What stays with a person, and why

  • Hardship, payment plans and disconnection holds. These are decisions about a person. In AER v Origin (Federal Court, 6 July 2022), automated processes changed payment plans without checking capacity to pay. Origin paid an A$17 million penalty.
  • The new hardship rules. The Australian Energy Market Commission (AEMC) writes the market rules. It made a final rule on 10 September 2026. It strengthens payment difficulty and disconnection protections from 30 March 2027. A second rule, on payment plan standards, was still open on 15 October 2026.
  • Fee-bearing orders and bills above the cap. This is money.
  • Standing data owned by another market party. That is someone else's record.
  • Regulatory reports. These are formal records that a named person signs.

Where the evidence is kept

  • Agent traces go to a store outside the agent, under the retailer's control. Each trace holds every tool call, its input and its result.
  • The CIS keeps its own case history and change records. These stay the legal record.
  • The B2B gateway logs every market message.
  • QA results are stored with each case.

This follows one of the two rules behind the seven capabilities. The audit trail is written where the agent cannot touch it.

What changes in the systems

  • New fields on the case: the proposal, the confidence, an evidence link and the agent run ID.
  • A new case status, "agent proposed".
  • An event subscription on case creation, through the integration fabric.
  • A service identity for the agent in the CIS and the meter data store. It can read and propose. It cannot release. This sits in the security and identity layer (R10).
  • A draft queue in the B2B gateway.
  • A store for the reference set of past decisions, in the agent data engineering layer (R14).
  • New dashboard measures: release rate, reversal rate, wrong releases found by sampling, and time to resolve.

What does not change

  • The meter data provider's checking and estimation rules. The market procedures set them.
  • The CIS billing engine and the tariffs.
  • The market procedures and message formats.
  • The hardship policy.
  • Who signs off.

Who does this today

The best measured exception automation is German, and it uses rules and models, not language models. Language-model agents for billing exceptions are still plans. No named utility was found letting a language-model agent change a bill on its own. Status is as of 15 October 2026.

Where this sits

Answer the four questions for this agent. Its role is assist: it helps a specialist with a set task. Its permissions are what its own credentials let it do. It can read the CIS, meter data, MSATS data and CRM notes. It can write proposals, case notes and drafts. It cannot release a bill or change an account.

Its autonomy is set on the autonomy contract. It is designed and permitted for delegated tasks (A2). It proposes, and a rule or a person decides. The fixed release rule runs plausible cases at supervised autonomy (A3), with sampling. The rule acts, not the model. Once hardship, a payment plan or disconnection is involved, the agent only flags. That is assisted (A1).

Its impact is on money. Any change to a bill sits in the money zone. Hardship, payment plans and disconnection fall under the rule for decisions about people. A named person decides each one.

On the risk profile it is Tier 3 (strict), because an action in a zone always scores high. The release rule could drop to Tier 2 (enhanced) only if it is fixed and reversible. It must also be named in the signed zone register. Hardship cases stay at Tier 3. Its learning is curated learning (L1). People choose the past decisions it learns from, offline, and review each change before release.

Register it through the agent lifecycle, with a named sponsor in billing operations. Its scoped tools sit behind the tool gateway. Policy is enforced outside the model, at the gateway and in the CIS. The enforcement page shows how.

Measure the result

Measure the resolution rate: cases resolved correctly and not reopened. Do not measure containment. Containment counts cases that never reached a person. Count wrong releases found by sampling, reversals, billing complaints and time to resolve. Track cost per resolved outcome. Count the hardship cases routed to a person, and how fast a person picked each one up. Compare with the current team on the same cases.

Start with a trial

Take a historical sample of exceptions, with the specialists' decisions as the reference. Run the agent in shadow mode, with no live releases. Review errors and costs with the billing team that will own the work. Then allow automatic release for one plausible exception type, under a small cap on the bill change. Keep sampling. Widen the scope only when quality, permissions, recovery and supervision hold.

Evidence and limits

The current process is written from industry knowledge, not a survey of one retailer. No Australian or New Zealand volumes or cycle times were found. Where a figure is typical, the page says so.

The measured results are German. They come from rules and models on German market messages, not from language models. Do not carry Westnetz's 90 percent to another market. SAP's billing agents were not confirmed as shipped on 15 October 2026.

Three points were not checked against their source for this page. They are the billing frequency rule, the limit on recovering undercharged amounts, and the quality flags on substituted data. Check the current National Energy Retail Rules and AEMO procedures before relying on them.

AER v Origin was a case about automation, not AI. It still sets the line for any agent that touches payment plans. This guide recommends a fixed rule, never the model, for every release.

Next step

Score this agent on the risk profile, then set its controls with the deterministic zones. Return to utilities for the other worked examples.

Explore this topic

All sources checked on 15 October 2026 unless a date says otherwise. "Search excerpt" means the page itself could not be opened.

Cite this page

Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.

Murali Sid (2026). Resolve billing exceptions without deciding hardship. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/use-cases/billing-exceptions

Machine-readable version of this page: /use-cases/billing-exceptions.md

Investigate a water-network anomaly

How a water utility's control room investigates an alarm today. How an agent can gather the evidence from a read-only copy of the data while people decide and act.

Safety coaching from CCTV, incident and observation data

Turn a risky moment caught on camera, or logged as an observation, into coaching the safety owner approves. Real-time interventions, discipline and any decision about a person stay with people.

On this page

The systems involvedHow it runs todayHandoffsReportingCycle time and volumesPain pointsThe water and New Zealand variantsHow agents run itWhat stays with a person, and whyWhere the evidence is keptWhat changes in the systemsWhat does not changeWho does this todayWhere this sitsMeasure the resultStart with a trialEvidence and limitsNext step