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.

In one sentence — in regulated revenue the ERP stops being where the price is decided and becomes where the application of the price has to be demonstrable — and it is that shift, not the volume, that breaks a standard rollout.

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.

the difference between free and regulated revenue: in free revenue the price is born in the contract and ends at the invoice; in regulated revenue it is born in the ruling and passes through validity with retroactivity, unit conversion and the regulatory filing before becoming an invoice
The path from price to invoice has three extra stops — and each stop is where the standard rollout planned nothing.

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.

Worth deciding early — three decisions that have to be made before the technical design, because changing them later means redoing it: how retroactivity is recorded (supplementary invoice, current-account adjustment or debit note — each with a different tax effect); where the tariff’s historical series lives, and for how long; and what the source of truth is when the regulator’s number differs from yours. The third is the one nobody writes down, and it is the one that decides who stays up at night during the close.

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?

The system stops being where the price is decided and becomes where the application of the price has to be demonstrable. In practice that forces you to keep the tariff’s historical series, not just the current value, because the audit asks for both the applied and the correct figure.

How do you handle a retroactive tariff ruling?

You have to recalculate what was already invoiced, generate the difference, and decide before the technical design how it will be issued: supplementary invoice, current-account adjustment or debit note. Each has a different tax effect, and changing that choice later means redoing the work.

Why does the problem only show up after go-live?

Because none of these cases happen in the pilot: they show up at the first close after a tariff revision. Until then, the pricing condition that overwrites the current value works normally and nothing signals that history is being lost.

Can AI calculate the tariff?

No, and it should not. The calculation is deterministic and stays deterministic. AI helps with three reading tasks: finding the paragraph of the ruling that affects master data, explaining where the divergence between numbers sits, and validating the file before it goes to the regulator.

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.