Germany — E-INVOICE DE (Unified API)

In Germany, fiskaly supports sending and receiving B2B e-invoices. E-invoicing is regulated by the Federal Ministry of Finance (BMF — Bundesministerium der Finanzen). All e-invoices are required to comply with EN 16931, which is satisfied by formats such as XRechnung, ZUGFeRD, or Peppol BIS 3.0 Billing, and are to be archived for 8 years in the electronically compliant format (§14b UStG).

fiskaly generates EN 16931-compliant e-invoices and delivers them over one of two channels, chosen per invoice on the recipient (recipients[].invoicing): by email — as ZUGFeRD or XRechnung — or over the PEPPOL network, as XRechnung.

The two directions are configured differently:

📤

Sending — B2B

Two delivery channels, chosen per invoice on the recipient: by email as ZUGFeRD or XRechnung, or over the PEPPOL network as XRechnung. Email needs no network registration.

📥

Receiving — B2B

Over PEPPOL only, so it requires the optional PEPPOL registration and a verified Proof of Ownership. A Taxpayer that sends by email only cannot receive. Inbound XRechnung is not currently received.

This page covers the Germany-specific requirements that complement the General Step-by-step Integration. Make sure you have the following taxpayer information ready before proceeding:

• vat_id_number — VAT identification number (Umsatzsteuer-ID)
• credentials.tax_number — tax number in ELSTER format (Steuernummer)
• name — registered legal name and trade name of the company or individual
• address — registered legal address of the company or individual

📘The VAT ID number is required to commission

A German E_INVOICE_SERVICE System cannot be commissioned unless the Taxpayer’s fiscalization carries a valid vat_id_number. The Steuernummer in credentials.tax_number does not satisfy this — German e-invoices require a VAT-shaped tax identity, so the two fields are not interchangeable here. Commissioning without it fails with 422 Unprocessable Content.

Sending e-invoices: recipient requirements

To send an e-invoice, you specify its recipient and how the invoice should reach them — right on the invoice record. When you create the invoice (TRANSACTION::INVOICE) with createRecord, add the recipient to its recipients array.

As the General Step-by-step Integration explains, each recipient must be a BUSINESS with a populated invoicing block. Beyond the standard details every e-invoice requires (recipient name, address, tax identification, invoice lines, and so on), Germany adds the delivery channel on the recipient:

• recipients[].type = BUSINESS
• recipients[].identification.type = VAT — German e-invoicing identifies the buyer by VAT identification number
• recipients[].invoicing.type = EMAIL or PEPPOL — the delivery channel
• recipients[].invoicing.email — (EMAIL only) the recipient’s email address
• recipients[].invoicing.format — (EMAIL only, optional) the document format
• recipients[].invoicing.identifier — (PEPPOL only) the recipient’s PEPPOL Network Identifier

invoicing.type	Also required	How fiskaly delivers it
EMAIL	invoicing.email	Emailed to that address, as ZUGFeRD or XRechnung depending on invoicing.format.
PEPPOL	invoicing.identifier	Sent to the recipient’s PEPPOL endpoint as XRechnung — see the XRechnung limitation.

You choose the channel per invoice, not once per recipient — the same business can receive one invoice by email and the next over PEPPOL.

📘Important

Without the invoicing block, the e-invoice is created but not delivered to the recipient.

Registering for PEPPOL

In Germany, registering on the PEPPOL network is optional — you opt in per System.

Declare it on the E_INVOICE_SERVICE System with createSystem:

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

Or add it to an existing System with updateSystem:

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

What follows from that choice:

• registrations omitted — the System sends by email only. No Proof of Ownership is involved and the System commissions straight to mode OPERATIVE.
• registrations includes PEPPOL — a Proof of Ownership document is required. On commissioning, the System’s state becomes COMMISSIONED but its mode becomes DEGRADED, and the System carries a log entry recording that the Proof of Ownership is missing.

To move the System into OPERATIVE mode, upload the Proof of Ownership as described in Step 11 of the general integration guide. Verification takes up to 72 hours; once it completes, the System transitions automatically and the log entry is removed. See the Proof of Ownership section for what the document must show.

📘Adding PEPPOL later

You can add PEPPOL to a System that is already commissioned. Doing so re-runs the Proof of Ownership check, so a System that has never supplied the document returns to mode DEGRADED until it does.

Sending via PEPPOL

On the recipient in your createRecord request, set:

• recipients[].invoicing.type = PEPPOL
• recipients[].invoicing.identifier — the recipient’s PEPPOL Network Identifier

Two things are required before this works: your E_INVOICE_SERVICE System must be registered on the PEPPOL network (see Registering for PEPPOL), and you need the recipient’s PEPPOL Network Identifier. fiskaly takes care of the identifier scheme.

Invoices sent this way are generated as XRechnung. recipients[].invoicing.format plays no part here — the format is not selectable on this channel.

⚠️Most PEPPOL recipients cannot receive XRechnung

PEPPOL registers each participant for the specific document types it is able to receive, and XRechnung is its own document type on the network. Sending to a recipient that is not registered for XRechnung fails with receiver does not support document type.

Conformance is not what decides this — XRechnung follows the Peppol BIS 3.0 rules, but that does not make it deliverable to a participant registered only for Peppol BIS Billing 3.0. fiskaly does not currently generate Peppol BIS Billing 3.0 for Germany: recipients[].invoicing.format offers ZUGFERD_V2 and XRECHNUNG_V3, and applies to the email channel only.

Until you know a recipient is registered for XRechnung, send to that recipient by email.

📘B2G is not yet supported

Sending to German public-sector buyers (B2G) is not supported yet, so Leitweg-ID addressing is not available.

Sending by email: choosing the document format

When the channel is EMAIL, you decide which document format fiskaly generates. Set it on the same recipient in your createRecord request, via recipients[].invoicing.format:

Value	Format
ZUGFERD_V2 (default)	ZUGFeRD — a hybrid document: a human-readable PDF/A-3 with the structured XML embedded inside it.
XRECHNUNG_V3	XRechnung — a pure structured XML invoice, with no PDF layer.

The field is optional: omit it and fiskaly generates ZUGFERD_V2. Both formats comply with EN 16931.

Receiving e-invoices

Receiving inbound e-invoices happens over PEPPOL, so it depends on the same PEPPOL registration that sending over PEPPOL does — including a verified Proof of Ownership. A Taxpayer that sends by email only cannot receive.

When you register a German Taxpayer on PEPPOL, fiskaly registers it for both sending and receiving by default. Inbound invoices addressed to the System’s PEPPOL identifier are matched to that System, and fiskaly creates a record of type E_INVOICE::RECEPTION for each one.

⚠️Inbound XRechnung does not reach your Taxpayer

The receiving registration covers Peppol BIS Billing 3.0, not XRechnung. An invoice addressed to your Taxpayer as XRechnung is rejected by the network before it reaches fiskaly, so no E_INVOICE::RECEPTION Record is created for it. This is the same document-type registration limit described under Sending via PEPPOL.

Call retrieveSystem to read compliance.state:

• TRANSMISSION_RECEPTION — the System can send and receive.
• TRANSMISSION_ONLY — the System can send only.

⚠️If compliance.state stays on TRANSMISSION_ONLY

Send-and-receive is the default, but fiskaly falls back to a send-only registration if the PEPPOL registration reports a conflict — typically because the Taxpayer’s PEPPOL participant identifier is already registered through another provider. The System stays usable for sending. If you expected to receive, contact the fiskaly support team at dev-support@fiskaly.com with the Taxpayer’s VAT ID.

Retrieving received invoices

Every invoice addressed to your Taxpayer is received and stored automatically as a Record — there is no webhook, so you poll for new ones:

1. Call listRecords and filter for E_INVOICE::RECEPTION.
2. For each new Record, call retrieveRecord with compliance-artifact to get the signed XML.

listRecords returns the most recent Records (limit defaults to 10, newest first), so track what you have already processed.