Skip to main content
Running the balance group is not enough: before a supplier may assign a market location to it, the BKV must have permitted that to the location’s Netzbetreiber. MaBiS (ch. 10.2) calls this the Zuordnungsermächtigung — granted je Zeitreihentyp, Bilanzierungsgebiet, Bilanzkreis und Lieferant, valid from a named date. It is required even when BKV and supplier are the same legal entity, and without it the NB rejects the supplier’s registrations against exactly this check (GPKE answer code: “Zuordnungsermächtigung liegt nicht vor”). The bridge generates the message and hands it to the MakoFlow AS4 gateway, which routes it to the NB. It is a pure permission record — no market locations, no volumes.

​
The message

A fixed-shape UTILMD (AHB Strom ch. 13.5): One Vorgang per Zeitreihentyp; each carries the Bilanzierungsgebiet (EIC), the Bilanzkreis (EIC) and the supplier’s MP-ID. Effective dates are midnight Europe/Berlin, expressed on the wire in UTC as the AHB requires.

​
Sending one

The console has a Zuordnungsermächtigung panel: pick the Netzbetreiber (type-to-filter over the official BDEW list, 1014 active entries), its Bilanzierungsgebiet, the Zeitreihentypen (LGS and EGS pre-selected — the value-based pair), the effective date, then Vorschau shows the exact EDIFACT and Senden delivers it after a confirmation. The dropdown data ships with the service and is regenerated from the published workbook via scripts/zuordnung_targets.py --emit-registry. The same works over the API. Preview first — the endpoint renders the exact interchange without sending anything, so the first message to each NB can be read by a human:
The same body on POST /v1/process/zuordnungsermaechtigungen builds the message, delivers it through MakoFlow, appends a zuordnung_sent event and stores the exact interchange in the audit trail under the effective day. action: "deactivate" produces the 55072 counterpart; a deactivation to a date that is not the 1st of a month is refused. bilanzkreis_eic and lieferant_mp_id may be omitted — they default to the configured balance group of the home control area and the configured supplier.

​
Automatic granting

Once the PARTIN exchange with a DSO is complete in both directions — our datasheet out, theirs in, no rejection standing — POST /v1/process/zuordnungsermaechtigungen/auto sends the standing selection to every Bilanzierungsgebiet the DSO has: action activate (55071), the configured Zeitreihentypen (AUTO_ZOE_ZEITREIHENTYPEN, default LGS/EGS/SLS/TLS/SES), valid from AUTO_ZOE_VALID_FROM (empty = first of next month). A ledger (zoe_auto.json in the audit trail) grants each (partner, BG) pair exactly once; partners whose Zuordnung was already sent manually are left alone, and a new BG in a registry update is picked up on a later run. dry_run lists without sending. AUTO_ZOE_VALID_FROM is a month-bound setting. MaBiS (Kap. 10.2.2) lets an activation take effect retroactively from the first of the current Bilanzierungsmonat, one Werktag before the first Zuordnung, so a wave sent mid-month is pinned to that month’s first (September 2026: the live app carries AUTO_ZOE_VALID_FROM=2026-09-01, set on the Container App, not in Bicep). On the first of the next month the value must be moved or cleared before any further grant — a date from the previous month would then be retroactive beyond the Bilanzierungsmonat. Eligibility widens in two explicit steps. By default the PARTIN exchange must be complete in both directions. on_positive_ack: true also grants to partners whose PARTIN was delivered (NRR ok) and positively acknowledged, though their own datasheet never came — many DSOs never send one. on_delivery: true goes one step further: delivery alone is enough once the APERAK deadline plus Karenz has passed in silence and no rejection stands. The Zuordnungsermächtigung is the deliverable and the PARTIN acknowledgment is no prerequisite for it; a UTILMD is processed by machine where a PARTIN often waits for a human, so the Zuordnung is the faster way to learn whether the partner’s system knows us at all. A rejection of any kind still blocks the grant until it is cleared. In the console: the Prüfen / Prüfen & senden pair under the Zuordnung panel. With AUTO_ZOE=true (console-mutable, off by default) the loop also runs on every orchestrator call, so a DSO is granted automatically as soon as its PARTIN answer arrives.

​
Extending the standing selection

When a Zeitreihentyp is added to AUTO_ZOE_ZEITREIHENTYPEN (as TLS was), partners already granted do not get the whole selection again. POST /v1/process/zuordnungsermaechtigungen/ergaenzung sends only the missing types, as a new activation (55071) for those types alone — that is how MaBiS defines the permission: “Die Ermächtigung erfolgt je ZRT, BG, BK und LF ab einem bestimmten Zeitpunkt” (BK6-24-174, Kap. 10.2.1), and the UTILMD AHB carries exactly one Summenzeitreihe per Vorgang. Resending the types already in force would be a duplicate activation, not an update. Only partners whose Zuordnung was positively acknowledged are extended (their grant demonstrably stands); the others are listed as skipped and picked up by a later run once their Quittung arrives. The validity date follows the partner’s existing grant where MaBiS allows it — an Ermächtigung may be granted retroactively to the 1st of the current Bilanzierungsmonat (Kap. 10.2.2, SD Nr. 1) — otherwise AUTO_ZOE_VALID_FROM or the first of next month. A grant sent by hand after the ledger’s last send for that (partner, BG) — the manual route does not write the ledger — is picked up from the audit trail: its extra types are topped up into the ledger (nachgetragen) instead of being sent a second time. The zoe_auto ledger records the added types per (partner, BG), so repeated runs send nothing twice, and the regular auto-grant keeps treating those BGs as granted. dry_run lists first. The run starts with a Ledger-Abgleich: Zuordnungen sent by hand before the ledger existed exist only as audit records (one per interchange). Those (partner, BG) pairs are seeded into zoe_auto with the types they carried (nachgetragen in the response), so the extension reaches them too and the auto-grant stops treating the partner as “manuell gesendet”.

​
Configuration

All of these are settable from the console like the other partner credentials.

​
Verification

MakoFlow answering 200 means the gateway accepted the message, not that the NB did. The NB’s answer arrives as CONTRL (syntax) and APERAK (application) messages in MakoFlow — check received messages there, or its GET /edifact/sent-messages API. A rejected Ermächtigung surfaces later as the NB refusing the supplier’s registrations, which is the expensive way to find out.
The generated message is pinned by tests to the AHB segment table — qualifiers, timezone rules and the UNB/NAD code-list split included. What is not yet proven is a live round trip against a real NB; the first send should be watched through MakoFlow’s portal until the CONTRL comes back clean.