Is XRechnung mandatory for small businesses in Germany?

Businesses with more than EUR 800,000 in prior-year turnover generally must issue e-invoices from 2027. Issuers at or below that threshold can use the transition rule through the end of 2027 where its statutory conditions apply. From 2028, the requirements generally apply to affected domestic B2B transactions, subject to statutory exceptions.

What changed with XRechnung 4.0?

XRechnung 4.0 is still being prepared. KoSIT states that its preliminary specification is not intended for production use. QuoteCash currently emits the XRechnung 3.0 customization identifier and does not claim production support for 4.0.

Can I validate an existing XRechnung XML before sending it?

Yes. QuoteCash exposes POST /api/v1/validate so you can submit XML for validation and inspect structured feedback before you send or archive the document.

How long do electronic invoices need to be stored in Germany?

For VAT purposes, incoming and outgoing invoices generally must be retained for eight years. For an e-invoice, at least the structured part must remain intact in its original form throughout that period.

Can I send a PDF together with XRechnung?

You can provide a human-readable view or PDF for convenience, but the structured XML remains the machine-readable invoice data. The recipient requirements decide what is acceptable.

Is XRechnung always better than ZUGFeRD?

No. XRechnung is usually better for strict XML workflows and public-sector recipients. ZUGFeRD is often better when the recipient also expects a readable PDF document.

Why does valid-looking invoice data fail XRechnung validation?

Validation checks structured business rules. Missing references, inconsistent tax data, invalid codes, or rounding mismatches can fail even when the visible invoice looks fine.

REST API for invoice workflows

XRechnung API for Germany

Generate XRechnung XML from structured invoice data and integrate creation directly into ERP, SaaS, and billing workflows.

QuoteCash validates the request, creates UBL XML, and sends the generated document through the configured validation service before returning it.

UBL 2.1 XMLValidation before returnBusiness-scoped API keys

01QuoteCash

Generate XRechnung

POST /api/v1/invoices/xrechnung checks required request fields, generates UBL XML, and validates the result before returning it.

02QuoteCash

Validate XML

POST /api/v1/validate checks existing XML with the same configured validation service and returns structured errors and warnings.

03QuoteCash

REST API for integrations

Business-scoped API keys, documented limits, and one access model support ERP, SaaS, and automation workflows.

How it works

Generation and validation are separate stages

The legacy generator first validates the JSON request and checks additional XRechnung fields such as issue date, VAT IDs, postal data, seller email and phone, and VAT rates. It then normalizes the data and generates UBL 2.1 XML.

The generator recalculates line, tax, and payable totals from quantity, net unit price, and VAT rate using two-decimal rounding; request totals are not copied into the XML. The generated XML is then passed to the same configured validation engine used by POST /api/v1/validate.

The XML identifies the XRechnung 3.0 CIUS through urn:xeinkauf.de:kosit:xrechnung_3.0. This repository does not pin a specific 3.0.x KoSIT bundle: the exact XSD and Schematron configuration belongs to the externally configured validator service, so QuoteCash does not claim a verified 3.0.2 bundle.

Who it’s for

Who is this for?

Software products

SaaS and billing products can generate structured invoices in the backend without maintaining a separate XML serializer.

SaaS developers

Billing products need deterministic backend generation and validation, not a manual export screen. The route fits checkout, subscription, and ERP sync flows without adding a separate XML layer.

Agencies and resellers

Agencies inheriting compliance deadlines need customer isolation and clear revocation paths. Business-scoped keys are easier to hand over cleanly than shared export credentials.

ERP integrators

Integrators need explicit validation failures and predictable quota behavior. That is easier to operationalize than embedding a one-off XML library inside middleware.

Editorial note

Last reviewed: July 24, 2026

Why QuoteCash writes about XRechnung

QuoteCash is a German B2B SaaS product from Luchianenco Labs. The product handles quotes, invoices, API keys, validation workflows, and structured e-invoicing output. This page is written from a software and finance operations perspective; it is not tax or legal advice.

Implementation guidance

What XRechnung actually is

XRechnung is a structured XML invoice format used in Germany. An additional PDF can help people view an invoice, but it does not replace the authoritative structured data. XRechnung describes the seller, buyer, invoice number, dates, line items, tax categories, totals, payment terms, and routing references in a way that accounting and procurement systems can process without OCR or manual retyping.

For developers, the important point is that XRechnung is not a PDF export with a different file extension. It is a data contract. If your upstream invoice data is incomplete, inconsistent, or too loosely modeled, the XML will fail even if the invoice looks reasonable in a user interface.

Structured XML, not a visual document.
Aligned with EN 16931 and German XRechnung rules.
Commonly required by public-sector and strict procurement workflows.
Needs validation before delivery or long-term archiving.

Implementation guidance

Which version and syntax QuoteCash generates

QuoteCash generates UBL 2.1 and sets the CustomizationID urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. XRechnung CII output is not implemented. The profile identifier is fixed to the Peppol Billing business process; the request does not expose a configurable BT-23 value.

The API supports Buyer Reference and seller and buyer electronic addresses with schemeID. If explicit endpoint_id values are missing, the generator falls back to a VAT ID or email address. The configured external validator determines whether the output passes the current rules; this repository does not pin its exact 3.0.x bundle.

Implementation guidance

XRechnung versus a PDF invoice

A PDF invoice is optimized for people. It can be opened, read, printed, and attached to an email, but software usually has to infer the invoice data from the visual representation. XRechnung is optimized for systems. The buyer name, VAT amount, payment due date, and invoice totals are explicit data fields.

That makes XRechnung powerful but unforgiving. A PDF can hide inconsistent source data behind a clean layout. XML cannot. If the buyer reference is missing, the VAT category does not match the line item, or totals do not reconcile after rounding, validation can fail before the customer ever sees the invoice.

Implementation guidance

Common validation errors teams should expect

Most validation problems start in customer and invoice master data, not in the final XML serializer. Typical failures include missing buyer references, incomplete postal addresses, invalid VAT IDs, wrong country or currency codes, tax categories that do not match line items, and totals that differ by a few cents because rounding rules are inconsistent.

QuoteCash checks required fields before generation and then submits the generated XML to the configured service. On a normative failure, the legacy endpoint returns HTTP 422 together with the XML and structured validation details for diagnosis.

Buyer reference or Leitweg-ID missing for the recipient.
Seller or buyer electronic address or schemeID is invalid.
Seller or buyer VAT ID does not match expected format.
Tax category, tax rate, and exemption reason are inconsistent.
Net, tax, and gross totals do not reconcile.

Example

API example: generate XRechnung from invoice data

The endpoint validates the request, generates UBL XML, and validates the result before returning it. This payload matches the published request schema.

POST /api/v1/invoices/xrechnung
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "schema_version": "1",
  "invoice_number": "RE-2026-1042",
  "issue_date": "2026-07-24",
  "due_date": "2026-08-07",
  "currency": "EUR",
  "buyer_reference": "04011000-12345-03",
  "seller": {
    "name": "Muster GmbH",
    "vat_id": "DE123456789",
    "street": "Musterstraße 1",
    "city": "Berlin",
    "postal_code": "10115",
    "country": "DE",
    "email": "rechnung@muster.example",
    "phone": "+49 30 123456",
    "endpoint_id": "rechnung@muster.example",
    "endpoint_scheme": "EM"
  },
  "buyer": {
    "name": "Beispielkunde GmbH",
    "vat_id": "DE987654321",
    "street": "Kundenweg 2",
    "city": "Hamburg",
    "postal_code": "20095",
    "country": "DE",
    "endpoint_id": "buchhaltung@kunde.example",
    "endpoint_scheme": "EM"
  },
  "line_items": [
    {
      "description": "Implementierung E-Rechnung",
      "quantity": 1,
      "price": 1200,
      "total": 1200,
      "vatRate": 19,
      "unitCode": "C62"
    }
  ],
  "totals": {
    "net": 1200,
    "tax": 228,
    "gross": 1428
  },
  "payment": {
    "iban": "DE02120300000000202051",
    "bic": "BYLADEM1001"
  }
}

Buyer reference is often the difference between a processable invoice and a rejected one.
Validation should run before the XML is sent to a customer portal or archived as final.

Implementation

XRechnung implementation checklist

1Add buyer reference, Leitweg-ID, VAT ID, and country code fields to customer data.
2Define rounding rules for line totals, tax totals, and invoice totals.
3Validate request payloads before XML generation.
4Validate generated XML before sending or storing it as final.
5Map validation errors to user-friendly finance and support messages.
6Keep sent and received structured original files unchanged in your own archive; QuoteCash is not a complete audit-proof archive.

Related QuoteCash pages

Validate XRechnung XML onlineValidate existing XML before it enters a customer portal, billing queue, or archive.ZUGFeRD APIGenerate hybrid PDFs with embedded CII XML when customers need readable and machine-readable invoice data.German e-invoicing deadlinesUnderstand the German mandate timeline and choose between XRechnung and ZUGFeRD.XRechnung API documentationReview request fields, responses, and integration examples.Payment inflow forecast APIAnalyze stored invoices and expected payment inflows through a REST API.

Official sources and standards

German Federal Ministry of Finance: e-invoicing FAQThe BMF explains the German B2B e-invoicing rules, transition periods, exceptions, and the distinction between structured e-invoices and other invoices.KoSIT / XStandards Einkauf: XRechnungKoSIT publishes XRechnung specification material, validator configuration, test assets, code lists, and Schematron components.KoSIT / XStandards: preparing XRechnung 4.0KoSIT explains that the preliminary XRechnung 4.0 specification is not intended for production use.

Frequently Asked Questions

Is XRechnung mandatory for small businesses in Germany?: Businesses with more than EUR 800,000 in prior-year turnover generally must issue e-invoices from 2027. Issuers at or below that threshold can use the transition rule through the end of 2027 where its statutory conditions apply. From 2028, the requirements generally apply to affected domestic B2B transactions, subject to statutory exceptions.
What changed with XRechnung 4.0?: XRechnung 4.0 is still being prepared. KoSIT states that its preliminary specification is not intended for production use. QuoteCash currently emits the XRechnung 3.0 customization identifier and does not claim production support for 4.0.
Can I validate an existing XRechnung XML before sending it?: Yes. QuoteCash exposes POST /api/v1/validate so you can submit XML for validation and inspect structured feedback before you send or archive the document.
How long do electronic invoices need to be stored in Germany?: For VAT purposes, incoming and outgoing invoices generally must be retained for eight years. For an e-invoice, at least the structured part must remain intact in its original form throughout that period.
Can I send a PDF together with XRechnung?: You can provide a human-readable view or PDF for convenience, but the structured XML remains the machine-readable invoice data. The recipient requirements decide what is acceptable.
Is XRechnung always better than ZUGFeRD?: No. XRechnung is usually better for strict XML workflows and public-sector recipients. ZUGFeRD is often better when the recipient also expects a readable PDF document.
Why does valid-looking invoice data fail XRechnung validation?: Validation checks structured business rules. Missing references, inconsistent tax data, invalid codes, or rounding mismatches can fail even when the visible invoice looks fine.