Skip to main content
In der Sparte Strom the receiver of a Geschäftsvorfall owes its sender the result of the Verarbeitbarkeitsprüfung — and owes it in both directions: an Anerkennungsmeldung (BGM+312) when the Geschäftsvorfall is free of errors, a Verarbeitbarkeitsfehlermeldung (BGM+313) when it is not. APERAK AHB 1.1 (01.04.2026), ch. 2.4:
Das Ergebnis der Verarbeitbarkeitsprüfung aller in einer Übertragungsdatei enthaltenen Geschäftsvorfälle hat der Empfänger der Übertragungsdatei dem Absender unverzüglich, jedoch spätestens bis zum nächsten Werktag 12 Uhr gesetzlicher deutscher Zeit nach Eingang der Übertragungsdatei, per APERAK mitzuteilen […]
Saying nothing is not one of the options. Two deadlines apply:
This is the mirror image of what the bridge already receives: the positive APERAKs partners send for our PARTIN and Zuordnungsermächtigung messages are their side of the same obligation.

​
What the bridge sends

One APERAK per Geschäftsvorfall, bundled into a single interchange back to the sender (AHB ch. 2.2.1):
  • RFF+ACE — the interchange reference of the message being answered, with DTM+171 carrying that interchange’s UNB clock.
  • RFF+AGO — the document number (BGM 1004) of the answered message.
  • RFF+TN — the Vorgangsnummer, only for IFTSTA, INSRPT, UTILMD and UTILTS (condition [16]). A UTILMD with 20 Vorgängen is therefore answered by 20 Anerkennungsmeldungen in one envelope; a PARTIN, which has no Vorgänge, by exactly one without RFF+TN.
  • NAD+MS/NAD+MR with each party’s own code-list qualifier (293 BDEW, 9 GS1) — as everywhere else in the bridge.
References are content-derived, so re-acknowledging the same interchange produces byte-identical output rather than a second opinion.

​
Which messages

The loop reads only the inbox of Cloover’s BRP (the BKV MP-ID). The mako365 account is shared with other market parties, and Cloover’s LF role is answered by the supplier’s own systems, so the bridge never acknowledges on their behalf. From that inbox it reads PARTIN, UTILMD (Zuordnungs- ermächtigung answers, MaBiS-ZP activations) and MSCONS: the sum series the BIKO and ÜNB send once a MaBiS-ZP is active (for example Prüfidentifikator 13003, Abrechnungssummenzeitreihe). An MSCONS has no Vorgänge, so each message (UNH) gets one Anerkennungsmeldung that names its document number in RFF+AGO. The answer is due by the next working day at 12:00. The APERAK only confirms that the series could be processed. Whether its energy amounts are right is a separate, optional business answer: for a BK-SZR (Kategorie A/B) the BKV may send a Prüfmitteilung (IFTSTA, MaBiS ch. 10.10 / 11.10, EBD E_0063 / E_0064). The bridge does not send Prüfmitteilungen. The Abrechnungssummenzeitreihe has no Prüfmitteilung.

​
Only the positive answer is automated

A message the bridge cannot even parse is not auto-rejected. Guessing an error code produces a wrong rejection, which is worse for the partner than a late one — so such a message raises an aperak_needs_review warning for a human instead, and no BGM+313 is invented. Negative answers stay a deliberate act.

​
Running it

The loop rides on the 15-minute orchestrator (AUTO_APERAK, on by default), which leaves head-room even against the 45-minute UTILMD deadline. Each interchange is acknowledged once; the ledger aperak_sent.json in the audit share keys on MakoFlow’s message id. A PARTIN that a partner sent as a mail attachment (imported by the mailbox reconciliation) is part of the same loop — it is acknowledged over AS4 like any other, keyed on its Datenaustauschreferenz. One mail may carry several: a service provider routinely sends the datasheets of the VNB (37001) and the MSB (37002) of the same company together, each with its own MP-ID and interchange reference. Every one of them is imported and acknowledged separately — each is a Geschäftsvorfall of its own. In the console the PARTIN tab has Empfangene Nachrichten quittieren: Prüfen lists what is open, Prüfen & quittieren sends. Over the API:
The response names every acknowledgement, whether it went out after its deadline (late), and how many are left for the next run (remaining, capped by APERAK_MAX_PER_RUN so a backlog cannot stall the orchestrator).

​
Settings