How would a utilities billing mismatch appear in a generated environment?

A utilities billing analyst receives a complaint on **CASE-1190**: the customer's bill **BILL-8841** charges for 640 kWh, but the customer says usage was far lower.

The analyst opens the meter record **MTR-2290** and finds two reads for the period. An estimated read was entered when the field team could not access the property. A later actual read, lodged by field services, is lower than the estimate. The billing system never replaced the estimate with the actual.

Policy says that when an actual read arrives within the billing cycle, it supersedes the estimate and the bill must be reissued. The analyst cancels BILL-8841, triggers a rebill using the actual read, and records a credit adjustment. The customer's account balance falls, the complaint status moves to resolved, and a note links CASE-1190, MTR-2290 and the replacement bill.

The consequence of missing this is a customer paying for energy they did not use, plus a repeat complaint when the next estimated read is entered.

**What it teaches:** a generated environment for this workflow needs more than two numbers. It needs the read history with source and date, the supersession rule, the tools to cancel and rebill, and a final state that can be compared with the expected one. That is the difference between a lookup test and a workflow test.