La facturation électronique est un domaine où trois métiers se parlent sans se comprendre : la comptabilité, l’informatique et le droit fiscal emploient les mêmes mots pour des choses différentes. Ce glossaire explique les termes qui apparaissent réellement dans les rapports de contrôle, les contrats et les courriels du cabinet — brièvement, avec un renvoi là où c’est développé.
Formats et normes
| Facture électronique | Une facture dans un format structuré exploitable par une machine. Un PDF sans données structurées n’en est pas une, même envoyé par courriel. |
| EN 16931 | La norme européenne qui définit le modèle sémantique d’une facture : quelles données existent et comment elles s’appellent. Tout le reste en est une déclinaison — voir EN 16931. |
| ZUGFeRD | Le format hybride allemand : un PDF/A-3 avec XML embarqué, lisible par l’humain et la machine dans un seul fichier — voir ZUGFeRD. |
| Factur-X | Le nom français du même format hybride ; techniquement la même spécification, maintenue en commun — voir Factur-X. |
| XRechnung | Le standard allemand de XML pur, sans page visible, surtout utilisé avec le secteur public. E-Rechnung Pro le contrôle mais ne le produit pas. |
| Format hybride | Page visible et données structurées dans le même fichier. En cas d’écart, c’est la partie structurée qui l’emporte. |
| UBL | Une syntaxe XML (OASIS) dans laquelle la norme peut s’exprimer. Syntaxe obligatoire sur le réseau Peppol. |
| CII | Cross Industry Invoice, la seconde syntaxe admise (UN/CEFACT). Le XML de ZUGFeRD et de Factur-X est du CII. |
| PDF/A-3 | La variante d’archivage du PDF qui autorise l’embarquement de fichiers — la condition du format hybride, voir PDF/A-3. |
| CIUS | « Core Invoice Usage Specification » : un resserrement de la norme qui n’ajoute rien. Exemples : XRechnung, Peppol BIS Billing 3.0. |
| Extension | L’inverse : des champs que la norme ne connaît pas — c’est ainsi que fonctionne le profil EXTENDED. |
| FeRD | Le forum allemand qui publie ZUGFeRD, hébergé par l’AWV et fondé en 2010. |
La structure d’une facture : BT et BG
| BT-… | « Business term » : un champ isolé de la norme, par exemple le total ou la date de livraison. Le numéro est fixe, le nom de l’élément varie selon la syntaxe. |
| BG-… | « Business group » : un groupe de champs liés, comme une ligne de facture (BG-25) ou une ventilation de TVA (BG-23). |
| BT-23 | Le processus métier. Les fichiers produits ici portent l’identifiant usuel du processus de facturation standard. |
| BT-24 | L’identifiant de la spécification. Tout contrôle y lit le profil et la conformité à la norme. |
| BT-10 | La référence acheteur. En Allemagne, le secteur public y met le Leitweg-ID. |
| BT-72 / BG-14 | Date de livraison et période de facturation. Pour une livraison intracommunautaire, l’une des deux devient obligatoire. |
| BT-118 / BT-151 | Le code catégorie de TVA dans la ventilation et sur la ligne — voir TVA. |
| BT-120 / BT-121 | Le motif d’exonération en texte et en code. |
| Leitweg-ID | L’identifiant de routage d’une administration allemande. Il figure dans la facture en BT-10 et sert d’adresse de livraison sur Peppol. |
| Type de document (BT-3) | Un code chiffré plutôt qu’un mot : 380 facture, 381 avoir, 384 facture rectificative, 386 facture d’acompte. Le titre ne décide pas, le code décide. |
| Avoir | Un document à part, code 381, qui renvoie à la facture d’origine — et non une facture avec un signe moins. |
L’emplacement de ces champs dans l’arbre XML est décrit dans la structure du XML.
Profils
| MINIMUM | Un en-tête réduit seulement. Ne compte pas comme facture électronique : les mentions obligatoires manquent. |
| BASIC WL | « Without lines » : sans lignes de facture. Ne compte pas non plus. |
| BASIC | Le cas simple et conforme : lignes et données de TVA présentes. |
| EN 16931 | Le modèle de base complet — le choix qui ne bloque nulle part. |
| EXTENDED | Une extension pour des champs hors norme. Nécessaire seulement si la norme n’a vraiment pas de place — voir les profils. |
Contrôle et règles
| Schéma (XSD) | La première couche : le XML est-il seulement bien formé ? Un fichier qui échoue ici est techniquement cassé. |
| Schematron | La deuxième couche : des règles sur le contenu, écrites comme des expressions de test. Tous les outils du domaine fonctionnent ainsi. |
| Règle de gestion (BR-…) | Une exigence unique de la norme, par exemple qu’une facture porte une date. Le code figure dans chaque message — voir les règles de gestion. |
| BR-CO-… | Les règles de calcul : totaux, arrondis, cohérence entre les montants. |
| BR-DE-… | Les règles allemandes supplémentaires, au-delà de la norme. |
| PEPPOL-EN16931-… | Les règles propres au réseau Peppol. Elles ne s’appliquent qu’au dépôt sur le réseau. |
| Validation | Le contrôle face au schéma, aux règles et aux listes de codes. Elle prouve la forme, pas l’exactitude du contenu — voir la validation. |
| Mustang | Une bibliothèque Java libre et son outil en ligne de commande pour ZUGFeRD et Factur-X, très utilisés pour le contrôle — voir Mustang. |
TVA
| Code catégorie | La lettre qui dit pourquoi un taux s’applique : S taux normal, Z taux zéro, E exonéré, AE autoliquidation, K livraison intracommunautaire, G exportation, O hors champ. |
| Autoliquidation | La taxe est due par le preneur. Dans le fichier : code AE, taux zéro et motif d’exonération. |
| Livraison intracommunautaire | Livraison de biens exonérée vers un autre État membre. Code K — avec date et pays de livraison devenus obligatoires. |
| VATEX | La liste des codes de motifs d’exonération, par exemple VATEX-EU-AE. Chaque code appartient à une seule catégorie. |
| Numéro de TVA | Le numéro avec préfixe pays. Pour une livraison intracommunautaire, sa validité est une condition de fond de l’exonération. |
| VIES | Le service d’interrogation de la Commission européenne. Il répond à une seule question : valide ou non. |
| Confirmation qualifiée | L’interrogation allemande qui compare en plus le nom et l’adresse. C’est son résultat que l’on conserve comme preuve. |
| État récapitulatif | La déclaration des opérations intracommunautaires. Depuis 2020, condition de l’exonération et non simple formalité. |
| Déduction de la TVA | Le droit de récupérer la taxe payée. C’est la raison pour laquelle la forme d’une facture reçue importe. |
| Petite entreprise (§ 19 UStG) | Régime allemand de franchise. L’entreprise doit pouvoir recevoir des factures électroniques, mais pas en émettre — voir TVA. |
Acheminement et réseaux
| Peppol | Un réseau d’acheminement à quatre coins, pas un format — voir Peppol. |
| Peppol BIS Billing 3.0 | La spécification de facture qui y circule : une CIUS de la norme, en UBL. |
| Point d’accès | Le prestataire accrédité par lequel on atteint le réseau. Personne ne s’y branche directement. |
| SMP / SML | Les annuaires qui disent qui est joignable où, et quels types de documents il accepte. |
| AS4 | Le protocole de transport du réseau, dans une déclinaison propre à Peppol. |
| Identifiant Peppol | L’adresse réseau d’un participant, écrite en schéma et valeur — un numéro de TVA ou un GLN, par exemple. |
| Modèle à cinq coins | Les quatre coins plus l’administration fiscale, qui reçoit les données de facturation. |
| E-reporting | La transmission des données de facturation à l’administration — une obligation distincte de l’envoi de la facture. |
Droit, conservation, organisation
| Circulaire du BMF | La doctrine du ministère allemand des finances. Pas une loi, mais ce sur quoi s’appuie un contrôle. |
| GoBD | Les exigences allemandes sur les livres et pièces électroniques : inaltérabilité, exploitabilité machine, traçabilité, documentation des procédures. |
| Documentation des procédures | La description du fonctionnement de votre archive. L’élément qui manque le plus souvent — voir la conservation. |
| « Autre facture » | Le pendant de la facture électronique : papier ou PDF simple sans données structurées. |
| Facture de faible montant | Une facture jusqu’à 250 € TTC. L’obligation allemande ne s’y applique pas — l’émettre au format reste permis. |
| Pièce | La facture elle-même en tant que fichier — ce dont le cabinet a besoin. |
| Lot d’écritures | Des écritures prêtes issues d’un logiciel comptable. Une livraison tout autre — voir la remise au cabinet. |
| ViDA | Le paquet européen « VAT in the Digital Age », moteur des calendriers nationaux — voir les échéances. |
Questions fréquentes
XRechnung vaut-il mieux que ZUGFeRD ?
Ni l’un ni l’autre. XRechnung est du XML pur, usuel avec le secteur public ; ZUGFeRD est hybride, avec une page visible en plus. Les deux satisfont l’obligation.
Si ZUGFeRD est un PDF, pourquoi parle-t-on de facture électronique ?
Parce que les données qui font foi s’y trouvent en XML. Un PDF sans ce XML est une « autre facture », pas une pièce structurée.
Quelle différence entre profil et syntaxe ?
La syntaxe est la langue (UBL ou CII), le profil l’étendue (de MINIMUM à EXTENDED). Les deux figurent dans le fichier, indépendamment.
Ai-je besoin de Peppol si je produis déjà du Factur-X ?
Pas nécessairement. Peppol est une voie d’acheminement ; en Allemagne la voie est libre et le courriel suffit.
Que signifie un code comme BR-CO-15 dans un rapport ?
Il nomme exactement l’exigence à laquelle le fichier a échoué. Le code est le chemin le plus court vers l’endroit — les plus fréquents sont listés dans les règles de gestion.
Si vous ne retenez que cinq termes
- EN 16931 est le modèle ; tout le reste en est une déclinaison.
- Syntaxe (UBL ou CII) et profil (de MINIMUM à EXTENDED) sont deux questions distinctes.
- BT et BG sont les numéros de champs dans lesquels tout le monde parle.
- Le code catégorie dit pourquoi un taux s’applique — pas le taux lui-même.
- Peppol est la voie, pas le format.
Envie de retrouver un terme dans un vrai fichier ? Déposez une facture — le rapport nomme le numéro de champ et la règle en clair.