InvoiceNinja est un logiciel de facturation open source largement utilisé par les TPE et PME françaises. Depuis la version 5, il propose une option d’export Factur-X pour générer des PDF hybrides conformes au standard européen. Mais générer un fichier Factur-X ne signifie pas qu’il sera accepté par les Plateformes de Dématérialisation Partenaires (PDP) lors de l’entrée en vigueur de la réforme de facturation électronique en France.
La norme EN16931 est exigeante : des contraintes structurelles, des règles métier Schematron et des exigences spécifiques à la France rendent la conformité difficile à atteindre sans validation outillée.
Pourquoi valider ses factures avant la réforme ?
La réforme de facturation électronique française impose à toutes les entreprises assujetties à la TVA d’émettre et de recevoir leurs factures via des plateformes agréées — soit le Portail Public de Facturation (PPF), soit des PDP accréditées par la DGFiP.
Ces plateformes effectuent une validation technique à la réception. Une facture Factur-X qui ne respecte pas les règles EN16931 sera rejetée automatiquement et ne sera pas transmise au destinataire. Le calendrier applicable est le suivant :
- 1er septembre 2026 : obligation de réception pour toutes les entreprises
- 1er septembre 2027 : obligation d’émission pour les PME et TPE
Un rejet de facture a des conséquences concrètes : retard de paiement, relances manuelles, risque de contentieux. Valider en amont, avant d’entrer dans le dispositif obligatoire, est donc indispensable.
Ce que vérifie la norme EN16931
La conformité d’un fichier Factur-X repose sur trois niveaux de validation distincts.
Niveau 1 — Conformité PDF/A-3
Le PDF doit respecter la norme ISO 19005-3 (PDF/A-3). Cela implique que toutes les ressources (polices, images, ICC profiles) soient embarquées dans le fichier, et qu’aucune dépendance externe ne soit présente. Un PDF généré avec des polices système non embarquées échoue à ce niveau.
Niveau 2 — Structure XML et validation XSD
Le fichier XML embarqué dans le PDF (généralement nommé factur-x.xml ou ZUGFeRD-invoice.xml) doit être valide selon le schéma XSD EN16931. Ce schéma définit les éléments obligatoires, optionnels et leur cardinalité. Une balise manquante, un namespace incorrect ou un type de données inapproprié entraîne un échec.
Niveau 3 — Règles métier Schematron
C’est le niveau le plus restrictif. Les fichiers Schematron officiels publiés par le CEN TC 434 définissent plusieurs centaines de règles métier codifiées (préfixe BR- pour les règles normatives). Ces règles vérifient la cohérence des montants, la présence des identifiants obligatoires et la validité des codes utilisés.
Les erreurs fréquentes dans les exports Factur-X d’InvoiceNinja
En pratique, les fichiers générés par InvoiceNinja présentent régulièrement les erreurs suivantes lors de la validation EN16931.
BR-CO-14 — Incohérence du montant de TVA
La règle BR-CO-14 vérifie que le total TVA de la facture (TaxTotalAmount) correspond à la somme des montants de TVA par catégorie fiscale. InvoiceNinja peut introduire des arrondis différents selon la configuration de précision monétaire, ce qui génère des centimes d’écart.
BR-CO-15 — Incohérence du total TTC
La règle BR-CO-15 impose que le montant TTC (BT-112) soit égal au montant HT (BT-109) plus le total TVA (BT-110). Là encore, les arrondis sont la cause principale d’échec.
BT-30 — Identifiant légal du vendeur (SIREN)
Pour les factures émises en France, le SIREN de l’émetteur doit figurer dans le champ AccountingSupplierParty/Party/PartyLegalEntity/CompanyID, accompagné du schéma 0002 (code INSEE pour les entreprises françaises). InvoiceNinja ne pré-remplit pas ce champ automatiquement.
BT-4 — Type de transaction commerciale
Le champ SubjectCode (BT-4) dans le nœud DocumentContext doit indiquer le type de transaction : B2B, B2C ou B2G. Ce champ est absent dans certaines configurations d’InvoiceNinja, ce qui entraîne une erreur de validation Schematron spécifique au profil FR-EN16931.
Profil MINIMUM insuffisant
Par défaut, InvoiceNinja peut générer des fichiers avec le profil MINIMUM. Ce profil n’est pas accepté pour les transactions B2B soumises à la réforme — le profil EN16931 (niveau 2) ou EXTENDED est requis.
Valider avec l’API FacturX
L’API FacturX permet de valider un fichier en envoyant une requête HTTP POST multipart. Voici un exemple fonctionnel avec curl :
curl -X POST https://facturxapi.com/api/v1/validate \
-H "X-API-Key: votre-cle-api" \
-F "[email protected]"La réponse JSON est structurée comme suit :
{
"valid": false,
"profile": "EN16931",
"errors": [
{
"id": "BR-CO-14",
"type": "error",
"message": "Le total TVA de la facture doit correspondre à la somme des montants de TVA par catégorie fiscale.",
"location": "/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxTotalAmount"
},
{
"id": "BT-30-missing",
"type": "error",
"message": "L'identifiant légal du vendeur (SIREN) est absent ou invalide.",
"location": "/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement"
}
],
"warnings": [],
"pdfConformance": {
"valid": true,
"standard": "PDF/A-3b"
}
}Le champ id correspond directement à l’identifiant de règle EN16931, ce qui permet de localiser rapidement la correction à apporter dans la configuration InvoiceNinja ou dans le template de facture.
Les 4 champs obligatoires pour la France en 2026
En plus des exigences EN16931 générales, la France impose des champs additionnels dans le cadre de la réforme :
1. SIREN de l’émetteur (BT-30)
Valeur : numéro SIREN à 9 chiffres, sans espaces.
Schème : 0002 (code officiel INSEE/DGFiP).
Champ XML : AccountingSupplierParty/Party/PartyLegalEntity/CompanyID avec attribut schemeID="0002".
2. Type de transaction (BT-4)
Valeurs acceptées : B2B, B2B-AUTOLIQ, B2G, B2C.
Champ XML : ExchangedDocumentContext/BusinessProcessSpecifiedDocumentContextParameter/ID.
Ce champ est requis par le schéma Factur-X France (extension nationale).
3. Adresse de livraison
Pour les transactions B2B, l’adresse de livraison ou de prestation doit être renseignée si elle diffère de l’adresse de facturation. Le nœud ShipToTradeParty doit contenir au minimum le code pays.
4. SIREN de l’acheteur
Le SIREN du destinataire de la facture doit également figurer dans AccountingCustomerParty/Party/PartyLegalEntity/CompanyID avec le même schème 0002. Ce champ est requis pour les factures B2B soumises à la réforme.
Préparer InvoiceNinja
InvoiceNinja permet d’ajouter des champs personnalisés sur les clients, les produits et les factures via le panneau Paramètres > Champs personnalisés. Pour intégrer les données requises :
Champ SIREN émetteur : Configurer le champ personnalisé company_custom1 (ou équivalent) avec le libellé “SIREN” sur le profil de la société. Modifier ensuite le template Factur-X pour que cette valeur soit injectée dans le nœud CompanyID avec schemeID="0002".
Champ SIREN client : Ajouter un champ personnalisé sur les fiches clients pour stocker le SIREN. Le mapper au nœud AccountingCustomerParty dans le template XML.
Type de transaction : Définir une valeur par défaut B2B dans les paramètres de template. Si vous avez des clients publics (B2G), créer un type de facture distinct avec la valeur B2G.
Profil Factur-X : Vérifier que le profil sélectionné dans les paramètres d’export est EN16931 et non MINIMUM. InvoiceNinja expose ce réglage dans Paramètres > Configuration PDF > Profil Factur-X.
Après chaque modification du template, valider un lot de factures représentatives avant de passer en production. La validation en amont via l’API permet de construire un pipeline de contrôle qualité automatisé : générer la facture, valider, alerter si des erreurs sont détectées avant l’envoi.
La conformité EN16931 n’est pas un obstacle, c’est un prérequis technique à la dématérialisation fiscale. Obtenir une clé API gratuite pour commencer à valider vos exports InvoiceNinja avant la réforme prend moins d’une minute.