A customer pays on Monday. On Tuesday, a disconnection-related message still goes out because the payment update has not reached the collections system.
For a utility buyer, that is a more revealing scenario than a polished product tour.
Utility collections software helps manage overdue accounts, customer conversations, payment arrangements, and approved follow-up. Choosing it means checking whether the platform can work reliably with your customer information system, enforce your service-area rules, and leave a record your team can explain.
This guide is for utility revenue leaders, customer-service teams, IT, security, and procurement comparing vendors or preparing a pilot. It focuses on purchasing evidence. For the operating model, read AI Collections for Utilities: Connect Billing to Recovery. For the economics of high-volume arrears, see AI-Powered Small-Balance Utility Debt Collection.
Start with the boundaries of the deployment
Before a vendor prices the project, define the utility services, territories, customer classes, channels, and actions in scope. Residential electricity, commercial water, and municipal sewer accounts do not automatically share the same rules.
Name the owners of billing corrections, assistance reviews, arrangement approvals, and service-status decisions. Put the division of responsibility in the proposal and implementation plan.
A useful shortlist distinguishes between available now, configuration required, integration work required, and not supported. “We can do that” needs a delivery owner, a test, and a date.
Compare vendors without averaging away a critical failure
Treat accurate account handling, applicable service safeguards, and accepted security evidence as mandatory gates. Mark each pass, fail, or unverified, with a reviewer and an evidence reference. A promise to deliver later stays unverified until tested; a critical failed control blocks expansion.
After the gates pass, score the remaining fit from 0 to 3: 0 unsupported, 1 claimed or planned, 2 demonstrated with representative records and documentation, 3 validated against your agreed pilot criteria or accepted evidence requirements.
One illustrative weighting is billing and integration 25%, assistance, arrangements, and service safeguards 25%, security 20%, staff usability and support 15%, and economics 15%. Calculate each category as its score divided by 3, multiplied by its weight, then add the results for a score out of 100. Agree the weights before comparing vendors.
Keep roadmapped features separate from the launch scope. A high weighted score cannot compensate for a failed mandatory gate.
1. Billing synchronization: test the balance before the conversation
Your customer information system (CIS) may hold the account, premises, service agreements, bills, adjustments, and posted payments. Decide which system is authoritative for each record. A customer ID alone may not distinguish two properties or two service accounts.
Ask the vendor to follow a single account through a bill correction, partial payment, return, and transfer of service. Watch both the balance and the next scheduled action.
| Integration check | Evidence to request |
|---|---|
| Correct account matching | Customer, service-account, premises, and transaction IDs mapped to your actual data model |
| Balance updates | Treatment of new charges, credits, adjustments, partial payments, and reversals |
| Freshness | Agreed maximum data age for each action, with visible sync status |
| Duplicate or late updates | Retry handling, duplicate protection, and prevention of older records overwriting newer ones |
| Failed synchronization | Alert, assigned owner, and hold behavior for affected actions |
| Approved writeback | Field-level permissions, acknowledgement, and a queue for rejected updates |
An integration can succeed technically while leaving the wrong operating state. “File received” is not proof that every payment has been applied or every hold enforced.
Keep payment initiation, confirmed transaction outcome, posting, and reconciliation distinct. A pledge is not received cash. An initiated payment can fail. A received payment can be waiting for allocation.
For queued outreach, define when the system rechecks the balance and account restrictions. Demonstrate a payment or hold arriving immediately before a scheduled send. If the required data is stale or unavailable, the agreed behavior should prevent affected actions from proceeding on an assumed account state.
2. Assistance referrals: track the next step without promising approval
A customer who says “I need help paying” needs an approved assistance path. A generic link is only the beginning.
USAGov explains that LIHEAP can help with heating or cooling bills and certain energy crises, with eligibility requirements that vary by state and territory. Do not treat it as a universal water-assistance program or promise an award.
Ask the vendor to demonstrate how the workflow records a referral, assigns follow-up, and distinguishes an application from an approved benefit or received payment.
Useful account states include referred, application pending, decision received, pledge recorded, and funds posted, where those states match your program. Each needs an owner and an appropriate next action.
Agree how assistance information enters the platform: staff entry, an authorized partner update, or an integration. Collect only the information necessary for the workflow. Sensitive eligibility documents should follow your approved access and retention rules.
A pending request should trigger the hold or review required by your applicable policy. Neither a referral nor an AI interpretation should silently create, release, or extend a protection outside those rules.
3. Payment arrangements: inspect the agreement after the offer
A plan is useful only if the system can keep it accurate as new bills arrive.
Test whether the workflow distinguishes arrears installments from current charges. Confirm how it handles down payments, allocation order, due dates, grace periods, partial installments, and a returned payment. A payment applied to the wrong obligation can make a customer appear to have broken an arrangement they were trying to keep.
The demonstration should cover the agreement itself: approved terms, customer acceptance, schedule, required notices, version history, and any payment authorization. Accepting an arrangement should not be treated as blanket permission for every future debit.
| Arrangement scenario | What to inspect |
|---|---|
| Customer requests standard terms | Eligibility check, approved offer, acceptance record, and accurate schedule |
| Customer requests longer terms | Staff approval path with no implied acceptance |
| New bill arrives during the plan | Current charges and arrears tracked according to your policy |
| Installment is partial or returned | Correct allocation, status, and approved review path |
| Staff changes the agreement | Versioned terms, notice requirements, and authorized update |
| Plan appears broken | Defined review and next steps; no automatic assumption that disconnection is permitted |
Ask the staff member who manages arrangements to test the screen. If they need a spreadsheet to understand what is due next, include that remaining work in the business case.
4. Disconnection controls: separate collection activity from service authority
A high recovery score is not permission to disconnect service.
USAGov notes that electricity and natural-gas disconnection policies differ by state and may depend on weather, customer circumstances, and the provider. Use that government resource to locate the relevant state policy, then confirm the applicable tariff, regulator rules, and provider-specific requirements with your compliance owner.
Build a requirements matrix for each service area. Have the authorized compliance owner approve the rules and their effective dates. Include notice requirements, disputes, assistance pledges, medical or other protected-status handling, active arrangements, and emergency restrictions where applicable.
Alongside service restrictions, map the applicable channel requirements: consent or other permission, identity checks before account disclosure, approved notices, contact timing, opt-outs, and complaint handling. Test a revoked channel permission while a message is queued. Compliance should confirm which requirements apply to each service, customer class, channel, and collecting party.
Evaluate permission to contact, permission to issue a notice, and permission to request or execute a service action separately. A pause on disconnection does not necessarily mean every communication must stop; the rule should specify what remains allowed.
Require the vendor to show:
- A deterministic permission check outside the model's free-text response.
- Restricted service-action permissions, with approvals where your policy requires them.
- A final check against current balances, holds, and applicable rules before an authorized service request.
- An audit record of the input state, rule version, decision, approval, and downstream acknowledgement.
If the project is outreach-only, disable service-action access and test that boundary. If service actions are included, test cancellation, delayed acknowledgements, and a newly received payment before execution. Agree how a hold propagates to the authoritative service-order system; changing a flag in the collections tool alone may not cancel an existing order.
An AI agent can route a request. It should not invent a shutoff date, promise reconnection, or release a protected status because a customer message tells it to.
5. Security review: ask for evidence that covers your deployment
Customer contact details, payment references, account histories, and hardship information deserve a concrete security review.
Start with the data flow. Where does each type of data travel? Which parties can access it? What reaches the model provider, logs, support tools, backups, and payment environment?
The NIST Cybersecurity Framework provides a structure for managing cybersecurity risk. Use your security team's requirements to decide what evidence is sufficient for this deployment.
| Review area | Procurement evidence |
|---|---|
| Independent assurance | Current SOC 2 Type II report or other agreed assurance, including scope, period, exceptions, and remediation |
| Access | SSO/MFA support, role permissions, account removal, privileged access, and access-review records |
| Data isolation | Tenant-boundary design and tests covering APIs, search, exports, attachments, and support access |
| Encryption and secrets | In-transit and at-rest controls, key ownership, rotation, and integration credential handling |
| Model and subprocessors | Named providers, processing locations, retention, training-use terms, and change notification |
| Incident and recovery | Notification commitments, escalation contacts, restore-test results, and agreed recovery objectives |
| Retention and exit | Record-level retention, usable export, backup treatment, and deletion commitments |
The AICPA's illustrative SOC 2 Type II report includes the system description, auditor's report, tests, and results. Review the actual report and responsibilities relevant to your deployment. A logo or a cloud provider's assurance does not establish that every vendor application control is covered.
Keep card-data scope explicit. Identify where payment credentials are captured and processed, which systems receive tokens or references, and the evidence appropriate to each party's responsibility.
Test AI boundaries as well as infrastructure
Ask for account-grounded responses and tool permissions. A customer attachment must not be able to override a hold, expose another customer's records, or grant the agent new authority.
Test invented account facts, ambiguous replies, cross-account requests, and attempts to bypass an approval. Review how the vendor evaluates changes to models, prompts, rules, and integrations before release. Include rollback and a way to pause affected automation.
NIST's Generative AI Profile is a voluntary risk-management resource, not a certification that a vendor's utility workflow is compliant.
6. ROI: separate better recovery from cash that would have arrived anyway
“Recovered $500,000” is not yet a return-on-investment calculation.
Choose an opening eligible arrears cohort and a fixed measurement window. Track received cash applied to that cohort, with a documented treatment for returns, refunds, credits, write-offs, and assistance funding. Keep new current charges outside the denominator unless the agreed measure explicitly includes them.
Where practical, compare a randomized pilot group with a comparable control group receiving the existing process. Otherwise, use a matched baseline and explain differences in arrears age, balance, customer class, weather, billing cycles, and assistance activity.
A useful financial measure is:
Pilot net benefit = incremental cash recovery + verified operating savings − total incremental costs.
Treat cash acceleration separately from incremental recovery when the same customer would otherwise have paid later. Staff hours released become spending savings only when they reduce actual costs or have an agreed, measurable redeployment value.
A hypothetical pilot business case
Suppose both groups start with $500,000 of comparable eligible arrears. The pilot receives and applies $220,000 during the window; the control receives and applies $190,000. The observed difference is $30,000. For this example, assume the comparison supports attributing that difference to the pilot, with returns and refunds accounted for and assistance and seasonal differences checked. If attribution is not supported, the observed difference should not be presented as incremental recovery.
If verified operating savings are $4,000 and total incremental costs are $12,000, modeled net benefit is $22,000. Modeled pilot ROI is 183%, rounded from $22,000 divided by $12,000. This measures the assumed incremental cash benefit and operating savings against pilot costs; it is not a profit-margin calculation. These are hypothetical inputs, not a FinanceOps result, quote, or forecast.
Total costs should include implementation, integration, platform or recovery fees, communications, processing, monitoring, staff review, and any agreed allocation of one-time work. Read fee terms for externally received payments, assistance funds, reversals, and payments after termination.
Pair the financial result with kept arrangements, repeat contacts, complaint rates, billing-error resolution time, and unsupported or blocked service actions. A short-term cash increase does not excuse a failed customer-protection control.
7. Pilot acceptance: make the buying decision testable
Give each test an owner, expected result, evidence, and a pass/fail decision. Set quantitative thresholds with your team before launch.
| Acceptance test | Example condition for expansion |
|---|---|
| Billing accuracy | Sampled balances and allocations match the authoritative records; affected errors are resolved before outreach |
| Update timing | Payments and holds suppress affected queued actions within the agreed window |
| Assistance handling | Referral, review, pledge, and posting states remain distinct, with owner and next step |
| Arrangement integrity | Tested terms, allocations, acceptance, and changes match approved policy |
| Service safeguards | Every tested prohibited service action is blocked, including stale-data and changed-status cases |
| Security and AI boundaries | Required evidence accepted; unauthorized access and out-of-policy actions blocked in the agreed tests |
| Customer outcomes and economics | Defined recovery, customer-experience, workload, and cost thresholds met |
A concrete payment-update acceptance test
In a test environment, queue an overdue-balance message for ten minutes from now. At the start of the test, post a payment in the authoritative billing system that clears the full eligible overdue amount.
For illustration, agree a five-minute update threshold. The integration owner verifies that the collections platform acknowledges the payment and updated balance within five minutes. The operations owner confirms the queued overdue message is suppressed and no affected disconnection notice or service request proceeds on the old balance.
Retain the billing transaction ID, source and receipt timestamps, queue cancellation or suppression record, permission-check result, and final account state. Repeat the test with a delayed update: if freshness exceeds the agreed limit, the affected action must enter the configured hold or staff-review path.
A missing acknowledgement, stale balance, or failed suppression is a failed test for that workflow. Fix the cause and rerun it before expanding. The timing is an illustrative acceptance threshold, not a regulatory deadline or a FinanceOps performance commitment.
The checklist conditions are evaluation criteria. Passing the agreed tests supports the tested scope; it does not establish coverage of every possible case.
Start with limited eligible accounts and staffed exceptions. A shadow phase can check matching and decisions before customer outreach. Put sync expectations, incident response, policy-update ownership, support, fees, export, and termination in writing. Name who signs off across revenue operations, customer service, compliance, IT, and security.
How to evaluate FinanceOps against this checklist
FinanceOps supports utility servicing and collections under the provider's brand. Evaluate Autopilot for eligible automated work and Copilot for staff-assisted cases. Use Strategy Builder to review treatment paths, limits, and escalation rules.
Invoice workflows and Agentic Payments are relevant to the handoff between follow-up and account outcomes. Confirm the exact CIS connection, arrangement behavior, assistance data, and service-action scope in your proposed deployment.
Request the current documentation through FinanceOps' security and compliance overview, and compare the full proposal with FinanceOps pricing. Verify evidence and supported configurations instead of assuming a feature name answers a procurement requirement.
For a working session, bring a sample billing extract, your service-area rules, and one difficult account: for example, a partial payment with a pending assistance pledge and a queued notice. Ask to see the data updates, permitted next action, and audit record.
The right platform earns its place by handling those dependencies reliably. A better conversation matters. A correct, explainable account outcome is what your team has to stand behind.
