AI optimization of utility tariffs: where manual calculation breaks down
Manual calculation of charges rests on a bundle of spreadsheets, exports, and people who remember “how it should be done.” The first thing that breaks as volume grows is inconsistency in reference data: the tariff grid, standards, area, and number of residents live in different files, are updated at different times, and enter the calculation in different versions.
The same apartment gets a different amount depending on which file was plugged into the formula, and the cause has to be found by manual reconciliation.
The second failure is period fragmentation and retroactive recalculation. A change of owner, benefit recipient status, meter verification, or tariff revision forces past months to be recalculated, and each case lives as a separate line in someone else’s memory.
While changes are made manually, some are lost, and the discrepancy surfaces in the bill — with a complaint and a repeated investigation.
This is how the calculation loop becomes a bottleneck: month-end closing drags on, and any reconciliation requires an export and blind comparison. Specialists spend time not on analyzing the tariff model but on finding where the data diverged.
AI optimization of utility tariffs removes this load differently: reference data is consolidated into a single source, calculation follows formalized rules, and recalculation is launched automatically to the required depth. Let’s break down how such a loop is structured.
Measurable effects of implementing the calculation model
The time to prepare a tariff scenario is reduced from several days of manual runs to one working session: the model calculates grid variants in parallel, while the engineer reviews ready-made branches — decrease, increase, and transition period.
Intermediate exports are no longer collected manually: the calculation period is pulled from the accounting system, standards from the reference data, and inconsistencies are highlighted before launch.
The share of manual edits in a prepared scenario drops to isolated cases. The bulk is covered by validation rules: permissible value ranges, growth limits by consumer category, mandatory validity periods.
Manual editing remains only where there is a legal exception or a regional authority decision — and every such deviation is logged with justification.
A separate class of failures disappears — desynchronization between the tariff case version and the calculation period.
Release is blocked if control sums for personal accounts do not match the reference, and recalculation itself is idempotent: a repeated run does not double charges.
The volume of repeated recalculations falls due to the delta — only accounts affected by the tariff or standard change are recalculated.
Charge accuracy is checked on a reference sample before publication, and the discrepancy with the control calculation is driven to zero.
The model works on top of the current accounting system without requiring replacement: tariff cases, reference data, and personal accounts remain in the familiar loop; only the layer for preparing and verifying the calculation changes.
Ready-made platform, in-house AI model, or hybrid
None of the three paths wins “in general” — the choice is determined by how much your tariff logic differs from the standard one and whether you are ready to maintain the model on your own.
Standard solutions bring calculation into operation faster, but their rules can be adjusted only within the built-in settings. An in-house model removes these limits, but it requires a history of charges and ongoing monitoring of forecast accuracy.
A practical criterion: we calculate the share of buildings where standard rules reproduce your tariff without manual edits. If it is high, a ready-made platform is sufficient.
If the calculation relies on dozens of local coefficients, seasonal recalculations, and benefits, moving your rules into an in-house model becomes mandatory.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made platform | Tariff logic is close to standard, fast launch is needed | Non-standard rules are maintained outside the system, part of the calculation remains manual |
| In-house calculation model | Many local rules, full control over logic is needed | A history of charges and payments is required, accuracy is checked with every edit |
| Hybrid approach | Standard calculation framework plus your own rules on top | Two loops must be synchronized, maintenance is more complex |
In any option, we fix the rules as verifiable formulas and compare the result with current charges over historical periods — before the calculation goes into operation.
How we implement: stages of engineering work
The tariff model in utilities is multi-level: consumption groups, standards, benefits, seasonal recalculations, and manual adjustments. An error in charging rules is more costly than an inaccurate forecast, so we start with data and finish with acceptance on real periods.
- Data audit. We consolidate archives of charges, payments, and requests over several years, looking for gaps, duplicates, and traces of manual edits. The output is a source map and a list of data that cannot be used without rework.
- Calculation scheme design. We fix which indicators affect the tariff and how they are related, where sensitivity limits are needed. We agree on the scheme with economists before the first line of code.
- Rule setup. Benefits, thresholds, and exceptions are described explicitly, with change history: editing one rule does not break neighboring calculations and remains visible.
- Validation on historical data. We run the system on closed periods and compare it with actual charges. Every discrepancy is investigated to its cause rather than smoothed with an average.
- Parallel run. The system calculates alongside the current process, and results are compared line by line. This shows behavior on non-standard cases — recalculations and disputed charges.
- Handover to operation. We provide regulations, calculation logs, and rollback procedure, train specialists, and assign owners for the rules.
After that, maintenance proceeds by metrics: share of discrepancies, number of manual edits, period recalculation time. We see an out-of-corridor deviation earlier than the subscriber notices it.
Project artifacts: regulations, schemes, access
A utility tariff optimization solution lives longer than the project: grids change, standards are revised, and reference data is replenished with new objects.
Therefore, along with the calculation loop, we hand over a set of documents that your maintenance team can use to run the system independently — without contacting us for every change.
- Calculation scheme — the path from charges and standards to the final tariff: steps, intermediate values, correctness control points.
- Reference data maintenance rules — who adds services, consumer categories, and standards, which fields are mandatory, which checks run before saving.
- Access control — role matrix: operator, analyst, reference data administrator; rights are granted on a least-privilege basis, changes are logged.
- Update regulation — frequency of model rebuilds when tariff policy changes and the rollback point to the previous calculation version.
- Operations documentation — instructions for the duty shift: typical failures, actions when a result diverges from the reference, escalation procedure.
- Integration scheme — exchange with billing and accounting systems: formats, frequency, behavior when the source is unavailable.
- Verification scenarios — a set of reference calculations that show, after any change, that the model calculates the same way.
We hand over the documents together with maintenance training and a walkthrough of reference calculations — the team accepts the system already knowing how to run it.
Case study: recalculating charges for a regional operator
The pilot was launched on the operating loop of a regional operator: 1.2 million personal accounts, more than forty tariff zones, and benefit categories — each with its own application procedure.
Recalculation proceeded in waves: specialists exported periods, manually reconciled tariffs and benefits, and uploaded the result back.
Before implementation
One recalculation wave took five working days, and about 3% of charges went to manual reconciliation: discrepancies in benefit grounds, doubled recalculations, items with expired validity.
Recalculation inquiries to the subscriber department held at about 1,800 per month — and a noticeable share of them resulted not from a tariff error but from desynchronization of reference data between systems.
What we changed and what we got
The charge history and reference data were consolidated into a single storage (ClickHouse), and tariff rules were fixed in a declarative configuration instead of calculator code.
The model labels an item based on past periods, consumption profile, and the current benefit ground; disputed cases go to the operator queue — about 4% of the volume, the rest is closed automatically.
Before the production run, the system was compared with manual calculation on a retrospective of 12 closed periods.
The recalculation cycle was reduced to a nightly run with morning confirmation — one working day instead of five.
The share of discrepancies reaching the personal account fell to 0.4%, and recalculation inquiries fell by about two-thirds: a disputed item is intercepted before the bill is generated.
The model does not set the tariff. The decision on a disputed charge is made by a specialist; the system only prepares an evidence set: period, ground, calculation, and reason for triggering.
How does automatic calculation differ from manual recalculation?
Automatic calculation is built on primary data — meter readings, personal account registers, exports from ГИС ЖКХ — and applies charging rules without manual input.
Each run saves the input set, rule version, and result, so any amount in a bill can be broken down to the source line. An error in a rule is fixed once and recalculates the entire period.
Manual recalculation starts from an export into spreadsheets and a specialist who edits formulas in place. This is how one-off disputed periods and non-standard situations for which a rule has not yet been formulated are closed.
The price is result verifiability: a month later it is no longer possible to reconstruct why exactly this value is in the line, and each edit lives in a separate file. Comparison of operating modes by typical tasks:
| Task | Operating mode | Limitations |
|---|---|---|
| Mass charging for a period | automatic calculation | verified reference data and rules are required |
| Handling an inquiry about a bill line | automatic, with tracing | depends on saved run history |
| Disputed period with a non-standard rule | manual recalculation | does not carry over to the next period |
| Reconciliation with supplier data | automatic | limited by the exchange format |
| Recalculation when the tariff changes | automatic | a rule version with an effective date is required |
Calculation maintenance is the main difference. In automatic mode, a new rule is changed in one place and applied to the entire database; in manual mode, the same edit is replicated across files, and the amount of work grows with the number of personal accounts.
Common technical doubts and answers
Objections to AI tariff optimization are usually the same: there is not enough historical data, grids change every season, the current charging system must not be touched, it is unclear how to accept the work and who cleans the reference data.
Each is closed by an architectural decision, not by a promise that “the model will figure it out itself.”
Is there enough historical data?
Two full seasons and an off-season are enough to separate seasonality from anomalies. If less, we start on rules and statistics by building groups, and connect the model as data accumulates. Quality is measured on a held-out period that was not involved in setup.
What should we do if tariff grids change every season?
The grid is not hard-coded into the model but stored in a version reference. When it changes, history is recalculated, the forecast is rebuilt, and the grid version is stored next to the result — the calculation remains reproducible.
Can we work on top of the current system?
Yes. Exchange is done via exports, calculation runs in parallel and does not affect charges. The current system remains the source of truth, and rollback comes down to disabling the exchange.
How are acceptance criteria formulated?
We agree before the start: the share of forecasts within a specified deviation corridor, reproducibility on a held-out period, response time to a grid change. Plus a shadow run against actual charges.
Who is responsible for reference data quality?
The source reference data is the customer’s responsibility, but before the model we perform profiling: a report on gaps, duplicates, and discrepancies, and normalization rules. Without clean reference data, the result is unreliable, so this is the first stage.
Let’s discuss the task: what to send for assessment
To make the assessment accurate, engineers need inputs about how the tariff is calculated now. A general description of the task is suitable for the first conversation, but the work plan and scope of the trial launch are assembled from actual data. The more specific the source data, the fewer clarification rounds before a working assessment.
- An export of charges, payments, and adjustments for one or two calculation periods — as spreadsheets or read access to the charging system.
- Current calculation rules: zones, standards, coefficients, benefits, recalculation procedure.
- A diagram of accounting systems — where readings come from and where the calculation result is returned.
- Regulator constraints and internal regulations: what cannot be changed, which cap indices are mandatory.
- Examples of disputed charges and manual edits — they show where the rules are ambiguous.
- Target metrics: share of automatic calculations, recalculation time, permissible error.
- Owners on both sides: who confirms the calculation rules and accepts the result.
The discussion procedure is simple: we review the inputs and clarify what data is missing, fix the work plan with stages and checkpoints, then agree on the scope of the trial launch — a limited set of rules and one calculation period on real data with pre-described acceptance criteria. Describe the task — we will come back with an assessment and a plan.
