Regulated revenue in SAP: when the tariff comes from outside
In an ordinary industry, the price is yours. You set it, negotiate it, adjust it, discount it. The ERP records what was agreed and revenue is the sum of what was sold.
Energy does not work that way. The tariff comes from outside, defined by a ruling, with an effective date that does not line up with your calendar, and revised by a regulator that does not consult your IT roadmap. The system does not decide the price — it has to prove it applied the right one.
That inversion looks like a configuration detail and it is not. It changes what SAP has to store, changes what the close has to reconcile, and changes the nature of the error: instead of a wrong sale, you have a regulatory divergence, which has a deadline, a penalty and a history.
The four things that change
Validity is not a date, it is a range with retroactivity. A ruling published in May can apply from March. The system has to be able to recalculate what was already invoiced, generate the difference, and keep both figures — the one applied and the correct one — because the audit will ask for both.
Adjustments do not replace, they accumulate. Adjustment on top of adjustment, with different bases and components that move by different indices. A price field holding the current value does not tell that story. You need the series.
The unit of the business is not the unit of the system. Invoicing in megawatt-hours, metering at the consumption point, contracts in contracted demand, taxation per invoice line. Every conversion between them is an opportunity to round — and rounding at volume becomes a divergence of thousands at the close.
There is a third party in the relationship. Besides you and the customer there is the regulator — and sometimes the distributor, the system operator and the trading chamber. Each expects a file, in a format, by a deadline. Those deadlines are not negotiable and almost never coincide with your accounting close.

Where a standard rollout gets stuck
None of these problems show up in the pilot. They all show up at the first close after a tariff revision.
The pricing condition that keeps no history. The common configuration writes the current value and overwrites. When a retroactive ruling lands, there is nowhere to read what was in force before — and redoing by hand what the system should have known costs days of the close.
The recalculation that does not exist. Invoicing again is not the same as invoicing the difference. Issuing a full invoice and cancelling the previous one has tax consequences; issuing a supplementary one requires a rule that has to be designed. Projects that did not decide this during the rollout decide it in the middle of the incident.
The rounding nobody defined. Rounding per line, per invoice or per total gives different results, and all three are defensible. The problem is not choosing wrong — it is not choosing, and finding out at reconciliation that each area chose something different.
The regulatory filing treated as a report. As long as the file is produced by a manual extract and checked in Excel, it works. Until the month the volume grows, somebody goes on holiday, or the layout changes. A filing with a legal deadline needs the same treatment as a tax filing — automated generation, validation before submission, and evidence of what was submitted.
What fixes it, in order
1. Model the tariff as a series, not a value. Each component with its validity, its base and its index. It is more work during the rollout and it is what turns retroactivity into a processing run instead of an all-hands effort.
2. Define the difference rule before you need it. When a recalculation produces a higher or lower value, what gets issued, with which document, in which period. Written down, approved by tax, and tested with a real case before it goes to production.
3. Fix rounding in one place only. One rule, documented, applied by every process that touches value. And a test that compares the three paths and proves they agree.
4. Treat the regulatory filing the way tax treats its own. Automated generation, layout validation before submission, comparison against the previous period and evidence kept. It is the same reasoning we apply in simulating tax filings before submitting them — rehearsing the submission costs an afternoon, discovering the error through an audit costs something else.
5. Reconcile the three numbers every month. What the system invoiced, what metering indicates and what was declared to the regulator. When those three do not agree, the difference needs an explanation — and it needs to be found in minutes, not days. It is the same kind of reconciliation we describe in the banking cycle: every step with its own confirmation.
Where AI genuinely helps here
The calculation is deterministic and should stay that way — nobody wants a model deciding a tariff. But three expensive parts of the work are reading and comparing, and that is where the economics change.
Reading the ruling and pointing out what changes. Regulatory text is long, and the part that affects your master data is usually one paragraph. Finding that paragraph and translating it into “which components change, from when” is reading at volume — exactly what AI does well, with mandatory human review.
Explaining the divergence. When the three numbers do not agree, comparing the bases and proposing where the difference sits shortens the investigation from days to hours.
Validating the file before submission. Checking layout, totals and coherence against the previous period — the same rehearsal done with tax filings.
Where it does not belong: the legal interpretation of the norm, signing off the reconciliation and submitting to the regulator. Those three stay with people, with names and with accountability.
The honest limit
None of this removes the tariff revision, the regulator’s deadline or the divergence between metering and invoicing. Those are facts of the sector, not defects of the system.
What changes is where you spend the time. With the tariff modelled as a series, the difference rule written down and the filing automated, a retroactive revision becomes a processing run with a review. Without that, it becomes an all-hands close — every quarter, with the same people, making the same typing errors.
And there is an effect that only appears later: when the number is demonstrable, the conversation with the regulator changes in nature. It stops being a defence and becomes a presentation of evidence.
If your starting point is understanding what exists today before deciding what to change, start with the IT diagnostic. And for the sector overview, see IT for energy, oil and gas.
Frequently asked questions
What changes in SAP when revenue is regulated?
How do you handle a retroactive tariff ruling?
Why does the problem only show up after go-live?
Can AI calculate the tariff?
If your operation runs on regulated revenue and the close turns into an all-hands effort at every tariff revision, that is the kind of work we do in IT for energy, oil and gas.