Facture d’autofacturation

L’autofacturation au sens du § 14 al. 2 de la loi allemande sur la TVA : c’est le preneur qui établit le document, pas le fournisseur. Deux lignes, deux taux de TVA, ni supplément ni remise – et comme seule différence avec une facture commerciale ordinaire, le type de document 389.

Certains liens de cette page mènent à la documentation approfondie dans l’espace client et demandent une connexion.

Deux choses appelées « Gutschrift »

Le mot allemand recouvre deux réalités totalement différentes, et les confondre est l’erreur la plus fréquente dans ce domaine :

Profil COMFORT plutôt qu’EXTENDED

Contrairement aux autres exemples de ces pages, ce document relève du profil Profile.Comfort – identifiant de guideline urn:cen.eu:en16931:2017, c’est-à-dire le profil EN 16931 pur, sans extension. Ce n’est pas une négligence de la référence mais l’affirmation que ce cas de gestion se passe des champs EXTENDED.

En conséquence, tous les champs que présente la facture de marchandises étendue sont absents ici : nom de document (BT-X-2), indicateur de test, indications de conditionnement (BT-X-9) et bases d’imposition étendues. Les renseigner ne serait pas une erreur – le writer les écarterait silencieusement dans le profil COMFORT.

1. En-tête du document

Numéro, date et devise comme dans toute facture. La seule ligne qui fait de ce document une autofacturation est invoice.Type.

2. Notes en texte libre

Quatre notes dans ram:IncludedNote (BG-1). La première se passe de subjectCode, deux portent REG pour les mentions réglementaires, la dernière ACB pour l’identification du format.

3. Vendeur avec deux immatriculations fiscales

AddSellerTaxRegistration peut être appelée plusieurs fois. Ici, le numéro fiscal national (FC, BT-32) vient d’abord, puis le numéro de TVA (VA, BT-31). L’ordre dans le XML suit l’ordre des appels.

4. Acheteur – avec son propre numéro fiscal

C’est ici que l’autofacturation apparaît dans le modèle de données : comme c’est le preneur qui établit le document, lui aussi porte un numéro de TVA (BT-48). Sur une facture commerciale ordinaire, ce champ reste le plus souvent vide.

5. Lignes du document

Deux lignes (BG-25) sans aucune remise sur article. Prix brut et prix net sont donc identiques – la référence écrit tout de même les deux éléments. À noter : les deux lignes relèvent de la même catégorie de TVA S et ne diffèrent que par le taux, 19 % pour la papeterie, 7 % pour les denrées alimentaires.

6. Moyen de paiement

Virement SEPA (code de type 58) et compte du bénéficiaire. Les autres moyens de paiement et leurs champs sont décrits sous Charger et enregistrer.

7. Ventilation de la TVA

Sans supplément ni remise au niveau du document, la base d’imposition est simplement la somme des lignes correspondantes – pas de allowanceChargeBasisAmount, aucun calcul de correction :

8. Condition de paiement

Uniquement une date d’échéance, sans escompte. Que description vaille ici null est délibéré : le writer n’émet alors pas du tout ram:Description plutôt que d’écrire un élément vide.

9. Totaux du document

10. Enregistrement

Ici, c’est Profile.Comfort et non Profile.Extended – la seule différence avec les autres exemples à cet endroit :

11. Contrôle croisé

Le fichier produit doit présenter la même structure arborescente que E10_01_Gutschrift.xml du jeu d’exemples FeRD. Les nombres se comparent numériquement, de sorte que 9.90 et 9.9000 comptent comme égaux.

Quant à savoir si le document respecte également le jeu de règles, vous le vérifiez soit dans le navigateur, soit directement depuis votre code. Pour le regard d’un humain sur le document, le visualiseur produit une version lisible :

C’est une simple vue, ni document juridique ni PDF ZUGFeRD hybride – détails sous Représentation visuelle.