EDI-Mapping ändern: Die Checkliste vor dem nächsten Format- oder ERP-Update

Wer ein EDI-Mapping ändern muss, hat selten nur ein Dateiformat vor sich. Ein Kunde fordert eine neue Belegversion, ein Geschäftspartner ändert Pflichtfelder oder ein ERP-Update verschiebt die Datenstruktur. Was als kleine Anpassung beginnt, betrifft schnell mehrere Systeme, Prozesse und Beteiligte. Ein EDI-Mapping übersetzt Geschäftsdaten zwischen ERP-System, Integrationsplattform und Geschäftspartner. Ändert sich eine Seite, wirkt das auf die gesamte Prozesskette. Unsere Checkliste zeigt in zehn Schritten, welche Fragen Sie vor, während und nach einer Mapping-Änderung klären sollten.

Wann Sie ein EDI-Mapping ändern müssen

EDI-Mappings laufen oft viele Jahre stabil. Die Anforderungen an sie verändern sich trotzdem regelmäßig. Typische Auslöser sind:

• eine neue Version eines Nachrichtenstandards, etwa von EDIFACT D96A auf D01B
• neue oder geänderte Pflichtfelder eines Kunden oder Lieferanten
• ein ERP-Update, eine S/4HANA-Migration oder ein Systemwechsel
• Änderungen an Artikel-, Kunden- oder Lieferantenstammdaten
• eine neue Gesellschaft oder ein zusätzlicher Standort
• die Anbindung eines weiteren Geschäftspartners
• geänderte steuerliche oder rechtliche Vorgaben
• wiederkehrende Fehler im bestehenden Prozess

Aktuelles Beispiel E-Rechnung: Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz im inländischen B2B-Geschäft E-Rechnungen ausstellen. Rechnungen im bestehenden EDI-Verfahren bleiben mit Zustimmung des Empfängers bis Ende 2027 zulässig. Ab 2028 müssen sich aus EDI-Rechnungen die Angaben nach EN 16931 korrekt extrahieren lassen. Für viele INVOIC-Mappings steht damit spätestens 2027 eine Anpassung an.

Auch kleine Änderungen können nachgelagerte Prozesse beeinflussen. Klären Sie deshalb vor der Umsetzung, welche Systeme, Partner und Nachrichtentypen betroffen sind.

1. Auslöser und Ziel der Änderung dokumentieren

Am Anfang steht die Frage, warum das Mapping geändert werden muss. Die Antwort sollte so konkret wie möglich dokumentiert sein. Die Aussage „Der Kunde braucht ein neues Format“ reicht dafür meistens nicht aus.

Halten Sie mindestens diese Angaben fest:

• Wer fordert die Änderung?
• Welcher Nachrichtentyp ist betroffen?
• Welche Formatversion wird aktuell verwendet?
• Welche Formatversion wird künftig erwartet?
• Ab welchem Zeitpunkt soll die Änderung gelten?
• Laufen alte und neue Version für eine Übergangszeit parallel?
• Gibt es eine technische Spezifikation?
• Handelt es sich um eine Pflichtanforderung oder eine Optimierung?
• Muss das bestehende Mapping ersetzt oder erweitert werden?

Diese Angaben bilden die Grundlage für Aufwandsschätzung, Umsetzung und Tests.

2. Betroffene Systeme und Prozesse bestimmen

Ein Mapping ist immer Teil einer Prozesskette, zum Beispiel vom Bestelleingang bis zur Rechnung. Prüfen Sie deshalb vor der Anpassung:

• Aus welchem System kommen die Daten?
• In welches System werden sie übertragen?
• Welche Integrationsplattform verarbeitet sie?
• Welche vor- und nachgelagerten Prozesse sind betroffen?
• Greifen weitere Mappings oder Schnittstellen auf dieselben Daten zu?
• Wird das Mapping von mehreren Partnern verwendet?
• Gibt es länder- oder gesellschaftsspezifische Varianten?

Besondere Vorsicht gilt bei zentralen Mappings, die mehrere Geschäftspartner gemeinsam nutzen. Eine Änderung für einen Partner darf die Verbindungen anderer Partner nicht beeinflussen. Planen Sie dafür von Anfang an Regressionstests ein.

3. Quell- und Zielformat vergleichen

Im nächsten Schritt vergleichen Sie die bisherige mit der neuen Struktur. Neue Felder sind dabei nur ein Teil der Arbeit. Auch geänderte Feldlängen, Datentypen oder Abhängigkeiten zwischen Feldern können Fehler auslösen.

Prüfen Sie unter anderem:

• neue oder entfallene Segmente und Felder
• geänderte Pflichtangaben
• Feldlängen und Datentypen
• Datums- und Zahlenformate
• Codes, Qualifier und Wertelisten
• Wiederholungen von Positionen oder Segmenten
• Bedingungen zwischen einzelnen Feldern
• Zeichensätze und Sonderzeichen
• Regeln für leere oder fehlende Werte
• Quittungen und Statusmeldungen wie CONTRL, APERAK oder X12 997/999

aurebus verarbeitet und transformiert unter anderem EDIFACT, VDA, SAP IDoc, ANSI X12, openTRANS, cXML, XML und CSV. Auch branchen- und partnerspezifische Anforderungen lassen sich im Mapping abbilden.

4. Datenverfügbarkeit im ERP-System prüfen

Nicht jedes Feld, das ein Geschäftspartner fordert, existiert bereits im eigenen ERP-System. Klären Sie deshalb früh:

• Ist der benötigte Wert im Quellsystem verfügbar?
• Wird er an der richtigen Stelle gepflegt?
• Ist die Datenqualität ausreichend?
• Muss der Wert aus anderen Angaben abgeleitet werden?
• Ist eine Änderung im ERP-System notwendig?
• Wer übernimmt die fachliche Verantwortung für das Feld?
• Was geschieht, wenn der Wert fehlt?

Fehlt eine Information im Quellsystem, kann das Mapping sie nur über eine definierte Regel erzeugen. Fachbereich, ERP-Verantwortliche und Integrationsteam legen gemeinsam fest, wie der Wert bereitgestellt wird.

5. Bestehende Mapping-Logik prüfen

Über Jahre gewachsene Mappings enthalten oft Sonderregeln, die auf den ersten Blick kaum erkennbar sind. Typische Beispiele sind:

• partnerabhängige Bedingungen
• unterschiedliche Regeln für Länder oder Gesellschaften
• Umrechnungen von Einheiten
• Zuordnungen von Artikel- oder Kundennummern
• feste Standardwerte
• Ausnahmen für bestimmte Belegarten
• individuelle Prüfungen und Fehlermeldungen

Klären Sie vor der Anpassung, welche dieser Regeln weiterhin gebraucht werden. Die Änderung ist zugleich eine gute Gelegenheit, veraltete oder doppelte Logik zu bereinigen.

6. Aussagekräftige Testdaten bereitstellen

Ein Mapping ist nur so gut getestet wie die Testdaten, die dafür bereitstehen. Eine einzelne Musterdatei deckt selten alle relevanten Fälle ab. Prüfen Sie neben dem Normalfall auch besondere Konstellationen:

• Belege mit einer und mit mehreren Positionen
• optionale und verpflichtende Angaben
• unterschiedliche Artikel- oder Belegarten
• Rabatte, Zuschläge oder abweichende Mengeneinheiten
• Sonderzeichen und lange Texte
• fehlende oder ungültige Werte
• länder- oder partnerabhängige Varianten
• bewusst erzeugte Fehlerfälle
• Echtdaten weiterer Partner für den Regressionstest

Mit diesen Testfällen sehen Sie, ob Daten korrekt umgesetzt und Fehler zuverlässig erkannt werden.

7. Technische und fachliche Tests trennen

Ein technisch fehlerfrei verarbeitetes Dokument kann fachlich trotzdem falsch sein. Die Abnahme sollte deshalb drei Perspektiven abdecken.

Technische Prüfung

• Kann die Nachricht eingelesen werden?
• Läuft das Mapping ohne technischen Fehler?
• Entspricht das Ergebnis der erwarteten Struktur?
• Werden Pflichtfelder und Formatregeln eingehalten?
• Werden Quittungen korrekt erzeugt und verarbeitet?
• Funktioniert die Übertragung über den vereinbarten Kommunikationsweg, etwa AS2 oder OFTP2?

Fachliche Prüfung

• Sind Bestellnummern, Artikel und Mengen korrekt?
• Werden Preise, Steuern und Währungen richtig verarbeitet?
• Stimmen Liefer- und Rechnungsadressen?
• Wird der Beleg im Zielsystem richtig verbucht?
• Laufen die nachfolgenden Prozesse wie erwartet?

Regressionstest

• Verarbeiten alle weiteren Partner, die dasselbe Mapping nutzen, ihre Nachrichten weiterhin fehlerfrei?

Die fachliche Abnahme übernehmen Personen, die den zugrunde liegenden Geschäftsprozess kennen.

8. Geschäftspartner frühzeitig einbinden

Wurde die Änderung durch einen Kunden, Lieferanten oder Logistikpartner ausgelöst, gehört dieser in die Testplanung. Stimmen Sie vor dem Produktivstart folgende Punkte ab:

• technische Spezifikation
• Testzeitraum
• Ansprechpartner auf beiden Seiten
• Anzahl und Art der Testfälle
• Umgang mit Fehlern
• Kriterien für die Abnahme
• geplanter Produktivtermin
• Dauer eines möglichen Parallelbetriebs
• Vorgehen bei Problemen nach der Umstellung

Eine klare Abstimmung stellt sicher, dass die Änderung auch beim Geschäftspartner wie erwartet verarbeitet wird.

9. Produktivsetzung und Rückfallplan vorbereiten

Auch nach erfolgreichen Tests bleibt bei jeder Änderung ein Restrisiko. Die Produktivsetzung sollte deshalb geplant und eng begleitet werden. Zur Vorbereitung gehören:

• Sicherung der bisherigen Mapping-Version
• dokumentierter Termin für die Umstellung
• Information aller beteiligten Teams
• geklärte Zuständigkeiten
• verstärkte Überwachung nach der Aktivierung
• Prüfung der ersten produktiven Nachrichten
• definierter Rückfallplan
• schnelle Erreichbarkeit der technischen Ansprechpartner

Bei geschäftskritischen Bestell-, Liefer- und Rechnungsprozessen steht vorab fest, wer bei einem Fehler wie reagiert.

10. Dokumentation aktualisieren

Mit der erfolgreichen Umstellung ist die Aufgabe noch nicht abgeschlossen. Halten Sie zum Abschluss folgende Informationen fest:

• Grund und Umfang der Änderung
• alte und neue Formatversion
• angepasste Mapping-Regeln
• durchgeführte Testfälle
• bekannte Ausnahmen
• beteiligte Systeme und Partner
• Datum der Produktivsetzung
• verantwortliche Ansprechpartner

Eine aktuelle Dokumentation erleichtert spätere Anpassungen, Fehleranalysen und Vertretungssituationen.

Kompakte Checkliste für Ihre nächste Mapping-Änderung

Vor der Umsetzung

• Anforderung und Termin liegen schriftlich vor
• Betroffene Nachrichten, Systeme und Geschäftspartner sind bekannt
• Quell- und Zielformat wurden verglichen
• Benötigte Daten sind im ERP-System verfügbar
• Bestehende Sonderregeln wurden geprüft
• Verantwortlichkeiten sind geklärt

Vor der Produktivsetzung

• Aussagekräftige Testdaten liegen vor
• Technische und fachliche Tests sind abgeschlossen
• Regressionstests für weitere Partner sind bestanden
• Der Geschäftspartner hat das Ergebnis freigegeben
• Produktivtermin und Parallelbetrieb sind abgestimmt
• Die bisherige Mapping-Version ist gesichert
• Überwachung und Rückfallplan sind vorbereitet

Nach der Produktivsetzung

• Erste produktive Nachrichten wurden geprüft
• Fehler und Auffälligkeiten wurden ausgewertet
• Die Dokumentation ist aktualisiert
• Beteiligte Teams wurden über den Abschluss informiert

Fazit: Eine Mapping-Änderung betrifft die ganze Prozesskette

Eine Änderung am EDI-Mapping wirkt über mehrere Systeme und Prozessschritte hinweg. Entscheidend sind vollständige Anforderungen, belastbare Testdaten, eine fachliche Abnahme und die Abstimmung mit dem Geschäftspartner. Wer diese Punkte vorab klärt, setzt Format- und ERP-Updates kontrolliert um.

aurebus entwickelt, ändert und testet EDI-Mappings in SEEBURGER BIS. Dazu gehören die Integration verschiedener Datenformate, Partner-Onboarding, Testing sowie die Anbindung von ERP-Systemen und APIs.

Steht bei Ihnen eine Formatänderung, ein ERP-Update oder die Umstellung auf E-Rechnung an? Wir prüfen gemeinsam, welche Mappings, Systeme und Partner betroffen sind und wie Sie die Änderung kontrolliert umsetzen.