Rechnungsformate und Konvertierung: Formate, Profile und Umwandlung

Übersicht der unterstützten Formate

Faktoora unterstützt eine breite Palette an elektronischen Rechnungsformaten. Die Wahl des richtigen Formats ist abhängig von der Art des Rechnungsempfängers und den gesetzlichen oder vertraglichen Anforderungen.

ZUGFeRD: Profile und Versionen

Faktoora erstellt ZUGFeRD-Rechnungen mit dem Extended-Profil, das die höchste Funktionalität bietet. Es gibt zwei Versionen:

• ZUGFeRD 1.0 (zf:1:extended): Die ursprüngliche Version auf Basis des CII-Standards. Sie wird weiterhin unterstützt.
• ZUGFeRD 2.1 (zf:2:extended): Die aktuelle Version nach EN 16931 und die Empfehlung für neue Rechnungen.

Das Extended-Profil ist das vollständigste Profil und erfüllt die Norm EN 16931. Die Nachricht „Sie können nur als PDF und als XRechnung herunterladen" bedeutet, dass der zugewählte Profile nur diese beiden Formate als Download anbietet – das ist bei bestimmten Konfigurationen und Rechnungstypen vorgesehen.

XRechnung und CII/UBL

Die XRechnung ist die deutsche Standard-E-Rechnung für öffentliche Auftraggeber. faktoora erzeugt sie automatisch in der jeweils gültigen Version. Welche Version aktuell verpflichtend ist, legt die Koordinierungsstelle für IT-Standards (KoSIT) fest — die verbindliche Übersicht führt xeinkauf.de.

XRechnung basiert technisch auf CII (Cross Industry Invoice), nicht auf UBL (Universal Business Language). CII ist das von Deutschland und Österreich bevorzugte XML-Format, während UBL vor allem im Peppol-Netzwerk (Nordeuropa, Niederlande) dominiert.

Die beiden Schemas unterscheiden sich in ihrer Struktur:

• CII: Strikte, hierarchische Struktur; wird von Deutschland, Österreich und der EN 16931-Spezifikation für XRechnung verwendet.
• UBL: Modularer aufgebaut, offener; Standard im Peppol-Netzwerk.

ZUGFeRD nutzt immer CII, deshalb wird bei der Erstellung einer ZUGFeRD-Rechnung die Schema-Option auf CII gesetzt (dies ist nicht wählbar).

Peppol (UBL) für internationale B2B-Rechnungen

Peppol (Pan-European Public Procurement Online) ist ein europaweites Netzwerk für strukturierte Rechnungen. Faktoora erstellt Peppol-Rechnungen als UBL-basierte EN 16931-Rechnungen und kann sie – mit aktivierter Peppol-Delivery – automatisch über das Peppol-Netzwerk versenden. Dies ist ideal für B2B-Rechnungen an europäische Unternehmen, die einen Peppol-Zugangspoint haben.

PDF und die Konvertierung von Formaten

PDF zu elektronischem Format: Was ist möglich, was nicht

PDF-Rechnungen können nicht automatisch in ein elektronisches Format (XRechnung, ZUGFeRD, etc.) umgewandelt werden. Dies liegt daran, dass:

1. Strukturelle Information fehlt: Ein PDF enthält nur visuelle Darstellung, keine strukturierten Daten.
2. OCR ist nicht zuverlässig: Faktoora nutzt OCR für die Extraktion von Texten aus eingescannten Rechnungen (eingehende Rechnungen), aber OCR kann keine 100% zuverlässige Feldverfolgung garantieren. Deshalb erfolgt die Erkennung als Hilfsmittel, nicht als vollständige Automatisierung.
3. Datenverlust: Komplexe Informationen wie Steuerkategorien, Rabatte auf Positionsebene oder Zahlungsbedingungen lassen sich aus einem PDF nicht automatisch rekonstruieren.

Ausnahme: Wenn die PDF ein XRechnung- oder ZUGFeRD-Format ist (also ein PDF/A-3 mit eingebettetem XML), kann faktoora das XML extrahieren und in andere Formate konvertieren.

Excel/CSV zu elektronischem Format

Faktoora bietet keinen direkten automatisierten Import von Excel oder CSV für die Erstellung von E-Rechnungen über die Web-UI. Für die API gibt es Möglichkeiten, strukturierte Daten zu übergeben, aber es ist notwendig, die Daten manuell zu strukturieren oder ein Integrations-Skript zu schreiben.

Workaround: Sie können Kundendaten und Produkte über CSV importieren (siehe Kontakte importieren, Produkte importieren) und dann Rechnungen manuell oder über die API erstellen.

Word zu elektronischem Format

Eine Word-Datei (DOCX) kann nicht automatisch in XRechnung oder ein anderes E-Rechnungsformat konvertiert werden. Dies unterliegt denselben Einschränkungen wie PDF: Das Format enthält nur visuelle und formale Informationen, nicht die strukturierten Daten, die ein E-Rechnungsformat benötigt.

Vorgehen: Erstellen Sie die Rechnung direkt in faktoora oder importieren Sie die relevanten Daten (Kunde, Positionen, Steuern) manuell.

Auslandische Rechnungen und Steuernummern

Ausländische Steuernummern und IBAN

Faktoora unterstützt Rechnungen, die nicht von einem deutschen Unternehmen ausgehen. Sie können in Ihren Profil-Einstellungen eine ausländische Steuernummer (z. B. österreichische UID, spanische NIF) und eine ausländische IBAN eintragen — aber dies muss über eine Kontaktanfrage oder einen Administrator-Zugriff konfiguriert werden, da die Web-UI auf deutsche Eingaben vorkonfiguriert ist.

Formate für Ausland

• International: Peppol (UBL) ist der Standard für europaweite B2B-E-Rechnungen.
• Spanien: Verifactu-Format für Behörden und B2B.
• Frankreich: Factur-X für Unternehmen; France-PA für öffentliche Auftraggeber (über eine Plateforme Agréée).
• Italien: FatturaPA für Behörden und B2B-Versand über das SdI-Netzwerk.
• Polen: KSeF (FA(3)) für Behörden und B2B.

Limitierungen bei elektronischen Rechnungen

Negative Beträge auf Positionsebene

Bei elektronischen Rechnungsformaten (XRechnung, ZUGFeRD, Peppol) können keine negativen Beträge auf Positionsebene eingetragen werden. Dies ist eine Anforderung der EN 16931-Norm.

Grund: EN 16931 sieht vor, dass Korrektionen über separate Gutschriftsanzeigen (Invoicetype-Code 381) oder Rechnungskorrektionen (Code 384) erfolgen, nicht durch negative Positionen in einer normalen Rechnung.

Lösung: Erstellen Sie stattdessen eine Gutschrift (Invoicetype 381) oder eine Rechnungskorrektur (384) als separate Rechnung.

Lieferdatum bei ZUGFeRD 2.x

Das Lieferdatum (BT-72 in EN 16931) wird bei ZUGFeRD 2.x in den XML-Daten erfasst, ist aber auf der PDF-Darstellung standardmäßig nicht sichtbar. Sie können es in der Rechnungs-UI aktivieren, damit es im PDF-Layout angezeigt wird.

Leistungsdatum ohne eigenes Datum je Position

Für einzelne Rechnungspositionen (z. B. Dienstleistungen ohne separates Lieferdatum) lässt sich zusätzlich ein Lieferdatum auf Produktebene setzen — das ist optional. Legen Sie kein eigenes Leistungsdatum oder keinen Leistungszeitraum für die Rechnung fest, gilt automatisch: Das Leistungsdatum entspricht dem Rechnungsdatum. Diese Vorbelegung wird auch so auf der Rechnung ausgewiesen und benötigt keine zusätzliche Eingabe.

Validierung und Fehlerbehandlung

Validierungsfehler bei Export/Download

Wenn der Export einer Rechnung als PDF oder CSV mit einem Validierungsfehler fehlschlägt, sind häufige Ursachen:

• BT-Feldverletzung: Ein erforderliches Feld nach EN 16931 ist nicht gesetzt oder hat ein ungültiges Format.
• Steuerinconsistenz: Negative Steuersätze, nicht-unterstützte Steuerkategorien oder ungültige Kategoriekombinationen.
• Feldformat: Ein Datum ist nicht im erwarteten Format, eine Telefonnummer hat ungültige Zeichen, etc.

Vorgehen: Überprüfen Sie die Fehlermeldung genau — sie nennt typischerweise das betroffene BT-Feld oder die Validierungsregel. Passen Sie die Daten an und versuchen Sie es erneut.

PDF-Generierungsfehler bei ZUGFeRD

Wenn eine als PDF heruntergeladene ZUGFeRD-Rechnung fehlschlägt oder beim Öffnen nicht angezeigt wird, können Ursachen sein:

• PDF/A-3-Konformität: Das PDF ist nicht PDF/A-3-konform, was in einigen Leseprogrammen zu Problemen führt. Versuchen Sie, es mit Acrobat Reader oder einem anderen PDF-Reader zu öffnen.
• Embeddings-Problem: Das eingebettete XML ist beschädigt. Dies ist selten und wird von der Validation erkannt.

Lösung: Nutzen Sie die Validierungsfunktion (validate: true bei der API-Erstellung), um Fehler vor dem Download zu erkennen.

Ansprechpartner in ZUGFeRD-Rechnungen

Wenn Sie einen Ansprechpartner im XML definieren (z. B. über die API), wird dieser nicht automatisch im PDF-Layout angezeigt. Das PDF zeigt typischerweise einen Standard-Kontakt oder das Unternehmen selbst an. Der Ansprechpartner ist dennoch in den strukturierten Daten (XML) vorhanden und wird von Systemen, die die XML auslesen, berücksichtigt.

Automatische PDF-Generierung bei API-Integrationen

Wenn eine Rechnung über eine externe API-Integration (z. B. durch einen Worker oder einen Batch-Prozess) erstellt wird, wird die PDF-Darstellung möglicherweise mit einem Standard-Layout generiert statt mit Ihrem individuellen Rechnungs-Template. Dies ist dann der Fall, wenn:

• Der API-Call keine Template-ID übergibt.
• Das System auf einen Fallback-Template zugreift (z. B. bei System-generierten Rechnungen).

Lösung: Stellen Sie sicher, dass Ihr API-Payload die richtige Template-ID oder Konfigurations-Referenzen enthält.

Feld BT-18: Dokumentreferenz

Das BT-18-Feld (Verweis auf Geschäftsdokument) wird in faktoora über das Feld buyerReference oder ähnliche Kontexte gepflegt. In der API können Sie invoiceReferencedDocument.IssuerAssignedID nutzen, um eine Referenz zu einer anderen Rechnung zu setzen (z. B. bei Korrektionen). Präzise BT-18-Feldmapping ist abhängig vom Rechnungstyp und dem Kontext.

Testfunktionalität

Zum Testen von ZUGFeRD-Rechnungen können Sie:

1. Eine Rechnung im Web-UI erstellen, sie als Draft speichern, und diese dann einem Kunden zeigen.
2. Die Rechnung mit den Daten des Kunden im Test-Konto des Kunden erstellen (mit dessen API-Key).
3. Eine Testrechnung über die API mit draftOnly: true erstellen.

Alle Optionen ermöglichen es, ein funktionierendes Beispiel zu zeigen, ohne sie produktiv zu versenden.

ZUGFeRD und XRechnung kombinieren

Eine Rechnung, die als ZUGFeRD 2.1 (Extended) erstellt wird, kann nicht automatisch als XRechnung heruntergeladen werden. Das liegt daran, dass ZUGFeRD 2.1 mit dem CII-Schema gebaut wird (PDF + CII-XML), während die XRechnung zwar ebenfalls CII nutzt, aber eigene Validierungsregeln und ein anderes Ausgabeformat hat.

Richtige Vorgehen:

• Für private Auftraggeber: ZUGFeRD 2.1 (Extended) erstellen.
• Für öffentliche Auftraggeber: XRechnung explizit auswählen.
• ZUGFeRD im Profil zf:2:xrechnung bietet ein Hybrid-Profil zwischen ZUGFeRD und XRechnung, ermöglicht aber keine freie Wahl nachträglich.

Wollen Sie eine echte XRechnung erstellen, wählen Sie Format: xrechnung bei der Erstellung. Wollen Sie ein ZUGFeRD-Hybrid mit XRechnung-Kompatibilität, nutzen Sie zf:2:xrechnung. Konvertierung zwischen ihnen ist nachträglich nicht möglich — das Format wird bei der Erstellung festgelegt.