Section navigation

Deutschland — E-INVOICE DE (Unified API)

In Deutschland unterstützt fiskaly das Senden und Empfangen von B2B-E-Rechnungen. Die E-Rechnung wird vom Bundesministerium der Finanzen (BMF) geregelt. Alle elektronischen Rechnungen müssen der EN 16931 entsprechen, die durch Formate wie XRechnung, ZUGFeRD oder Peppol BIS 3.0 Billing erfüllt wird, und müssen 8 Jahre lang in einem gesetzeskonformen elektronischen Format archiviert werden (§14b UStG).

fiskaly generiert EN 16931-konforme E-Rechnungen und stellt sie über einen von zwei Kanälen zu. Den Kanal legen Sie pro Rechnung beim Empfänger fest (recipients[].invoicing): per E-Mail — als ZUGFeRD oder XRechnung — oder über das PEPPOL-Netzwerk als XRechnung.

Die beiden Richtungen werden unterschiedlich konfiguriert:

📤

Senden — B2B

Zwei Zustellkanäle, pro Rechnung beim Empfänger wählbar: per E-Mail als ZUGFeRD oder XRechnung, oder über das PEPPOL-Netzwerk als XRechnung. Für E-Mail ist keine Registrierung im Netzwerk erforderlich.

📥

Empfangen — B2B

Nur über PEPPOL, daher sind die optionale PEPPOL-Registrierung und ein bestätigter Proof of Ownership erforderlich. Ein Taxpayer, der ausschließlich per E-Mail versendet, kann nicht empfangen. Eingehende XRechnungen werden derzeit nicht empfangen.

Diese Seite behandelt die Deutschland-spezifischen Anforderungen, die die Allgemeine Schritt-für-Schritt-Integration ergänzen. Stellen Sie sicher, dass Ihnen die folgenden Daten des Steuerpflichtigen vorliegen, bevor Sie fortfahren:

vat_id_number — Umsatzsteuer-Identifikationsnummer (Umsatzsteuer-ID)
credentials.tax_number — Steuernummer im ELSTER-Format (Steuernummer)
name — Eingetragener Firmenname und Handelsname des Unternehmens oder der natürlichen Person
address — Eingetragene Geschäftsadresse des Unternehmens oder der natürlichen Person

📘Die Umsatzsteuer-ID ist für die Inbetriebnahme erforderlich

Ein deutsches E_INVOICE_SERVICE System kann nicht in Betrieb genommen werden, solange beim Taxpayer keine gültige vat_id_number hinterlegt ist. Die Steuernummer in credentials.tax_number genügt dafür nicht — deutsche E-Rechnungen erfordern eine umsatzsteuerliche Identität, die beiden Felder sind hier also nicht austauschbar. Ohne sie schlägt die Inbetriebnahme mit 422 Unprocessable Content fehl.

E-Rechnungen versenden: Empfängeranforderungen

Um eine E-Rechnung zu versenden, geben Sie den Empfänger und den Zustellweg direkt im Record der Rechnung an. Wenn Sie die Rechnung (TRANSACTION::INVOICE) mit createRecord erstellen, fügen Sie den Empfänger dem recipients-Array hinzu.

Wie in der Allgemeinen Schritt-für-Schritt-Integration beschrieben, muss jeder Empfänger vom Typ BUSINESS sein und einen ausgefüllten invoicing-Block haben. Zusätzlich zu den Standardangaben jeder E-Rechnung (Name, Adresse, Steueridentifikation des Empfängers, Rechnungspositionen usw.) kommt in Deutschland der Zustellkanal beim Empfänger hinzu:

recipients[].type = BUSINESS
recipients[].identification.type = VAT — die deutsche E-Rechnung identifiziert den Käufer über die Umsatzsteuer-Identifikationsnummer
recipients[].invoicing.type = EMAIL oder PEPPOL — der Zustellkanal
recipients[].invoicing.email — (nur EMAIL) die E-Mail-Adresse des Empfängers
recipients[].invoicing.format — (nur EMAIL, optional) das Dokumentformat
recipients[].invoicing.identifier — (nur PEPPOL) der PEPPOL Network Identifier des Empfängers

`invoicing.type`	Zusätzlich erforderlich	Wie fiskaly zustellt
`EMAIL`	`invoicing.email`	Per E-Mail an diese Adresse, als ZUGFeRD oder XRechnung je nach `invoicing.format`.
`PEPPOL`	`invoicing.identifier`	An den PEPPOL-Endpunkt des Empfängers als XRechnung — siehe XRechnung-Einschränkung.

Sie wählen den Kanal pro Rechnung, nicht dauerhaft pro Empfänger — dasselbe Unternehmen kann eine Rechnung per E-Mail und die nächste über PEPPOL erhalten.

📘Wichtig

Ohne den invoicing-Block wird die E-Rechnung erstellt, aber nicht an den Empfänger zugestellt.

PEPPOL-Registrierung

In Deutschland ist die Registrierung im PEPPOL-Netzwerk optional — Sie entscheiden sich pro System dafür.

Hinterlegen Sie sie am E_INVOICE_SERVICE System mit createSystem:

{
  "content": {
    "type": "E_INVOICE_SERVICE",
    "location": { "id": "..." },
    "software": { "...": "..." },
    "registrations": [{ "type": "PEPPOL" }]
  }
}

Oder ergänzen Sie sie an einem bestehenden System mit updateSystem:

{
  "content": {
    "registrations": [{ "type": "PEPPOL" }]
  }
}

Was sich aus dieser Entscheidung ergibt:

registrations weggelassen — das System versendet ausschließlich per E-Mail. Ein Proof of Ownership ist nicht erforderlich, und das System geht bei der Inbetriebnahme direkt in den Modus OPERATIVE.
registrations enthält PEPPOL — ein Proof of Ownership ist erforderlich. Bei der Inbetriebnahme wird der state des Systems COMMISSIONED, sein mode jedoch DEGRADED, und das System erhält einen Log-Eintrag, der den fehlenden Proof of Ownership festhält.

Um das System in den Modus OPERATIVE zu bringen, laden Sie den Proof of Ownership wie in Schritt 11 der allgemeinen Integrationsanleitung beschrieben hoch. Die Prüfung dauert bis zu 72 Stunden; sobald sie abgeschlossen ist, wechselt das System automatisch und der Log-Eintrag wird entfernt. Was das Dokument enthalten muss, steht im Abschnitt Proof of Ownership.

📘PEPPOL später ergänzen

Sie können PEPPOL auch bei einem System ergänzen, das bereits in Betrieb genommen wurde. Dadurch wird die Prüfung des Proof of Ownership erneut ausgeführt, sodass ein System, das das Dokument noch nie eingereicht hat, wieder in den Modus DEGRADED zurückfällt.

Versand über PEPPOL

Setzen Sie beim Empfänger in Ihrem createRecord-Request:

recipients[].invoicing.type = PEPPOL
recipients[].invoicing.identifier — der PEPPOL Network Identifier des Empfängers

Dafür müssen zwei Voraussetzungen erfüllt sein: Ihr E_INVOICE_SERVICE System muss im PEPPOL-Netzwerk registriert sein (siehe PEPPOL-Registrierung), und der PEPPOL Network Identifier des Empfängers muss Ihnen vorliegen. Um das Identifier-Schema kümmert sich fiskaly.

Auf diesem Weg versandte Rechnungen werden als XRechnung erzeugt. recipients[].invoicing.format spielt hier keine Rolle — auf diesem Kanal ist das Format nicht wählbar.

⚠️Die meisten PEPPOL-Empfänger können keine XRechnung empfangen

PEPPOL registriert jeden Teilnehmer für die Dokumenttypen, die er empfangen kann, und die XRechnung ist im Netzwerk ein eigener Dokumenttyp. Der Versand an einen Empfänger, der nicht für XRechnung registriert ist, schlägt mit receiver does not support document type fehl.

Ausschlaggebend ist dabei nicht die Konformität: Die XRechnung folgt den Peppol BIS 3.0-Regeln, zustellbar wird sie dadurch aber nicht an einen Teilnehmer, der nur für Peppol BIS Billing 3.0 registriert ist. fiskaly erzeugt für Deutschland derzeit kein Peppol BIS Billing 3.0: recipients[].invoicing.format bietet ZUGFERD_V2 und XRECHNUNG_V3 und gilt ausschließlich für den E-Mail-Kanal.

Solange Sie nicht wissen, dass ein Empfänger für XRechnung registriert ist, senden Sie an diesen Empfänger per E-Mail.

📘B2G wird noch nicht unterstützt

Der Versand an deutsche öffentliche Auftraggeber (B2G) wird noch nicht unterstützt, daher ist die Adressierung über die Leitweg-ID nicht verfügbar.

Versand per E-Mail: Dokumentformat auswählen

Wenn der Kanal EMAIL ist, entscheiden Sie, welches Dokumentformat fiskaly erzeugt. Setzen Sie es beim selben Empfänger in Ihrem createRecord-Request über recipients[].invoicing.format:

Wert	Format
`ZUGFERD_V2` (Standard)	ZUGFeRD — ein hybrides Dokument: ein menschenlesbares PDF/A-3 mit eingebettetem strukturiertem XML.
`XRECHNUNG_V3`	XRechnung — eine reine strukturierte XML-Rechnung, ohne PDF-Ebene.

Das Feld ist optional: Wenn Sie es weglassen, erzeugt fiskaly ZUGFERD_V2. Beide Formate entsprechen der EN 16931.

Empfang von E-Rechnungen

Der Empfang eingehender E-Rechnungen läuft über PEPPOL und setzt daher dieselbe PEPPOL-Registrierung voraus wie der Versand über PEPPOL — einschließlich eines bestätigten Proof of Ownership. Ein Taxpayer, der ausschließlich per E-Mail versendet, kann nicht empfangen.

Wenn Sie einen deutschen Taxpayer im PEPPOL-Netzwerk registrieren, registriert fiskaly ihn standardmäßig für Versand und Empfang. Eingehende Rechnungen, die an den PEPPOL Identifier des Systems adressiert sind, werden diesem System zugeordnet, und fiskaly erstellt für jede einen Record vom Typ E_INVOICE::RECEPTION.

⚠️Eingehende XRechnungen erreichen Ihren Taxpayer nicht

Die Registrierung für den Empfang umfasst Peppol BIS Billing 3.0, nicht die XRechnung. Eine Rechnung, die als XRechnung an Ihren Taxpayer adressiert ist, weist das Netzwerk ab, bevor sie fiskaly erreicht; es wird dafür also kein Record vom Typ E_INVOICE::RECEPTION erstellt. Es ist dieselbe Beschränkung auf registrierte Dokumenttypen, die unter Versand über PEPPOL beschrieben ist.

Rufen Sie retrieveSystem auf, um compliance.state zu lesen:

TRANSMISSION_RECEPTION — das System kann senden und empfangen.
TRANSMISSION_ONLY — das System kann nur senden.

⚠️Wenn compliance.state auf TRANSMISSION_ONLY bleibt

Versand und Empfang ist der Standard, fiskaly fällt jedoch auf eine reine Versandregistrierung zurück, wenn die PEPPOL-Registrierung einen Konflikt meldet — typischerweise, weil der PEPPOL Participant Identifier Ihres Taxpayers bereits über einen anderen Anbieter registriert ist. Das System bleibt für den Versand nutzbar. Wenn Sie mit dem Empfang gerechnet haben, wenden Sie sich mit der Umsatzsteuer-ID des Taxpayers an das fiskaly Support-Team unter dev-support@fiskaly.com.

Abrufen empfangener Rechnungen

Jede an Ihren Taxpayer adressierte Rechnung wird automatisch empfangen und als Record gespeichert — es gibt keinen Webhook, Sie fragen neue Rechnungen also selbst ab:

Rufen Sie listRecords auf und filtern Sie nach E_INVOICE::RECEPTION.
Rufen Sie für jeden neuen Record retrieveRecord mit compliance-artifact auf, um das signierte XML zu erhalten.

listRecords gibt die neuesten Records zurück (limit ist standardmäßig 10, neueste zuerst) — verfolgen Sie daher, welche Sie bereits verarbeitet haben.