Votre ERP est centralisé à Paris. Votre filiale polonaise vient de basculer sous KSeF. Votre équipe comptable de Budapest déclare ses factures en temps réel à l’administration fiscale hongroise. Et votre directeur financier de Bucarest reçoit des pénalités parce que vos factures ne transitent pas par le portail ANAF. Bienvenue dans la réalité de la facturation électronique en Europe centrale et orientale.
Ces pays ont pris une longueur d’avance sur l’Ouest en matière de dématérialisation fiscale — non pas par idéologie numérique, mais parce qu’ils cherchaient à réduire la fraude à la TVA, endémique dans les années 2010. Résultat : la Pologne, la Hongrie et la Roumanie imposent aujourd’hui des régimes de facturation électronique obligatoire que la majorité des groupes français n’ont pas anticipé dans leur déploiement ERP. Ce guide cartographie les obligations pays par pays, avec les paramètres techniques que votre ERP doit maîtriser avant de toucher à une facture dans ces territoires.
Contexte : pourquoi l’Europe centrale et orientale est en avance sur la facturation électronique
La fraude TVA comme déclencheur de l’innovation réglementaire
La Pologne, la Hongrie et la Roumanie ont figuré parmi les pays de l’UE avec les taux de VAT Gap (écart entre la TVA théorique et la TVA effectivement collectée) les plus élevés dans les années 2010. La Commission européenne estimait le VAT Gap polonais à plus de 25 % de la TVA théorique en 2015 (European Commission, VAT Gap Report). La réponse politique : imposer la déclaration en temps réel ou la facturation centralisée pour rendre la fraude structurellement plus difficile.
La directive ViDA comme convergence UE d’ici 2030
La directive ViDA (VAT in the Digital Age), adoptée en avril 2025, généralise le reporting numérique à l’ensemble de l’UE (Commission européenne, adoption ViDA). Les échéances clés :
- 1er juillet 2030 : reporting numérique obligatoire pour toutes les transactions B2B intra-UE transfrontalières, basé sur la facturation électronique
- 1er janvier 2035 : harmonisation des systèmes domestiques de reporting numérique (y compris ceux en place avant 2024) avec les standards EU
Ce calendrier signifie que les systèmes KSeF, RTIR et e-Factura ne sont pas des exceptions régionales appelées à disparaître : ils préfigurent le modèle que l’ensemble de l’UE adoptera. Les groupes qui les traitent comme des “problèmes de filiale” manquent l’ampleur du sujet.
Ce que cela signifie pour les groupes français avec des filiales en Europe centrale
Un ERP centralisé en France, configuré pour le modèle franco-français (Chorus Pro pour le B2G, PDP pour le B2B dès 2026), ne peut pas traiter les flux polonais, hongrois ou roumains de la même manière. Chaque pays a son propre système, son propre format XML, sa propre API gouvernementale, ses propres délais de transmission. La gouvernance ERP doit passer de “une instance centrale” à “une instance centrale avec des connecteurs de conformité locaux”.
Pologne : KSeF, le modèle de clearance centralisée
Le calendrier en vigueur depuis février 2026
La Pologne a adopté un modèle de clearance centralisée unique en Europe : toutes les factures B2B et B2G transitent par la plateforme nationale KSeF (Krajowy System e-Faktur), gérée par le ministère des Finances polonais, avant d’atteindre le destinataire.
Le calendrier réglementaire :
- 1er février 2026 : obligation pour les grands contribuables (chiffre d’affaires supérieur à 200 millions PLN, soit environ 47 M€) — confirmé par la signature présidentielle du 27 août 2025 (poland-accounting.eu)
- 1er avril 2026 : extension à tous les autres assujettis à la TVA polonaise
- 1er janvier 2027 : micro-entrepreneurs inclus, avec entrée en vigueur des sanctions financières (2026 est une période de grâce sans pénalité)
Comment KSeF fonctionne techniquement
L’ERP crée la facture, la sérialise au format FA(3) XML (le schéma 3.0, qui remplace FA(2) depuis début 2026), l’envoie à l’API KSeF avec un certificat ou un token d’authentification. KSeF valide le schéma, attribue un numéro KSeF unique, renvoie un accusé UPO (Urzędowe Poświadczenie Odbioru), et archive la facture côté État. Le destinataire la récupère directement dans son interface KSeF.
Il n’y a pas de PDF par email, pas de réseau Peppol : tout passe par la plateforme étatique.
Ce que l’ERP doit faire
- Connecteur API KSeF natif ou via middleware (gestion des tokens d’authentification, retry en cas d’indisponibilité)
- Génération de factures au format FA(3) XML avec tous les champs obligatoires (dont les données acheteur à 100 champs structurés)
- Stockage du numéro KSeF dans l’enregistrement comptable (requis pour les rapprochements et contrôles)
- Accès au portail KSeF pour le suivi et la récupération des factures reçues
Les éditeurs SAP (via SAP Document and Reporting Compliance), Oracle (Tax Reporting Cloud), Sage et Comarch proposent des connecteurs natifs ou certifiés. Les plateformes middleware Pagero, Sovos, et Edicom couvrent également KSeF avec une couche d’abstraction multi-pays (Pagero, KSeF e-invoicing).
Pour une analyse complète du fonctionnement technique de KSeF et de la checklist ERP associée, consultez notre article dédié : KSeF Pologne 2026 : la facturation électronique centralisée et ce que votre ERP doit gérer.
Hongrie : RTIR, le reporting en temps réel depuis 2021
Un système opérationnel depuis cinq ans
La Hongrie a devancé tous ses voisins. Depuis le 1er juillet 2021, le RTIR (Real-Time Invoice Reporting, connu sous le nom “Online Számla”) est obligatoire pour toutes les entreprises assujetties à la TVA hongroise, sans exception et sans seuil de taille (EDICOM, Hungary RTIR).
La différence fondamentale avec le modèle polonais : le RTIR n’est pas un système de clearance. La facture est émise normalement entre l’émetteur et le destinataire. Ce qui est obligatoire, c’est la déclaration du contenu de la facture à l’administration fiscale (NAV, Nemzeti Adó- és Vámhivatal) en temps réel — au moment de l’émission ou dans les 24 heures.
Le format XML 3.0 obligatoire depuis mai 2025
Le NAV a mis fin au support de la version XML 2.0 le 15 mai 2025. Toutes les entreprises doivent désormais transmettre leurs données de facturation au format XML schema 3.0 (Global VAT Compliance, Hungary 2025). Les ERP configurés sur d’anciens schémas risquent des rejets de transmission depuis cette date.
À compter de septembre 2025, le NAV a renforcé les validations du contenu des données transmises : 15 nouveaux types d’erreurs bloquants ont été introduits (erreurs techniques ou de contenu qui empêchent la soumission).
Le piège des filiales hongroises dans un groupe centralisé
La règle s’applique à toute entité assujettie à la TVA en Hongrie, peu importe où est hébergé l’ERP. Une filiale hongroise dont la comptabilité est gérée depuis le siège parisien via une instance ERP française doit quand même transmettre chaque facture B2B à NAV via le RTIR. Si l’ERP central ne sait pas envoyer des flux XML 3.0 à l’API Online Számla, la filiale est en infraction.
Sanctions : jusqu’à HUF 1 000 000 (environ 2 300 euros) par facture non déclarée, auxquels s’ajoutent des contrôles fiscaux et des risques de perte de déductibilité TVA côté acheteur (DDDInvoices, Hungary RTIR).
Cas particulier : secteur de l’énergie
Depuis le 1er juillet 2025, les entreprises du secteur de l’électricité et du gaz naturel sont soumises à une obligation de facturation électronique B2B (pas seulement le reporting). Ce secteur sert de pilote pour une éventuelle extension.
Roumanie : e-Factura, le clearance à la française avant la France
Le calendrier roumain en un coup d’oeil
La Roumanie a imposé la facturation électronique B2B par clearance ANAF depuis le 1er janvier 2024, avec un modèle proche du futur système français. Résumé chronologique :
- Janvier 2022 : obligation B2G (marchés publics)
- 1er janvier 2024 : obligation B2B pour toutes les entreprises établies ou immatriculées à la TVA en Roumanie
- Juillet 2024 : passage en mode clearance complet — l’ANAF valide chaque facture, lui appose un sceau numérique, puis la transmet au destinataire ; fin de la période de grâce, sanctions applicables
- 2025 : extension au B2C (régime simplifié) et aux indépendants
Format et plateforme
Le format requis est XML UBL 2.1 conforme aux spécifications ANAF. Les factures sont transmises à la plateforme e-Factura de l’ANAF via une API dédiée. À l’issue de la validation, la facture reçoit un numéro d’index ANAF — ce numéro est la preuve juridique que la facture est valide. Sans lui, la facture n’a pas de valeur légale en Roumanie, même si elle est signée et archivée côté émetteur.
L’archivage légal est de 10 ans.
Sanctions : un barème progressif et une pénalité de 15 %
Le régime de sanctions roumain est parmi les plus sévères de l’UE :
Pour transmission tardive ou manquante (Global VAT Compliance, Romania 2025) :
- Grandes entreprises : 5 000 à 10 000 RON (~1 000 à 2 000 €) par facture
- Moyennes entreprises : 2 500 à 5 000 RON (~500 à 1 000 €) par facture
- Petites entreprises : 1 000 à 2 500 RON (~200 à 500 €) par facture
Pour non-émission via le système (depuis juillet 2024) : une pénalité de 15 % de la valeur de la facture — ce qui, pour des transactions B2B importantes, peut se chiffrer en dizaines de milliers d’euros par erreur (Sovos, Romania e-Factura).
Pour les détails techniques et la configuration ERP requise, voir notre guide dédié : E-Factura et RO e-Transport : ce que les entreprises opérant en Roumanie doivent configurer dans leur ERP.
République tchèque et autres pays : état des lieux 2026
Tchéquie : B2G obligatoire, B2B attendu avec ViDA
La Tchéquie impose la facturation électronique pour les marchés publics via la plateforme NEN (Národní elektronický nástroj). En revanche, il n’existe pas à ce jour de mandat B2B domestique. Le gouvernement tchèque a indiqué qu’il s’appuierait sur la directive ViDA pour structurer son approche du B2B, sans lancer de système national parallèle (Accace, Czech Republic e-invoicing). Les entreprises ayant des filiales tchèques peuvent opérer en facturation traditionnelle pour leurs flux B2B domestiques jusqu’à ce que ViDA impose la convergence.
Slovaquie, Bulgarie, Slovénie
Ces pays sont en phase de consultation ou d’adaptation progressive aux exigences ViDA. Aucun mandat B2B n’est en vigueur au moment de la rédaction de cet article (juin 2026). À surveiller : la transposition de ViDA par chaque État membre, dont les premières obligations s’appliqueront à partir de juillet 2030 pour les flux intra-UE.
Impact ERP et recommandations pour les groupes français
Audit pays par pays : trois niveaux d’obligation
Avant tout paramétrage, cartographiez vos entités :
| Pays | Régime en vigueur | Modèle | Délai de transmission |
|---|---|---|---|
| Pologne | KSeF (B2B + B2G) | Clearance centralisée | Avant envoi au destinataire |
| Hongrie | RTIR Online Számla (B2B + B2C) | Reporting temps réel | Immédiat ou 24h max |
| Roumanie | e-Factura ANAF (B2B + B2G) | Clearance | Avant envoi au destinataire |
| Tchéquie | B2G uniquement (NEN) | Portail public | Sans objet B2B |
| Autres pays CEE | En cours (ViDA 2030+) | À définir | — |
Connecteur natif ERP ou middleware spécialisé ?
Deux approches coexistent dans les organisations :
1. Connecteur natif ERP : SAP (Document and Reporting Compliance, ou SAP DRC), Oracle (Tax Reporting Cloud), Sage et d’autres éditeurs majeurs intègrent des connecteurs certifiés pour KSeF, RTIR et e-Factura. Cette approche est cohérente si votre ERP est un tier 1 avec un roadmap de conformité fiscale internationale documentée. Vérifiez que la version que vous utilisez (S/4HANA, Oracle Cloud, etc.) dispose bien des connecteurs actifs pour chaque pays concerné — les versions on-premise en fin de cycle de maintenance peuvent être lacunaires.
2. Middleware spécialisé : Sovos, Pagero (ONESOURCE Pagero, ex-Thomson Reuters), Edicom, et Eesiflo proposent des plateformes multi-pays qui s’intercalent entre votre ERP et les portails gouvernementaux. L’avantage : un seul partenaire gère la conformité de 10 à 80 juridictions, en absorbant les mises à jour réglementaires (changements de schéma, nouvelles validations NAV, etc.) sans toucher à votre ERP core. Le surcoût de licence est réel mais souvent inférieur au coût de maintenance d’un connecteur natif par pays.
Pour un groupe avec 3 filiales CEE et un ERP centralisé, le middleware spécialisé est généralement l’option la plus rapide à déployer et la moins risquée en termes de continuité.
Checklist de 8 points pour un groupe avec filiales en Europe centrale et orientale
Avant de valider la conformité de votre système de facturation dans ces pays, répondez à ces questions :
- Pologne : votre ERP génère-t-il du XML FA(3) et dispose-t-il d’un connecteur API KSeF avec gestion des tokens ?
- Pologne : le numéro KSeF est-il stocké dans chaque enregistrement de facture côté ERP ?
- Hongrie : votre ERP envoie-t-il des données de facturation en XML schema 3.0 à l’API Online Számla ?
- Hongrie : le délai de transmission est-il inférieur à 24 heures après émission ?
- Roumanie : votre ERP transmet-il les factures à l’API ANAF avant envoi au destinataire, et stocke-t-il le numéro d’index ANAF retourné ?
- Roumanie : votre système d’archivage est-il configuré pour 10 ans de conservation ?
- Multi-pays : en cas d’indisponibilité du portail gouvernemental (maintenance planifiée ou incident), quel est le mécanisme de queue et retry dans votre ERP ou middleware ?
- Gouvernance : qui, dans votre organisation, est responsable du suivi des mises à jour de schéma et des nouvelles validations réglementaires dans chaque pays ?
Si vous ne pouvez pas répondre “oui” avec preuve à l’appui pour chacun de ces points, votre groupe est exposé à des sanctions dans au moins un pays.
Ce qu’il faut surveiller en 2026-2027
Pologne — fin de la grâce le 1er janvier 2027 : les amendes pour non-conformité KSeF entreront en vigueur dès le premier trimestre 2027. Si votre filiale polonaise n’est pas compliant avant fin 2026, vous avez une fenêtre de risque très courte.
Hongrie — nouvelles validations NAV (septembre 2025 déjà actives) : les 15 types d’erreurs bloquants introduits peuvent rejeter des transmissions si les données manquent de cohérence. Vérifiez les logs de transmission de votre filiale hongroise.
ViDA — transposition nationale à surveiller par pays : chaque État membre doit transposer ViDA. Les pays qui n’ont pas encore de système domestique (Tchéquie, Slovaquie, Bulgarie) vont légiférer entre 2026 et 2029. Une veille réglementaire semestrielle est recommandée pour les groupes multi-pays CEE.
Convergence des formats vers EN 16931 : ViDA impose que les systèmes domestiques convergent vers la norme européenne EN 16931 d’ici 2035. KSeF (FA(3)) et e-Factura (UBL 2.1) sont déjà partiellement alignés. RTIR est un système de reporting, pas d’échange — son architecture devra évoluer.
Pour aller plus loin, consultez notre panorama de la facturation électronique obligatoire en Europe et son impact ERP et notre état des lieux mi-2026 de la facturation électronique en France (PDP, PPF, e-reporting) — le cadre français partage la logique de clearance roumaine, avec ses propres particularités opérateur.
