> ## Documentation Index
> Fetch the complete documentation index at: https://docs.invopop.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Germany FAQ

> Frequently asked questions about invoicing compliance in Germany

### Compliance questions

**Germany**

<AccordionGroup>
  <Accordion title="When does mandatory B2B e-invoicing start in Germany?">
    Receiving capability has been mandatory since 1 January 2025. Issuing becomes mandatory on 1 January 2027 for companies with turnover above €800k, and 1 January 2028 for everyone else. B2G has been mandatory since 2020.
  </Accordion>

  <Accordion title="Is there a legal mandate to use Peppol?">
    There is no legal mandate to use Peppol in Germany. The requirement is to issue and receive invoices in a structured, EN 16931-compliant format (like XRechnung or ZUGFeRD).

    In practice, Peppol is by far the most widely used network, because it is the standardized, government‑endorsed way to exchange XRechnung invoices electronically with German public authorities and, increasingly, with large businesses. Using Peppol ensures:

    * Interoperability with virtually all public sector recipients.
    * Compliance with format and technical rules without having to negotiate separate connections or portals.
    * Access via certified Peppol Access Points, which handle validation and delivery.
    * Other delivery channels exist (email, portal upload), but they are often less convenient, less standardized, and may not scale for high-volume or cross-border invoicing. So, while Peppol isn't legally required, almost everyone uses it in practice for compliance and efficiency.
  </Accordion>

  <Accordion title="Are there any issuing timing requirements in Germany?">
    Timing is linked to contractual and procedural deadlines, not a specific law that defines a universal submission window. However, in the context of B2G many authorities specify invoice submission within 10 days of service completion in their contracts or portals, so it's best to issue the invoice as early as possible.

    In the case of B2B the general VAT rule states that the invoice must be issued within 15 days after the end of the month in which the supply was made, if the transaction is subject to VAT and involves another taxable business. This 15-day window is critical because late issuance can make VAT reporting inconsistent between supplier and customer and it may also affect the buyer's right to input VAT deduction.
  </Accordion>

  <Accordion title="Who can act as a supplier in Germany?">
    Any entity with a Steuernummer (tax number) or USt-IdNr (VAT ID). Foreign suppliers selling into German B2G need a valid VAT ID and a Leitweg-ID provided by the recipient.
  </Accordion>

  <Accordion title="Are there special supplier obligations under Peppol in Germany?">
    For B2G, the supplier must include the recipient's Leitweg-ID (the German B2G routing identifier) in the BuyerReference field. For B2B, no extra obligations beyond the standard Peppol participant registration.
  </Accordion>

  <Accordion title="What are the legal obligations for receiving invoices in Germany?">
    Since 1 January 2025, every German VAT-registered business must accept structured e-invoices (XRechnung, ZUGFeRD ≥ EN 16931). Archival in original format for 8 years (§ 14b UStG) — the structured XML is the legal record, the PDF is supplementary.
  </Accordion>

  <Accordion title="What periodic reporting obligations exist in Germany?">
    Monthly or quarterly Umsatzsteuer-Voranmeldung (USt-VA) and the annual Umsatzsteuerjahreserklärung. Cross-border B2B sales also require Zusammenfassende Meldung (EC sales list). E-reporting tied to e-invoicing is expected from 2028 but not yet legislated.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="Is sending invoices via Peppol mandatory?">
    Mandatory dates vary by country. Belgium requires structured B2B e-invoicing — Peppol BIS by default — from January 2026. Germany phases B2B e-invoicing in between 2025–2028. France's Factur-X via Peppol applies once the PA reform takes effect. Outside mandates, Peppol delivery is voluntary but increasingly expected for B2G and cross-border trade.
  </Accordion>

  <Accordion title="Does a Peppol invoice need to be EN16931 compliant?">
    Yes. Every document exchanged on Peppol BIS uses a UBL or CII syntax that conforms to the EN16931 European e-invoicing standard, plus the relevant Peppol BIS specification. Invopop generates compliant XML automatically when you use the Peppol app.
  </Accordion>

  <Accordion title="Why does Peppol require proof of ownership?">
    Peppol is a federated network — anyone could otherwise register a Participant ID for a company they don't represent. Proof of ownership ties the Participant ID to a verifiable contact at the company, which is what allows the registration to be published on the SML.
  </Accordion>

  <Accordion title="What documents count as proof of ownership?">
    Requirements vary by Authority. In Belgium, for example, the supplier must provide a recent extract from the Banque-Carrefour des Entreprises (KBO/BCE) plus a signed mandate. Invopop walks the registering party through the local requirements during the registration wizard.
  </Accordion>

  <Accordion title="Are received Peppol invoices considered legally valid?">
    Yes — a Peppol BIS document delivered through a certified Access Point is treated as the legal e-invoice in any country that recognises Peppol. The signed UBL or CII XML is the authoritative record; archive it alongside any human-readable rendering you generate.
  </Accordion>

  <Accordion title="How long must I retain received Peppol invoices?">
    Retention is set by each country's tax authority — typically 7 to 10 years in the EU. Invopop preserves the original XML and any generated PDF in the silo entry so you can satisfy local archival requirements wherever you operate.
  </Accordion>
</AccordionGroup>

### Invoicing questions

**Germany**

<AccordionGroup>
  <Accordion title="How do I configure my workspace for German invoicing?">
    Pick a format based on the recipient: XRechnung (UBL or CII) for B2G via Peppol, ZUGFeRD/Factur-X for B2B where a human-readable PDF is also wanted. Both are EN 16931-compliant — Invopop generates either from the same GOBL invoice.
  </Accordion>

  <Accordion title="What's the workflow for issuing Peppol invoices in Germany?">
    Generate a GOBL invoice with the `de-xrechnung-v3` addon, then run the Peppol Send workflow. Invopop emits XRechnung (UBL or CII per recipient preference), looks up the recipient's Access Point, and delivers via Peppol.
  </Accordion>

  <Accordion title="Which XRechnung syntax should I choose, UBL or CII?">
    Both syntaxes are equally valid and contain the same information, so in the majority of cases the choice has no consequences.

    If you plan on sending invoices through the PEPPOL network, we recommend using UBL as it is the supported format. If you plan on also issuing invoices in ZUGFeRD or Factur-X, it might be more convenient to use CII, as it is the syntax also supported by ZUGFeRD and Factur-X.
  </Accordion>

  <Accordion title="How can I view an XML attached to a PDF?">
    For ZUGFeRD PDFs, the XML file is embedded within the PDF itself. To extract and view it, you can use the `Attachments` section in Adobe Acrobat Reader.

    Alternatively, you can use specialized tools like the [SysTools PDF Extractor](https://www.systoolsgroup.com/pdf/extractor/) to extract the XML file.
  </Accordion>

  <Accordion title="Where do I find Germany-specific GOBL documentation?">
    See the [Germany tax regime in GOBL](https://docs.gobl.org/regimes/de) for tax categories and identifiers. The XRechnung mapping lives in [`de-xrechnung-v3`](https://docs.gobl.org/addons/de-xrechnung-v3); ZUGFeRD/Factur-X share the EN 16931 CII profile.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="What should we do if the customer doesn't belong to the Peppol network?">
    In countries where Peppol is the standard but not mandatory, you may still need to issue an e-invoice when the recipient isn't on the network. Both parties can agree on an alternative transfer method, but the invoice must still be EN16931 compliant.

    Recommended approach:

    * Set up a separate workflow that generates the XML without the send-Peppol-document step
    * Or reuse your existing workflow without the customer Peppol ID — the send step is automatically skipped
    * Fetch the generated XML and deliver it through the agreed channel, typically email
  </Accordion>

  <Accordion title="How do I handle B2C invoices in Peppol?">
    B2C invoices typically lack the structured customer information required for Peppol delivery, and most consumers don't have inboxes. Use a conditional workflow:

    1. Add an **If/Else** step that checks for a customer inbox using `count(customer.inboxes, true) > 0`.
    2. On the `false` branch, generate a PDF and email it to the customer, then stop the flow.

    This routes B2B invoices through Peppol while keeping a smooth path for consumers.
  </Accordion>

  <Accordion title="How do I handle 'Receiver Not Found' errors?">
    If a job fails with `KO` and `receiver not found in the peppol network`, treat it like an invalid email address — the recipient simply isn't reachable on Peppol. Add the **Lookup Participant ID** step (ideally in a separate validation workflow run against customer data) so you catch missing IDs before generating the invoice.
  </Accordion>

  <Accordion title="Should I set the `$regime` field when using Peppol?">
    No. The regime is automatically derived from the supplier's settings, which is the recommended approach for Peppol — leave it unset on the document.
  </Accordion>

  <Accordion title="Where do I find Peppol GOBL documentation?">
    See the [`oasis-ubl-v2`](https://docs.gobl.org/addons/oasis-ubl-v2) addon and the [Peppol app reference](/apps/peppol) for required fields, supported document types, and Participant ID schemes.
  </Accordion>
</AccordionGroup>

### Registering supplier questions

**Germany**

<AccordionGroup>
  <Accordion title="How do I onboard a new supplier in Germany?">
    No certificate-based registration is required to issue. To send via Peppol, register the supplier as a Peppol participant (typically by USt-IdNr scheme `9930`). For ZUGFeRD/Factur-X, no registration is needed — the supplier just attaches the XML to their PDF.
  </Accordion>

  <Accordion title="How do I register a supplier with Peppol in Germany?">
    Run the Register Participant workflow with the supplier's USt-IdNr (scheme `9930`). Invopop publishes the participant in Peppol's SMP and routes outbound documents from that point onward.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="How do I register for a Peppol inbox in Invopop?">
    Upload the company as a party (Console → Parties → Suppliers → + New Supplier, or via the Create an Entry API) with name, tax\_id, address, and email. Then run it through the party registration workflow — the contact will receive a registration wizard link to provide proof of ownership.

    Once approved, the party is registered on the Peppol network (SMP+SML+Peppol visibility by default with the `ubl-invoice` doc group) and ready to receive invoices.
  </Accordion>

  <Accordion title="I get 'XXXX:XXXXXXXXX is already registered' when registering a supplier — what now?">
    A supplier with that Participant ID already exists in your workspace. Either reuse the existing party or, if it really is a new entity, check whether it should be registered under an alternative scheme (for example Belgium's `9925` VAT scheme rather than the default `0208`).
  </Accordion>

  <Accordion title="How do I assign multiple inboxes to a single supplier?">
    Register them through different silo entries, even though they represent the same legal party. The supplier must upload proof of ownership for each inbox.
  </Accordion>

  <Accordion title="What are Participant IDs?">
    Unique identifiers for entities on the Peppol network, made up of two parts:

    * **Scheme** — identifies the type of identifier (e.g. `9920` for Spanish VAT, `0208` for Belgian KBO/BCE)
    * **Code** — the actual identification number

    Participant IDs are usually based on VAT numbers or local business identifiers, and Invopop can derive them automatically from a Tax ID. Some countries support multiple schemes — Belgium, for example, defaults to `0208` but some entities are only registered under `9925` (VAT). If you hit a "receiver not found" error, the recipient may be registered under an alternative scheme.
  </Accordion>

  <Accordion title="What visibility level should I set on my Peppol Party?">
    Peppol Party visibility determines what you can send and receive:

    * `smp` — SMP only, for testing
    * `smp+sml` — SMP and SML, useful when you only want to send
    * `smp+sml+peppol` — SMP, SML, and the Peppol Directory, recommended for both sending and receiving (and for being discoverable in the Directory)

    In general, use the highest visibility available.
  </Accordion>
</AccordionGroup>

### Receiving questions

**Peppol**

<AccordionGroup>
  <Accordion title="How do I import received invoices via Peppol?">
    Register the recipient as a Peppol participant with Invopop as their Access Point. Incoming documents are routed through your configured Import workflow, which converts the UBL or CII payload to GOBL and stores the entry in the Expenses folder.
  </Accordion>

  <Accordion title="Can I remove UBL or CII from the 'Peppol receive invoice' workflow if I only use one format?">
    Yes. Either format can be removed based on your needs. The default template includes both for comprehensiveness, but if you're certain you'll only receive invoices in one syntax, dropping the other simplifies the workflow and reduces the apps you need to activate.
  </Accordion>

  <Accordion title="How are incoming Peppol documents converted into GOBL?">
    The Import workflow's UBL and CII parser steps map the inbound XML into a GOBL invoice. From there you can route it to webhooks, Google Drive, accounting integrations, or any other destination — the GOBL representation is the single source of truth for downstream processing.
  </Accordion>
</AccordionGroup>

<Card title="Participate in our community" icon="forumbee" href="https://community.invopop.com" arrow="true" horizontal>
  Ask and answer questions about Germany's regulation →
</Card>