From Utility Bill to Reconciled Payment: A Connected Municipal Revenue Workflow

A utility payment is complete only when it reaches the correct account and can be reconciled to the municipality's revenue records. A successful online transaction alone does not explain whether the receipt has been matched, posted or included in the daily close.

A connected workflow preserves that distinction. Residents have clear bills and accessible payment options, while staff have visibility into receipts, processing status and exceptions. PCL One's proposed approach brings resident-facing services and financial controls together through configured workflows and agreed integrations.

Clear bills and traceable delivery

The bill is the starting point for both payment and account enquiries. English and French templates, applied according to the customer's language preference, help residents understand their charges. Itemized rates, consumption, meter details and service-location identifiers give each bill an explanation that staff can trace back to the account.

Configurable layouts can include consumption charts and approved messages alongside the charge breakdown. Those messages may explain a billing change or provide a relevant service update. For customers with several utility accounts, a parent-child relationship can organize account access while retaining each location's identity.

Electronic delivery needs a recorded outcome. A bill made available online, a notification sent and a notification returned as undeliverable are different events. Delivery tracking supports resending or follow-up, while batch printing and mailing remain part of the workflow for residents who receive paper bills.

Connected resident access

A resident portal connects the customer to current e-bills, historical bills, water consumption information, consumption alerts and online payment options. Integration with Silverblaze or a similar service needs an agreed account relationship and a clear definition of which information moves between the portal and the billing system.

Payment status requires particular care. A processor may confirm that a transaction was accepted before the receipt reaches the billing account. The portal and staff view need to distinguish that acknowledgement from account posting, using the timing and status information supported by the chosen interfaces.

This shared account context helps staff answer a resident's question without searching separately through a portal, a payment file and an account ledger. Access controls and account associations also need to keep each customer's information within the intended permissions.

Multiple payment channels, one account record

Residents may pay through preauthorized debit or card arrangements, online banking, third-party services, or cash and cheque at the counter. Each route has its own identifiers and processing schedule, but every receipt needs to reach the intended account with its source and reference preserved.

Preauthorized payment runs can follow document due dates or an approved on-demand process. Where Moneris is the municipality's card merchant, compatibility and transaction handling form part of integration design. Payment imports from Telpay and Service New Brunswick similarly depend on the available interfaces and agreed data mappings.

Online banking receipts may arrive as electronic funds transfer files, while counter receipts originate in staff-operated workflows. The implementation defines how each channel updates customer balances and accounting records, including the real-time updates required for in-person cash and cheque payments.

Payment matching and visible exceptions

Batch and API imports need matching rules that connect incoming receipts to customer accounts. Account number, name and address may be available as matching information, but the design needs to establish their priority and how ambiguous results are handled. A possible match is not sufficient grounds to allocate money to an uncertain account.

Unmatched receipts belong in a review queue with the original reference, amount, channel and processing result. Staff can resolve an incomplete identifier without losing the source record. Controls around repeated imports also help prevent a payment from being applied twice when a file is retried.

Declined and returned payments follow a different path. The workflow flags the failure and reverses the affected entry where applicable, preserving its relationship to the original receipt. NSF fees follow approved rules by account type. The account history then explains both the unsuccessful payment and any resulting balance or fee.

Daily revenue reconciliation

Daily reconciliation connects channel totals, applied receipts and the corresponding accounting entries. Utility payment types need defined general ledger mappings so a correctly matched customer payment also reaches the correct financial code.

Batch totals and exception reports provide a basis for closing daily revenue activity. Differences remain identifiable, with an owner and a recorded resolution. Where settlement arrives later than the receipt, the reconciliation distinguishes the timing difference from missing or incorrectly posted revenue.

This creates a traceable path from the source payment through the customer account to the revenue batch, supporting both daily balancing and later account enquiries.

An illustrative payment journey

A resident receives an English or French bill and pays through a third-party channel. The incoming payment record carries a valid account reference, allowing the configured matching process to identify the account and apply the receipt.

The account records the amount, source and processing status. Finance staff reconcile the receipt within the daily revenue batch, using the agreed ledger mapping and settlement information. If the reference cannot be matched, the receipt stays visible for review rather than being allocated to a guessed account.

This illustrative workflow shows how resident convenience and financial control connect. It describes the intended process rather than a customer case study.

How PCL One connects the revenue workflow

PCL One's implementation approach brings bill presentation, resident access, payment interfaces and reconciliation into one process design. Responsibilities are agreed across the municipality, portal provider, payment services and financial system, with explicit mappings, processing schedules and exception ownership.

Validation covers successful payments and the cases that interrupt them: bounced notifications, unmatched references, duplicate imports, declined transactions and returned payments. The result is a proposed workflow in which staff can follow the account history and explain how each receipt contributes to the daily revenue position.