Notice no. 56: what actually goes live on 1 October
Six days before the deadline it pays to read the document closely. Part of what was consulted in February is missing from the binding version.
Notice no. 56 of the Bundesnetzagentur makes 25 AHB and MIG versions covering 13 EDIFACT message types binding from 1 October 2026, together with AS4 profile 1.2 and the transmission path rules 1.10. It applies to every market participant required to implement the market communication rules, so distribution grid operators, metering point operators and suppliers alike. The API web services electricity release 2.0.0 went out for consultation in February but did not make it into the binding publication, and they reappear only in notice no. 57 with the target date 1 April 2027. October is therefore a pure EDIFACT and AS4 release, and anyone who scheduled the API step for this year is replanning it.
What becomes binding on 1 October 2026
On 1 October 2026, 25 AHB and MIG versions covering 13 EDIFACT message types take effect. The legal basis sits in notice no. 56 of the Bundesnetzagentur, published on 1 April 2026, and it is stated briefly.
These versions apply bindingly from 01.10.2026 to all market participants required to implement them under the market communication rules.
No parallel operation of the old versions is foreseen. Send in the old version on Thursday morning and a rejection comes back.
25
AHB and MIG versions go live on the day
13
EDIFACT message types change, from APERAK to UTILTS
1.2
AS4 profile replaces the current one on the transport path
4.0
Check identifiers follow version 3.3 from April
0
API web services sit in the binding October package
12
Months of implementation time EDI@Energy wants for the next package
The message types run from the acknowledgement to the invoice: APERAK, IFTSTA, INVOIC, MSCONS, ORDCHG, ORDERS, ORDRSP, PARTIN, PRICAT, QUOTES, REQOTE, UTILMD for electricity and gas, and UTILTS. Then come the documents nobody reads and everybody needs.
| Document | Version | Effect in house |
|---|---|---|
| UTILMD electricity | AHB and MIG 2.2 | Carries the remote controllability flag, so it sits inside the section 14a programme |
| UTILMD gas | G1.2 | Gas processes run against new check identifiers |
| MSCONS | AHB 3.2, MIG 2.5 | The largest volume lever, because meter value delivery depends on it |
| APERAK | AHB 1.1, MIG 2.2 | Business rejections come back with new identification |
| PARTIN | AHB 1.1, MIG 1.1 | Demands clean market partner master data |
| General provisions | 6.1d | Cross-cutting rules for every message type |
| Check identifiers | 4.0 | Exception rules and rejection logic need reloading |
| Decision tree diagrams | 4.3 | Process logic in converter and EDM needs adjusting |
| AS4 profile | 1.2 | Gateway configuration and certificates need checking |
| Transmission path rules | 1.10, AS4 2.6 | Transport rules for every market partner |
Unlike the 24-hour supplier switch, this package brings no new business processes. It sharpens mandatory fields, validation rules and decision trees. That sounds harmless. Releases of exactly this kind produce the errors nobody spots in the functional design, because what changes is not the process but its edges.
The API web services dropped out of the October package
The most important finding for planning is not in the headline of the notice. The API web services electricity release 2.0.0 were part of the consultation for 1 October 2026 and did not become part of the binding publication.
The changes to the API web services put out for consultation in release 2.0.0 are not part of this publication.
October is therefore a pure EDIFACT and AS4 release. Anyone who read the consultation papers in February and derived an API sub-project for the third quarter has been working since April on an assumption that no longer holds.
The Bundesnetzagentur announced that it would consult the changes again in the next version alongside further API web services. That happened on 31 July 2026 with notice no. 57, carrying the target date 1 April 2027.
An API sub-project planned for October moves back in an orderly way instead of stranding in a test for which no binding specification exists. The freed capacity is better spent on test depth and exception handling for the EDIFACT package.
How EDIFACT, AS4 and the API layer fit together, and why the rebuild runs in stages, is set out in our overview of MaKo 2026.
Where the exception cases will come from
Exception cases rarely arise where the format description is unambiguous. They arise where two market partners read the same rule differently. Notice no. 56 shifts exactly those places: the check identifiers go to 4.0, the decision tree diagrams to 4.3.
Both documents decide when a message is rejected on business grounds and which identification the APERAK carries back. Change that and the rejection rate changes before anyone has touched a line of business logic.
The consultancy BET names two main risks for this year's releases: inconsistent readings of segment assignments and validation rules between market partners, and rising rejection rates in the high-volume processes GPKE, WiM, MaBiS and GeLi Gas. Nobody publishes in advance which transactions October will hit. What the notice changes does say where to look.
Four places follow directly from what changes:
- Transactions across the month boundary. A registration that starts in September under the old version and is answered in October under the new one likes to hang halfway.
- MSCONS and meter value delivery. The volume here is large enough that even a small rise in the rejection rate means noticeable rework.
- PARTIN and market partner master data. Unclean master data creates follow-on errors in every downstream process, and that only shows up in week three.
- Mapping the new check identifiers in your own exception handling tool. If your system does not know the identifier, the transaction lands in the catch-all queue instead of with the team that owns it.
Why master data so often turns out to be the trigger, we have set out with figures elsewhere: master data quality in market communication.
Fallback processes that hold on 1 October
A fallback process drafted on the day itself is not one. Three things should exist beforehand in writing: the threshold at which you switch, the person who decides, and the route back into the system.
Five decisions before the go-live date
-
Name the threshold and the decision maker
Define the rejection rate over which period triggers escalation, and write down the name of the person who then decides. A threshold without a decision maker is a metric, not a process.
-
Keep a manual route for the deadline-bound processes
The deadlines under GPKE and WiM keep running even when the gateway falls silent.
-
Settle the rollback with your IT provider
Ask in advance what a rollback to the previous converter version looks like and how long it takes. After the deadline it is not a lasting answer in regulatory terms, because the old versions no longer apply. As a bridge for a few hours it can make the difference, and it is not an answer you want to hear for the first time on Thursday morning.
-
Agree named contacts at your main market partners
For the first two weeks, a name and a direct line, not just a shared mailbox.
-
Document every manual transaction
Evidence for internal audit and for the Bundesnetzagentur rests on it. Clean logging in October saves the reconstruction in January.
A rollback to the old versions is not a regulatorily acceptable steady state after 1 October. It can bridge an incident, but it does not replace the migration. How long such a bridge is defensible in a given case is something to settle with your market partner and your legal team.
An argument about pace: six months or twelve
The October package is not yet in production and the draft for the one after it is already on the table. Notice no. 57 of 31 July 2026 put UTILMD AHB electricity 2.3, the general provisions 6.1e and the API web services electricity release 2.0.0 out for consultation. The window closed on 31 August 2026.
In that same notice the Bundesnetzagentur holds to the established rhythm and names 1 April 2027 as the target date. The EDI@Energy project group, where market participants draft the documents under BDEW leadership, pushes back: it proposes a twelve-month implementation period for the document package due to be published on 1 October 2026 instead of the customary six, which would move productive use to 1 October 2027. Among its reasons it names the need to take the MiSpeL rules into account.
Both sides have a case. The regulator needs a predictable cadence, or every determination slips into the next round. The practitioners point out that a utility migrating in October is testing again by spring. The twelve-month proposal is the clearest admission yet that the half-year cadence has become too tight for many houses. It has not been decided.
A larger movement runs behind all of this. Under the file reference BK6-25-000 the Bundesnetzagentur has been preparing a revision of electricity market communication since July 2025. It wants to realign it, as the notice puts it, for the future using new technological possibilities, with hub approaches at the centre and 2032 as the horizon. An expert report from a consortium led by Fraunhofer IEE was announced for the second quarter of 2026.
For investment decisions that is the more important number than any single release. In-house development close to the EDIFACT format ties up capital in a layer that will probably not survive in this form until 2032. How the same movement plays out on the balancing side is already visible at the MaBiS hub.
What is still worth doing
In the days that remain, what counts is not what gets built but what has demonstrably been tested. Four things are worth the time.
Get written confirmation from your IT provider on which of the 25 versions the delivered release contains and from which date they switch on. Check the AS4 configuration against profile 1.2 and the transmission path rules 1.10, including certificate validity past the deadline. A certificate expiring in mid-October is the most annoying outage of all, because it has nothing to do with the release.
Set up a daily evaluation of APERAK returns per check identifier for the first two weeks. Without that view you notice a rising rejection rate only in the billing run, and by then the month is gone.
And take the API sub-project out of the October plan. It belongs in the 2027 roadmap alongside UTILMD 2.3. For the gas side it is worth looking at GeLi Gas 2.0 in parallel, because the same check identifiers apply there.
After two weeks, evaluate which exception cases actually occurred. That is the best test basis you will get for the next release, and it costs nothing beyond the analysis.
Further reading
Frequently asked questions
Notice no. 56 of the Bundesnetzagentur, published on 1 April 2026, makes 25 AHB and MIG versions covering 13 EDIFACT message types binding. They include UTILMD electricity 2.2 and UTILMD gas G1.2, MSCONS AHB 3.2 with MIG 2.5, and APERAK AHB 1.1 with MIG 2.2. The package also carries the general provisions 6.1d, the overview of check identifiers 4.0, the decision tree diagrams 4.3, AS4 profile 1.2 and the transmission path rules 1.10 with AS4 version 2.6.
No. Notice no. 56 states explicitly that the changes to the API web services put out for consultation in release 2.0.0 are not part of that publication. The plan was to consult them again in the next version together with further API web services. That happened with notice no. 57 of 31 July 2026, where they carry the target date 1 April 2027.
The notice addresses every market participant required to implement the market communication rules. In practice that means the electricity and gas distribution grid operators, the default and competitive metering point operators, the suppliers and the balancing-relevant parties. In Germany that covers roughly 870 electricity grid operators, roughly 710 gas grid operators and more than 1,000 energy suppliers.
Exception cases rarely arise where the format description is unambiguous. They arise where two market partners read the same rule differently. Notice no. 56 lifts the overview of check identifiers to version 4.0 and the decision tree diagrams to 4.3. Both decide when a message is rejected on business grounds and which check identifier the APERAK carries back. Transactions that start in September under the old version and are answered in October under the new one are the classic candidates for a stuck process.
Three decisions should exist in writing: an escalation threshold at which processing switches from automated to manual, the person who makes that call, and the route by which manually handled transactions are later reconciled in the system and documented. The deadlines under GPKE and WiM keep running even when a gateway falls silent.
Notice no. 57 of 31 July 2026 put UTILMD AHB electricity 2.3, the general provisions 6.1e and the API web services electricity release 2.0.0 out for consultation, among others. The consultation ran until 31 August 2026. Those versions are in principle binding from 1 April 2027. The EDI@Energy project group proposes a twelve-month implementation period for the package instead of the customary six, which would move productive use to 1 October 2027.