skip to Main Content

INVOIC

Branchenübergreifender Standard-Nachrichtentyp zur Übermittlung von Rechnungsdaten

Der EDI-Geschäftsprozess INVOIC-Rechnung wird branchenübergreifend zur Übermittlung von Rechnungsdaten verwendet und findet sowohl im Handel als auch in der Automobilbranche als EDI-Standardprozess eine breite Anwendungspalette.

Der Prozess gilt allgemein als relativ anspruchsvoll, da in den EDI-Anforderungskatalogen ein vergleichsweise großer Umfang an EDI-Dateninhalten eingefordert wird. Dabei wird vor dem Hintergrund der immensen Einsparungspotenziale, die sich die großen Marktteilnehmer von einem digitalisierten Rechnungseingang versprechen, oftmals auch ein gewisser Druck auf die Zulieferer ausgeübt, diesen Prozess mittels EDI-Technologien abzubilden. Die Zahlen für das Potenzial einer Kostenreduktion durch EDI Prozesse beim Rechnungseingang im Vergleich zur manuellen Erfassung variieren je nach Szenario zwischen 5 und 40 Euro. Pro Beleg!

Der EDI-Nachrichtentyp INVOIC-Rechnung existiert innerhalb der diversen EDI-Formate in unterschiedlichen Nomenklaturen:

Nachrichtentyp INVOIC–Rechnung in den unterschiedlichen EDI-Formaten

  • UN/EDIFACT Rechnung: INVOIC
  • ANSI X.12 Rechnung: ANSI X12 810
  • VDA Rechnung: VDA 4906
  • VDA Rechnung: VDA 4938 Global INVOIC
  • PDF Rechnung: ZUGFeRD
  • ODETTE Rechnung: INVOIC
  • XML Rechnung: Invoice o.ä.

Individuelle Anforderungen an Inhalte von EDI-Rechnungen

Die Anforderungen an die Inhalte der EDI-Rechnungen sind sehr stark partnerindividuell ausgeprägt. Die EDI-Dokumentationen der geforderten Rechnungsinhalte spiegeln die semantischen Anforderungen der unterschiedlichen Warenwirtschaftssysteme auf Kundenseite wieder. Da das Prozessdesign zur Verarbeitung der EDI-bürtigen Rechnungsdaten auf einer sehr heterogenen Ebene angesiedelt ist, können die Vorgaben je nach Rechnungsempfänger stark variieren. Die Darstellung von Rabatten, Zu- und Abschläge auf Kopf- und Positionsebene sowie die Rundungsproblematik sind nur einige der Facetten, die es bei der Implementierung von EDI-Rechnungen auf Seite des Versenders zu berücksichtigen und korrekt darzustellen gilt. Selbst in Bereichen mit starken Standardisierungstendenzen – wie z.B. dem AK-Handel – wird man feststellen, dass eine Handelskette wie Metro eine MGE-Lieferantennummer in den EDI-Rechnungen verlangt, während dieses Datenelement natürlich bei Edeka, Rewe & Co. keine Rolle spielt.

Fehlerhafte EDI-Rechnungen führen zu Zahlungsverzögerungen

Dabei existiert wenig bis kein Spielraum für Abweichungen von den Spezifikationen, die in den diversen EDI-Dokumentationen für einen korrekten elektronischen Rechnungsaustausch definiert sind. Auf Empfängerseite existieren fast durchgehend automatisierte Validierungsprogramme, die vor der eigentlichen Verarbeitung der elektronischen Rechnungen im dahinter liegenden ERP-System zunächst die syntaktische Korrektheit des EDI-Belegs prüfen, um hernach eine semantische Plausibilitätsprüfung durch zuführen. Durchläuft die EDI-Rechnung die Vorverarbeitung  im Rahmen des EDI-Eingangsprozesses ohne Beanstandung, wird die Rechnung beglichen. Wird eines der Prüfkriterium verletzt, wird die Rechnung abgelehnt, der Lieferant erhält eine automatisierte Fehlerbenachrichtigung, und i.d.R verschiebt sich das entsprechende Zahlungsziel auf einen späteren Zeitpunkt. Dies kann insbesondere bei höheren Rechnungsvolumina empfindliche monetäre Einbußen zur Folge haben.

Korrekte Formate durch vorgelagerte Plausibilitätsprüfungen

Softzoll unterstützt seine Kunden nicht nur auf syntaktischer Ebene, indem das korrekte Rechnungsausgangsformat sichergestellt wird. Softzoll ist außerdem in der Lage, eine Plausibilitätsprüfung der EDI-Rechnungen vice versa zu implementieren. Die ausgehenden EDI-Rechnungen werden dabei zunächst in die Transaktionsdatenbank des EDI-Systems überführt und dort gesammelt. Anschließend durchlaufen die aus dem ERP-System generierten Rechnungsdaten eine vorgelagerte Plausibilitätsprüfung.

Beispielhafte Kriterien für eine Plausibilitätsprüfung

Nachfolgend sind Beispiele für Prüfungen nach vorgegebenen inhaltlichen Bedingungen aufgeführt (für ein- und ausgehende Rechnungen). Diese Prüfbedinungen können individuell angepasst werden.

Basiswerte Prüfung Rechnungseingang/-ausgang

  • Es fehlt der Absender der Datei in Feld
  • Es fehlt der Empfänger der Datei in Feld
  • Es fehlt die fortlaufende Nummerierung des Datensatzes im Beleg in Feld LinNum.
  • Es fehlt die Rechnungs-Nr
  • Es fehlt die Rechnungs-Art
  • Es fehlt das Rechnungs-Datum
  • Es fehlt das Datum der Leistungserbringung
  • Es fehlt die Lieferschein-Nr
  • Es fehlt das Lieferschein-Datum
  • Es fehlt die Auftrags-Nr. des Kaeufers
  • Es fehlt das Auftrags-Datum des Kaeufers
  • Es fehlt der maßgebliche MWSt-Satz
  • Es fehlt die Steuerkategorie (S=Einheitssatz, E=Steuerbefreit)
  • Es fehlt die Währung
  • Es fehlt der Gesamtbetrag der Rechnung
  • Es fehlt der Gesamt-Positionsbetrag
  • Es fehlt der Gesamt-Steuerbetrag
  • Es fehlt der steuerpflichtige Betrag

Beteiligte

  • Die GLN des Lieferanten fehlt
  • Die GLN des Kaeufers fehlt
  • Die GLN des Warenempfaengers fehlt

Zu-/Abschläge auf Kopfebene

  • Es fehlt der Code fuer die Art des Zu-/Abschlages (DI=Rabatt, EAB=Skonto, FC=Frachtgebuehren)
  • Es fehlt die Angabe der Kalkulationsstufe
  • Es fehlt die Angabe des Zu-/Abschlags-Geldbetrages (ohne Vorzeichen)
  • Es fehlt die Angabe des Zu-/Abschlags-Prozentsatzes (ohne Vorzeichen)
  • Der Zu-/Abschlags-Geldbetrag muss ohne Vorzeichen angegeben werden
  • Der Zu-/Abschlags-Prozentsatz muss ohne Vorzeichen angegeben werden

Position

  • Es fehlt die Mengeneinheit der fakturierten Menge
  • Es fehlt die Mengeneinheit der Menge ohne Berechnung
  • Es fehlt die Mengeneinheit der Verbrauchereinheiten je fakturiertem Gebinde
  • Es fehlt die Mengeneinheit der Verbrauchereinheiten je fakturiertem Display
  • Es fehlt die Mengeneinheit der Displays bei Fakturierung der Inhaltsartikel
  • Es darf nur ein Verfahren verwendet werden, entweder Brutto- oder Netto-Beträge

Zu-/Abschläge auf Positionsebene

  • Es fehlt der Code fuer die Art des Zu-/Abschlages (DI=Rabatt, EAB=Skonto, FC=Frachtgebühren)
  • Es fehlt die Angabe der Kalkulationsstufe
  • Es fehlt die Angabe des Zu-/Abschlags-Geldbetrages (ohne Vorzeichen)
  • Es fehlt die Angabe des Zu-/Abschlags-Prozentsatzes (ohne Vorzeichen)
  • Der Zu-/Abschlags-Prozentsatz muss ohne Vorzeichen angegeben werden
  • Der Zu-/Abschlags-Geldbetrag muss ohne Vorzeichen angegeben werden

Summen-Prüfung

  • Summe der Zu-/Abschläge
  • Es fehlt die Summe der Zu-/Abschläge

Gesamt-Positionsbetrag

  • Der Gesamt-Positionsbetrag im Beleg entspricht nicht der Summe aller Positions-Bruttobeträge
  • Der Gesamt-Positionsbetrag im Beleg entspricht nicht der Summe aller Positions-Nettobeträge

Steuerpflichtiger Betrag

  • Der angegebene steuerpflichtige Betrag stimmt nicht

Gesamt-Steuerbetrag

  • Der Gesamt-Steuerbetrag (100.NP2_3) wurde nicht korrekt errechnet

Gesamtbetrag der Rechnung

  • Der Gesamtbetrag der Rechnung stimmt nicht.

Vermeidung von Zahlungsausfällen durch intelligente Plausibilitätskriterien

Jede einzelne EDI-Rechnung – und bei Bedarf auch eine zugehörige EDI-Sammelrechnung – wird auf die hinterlegten Kriterien überprüft. Wird eine Verletzung der Plausibilitätskriterien festgestellt, werden der betroffene Beleg suspendiert und eine Fehlermeldung generiert. Alle validen Belege, die konform der hinterlegten Rahmenparameter sind, werden weiterverarbeitet, konvertiert und über den gewählten EDI-Kommunikationsweg an den Rechnungsempfänger versendet. Durch diese Vorgehensweise wird vermieden, dass aufgrund eines fehlerhaften Belegs der komplette Rechnungsversand via EDI scheitert, bzw. der gesamte Rechnungsblock beim EDI-Partner abgelehnt wird. Es wird sichergestellt, dass zumindest alle korrekten Belege durch den Empfänger der EDI-Rechnungen verarbeitet und beglichen werden, ein kompletter Zahlungsausfall wird vermieden.

Plausibilitätsprüfung auf Datenbankebene

Diese Plausibilitätsprüfung übernimmt im Rahmen der Softzoll EDI-Technologie eine gekapselte Entität auf Datenbankebene. Dadurch dass diese nicht in die entsprechenden Konvertierungslogiken auf ERP- oder EDI-Seite eingebettet ist, kann die Plausibilitätsprüfung über einzelne Anwendungsbereiche portiert und wiederverwendet werden.Eine  Nutzung für den globalen EDI-Prozess Rechnung ist ebenso möglich wie eine partnerspezifische Anpassung oder der Einsatz für individuelle Anforderungen eines speziellen Rechnungsempfängers.

Zurück zur Übersicht
Back To Top