Aperçu des InvoiceTypeCodes en e-facturation : quel code utiliser et quelles normes les prennent en charge ?
L'InvoiceTypeCode est un code à trois chiffres dans l'élément XML cbc:InvoiceTypeCode qui détermine le type de facture que vous envoyez. Le bon code permet au destinataire de savoir immédiatement s'il s'agit d'une facture ordinaire, d'un avoir, d'une correction ou d'une facture d'autofacturation.
Les codes autorisés proviennent de deux sous-ensembles de la liste de codes UNCL1001 : la liste des factures (UNCL1001-inv) pour les factures et la liste des avoirs (UNCL1001-cn) pour les notes de crédit. Tous les codes ne sont pas disponibles dans chaque norme.
(*) Le code 389 n'est pas autorisé dans la norme standard Peppol BIS Billing V3, mais il l'est dans le profil Peppol BIS Self-Billing 3.0 (un profil distinct avec son propre CustomizationID et ProfileID). Dans NLCIUS, le code 389 est autorisé comme InvoiceTypeCode standard sans profil séparé.
Le code standard pour les factures de vente ordinaires. C'est de loin l'InvoiceTypeCode le plus utilisé. Pratiquement chaque facture B2B ou B2G envoyée via Peppol utilise le code 380. Ce code est disponible dans toutes les normes courantes : Peppol BIS V3, NLCIUS et XRechnung.
Aux Pays-Bas, le code 380 est également utilisé comme alternative à un avoir. Dans ce cas de « facture négative », les montants et quantités sont remplis en négatif, de sorte que la facture fonctionne comme un avoir. C'est la convention décrite dans le test de chaîne UBL du bureau de recherche GBNED. La différence avec un véritable avoir (381) : avec le code 380, les montants sont négatifs, avec le code 381, ils sont positifs (le schéma CreditNote indique implicitement qu'il s'agit d'une correction). Consultez Variantes d'avoir pour une comparaison détaillée.
Un avoir corrige ou annule (une partie de) une facture antérieure. L'avoir fait référence à la facture d'origine via un BillingReference. Les avoirs utilisent une syntaxe XML distincte (CreditNote au lieu de Invoice) et un DocumentTypeId séparé sur le réseau Peppol.
Le code 381 est pris en charge dans Peppol BIS V3, NLCIUS et XRechnung.
Une note de débit est utilisée lorsqu'un montant supplémentaire doit être facturé après la facture d'origine, par exemple pour des services supplémentaires, des corrections de prix ou des ajustements contractuels. Contrairement à une facture corrective (384), une note de débit ne contient que des montants positifs.
Ce code est disponible dans Peppol BIS V3 et NLCIUS, mais pas dans XRechnung.
Une facture corrective remplace ou corrige une facture antérieure et peut contenir des montants positifs et négatifs. NLCIUS privilégie les factures correctives par rapport aux avoirs, car le mécanisme de correction rend clairement visible dans un seul document ce qui a été modifié.
Le code 384 est disponible dans NLCIUS et XRechnung, mais pas dans la norme standard Peppol BIS Billing V3.
Attention (PEPPOL-EN16931-P0112) : dans Peppol BIS Billing 3.0, les codes de type 326 et 384 ne sont autorisés que lorsque le fournisseur et le destinataire sont tous deux des organisations allemandes. Si vous utilisez BIS Billing V3 en dehors d'un scénario DE→DE, choisissez plutôt le code de type 380 (éventuellement avec des montants négatifs) au lieu de 384. Voir Erreurs d'envoi pour l'explication complète et la solution.
Une facture d'acompte (prepayment invoice) est utilisée pour les paiements partiels préalables à la livraison complète de biens ou de services. Ce code est disponible dans Peppol BIS V3 et NLCIUS, mais pas dans XRechnung.
L'autofacturation (self-billing) est le processus par lequel l'acheteur établit la facture au nom du fournisseur. Cela se produit dans le cas de travailleurs intérimaires, de facturation interentreprises et de certains contrats d'achat. Il existe deux codes pour l'autofacturation :
Au sein de l'écosystème Peppol, il existe deux façons d'implémenter l'autofacturation. Le choix dépend du profil que vous utilisez.
...selfbilling:3.0)...selfbilling:01:1.0)Avec Peppol BIS Self-Billing 3.0, l'autofacturation est un profil séparé avec son propre CustomizationID et ProfileID. Le fournisseur doit être spécifiquement enregistré dans le SMP pour pouvoir recevoir des documents d'autofacturation.
Avec NLCIUS/SI-UBL 2.0, l'approche est plus simple : vous modifiez uniquement l'InvoiceTypeCode en 389. Le CustomizationID et le ProfileID restent inchangés, et le PSB reconnaît automatiquement le type de document. Si le fournisseur est déjà enregistré pour les factures SI-UBL ordinaires, aucun enregistrement SMP supplémentaire n'est nécessaire.
Pour la plupart des situations, le code 380 (facture ordinaire) ou 381 (avoir) suffit. Ce sont les codes pris en charge par toutes les normes et tous les destinataires. Choisissez un autre code uniquement si votre cas d'utilisation spécifique l'exige :
Consultez également l'aperçu des Party Identifiers et codes EAS