What does a billing mismatch caused by a transposed meter read look like?

At a water and electricity retailer, a billing analyst opens `CASE-0412`. Customer account `ACC-7730` was billed for 1,840 kWh, but the meter-data system shows 1,184 kWh for the same period. The two records should agree; they differ by 656 kWh.

The analyst pulls the read history. A manual read entered mid-period has its digits transposed, and an estimated read that followed was built on it. The billing engine used the estimate. The meter-data system holds the later actual read, which is correct.

Policy says billing corrections above a set threshold need a team leader's approval, and a credit must be raised against the original invoice rather than editing it. The analyst reissues the read as a corrected value with a reason code, triggers a rebill, and routes the credit to `APPR-0091` for approval. The case note records the cause as a transposed manual read.

The cost of the wrong move is concrete. An agent that simply overwrote the invoice total would make the figures agree, break the audit link to the original invoice, and skip the approval step.

**What it teaches:** the right fix sits upstream of the visible difference, the correction path is constrained by policy, and success depends on the order of actions and the handover, not only on the final numbers.