Prozessverlauf (Inbound)
Der Prozessverlauf im Inbound Monitor (Button
Process History) beschreibt alle internen Verarbeitungsschritte, die unmittelbar nach dem Eingang eines Belegs erfolgen.
Die interne Verarbeitung hat das Ziel, eingehende Belege technisch korrekt zu erfassen und sie eindeutig zuzuordnen. Auf diese Weise können die Belege konsistent in das xSuite-eDNA Helix-interne Format überführt und sicher weiterverarbeitet werden.
Der Prozessverlauf enthält folgende Verarbeitungsschritte:
Verarbeitungsschritt | Beschreibung | |
|---|---|---|
1 | New | Annahme des Belegs und technische Datenprüfung |
2 | Download document | Download des Belegs in konnektorabhängigem Format |
3 | Download attachments | Download der Dateianhänge und Prüfung eingehender Belege |
4 | Create PDF visualization | Erstellung einer PDF-Visualisierung |
5 | Post processing | Nachverarbeitung |
6 | Received | vollständiger Empfang des Belegs |
Verarbeitungsschritt "New" (Inbound)
Im Verarbeitungsschritt New nimmt xSuite eDNA Helix einen eingehenden Beleg über einen definierten Eingangskanal entgegen. Unabhängig vom Eingangskanal werden dabei die folgenden Daten erfasst:
Zeitpunkt des Belegeingangs
xSuite-eDNA-Helix-Mandant und steuerrechtliche Einheit (Unternehmen)
Quellsystem / technischer Absender des Belegs
Der Annahmevorgang der Belege stellt sicher, dass die Belege alle vollständig und unverändert in xSuite eDNA Helix gespeichert werden. Nach erfolgreicher Annahme erzeugt xSuite eDNA Helix für jeden Beleg ein Workitem zur weiteren Verarbeitung.
Ein Workitem enthält die folgenden Daten:
technische und fachliche Metadaten zum Belegeingang
eindeutige Referenzen für die Nachverfolgung
Verarbeitungsschritt "Download document" (Inbound)
Im Verarbeitungsschritt Download document lädt xSuite eDNA Helix den Beleg in einem spezifischen Format herunter. Das Format des Belegs ist abhängig vom jeweiligen Konnektor und kann z. B. eine JSON-Datei oder eine XML-Datei sein. Diese Datei wird in das interne xSuite-eDNA-Helix-Format konvertiert. Dadurch wird in xSuite eDNA Helix ein Workitem erzeugt. Der heruntergeladene Beleg wird im zugehörigen Workitem gespeichert.
Unter Inbound → Invoices werden die Daten des Workitems angezeigt, z. B. der Bruttobetrag, der Nettobetrag und der Steuerbetrag.
Verarbeitungsschritt "Download attachments" (Inbound)
Im Verarbeitungsschritt Download attachments lädt xSuite eDNA Helix die Dateianhänge des Belegs herunter, die über den jeweiligen Konnektor bereitgestellt werden. Die Dateianhänge speichert xSuite eDNA Helix im zugehörigen Workitem.
xSuite eDNA Helix lädt die folgenden Dateianhänge herunter:
Originalbeleg des Absenders
über den Konnektor heruntergeladene Belege in spezifischem Format
weitere Dateianhänge (optional)
Eingehende E-Rechnungen, die der europäischen Norm EN 16931 unterliegen, werden in xSuite eDNA Helix durch den KoSIT-Validator geprüft (siehe Prüfung eingehender elektronischer Belege). Die Art der durchgeführten Prüfung ist abhängig vom Konnektor.
Konnektor | Prüfung |
|---|---|
Office365-Konnektor |
|
Ecosio-Konnektor |
|
Achtung
Für die polnischen Formate FA(2) und FA(3) im KSeF wird keine Formatprüfung durchgeführt.
Prüfung eingehender elektronischer Belege
xSuite eDNA Helix prüft eingehende elektronische Belege in den Formaten "BIS Billing" (Peppol), "XRechnung" und "ZUGFeRD" automatisiert auf Konformität mit der europäischen Norm EN 16931 sowie auf Konformität mit der CIUS (Core Invoice Usage Specification) von XRechnung und BIS Billing.
xSuite eDNA Helix verwendet für die Prüfung offizielle Schematron-Prüfregeln der Europäischen Union ("Validation Artefacts") sowie formatspezifische Artefacts von KoSIT (Format "XRechnung") und Peppol (Format "BIS Billing"). Das Ergebnis wird in einem maschinenlesbaren Prüfprotokoll als XML-Datei und in einem HTML-Report bereitgestellt.
Rechtliche Einordnung
Die Prüfung der eingehenden elektronischen Belege dient der rechtlichen Absicherung im Sinne des § 14 Abs. 1 UStG. Nur Rechnungen, die der Norm EN 16931 oder der Richtlinie 2014/55/EU des Europäischen Parlaments entsprechen, gelten in Deutschland als elektronische Rechnungen im Sinne des Umsatzsteuergesetzes.
Wenn Rechnungen dieser Norm nicht entsprechen, sind dies sogenannte "sonstige Rechnungen". Bei "sonstigen Rechnungen" gilt in der Regel das PDF-Dokument als rechtsverbindlich. Die eingebettete XML-Datei gilt nur als Verarbeitungshilfe. Diese Regelung gilt nach aktuellem Stand gemäß §27. Abs 38 UstG bis Ende 2026.
Prüfungsablauf
xSuite eDNA Helix prüft eingehende elektronische Belege anhand folgender 3 Schritte:
Syntax-Prüfung: xSuite eDNA Helix prüft, ob der Aufbau des elektronischen Belegs den syntaktischen Vorgaben des jeweiligen Belegtyps entspricht. Diese Prüfung erfolgt anhand der XSD-Prüfdateien der Formate.
EN 16931-Prüfung: xSuite eDNA Helix prüft, ob der Inhalt des elektronischen Belegs den Vorgaben gemäß EN 16931 entspricht.
Formatprüfung: xSuite eDNA Helix prüft, ob der elektronische Beleg den formatspezifischen Regeln entspricht.
Hinweis
Einige Formate haben zusätzlich zu den Regeln der EN 16931 formatspezifische Prüfregeln. Die Formate werden in der Regel von der jeweiligen nationalen Behörde eines Landes entwickelt. Daher handelt es sich bei diesen Regeln um landesspezifische Prüfregeln.
Auswertung des Prüfreports
Achtung
xSuite eDNA Helix stellt ausschließlich das technisch und rechtlich fundierte Prüfprotokoll bereit. Die Verantwortung zur Bewertung und Verarbeitung der Rechnung liegt beim Rechnungsempfänger.
Die formale Ablehnung ist nur bei technischen oder normativen Fehlern (XML/XSD oder EN 16931 fatal) zulässig. Wir empfehlen eine formale Ablehnung oder eine Behandlung der Rechnung als "sonstige Rechnung" unter Berücksichtigung der Übergangsregelung gemäß § 27 UStG - Einzelnorm.
Rechnungen, die nicht EN16931 konform sind und akzeptiert werden, sind gemäß §15 UstG nicht vorsteuerabzugsberechtigt.
Achtung
Warnungen verbieten keine Annahme, sondern weisen auf potenzielle Unklarheiten hin. Wir empfehlen, Rechnungen mit Warnungen sorgfältig zu prüfen, insbesondere wenn diese systematisch oder bei wichtigen Geschäftspartnern auftreten.
Anhand des Prüfergebnisses entscheiden Sie, ob Sie eine Rechnung annehmen, ablehnen oder überprüfen. Die folgenden Tabelle bietet eine Übersicht über mögliche Prüfergebnisse und die empfohlenen Aktionen:
Prüfergebnis | Bedeutung | Empfehlung |
|---|---|---|
Syntax-Prüfung: XML syntaktisch valide EN 16931-Prüfung: konform | Die Rechnung ist vollständig gültig und muss akzeptiert werden. | akzeptieren |
Syntax-Prüfung: XML syntaktisch fehlerhaft | Das XML-Dokument entspricht nicht dem technischen Formatstandard (UBL 2.1 oder CII). | ablehnen |
EN 16931-Prüfung: Fehler (fatal) | Eine oder mehrere Pflichtregeln der EN 16931 wurden verletzt. Die Rechnung ist nicht gesetzeskonform. | ablehnen |
EN 16931-Prüfung: nur Warnungen | Eine oder mehrere empfohlene Regeln der EN 16931 wurden verletzt. Pflichtregeln wurden nicht verletzt. | annehmen und buchhalterisch prüfen |
Formatprüfung: Format ungültig | Für Deutschland ist die Formatprüfung irrelevant. Für andere Länder muss gemäß der gesetzlichen Vorgaben geprüft werden. | Deutschland: annehmen Anderes Land: Prüfen |
Verarbeitungsschritt "Create PDF visualization" (Inbound)
Im Verarbeitungsschritt Create PDF visualization erstellt xSuite eDNA Helix eine Visualisierung des Belegs im PDF-Format. Mithilfe der PDF-Visualisierung können Sie elektronische Belege unabhängig vom ursprünglichen Dateiformat visuell prüfen.
xSuite eDNA Helix wandelt die strukturierten Daten (z. B. XML-Daten oder JSON-Daten) in ein standardisiertes PDF-Layout für die PDF-Visualisierung um. Die fachlich relevanten Inhalte, wie z. B. Absender, Empfänger, Positionen, Beträge und Steuerinformationen, werden übersichtlich dargestellt. xSuite eDNA Helix speichert die PDF-Datei unter dem Namen {Absendername}:{Rechnungsnummer}.pdf.
Hinweis
Die PDF-Visualisierung dient ausschließlich zur Ansicht und hat keinen Einfluss auf die fachliche oder rechtliche Bewertung des Belegs. Der Originalbeleg bleibt unverändert erhalten und bildet weiterhin die maßgebliche, revisionssichere Grundlage für Verarbeitung, (technische) Validierung und Archivierung.
Verarbeitungsschritt "Post processing" (Inbound)
Im Verarbeitungsschritt Post processing führt xSuite eDNA Helix technische Nacharbeiten im Hintergrund durch.
Verarbeitungsschritt "Received" (Inbound)
Der Verarbeitungsschritt Received ist der letzte Schritt im Prozess. xSuite eDNA Helix hat den Beleg vollständig empfangen, verarbeitet und stellt den Beleg dem nachgelagerten System zur Verfügung.