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.
| Format | Type de destinataire | Description |
|---|---|---|
| ZUGFeRD (Extended) | Secteur privé B2B | Format hybride composé d'un PDF/A-3 et d'un XML structuré |
| XRechnung | Acheteurs 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 |
| Verifactu | Administrations et entreprises espagnoles | Facture électronique espagnole, format XML |
| Factur-X | Entreprises françaises | Format hybride français similaire à ZUGFeRD |
| FatturaPA | Administrations italiennes et B2B | Format national italien de facture électronique |
| KSeF (FA(3)) | Administrations polonaises et B2B | Format polonais de facture électronique |
| PDF simple | Tous 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 :
- Les informations structurelles manquent : un PDF ne contient qu'une représentation visuelle, sans données structurées.
- 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.
- 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 :
- Créer une facture dans l'interface web, l'enregistrer comme brouillon, puis la montrer à un client.
- Créer la facture avec les données du client dans le compte de test du client (avec sa clé API).
- 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:xrechnungoffre 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 ?