Utility Billing to General Ledger Reconciliation
A billing-to-ledger reconciliation should show which source activity was accepted, posted, rejected or still in transit. Begin with a defined batch or period rather than two unrelated totals.
Utility Billing to General Ledger Reconciliation
Separate billing completion from financial posting completion. A source transaction may be valid while its downstream handoff remains unresolved.
Follow one transaction through the handoff between billing and finance. Identify the source reference, processing status, posting date and destination. Then test a cancellation or adjustment as a separate scenario. The original transaction and its later changes should remain understandable as a connected history rather than a collection of unrelated totals.
A practical first pass
- Identify the source population and totals.
- Match financial references and statuses.
- Investigate missing or repeated items individually.
Distinguish a timing difference from a lost transaction. A source batch may be complete while the financial interface is still processing, or an item may have been rejected and require action. Save the relevant timestamps and statuses before rerunning anything. Reprocessing without understanding the previous outcome can create duplicates or make the investigation harder.
A hypothetical example
A batch can balance internally but contain a rejected posting that never reaches the ledger. The reconciliation should expose the rejected item rather than treating the source total as proof of completion.
Test the process using representative customer situations rather than only an ordinary bill. A move, a corrected reading, a reversed charge and an unmatched payment can expose different handoffs. Confirm the expected business outcome with the responsible owners before testing the software. Available functions and detailed behavior must be checked in the specific billing environment.
Avoid the common shortcut
Do not rerun an entire batch before checking whether part of it has already posted.
Keep customer-facing facts separate from financial assumptions. Meter readings, service dates, account relationships and approved charge rules each have their own owner. A billing review should identify which fact is being questioned before selecting a correction. Do not ask a finance user to infer technical meter circumstances from an amount alone.
Keep the wider process connected
Design reprocessing before the first failure occurs. The team should know how to determine whether a record was never received, rejected before posting or partly processed. Those states may require different actions. Preserve source identifiers and processing references so a retry can be evaluated without guessing whether it will duplicate an earlier result.
Validate relationships as well as individual fields. A code can be valid on its own but inconsistent with the company, service, location or project to which it is assigned. Test those combinations using representative records. A list of technically valid values is not enough to establish that the business relationships are correct.
Keep emergency access temporary, attributable and reviewed. Record why it was needed, which activity was performed and who checked the result. The exact mechanism depends on the organization's security design. The business process should not allow a temporary exception to become an unexplained permanent entitlement.
What to take away
Keep a batch-level reconciliation with accepted, pending and rejected items clearly separated.
Related reading
Utility Billing Adjustments: Keeping the Customer Story Clear; Utility Billing Exception Dashboards; Move-In and Move-Out Billing Handoffs.