ZUGFeRD PDF/A-3
Das strukturierte CII-XML wird in ein PDF/A-3 eingebettet und gemeinsam als hybrider Beleg ausgegeben.
Invoify erzeugt strukturierte E-Rechnungen aus dem fertig erfassten Beleg. Ein Gate prüft notwendige Empfänger-, Leistungs- und Steuerdaten, bevor XML beziehungsweise PDF/A-3 erzeugt und technisch validiert werden.
Das strukturierte CII-XML wird in ein PDF/A-3 eingebettet und gemeinsam als hybrider Beleg ausgegeben.
Für B2G-Empfänger kann ein eigenständiges strukturiertes XML erzeugt werden; erforderliche Käuferreferenzen werden vorab geprüft.
Die erzeugte Ausgabe wird gegen XSD, EN-16931-Schematron und beim ZUGFeRD-PDF zusätzlich gegen PDF/A-Anforderungen geprüft.
Sichtbare Rechnung und strukturierter Datensatz stammen aus demselben Belegmodell statt aus einer nachträglichen Texterkennung.
Das E-Rechnungs-Gate meldet fehlende Felder vor der Erzeugung und ordnet sie dem Empfänger- oder Rechnungsbereich zu.
Erzeugte XML- und PDF-Ausgaben bleiben zum festgeschriebenen Beleg abrufbar.
Eine E-Rechnungssoftware erzeugt strukturierte Rechnungsdaten in einem vereinbarten Format, prüft die dafür nötigen Felder und stellt Datei sowie Validierung für den vorgesehenen Übertragungsweg bereit. Eine normale PDF-Rechnung erfüllt diese Aufgabe nicht. Bei Invoify wird die Rechnung zuerst fachlich als normaler Ausgangsbeleg vorbereitet; anschließend kann sie für Deutschland als ZUGFeRD oder XRechnung erzeugt und technisch validiert werden.
Invoify ist dabei ein Werkzeug für Ausgangsrechnungen. Es besitzt aktuell keine vollständige Eingangsrechnungsplattform, keinen eigenen Peppol-Access-Point und keinen automatischen Versand an ein Behördenportal. Empfang, Freigabe eingehender Rechnungen und der konkrete Transportkanal müssen deshalb getrennt bewertet werden. Diese Grenze verhindert, dass Dateierzeugung mit einem belegten Ende-zu-Ende-Versand verwechselt wird.
Kurzform: ZUGFeRD verbindet ein sichtbares PDF/A-3 mit eingebetteten strukturierten Rechnungsdaten. XRechnung ist eine strukturierte XML-Rechnung. Invoify erzeugt und validiert beide Ausgaben; Empfängeranforderung und Übertragungsweg werden vor dem Versand separat geklärt.
ZUGFeRD eignet sich häufig für Geschäftsprozesse, in denen Menschen weiterhin eine lesbare PDF-Darstellung benötigen und Systeme zugleich strukturierte Daten verarbeiten sollen. Das eingebettete XML ist kein unverbindlicher Zusatz: Sichtbare Darstellung und strukturierte Werte müssen zusammenpassen. Der Empfänger muss das verwendete Profil annehmen können. Invoify verwendet für die deutsche ZUGFeRD-Ausgabe das EN-16931-Profil und bettet die validierten Daten in das Rechnungs-PDF ein.
XRechnung ist eine reine strukturierte XML-Ausgabe und besonders aus dem deutschen B2G-Umfeld bekannt. Öffentliche Auftraggeber können neben dem Profil zusätzliche Angaben wie Käuferreferenz beziehungsweise Leitweg-ID, Bestellreferenz oder einen konkreten Einbringungsweg verlangen. Die Tatsache, dass eine Datei technisch XRechnung ist, sagt noch nicht, ob sie im richtigen Portal, per E-Mail oder über ein Netzwerk angenommen wird.
Die Auswahl sollte deshalb nicht über einen pauschalen Schalter für alle Kunden erfolgen. Firmeneinstellung, Empfängerstamm und einzelner Auftrag werden gemeinsam geprüft. Ein Geschäftskunde kann ZUGFeRD akzeptieren, während eine Behörde XRechnung und einen bestimmten Kanal vorgibt. Ändert sich die Anforderung, kann eine vorhandene E-Rechnung in Invoify bewusst im anderen unterstützten Format neu erzeugt werden; der Vorgang bleibt an derselben festgeschriebenen Rechnung.
| Prüffrage | ZUGFeRD | XRechnung |
|---|---|---|
| Ausgabe | PDF/A-3 mit eingebetteten strukturierten Rechnungsdaten | strukturierte XML-Datei ohne notwendige visuelle PDF-Leitansicht |
| Typischer Bedarf | B2B-Prozess mit menschlich lesbarer Darstellung und maschinenlesbaren Daten | häufig B2G oder Empfänger mit ausdrücklich verlangtem XML-Profil |
| Empfängerangaben | vollständige Rechnungs- und Referenzdaten nach Profil und Geschäftsvorgang | zusätzlich häufig konkrete Käuferreferenz/Leitweg-ID und Auftraggebervorgaben |
| Transport | Datei kann zum Beispiel als E-Mail-Anhang übergeben werden, wenn der Empfänger das akzeptiert | Portal, E-Mail oder Netzwerk werden vom Empfänger festgelegt; die XML-Datei bestimmt den Kanal nicht |
| Invoify-Grenze | Erzeugung, Einbettung, Validierung und Download beziehungsweise E-Mail-Anhang | Erzeugung, Validierung und XML-Download; kein eigener Portal- oder Peppol-Versand |
Die strukturierte Ausgabe wird nicht aus einer leeren Dokumenthülle erzeugt. Grundlage ist eine fertig vorbereitete Rechnung mit eindeutiger Nummer, Empfänger-Snapshot, Rechnungs- und Leistungsdaten, Positionen, Mengen, Einheiten, Preisen, Steuerkategorien, Summen und Zahlungsinformationen. Invoify verwendet dieselben freigegebenen Belegdaten für sichtbare Rechnung und XML, damit keine zweite manuell gepflegte Wahrheit entsteht.
Für die deutsche Ausgabe prüft das Gate unter anderem, ob eine Käuferreferenz oder Leitweg-ID vorhanden ist, der Verkäufer über die erforderliche eindeutige Identifikation verfügt und ein Verkäuferkontakt mit Kontaktweg hinterlegt ist. Außerdem müssen Land, Anschriften, Steuereinstellungen und Zahlungskontext zum unterstützten Profil abbildbar sein. Nicht abbildbare Steuerfälle werden blockiert, statt mit einer scheinbar passenden Standardkategorie exportiert zu werden.
Vor der Speicherung gleicht Invoify zusätzlich Positionssumme, Rabatt und Belegnettosumme ab. Eine relevante Abweichung stoppt die Erzeugung. Das ist wichtig, weil ein optisch plausibles PDF und ein abweichender XML-Zahlbetrag zwei widersprüchliche Rechnungsstände erzeugen würden. Fehlermeldungen benennen den betroffenen Bereich, damit Stammdaten oder Rechnung gezielt korrigiert werden können.
Der praktische Ablauf beginnt nicht im XML-Editor. Zuerst werden Firma, Kontakt und E-Rechnungsangaben gepflegt. Danach entsteht die Rechnung aus einem Angebot, einer Shopbestellung oder als neuer Vorgang. Positionen und Steuerfall werden geprüft, bevor der Beleg fertiggestellt und versendet wird. Die Rechnungsnummer entsteht im regulären Belegprozess; eine E-Rechnung ohne eindeutigen Ausgangsbeleg wird nicht als unabhängige Datei daneben geführt.
Wenn E-Rechnung aktiviert ist, versucht Invoify beim Versand die konfigurierte ZUGFeRD-Ausgabe zu erzeugen. Fehlen Pflichtdaten oder ist der technische Validator vorübergehend nicht erreichbar, bleibt der versendete Beleg sichtbar und die E-Rechnung kann nach Korrektur nachgeholt werden. Der Fehler wird nicht als erfolgreiche E-Rechnung verborgen. In der E-Rechnungssektion stehen Format, Gültigkeitsstatus und konkrete Verstöße zur Verfügung.
Für ZUGFeRD wird das strukturierte XML in das eingefrorene Versand-PDF eingebettet. Für XRechnung entsteht die strukturierte XML-Ausgabe. Anschließend läuft die technische Validierung. Nur eine erfolgreiche Ausgabe wird als gültige E-Rechnung gespeichert; bei einem Fehler wird nichts als gültiges Artefakt eingefroren. XML, ZUGFeRD-PDF und Validierungsbericht können anschließend über die vorgesehenen Funktionen abgerufen werden.
Der letzte Schritt bleibt die Übergabe. Ein akzeptierter E-Mail-Anhang, ein Behördenportal und Peppol sind drei unterschiedliche Kanäle. Das Team dokumentiert, welche Datei wann über welchen Weg übertragen wurde und welche Rückmeldung der Empfänger geliefert hat. Invoify kann das ZUGFeRD-PDF an die Rechnungs-E-Mail anhängen, behauptet daraus aber keinen Portal-Upload oder Peppol-Transport.
| Schritt | Ergebnis | Stoppkriterium |
|---|---|---|
| 1. Stammdaten | Firma, Empfänger und E-Rechnungsreferenzen sind vollständig | unklare Identität, Adresse oder Käuferreferenz |
| 2. Fachlicher Beleg | Leistung, Positionen, Steuerfall und Summen sind freigegeben | ungeklärter Steuer- oder Leistungsfall |
| 3. Festschreibung | Rechnung besitzt eine eindeutige Nummer und einen stabilen Stand | Entwurf ohne endgültigen Belegstatus |
| 4. Erzeugung | ZUGFeRD-PDF oder XRechnung-XML wird aus denselben Daten gebaut | nicht unterstütztes Profil oder fehlende Pflichtdaten |
| 5. Validierung | technischer Bericht bestätigt die erzeugte Ausgabe | Schema-, Profil-, Summen- oder Konsistenzfehler |
| 6. Übergabe | Datei wird über den vereinbarten Kanal gesendet und nachverfolgt | Kanal oder Empfängeranforderung ist nicht belegt |
Ein kleiner Dienstleister erhält einen Auftrag von einer Behörde. In den Kontaktdaten werden die offizielle Rechnungsempfängeradresse und die vom Auftraggeber genannte Leitweg-ID gespeichert. Im Angebot und später in der Rechnung bleiben Bestellreferenz, Leistungsbeschreibung und Leistungszeitraum nachvollziehbar. Vor dem Fertigstellen kontrolliert eine zweite Person, ob die Käuferreferenz zum konkreten Auftrag gehört und ob der gewählte Steuerfall zur Leistung passt.
Nach dem Versand wird XRechnung ausgewählt. Das Gate erkennt beispielsweise eine fehlende Verkäufer-E-Mail oder eine unvollständige Adresse und blockiert die Erzeugung mit einem konkreten Hinweis. Nach der Korrektur wird die XML-Datei erneut gebaut und technisch validiert. Der Validierungsbericht belegt das Profil; er bestätigt aber nicht automatisch, dass die Behörde den Inhalt fachlich akzeptiert.
Die Behörde verlangt in diesem Beispiel ein bestimmtes Portal. Die validierte XML-Datei wird deshalb dort hochgeladen, nicht lediglich an eine beliebige E-Mail-Adresse geschickt. Upload- beziehungsweise Eingangsbestätigung wird zusammen mit der Rechnungsreferenz gespeichert. Würde der Auftraggeber stattdessen Peppol verlangen, wäre zusätzlich ein zertifizierter Access-Point-Dienst nötig, denn Invoify stellt aktuell keinen eigenen Peppol-Sende- oder Empfangskanal bereit.
Eine technische Validierung prüft Syntax, Profilregeln, Pflichtfelder, Codelisten und rechnerische Beziehungen der strukturierten Datei. Sie kann zeigen, dass ein Feld fehlt, eine Summe nicht aufgeht oder eine Regel des gewählten Profils verletzt ist. Damit ist sie ein wesentliches Ausgabegate. Sie kann jedoch nicht wissen, ob eine Leistung wirklich am angegebenen Tag erbracht wurde, ein Reverse-Charge-Fall tatsächlich vorliegt oder die verwendete Käuferreferenz zum Auftrag gehört.
Deshalb braucht der Prozess zwei Freigaben: eine fachliche Belegprüfung vor der Erzeugung und die technische Prüfung der resultierenden Datei. Warnungen werden nach einer dokumentierten Regel bewertet; Fehler werden nicht pauschal ignoriert. Nachträgliche Korrekturen erfolgen am nachvollziehbaren Belegprozess und nicht durch manuelles Bearbeiten der eingefrorenen XML-Datei.
Für die Toolauswahl sollte ein Betrieb mindestens einen Standardfall und drei Fehlerfälle testen: fehlende Käuferreferenz, widersprüchliche Summe und fachlich falscher Steuerfall. Gute Software zeigt nicht nur einen grünen Haken, sondern führt zum konkreten Ursprung des Problems. Ebenso wichtig sind unveränderte Downloads, ein abrufbarer Validierungsbericht und ein klarer Korrekturweg.
Invoify erzeugt deutsche Ausgangs-E-Rechnungen. Eine vollständige Eingangsrechnungsplattform mit Kanalüberwachung, Lieferantenzuordnung, fachlicher Rechnungsfreigabe, Buchung und Zahlungsworkflow gehört nicht zum beschriebenen Umfang. Auch eine Dateiablage oder OCR-Erkennung macht daraus keine vollständige Kreditorenbuchhaltung. Wer E-Rechnungen empfangen muss, benötigt einen vereinbarten Eingangskanal und einen gesonderten Prüf- und Archivprozess.
Ebenso wenig ersetzt die Ausgabe eine vollständige Finanzbuchhaltung oder Steuerberatung. Invoify erstellt keine EÜR oder Umsatzsteuervoranmeldung und entscheidet keinen rechtlichen Einzelfall. Für Aufbewahrung und Verfahrensdokumentation muss geklärt sein, wo Originaldatei, sichtbare Darstellung, Validierungsbericht, Versandnachweis und spätere Korrekturen dauerhaft zusammengehalten werden.
Der freigegebene Invoify-Umfang kostet während des Pre-Launch 0 €. Das ist keine Zusage für einen dauerhaft kostenlosen Volltarif. Eine Auswahl sollte deshalb neben dem aktuellen Preis auch Formatabdeckung, Empfängerkanäle, Support, Export, Archivanschluss und den späteren Tarifstand prüfen.
Die gesetzlichen Übergänge für 2025, 2027 und 2028 stehen ausschließlich auf der Seite zur E-Rechnung-Pflicht. Den direkten Formatentscheid erklärt ZUGFeRD oder XRechnung. Für die technische Prüfung folgt E-Rechnung validieren; Netzwerk und Access Points behandelt Peppol erklärt. Wer Produkte vergleichen möchte, wechselt zum neutralen E-Rechnungssoftware-Vergleich. Produkt- und Redaktionsstand: 31. Juli 2026.
Registriere dich ohne Kreditkarte und prüfe Firmendaten, Käuferreferenz, ZUGFeRD oder XRechnung und Validierungsfehler mit einem realistischen Vorgang. Der freigegebene Umfang kostet während des Pre-Launch 0 €; ein dauerhaft kostenloser Volltarif wird nicht zugesagt.
Kostenlos registrierenDirektantwort: E-Rechnungssoftware sollte strukturierte Rechnungsdaten aus einer kontrollierten Quelle erzeugen, das passende XRechnung- oder ZUGFeRD-Profil ausgeben, technische Fehler vor Versand anzeigen und die finale Datei am Beleg erhalten. Invoify deckt diesen Ausgangsprozess ab. Ein automatischer Lieferanteneingang, fachliche Buchung, Peppol-Netzwerkdienst und Behördenportal-Versand gehören nicht zum belegten Umfang.
Der kommerzielle Suchintent lautet nicht nur „kann XML“. Unternehmen brauchen einen reproduzierbaren Ablauf: Stammdaten, Leistung, Steuer, Referenzen, Festschreibung, Format, Validierung, Ausgabe und spätere Wiederauffindbarkeit müssen zusammenpassen. Ein eigenständiger Konverter kann für eine einzelne Datei ausreichen; bei wiederkehrenden Rechnungen ist entscheidend, ob die strukturierte Ausgabe aus demselben Belegmodell wie die sichtbare Rechnung stammt.
| Fähigkeit | Invoify-Stand | Vor Einsatz prüfen |
|---|---|---|
| Rechnungsdaten erfassen | Kontakte, Positionen, Leistung, Steuerfall, Zahlung und Empfängerreferenzen im Beleg | fachliche Richtigkeit und richtiger Rechtsträger |
| XRechnung erzeugen | strukturierte XML als eigenständige Ausgabe | Syntax, Buyer Reference, Version und Empfängerkanal |
| ZUGFeRD erzeugen | hybrides PDF/A-3 mit eingebetteter CII-XML | Profil, unterstützter Release-Stand und Gleichheit von Sicht/Struktur |
| Technisch validieren | Schema- und Regelprüfung der unterstützten Ausgabe | Validatorstand dokumentieren; fachliche Prüfung bleibt separat |
| Ausgeben | ZUGFeRD im dokumentierten E-Mail-Ablauf; XRechnung zusätzlich als XML-Download | konkrete Portal-, Netzwerk- oder Vertragsvorgabe des Empfängers |
| E-Rechnungen empfangen | kein überwachter Lieferanten-Eingang als Produktfunktion belegt | separates Postfach, Portal oder Eingangssystem organisieren |
| Peppol / Behördenportal | kein eigener Zustelldienst | Datei über den vom Empfänger verlangten Dienst übertragen |
| Buchhaltung | keine vollständige Finanzbuchhaltung, EÜR oder UStVA | Übergabe an Buchhaltung beziehungsweise Steuerkanzlei festlegen |
Die Informationsseite E-Rechnungsformate erklärt Standard, Syntax, Profil, Container und Transport. Diese Seite bleibt dagegen bei der Produktentscheidung für Invoify. Ein neutraler Kriterienvergleich mehrerer Produktkategorien liegt auf E-Rechnungssoftware im Vergleich.
Für ZUGFeRD ist am 5. August 2026 zusätzlich der Releaseübergang relevant: Version 2.5 ist nutzbar; das am 4. August veröffentlichte Korrigendum ZUGFeRD 2.5.2 gilt laut FeRD ab 1. September 2026. Ein Produktclaim zur neuen Version folgt erst nach Implementierungs- und Empfängertest. Für XRechnung führt KoSIT derzeit Version 3.0 mit Spezifikation und technischem Bundle 3.0.2.
Ein technischer Validator kann fehlende oder widersprüchliche strukturierte Felder erkennen. Er kann nicht entscheiden, ob die Leistung tatsächlich erbracht wurde, der ausgewählte Steuersatz zum Sachverhalt passt oder eine Leitweg-ID zum richtigen Auftrag gehört. Die Abnahme kombiniert deshalb technische Regeln mit Beleg- und Empfängerprüfung.
Produkt- und Quellencheck: 5. August 2026. Invoify wird hier anhand des belegten Ausgangsrechnungsprozesses beschrieben; nicht vorhandene Eingangs-, Netzwerk- und Buchhaltungsfunktionen werden nicht durch allgemeine Begriffe wie „komplette E-Rechnungslösung“ impliziert.