Melasoft GmbH, Frankfurt am Main
Für die meisten Finanzteams begann der Übergang zur digitalen Rechnungsstellung mit einem kleinen und sinnvollen Schritt: Aufhören zu drucken, ein PDF anhängen, die E-Mail senden. Die Rechnung kommt innerhalb von Sekunden an, der Versand kostet nichts und sie sieht genauso aus wie das Papierdokument, das sie ersetzt hat. Genau dieser letzte Punkt ist das Problem. Nach der europäischen Norm EN 16931 und den nationalen Vorgaben, die derzeit in ganz Europa eingeführt werden, ist ein PDF eher ein Bild einer Rechnung als eine Rechnung selbst. Die eigentliche Frage hinter PDF versus E-Rechnung ist weder die Dateigröße noch die Bequemlichkeit, sondern ob die Daten im Dokument von einer Maschine gelesen werden können. Nachfolgend erfahren Sie, was das in der Praxis bedeutet und was Sie einen Anbieter fragen sollten, bevor Sie unterschreiben.
Warum eine PDF-Datei keine elektronische Rechnung ist
Ein PDF ist für das menschliche Auge konzipiert. Es fixiert Text in einem Layout, sodass das Dokument überall identisch aussieht, enthält jedoch keine zuverlässige Struktur im Hintergrund. Nichts in der Datei teilt einem empfangenden System mit, welcher Betrag der Nettobetrag, welcher der Mehrwertsteuersatz und welcher die Käuferreferenz ist. Eine maschinenlesbare Rechnung leistet genau das: Jedes Feld wird vor dem Verlassen des Senders beschriftet, typisiert und anhand eines Schemas validiert.
Die Kosten dieser Lücke schlagen in den Kreditorenbuchhaltungen zu Buche. Jemand tippt den Kopfdatensatz neu ein, jemand anderes läuft einer fehlenden Bestellnummer hinterher, und die Fehler tauchen Wochen später bei der Umsatzsteuervoranmeldung auf. Es gibt eine rühmliche Ausnahme. Hybride elektronische Rechnungsformate wie Factur-X in Frankreich und ZUGFeRD in Deutschland betten eine XML-Datei in einen PDF/A-3-Container ein, sodass der Empfänger jede der beiden Versionen lesen kann. Das ist eine nützliche Brücke für Lieferanten, die noch nicht vollständig strukturiert arbeiten können, aber man sollte sich im Klaren darüber sein, was die Rechnungsformate tatsächlich konform macht: das XML, nicht die PDF-Hülle.
Die XML-Schicht: Ein Standard, viele Dialekte
XML-E-Rechnungen sind das technische Fundament fast jeder europäischen Vorgabe, doch es gibt keine einzige Datei, die allen Anforderungen gerecht wird. Die EN 16931 definiert ein semantisches Datenmodell mit zwei zulässigen Syntaxen, UBL 2.1 und UN/CEFACT CII, und jeder Mitgliedstaat legt daraufhin seine eigenen Regeln fest. Ein europaweit agierendes Unternehmen sieht sich typischerweise mit Folgendem konfrontiert:
| Markt | Erforderliches Format | Typischer Kanal |
|---|---|---|
| Deutschland | XRechnung, ZUGFeRD (hybrides PDF/A-3 plus XML) | Peppol, E-Mail |
| Frankreich | Factur-X, UBL, CII | Zugelassene Plattform für das DGFiP |
| Italien | FatturaPA | SdI-Sicherheitsüberprüfung |
| Polen | Durch KSeF definierte strukturierte XML | KSeF |
| Belgien | Peppol BIS Billing 3.0 | Peppol |
| Slowakei | UBL und CII gemäß EN 16931 | Nationaler Umtausch ab 2027 |
Die Unterstützung von “XML” im Abstract bedeutet daher sehr wenig. Die Einhaltung strukturierter Rechnungsformate bedeutet benannte Formate in spezifischen Versionen, die bei Änderungen dieser Versionen aktuell gehalten werden. Docnova unterstützt XRechnung, ZUGFeRD, UBL, Peppol BIS und FatturaPA neben anderen gesetzlich vorgeschriebenen Formaten, und Melasoft agiert als akkreditierter Peppol-Zugangspunkt, sodass sich der Übertragungskanal und die Formatbibliothek in einer einzigen Plattform statt in zwei Verträgen befinden.
Was strukturierte Daten Ihnen tatsächlich bringen
Die Compliance ist der Auslöser für die meisten Projekte, aber der tatsächliche Nutzen liegt in strukturierten E-Rechnungsdaten. Da jedes Feld maschinenlesbar ist, kann eine Rechnung vor dem Versand validiert werden, anstatt nach dem Versand abgelehnt zu werden. Docnova führt diese Prüfungen in Echtzeit durch – das ist der Unterschied zwischen einem Validierungsfehler, den Sie im Cockpit korrigieren, und einem, den Ihnen Ihr Kunde oder eine Steuerbehörde meldet.
Im weiteren Verlauf summieren sich die Vorteile. Das System des Käufers kann das Dokument ohne manuelles Eingreifen buchen, wodurch sich die Zahlungszyklen verkürzen. Derselbe Datensatz speist MwSt-Vormeldungen, E-Reporting und SAF-T-Exporte ohne eine zweite Datenerhebung. Und das Archiv wird durchsuchbar, was bedeutet, dass eine Prüfungsfrage mit einem Filter beantwortet wird, anstatt dreihundert PDFs zu öffnen.
Konvertierung von Rechnungsformaten: Die Funktion, die jeder unterschätzt
Dies ist der Teil, den die meisten Evaluierungen überspringen. Ihr ERP-System erzeugt eine Ausgabe. SAP gibt möglicherweise ein IDoc oder ein eigenes XML aus, während Oracle, Dynamics oder ein maßgeschneidertes System etwas völlig anderes ausgeben. Zwölf Märkte verlangen jeweils etwas anderes. Die Konvertierung von Rechnungsformaten ist daher der Motor jeder ernsthaften Plattform: Einmaliges Mapping vom Quellsystem, Transformation in jedes Zielformat und Absorbieren von Schemaänderungen, sobald diese eintreffen.
Die Eingangsseite verdient das gleiche Gewicht. Lieferantendokumente werden noch jahrelang als PDFs, Scans und Portal-Downloads eintreffen, daher gehören die digitale Rechnungsdatenerfassung und die Kreditorenbuchhaltungs-Automatisierung in dieselbe Lösung wie Ihr Ausgangsfluss. Andernfalls automatisieren Sie die Debitorenbuchhaltung und überlassen der Kreditorenbuchhaltung die Tipparbeit. Eine direkte Frage trennt hier die Anbieter: Wer pflegt die Mappings, wenn sich eine Formatversion ändert, und ist diese Arbeit im Preis inbegriffen oder wird sie pro Änderung abgerechnet?
Die Integration ist Teil der Formatunterstützung
Die Integration von Rechnungs-XML sollte für ein Projektteam niemals bedeuten, XML von Hand zu schreiben. Drei Muster decken fast jede Anforderung ab, und die meisten Gruppen benötigen mehr als eines:
- Der Melasoft SAP Add-On hält den gesamten Prozess innerhalb von SAP ECC oder S/4HANA, sodass die Benutzer in vertrauten Transaktionen bleiben.
- Ein API-First-Ansatz eignet sich für Oracle, Microsoft Dynamics und maßgeschneiderte ERPs, da er die Plattform direkt mit dem System verbindet, das die Daten bereits vorhält.
- Ein Webportal deckt Einheiten mit geringem Volumen und Sonderfälle ab, wobei Docnova Global für länderübergreifende Operationen und Docnova France für die französische Reform zuständig ist.
Es kommt darauf an, dass alle drei dieselbe Formatbibliothek und dieselben Compliance-Updates nutzen. Andernfalls betreibt eine Gruppe am Ende drei separate Compliance-Stacks und zahlt für die Wartung jedes einzelnen.
Eine Checkliste zur Bewertung der Unterstützung von E-Rechnungsformaten
- Welche benannten Formate und Versionen werden heute unterstützt, von Land zu Land?
- Werden Hybridformate wie Factur-X und ZUGFeRD verarbeitet und wird das eingebettete XML validiert?
- Wird der Peppol-Zugang direkt bereitgestellt oder an einen Dritten untervergeben?
- Wer pflegt die Mappings und Schema-Updates, und ist das in der Lizenz enthalten?
- Können eingehende und ausgehende Dokumente auf einer Plattform verarbeitet werden?
- Was passiert, wenn ein Land, in dem Sie bereits tätig sind, ein neues Mandat ankündigt?
- Sind die Sicherheits- und Datenschutznachweise vorhanden, wie beispielsweise eine ISO 27001-Zertifizierung und die DSGVO-Konformität?
Fazit
Die Unterstützung von E-Invoicing-Formaten ist keine Funktionsliste, die man bei der Vertragsunterzeichnung einmalig abhakt. Sie ist eine Wartungsverpflichtung, die sich über das nächste Jahrzehnt europäischer Mandate erstreckt, und die Anbieter, die in die engere Wahl kommen sollten, sind diejenigen, die sie auch so behandeln. Melasoft deckt über 30 Märkte über die Docnova-Plattform ab, mit SAP-Add-On-, API-, Peppol- und EDI-Konnektivität sowie Eingangs- und Ausgangsströmen auf derselben Compliance-Engine.
Senden Sie uns die Länder, in die Sie fakturieren, und wir werden Ihre aktuellen Formate mit den Anforderungen der jeweiligen Märkte abgleichen. Buchen Sie ein kurzes technisches Gespräch unter docnova.ai und wir kümmern uns um den Rest.