E-Rechnungssoftware für Europa: Was Sie vor der Auswahl prüfen sollten

E-Rechnungssoftware für ein europäisches Unternehmen muss sieben Dinge gut können: das richtige strukturierte Format für jedes Land erzeugen, es vor der Ausstellung der Rechnung validieren, es über den Kanal übermitteln, den das jeweilige Land verwendet, eingehende strukturierte Rechnungen lesen, das strukturierte Original für die Aufbewahrungsfrist aufbewahren, die umsatzsteuerliche Behandlung aus den Fakten des Geschäftsvorfalls ableiten und all das anderen Systemen über eine API zugänglich machen. Kein einzelnes Produkt beherrscht alle sieben in jedem Land ohne Einschränkungen; die nützliche Frage lautet, welche Einschränkungen es gibt und ob der Anbieter sie benennt.

Formaterzeugung: eine Rechnung, vier nationale Dialekte

Die Software muss genau das Format erzeugen, das die jeweilige Pflicht erwartet — XRechnung oder ZUGFeRD für Deutschland, Factur-X für Frankreich, Peppol BIS Billing 3.0 für Belgien, FA(3) für Polen — und zwar aus denselben Rechnungsdaten, ohne dass der Nutzer XML bearbeitet.

Drei der vier sind Profile der EN 16931, der europäischen semantischen Norm, deren Teile 1 und 2 die Kommission über die nationalen Normungsinstitute kostenlos zugänglich macht; das vierte, das polnische FA(3), ist ein eigenes nationales Schema. „Unterstützt EN 16931“ ist daher notwendig, aber nicht hinreichend. Fragen Sie konkret:

• Welche Syntaxen für Deutschland — XRechnung in UBL, in CII oder beides? ZUGFeRD in welchen Profilen (die BMF-FAQ schließen MINIMUM und BASIC-WL aus der Definition der E-Rechnung aus)?
• Bettet die französische Ausgabe das CII-XML in ein PDF/A-3 (Factur-X) ein, sodass dieselbe Datei Menschen und Maschinen dient?
• Ist die belgische Ausgabe das Peppol-BIS-Billing-3.0-UBL, das das Netzwerk validiert, oder ein generisches UBL, das ein empfangender Access Point ablehnen kann?
• Welche FA-Version für Polen — FA(3) ist das aktuelle Schema — und kann die Software auch die Visualisierung mit KSeF-Nummer und QR-Code erzeugen, die das Ministerium verlangt, wenn eine Rechnung außerhalb des Systems verwendet wird?
• Wird das Format automatisch aus dem Land des ausstellenden Unternehmens gewählt, oder muss der Nutzer es auswählen?

Der Formatleitfaden ordnet jedes Format seinem Land und seiner Pflicht zu.

Validierung vor der Ausstellung, nicht nach der Ablehnung

Eine strukturierte Rechnung, die die nationalen Geschäftsregeln verletzt, ist nach dieser Pflicht keine E-Rechnung; die Software sollte diese Regeln prüfen, bevor die Nummer vergeben wird, und nicht erst durch eine abgelehnte Übermittlung vom Fehler erfahren.

Validierung hat Ebenen: XML-Schema, Schematron-Regeln der EN 16931, nationale CIUS-Regeln (die der KoSIT für XRechnung, die Peppol-BIS-Regeln für Belgien, das FA(3)-Schema für Polen) und Querprüfungen wie die Arithmetik der Summen und der Umsatzsteueraufschlüsselung. Fragen Sie, welche Ebenen laufen, ob die Regelsätze in der aktuellen Version vorliegen (die Ausgabe 2026 der Norm löst eine Migration aus, und KoSIT und OpenPeppol veröffentlichen Releases nach eigenen Zeitplänen) und ob eine fehlgeschlagene Validierung die Ausstellung blockiert oder nur warnt. Ein kostenloser Online-Prüfer, der eine Datei gegen die Regeln eines Landes validiert, ist ein fairer Weg, die Behauptungen eines Anbieters zu testen — siehe den E-Rechnungs-Prüfer.

Übermittlung: der Teil, der sich je Land am stärksten unterscheidet

Deutschland schreibt keinen Kanal vor, Belgien schreibt Peppol vor, Frankreich schreibt registrierte Plattformen vor, Polen schreibt sein staatliches System vor; Software, die alle vier abdeckt, integriert entweder jeden Kanal oder benennt, welchen sie an einen Dienstleister übergibt.

Achten Sie auf die Wortwahl. „Peppol-ready“ kann einen akkreditierten Access Point, eine Anbindung über einen solchen oder lediglich die Fähigkeit bedeuten, eine BIS-Datei zu exportieren. „KSeF-ready“ kann produktiven Einsatz oder ein nur gegen die Sandbox getestetes Modul bedeuten. Der Anbieter sollte sagen, was zutrifft; der Netzwerkvergleich erklärt, warum der Unterschied zählt.

Empfang: eingehendes XML in Eingangsrechnungen verwandeln

Jede Pflicht beginnt mit dem Empfang, deshalb muss die Software XRechnung-, ZUGFeRD/Factur-X- und UBL-Dateien — aus E-Mail, Upload oder einem Netzwerk — ohne Abtippen in einen Einkaufsbeleg einlesen.

Fragen Sie, was mit einem hybriden PDF passiert: Wird das eingebettete XML extrahiert und verwendet, oder wird das PDF wie ein Bild behandelt? Fragen Sie, ob Lieferant, Beträge, Umsatzsteueraufschlüsselung, Fälligkeitsdatum und Zahlungsreferenz in die Eingangsrechnung übernommen werden und ob eine Datei, die die Validierung nicht besteht, abgewiesen oder markiert wird. Fragen Sie, wie eingehende Peppol-Dokumente den Posteingang erreichen, sobald die Kennung des Unternehmens registriert ist. Für Deutschland siehe E-Rechnungen empfangen.

Archivierung: die strukturierte Datei ist das Original

Wo die Rechnung eine strukturierte Datei ist, muss diese Datei — nicht eine PDF-Darstellung davon — für die nationale Aufbewahrungsfrist unverändert und abrufbar aufbewahrt werden.

Die belgische Behörde weist darauf hin, dass „die Regeln zur Archivierung unverändert bleiben“ durch die Pflicht, was überall gilt: Aufbewahrungsfristen und Integritätsanforderungen sind national und älter als die E-Rechnung. Was sich ändert, ist das Objekt. Fragen Sie, ob die Software das ausgestellte XML (und das empfangene XML) so speichert, wie es gesendet wurde, ob sie das Archiv gesammelt exportieren kann und ob eine Rechnung nach Ende eines Abonnements abrufbar bleibt. Aufbewahrungsfristen und etwaige nationale Anforderungen an Unveränderbarkeit oder Prüfpfade erfordern eine fachliche Bestätigung.

Steuerurteile: aus Fakten abgeleitet, nicht eingetippt

Die Umsatzsteuerzeile einer Rechnung folgt aus dem Land des Verkäufers, dem Land des Käufers, dem Status des Käufers als Unternehmer und der Art der Leistung; Software sollte sie aus diesen Fakten ableiten und sich weigern zu raten, wo die Fakten nicht ausreichen.

Das zählt in Europa mehr als anderswo, weil die strukturierten Formate die Umsatzsteuer-Kategoriecodes und Befreiungsgründe explizit tragen und Validatoren sie gegen die Beträge prüfen. Fragen Sie, ob die Software zwischen Regelbesteuerung, Nullsatz, Steuerbefreiung, Reverse Charge und nicht steuerbar unterscheidet, ob sie die USt-IdNr. des Käufers bei der Ausstellung gegen VIES prüft, ob sie die Entscheidung mit der Rechnung für spätere Prüfungen speichert und — wichtig — ob sie einen ehrlichen Zustand „Eingabe erforderlich“ statt eines Standardsatzes kennt. Siehe grenzüberschreitende E-Rechnung für die Regeln hinter den Urteilen und den kostenlosen USt-IdNr.-Prüfer.

API: die Rechnung entsteht meist anderswo

Für ein SaaS-, Marktplatz- oder ERP-getriebenes Unternehmen entsteht die Rechnung in einem anderen System; die E-Rechnungssoftware braucht eine dokumentierte API mit Authentifizierung, idempotenter Erstellung, Webhooks und einem Testmodus.

Fragen Sie, ob die API Entwürfe anlegt, die dann unter der Validierung des Produkts ausgestellt werden, oder ob sie rechtsgültige Rechnungen direkt ausstellt (was die obigen Prüfungen umgeht); ob Schlüssel auf ein einzelnes Unternehmen und auf Lesen oder Schreiben eingeschränkt werden können; ob POST-Anfragen einen Idempotenzschlüssel akzeptieren, sodass ein wiederholter Aufruf keine zwei Rechnungen erzeugen kann; welche Ereignisse per Webhook gesendet werden und wie sie signiert sind; und wie hoch das Rate-Limit ist. Entwickler werden die Referenz vor dem Kauf lesen wollen — siehe die E-Rechnungs-API und die API-Referenz.

Die Checkliste

Zwölf Fragen, die Abdeckung von Behauptungen trennen; ein Anbieter, der jede mit einem klaren Ja, Nein oder „über Dienstleister X“ beantwortet, sagt Ihnen, was Sie wissen müssen.

1. Welche nationalen Formate werden automatisch aus dem Land des Unternehmens erzeugt, und in welchen Syntaxen und Profilen?
2. Welche Validierungsregelsätze laufen vor der Ausstellung, und in welchen Versionen?
3. Blockiert eine fehlgeschlagene Validierung die Ausstellung?
4. Für Belgien: Welcher akkreditierte Access Point transportiert den Verkehr, und ist der Anbieter selbst einer?
5. Für Frankreich: Ist der Anbieter eine plateforme agréée, oder über welche PA übermittelt er, und ist das produktiv?
6. Für Polen: Wurde die KSeF-Integration produktiv eingesetzt?
7. Werden eingehende XRechnung-, ZUGFeRD/Factur-X- und UBL-Dateien mit dem eingebetteten XML in Eingangsrechnungen eingelesen?
8. Wird das strukturierte Original so gespeichert, wie es ausgestellt wurde, und ist es gesammelt exportierbar?
9. Wird die umsatzsteuerliche Behandlung aus den Fakten des Geschäftsvorfalls abgeleitet, mit VIES-Prüfung und gespeichertem Urteil?
10. Legt die API Entwürfe unter Validierung an, mit eingeschränkten Schlüsseln, Idempotenz und signierten Webhooks?
11. Gibt es einen Testmodus, der sich wie die Produktion verhält?
12. Welche der obigen Punkte beschreibt der Anbieter als Einschränkungen, und sind die Einschränkungen datiert?

So geht KRONENWERK damit um

KRONENWERK deckt Formate, Validierung, Empfang, Steuerurteile und die API vollständig ab; bei der Übermittlung liegen die Einschränkungen, und sie sind unten benannt.

KRONENWERK reicht keine Steuern ein und führt keine ab, bietet keine Steuer- oder Rechtsberatung und besitzt keine Sicherheitszertifizierung; es gibt keine Garantie für Compliance-Ergebnisse. Über die E-Rechnung hinaus ist es ein Buchhaltungsprodukt — doppelte Buchführung, Eingangsrechnungen und Ausgaben, Bankanbindungen über Enable Banking und Plaid, mehrere Unternehmen und Währungen, fünf Oberflächensprachen. Siehe E-Rechnung in KRONENWERK, Rechnungsstellung, Pläne und, für Entwickler, die Entwicklerübersicht. Zurück zum Europa-Hub.