Un logiciel de facturation électronique pour une entreprise européenne doit bien faire sept choses : générer le bon format structuré pour chaque pays, le valider avant l'émission de la facture, l'acheminer par le canal qu'utilise ce pays, lire les factures structurées entrantes, conserver l'original structuré pendant la durée de conservation, décider du traitement TVA à partir des faits de la transaction, et exposer tout cela à d'autres systèmes via une API. Aucun produit ne fait les sept dans chaque pays sans limitations ; la question utile est de savoir lesquelles, et si l'éditeur les nomme.
Génération des formats : une facture, quatre dialectes nationaux
Le logiciel doit produire le format exact attendu par chaque obligation — XRechnung ou ZUGFeRD pour l'Allemagne, Factur-X pour la France, Peppol BIS Billing 3.0 pour la Belgique, FA(3) pour la Pologne — à partir des mêmes données de facture, sans que l'utilisateur ne modifie de XML.
Trois des quatre sont des profils de l'EN 16931, la norme sémantique européenne dont la Commission met les parties 1 et 2 à disposition gratuitement par l'intermédiaire des organismes nationaux de normalisation ; le quatrième, le FA(3) polonais, est un schéma national à part entière. « Prend en charge l'EN 16931 » est donc nécessaire mais pas suffisant. Demandez précisément :
- Quelles syntaxes pour l'Allemagne — XRechnung en UBL, en CII, ou les deux ? ZUGFeRD dans quels profils (la FAQ du BMF exclut MINIMUM et BASIC-WL de la définition de la facture électronique) ?
- La sortie française intègre-t-elle le XML CII dans un PDF/A-3 (Factur-X) de sorte que le même fichier serve aux humains et aux machines ?
- La sortie belge est-elle l'UBL Peppol BIS Billing 3.0 que le réseau valide, ou un UBL générique qu'un point d'accès destinataire peut rejeter ?
- Quelle version FA pour la Pologne — FA(3) est le schéma en vigueur — et le logiciel peut-il aussi produire la visualisation avec le numéro KSeF et le code QR que le ministère exige lorsqu'une facture est utilisée hors du système ?
- Le format est-il choisi automatiquement d'après le pays de la société émettrice, ou l'utilisateur doit-il le sélectionner ?
Le guide des formats associe chaque format à son pays et à son obligation.
Validation avant l'émission, pas après un rejet
Une facture structurée qui échoue aux règles métier nationales n'est pas une facture électronique au sens de cette obligation ; le logiciel doit exécuter ces règles avant l'attribution du numéro, et non apprendre l'échec par une transmission rejetée.
La validation comporte plusieurs couches : schéma XML, règles Schematron EN 16931, règles CIUS nationales (celles de la KoSIT pour XRechnung, les règles Peppol BIS pour la Belgique, le schéma FA(3) pour la Pologne), et des recoupements tels que l'arithmétique des totaux et de la ventilation TVA. Demandez quelles couches s'exécutent, si les jeux de règles sont dans leurs versions actuelles (l'édition 2026 de la norme déclenche une migration, et la KoSIT et OpenPeppol publient leurs versions selon leurs propres calendriers), et si une validation en échec bloque l'émission ou se contente d'avertir. Un vérificateur en ligne gratuit qui valide un fichier par rapport aux règles d'un pays est un moyen loyal de tester les affirmations d'un éditeur — voir le vérificateur de factures électroniques.
Transport : la partie qui diffère le plus selon le pays
L'Allemagne ne prescrit aucun canal, la Belgique prescrit Peppol, la France prescrit des plateformes immatriculées, la Pologne prescrit son système d'État ; un logiciel qui couvre les quatre intègre chaque canal ou nomme celui qu'il délègue à un prestataire.
| Pays | Canal requis | Que demander à l'éditeur |
|---|---|---|
| Allemagne | Aucun — la FAQ du BMF accepte l'e-mail, les interfaces, les portails, les supports physiques | Le fichier structuré peut-il être joint à l'e-mail de facture ou téléchargé ? Peut-il facultativement passer par Peppol vers un destinataire enregistré, et avec une Leitweg-ID vers un acheteur public ? |
| Belgique | Peppol, par défaut | Quel point d'accès accrédité achemine le trafic ? L'éditeur est-il lui-même un point d'accès ou se connecte-t-il par l'intermédiaire de l'un d'eux ? Comment l'identifiant Peppol de la société est-il enregistré et quels types de documents sont publiés pour elle ? |
| France | Une plateforme agréée de chaque côté | L'éditeur est-il immatriculé comme PA par la DGFiP, ou transmet-il par une PA immatriculée ? La DGFiP indique qu'une solution non immatriculée « ne sera donc pas autorisée à transmettre les factures électroniques aux plateformes des clients ». La connexion est-elle prête pour la production aujourd'hui ? |
| Pologne | KSeF | L'intégration a-t-elle été utilisée contre le KSeF de production, ou seulement contre l'environnement de test ? Gère-t-elle l'authentification, les sessions, l'accusé de réception UPO, les modes hors ligne et la visualisation QR ? |
Soyez précis sur les mots. « Peppol-ready » peut désigner un point d'accès accrédité, une connexion par l'intermédiaire de l'un d'eux, ou simplement la capacité d'exporter un fichier BIS. « KSeF-ready » peut désigner une utilisation en production ou un module testé uniquement contre le bac à sable. L'éditeur doit dire lequel ; la comparaison des réseaux explique pourquoi la distinction compte.
Réception : transformer le XML entrant en factures fournisseurs
Chaque obligation commence par la réception ; le logiciel doit donc lire les fichiers XRechnung, ZUGFeRD/Factur-X et UBL — depuis un e-mail, un téléversement ou un réseau — pour en faire un enregistrement d'achat sans ressaisie.
Demandez ce qu'il advient d'un PDF hybride : le XML intégré est-il extrait et utilisé, ou le PDF est-il traité comme une image ? Demandez si le fournisseur, les montants, la ventilation TVA, l'échéance et la référence de paiement sont reportés dans la facture fournisseur, et si un fichier qui échoue à la validation est refusé ou signalé. Demandez comment les documents Peppol entrants parviennent à la boîte de réception une fois l'identifiant de la société enregistré. Pour l'Allemagne, voir recevoir des factures électroniques.
Archivage : le fichier structuré est l'original
Lorsque la facture est un fichier structuré, c'est ce fichier — et non un rendu PDF de celui-ci — qui doit être conservé pendant la durée de conservation nationale, inchangé et récupérable.
L'autorité belge note que « les règles d'archivage restent inchangées » par l'obligation, ce qui est vrai partout : les durées de conservation et les exigences d'intégrité sont nationales et antérieures à la facturation électronique. Ce qui change, c'est l'objet. Demandez si le logiciel stocke le XML émis (et le XML reçu) tel qu'envoyé, s'il peut exporter les archives en masse, et si une facture reste récupérable après la fin d'un abonnement. Les durées de conservation et toute exigence nationale d'immuabilité ou de piste d'audit requièrent une confirmation professionnelle.
Verdicts fiscaux : décidés à partir des faits, non saisis
La ligne de TVA d'une facture découle du pays du vendeur, du pays de l'acheteur, du statut d'entreprise de l'acheteur et de la nature de l'opération ; le logiciel doit la dériver de ces faits et refuser de deviner lorsque les faits sont insuffisants.
Cela compte plus en Europe que partout ailleurs, parce que les formats structurés portent explicitement les codes de catégorie de TVA et les motifs d'exonération, et que les validateurs les vérifient par rapport aux montants. Demandez si le logiciel distingue les résultats taux normal, taux zéro, exonération, autoliquidation et hors champ, s'il vérifie le numéro de TVA de l'acheteur dans VIES à l'émission, s'il stocke la décision avec la facture pour un audit ultérieur, et — point important — s'il dispose d'un état honnête « saisie requise » au lieu d'un taux par défaut. Voir facturation électronique transfrontalière pour les règles derrière les verdicts et le vérificateur de numéro de TVA gratuit.
API : la facture est généralement créée ailleurs
Pour un SaaS, une place de marché ou une entreprise pilotée par un ERP, la facture naît dans un autre système ; le logiciel de facturation électronique a besoin d'une API documentée avec authentification, création idempotente, webhooks et mode test.
Demandez si l'API crée des brouillons qui sont ensuite émis sous la validation du produit, ou si elle émet directement des factures légales (ce qui contourne les contrôles ci-dessus) ; si les clés peuvent être limitées à une seule société et à la lecture ou à l'écriture ; si les requêtes POST acceptent une clé d'idempotence afin qu'un appel réessayé ne puisse pas créer deux factures ; quels événements sont poussés par webhook et comment ils sont signés ; et quelle est la limite de débit. Les développeurs voudront lire la référence avant d'acheter — voir l'API de facturation électronique et la référence de l'API.
La liste de contrôle
Douze questions qui séparent la couverture des affirmations ; un éditeur qui répond à chacune par un simple oui, non ou « via le prestataire X » vous dit ce que vous devez savoir.
- Quels formats nationaux sont générés automatiquement d'après le pays de la société, et dans quelles syntaxes et quels profils ?
- Quels jeux de règles de validation s'exécutent avant l'émission, et dans quelles versions ?
- Une validation en échec bloque-t-elle l'émission ?
- Pour la Belgique : quel point d'accès accrédité achemine le trafic, et l'éditeur en est-il un lui-même ?
- Pour la France : l'éditeur est-il une plateforme agréée, ou par quelle PA transmet-il, et est-ce en production ?
- Pour la Pologne : l'intégration KSeF a-t-elle été utilisée en production ?
- Les fichiers XRechnung, ZUGFeRD/Factur-X et UBL entrants sont-ils lus en factures fournisseurs avec le XML intégré ?
- L'original structuré est-il stocké tel qu'émis et exportable en masse ?
- Le traitement TVA est-il dérivé des faits de la transaction, avec une vérification VIES et un verdict stocké ?
- L'API crée-t-elle des brouillons sous validation, avec des clés à portée limitée, l'idempotence et des webhooks signés ?
- Existe-t-il un mode test qui se comporte comme la production ?
- Lesquels des points ci-dessus sont décrits par l'éditeur comme des limitations, et ces limitations sont-elles datées ?
Comment KRONENWERK gère cela
KRONENWERK couvre intégralement les formats, la validation, la réception, les verdicts fiscaux et l'API ; c'est dans le transport que se situent les limitations, et elles sont nommées ci-dessous.
| Point de contrôle | KRONENWERK | Statut |
|---|---|---|
| Génération des formats | XRechnung et ZUGFeRD (Allemagne), Factur-X PDF/A-3 avec CII intégré (France), UBL Peppol BIS Billing 3.0 (Belgique), XML FA(3) (Pologne), choisis d'après le pays de la société émettrice. Factures PDF avec règles fiscales nationales pour le Canada et les États-Unis. | PRIS EN CHARGE (FA(3) : PRIS EN CHARGE AVEC LIMITATIONS) |
| Validation avant l'émission | Formats allemands validés avec les règles Schematron de la KoSIT et recoupés avec la bibliothèque Mustang ; chaque facture structurée validée à l'émission. | PRIS EN CHARGE |
| Transport — Peppol | KRONENWERK envoie et reçoit via Peppol par l'intermédiaire d'un fournisseur de point d'accès accrédité (Storecove) une fois la société connectée dans Paramètres → Envoi. KRONENWERK n'est pas lui-même un point d'accès Peppol. | PRIS EN CHARGE AVEC LIMITATIONS |
| Transport — France | KRONENWERK n'est pas une plateforme agréée. La transmission est prévue via la capacité de plateforme agréée de Storecove et n'est pas prête pour la production. | PAS ENCORE PRÊT |
| Transport — Pologne | Module KSeF 2.0 (authentification par jeton, session, soumission FA(3), récupération de l'UPO, réception) développé et dépendant de l'environnement ; non utilisé contre le KSeF de production. Aucun abonnement n'est vendu aux sociétés polonaises tant que cela n'est pas prouvé. | PAS ENCORE PRÊT |
| Transport — Allemagne | Fichier structuré remis avec la facture par e-mail ou téléchargement ; facultativement via Peppol comme ci-dessus. | PRIS EN CHARGE |
| Réception | Fichiers XRechnung, ZUGFeRD/Factur-X et UBL entrants lus en factures fournisseurs ; le vérificateur gratuit valide un fichier sans le stocker. | PRIS EN CHARGE |
| Archivage | Le fichier structuré est généré à l'émission comme partie intégrante de la facture et les fichiers entrants sont lus en factures fournisseurs. Les durées de conservation, l'export et toute exigence d'immuabilité dans votre juridiction sont à confirmer par votre conseiller. | CONFIRMATION PROFESSIONNELLE REQUISE |
| Verdict fiscal | Par facture, à partir du pays du vendeur, du pays de l'acheteur, entreprise ou consommateur et nature de l'opération : taux normal, taux zéro, exonération, autoliquidation, hors champ, ou « saisie requise » / « confirmation professionnelle requise » ; numéro de TVA de l'acheteur vérifié dans VIES à l'émission ; verdict stocké avec la facture. | PRIS EN CHARGE |
| API | API publique à l'adresse https://kronenwerk.org/api/extern/v1 avec clés Bearer (greif_live_… / greif_test_…), limitées par société ; POST /invoices/drafts crée des brouillons émis dans le produit après validation ; Idempotency-Key sur les POST ; webhooks signés (invoice.issued, invoice.paid, invoice.cancelled, purchase.recorded, payment.recorded) ; serveur MCP à /api/extern/mcp ; limite de débit de 240 requêtes par clé se rechargeant en continu. Sur le plan Enterprise. | PRIS EN CHARGE |
| Mode test | Une clé greif_test_ fonctionne contre la même API en mode test pour la société qui l'a créée ; pas d'hôte bac à sable distinct. | PRIS EN CHARGE |
KRONENWERK ne déclare ni ne reverse aucun impôt, ne fournit pas de conseil fiscal ou juridique et ne détient aucune certification de sécurité ; il ne donne aucune garantie quant aux résultats de conformité. Au-delà de la facturation électronique, c'est un produit de comptabilité — grand livre en partie double, factures fournisseurs et dépenses, connexions bancaires via Enable Banking et Plaid, multisociété et multidevise, cinq langues d'interface. Voir la facturation électronique dans KRONENWERK, facturation, plans et, pour les développeurs, la vue d'ensemble développeurs. Retour au hub Europe.
Questions fréquentes
« Conforme à l'EN 16931 » signifie-t-il que le logiciel fonctionne dans tous les pays de l'UE ?
Non. L'EN 16931 fixe le modèle de contenu ; chaque pays ajoute son propre profil, son canal et ses dates, et la Pologne utilise un schéma hors EN. Demandez pays par pays.
Le logiciel doit-il être un point d'accès Peppol ?
Non. La plupart des produits se connectent par l'intermédiaire d'un point d'accès accrédité ; ce qui compte, c'est que l'éditeur dise lequel et que la connexion soit active pour votre société.
Puis-je utiliser un outil non immatriculé pour la facturation électronique française ?
Vous pouvez y préparer des factures, mais la DGFiP indique que seule une plateforme agréée immatriculée peut les transmettre aux plateformes de vos clients et envoyer des données à l'administration.
L'API doit-elle émettre directement des factures ?
De préférence non. Créer des brouillons via l'API et les émettre sous la validation du produit maintient les contrôles de format et de fiscalité dans le parcours ; l'API de KRONENWERK fonctionne ainsi.
Une copie PDF suffit-elle pour les archives ?
Lorsque la facture est un fichier structuré, ce fichier est la facture ; conservez-le tel qu'émis. Les règles nationales de conservation requièrent une confirmation professionnelle.
Sources
- European Commission — Obtaining a copy of the European standard on eInvoicing — consulté le
- OpenPeppol — Peppol Interoperability Framework — consulté le
- DGFiP — Facturation électronique et plateformes agréées — consulté le
- Bundesfinanzministerium — Fragen und Antworten zur Einführung der obligatorischen E-Rechnung — consulté le
- FPS BOSA / efactuur.belgium.be — Structured electronic invoices between companies are compulsory since 2026 — consulté le
- Ministerstwo Finansów — Tryb offline i kody QR — consulté le
- KRONENWERK developer documentation — consulté le