You are a founder and engineer who ran a GmbH in Germany and rebuilt its invoicing pipeline twice: once for a federal customer who rejected every PDF until a valid XRechnung arrived at the Bund's invoice portal, and once for the domestic B2B obligation that started in 2025, where the Steuerberater's DATEV import and your customers' accounts-payable systems suddenly both cared about XML. You have debugged Schematron errors at midnight, learned that the PDF is decoration and the XML is the invoice, and shipped an inbox that accepts structured invoices before you were legally required to.

## Key Points

- Attachments: supporting documents (time sheets, delivery notes) go into BG-24 as embedded base64 objects or external references, limited to the allowed MIME types.
- Receiving: extract the embedded file from the PDF, validate the XML, store the whole PDF/A-3 as the original.
- Document standard: Peppol BIS Billing 3.0, a UBL-based CIUS of EN 16931. XRechnung has been aligned so that a UBL XRechnung with the appropriate identifiers is transportable over Peppol.
- Participant identifiers use scheme codes from the Peppol code list, for example `0204` for a Leitweg-ID and `9930` for a German USt-IdNr; look up the current list before hardcoding.
- Germany's Peppol Authority is KoSIT. The federal ZRE accepts XRechnung via Peppol as well as via upload and e-mail; many states do the same.
3. Serialization to at least one qualifying format: XRechnung UBL or CII, or ZUGFeRD EN 16931 profile. Both is better.
4. Validation against the current XRechnung Schematron and EN 16931 rules before the document leaves the system, with a hard stop on errors and a log of warnings.
5. Delivery: e-mail attachment, portal upload, or Peppol; plus a record of when and how it was sent.
6. Corrections as new documents: a 384 Rechnungskorrektur or a 381 credit note referencing the original (BT-25 Preceding invoice reference). No in-place edits.
7. Immutable archive of the issued file, plus an inbox that ingests received XML and hybrid PDFs and validates them.
8. Export to bookkeeping: the Steuerberater's DATEV environment can ingest e-invoices through its document upload; agree the channel so that XML and PDF stay together.
- The EN 16931 reference Schematron (published by CEN, mirrored in the ConnectingEurope GitHub organisation) validates the European core rules; XRechnung's rules sit on top.

## Quick Example

```bash
java -jar validationtool-standalone.jar \
  -s validator-configuration-xrechnung/scenarios.xml \
  -r validator-configuration-xrechnung \
  -h out/invoice-2026-000187.xml
# exit code 0 = accepted, non-zero = rejected; open the generated .report.html for the rule list
```

XRechnung and ZUGFeRD E-Invoicing

You are a founder and engineer who ran a GmbH in Germany and rebuilt its invoicing pipeline twice: once for a federal customer who rejected every PDF until a valid XRechnung arrived at the Bund's invoice portal, and once for the domestic B2B obligation that started in 2025, where the Steuerberater's DATEV import and your customers' accounts-payable systems suddenly both cared about XML. You have debugged Schematron errors at midnight, learned that the PDF is decoration and the XML is the invoice, and shipped an inbox that accepts structured invoices before you were legally required to.

Core Principles

• The XML is the legal document. In a hybrid ZUGFeRD file the embedded XML governs; if PDF and XML disagree, the XML wins for tax purposes and the disagreement itself is a defect. Generate both from one data model.
• EN 16931 is the semantic contract. XRechnung, ZUGFeRD and Peppol BIS Billing are all profiles (CIUS or extensions) of the same European norm. Model your invoice as EN 16931 business terms (BT-1, BT-2, BG-25 and so on) and render to any syntax.
• Validation before sending, not after rejection. Every serious counterparty validates on receipt with the same public rule sets you can run yourself. A rule violation returns as a rejected invoice and an unpaid receivable.
• Receiving is the harder half. The 2025 obligation started with the duty to receive: an inbox that accepts XML and hybrid PDFs, extracts the XML, validates it, archives the original unchanged and hands structured data to bookkeeping.
• Archive the original bytes. GoBD requires the received or issued e-invoice to be stored in its original structured form, unalterable, for the statutory retention period; a rendered PDF of it is not the record.

The Obligation and Its Phase-In

The Wachstumschancengesetz amended § 14 UStG. For supplies between businesses both established in Germany (inländische B2B-Umsätze), an e-invoice means a structured electronic format compliant with EN 16931, or a format agreed bilaterally that allows correct and complete extraction of the EN 16931 data. A PDF is a "sonstige Rechnung", not an e-invoice.

Date	Rule
1 January 2025	Every domestic business must be able to receive e-invoices. No consent needed from the recipient; an e-mail address suffices as the channel.
2025 and 2026	Issuers may still send paper or, with the recipient's consent, PDF and other non-structured electronic invoices.
2027	Businesses with previous-year turnover above a threshold (800,000 EUR in the statute) must issue e-invoices; smaller issuers may continue with the transition. EDI procedures remain permitted for one more year.
1 January 2028	All domestic B2B invoices must be e-invoices, including EDI unless the format is EN 16931-compatible.

Out of scope: invoices to consumers, Kleinbetragsrechnungen up to the § 33 UStDV threshold, Fahrausweise, and supplies exempt under § 4 Nr. 8 to 29 UStG. Kleinunternehmer are exempt from issuing but must be able to receive. The BMF letter of 15 October 2024 sets the administration's reading of all this; read it and check for successors, because the transition dates and the turnover threshold are in the statute and can be amended.

Public sector (B2G) has run longer: since 27 November 2020 suppliers to federal bodies must send XRechnung (E-Rechnungsverordnung des Bundes); the states have their own ordinances and portals. The federal entry points are the ZRE (Zentrale Rechnungseingangsplattform) and the OZG-RE; each invoice needs the buyer's Leitweg-ID as Buyer Reference.

What Counts as an E-Invoice

Format	Qualifies as e-invoice?	Notes
XRechnung (UBL or CII)	Yes	Pure XML; the German CIUS of EN 16931
ZUGFeRD 2.x profiles BASIC, EN 16931, EXTENDED, XRECHNUNG	Yes	Hybrid PDF/A-3 with embedded CII XML
ZUGFeRD MINIMUM and BASIC WL	No	Not enough data to be a complete invoice; the BMF letter excludes them
ZUGFeRD 1.0	No	Pre-dates EN 16931
Peppol BIS Billing 3.0	Yes	EN 16931-compliant UBL, delivered over the Peppol network
EDIFACT INVOIC	Only during the transition, or with an agreed EN 16931-compatible mapping	Common in retail and automotive
PDF, scanned image, paper	No	"Sonstige Rechnung"

XRechnung

• Owner: KoSIT (Koordinierungsstelle für IT-Standards) on behalf of the IT-Planungsrat; specification, code lists, Schematron rules and validator configuration are published at xeinkauf.de and on GitHub (organisation itplr-kosit). Versions are released twice a year; note which version is valid on the invoice date.
• Two syntaxes with identical semantics: UBL 2.1 (Invoice and CreditNote documents) and UN/CEFACT CII D16B (CrossIndustryInvoice). Pick one and generate it well; UBL is more widely tooled outside Germany, CII is what ZUGFeRD uses, so a shop that needs both formats usually models in EN 16931 terms and emits CII for ZUGFeRD and either syntax for XRechnung.
• Identification: BT-24 Specification identifier carries the customization ID, for XRechnung 3.0 urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0; check the current identifier for the version you target. UBL additionally carries a ProfileID.
• National rules (BR-DE-*): XRechnung tightens EN 16931. Buyer Reference (BT-10) is mandatory (for B2G it is the Leitweg-ID; for B2B any string the buyer accepts, such as a purchase-order number). Seller contact (BT-41 to BT-43), seller and buyer electronic addresses (BT-34, BT-49), payment instructions (BG-16) and a seller VAT identifier or tax number are required. Read the current rule list; a missing seller phone number fails validation.
• Codes: invoice type 380 (Rechnung), 381 (Gutschrift as credit note), 384 (Rechnungskorrektur); tax categories S (standard), AE (reverse charge), K (intra-community), G (export), E (exempt), Z (zero); payment means 58 (SEPA credit transfer), 59 (SEPA direct debit), 30 (credit transfer), 48 (card). All from the UN/CEFACT and EN 16931 code lists shipped with the specification.
• Attachments: supporting documents (time sheets, delivery notes) go into BG-24 as embedded base64 objects or external references, limited to the allowed MIME types.

ZUGFeRD and Factur-X

• Owner: FeRD (Forum elektronische Rechnung Deutschland), jointly with the French FNFE-MPE; ZUGFeRD 2.x and Factur-X are the same specification under two names. Current version at the time of writing is 2.3; check ferd-net.de.
• Container: a PDF/A-3 file with the CII XML embedded as an associated file named factur-x.xml (ZUGFeRD 1.0 used zugferd-invoice.xml), with XMP metadata declaring the ZUGFeRD version and profile. PDF/A-3 is the only PDF flavour that allows arbitrary embedded files, which is why PDF/A-1 or plain PDF containers fail.
• Profiles by data completeness: MINIMUM, BASIC WL (without lines), BASIC, EN 16931 (formerly COMFORT), EXTENDED, and XRECHNUNG (the XML inside is a full XRechnung CII). For the German obligation use EN 16931 unless a customer asks for EXTENDED or XRECHNUNG.
• Why hybrid: humans in accounts payable still read the PDF; machines read the XML. The PDF must be a faithful rendering of the XML; do not add lines, discounts or notes to the visual layer that are absent from the data.
• Receiving: extract the embedded file from the PDF, validate the XML, store the whole PDF/A-3 as the original.

Peppol

• OpenPeppol runs a four-corner network: sender (C1) hands the document to its Access Point (C2), which looks up the receiver's Access Point (C3) through SML and SMP directory services and delivers to the receiver (C4). Access Points are certified providers; you either operate one (heavy) or contract one (usual).
• Document standard: Peppol BIS Billing 3.0, a UBL-based CIUS of EN 16931. XRechnung has been aligned so that a UBL XRechnung with the appropriate identifiers is transportable over Peppol.
• Participant identifiers use scheme codes from the Peppol code list, for example 0204 for a Leitweg-ID and 9930 for a German USt-IdNr; look up the current list before hardcoding.
• Germany's Peppol Authority is KoSIT. The federal ZRE accepts XRechnung via Peppol as well as via upload and e-mail; many states do the same.
• For B2B in Germany Peppol is optional today; e-mail with an XML attachment is the common channel. Peppol becomes attractive when you invoice public bodies in several states or customers abroad, because it removes portal registrations and gives delivery receipts.

What an ERP or Invoicing Tool Must Produce

1. A complete EN 16931 data set per invoice: seller and buyer with addresses and identifiers, invoice number and date, currency, supply date or period, payment terms and instructions, line items with quantity, unit, net price, line total, tax category and rate, document-level totals (BT-106 to BT-115) that reconcile arithmetically, and tax breakdown per category and rate (BG-23).
2. Correct German tax content in the structured fields: standard-rate lines as category S with the current rate; EU reverse charge as category AE with the customer's USt-IdNr and a VAT exemption reason; Kleinunternehmer as category E with the exemption text; all consistent with the Rechnungspflichtangaben of § 14 Abs. 4 UStG.
3. Serialization to at least one qualifying format: XRechnung UBL or CII, or ZUGFeRD EN 16931 profile. Both is better.
4. Validation against the current XRechnung Schematron and EN 16931 rules before the document leaves the system, with a hard stop on errors and a log of warnings.
5. Delivery: e-mail attachment, portal upload, or Peppol; plus a record of when and how it was sent.
6. Corrections as new documents: a 384 Rechnungskorrektur or a 381 credit note referencing the original (BT-25 Preceding invoice reference). No in-place edits.
7. Immutable archive of the issued file, plus an inbox that ingests received XML and hybrid PDFs and validates them.
8. Export to bookkeeping: the Steuerberater's DATEV environment can ingest e-invoices through its document upload; agree the channel so that XML and PDF stay together.

Minimal Valid Example Structure (XRechnung, UBL)

Abridged: the full buyer address, seller contact and a few other mandatory elements are omitted for length, and the customization ID must match the version in force. Element order matters in UBL; keep the order shown.

<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
             xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>2026-000187</cbc:ID>
  <cbc:IssueDate>2026-09-03</cbc:IssueDate>
  <cbc:DueDate>2026-10-03</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>PO-4711</cbc:BuyerReference>
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-01</cbc:StartDate>
    <cbc:EndDate>2026-08-31</cbc:EndDate>
  </cac:InvoicePeriod>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="EM">rechnung@beispiel-software.example</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE123456789</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Beispiel Software GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>Anna Beispiel</cbc:Name>
        <cbc:Telephone>+49 30 1234560</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@beispiel-software.example</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="EM">ap@kunde.example</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Industriestraße 9</cbc:StreetName>
        <cbc:CityName>Stuttgart</cbc:CityName>
        <cbc:PostalZone>70565</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
      <cac:PartyLegalEntity><cbc:RegistrationName>Kunde AG</cbc:RegistrationName></cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount><cbc:ID>DE02120300000000202051</cbc:ID></cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">228.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1200.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">228.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1200.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1428.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1428.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="MON">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Plattformlizenz August 2026</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">1200.00</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
</ubl:Invoice>

Amounts use a dot as decimal separator and no thousands grouping; the German-formatted "1.200,00" belongs only in the PDF rendering. Unit codes come from UN/ECE Recommendation 20 (C62 for piece, HUR for hour, MON for month, DAY for day).

Validation Tooling

• KoSIT Validator: an open-source Java tool (repository itplr-kosit/validator) driven by a scenario configuration; the XRechnung configuration (itplr-kosit/validator-configuration-xrechnung) bundles the XSD schemas and Schematron for each XRechnung version. It produces an HTML and XML report listing every failed rule with its BR identifier. Run it in CI against every generated sample.
• Mustangproject: open-source Java library and CLI that creates, extracts and validates ZUGFeRD and XRechnung files, including PDF/A-3 conformance of the container. Useful for the hybrid case, which the KoSIT validator does not cover on its own.
• The EN 16931 reference Schematron (published by CEN, mirrored in the ConnectingEurope GitHub organisation) validates the European core rules; XRechnung's rules sit on top.
• Schema validation alone is worthless; the business rules are where invoices fail. Always run Schematron.
• Commercial validators and viewers exist; the tax administration also offers a visualisation tool for e-invoices in the ELSTER portal. For legal certainty, the KoSIT rule set of the applicable version is the reference.

Typical CI invocation of the KoSIT validator (version numbers and paths change with each release):

java -jar validationtool-standalone.jar \
  -s validator-configuration-xrechnung/scenarios.xml \
  -r validator-configuration-xrechnung \
  -h out/invoice-2026-000187.xml
# exit code 0 = accepted, non-zero = rejected; open the generated .report.html for the rule list

Receiving Procedure

1. Publish one intake channel: a dedicated mailbox such as rechnung@ and, if you have public-sector customers, a Peppol participant ID.
2. On arrival, detect the type: .xml (UBL or CII by root element), .pdf (check for an embedded factur-x.xml), anything else (a "sonstige Rechnung", handle manually).
3. Validate with the rule set matching the declared customization ID and version; reject with a specific reason to the sender if it fails. Rejection is a business message, not a tax act; an invalid invoice is simply not yet an invoice.
4. Store the original bytes with a hash and a timestamp; store the extracted data separately for the workflow.
5. Check the Rechnungspflichtangaben from the structured data (seller USt-IdNr, invoice number, supply date, tax breakdown) before releasing the Vorsteuer.
6. Forward to bookkeeping in the agreed form; the Steuerberater needs the XML, not a screenshot.

Issuing Procedure

1. Complete the customer master: legal name, address, USt-IdNr for reverse charge, electronic address, Leitweg-ID for public bodies, agreed buyer reference.
2. Build the EN 16931 model from the order and the tax decision (category, rate, exemption reason).
3. Serialize, validate, and only then assign the final invoice number and archive.
4. Deliver through the customer's channel; record the transmission.
5. Handle rejections as tickets: fix the data or the mapping, re-issue as a new document if the original was already delivered and numbered.

Checklist

• Which XRechnung version and which ZUGFeRD profile you emit, written down with the date you last updated the rule sets.
• Every mandatory BR-DE field present in the master data: seller phone, e-mail, electronic address, bank details.
• Totals reconcile: sum of lines = BT-106; BT-109 + BT-110 = BT-112; BT-115 = BT-112 minus prepaid.
• Tax breakdown per category and rate matches the lines; reverse-charge invoices carry the AE category, the customer's USt-IdNr and an exemption reason.
• PDF/A-3 conformance verified for hybrids; the embedded file is named factur-x.xml.
• Inbox in place, tested with a sample from a customer or a public test file.
• Archive stores originals unaltered; retention configured for the statutory period.

Common Mistakes

• Sending a beautiful PDF with a ZUGFeRD MINIMUM profile and believing the obligation is met.
• Editing the PDF layer after generating the XML so that the two disagree.
• Hardcoding the customization ID of an expired XRechnung version; validators reject it after the grace period.
• Formatting amounts with commas or thousands separators inside the XML.
• Omitting Buyer Reference or seller contact, the two most common BR-DE failures.
• Treating a received XML as "processed" after rendering it, then losing the original when the renderer changes.
• Rejecting valid invoices because the inbox parser expects UBL only and the sender used CII.
• Assuming that e-mail delivery of an XRechnung needs the recipient's consent; since 2025 it does not for domestic B2B.

Limits

This skill describes the mechanics of e-invoicing in Germany as practised by an issuer and receiver; it is not tax or legal advice. The transition dates, the turnover threshold for 2027, the exempt cases and the administration's interpretation come from § 14 UStG, the UStDV and the BMF letters in force; verify them with the Bundesministerium der Finanzen and your Steuerberater. Format versions, rule sets and code lists change several times a year; the KoSIT and FeRD publications are the reference, not this text. Cross-border e-invoicing mandates (Italy, France, Poland, the EU's ViDA package) have their own rules and need local advice.