EDI-Standards und Formate: So sprechen Ihre Systeme dieselbe Sprache

Ein Großkunde will ab dem nächsten Quartal nur noch elektronisch bestellen. Im Anhang seiner Mail liegt eine Guideline: Bestellungen und Lieferavise im Format EDIFACT D.96A, übertragen per OFTP2. Für viele Hersteller und Händler beginnt hier das Thema EDI.

EDI folgt einem einfachen Prinzip. Statt auf Papier oder als PDF-Anhang schickt das eine System dem anderen einen strukturierten Datensatz. Voraussetzung ist, dass beide Seiten dieselbe Sprache sprechen. Genau das leisten EDI-Standards und Formate.

Mit DIAConnect übernehmen wir die Übersetzung zwischen diesen Sprachen. Das Ergebnis: Ihre Kunden erhalten das Format, das ihr System verlangt, und Ihr ERP-System bleibt unverändert.

EDI: Elektronischer Datenaustausch nach festen Regeln

Bei EDI übermittelt ein Unternehmen einen Beleg so, dass die Software des Empfängers ihn ohne menschliches Zutun einlesen und weiterverarbeiten kann. Beteiligt sind die Systeme, in denen Belege ohnehin verwaltet werden: ERP-System, Onlineshop, Beschaffungsportal.

Am Entstehungsort des Belegs ändert sich nichts. Beim Empfänger entfällt die zweite Erfassung, also das Auslesen der Mail, das Abtippen der Positionen und das Weiterleiten an die zuständige Abteilung. Aus einem Vorgang von mehreren Minuten wird ein automatischer Schritt.

Damit die Software des Empfängers den Beleg versteht, muss sie drei Dinge wissen:

Genau das legt ein EDI-Standard fest. Beide Seiten behalten dabei ihr eigenes ERP-System; die Übersetzung findet auf der EDI-Ebene dazwischen statt. Bei einem Managed Service wie DIAConnect liegt diese Ebene beim Dienstleister.

Warum der Standard über Ihre Kundenbeziehungen entscheidet

Über den Standard entscheidet fast immer Ihr Kunde. Ein Konzern stellt seine Beschaffung nicht um, weil ein einzelner Lieferant einen anderen bevorzugt. Große Abnehmer automatisieren ihre Prozesse und ziehen die gesamte Lieferkette mit hinein. Für Sie als Lieferant bleiben damit zwei Möglichkeiten: die geforderten EDI-Prozesse umsetzen oder auf diesen Kunden verzichten.

Die gleiche Rechnung gilt in die andere Richtung. Wo Sie selbst einkaufen, geben Sie die Vorgaben vor: Ihre Lieferanten liefern Bestandsdaten, Auftragsbestätigungen und Rechnungen in dem Format, das Ihr System erwartet. Gerade bei C-Teilen mit vielen kleinen Positionen macht das den Unterschied zwischen einem automatischen Lauf und täglicher Handarbeit.

Was EDI Ihnen im Tagesgeschäft bringt

Die Anforderung kommt von außen, der Nutzen bleibt bei Ihnen:

Ausschreibungsfähigkeit: Viele Beschaffungsabteilungen setzen eine EDI-Anbindung voraus, bevor sie überhaupt über Konditionen sprechen.
Zeitersparnis: Die Gesamtzeit für die Auftragsabwicklung reduziert sich auf etwa 2 bis 4 Minuten pro Auftrag.
Weniger Nacharbeit: Strukturierte Belegdaten laufen ohne zweite Erfassung ins ERP-System. Rückfragen und Korrekturen nehmen ab.
Planbarer Einkauf: Bestandsberichte und Preislisten Ihrer Lieferanten laufen automatisch ein. Sie sehen Verfügbarkeiten und Konditionen, ohne sie anzufragen.
Ruhe im Tagesgeschäft: Eine eingerichtete Verbindung läuft dauerhaft. Je reibungsloser die Abwicklung, desto seltener steht sie zur Diskussion.
Keine Sprachbarriere: Standards arbeiten mit Codes und festen Feldern statt mit Fließtext. Eine Bestellung aus Lyon liest Ihr System genauso wie eine aus Hamburg.
Weniger Fehlerkosten: Beim Abtippen entstehen Zahlendreher. Ein falscher Einkaufspreis fällt oft erst in der Rechnungsprüfung auf. Übernimmt die Software die Daten, entfällt diese Fehlerquelle.
Vorbereitung auf die Pflicht: Die E-Rechnungspflicht verlangt strukturierte Rechnungsformate. Wer seine Belegprozesse auf EDI umstellt, kann dafür die Grundlage schaffen.

Standard, Subset, Version, Protokoll: Die vier Angaben einer EDI-Anforderung

Anforderungen aus EDI-Projekten enthalten bis zu vier Angaben: die Grammatik, den Dialekt, die Auflage des Wörterbuchs und den Zustellweg. Wie viele davon in Ihrer Anfrage stehen, hängt vom Standard ab. Wer sie auseinanderhält, kann jede Kundenanfrage sofort einordnen.

1. Der Standard

Der Standard ist die Grammatik. Er legt fest, wie eine Nachricht grundsätzlich aufgebaut ist. Zu den gängigen Standards für den elektronischen Datenaustausch gehören EDIFACT, ANSI ASC X12, openTRANS und UBL. Daneben existieren branchenspezifische Standards und Nachrichtenformate, etwa VDA in der Automobilindustrie, ISO 20022 im Finanzwesen und HL7 im Gesundheitswesen.

Zwei Gruppen begegnen Ihnen daneben, die enger gefasst sind. XRechnung und ZUGFeRD decken einen einzigen Belegtyp an, die Rechnung. SAP IDoc regelt den Weg in ein SAP-System. Beide finden Sie weiter unten im Überblick.

Welches Format Ihr Kunde verlangt, entscheidet nicht darüber, ob eine Anbindung möglich ist. DIAConnect verarbeitet diese Formate ebenso wie cXML, VDA-Formate, xCBL, TRADACOMS und Sonderformate.

2. Das Subset

Ein Subset ist der Branchendialekt eines Standards. Es beschränkt sich auf die Segmente, die eine Branche wirklich braucht, und belegt einzelne Felder mit branchenspezifischen Codes. Der Aufbau bleibt der des übergeordneten Standards, sodass eine Subset-Nachricht auch mit dem allgemeinen Regelwerk lesbar bleibt.

Subsets gibt es vor allem bei EDIFACT, in Teilen auch im VDA-Umfeld. Bei XML-Standards wie openTRANS oder cXML entfällt diese Ebene.

3. Die Verzeichnisversion

Die Verzeichnisversion ist die Auflage des Wörterbuchs. Sie legt fest, welche Nachrichtentypen und Datenelemente im Standard zur Verfügung stehen. Jede neue Ausgabe erweitert diesen Umfang. Angaben wie D.96A gehören zu EDIFACT; andere Standards führen ihre Versionen anders oder gar nicht mit.

Entscheidend ist, dass beide Seiten dieselbe Ausgabe verwenden. Deshalb fordern große Marktteilnehmer ihre Partner regelmäßig zu einem Versionswechsel auf.

4. Das Übertragungsprotokoll

Das Protokoll ist der Zustellweg. Es bestimmt, wie die fertige EDI-Datei zum Empfänger gelangt und wie sie dabei abgesichert wird. Auf den Inhalt der Datei hat es keinen Einfluss.

Format und Protokoll lassen sich kombinieren. Dieselbe EDIFACT-Bestellung kann über SFTP laufen oder über OFTP2.

Damit haben Sie das Raster. Die Anforderung „EDIFACT EANCOM D.96A über OFTP2“ nennt alle vier Angaben in einer Zeile: Standard, Subset, Verzeichnisversion und Protokoll. Was aus der Mail Ihres Kunden zunächst wie ein kryptischer Code aussah, ist damit einsortiert. Eine cXML-Anbindung kommt nur mit Standard und Protokoll aus.

Welche Standards und Formate kommen auf Sie zu?

Welche Angaben in Ihrer Kundenanfrage stehen, hängt davon ab, in welcher Branche Ihr Geschäftspartnerunterwegs ist. Diese Zuordnung gibt Ihnen eine erste Einschätzung:

Deutscher Groß- und Fachhandel: EDIFACT mit dem passenden Branchen-Subset
Automobilindustrie: VDA- und Odette-Nachrichtenformate, meist über OFTP2
SAP Ariba oder Coupa: cXML, häufig kombiniert mit einem Punchout-Katalog
SAP im direkten Einsatz: IDoc-Basistypen wie ORDERS05 und INVOIC02
Nordamerikanische Partner: ANSI ASC X12 mit Codes wie 850, 856 und 810

Für Rechnungen gilt eine eigene Logik, unabhängig davon, welcher Standard sonst zum Einsatz kommt: Öffentliche Auftraggeber verlangen immer XRechnung, im B2B-Geschäft kommen XRechnung oder ZUGFeRD in einem geeigneten Profil infrage.

Und wenn ein Geschäftspartner ein Format verlangt, das Ihr ERP nicht kennt? Dann ist eine Anbindung trotzdem möglich. Weil die Übersetzung bei DIAConnect außerhalb Ihres Systems stattfindet, spielt es keine Rolle, welches ERP bei Ihnen läuft und wie viele Formate zusammenkommen.

Ohne Guideline funktioniert es nicht

Vier Angaben zu kennen heißt noch nicht, sie umsetzen zu können. Die Standards selbst sind öffentlich, jeder kann nachlesen, wie eine ORDERS-Nachricht aufgebaut ist.

Nicht nachlesbar ist, welche Codelisten ein Geschäftspartner erwartet, welche Felder er zwingend gefüllt haben will und wo seine Guideline vom allgemeinen Standard abweicht. Diese Angaben stehen allein in seinen Unterlagen.

Fordern Sie deshalb früh die EDI-Guideline Ihres Kunden an. Sie ist die eigentliche Arbeitsgrundlage. Was darin steht, lässt sich abarbeiten, sobald jemand die Vorgaben in Ihr System übersetzt. Umgekehrt gilt dasselbe: Binden Sie Ihre eigenen Lieferanten an, stellen Sie die Guideline und geben vor, in welcher Form die Daten bei Ihnen ankommen. Wenn Sie eine Guideline vor sich haben und wissen möchten, was daraus für Ihr System folgt, sehen wir sie uns gemeinsam an.

Standards und Formate im Überblick

Die folgenden EDI-Standards und Formate begegnen Ihnen in der Praxis am häufigsten. Springen Sie zu dem Namen, der in Ihrer Kundenanfrage steht.

UN/EDIFACT: Der internationale Klassiker

EDIFACT steht für Electronic Data Interchange for Administration, Commerce and Transport. Gepflegt wird der Standard von UN/CEFACT, einer Einrichtung der Wirtschaftskommission der Vereinten Nationen für Europa (UNECE).

Die Nachrichtentypen tragen Kurznamen aus sechs Großbuchstaben: ORDERS für die Bestellung, INVOIC für die Rechnung, DESADV für das Lieferavis.

Zwei Eigenschaften prägen den Standard:

Die EDIFACT-Subsets: Dialekte einzelner Branchen

Jede Branche hat ihren eigenen Dialekt entwickelt. Drei Subsets begegnen Ihnen besonders häufig:

EANCOM: das weltweit verbreitetste Subset, entwickelt von GS1 für Handel und Konsumgüter, mit GLN und GTIN zur eindeutigen Identifikation
EDITEC: für die SHK-Branche, betreut von der ITEK und auf EANCOM aufgebaut (aktuell ist Version 4.2, Migration von Version 3.5 wird empfohlen)
EDILEKTRO: für Elektroindustrie und Elektrogroßhandel, ebenfalls auf EANCOM aufgebaut

Daneben existieren Subsets für Baustoffe, Chemie, Elektronik und die Automobilindustrie. Welches für Sie infrage kommt, ergibt sich aus der Branche Ihres Kunden.

ANSI ASC X12: Der nordamerikanische Standard

X12 entstand 1979 im Accredited Standards Committee, einer Untergliederung des American National Standards Institute. Statt sechsstelliger Buchstabenkürzel arbeitet X12 mit dreistelligen Nummern: 850 für die Bestellung, 810 für die Rechnung, 856 für das Lieferavis, 997 für die technische Empfangsbestätigung.

Neue Ausgaben erscheinen jährlich. In der Praxis arbeiten viele Branchen weiterhin mit älteren, von ihren Handelspartnern vorgeschriebenen Versionen.

VDA und Odette: Die Automobilwelt

Die Autobranche arbeitet mit eigenen Formaten, die der Verband der Automobilindustrie (VDA) definiert. Sie tragen vierstellige Nummern und decken jeweils einen Prozessschritt ab, etwa den Lieferabruf, den Lieferschein oder die Rechnung.

Auf europäischer Ebene übernimmt die Organisation Odette dieselbe Rolle. Von ihr stammen sowohl eigene Nachrichtenformate als auch das Übertragungsprotokoll OFTP, dessen Nachfolger OFTP2 in der Branche bis heute der Standardweg ist.

Die XML-Familie: openTRANS und cXML

openTRANS erschien 2001 als offener Standard des BME und ergänzt den Produktkatalog-Standard BMEcat. Beide nutzen identische Felder und Strukturen, was die Umsetzung erleichtert. Weil openTRANS auf XML basiert, sind die Feldnamen im Klartext lesbar.

cXML stammt von Ariba, das inzwischen zu SAP gehört. Der Standard begleitet einen Einkaufsvorgang von der ersten Anfrage bis zur Rechnung und ist auf Plattformen wie SAP Ariba und Coupa der Normalfall.

SAP IDoc: Das Zwischenformat aus der ERP-Welt

IDoc steht für Intermediate Document, das Zwischenformat für den Datenaustausch mit einem SAP-System. Anders als EDIFACT oder X12 ist es nicht zwischen Unternehmen abgestimmt, sondern auf ein bestimmtes ERP-System zugeschnitten.

Die wichtigsten Basistypen sind ORDERS05 für Einkauf und Vertrieb, INVOIC02 für die Rechnung, DELVRY07 für die Lieferung und DELFOR02 für den Lieferabruf. Arbeitet Ihr Geschäftspartner mit SAP, taucht dieses Format häufig im Projekt auf.

XRechnung und ZUGFeRD: Die Rechnungsformate

Beide gelten für einen einzigen Belegtyp: die Rechnung. XRechnung basiert auf der europäischen Norm EN 16931. Bei ZUGFeRD hängt die Konformität mit dieser Norm vom gewählten Profil ab.

XRechnung ist reines XML. Anders als ZUGFeRD enthält die Datei keine eingebettete PDF-Ansicht, sondern strukturierte Daten für die maschinelle Verarbeitung. Bei öffentlichen Auftraggebern spielt die XRechnung eine zentrale Rolle und ist in vielen Fällen das vorgegebene Format.
ZUGFeRD kombiniert PDF und XML in einer Datei: ein sichtbares PDF nach dem Standard PDF/A-3 und darin eingebettet die strukturierten Rechnungsdaten als XML. Der Empfänger kann die Rechnung also ansehen oder automatisch verarbeiten. Für den grenzüberschreitenden Verkehr nützlich: ZUGFeRD und das französische Factur-X sind technisch aufeinander abgestimmt.

Maßgeblich sind Version und Profil. Zulässig ist ZUGFeRD ab Version 2.0.1, ausgenommen die Profile MINIMUM und BASIC WL: Diese enthalten nicht alle erforderlichen Daten und dienen nur als Buchungshilfe. Vollständige E-Rechnungen bilden BASIC, EN 16931 (auch COMFORT genannt) und EXTENDED ab, dazu das Referenzprofil XRECHNUNG.

Nachrichtentypen und Übertragungswege

Zwei Fragen bleiben: Welche Belege tauschen Sie aus, und wie kommen sie beim Empfänger an?

Welche Nachrichtentypen Sie wirklich brauchen

In der Praxis deckt eine Handvoll Nachrichten den gesamten Prozess ab, im Verkauf von der Bestellung bis zur Zahlung, im Einkauf in umgekehrter Richtung. Dieselben Nachrichtentypen laufen dabei nur andersherum: Was Sie als Lieferant empfangen, senden Sie als Einkäufer.

Geschäftsvorgang	EDIFACT	ANSI X12	openTRANS
Bestellung	ORDERS	850	ORDER
Auftragsbestätigung	ORDRSP	855	ORDERRESPONSE
Bestelländerung	ORDCHG	–	ORDERCHANGE
Lieferavis	DESADV	856	DISPATCHNOTIFICATION
Rechnung	INVOIC	810	INVOICE
Empfangsbestätigung	CONTRL	997	–

Auf SAP-Seite kommen für diese Vorgänge unter anderem die Basistypen ORDERS05, DELVRY07 und INVOIC02 zum Einsatz.

Im SHK-Großhandel etwa tauschen Hersteller und Handel typischerweise fünf Nachrichten aus: ORDERS, ORDRSP, DESADV, INVOIC und den Bestandsbericht INVRPT. Mehr braucht es für einen sauberen Prozess zunächst nicht.

Die Übertragungswege

Welches Protokoll zum Einsatz kommt, entscheidet meist die Branche Ihres Kunden. OFTP2 kommt aus der Automobilindustrie und ist dort der Standardweg; reißt eine Übertragung ab, wird sie an der Abbruchstelle fortgesetzt, statt von vorn zu beginnen. SFTP und FTPS übertragen ganze Dateien und sind schnell eingerichtet, was für eine überschaubare Zahl an Partnern meist ausreicht. HTTP-basierte Übertragungen kommen vor allem bei einfachen Integrationen zum Einsatz.

DIAConnect unterstützt HTTPS, FTPS, SFTP, OFTP2 und den Belegaustausch per E-Mail.

E-Rechnungspflicht: Was sie für Ihre EDI-Prozesse bedeutet

Wer heute per EDI Rechnungen versendet, ist von der E-Rechnungspflicht unmittelbar betroffen. Sie schreibt vor, in welchem Format Rechnungen künftig ausgestellt werden dürfen, und betrifft damit auch Verbindungen, die seit Jahren laufen.

Definition und Fristen

Eine E-Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Eine PDF-Rechnung per E-Mail erfüllt das nicht und gilt als sonstige Rechnung. Für das Format gibt es zwei Wege: Entweder entspricht es der Norm EN 16931 oder Aussteller und Empfänger vereinbaren ein anderes. Welche Formate die Norm erfüllen, steht weiter oben im Formatüberblick.

Diese Fristen gelten:

Seit 2025: Jedes inländische Unternehmen muss E-Rechnungen empfangen können, also auch die Rechnungen seiner Lieferanten verarbeiten.
Bis 2026: Papierrechnungen bleiben zulässig. Andere elektronische Formate können mit Zustimmung des Empfängers weiterhin verwendet werden.
Bis 2027: Beide Möglichkeiten gelten für Unternehmen mit höchstens 800.000 Euro Gesamtumsatz im Vorjahr weiter.
Ab 2028: Die Übergangsregelungen laufen aus.

Quellen: dejure.org, gesetze-im-internet.de

Kurz gesagt: Empfangen müssen Sie E-Rechnungen bereits heute. Die Pflicht zum Ausstellen greift ab 2027, bei höchstens 800.000 Euro Vorjahresumsatz erst ab 2028. Beides gilt für Rechnungen zwischen inländischen Unternehmen.

Was das für bestehende EDIFACT-Verbindungen heißt

Bis Ende 2027 gilt Bestandsschutz: Rechnungen dürfen per EDI übermittelt werden, auch wenn das Format die Anforderungen an eine E-Rechnung nicht erfüllt. Voraussetzung ist die Zustimmung des Empfängers.

Darüber hinaus bleibt EDI dauerhaft möglich, aber unter einer Bedingung. Ein zwischen den Parteien vereinbartes Format ist erlaubt, die Finanzverwaltung nennt EDI-Verfahren dabei ausdrücklich als Beispiel. Aus der Rechnung müssen sich die umsatzsteuerlich erforderlichen Angaben dann allerdings vollständig in ein Format der EN 16931 überführen lassen, ohne dass Inhalt oder Bedeutung verloren gehen.

Ein Vorteil, der oft übersehen wird: Wer per EDI überträgt und in der EDI-Vereinbarung entsprechende Verfahren vorsieht, bei dem gelten Echtheit der Herkunft und Unversehrtheit des Inhalts als gewährleistet. Ein zusätzliches Kontrollverfahren entfällt. Die Anforderungen an die inhaltliche Richtigkeit, die steuerlichen Pflichtangaben und die GoBD-konforme Aufbewahrung bleiben davon unberührt.

Ihre EDI-Verbindungen müssen nicht abgeschaltet werden, aber sie müssen geprüft werden. Welche davon betroffen sind, sehen wir uns im Erstgespräch gemeinsam an.

Quellen: dejure.org, gesetze-im-internet.de

Der Blick nach 2030

Wenn Sie Kunden oder Lieferanten in anderen EU-Ländern haben, kommt ab 2030 eine weitere Anforderung dazu. Das ViDA-Paket führt digitale Meldepflichten für innergemeinschaftliche Umsätze ein.

Für Ihre Formatwahl ist ein Detail wichtig: Die zu meldenden Angaben müssen der europäischen Norm für die elektronische Rechnungsstellung nach Richtlinie 2014/55/EU entsprechen, also der EN 16931.

Damit taucht dieselbe Norm zum zweiten Mal auf. Sie entscheidet schon heute darüber, ob sich aus Ihrem EDI-Format eine gültige E-Rechnung ableiten lässt, und ab 2030 zusätzlich über Ihre Meldepflichten. Wer sein Format daran ausrichtet, deckt beides mit einer Entscheidung ab.

Quellen: dejure.org, gesetze-im-internet.de

Die Einführung mit DIAConnect

Wer die Anforderungen seiner Kunden erfüllen will, braucht dafür kein eigenes EDI-Wissen im Haus. Mit DIAConnect überlassen Sie die technische Seite uns: Betrieb, Umsetzung, die Anbindung Ihrer Kunden und Lieferanten sowie die Überwachung des Belegflusses. Auf Ihrer Seite bleibt nur das Versenden und Empfangen der Belege.

Was Sie dabei erwartet

Planbarer Zeitrahmen: Von der ersten Abstimmung bis zum produktiven Betrieb vergehen etwa acht Wochen. Die Einführung läuft in vier Schritten, vom Kick-off über das technische Setup und die Übergabe bis zur laufenden Betreuung.
Fehlererkennung inklusive: Das System meldet sich nur bei Abweichungen, etwa wenn ein Einkaufspreis oder eine Lieferzeit nicht zu Ihren Daten passt.
Mitwachsend: Kommt später ein Partner mit einem anderen Standard hinzu, richten wir die Verbindung ein, ohne dass Sie eingreifen müssen.
Vorab kalkulierbar: In unseren Projekten sinkt der Zeitaufwand in der Auftragsabwicklung um bis zu 90 Prozent. Der EDI-ROI-Rechner zeigt Ihnen die Größenordnung Ihrer Ersparnis in wenigen Minuten.

DIA: Aus dem Handel für den Handel

Welchen EDI-Standard Sie unterstützen, entscheiden Sie selten selbst. Wer die geforderten Formate nicht liefern kann, kommt für automatisierte Beschaffungsprozesse nicht in Betracht, und die Anforderungen an die Rechnung kommen in den nächsten Jahren dazu. Ein EDI-Experte müssen Sie deshalb trotzdem nicht werden.

DIA arbeitet seit 2004 mit Herstellern und Händlern an ihren Belegprozessen. Unsere Geschäftsleitung war jahrzehntelang selbst im Handel tätig und kennt die Abläufe aus eigener Erfahrung. Wir lesen die Guideline Ihres Kunden, bauen die Verbindung und halten sie in Betrieb.

EDI ist bei uns Teil eines größeren Ganzen: Der B2B-Onlineshop DIASales, das Datennetzwerk DIAInterlink und das Beschaffungsportal DIAProcure greifen ineinander. Was davon zu Ihnen passt, klären wir im persönlichen Gespräch.

FAQ: Häufige Fragen zu EDI-Standards und Formaten

Welche Arten von EDI-Lösungen gibt es?

Vier Modelle sind üblich. Bei Direct EDI richten Sie jede Verbindung zu jedem Partner selbst ein und betreiben sie auch selbst. Ein VAN ist ein Vermittlungsnetzwerk, über das mehrere Partner erreichbar sind. Ein EDI-Modul im ERP-System integriert die Funktion direkt in Ihre bestehende Software, bindet sie damit aber fest an dieses System. Bei einem Managed Service betreibt ein Dienstleister die Lösung für Sie.

DIAConnect gehört zur letztgenannten Kategorie und arbeitet als Clearing-Center: Wir stellen die Verbindungen her, halten sie in Betrieb und behalten den Belegfluss im Blick.

Kann ich EDI-Nachrichten selbst programmieren?

Technisch ja. Eine EDIFACT-Datei ist eine Textdatei aus Segmenten: UNB eröffnet den Austausch, UNH die einzelne Nachricht, dazwischen stehen etwa NAD für die Partner und LIN für jede Bestellposition. Der Aufwand liegt aber nicht im Schreiben der Datei, sondern in allem, was danach kommt: die Guideline des Kunden umsetzen, die Verzeichnisversion verwenden, Codelisten abgleichen, testen und überwachen. Die häufigsten Stolpersteine sind eine fehlerhafte Umschlagstruktur, unterschiedliche Codelisten und falsche Stammdaten. Bei der zweiten Kundenanbindung beginnt vieles davon von vorn.

Was passiert, wenn ein Partner auf eine neue Verzeichnisversion umstellt?

Große Marktteilnehmer fordern ihre Partner im Abstand von drei bis sechs Jahren zu einem Versionswechsel auf, weil mit jeder Ausgabe neue Nachrichtentypen und Datenelemente hinzukommen. Für Sie bedeutet das eine Anpassung des Mappings, nicht den Neubau der Verbindung. Beide Seiten müssen dieselbe Ausgabe verwenden, deshalb wird der Umstellungstermin abgestimmt und die Umstellung vorher getestet.

Wie lange muss ich E-Rechnungen aufbewahren?

Acht Jahre. Bei einer E-Rechnung ist zumindest der strukturierte Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form erhalten bleibt. Bei hybriden Formaten wie ZUGFeRD kann auch der sichtbare PDF-Teil aufbewahrungsrelevant sein, wenn er steuerlich relevante Informationen enthält, die nicht im strukturierten Datensatz enthalten sind. Werden E-Rechnungen außerhalb eines GoBD-konformen Datenverarbeitungssystems gespeichert und archiviert, liegt darin allein noch kein Verstoß gegen die Aufbewahrungspflicht.

Quelle: bundesfinanzministerium.de

Was kostet eine EDI-Anbindung?

Das hängt von der Zahl Ihrer Partner ab, von den Nachrichtentypen und davon, wie weit die Vorgaben Ihrer Kunden vom Standard abweichen. Dazu kommt der laufende Betrieb, der bei einem Managed Service im Service enthalten ist. Eine erste Größenordnung liefert der EDI-ROI-Rechner, die konkreten Zahlen rechnen wir im Erstgespräch gemeinsam durch.

Unser Standort

In Schortens, direkt an der Nordsee, kombinieren wir klare Köpfe mit klarer Brise – für Ergebnisse, die frischen Wind in Ihr Business bringen.

Für eine Zusammenarbeit müssen Sie hier aber nicht vorbeikommen. Wir besprechen alle Details mit Ihnen per Videokonferenz. Auf Wunsch, besuchen wir Sie aber auch an Ihrem Standort.