REMADV verstehen

Kurzantwort

REMADV steht für Remittance Advice, auf Deutsch Zahlungsavis. In der deutschen energiewirtschaftlichen Marktkommunikation ist REMADV eine strukturierte EDIFACT-Nachricht, mit der der Empfänger einer INVOIC deren Ergebnis an den Rechnungsaussteller zurückmeldet. Sie kann eine Rechnung bestätigen, eine Rechnung ablehnen oder – je nach Use Case und Nachrichtenversion – eine Abweichung auf Kopf-, Summen- oder Positionsebene beschreiben. REMADV ist damit weder die Rechnung selbst noch der Zahlungsauftrag der Bank.

Die fachliche Kette lautet: Eine Partei stellt eine INVOIC aus, die andere prüft sie gegen Vertrag, Preisblatt, Stammdaten und Abrechnungsdaten. Das Prüfergebnis wird als REMADV mit einer Referenz auf die Rechnungsnummer und einem Prüfidentifikator übermittelt. Die tatsächliche Überweisung kann zeitlich davor oder danach liegen und wird nicht durch REMADV ersetzt. Für die Implementierung ist die gültige Formatversion entscheidend: Seit dem 1. April 2026 gelten nach der BNetzA-Mitteilung Nr. 54 REMADV-AHB 1.0a und REMADV-MIG 2.9e verbindlich, soweit keine abweichende Festlegung greift.

Die vier Dinge, die nicht verwechselt werden dürfen

Eine belastbare Verarbeitung beginnt mit einer sauberen Begriffsgrenze:

Die Abrechnung ist der fachliche Rechenvorgang. Das Ergebnis wird als Dokument ausgegeben und in der Marktkommunikation typischerweise mit INVOIC übertragen. REMADV beantwortet anschließend die Frage, wie der Rechnungsempfänger dieses Dokument behandelt: Ist die Forderung in der vorliegenden Form akzeptiert oder wird sie beanstandet? Ein Zahlungsavis ist also eine Nachricht über die Zuordnung und Beurteilung einer Forderung, nicht die Kontobewegung selbst.

Auch eine bestätigte REMADV garantiert nicht, dass das Geld bereits eingegangen ist. Umgekehrt kann eine Bankzahlung eingehen, bevor eine automatisierte REMADV verarbeitet wurde. Finanzbuchhaltung und Marktkommunikation müssen deshalb über gemeinsame Schlüssel wie Rechnungsnummer, Geschäftspartner, Betrag und Währung zusammengeführt werden, ohne die Ereignisse zeitlich oder semantisch gleichzusetzen.

Was steht in einer REMADV?

Das REMADV-MIG beschreibt die technische Segmentstruktur; das AHB beschreibt die fachliche Verwendung und die zulässigen Bedingungen. Im Nachrichtengerüst stehen unter anderem Nachrichtentyp und Referenz, Absender und Empfänger, Währung, die referenzierte Rechnung und der zugehörige Betrag. Die Nachricht enthält außerdem den Prüfidentifikator, über den der konkrete Use Case erkannt wird.

Im AHB sind für die klassischen Rückmeldungen Prüfidentifikatoren wie 33001 (Bestätigung) und 33002 (Abweisung) beschrieben. Für Strom sieht das Anwendungshandbuch zusätzlich Abweisungen auf Kopf-/Summenebene beziehungsweise Positionsebene vor, beispielsweise 33003 und 33004. Welche Variante zulässig ist, hängt vom Prozess, der Sparte und der geltenden AHB-Version ab. Die Nummern sind keine allgemein gültigen Fehlercodes für beliebige Nachrichten; sie müssen immer im Kontext des aktuellen AHB gelesen werden.

Die Dokumentreferenz ist der wichtigste fachliche Anker. Bei einer Bestätigung verweist die REMADV auf die angenommene INVOIC. Bei einer Abweisung muss aus der Nachricht erkennbar sein, welche Rechnung und – sofern vorgesehen – welche Position oder Summe betroffen ist. Der Betrag ist dabei eine fachliche Information zur geprüften Forderung, aber kein Ersatz für die Einzelprüfung von Mengen, Preisen und Steuern.

EDIFACT liefert die Syntax, nicht die komplette Geschäftslogik. Pflicht- und Kann-Segmente, Qualifier, Codelisten und Bedingungen stammen aus dem für den Use Case geltenden BDEW-/EDI@Energy-Anwendungshandbuch. Deshalb darf ein Parser nicht nur prüfen, ob die Segmente lesbar sind. Er muss die AHB-Regeln, die MIG-Version und die Nachrichtenversion gemeinsam auswerten.

Bestätigung, Abweisung und Prüfebenen

Eine Bestätigung sagt: Die referenzierte Rechnung wurde nach dem im Use Case definierten Prüfprozess akzeptiert. Sie ist nicht dasselbe wie eine CONTRL. CONTRL betrifft die formale Syntax und Übernahme einer EDIFACT-Nachricht. Eine syntaktisch gültige REMADV kann fachlich trotzdem falsch sein; eine fachlich bestätigte Rechnung muss umgekehrt auf einer formal korrekt empfangenen Nachricht beruhen.

Bei einer Abweisung sollte der Empfänger den Grund fachlich nachvollziehbar machen. Denkbar sind etwa eine unbekannte oder bereits verarbeitete Rechnungsnummer, eine nicht passende Marktpartnerbeziehung, ein abweichender Rechnungsbetrag oder eine nicht akzeptierte Position. Die konkrete Ursache und die zulässige Rückmeldung ergeben sich aus AHB, EBD und Codelisten. Freitext allein ist kein stabiler Integrationsvertrag: Automatisierte Systeme benötigen den vorgesehenen Code, die Referenz und die Zuordnungsebene.

Die Ebenen lassen sich so lesen:

1. Syntax: Kann die Datei beziehungsweise Nachricht nach EDIFACT/MIG gelesen werden?
2. Nachrichtenprüfung: Sind Identifikatoren, Rollen, Währung, Referenzen und Bedingungen plausibel?
3. Rechnungsprüfung: Stimmen die Forderung und ihre Positionen mit den fachlichen Daten überein?
4. Finanzielle Verarbeitung: Wird der offene Posten bestätigt, geklärt oder später mit einer Zahlung ausgeglichen?

Eine Ablehnung auf Kopf- oder Summenebene kann den gesamten Rechnungsbezug betreffen. Eine Positionsabweichung kann dagegen eine differenziertere Klärung erfordern. Das Ziel ist nicht, jede Abweichung sofort in eine automatische Korrekturbuchung umzuwandeln. Zuerst muss klar sein, ob eine Rechnung vollständig abgelehnt, teilweise beanstandet oder nur zur manuellen Klärung markiert wird.

Verhältnis zu INVOIC, Zahlung und Korrektur

INVOIC ist die ausstellende Nachricht. Sie transportiert das Rechnungsdokument mit Rechnungsart, Dokumentennummer, Leistungs- oder Rechnungszeitraum, Positionen, Beträgen und Zahlungsbedingungen. REMADV ist die Antwort beziehungsweise Rückmeldung des Rechnungsempfängers. Eine neue INVOIC korrigiert eine alte Rechnung nur dann, wenn sie als passende Korrektur-, Storno- oder Gutschriftkonstellation im betreffenden Prozess vorgesehen ist. REMADV selbst ändert keine Preise und erzeugt keine neue Abrechnung.

Auch eine Differenz zwischen INVOIC-Betrag und tatsächlich gezahltem Betrag ist nicht automatisch ein REMADV-Fehler. Skonto, Aufrechnung, Teilzahlung oder eine Bankgebühr können in einem kaufmännischen Prozess eine Rolle spielen; ob und wie das im Energiemarkt-Use-Case abgebildet wird, entscheidet die jeweilige Prozessbeschreibung. Ein System sollte deshalb Zahlbetrag, Avisbetrag, Rechnungsbetrag und eventuelle Differenzgründe getrennt speichern.

Bei einer Abweisung ist die Folge nicht pauschal „neue Rechnung senden“. Der Rechnungsaussteller muss den Grund analysieren. Liegt ein Daten- oder Preisfehler vor, kann eine Korrekturabrechnung erforderlich sein. Liegt dagegen ein Verarbeitungs- oder Zuordnungsproblem vor, kann eine erneute Verarbeitung mit unveränderter Rechnung oder eine Klärung zwischen Marktpartnern genügen. Die Belegkette darf dabei nicht durch Überschreiben der ursprünglichen INVOIC zerstört werden.

Umsetzung in SAP IS-U und FI-CA

In einem SAP-IS-U-Umfeld liegen die Ursprungsdaten der Abrechnung typischerweise in Vertrags-, Anlagen-, Geräte- und Abrechnungsobjekten. Aus dem Abrechnungsergebnis entsteht ein Beleg beziehungsweise eine Rechnung, die über die Marktkommunikationsstrecke als INVOIC ausgegeben werden kann. Die eingehende REMADV wird in der Integrationsschicht technisch angenommen, gegen die Nachrichtenversion geprüft und anschließend dem passenden Geschäftsvorfall zugeordnet.

Für FI-CA ist die entscheidende Frage, was die Rückmeldung mit dem offenen Posten macht. Eine Bestätigung kann einen Prozessstatus setzen oder eine fachliche Freigabe dokumentieren. Sie ist jedoch nicht automatisch eine Ausgleichsbuchung. Der Ausgleich entsteht durch die Zahlung beziehungsweise den dafür vorgesehenen Zahlungs- und Zuordnungsprozess. Bei einer Abweisung sollte das System einen nachvollziehbaren Klärstatus mit Originalnachricht, Rechnungsreferenz, Prüfidentifikator und Fehlergrund erzeugen.

Eine robuste Integration trennt mindestens diese Zustände:

Welche konkreten SAP-Objekte, Jobs oder Transaktionen verwendet werden, hängt von Release, Add-ons, Konverter, Kommunikationsadapter und kundeneigener Prozessausprägung ab. Aussagen wie „REMADV bucht immer automatisch aus“ sind daher fachlich und technisch unzulässig. Das Customizing muss anhand des konkreten AHB-Use-Cases und der FI-CA-Prozessdefinition geprüft werden.

Praxisfall: Netznutzungsrechnung mit Differenz

Ein Netzbetreiber versendet eine INVOIC für einen abgegrenzten Abrechnungszeitraum. Der Lieferant ordnet die Rechnung über Marktpartner-ID, Rechnungsnummer und weitere im Use Case geforderte Referenzen zu. Bei der Prüfung stimmen die Lokation und die Periode, eine abgerechnete Preisposition weicht jedoch vom erwarteten Preisblatt ab.

Zuerst wird die INVOIC technisch und fachlich vollständig protokolliert. Der Lieferant erzeugt keine freie E-Mail als alleinige maschinenlesbare Antwort, sondern verwendet die im geltenden REMADV-AHB vorgesehene Abweisungsebene und Referenz. Die REMADV benennt die betroffene Rechnung und – sofern der Use Case das vorsieht – die beanstandete Position. Im ERP bleibt der ursprüngliche offene Posten nachvollziehbar; die Abweisung erzeugt einen Klärfall.

Der Netzbetreiber prüft anschließend Preisquelle, Zeitraum und Abrechnungslogik. Ergibt sich ein echter Rechnungsfehler, folgt eine fachlich passende Korrektur. War nur die Stammdaten- oder Preisversion des Lieferanten veraltet, wird die Rechnung möglicherweise erneut verarbeitet. In beiden Fällen ist die REMADV die dokumentierte Rückmeldung zur ersten INVOIC, aber nicht selbst die Korrekturrechnung und nicht der Zahlungsauftrag.

Typische Missverständnisse

„REMADV ist die Rechnung.“ Nein. INVOIC transportiert die Rechnung; REMADV meldet deren Prüfung oder Annahme zurück.

„Eine Bestätigung bedeutet, dass das Geld überwiesen wurde.“ Nein. Zahlung und Zahlungsavis sind getrennte Ereignisse. Die Bestätigung kann vor, nach oder unabhängig vom Bankumsatz verarbeitet werden.

„CONTRL und REMADV sind austauschbar.“ Nein. CONTRL beschreibt die formale Verarbeitung der Nachricht. REMADV beschreibt den fachlichen Rechnungsbezug.

„Ein abweichender Betrag muss immer als neue Rechnung gebucht werden.“ Nein. Erst muss geklärt werden, ob eine Korrektur, Teilbeanstandung, Aufrechnung oder ein Datenproblem vorliegt und welcher Use Case das erlaubt.

„Die AHB-Version ist nebensächlich, solange die Segmente gleich aussehen.“ Nein. Bedingungen, Prüfidentifikatoren, Codelisten und Umsetzungstermine können sich ändern. Zum Stand dieses Artikels ist REMADV AHB 1.0a mit MIG 2.9e maßgeblich.

„SAP verarbeitet jede positive REMADV automatisch als Ausgleich.“ Nein. Eine fachliche Bestätigung ist nicht identisch mit einer FI-CA-Zahlungszuordnung. Diese Kopplung muss ausdrücklich modelliert und geprüft werden.

Quellen und Pflegehinweis

Die verbindliche Version ist stets gegen die aktuelle Veröffentlichung der Bundesnetzagentur und die zugehörigen EDI@Energy-Dokumente zu prüfen. Mitteilung Nr. 54 nennt REMADV-AHB 1.0a und REMADV-MIG 2.9e und legt den verbindlichen Umsetzungstermin 1. April 2026 fest. Ältere AHB-Dokumente sind als historische Referenz nützlich, dürfen aber nicht ungeprüft als aktuelle Spezifikation eingesetzt werden.

Bei einem Versionswechsel sollten mindestens Parser, AHB-Regeln, Prüfidentifikatoren, Codelisten, Testfälle, Klärfallzuordnung und die Kopplung an INVOIC/FI-CA gemeinsam geprüft werden. Für jede Abweisung gehören Originalnachricht, Referenz auf die INVOIC, Version, Prüfidentifikator und fachliche Entscheidung in den Audit Trail. Dieser Artikel wurde zuletzt am 8. September 2026 geprüft.

• BNetzA: Mitteilung Nr. 54 – Nachrichtentypen ab 01.04.2026
• BNetzA: Mitteilung Nr. 51 – Nachrichtentypen ab 01.10.2025
• BNetzA: INVOIC/REMADV-AHB 2.5d – historische Referenz
• EDI@Energy: Datenformate Strom und Gas