Date de livraison dans ZUGFeRD et XRechnung (BT-72) : la reprendre et la corriger correctement

De nombreux convertisseurs automatiques indiquent simplement la date de facturation comme date de livraison – et c'est une erreur. La date réelle de livraison ou de prestation constitue, dans la norme EN 16931, un champ à part entière (BT-72) qui doit refléter le moment réel de la livraison, et non le jour où la facture a été rédigée.

> Réponse rapide : La date de livraison (BT-72, désignée dans le XML par ActualDeliveryDate) est le jour de la livraison ou de la prestation réelle – et non la date de facturation (BT-2). Les deux peuvent différer. TaxLayer détecte la date de livraison de façon autonome à partir de la facture et permet de la vérifier et de la corriger avant la génération.

La date de livraison n'est pas la date de facturation

De nombreuses factures comportent deux dates distinctes : la date à laquelle la facture a été émise et celle à laquelle la livraison ou la prestation a réellement eu lieu. Un exemple :

Si l'on renseigne par erreur la date de facturation à la place de la date de livraison, la facture électronique est certes formellement valide, mais matériellement inexacte – avec des conséquences pour la comptabilisation, le moment de la prestation et la TVA.

Ce qu'exige la norme EN 16931

La norme EN 16931 désigne la date de livraison réelle par BT-72. Dans les deux syntaxes, cela se présente ainsi :

• ZUGFeRD / CII : ram:ApplicableHeaderTradeDelivery → ram:ActualDeliverySupplyChainEvent → ram:OccurrenceDateTime
• XRechnung / UBL : cac:Delivery → cbc:ActualDeliveryDate

Le format est une date calendaire (dans CII, sous la forme AAAAMMJJ, code de format 102). Elle décrit le moment de la livraison, indépendamment de la date de facturation ou d'échéance.

L'erreur typique des convertisseurs automatiques

Un simple convertisseur PDF vers XML ne lit souvent que les données d'en-tête évidentes et remplit les champs manquants avec des valeurs par défaut. Faute d'une détection dédiée de la date de livraison, il y inscrit à la place la date de facturation. Tant que les deux dates sont identiques, cela passe inaperçu ; dès qu'elles diffèrent, la facture électronique contient un ActualDeliveryDate erroné.

Comment TaxLayer résout ce problème

TaxLayer détecte la date de livraison/prestation de façon autonome et distincte de la date de facturation. Dans l'étape de vérification qui précède la génération, elle apparaît dans un champ dédié Date de livraison et peut y être corrigée avant la création du fichier ZUGFeRD ou XRechnung. Le XML généré contient alors la date correcte comme ActualDeliveryDate.

La responsabilité de l'exactitude matérielle reste ainsi entre vos mains – et une erreur automatique ne peut tout simplement pas passer inaperçue.

Conclusion

La date de livraison est un champ obligatoire ou d'usage courant de la norme EN 16931 (BT-72) et ne doit pas être assimilée aveuglément à la date de facturation. Veillez, à chaque conversion, à ce que l'ActualDeliveryDate reflète la date de livraison réelle.

---

Essayez TaxLayer gratuitement dès maintenant – détecte automatiquement la date de livraison, les numéros d'article et les références, et vous permet de les vérifier avant la génération. Questions à info@landauer.de.