# Facturation électronique en Allemagne (XRechnung)

> Statut au 21/07/2026 : **variante non disponible**. Cette page documente
> l'écart explicitement plutôt que de laisser une impression de couverture.

## Ce que dit la réglementation

L'Allemagne impose progressivement (mandat 2027-2028) la facturation
électronique structurée, avec **XRechnung** comme spécialisation de
l'EN 16931 — disponible en sérialisation **CII ou UBL**.

## Pourquoi XRechnung n'est pas exposée dans Heartwood aujourd'hui

Le PRD (§6, jalon J4) conditionne explicitement la disponibilité de la
variante `xrechnung` à un **spike licences/corpus** — vérifier que les
artefacts officiels (schémas, schematrons, corpus de test KoSIT) peuvent
être obtenus et utilisés légalement avant d'annoncer un support réel.
**Ce spike n'a pas été réalisé dans cet environnement.**

Conséquence directe et volontaire : `POST /v1/generate/ubl?variant=xrechnung`
retourne HTTP 400, sans casser la disponibilité de `fr-socle` ni
`peppol-bis` (Story 6.1, AC #2) :

```json
{
  "type": "unknown-ubl-variant",
  "title": "Variante UBL non supportée",
  "status": 400,
  "detail": "variante \"xrechnung\" non encore disponible (spike licences/corpus J4 requis, PRD §6) — utilisez fr-socle ou peppol-bis",
  "instance": "01H..."
}
```

## Ce qui fonctionne déjà pour un marché allemand

Le modèle pivot EN 16931 commun (utilisé par CII, UBL fr-socle et
peppol-bis) couvre le socle sémantique partagé par XRechnung — un document
CII ou UBL généré par Heartwood aujourd'hui n'est **pas** un XRechnung
certifié, mais partage la même norme de base. Dès que le spike J4 valide
la disponibilité des artefacts officiels, cette page sera mise à jour et
la variante exposée sans changement de contrat d'API (même endpoint,
nouvelle valeur de `variant` acceptée).