Jede APERAK-Ablehnung bedeutet Nacharbeit: ein Klärfall, ein blockierter Prozess, im schlimmsten Fall ein geplatzter Lieferantenwechsel. Wer die häufigsten Ursachen kennt und Ablehnungen als Datenquelle statt als Störfall behandelt, kann Clearingfälle systematisch reduzieren. Dieser Beitrag zeigt die typischen Fehlerbilder und ein Vorgehen, das die Quote dauerhaft senkt.
Was eine APERAK aussagt
Die APERAK ist die fachliche Quittung der Marktkommunikation: Sie meldet, dass eine empfangene Nachricht gegen das Anwendungshandbuch (AHB) verstößt, etwa weil ein Pflichtfeld fehlt oder ein Codewert im Anwendungsfall unzulässig ist. Dabei gilt: Werden mehrere AHB-Fehler gefunden, muss die APERAK alle benennen, nicht nur den ersten. Die Regeln dafür stehen inzwischen in einem eigenen APERAK-Anwendungshandbuch; früher teilte sie sich ein Handbuch mit der CONTRL.
Davon zu trennen ist die CONTRL: Sie prüft eine Ebene tiefer, auf Syntax. Eine Nachricht, die schon strukturell kein gültiges EDIFACT ist, wird per CONTRL verworfen und erreicht die AHB-Prüfung gar nicht.
Die Prüfkette: wo eine Nachricht scheitern kann
- Transport (AS4) Die Übertragung wird technisch quittiert; scheitert sie, kommt die Nachricht nie an. Der Sender ist in der Pflicht, ausbleibende Quittungen zu bemerken und zu klären.
- Syntax (CONTRL) Der Empfänger prüft die EDIFACT-Struktur. Syntaxfehler führen zur Ablehnung der Übertragungsdatei oder Nachricht.
- AHB-Konformität (APERAK) Inhaltliche Prüfung gegen das Anwendungshandbuch des Nachrichtentyps und Prüfidentifikators.
- Fachliche Prüfung (Antwortnachricht) Erst jetzt entscheidet der Empfänger nach den Entscheidungsbaum-Diagrammen (EBD) über den Geschäftsvorfall und antwortet mit einem Antwortcode.
Für das Clearing ist diese Unterscheidung zentral: Eine fachliche Ablehnung (etwa einer Anmeldung) ist keine APERAK, und ein APERAK-Fehler ist fast nie ein Sachbearbeiterthema, sondern ein Daten- oder Systemthema. Wer beides in einen Topf wirft, misst falsch und behebt an der falschen Stelle.
Typische Clearingfälle und ihre Ursachen
| Fehlerbild | Typische Ursache | Ansatzpunkt |
|---|---|---|
| Unbekannte MaLo/MeLo-Referenz | Stammdaten zwischen den Marktpartnern asynchron, Zahlendreher, veralteter Zuordnungsstand nach Wechselprozessen | Stammdatenabgleich, Validierung der Codenummern im Ausgang |
| Veraltete Formatversion | Nachricht nach dem Release-Stichtag im Altformat versendet | Releasekalender, Regressionstests vor jedem Formatwechsel |
| Pflichtfeld fehlt / Codewert unzulässig | Mapping-Lücke im Backend, Sonderfall im Datenbestand, den das Mapping nicht kennt | AHB-Prüfung bereits im Nachrichtenausgang |
| Falscher Prüfidentifikator | Anwendungsfall im Vorsystem falsch klassifiziert, etwa Stammdatenänderung statt Anmeldung | Prozesslogik und Transaktionsgründe prüfen |
| Referenz auf unbekannten Vorgang | Antwort auf eine nie zugestellte Nachricht, Reihenfolgeprobleme im Versand | Sendewege-Monitoring, Quittungsabgleich |
| Ablehnung „Sonstiges" (A99) | Sammelgrund; der Ablehnungsgrund muss dann im Freitext begründet werden | Freitexte auswerten, wiederkehrende Muster bilateral klären |
In fünf Schritten zur niedrigen Quote
- Messen Ablehnungsquote je Nachrichtentyp, Prüfebene und Marktpartner erheben. Ohne Basiswert ist jede Maßnahme Blindflug.
- Clustern Fehlercodes und Freitexte gruppieren: Meist erzeugen wenige Ursachen den Großteil der Fälle; in Projekten zeigt sich regelmäßig, dass eine Handvoll Fehlerbilder über die Hälfte des Klärfallvolumens ausmacht.
- Ursache statt Symptom beheben Stammdaten korrigieren und abgleichen, Mapping-Lücken schließen, Prozesslogik anpassen. Ein Klärfall, der manuell „durchgedrückt" wird, kommt nächsten Monat wieder.
- Ausgang validieren Nachrichten vor dem Versand gegen AHB-Regeln und Stammdaten prüfen. Jeder abgefangene Fehler spart eine Ablehnung samt Antwortzyklus mit dem Marktpartner.
- Klärfallbearbeitung automatisieren Wiederkehrende Fälle per Regelwerk lösen (nachreferenzieren, korrigieren, neu senden), sodass nur echte Ausnahmen bei der Sachbearbeitung landen.
Eine APERAK ist kein Betriebsunfall, sondern ein Messwert: Wer seine Ablehnungen systematisch auswertet, kennt die Schwachstellen seiner Stammdaten besser als jedes Audit.
Releases sind die größten Fehlertreiber
Die Ablehnungsquote hat einen Rhythmus: Sie springt an den Formatwechsel-Stichtagen. Zum Release am 1. Oktober 2026 (final beschlossen per BNetzA-Mitteilung Nr. 56, unter anderem mit EBD 4.3 und AS4-Profil 1.2) trifft ein Formatwechsel erneut alle Marktpartner gleichzeitig: Wer im Altformat sendet oder neue Prüfregeln ignoriert, produziert ab Tag eins Ablehnungen in Serie.
Bewährt hat sich ein festes Stichtags-Drehbuch: Formatstände und Codelisten rechtzeitig aktualisieren, Testnachrichten mit den wichtigsten Marktpartnern austauschen und in der ersten Woche nach Umstellung die Quote täglich auswerten. Auch der 24-Stunden-Lieferantenwechsel verschärft die Lage, denn seit LFW24 fehlt die Zeit, Ablehnungen in Ruhe nachzuarbeiten. Details zum kommenden Stichtag bündelt der Beitrag zum MaKo-Release Oktober 2026, die Datenseite der Beitrag zur Stammdatenqualität in der Marktkommunikation.
Häufige Fragen
Das Wichtigste in Kürze
- APERAK meldet Verstöße gegen das Anwendungshandbuch; CONTRL prüft die Syntax, fachliche Ablehnungen kommen als Antwortnachricht mit EBD-Antwortcode.
- Jede Nachricht durchläuft vier Prüfebenen: AS4-Transport, Syntax, AHB-Konformität, fachliche Prüfung. Klärfälle gehören der Ebene zugeordnet, auf der sie entstehen.
- Häufigste Ursachen: asynchrone Stammdaten, veraltete Formatversionen, Mapping-Lücken und falsche Prüfidentifikatoren.
- Dauerhaft senkt die Quote nur Ursachenarbeit: messen, clustern, Stammdaten und Mapping korrigieren, Ausgang validieren, Klärfälle automatisieren.
- Formatwechsel-Stichtage wie der 1. Oktober 2026 sind die größten Fehlertreiber; Tests mit Marktpartnern und tägliches Monitoring nach der Umstellung sind Pflicht.