MaKo 2026: EDIFACT, AS4 and API Web Services

What MaKo 2026 really is: an architecture shift, not a process big bang

MaKo 2026 is best treated as a data architecture and integration topic, not a pure business project. It is not a single event but a staggered rebuild of market communication that leaves the business processes broadly stable and instead modernises formats, transport paths and interfaces. The current format release took effect on 1 April 2026, and the BNetzA itself places it under the motto consolidation rather than upheaval. The handbook chapter on market communication shows how meter readings turn into processes between the market roles, from supplier switching to the MaBiS hub.

A short clarification matters here. MaKo 2026 is the regulatory reform of market communication itself, not the SAP product Mako Cloud, which is one vendor's software for handling that communication. The release under Mitteilung No. 54 brings EBD 4.2, check identifiers 3.3, general specifications 6.1c and OBIS codes 2.5c, with clearer mandatory field definitions, harmonised reference logic and less room for interpretation in the validations. It touches the core processes GPKE, WiM, MaBiS and GeLi Gas, that is supplier switching, metering, balancing and gas supply. Where a single vendor platform fits into this picture is set out in innobu's guide to the SAP Mako Cloud.

EDIFACT and API: two worlds in parallel

What is new is that synchronous API web services with JSON now sit next to the file-based EDIFACT exchange. EDIFACT messages such as UTILMD, MSCONS or INVOIC remain in place. With Mitteilung No. 58 of 1 October 2026, BNetzA made clear that API web services will not replace EDIFACT for the foreseeable future and are expected to remain limited to MaLo-Ident and control. The first binding API process, for determining the MaLo-ID (the market location identifier), has applied since 6 June 2025.

The two channels coexist, and that will not change soon. Mitteilung No. 55 put API web services electricity release 2.0.0 out for consultation, splitting the single MaLo-ID service into several functionally separate ones and moving it from Swagger to GitHub. It did not make the binding version under Mitteilung No. 56. With Mitteilung No. 58 of 1 October 2026 BNetzA changed course: UTILTS stays, the API web services for calculation formulas and location bundles consulted in July will not be introduced, and API web services are expected to remain limited to MaLo-Ident and control. For an integration team this means EDIFACT and API are not an either or but two structures to be kept in sync.

AS4: the new transport layer under the hood

While formats and APIs concern the content, AS4 governs the transport. AS4 (Applicability Statement 4) is a standard based on ebMS3 and web services that has been mandatory in the German electricity market since 1 April 2024 and replaces the earlier transfer of EDIFACT messages by email and AS2. The channel becomes more secure, acknowledged and auditable, which is decisive for the mass operation.

AS4 covers the core processes GPKE, MPES, WiM and MaBiS, while schedule exchange and Redispatch 2.0 are governed separately. The communication security rests on the Smart Metering PKI and the cryptography standards of the BSI (the Federal Office for Information Security), with the transport secured by TLS. Mitteilung No. 56 updates the AS4 profiles to version 1.2 and the transmission rules to version 1.10, each binding from 1 October 2026. The EDIFACT messages that carry the mass operation travel over this transport, which is why the transport layer is the part to get right first. The grid-side context, from metering to control, runs alongside this, as innobu set out for the control box and Section 14a.

Who is affected and what happens in the systems

The change touches every market role at once, from the grid operator through the energy supplier and metering point operator to the balancing group responsible party. For municipal utilities with grown IT estates this means adapting energy data management (EDM) systems, converters and interfaces in step with each deadline, without interrupting the live operation. The quality of the data architecture decides the effort and the risk.

This is where data architecture stops being a back-office concern, and the same holds for the HEDWIG reporting duty under § 111g EnWG. A clean separation between the message format, the transport connector and the partner endpoint lets a team absorb a new release by changing one layer rather than rewiring the whole chain. A grown estate that mixes these concerns pays for it at every BNetzA deadline.

The roadmap: staggered deadlines, not a single cut-off date

MaKo 2026 is organised as a rolling roadmap in which the BNetzA sets consultation and binding dates in numbered Mitteilungen. The release of 1 April 2026 under Mitteilung No. 54 is followed by the next bundle of formats and services under Mitteilung No. 56, binding from 1 October 2026. Whoever sets the programme up as a standing task rather than a one-off project stays able to deliver.

The layering matters for planning. The mail-based EDIFACT transfer has been replaced step by step since late 2023, AS4 carried that shift, and API web services arrived in June 2025 as a fast B2B channel for MaLo identification. There is no single switchover date to plan against, only a sequence of binding releases that a programme has to meet one after another.

What utilities and municipal utilities should do now

The economically sensible answer to MaKo 2026 is a standing programme with clear enterprise architecture control, not point fixes at each deadline. Whoever bundles the EDIFACT, AS4 and API paths into one integrated architecture and encapsulates converters and interfaces cleanly reduces the adaptation effort at every new release. A regulatory duty then becomes a stable foundation for further digital work.

1. Define a target architecture with coexisting channels

   Set out a target architecture that encapsulates EDIFACT, AS4 transport and API web services as coexisting channels, so each can change without forcing changes in the others.

2. Maintain converters and mappings centrally

   Keep converters and mappings in one place, so that new format versions and API releases land in the mass operation without a break and without scattered local patches.

3. Couple the programme to the BNetzA deadlines

   Tie the programme to the BNetzA binding dates and run it as a standing task, with each numbered Mitteilung treated as a planned release rather than a surprise.

4. Connect to the wider regulatory picture

   Think through the links to Redispatch, the smart meter rollout and Section 14a EnWG, because the same EDM and integration estate carries those duties as well.

Further reading

Frequently asked questions