Logiciel de facturation électronique pour développeurs : XRechnung, Factur-X

Générer un fichier XML EN 16931 valide est la petite partie de la facturation électronique, et une bonne bibliothèque le fera pour vous en une semaine. La grande partie, c'est tout ce qui entoure le fichier : suivre des jeux de règles nationaux qui changent sans cesse, valider contre le Schematron du pays de l'acheteur, choisir le bon profil et la bonne syntaxe par acheteur, transporter le document via Peppol, une plateforme agréée ou KSeF, conserver la facture telle qu'émise pendant la durée de conservation, et faire de même en sens inverse pour ce que vos fournisseurs vous envoient. Développez lorsque la facturation électronique est votre produit ; achetez — ou intégrez par une API — lorsqu'elle est votre obligation.

Ce que la norme vous demande réellement

EN 16931 définit un modèle sémantique de facture et deux syntaxes XML qui le portent ; chaque format national d'Europe occidentale et centrale est soit un profil restreint de ce modèle, soit, dans le cas de la Pologne, un schéma distinct. Pour l'implémenter, il vous faut le modèle, la liaison syntaxique et les règles nationales par-dessus.

La page de la Commission sur l'obtention de la norme en énumère les parties : « le modèle sémantique de données (EN 16931-1 : 2017) » et « les deux syntaxes obligatoires conformes à la norme (CEN/TS 16931-2 : 2017) » sont disponibles gratuitement auprès des organismes nationaux de normalisation, tandis que « les copies des autres parties (3-6) de la norme, constituées des liaisons syntaxiques, lignes directrices et méthodologies, sont vendues ». Les deux syntaxes sont UBL 2.1 (partie 3-2) et UN/CEFACT CII D16B (partie 3-3). Par-dessus :

• Allemagne — XRechnung, la spécification nationale de la KoSIT, avec son propre Schematron et ses restrictions de listes de codes ; et ZUGFeRD, le PDF/A-3 hybride avec CII intégré. À partir de 2027, les entreprises au-dessus de 800 000 EUR de chiffre d'affaires « ne seront plus autorisées à émettre des factures papier ni à utiliser des formats électroniques non structurés » ; toutes les entreprises à partir de 2028.
• France — Factur-X, « une norme franco-allemande de facture électronique hybride (PDF pour les utilisateurs et données XML pour le traitement automatisé) », techniquement « la même norme que ZUGFeRD 2.5 », plus UBL et CII, échangés via des plateformes agréées que le ministère qualifie d'« intermédiaire obligatoire entre les entreprises ».
• Belgique — Peppol BIS Billing 3.0, une CIUS de EN 16931 en UBL 2.1 ; « tout document conforme à cette spécification sera conforme à la norme européenne (EN 16931) ».
• Pologne — FA(3), un schéma XML national soumis à KSeF, « obligatoire pour tous les entrepreneurs » à partir du 1er avril 2026, sauf les plus petits, qui suivent le 1er janvier 2027.

Les formats sont comparés en détail sur la page des formats ; le modèle lui-même sur EN 16931.

Ce qu'une bibliothèque vous donne, et ce qu'elle ne donne pas

Une bibliothèque transforme votre objet facture en XML (ou en PDF hybride) et, pour les meilleures, exécute le Schematron. Elle ne connaît ni le pays de votre acheteur, ni votre verdict TVA, ni votre séquence de numérotation, ni la durée de conservation, et elle ne livre rien nulle part.

Une décision de développer est en réalité une décision de prendre en charge les lignes du milieu de ce tableau. Pour une entreprise dont le produit est la facturation, c'est le bon choix. Pour un SaaS ou une société de services qui doit émettre cinquante factures valides par mois dans trois pays, c'est un second produit que personne n'a demandé.

Validation : les règles bougent, et c'est le validateur de l'acheteur qui gagne

Une facture est valide lorsque le validateur du récepteur le dit, et les récepteurs exécutent les jeux de règles nationaux. Validez contre ceux-ci, pas contre du « XML bien formé », et revalidez lorsque le jeu de règles change — la KoSIT comme OpenPeppol publient des ensembles de règles mis à jour selon des cycles de publication réguliers.

L'outil de référence pour l'Allemagne est le validateur de la KoSIT, un moteur open source qui va « identifier le format XML réel, valider le fichier XML (à l'aide des règles de schéma et Schematron), générer un rapport personnalisé / extraire des données personnalisées du fichier XML, calculer un statut d'acceptation », piloté par des configurations de scénarios pour XRechnung et EN 16931. Il s'exécute en ligne de commande, intégré en Java ou comme démon HTTP, sous licence Apache 2.0 — ce qui en fait une bonne étape d'intégration continue, que vous développiez ou achetiez. Peppol BIS Billing 3.0 livre son Schematron en deux jeux, « Peppol transaction business rules » et « EN 16931 transaction business rules » ; les deux doivent passer. Pour les formats hybrides, vous validez deux fois : le XML intégré contre le profil, et le conteneur contre PDF/A-3.

Quel que soit votre choix, gardez un validateur indépendant dans votre chaîne. Le vérificateur de factures électroniques gratuit valide un fichier selon les règles d'un pays sans le stocker, ce qui suffit pour un contrôle ponctuel ; le validateur KoSIT en intégration continue est la meilleure habitude. Le détail au niveau développeur — termes métier, identifiants de règles, échecs courants — figure dans le guide développeur EN 16931.

Transport : trois réseaux, trois problèmes différents

Produire le fichier est le même problème dans chaque pays ; le livrer ne l'est pas. Peppol est un réseau à quatre coins que l'on rejoint par un point d'accès ; le système français achemine les factures B2B par des plateformes agréées ; le KSeF polonais est une plateforme gouvernementale centrale qui confère à la facture son identité juridique.

Peppol (Belgique, et transfrontalier)

Vous ne parlez pas à l'acheteur ; votre point d'accès parle au sien après avoir recherché l'identifiant de participant de l'acheteur. Construire votre propre point d'accès implique une accréditation auprès d'OpenPeppol et l'exploitation d'une infrastructure SMP/AS4 ; presque toutes les entreprises contractent plutôt avec un prestataire de point d'accès et s'intègrent à son API. Voir Peppol et le guide développeur Peppol.

Plateformes agréées (France)

Seule une plateforme agréée peut transmettre entre entreprises et vers l'administration fiscale. Un éditeur de logiciel soit en devient une — une procédure d'immatriculation auprès de l'administration — soit s'intègre à l'une d'elles. Voir plateformes agréées.

KSeF (Pologne)

Vous vous authentifiez, ouvrez une session, soumettez le XML FA(3), et recevez un numéro KSeF et un accusé de réception officiel (UPO) ; la facture est juridiquement émise lorsque KSeF l'accepte, pas lorsque vous la générez. La plateforme a des environnements de test et de production distincts, et un comportement prouvé dans l'un ne prouve pas l'autre. Voir KSeF.

Allemagne

Aucun réseau imposé : e-mail, téléchargement ou Peppol sont tous des canaux acceptables pour XRechnung et ZUGFeRD en B2B. L'obligation porte sur le format, pas sur le transport.

Archivage : le fichier que vous avez émis, inchangé, pendant des années

La facture que vous devez conserver est le fichier structuré tel qu'émis — pas un rendu PDF, ni une copie régénérée à partir des données d'aujourd'hui. Les règles de l'UE laissent la forme du stockage ouverte (« les entreprises sont généralement libres de stocker les factures où et comme elles le souhaitent »), mais chaque pays fixe une durée de conservation et des exigences d'accès pour les contrôles, et lorsque la facture a été émise en XML structuré, c'est le XML — et non un rendu — qui compte comme facture.

Pour un développeur, cela signifie : stockez les octets exacts que vous avez envoyés, avec un hachage, aux côtés du rapport de validation et — pour Peppol ou KSeF — de l'accusé de transport ; ne régénérez jamais ; rendez l'archive lisible sans votre application. Les durées de conservation et le lieu de stockage acceptable pour votre entité requièrent une confirmation professionnelle.

Comment KRONENWERK gère cela

KRONENWERK est un système comptable qui génère et valide la facture électronique à l'émission, avec une API pour les flux qui l'entourent. C'est la colonne « acheter / intégrer » du tableau ci-dessus, avec les limitations de transport indiquées. Pris en charge avec des limitations

• Génération et validation à l'émission. Allemagne : XRechnung et ZUGFeRD, validés avec les règles Schematron de la KoSIT et contre-vérifiés par la bibliothèque Mustang. France : Factur-X (PDF/A-3 avec CII intégré). Belgique : Peppol BIS Billing 3.0 UBL. Pologne : XML FA(3) pour KSeF. Le profil et la syntaxe suivent le pays de l'acheteur ; le verdict TVA et la vérification VIES ont lieu à la même étape.
• Réception. Les fichiers XRechnung, ZUGFeRD/Factur-X et UBL entrants sont lus en factures fournisseurs.
• Transport. Envoi et réception Peppol via un prestataire 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. Pris en charge avec des limitations. La transmission française est prévue via la capacité de plateforme agréée de Storecove et n'est pas encore prête pour la production — KRONENWERK n'est pas une plateforme agréée. Pas encore prêt. Le module KSeF 2.0 (authentification par jeton, session, soumission FA(3), récupération de l'UPO, réception) est développé et dépend de l'environnement, n'a pas été utilisé contre le KSeF de production, et KRONENWERK ne vend actuellement pas d'abonnements aux entreprises polonaises. Pas encore prêt pour la transmission.
• API. Votre application crée des clients et des brouillons de facture sur https://kronenwerk.org/api/extern/v1 (POST /customers, POST /invoices/drafts, avec Idempotency-Key) ; l'émission — l'étape qui attribue le numéro, génère la facture électronique et lance la validation — a lieu dans le produit après validation. Les webhooks signalent invoice.issued, invoice.paid et invoice.cancelled. Commencez par le démarrage rapide ; l'angle facturation électronique est sur la page API de facturation électronique.