Why an energy company portal goes down at peak payments and data collection
An energy company portal rarely goes down on a quiet Tuesday — it goes down in the last three or four days of the billing period.
At that moment, three streams converge: customers mass-submit readings, payments flow in, and legal entities close reconciliations and request documents. Each stream is tolerable on its own; together they create a load that ordinary architecture was not designed for.
The root of the problem is not the web server, but the integration bottleneck with the metering system. The exchange is built on synchronous requests: until billing responds for an account, the portal holds the connection and waits.
At peak, the request queue grows faster than it is processed, some calls time out, and externally it looks like a "payment failure" — money debited, but the receipt is not generated.
The same happens with readings: meters and operators send them in batches, and reading collection chokes on retries.
The cost of such peak load is measured not only in downtime. Operators manually recheck stuck payments, reconcile duplicates, and restore discrepancies in charges — and this stretches for days after the peak.
A separate pain point: some operations simply cannot be replayed, because there is no idempotency and no clear log showing where the transaction broke off.
Below we examine how this is addressed: where exactly the failure boundary lies, what asynchronous processing of payments and data collection provides, and why the customer portal must remain responsive even when exchange with the metering system lags.
What a unified circuit provides: speed of settlements and fewer manual operations
The point of a unified circuit is that metering device telemetry, charges, and the customer portal operate on one data model rather than exchanging scheduled exports. A discrepancy is visible at the moment data is received, not a week later in a customer request. The three effects below are measured in operation, not in an implementation report.
Billing period closing time
The period closes when readings, charges, and payment allocation reconcile without manual spreadsheets.
Automation of reading collection follows a procedure with a log for each load: missing intervals, duplicates, and out-of-profile bounds are flagged immediately, and reconciliation with the metering system is performed before charging, not after.
In practice, this compresses closing from several days of manual reconciliation to a single pass, and issues are resolved selectively by flagged records.
According to International Energy Agency (iea.org), digitalization of metering and settlements is a sustained industry practice, not an isolated case.
Share of operations without manual intervention
Reading intake, normative recalculations, invoice generation, delivery to the customer portal, and payment acceptance follow one route, and operator intervention remains only for anomalies.
Each operation is logged with its author — human or rule — so it is visible where the share of manual actions is still high.
Usually after stabilization, about a tenth of operations remain for manual review, and these are exactly the cases where a human is needed: disputed consumption, change of owner, splitting of an account.
Failures that stop reaching the user
The class of failures the circuit eliminates is desynchronization between metering and billing.
Repeated loading of intervals is idempotent: the same batch does not create a second charge, a lost interval is raised from the retry queue, and a discrepancy between systems is detected by reconciliation before invoicing.
As a result, the customer does not receive a double amount and a correction a month later — disputed cases go to an engineer, not to support.
Options for connecting the customer portal to the metering system
The customer portal does not store primary data — it receives it from the metering system: ASKUE, billing, settlement module. The connection scheme is chosen based on the state of the metering circuit and exchange procedures, not development convenience. Below are four schemes and their integration limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection | Circuit is open, metering system interface is stable, request flow is predictable | Tight coupling: a change in the metering system breaks the portal; constant access to the production circuit is required |
| Data exchange gateway | Online readings and events are needed, circuits are isolated | Separate service to maintain: queues, retries, desynchronization control |
| Batch registry export | Charges and reconciliations once a day or month, large volumes | Data delay, no reaction to events, discrepancies are resolved after the fact |
| Hybrid scheme | Some data is needed online, some on a scheduled basis | More expensive to debug: two channels, shared reconciliation logic, and source priority |
When direct exchange is justified
Direct connection is used when the metering system provides data via a documented interface, and access between the portal and the metering circuit is agreed upon.
The gain is a minimum of intermediate links: readings arrive with seconds of delay, and discrepancies are visible at the source without reconciling two repositories.
When an intermediate layer is needed
A data exchange gateway is needed if the production circuit is isolated or meters cannot be polled directly.
The gateway handles scheduled polling, buffering during communication loss, and resending — the portal receives a steady stream and does not depend on the unavailability of an individual metering node.
Batch registry export remains for reconciliations and charges, while the hybrid scheme combines both channels with priority for online data.
Work stages: from survey to handover to operation
Work proceeds sequentially: each stage relies on the agreed result of the previous one, so data discrepancies surface at the beginning, not at acceptance. The energy company portal is built the same way — with metering, payment, and customer portal.
- Survey of the metering system (ASKUE) and related services: composition of points, reading collection procedure, user roles, current exports.
- Integration scheme: we fix data sources, exchange frequency, and system behavior when communication with a metering node is lost.
- Exchange setup: we connect metering data to the customer portal, verify formats, and map reference data.
Validation on historical data
- Run on accumulated readings for past periods: we verify amounts, discrepancies by point, and correctness of recalculation. Acceptance checks follow an agreed scenario — including communication outages and repeated data loading.
Training for dispatchers and operators
- We show the services how to resolve disputed readings and what to do when there is a discrepancy with a metering device.
- Handover to operation: procedures, accesses, incident log, and support during the first weeks of operation.
"The exchange scheme was agreed before development — by the setup stage there was nothing left to argue about," notes the technical project lead on the customer side.
This order keeps the acceptance timeline predictable: disputed points are closed before handover to operation.
Handover of the energy company portal: schemes, procedures, instructions
Handover of an energy company portal is not an archive with source code, but a working documentation set that your team can use to develop the customer portal and integrations with the metering system without us.
We assemble it so that the answer to a work question can be found in minutes, not reconstructed from code.
- Data flow scheme: from the metering device to the figure in the customer portal — with storage points and exchange procedures.
- Access matrix: roles of employees and contractors, scope of visible data, permitted operations.
- Reconciliation procedure: how readings are matched and in what order discrepancies are resolved.
- Operator instructions: handling requests, adjusting charges, working with debt.
- Recovery plan: backup and procedure after a failure.
Role and access rights matrix
The matrix is built on the principle of least privilege: a role receives only the data and actions it needs according to procedure.
Administrator, operator, accountant, and external contractor are described separately — including what changes when an employee leaves or the organization changes.
Reconciliation and discrepancy resolution procedure
Here it is fixed how often readings are reconciled, who is responsible for each stage, and what to do if data in the portal and the metering system diverge.
The escalation procedure is described separately — from operator to integration owner, with the cause of the discrepancy recorded.
| Artifact | Purpose | Who uses it |
|---|---|---|
| Data flow scheme | Understand where the figure in the portal comes from | Engineers, analysts |
| Access matrix | Grant and revoke rights | Administrators, security service |
| Reconciliation procedure | Close reading discrepancies | Operators, accounting |
| Operator instructions | Train new employees | Support manager |
Case: billing circuit for 42 thousand accounts
An energy company with 42 thousand customer accounts closed the billing period manually: readings were taken from ASKUE, reconciled with billing in spreadsheets, and transferred to the database by row-by-row import.
The period stretched to four days, each closing involved 300–400 manual edits, and charges went out to customers late — half of support requests were about "why did the amount change."
We built a unified billing circuit: readings come directly from the metering system, charging and recalculation rules are described declaratively and run on a test set of accounts before production launch.
The customer portal calculates by the same rules as the operator — the customer sees the same amount with a breakdown for each service, so the dispute is resolved before the call.
What measurements showed after launch
Period closing time dropped from four days to several hours, the share of automatic charges rose from 62% to 99.4% — only disputed readings based on a customer request remain manual.
Support requests about charges fell by 2.7 times, and in the first days after closing — almost fourfold.
Service availability on peak days (the 1st and 10th, when load is several times above average) stays at 99.9%: the billing circuit is separated, heavy recalculations are queued and do not block the customer portal.
What to do if the metering system is already deployed and cannot be changed
We do not touch the existing metering system: the portal is built alongside it, and an intermediate exchange layer provides communication between them.
It takes data on meters, charges, and payments in the form provided by the metering circuit, brings it to a unified model, and passes it to the customer portal. No modification of the metering system itself is required — neither in the data schema nor in vendor updates.
The layer consists of two adapters and a canonical model between them. The input adapter reads exports and uses standard access methods already open in the metering system; the output adapter delivers data to the portal.
Each operation gets an identifier: repeated delivery does not create duplicates, and the exchange log records what arrived and when — a discrepancy is resolved by a specific record, not the entire dataset.
Connection proceeds in groups of customers, not as a single switchover. The first group is a small circuit where readings, charges, and receipts are reconciled; if there are no discrepancies, the next group is connected using the same template.
This order allows a group to be disconnected and returned to the previous scheme without stopping service for the others.
As a result, the metering circuit remains under the responsibility of its owners and receives updates on its own schedule, while the portal develops independently of it.
Our engineers describe the exchange model, reconciliation rules, and discrepancy resolution procedure — the support team works from the document, not from a specific developer's memory.
We separately clarify which export and access methods the existing system already provides: the layer scheme and group order depend on this. Describe the task — we will return with an estimate and a phased connection plan.
FAQ on integration, payment, and access separation
Questions at acceptance are almost always the same: who sees what, how payments reconcile, what the portal will show if a meter goes silent, whether it can withstand the billing peak, and what happens after system handover.
Below are short answers to the point, without general wording. If your case is not covered, we will discuss it separately on a call.
How is access separated between roles?
We describe roles as a set of permissions at the service level, not as button visibility: a dispatcher works with meters in their area, accounting — only with payment reconciliation, a contractor — with requests.
The check is duplicated on the server, so a direct request bypassing the interface does not circumvent the restrictions. Every action is logged with the user and time.
How does payment reconciliation work?
A receipt is automatically matched to the account and period; discrepancies with the bank export go to a manual review queue. Reprocessing is idempotent — a duplicate will not create a second charge.
What happens when communication with a meter is lost?
The last reliable reading is saved with a timestamp rather than replaced with zero. A pause longer than a set threshold raises an event for the dispatcher; when communication is restored, data is loaded from the meter's buffer.
Can the portal withstand peak load?
We compute heavy consumption queries separately from interface delivery and cache them; we separately measure peak scenarios such as mass payment at the end of the period. Scaling is done by adding nodes, without rewriting logic.
What does post-launch support include?
On-call response to requests with a reaction procedure, incident analysis, scheduled dependency updates. We keep a change log from day one — rollback to the previous state remains predictable.
Let's discuss the task: what to send for an estimate and work plan
Project estimation accelerates exactly as much as the input data set is complete. Below is a list of what to send before the discussion: from it we calculate the scope of work and assemble a plan, rather than clarifying basic things a week into correspondence.
- Service composition and launch priority. Customer portal, payment, reading submission, integration with the metering system — what is needed in the first phase and what can wait.
- Metering scheme and data sources. Types of meters, reading collection frequency, where the archive is stored and how it is replenished.
- User roles and access rights. Customer, legal entity, operator, inspector: who sees, changes, and confirms what.
- Regulator requirements. Mandatory reports and exports, their deadlines, who is responsible for data accuracy.
- Related systems and exchange formats. Billing, payment provider, metering, reference data — what each system provides and accepts.
- Accesses and test environment. Anonymized data set, personal data restrictions, environment for checking integrations.
- Project scope. Timelines, expected volume, who manages the task on the customer side and accepts the result.
The discussion procedure is simple: we review what you send, ask questions about unclear points, and align priorities. Then we return with a project estimate, work plan, and team composition for your circuit. Describe the task — that is enough to begin.
