A disputed bill can leave your team doing the integration work by hand.
Your operator opens support to read the complaint, billing to check the charges, then another system for the readings and service history. Before explaining anything to the customer, they have to establish which records belong together.
For Australian energy retailers, billing investigations are a useful place to evaluate AI agents. Start with gathering the right evidence, applying the checks your business defines, and preparing a case a person can review. Measure whether that investigation reaches an accepted result, including the work people still have to do.
That gives you a clear first job to prove before adding financial actions such as changing a bill or issuing a credit.
A NMI identifies the connection point; your case also needs an account and a period
The National Metering Identifier, or NMI, identifies the electricity connection at an address. The Australian Energy Regulator's Energy Made Easy service explains this distinction and notes that the NMI differs from the number on the meter. Energy Made Easy: finding your NMI.
Your workflow still needs the retailer's account relationship and the dates relevant to the complaint. Finding a matching NMI does not establish that every bill or service record returned belongs in this customer's investigation.
Keep the NMI, customer account ID, and meter serial as separate fields. Use the mappings your business already trusts, including their effective dates. If two records disagree, show both to the reviewer and flag what needs resolving.
The practical question is whether the evidence refers to the correct connection point, account, and period. Put those checks into the workflow before it prepares an explanation or proposes a change.
Follow one disputed bill through the records
Consider an illustrative NSW electricity customer who queries a bill after a meter-related service event. The timing gives the team something to investigate. It does not establish that the event caused a billing error.
The support case describes the customer's concern. Billing holds the disputed period and charges. The retailer's authorised metering records and service history help the reviewer establish what information was available and what changed.
AER's bill guidance identifies the billing period, readings, estimated basis, and supply and usage charges as information worth checking. Its guidance applies to NSW and several other jurisdictions; the workflow here uses NSW as its example. AER: understanding your energy bill.
The agent should collect the relevant evidence using the retailer's approved access routes. Preserve the source's reading labels and units. If a code is unfamiliar, the domain owner supplies its meaning; the model should not invent an interpretation.
A meter event may explain why two serial numbers appear in the records. A missing reading may explain why the investigation cannot yet reach a conclusion. Neither finding, on its own, tells the agent what financial adjustment the customer should receive.
That decision depends on the evidence and the retailer's policy. The workflow should make both visible to the person responsible.
Give the reviewer an investigation they can check
A useful evidence packet lets the reviewer inspect the reasoning without reopening every system and repeating the search. Each material statement should point to a record, and each unresolved question should say what is missing.
| Part of the investigation | What the reviewer needs |
|---|---|
| Customer question | The disputed bill and concern recorded in the support case |
| Record selection | Account, NMI, and period references, with the checks used to connect them |
| Billing evidence | Relevant charges and the reading information used for the disputed period |
| Metering and service context | Source records, original labels, and relevant event dates |
| Proposed next step | The applicable business rule, supporting evidence, and any uncertainty |
| Review record | The person's decision, reasons, and work still required |
Keep observations separate from proposed explanations. “The service record shows a meter event on this date” is something the reviewer can verify. “That event caused the overcharge” needs supporting evidence and an authorised decision.
When evidence conflicts, the packet can still be useful. It should identify the conflicting records and route the case to someone who can resolve them. A fluent summary that hides the conflict makes the next person's job harder.
Use the access your team can authorise
Start with the retailer's own systems and approved records. Existing APIs, integrations, or test extracts may already provide what the investigation needs. Keep those routes where they work.
If the next step sits in a legacy billing application, verify that the selected account can perform the exact operation. An agent may need a private web interface or an authorised UI route where the public API falls short. Our guide to AI agents working with legacy systems explains those choices.
Prove the workflow in a non-production environment using records that preserve the relationships and exceptions you need to test. Scope access to the selected job so the pilot demonstrates the permissions you intend to use.
Decide what “finished” means before the first run
For an initial pilot, a completed investigation might mean an accepted evidence packet, a review-task reference recorded in support, and a named owner for the next action. Issuing a corrected bill is a different completion condition.
Make that distinction explicit in the workflow and in the result it reports. Otherwise, a team can count an investigation summary as success while the customer is still waiting for someone to act on it.
Test the writes as well as the analysis. If the review task is created but the support update fails, the workflow should retain the task identifier and report the unfinished step. The next attempt should check for the existing task before creating another one.
Material changes after review need attention too. If the account reference or evidence changes before the proposed write, revalidate the action and seek renewed approval where the policy requires it.
Measure the accepted investigation and the work around it
Compare the workflow with how your team investigates similar cases today. Include ordinary cases, missing evidence, and conflicting records so the result shows where the workflow helps and where people still carry the work.
Track unique cases separately from attempts. A case attempted three times remains one case, with all three attempts included in its cost.
Track which investigations were accepted, which needed extra human work, and which remain unresolved. A deliberate stop can be the correct response to ambiguous evidence while the investigation remains unfinished.
Measure active human time and elapsed time separately. An agent may collect records quickly while a case waits in an approval queue. The customer experiences the whole delay.
Cost per completed investigation = total operating cost for the cases attempted ÷ investigations completed to the agreed standard.
Include model and tool use, platform charges, and the time people spend reviewing, recovering, and maintaining the workflow. Keep one-time implementation visible separately. Our guide to agent failures and completed-work cost explains the calculation in more detail.
Set quality and economic targets before reviewing the results. A wrong-account write should trigger investigation and repair even when the average handling time looks good. Time saved is useful capacity; whether it becomes a financial saving depends on how the team uses it.
Where Monarch fits
Monarch is the orchestration layer between agents and enterprise systems. Its Product Graph discovers application operations and their requirements, including routes below the public API where available. The graph covers operations the connected account can access and discovery has captured and verified.
For a billing investigation, that application knowledge can connect the work across support, billing and metering or service applications. Your team supplies the authoritative mappings, business rules, and approval decisions. Repeatable steps can use deterministic code while the workflow checks the records for the current case.
Monarch offers Australian hosting and customer-cloud deployment options, with customer-controlled accounts, review of consequential writes, and audit evidence. Bring the deployment and data-handling requirements into the security discussion as you choose the workflow.
Two questions to settle when choosing the first workflow
Does the pilot need to change customer bills?
No. A reviewable investigation can be a valuable first outcome when people spend substantial effort gathering evidence. Define how that investigation moves into the existing billing process, and measure the remaining work so the pilot does not hide it.
What if our existing billing integration already supplies the records?
Use it. Evaluate the work still needed to connect those records to the support case, check their relevance, and get a decision from the right person. A new tool should prove value on that remaining job.
Bring one billing investigation your team knows well to a scoped Monarch pilot. We'll work through the systems, evidence, and approvals it needs, then agree how to measure a completed result.