Case study · Energy & utilities · Payment operations
A top 5 utility providerReconciliation automation
One of the five largest utility providers in the country is moving its payment operations onto a new platform. We advise the implementation as payments specialists: we answer the reconciliation questions, design the matching rules, and find the edge cases that show up at national scale.
Stack
Django
React
Trigger.dev
PostgreSQL
Datadog
OpenAI
Anthropic'%20fill-rule='nonzero'/%3e%3c/svg%3e)
GeminiThe problem
A top 5 utility takes payments from millions of customers, across multiple billing systems and every payment method, and the bank activity has to reconcile to the penny.
The utility is moving this onto a new payment operations platform. Standing up the platform is the easy part. The hard part is the long tail: partial payments, returns, timing gaps, bank fees, and deciding which rules govern what matches what. Get those wrong and reconciliation leaks exceptions from day one.
At national scale, the edge cases are most of the work.
This is specialist implementation work: we know how payment reconciliation behaves in production, and we design for it before go-live.
Our role
We advise the implementation as payments specialists and work the questions that decide whether reconciliation closes.
Reconciliation coverage
We map which records reconcile against which sources (billing, remittance, and bank activity) and define what "matched" means for each.
Rule design
We advise which matching rules make sense, how to build them on the platform, and where to set tolerances for timing gaps and partial amounts.
Edge case identification
We find the transactions that break clean matching (returns, fees, partial payments) and define how each is handled before it reaches production.
How the advisory works
We build the advisory around how the utility's money moves, so the rules match real transaction behavior rather than a generic playbook.
Phase 01
Understand the flows
Trace how payments, returns, and bank activity move for each line of business.
Phase 02
Design the rules
Answer the implementation questions: which reconciliation rules make sense, and how to build them on the platform.
Phase 03
Work the edge cases
Identify the transactions that won't match cleanly and define how each one is handled before go-live.
Outcomes
What the advisory changes before go-live.
Reconciliation that closes
Rules tuned to real transaction behavior clear everything that ties out, so the finance team spends its time on genuine exceptions instead of matching line by line.
Fewer surprises at go-live
We resolve edge cases during design and write down the reasoning, so they don't surface in production after launch.