Aller au contenu

Formats de facture et conversion : formats, profils et transformation

Repères sur les formats de facture électronique, les profils et versions pris en charge, et le fonctionnement des conversions entre formats.

Vue d'ensemble des formats pris en charge

faktoora prend en charge un large éventail de formats de facture électronique. Le choix du bon format dépend du type de destinataire de la facture et des exigences légales ou contractuelles.

FormatType de destinataireDescription
ZUGFeRD (Extended)Secteur privé B2BFormat hybride composé d'un PDF/A-3 et d'un XML structuré
XRechnungAcheteurs publics (État fédéral/Länder)XML purement structuré basé sur la norme EN 16931
Peppol (UBL)Entreprises européennes (B2B)Conforme à la norme EN 16931 pour le réseau Peppol, utilisable à l'international
VerifactuAdministrations et entreprises espagnolesFacture électronique espagnole, format XML
Factur-XEntreprises françaisesFormat hybride français similaire à ZUGFeRD
FatturaPAAdministrations italiennes et B2BFormat national italien de facture électronique
KSeF (FA(3))Administrations polonaises et B2BFormat polonais de facture électronique
PDF simpleTous les destinataires (solution de repli)PDF visuel sans données structurées

ZUGFeRD : profils et versions

faktoora crée les factures ZUGFeRD avec le profil Extended, qui offre les fonctionnalités les plus étendues. Il existe deux versions :

  • ZUGFeRD 1.0 (zf:1:extended) : la version d'origine, basée sur la norme CII. Elle reste prise en charge.
  • ZUGFeRD 2.1 (zf:2:extended) : la version actuelle conforme à la norme EN 16931, recommandée pour les nouvelles factures.

Le profil Extended est le profil le plus complet et satisfait à la norme EN 16931. Le message « Vous ne pouvez télécharger qu'au format PDF et XRechnung » signifie que le profil sélectionné ne propose que ces deux formats au téléchargement ; c'est le comportement prévu pour certaines configurations et certains types de facture.

XRechnung et CII/UBL

La XRechnung est la facture électronique standard allemande pour les acheteurs publics. faktoora la génère automatiquement dans la version en vigueur. La version actuellement obligatoire est fixée par l'organisme allemand de coordination des normes informatiques (KoSIT) ; la vue d'ensemble officielle est publiée sur xeinkauf.de.

Sur le plan technique, la XRechnung repose sur CII (Cross Industry Invoice), et non sur UBL (Universal Business Language). CII est le format XML privilégié par l'Allemagne et l'Autriche, tandis qu'UBL domine surtout dans le réseau Peppol (Europe du Nord, Pays-Bas).

Les deux schémas diffèrent par leur structure :

  • CII : structure stricte et hiérarchique ; utilisée par l'Allemagne, l'Autriche et la spécification EN 16931 pour XRechnung.
  • UBL : structure plus modulaire et plus ouverte ; standard du réseau Peppol.

ZUGFeRD utilise toujours CII ; c'est pourquoi l'option de schéma est réglée sur CII lors de la création d'une facture ZUGFeRD (elle ne peut pas être choisie).

Peppol (UBL) pour les factures B2B internationales

Peppol (Pan-European Public Procurement Online) est un réseau européen de factures structurées. faktoora crée les factures Peppol sous forme de factures EN 16931 basées sur UBL et peut, lorsque la livraison Peppol est activée, les envoyer automatiquement via le réseau Peppol. C'est la solution idéale pour les factures B2B destinées à des entreprises européennes disposant d'un point d'accès Peppol.

Le PDF et la conversion de formats

Du PDF au format électronique : ce qui est possible et ce qui ne l'est pas

Les factures PDF ne peuvent pas être converties automatiquement en format électronique (XRechnung, ZUGFeRD, etc.). En effet :

  1. Les informations structurelles manquent : un PDF ne contient qu'une représentation visuelle, sans données structurées.
  2. L'OCR n'est pas fiable : faktoora utilise l'OCR pour extraire le texte des factures numérisées (factures entrantes), mais l'OCR ne peut pas garantir une reconnaissance des champs fiable à 100 %. La reconnaissance sert donc d'outil d'aide et non d'automatisation complète.
  3. Perte de données : des informations complexes comme les catégories de taxe, les remises au niveau des lignes ou les conditions de paiement ne peuvent pas être reconstituées automatiquement à partir d'un PDF.

Exception : si le PDF est au format XRechnung ou ZUGFeRD (c'est-à-dire un PDF/A-3 avec XML intégré), faktoora peut extraire le XML et le convertir dans d'autres formats.

D'Excel/CSV au format électronique

faktoora ne propose pas d'import automatisé direct depuis Excel ou CSV pour créer des factures électroniques via l'interface web. L'API permet de transmettre des données structurées, mais il est nécessaire de structurer les données manuellement ou d'écrire un script d'intégration.

Solution de contournement : vous pouvez importer les données client et les produits via CSV (voir Importer des contacts, Importer des produits), puis créer les factures manuellement ou via l'API.

De Word au format électronique

Un fichier Word (DOCX) ne peut pas être converti automatiquement en XRechnung ou dans un autre format de facture électronique. Les mêmes restrictions que pour le PDF s'appliquent : le format ne contient que des informations visuelles et formelles, et non les données structurées dont un format de facture électronique a besoin.

Procédure : créez la facture directement dans faktoora ou importez manuellement les données pertinentes (client, lignes, taxes).

Factures étrangères et numéros fiscaux

Numéros fiscaux et IBAN étrangers

faktoora prend en charge les factures qui n'émanent pas d'une entreprise allemande. Vous pouvez saisir dans les paramètres de votre profil un numéro fiscal étranger (par ex. UID autrichien, NIF espagnol) et un IBAN étranger, mais cette configuration doit passer par une demande de contact ou un accès administrateur, car l'interface web est préconfigurée pour des saisies allemandes.

Formats pour l'étranger

  • International : Peppol (UBL) est le standard pour les factures électroniques B2B à l'échelle européenne.
  • Espagne : format Verifactu pour les administrations et le B2B.
  • France : Factur-X pour les entreprises ; France-PA pour les acheteurs publics (via une Plateforme Agréée).
  • Italie : FatturaPA pour les administrations et l'envoi B2B via le réseau SdI.
  • Pologne : KSeF (FA(3)) pour les administrations et le B2B.

Limites des factures électroniques

Montants négatifs au niveau des lignes

Dans les formats de facture électronique (XRechnung, ZUGFeRD, Peppol), aucun montant négatif ne peut être saisi au niveau des lignes. Il s'agit d'une exigence de la norme EN 16931.

Raison : la norme EN 16931 prévoit que les corrections s'effectuent par des avoirs distincts (code de type de facture 381) ou des factures rectificatives (code 384), et non par des lignes négatives dans une facture normale.

Solution : créez plutôt un avoir (type 381) ou une facture rectificative (384) sous forme de facture distincte.

Date de livraison avec ZUGFeRD 2.x

La date de livraison (BT-72 dans la norme EN 16931) est enregistrée dans les données XML avec ZUGFeRD 2.x, mais n'est pas visible par défaut dans la présentation PDF. Vous pouvez l'activer dans l'interface de facturation pour qu'elle s'affiche dans la mise en page PDF.

Date de prestation sans date propre à chaque ligne

Pour certaines lignes de facture (par ex. des prestations de services sans date de livraison distincte), il est possible de définir en plus une date de livraison au niveau du produit ; c'est facultatif. Si vous ne définissez ni date de prestation ni période de prestation propre pour la facture, la règle suivante s'applique automatiquement : la date de prestation correspond à la date de facture. Cette valeur par défaut figure telle quelle sur la facture et ne nécessite aucune saisie supplémentaire.

Validation et gestion des erreurs

Erreurs de validation lors de l'export ou du téléchargement

Si l'export d'une facture au format PDF ou CSV échoue avec une erreur de validation, les causes fréquentes sont :

  • Non-respect d'un champ BT : un champ obligatoire selon la norme EN 16931 n'est pas renseigné ou a un format invalide.
  • Incohérence fiscale : taux de TVA négatifs, catégories de taxe non prises en charge ou combinaisons de catégories invalides.
  • Format de champ : une date n'est pas au format attendu, un numéro de téléphone contient des caractères invalides, etc.

Procédure : lisez attentivement le message d'erreur ; il indique généralement le champ BT concerné ou la règle de validation. Ajustez les données et réessayez.

Erreurs de génération PDF avec ZUGFeRD

Si une facture ZUGFeRD téléchargée au format PDF échoue ou ne s'affiche pas à l'ouverture, les causes peuvent être :

  • Conformité PDF/A-3 : le PDF n'est pas conforme PDF/A-3, ce qui pose problème dans certains lecteurs. Essayez de l'ouvrir avec Acrobat Reader ou un autre lecteur PDF.
  • Problème d'intégration : le XML intégré est endommagé. C'est rare et détecté par la validation.

Solution : utilisez la fonction de validation (validate: true lors de la création via l'API) pour détecter les erreurs avant le téléchargement.

Interlocuteur dans les factures ZUGFeRD

Si vous définissez un interlocuteur dans le XML (par ex. via l'API), celui-ci n'est pas affiché automatiquement dans la mise en page PDF. Le PDF affiche généralement un contact standard ou l'entreprise elle-même. L'interlocuteur figure néanmoins dans les données structurées (XML) et est pris en compte par les systèmes qui lisent le XML.

Génération automatique de PDF dans les intégrations API

Si une facture est créée via une intégration API externe (par ex. par un worker ou un traitement par lots), la présentation PDF est parfois générée avec une mise en page standard au lieu de votre modèle de facture personnalisé. C'est le cas lorsque :

  • L'appel API ne transmet pas d'ID de modèle.
  • Le système utilise un modèle de repli (par ex. pour les factures générées par le système).

Solution : assurez-vous que votre payload API contient le bon ID de modèle ou les bonnes références de configuration.

Champ BT-18 : référence de document

Le champ BT-18 (référence à un document commercial) est renseigné dans faktoora via le champ buyerReference ou des contextes similaires. Dans l'API, vous pouvez utiliser invoiceReferencedDocument.IssuerAssignedID pour définir une référence à une autre facture (par ex. pour des corrections). La correspondance précise du champ BT-18 dépend du type de facture et du contexte.

Fonctions de test

Pour tester des factures ZUGFeRD, vous pouvez :

  1. Créer une facture dans l'interface web, l'enregistrer comme brouillon, puis la montrer à un client.
  2. Créer la facture avec les données du client dans le compte de test du client (avec sa clé API).
  3. Créer une facture de test via l'API avec draftOnly: true.

Toutes ces options permettent de montrer un exemple fonctionnel sans l'envoyer en production.

Combiner ZUGFeRD et XRechnung

Une facture créée au format ZUGFeRD 2.1 (Extended) ne peut pas être téléchargée automatiquement au format XRechnung. En effet, ZUGFeRD 2.1 est construit avec le schéma CII (PDF + XML CII), tandis que la XRechnung, bien qu'utilisant également CII, a ses propres règles de validation et un autre format de sortie.

Bonne procédure :

  • Pour les clients privés : créer une facture ZUGFeRD 2.1 (Extended).
  • Pour les acheteurs publics : sélectionner explicitement XRechnung.
  • ZUGFeRD avec le profil zf:2:xrechnung offre un profil hybride entre ZUGFeRD et XRechnung, mais ne permet pas de choix libre a posteriori.

Si vous souhaitez créer une véritable XRechnung, choisissez format : xrechnung lors de la création. Si vous souhaitez un hybride ZUGFeRD compatible XRechnung, utilisez zf:2:xrechnung. Une conversion entre les deux n'est pas possible a posteriori : le format est fixé lors de la création.

Cela vous a-t-il été utile ?

Des questions ?

N’hésitez pas à nous contacter ! Notre équipe est toujours à votre disposition pour répondre à vos questions et vous accompagner.

Contactez-nous par e-mail à :

info@faktoora.com

Ou appelez-nous :

+49 731 85070390

Au plaisir de vous lire !