SAF-T et facturation électronique en Bulgarie 2026 : Guide de configuration NetSuite

Résumé analytique

Ce rapport complet analyse les exigences émergentes pour la facturation électronique B2B en Bulgarie et le Fichier d'audit standard pour la fiscalité (SAF-T), rendus obligatoires à partir de 2026, et fournit des conseils détaillés sur la configuration d'Oracle NetSuite ERP pour assurer la conformité. Ces dernières années, la Bulgarie s'est lancée dans une transformation numérique de ses processus de reporting fiscal et comptable, suivant les tendances de l'UE et de l'OCDE. En 2025, le Parlement bulgare a officiellement intégré une exigence SAF-T progressive dans la loi, effective au 1er janvier 2026 pour les grandes entreprises, avec une couverture complète (à l'exclusion des micro-entreprises uniquement) d'ici 2030 ^[1] (Source: accountingnews.bg). Parallèlement, les directives de l'UE (notamment la TVA à l'ère du numérique, ViDA) rendront bientôt obligatoire la facturation électronique dans les échanges B2B. La Bulgarie impose depuis longtemps la facturation électronique pour les contrats B2G (marchés publics) depuis fin 2019 ^[2], mais les mandats de facturation électronique B2B sont toujours en cours de développement. Des sources industrielles confirment que la Bulgarie prévoit un régime de facturation électronique centralisé de type « clearance » pour les entreprises au cours de cette décennie ^[3] (Source: accountingnews.bg). Dans l'intervalle, les entreprises nationales et étrangères en Bulgarie doivent se préparer aux déclarations mensuelles SAF-T (registres du grand livre, factures, paiements, etc.) et à l'éventuelle facturation électronique en temps réel via le système national de facturation électronique (NEFS) (Source: www.brait.cc) (Source: accountingnews.bg).

Ce rapport fournit un contexte et une analyse rigoureux : il passe en revue l'évolution historique des mandats de facturation électronique et SAF-T en Bulgarie et dans l'UE, détaille les spécifications juridiques et techniques (formats de dépôt, calendriers, signatures numériques, règles de conservation, etc.) et compare le régime bulgare avec d'autres pionniers de l'UE (Italie, Pologne, France, etc.). Nous utilisons des sources faisant autorité (communiqués gouvernementaux, directives de l'UE, arrêtés des autorités fiscales, publications industrielles) pour établir les faits et fournir des informations basées sur des données. Dans la mesure du possible, nous présentons des statistiques sur la conformité à la TVA et l'adoption de la facturation électronique – par exemple, le mandat de facturation électronique en Italie a réduit son écart de TVA de 10,7 % en deux ans (Source: accountingnews.bg), et l'écart de TVA propre à la Bulgarie (~10,8 % des recettes attendues) justifie une application numérique agressive ^[4].

Il est crucial de noter que le rapport inclut des conseils pratiques sur la configuration de NetSuite pour la conformité bulgare. Nous examinons les options de localisation de NetSuite (par exemple, les bundles de TVA bulgare de BTS One et Balkan Services) et décrivons comment le SuiteApp Electronic Invoicing et le SuiteApp Tax Audit Files de NetSuite peuvent être utilisés ou étendus. Par exemple, NetSuite peut produire un fichier XML SAF-T conforme à l'OCDE ^[5] qui peut servir de point de départ pour le schéma bulgare (actuellement défini dans l'arrêté NRA Z-ЦУ-30-1085/2025, mis à jour v1.0.2 pour les soumissions de 2026 (Source: nra.bg) (Source: nra.bg). Nous examinons des études de cas d'autres pays (par exemple, l'Italie et la Pologne) pour illustrer comment les entreprises ont automatisé la facturation électronique via des intégrations ERP (Source: rite.digital) (Source: www.rsmpoland.pl).

La conclusion discute des implications et des prochaines étapes : comment les autorités bulgares prévoient de déployer la conformité, comment les éditeurs de logiciels et les consultants peuvent soutenir les entreprises (y compris les éventuels SuiteApps NetSuite), et comment une stratégie européenne à long terme (ViDA à partir de 2030) poussera tous les contribuables bulgares vers la facturation numérique. Nous insistons sur le fait que les entreprises ne doivent pas attendre 2026, mais commencer dès maintenant à cartographier leurs systèmes et processus comptables. En tirant parti des outils de NetSuite et en suivant des étapes de mise en œuvre structurées, les entreprises multinationales peuvent minimiser les perturbations tout en atteignant une conformité totale avec le SAF-T 2026 de la Bulgarie et les futures exigences de facturation électronique. Toutes les affirmations et données de ce rapport sont étayées par des citations de sources crédibles.

Table des matières

• Résumé analytique
• 1. Introduction et contexte
  • 1.1 Transformation numérique de la fiscalité dans l'UE
  • 1.2 Paysage réglementaire bulgare
  • 1.3 ViDA et futurs mandats de l'UE
• 2. Exigences de facturation électronique en Bulgarie
  • 2.1 Facturation électronique dans les marchés publics (B2G) : historique et statut
  • 2.2 Statut actuel de la facturation électronique B2B (volontaire vs obligatoire)
  • 2.3 Mandats B2B prévus : modèles proposés et calendrier
  • 2.4 Normes techniques (UBL 2.1, XML, signatures numériques)
  • 2.5 Infrastructure nationale de facturation électronique (NEFS)
• 3. SAF-T (Fichier d'audit standard pour la fiscalité) en Bulgarie
  • 3.1 Aperçu du SAF-T (norme OCDE, contexte UE)
  • 3.2 Adoption en Bulgarie (Loi sur le budget de l'État 2025)
  • 3.3 Calendrier de mise en œuvre progressive (2026–2030)
  • 3.4 Obligations de déclaration et fréquence
  • 3.5 Spécifications techniques (arrêtés NRA, XSD, contenu des fichiers)
  • 3.6 Processus de soumission et archivage
• 4. Impacts et justification
  • 4.1 Fraude à la TVA et conformité (écarts de TVA)
  • 4.2 Exemples d'autres pays (Italie, Pologne, France)
  • 4.3 Contexte économique bulgare (écart de TVA, paysage des PME)
  • 4.4 Avantages et défis pour les entreprises
• 5. Aperçu de NetSuite pour la conformité
  • 5.1 Cadre de localisation de NetSuite (SuiteApps EMEA)
  • 5.2 SuiteApps et fonctionnalités NetSuite pertinentes
    • 5.2.1 SuiteApp Electronic Invoicing (documents électroniques)
    • 5.2.2 SuiteApp Tax Audit Files (SAF-T, extraits du GL)
    • 5.2.3 Bundles de localisation bulgare (BTS One, Balkan Services)
  • 5.3 Mappage des données aux exigences bulgares (plan comptable, taxes)
  • 5.4 Capacités d'intégration (API, EDI, signature électronique qualifiée)
• 6. Guide de mise en œuvre : configuration de NetSuite
  • 6.1 Évaluation pré-mise en œuvre (analyse des écarts)
  • 6.2 Configuration de NetSuite pour le droit fiscal bulgare (localisation)
  • 6.3 Génération de factures électroniques avec NetSuite
  • 6.4 Génération de fichiers SAF-T (mappage et SuiteApp)
  • 6.5 Intégration avec les systèmes NRA (NEFS, portail e-Services)
  • 6.6 Tests, projets pilotes et déploiement progressif
• 7. Études de cas et exemples
  • 7.1 Italie : mise en œuvre de la facturation électronique SdI via Oracle Integration Cloud (Source: rite.digital)
  • 7.2 Pologne : module NetSuite KSeF pour les factures électroniques (Source: www.rsmpoland.pl) (Source: www.rsmpoland.pl)
  • 7.3 Roumanie (localisation BTS One pour SAF-T)
  • 7.4 Exemple interne : filiale bulgare dans un tenant NetSuite mondial
• 8. Données et analyse
  • 8.1 Tendances d'adoption (SAF-T au niveau mondial, facturation électronique dans l'UE)
  • 8.2 Impact projeté sur le marché (TCAC, solutions de conformité)
  • 8.3 Données d'enquête (le cas échéant sur l'état de préparation)
  • 8.4 Avis d'experts (consultants fiscaux, cadres d'Oracle)
• 9. Discussion : implications et orientations futures
  • 9.1 Court terme (2026–2028) : préparation à la conformité
  • 9.2 ViDA et convergence paneuropéenne (à partir de 2030)
  • 9.3 Évolution technologique (IA, blockchain, reporting en temps réel)
  • 9.4 Risques et incertitudes (changements politiques, retards techniques)
• 10. Conclusion et recommandations
  • 10.1 Résumé des exigences
  • 10.2 Plan d'action stratégique pour les utilisateurs de NetSuite
  • 10.3 Remarques finales sur la fiscalité numérique en Bulgarie

1. Introduction et contexte

1.1 Transformation numérique de la fiscalité dans l'UE

Au cours de la dernière décennie, l'Union européenne a poussé les États membres vers le reporting numérique de la TVA et des données fiscales structurées. La directive phare 2014/55/UE a rendu obligatoire l'adoption de la facturation électronique dans le B2G (marchés publics) d'ici 2018. En 2025, l'UE a introduit le paquet TVA à l'ère du numérique (ViDA), articulé autour de trois piliers : (1) facturation électronique obligatoire pour les livraisons intra-UE B2B d'ici juillet 2030, (2) reporting en temps réel via des plateformes numériques pour les places de marché d'ici janvier 2030, et (3) élargissement du guichet unique (OSS) d'ici 2028 (Source: accountingnews.bg). Ces mesures visent à standardiser les contrôles de TVA sur le marché unique et à réduire la fraude. De nombreux pays de l'UE ont déjà imposé des exigences avancées en matière de facturation électronique et de SAF-T (Tableau 1). L'Italie, par exemple, a rendu obligatoire la facturation électronique B2B via la plateforme SDI en 2019, atteignant une baisse estimée à 10,7 % de son écart de conformité à la TVA en deux ans (Source: accountingnews.bg). La Pologne a introduit une plateforme nationale de facturation électronique B2B (KSeF) à partir de février 2026 (Source: accountingnews.bg). Parallèlement, plus d'une douzaine de membres de l'UE exigent désormais des soumissions de données de transaction de type SAF-T (mensuelles ou à la demande) aux autorités fiscales ^[6] (Source: accountingnews.bg).

Tableau 1. Sélection de régimes de facturation électronique/SAF-T dans l'UE (exemples). (B2G = Business to Government, CTC = Contrôles continus des transactions, *la conformité SAF-T est une version nationale.)

| France| Oui, conforme à la directive | Mandat progressif à partir de sept. 2026 | Chorus Pro (XML/B2G) ; PPF (audit a posteriori pour le B2B) (Source: accountingnews.bg) | Pas de SAF-T complet ; e-reporting de TVA prévu dans le cadre de ViDA (Source: accountingnews.bg) | | Bulgarie| Oui, depuis nov. 2019 (Directive UE) ^[2] | Pas encore ; mandat futur prévu (Source: accountingnews.bg) ^[3] | NEFS prévu (UBL 2.1 XML) (Source: www.brait.cc) | SAF-T introduit en janv. 2026, déploiement progressif jusqu'en 2030 ^[7] (Source: accountingnews.bg) |

Par rapport à ces pays, la Bulgarie suit une trajectoire similaire : la facturation électronique pour les organismes publics est possible depuis fin 2019 ^[2], mais la facturation B2B obligatoire est toujours en cours de développement (Source: accountingnews.bg) ^[3]. Parallèlement, la Bulgarie s'est engagée à mettre en œuvre le reporting SAF-T basé sur les normes de l'OCDE à partir de 2026 ^[1] (Source: accountingnews.bg). Ce rapport examine les règles spécifiques à la Bulgarie et la manière dont les entreprises (en particulier celles utilisant l'ERP NetSuite) peuvent s'y conformer.

1.2 Paysage réglementaire bulgare

L'administration fiscale bulgare, l'Agence nationale des revenus (NRA, Национална агенция за приходите), modernise ses systèmes numériques. Dans le budget de l'État pour 2025 (promulgué en mars 2025), l'Assemblée nationale bulgare a explicitement rendu obligatoire le dépôt du SAF-T d'ici 2026 ^[1]. La base juridique est désormais intégrée à l'art. 71z du Code de procédure fiscale et de sécurité sociale (Данъчно-осигурителния процесуален кодекс, ДОПК). En pratique, la NRA a émis des arrêtés détaillant la structure, le format et la procédure des fichiers SAF-T (Source: nra.bg) (Source: nra.bg). Par exemple, l'arrêté n° З-ЦУ-30-1085/25.07.2025 (modifié par des arrêtés ultérieurs) a officiellement défini le schéma XML et XSD du SAF-T bulgare (version 1.0.2 pour 2026) (Source: nra.bg) (Source: nra.bg).

La facturation électronique B2G en Bulgarie est prise en charge par le Système d'information automatisé centralisé pour les marchés publics électroniques (CAIS EPP), et tous les organismes du secteur public sont en mesure de recevoir des factures électroniques (format UBL 2.1) depuis novembre 2019 ^[2]. Cependant, l'émission de factures électroniques aux acheteurs du secteur privé reste volontaire. En décembre 2024, le projet de loi de finances 2025 mentionnait des mandats de facturation électronique dans le cadre de réformes plus larges de la TVA numérique ^[8], et les sources du secteur s'attendent à ce que des règles formelles émergent bientôt pour mettre en œuvre la directive ViDA de l'UE.

Dans les sections suivantes, nous détaillons les exigences bulgares exactes pour la facturation électronique B2B et le reporting SAF-T en 2026 et au-delà, en mettant l'accent sur les spécifications techniques et les délais.

1.3 Mandats de l'UE et ViDA

Les réformes de la Bulgarie s'inscrivent dans un contexte de politique à l'échelle de l'UE. La directive de 2014 sur la facturation électronique et la directive ViDA de 2022 établissent un calendrier clair pour que les États membres numérisent la conformité à la TVA. D'ici juillet 2030, toutes les livraisons B2B transfrontalières au sein de l'UE devront utiliser des factures électroniques conformes à la norme européenne (généralement basée sur UBL ou UN/CEFACT XML) (Source: accountingnews.bg). De plus, ViDA encourage les plateformes de reporting en temps réel (appelées contrôles continus des transactions) pour les entreprises nationales. La Bulgarie a opté pour un modèle d'audit a posteriori (les factures vont directement aux acheteurs/fournisseurs, puis sont déclarées) plutôt qu'un modèle de pré-autorisation (où l'autorité intercepte les factures) (Source: accountingnews.bg), mais cela pourrait changer à mesure que le gouvernement finalise son approche.

Il est important de noter que ViDA prévoit également que d'ici mi-2030, les transactions B2B intra-UE devront être déclarées par voie électronique. Cela signifie que même si la Bulgarie n'impose initialement que des factures électroniques B2B locales, son système devra s'aligner sur les normes ViDA à long terme. Pour l'instant, les autorités bulgares se concentrent sur le SAF-T comme une étape vers cet avenir. En pratique, le SAF-T exigera des entreprises qu'elles fournissent des données détaillées sur les factures et les grands livres sur une base mensuelle, ce qui pousse déjà les entreprises vers des enregistrements électroniques structurés et (indirectement) prépare le terrain pour la conformité à la facturation électronique.

2. Exigences de facturation électronique en Bulgarie

2.1 Facturation électronique B2G : historique et statut

En vertu de la directive européenne 2014/55/UE, les États membres de l'UE devaient permettre la facturation électronique B2G (Business-to-Government) d'ici avril 2019. En Bulgarie, cette exigence a été mise en œuvre comme suit : depuis le 1er novembre 2019, les entités du secteur public bulgare peuvent accepter et traiter des factures électroniques. En pratique, cela signifie que les fournisseurs de l'État peuvent volontairement émettre des factures électroniques pour les marchés publics ; les systèmes gouvernementaux sont tenus de les traiter, mais les entreprises ne sont pas obligées de les utiliser. La plateforme officielle de facturation électronique pour les marchés publics est le CAIS EPP ^[2].

La date d'obligation (nov. 2019) a été annoncée par le gouvernement bulgare et est reflétée dans les résumés des experts ^[2]. Thomson Reuters note explicitement que les factures électroniques pour les marchés publics sont possibles depuis fin 2019 ^[2]. Les fournisseurs peuvent envoyer des factures électroniques au format UBL-2.1 XML aux agences d'État via le CAIS EPP (souvent par l'intermédiaire d'intermédiaires). Le format doit suivre la norme européenne (EN 16931). Les factures doivent porter une signature électronique qualifiée ou être certifiées par des procédures d'échange de données électroniques approuvées ^[2].

Notamment, bien que le secteur public puisse recevoir des factures électroniques, le rapport Sovos indique qu'il n'existe toujours aucune obligation pour les fournisseurs bulgares d'émettre des factures électroniques, même aux autorités publiques ^{[9] [10]}. En d'autres termes, le B2G en Bulgarie est actuellement « à sens unique » : le gouvernement est prêt à recevoir des factures électroniques (comme l'exige la directive européenne), mais la loi bulgare n'a pas contraint les entreprises à abandonner la facturation papier ou PDF. Ainsi, la conformité pour la plupart des entreprises s'est jusqu'à présent concentrée sur le SAF-T plutôt que sur la facturation électronique.

2.2 Statut actuel de la facturation électronique B2B (volontaire)

En mai 2026, la facturation électronique B2B en Bulgarie reste volontaire, sans mandat légal encore en vigueur (Source: accountingnews.bg) ^[11]. Les entreprises peuvent émettre des factures électroniques si les deux parties sont d'accord, mais sont sinon libres d'utiliser des factures papier ou PDF. Des exigences plus souples (par exemple, le consentement de l'acheteur) s'appliquent : si un fournisseur souhaite envoyer un PDF par e-mail à un client, l'acheteur doit donner son accord (similaire aux règles de TVA dans de nombreuses juridictions). Le guide Sovos déclare explicitement : « Les autorités fiscales bulgares n'imposent en aucune manière l'émission de factures électroniques… la facturation électronique est autorisée tant que le fournisseur obtient le consentement de l'acheteur au préalable » ^[10].

Cependant, la Bulgarie se prépare activement à une transition. Des sources industrielles décrivent des projets de modèle de centralisation par lequel toutes les factures commerciales seraient déclarées à un système national. Cela refléterait des systèmes comme le SDI italien ou le KSeF polonais. Pour l'instant, il s'agit d'annonces et de propositions. La NRA a mené une consultation publique sur la facturation électronique en 2021, et les déclarations des responsables indiquent un futur passage vers une facturation électronique B2B obligatoire selon un modèle de chambre de compensation (« centralisé ») (Source: www.brait.cc) ^[3]. Des représentants ont mentionné que le nouveau système utilisera le format UBL 2.1 XML et exigera des signatures électroniques sur les e-mails, etc. Bien que les détails soient encore en cours d'élaboration, il est largement prévu qu'une exigence de facturation électronique progressive sera déployée après le déploiement initial du SAF-T.

2.3 Mandats B2B prévus : modèles et calendrier

Le calendrier exact des mandats de facturation électronique B2B en Bulgarie n'a pas été fixé par la loi en 2026. Cependant, le calendrier annoncé par le gouvernement est agressif. Selon les rapports de l'industrie (par exemple, Brait, DDD Invoices, EDICOM), la Bulgarie prévoit une mise en œuvre progressive commençant vers 2026, affectant d'abord les plus grands contribuables (Source: www.brait.cc) ^[12]. Par exemple, un résumé de cabinet de conseil indique :

• Janv. 2026 : Les grandes entreprises (chiffre d'affaires > 300 millions BGN en 2023 ou impôt > 3,5 millions) doivent émettre des factures électroniques.
• Janv. 2027 : Entreprises atteignant les mêmes seuils en 2024.
• Janv. 2028 : Entreprises moyennes (chiffre d'affaires > 15 millions BGN en 2025 ou impôt > 1,5 million).
• Janv. 2029 : Toutes les entreprises (quelle que soit leur taille) deviennent obligatoires.

Ces chiffres reflètent le déploiement du SAF-T mais appliqués aux factures réelles. Il convient de noter que ce plan provient de sources privées (Source: www.brait.cc) ; les avis officiels bulgares se sont concentrés sur le SAF-T plutôt que sur les mandats de facturation électronique. Néanmoins, ils signalent l'orientation politique prévue : la facturation électronique sera progressivement introduite pour les entreprises d'ici la fin des années 2020.

Le modèle devrait être centralisé/de pré-autorisation : toutes les factures électroniques seraient transmises à une plateforme centrale (le Système national de facturation électronique, NEFS), où elles seraient validées et signées numériquement, puis transmises aux acheteurs (Source: www.brait.cc). Cela est parallèle au modèle italien Sistema di Interscambio (SdI) et au KSeF polonais. Le NEFS utilisera probablement le format UBL 2.1, avec des certificats numériques certifiés pour les signatures (Source: www.brait.cc). Voir le tableau 2 pour un résumé des exigences proposées telles que rapportées par les consultants :

| Reporting | Déclaration fiscale annuelle et mensuelle des données de facturation/grand livre (via SAF-T) (Source: www.brait.cc) (Source: accountingnews.bg) | | Phases de mise en œuvre | Progressive, selon la taille de l'entreprise et le chiffre d'affaires (2026–2029) (Source: www.brait.cc) (Source: accountingnews.bg) |

2.4 Normes techniques (UBL 2.1, XML, signatures)

Le modèle référencé s'appuierait sur les normes internationales de facturation électronique : l'UBL 2.1 (Universal Business Language) est explicitement mentionné comme format pour les factures électroniques (Source: www.brait.cc). L'UBL 2.1 est largement utilisé en Europe (par exemple dans les réseaux Peppol) et répond à la norme sémantique européenne EN 16931 pour les factures. Par conséquent, les factures électroniques bulgares utiliseront probablement des éléments UBL (schéma XML UBL 2.1) pour des données telles que les lignes de facture, les parties, les taxes, etc. L'aperçu d'EDICOM confirme que les factures « doivent être dans un format électronique structuré (XML) permettant un traitement automatique » ^[13].

Toutes les factures électroniques doivent être signées numériquement. Le plan bulgare, tel que résumé par Brait, stipule que « toutes les factures électroniques doivent être validées et signées électroniquement à l'aide de certificats numériques » (Source: www.brait.cc). En pratique, cela signifie que le fichier XML de la facture doit comporter une signature électronique qualifiée (XAdES ou similaire), ou être certifié par un processus EDI qualifié. L'utilisation de certificats numériques garantit l'authenticité et l'intégrité de chaque facture électronique. Elle lie également légalement les factures à l'émetteur.

Concernant l'infrastructure technique, le NEFS (National Electronic Billing System) de la Bulgarie représente le portail gouvernemental pour les factures électroniques. Bien que les détails soient encore en cours d'élaboration, le NEFS devrait fonctionner de manière similaire aux plateformes de facturation électronique d'autres pays : les entreprises se connecteront (via API ou fichier par lots) au NEFS pour envoyer des factures, que le portail validera (contrôles de schéma, signatures) avant de les mettre à la disposition des destinataires. Début 2026, les détails exacts de l'API et de la mise en œuvre du portail NEFS étaient encore en cours de développement, mais les entreprises doivent anticiper le besoin de connexions et d'identifiants sécurisés.

Il convient de noter que jusqu'à la mise en service officielle du NEFS, les entreprises bulgares peuvent utiliser des solutions provisoires (par exemple, certains fournisseurs proposent des environnements de test). Le fournisseur E-faktura (efaktura.bg) est une plateforme qui permet la remise de factures électroniques, ce qui indique que des canaux de facturation numérique existent déjà sur le marché, bien qu'ils ne soient pas officiellement obligatoires.

2.5 Infrastructure nationale de facturation électronique (NEFS)

Bien que les spécifications détaillées du NEFS soient en attente de publication par la NRA, le modèle conceptuel est clair : le NEFS sera une plateforme centrale. Chaque facture électronique certifiée y transitera. La NRA a annoncé un portail de services électroniques pour les soumissions SAF-T (Standard Audit File), mais n'a pas encore fait d'annonce publique distincte pour le NEFS. Cependant, les commentaires de l'industrie (EDICOM, DDDInvoices) confirment le rôle central du NEFS (Source: www.brait.cc) ^[11]. Un fournisseur de localisation bulgare l'appelle également intégration au « Système national de facturation électronique ».

Les utilisateurs de NetSuite doivent planifier cette architecture en suivant les développements du NEFS. Le système nécessitera probablement soit une intégration directe par service web, soit un flux SFTP/EDI pour soumettre les fichiers XML UBL. Le protocole de transmission réel (par exemple SOAP, REST, FTP sécurisé) n'est pas encore public, mais les précédents bulgares (comme les plans d'archivage électronique) suggèrent une API HTTPS sécurisée avec des certificats clients. Il est important de noter que toutes les données à envoyer au NEFS seraient déjà générées via la facturation de NetSuite. Par conséquent, une tâche clé consiste à s'assurer que NetSuite peut générer des factures dans le schéma XML UBL 2.1 correspondant exactement au XSD du NEFS.

3. SAF-T (Standard Audit File for Tax) de la Bulgarie

3.1 Aperçu du SAF-T

Le Standard Audit File for Tax (SAF-T) est une norme développée par l'OCDE (SAF-T 2.0) pour l'échange de données comptables entre les entreprises et les autorités fiscales dans un format structuré (généralement XML) ^[14]. Dans le cadre du SAF-T, les contribuables soumettent périodiquement des registres comptables détaillés (grand livre, journaux auxiliaires, immobilisations, inventaire, etc.) aux agences fiscales pour faciliter les audits et la conformité à la TVA. Plus d'une douzaine de pays européens utilisent désormais le SAF-T, au moins à la demande (voir Figure 1).

Figure 1 : Pays utilisant le SAF-T ou une déclaration fiscale équivalente (le bleu indique une utilisation obligatoire à un certain niveau) ; le lancement progressif de la Bulgarie débute en 2026 ^[15] (Source: accountingnews.bg).

En Bulgarie, la motivation derrière le SAF-T est d'améliorer la conformité à la TVA et la gestion des risques. En recevant les données des factures de vente et d'achat mensuelles sous forme XML, la NRA peut plus facilement croiser les déclarations de TVA et identifier les sous-déclarations. Le gouvernement bulgare cite explicitement les avantages de l'OCDE en matière de conformité des contribuables, de ciblage des risques et de réduction des charges administratives (Source: nra.bg).

3.2 Mandat et base juridique

L'exigence légale pour le SAF-T a été fixée par la loi de finances de l'État pour 2025. Fin 2024 (projet de loi du 9 décembre 2024) et à nouveau au printemps 2025 (adoption finale), l'Assemblée nationale bulgare a inséré des dispositions dans le droit fiscal rendant le SAF-T obligatoire. Thomson Reuters rapporte : « la ratification du budget de l'État introduit formellement l'obligation pour les entreprises de soumettre le SAF-T à partir du 1er janvier 2026. L'obligation entre en vigueur d'abord pour les grandes entreprises en 2026, et concernera tous les contribuables d'ici 2030. » ^[16]. Cela a été précisé ultérieurement par des arrêtés de la NRA.

Conformément à l'art. 71z du Code des impôts (ajouté par la loi de finances), toutes les entreprises devront éventuellement déposer le SAF-T. Les micro-entreprises sont exemptées. D'ici le 1er janvier 2030, pratiquement toutes les entreprises (à l'exception des micro-entreprises en dessous des seuils et de certains organismes publics) devront s'y conformer ^[7] (Source: accountingnews.bg). Le calendrier progressif est spécifié. En général :

• 2026 : Les « grandes » entreprises (chiffre d'affaires net 2023 > 300 M BGN ou impôt > 3,5 M BGN) doivent déposer.
• 2027 : Les entreprises (grandes/moyennes/petites) dépassant 300 M BGN en 2024 (ou impôt > 3,5 M) rejoignent le dispositif.
• 2028 : Les entreprises avec > 15 M BGN de ventes en 2025 (ou > 1,5 M d'impôt) rejoignent le dispositif.
• 2029 : Les moyennes et petites entreprises basées sur la classification comptable de 2026.
• 2030 : Presque toutes les entreprises restantes (Art 2 de la loi comptable).

Ce calendrier est résumé dans le Tableau 3 (adapté des conseils de la NRA (Source: accountingnews.bg):

(Seuils convertis à partir des derniers tableaux de la NRA (Source: accountingnews.bg) ^[17].)

Une période de grâce a été prévue : chaque phase bénéficie d'une période de six mois sans pénalité ^[18], ce qui signifie que les soumissions tardives au cours des premiers mois n'entraînent aucune amende pendant que les entreprises s'adaptent. La NRA a publié des FAQ et des échéances pour guider les contribuables.

3.3 Obligations de déclaration et fréquence

En vertu de la nouvelle loi (Art. 71k du Code des impôts), les entreprises éligibles doivent déclarer mensuellement des données comptables détaillées à la NRA. Plus précisément, les fichiers requis sont :

1. SAF-T mensuel (jusqu'en 2030) : incluant les écritures du grand livre, les comptes fournisseurs (AP) et les comptes clients (AR), ainsi que les factures de vente et d'achat. (Ces documents doivent être soumis avant le 14e jour du mois suivant, c'est-à-dire avant la fin de la première quinzaine du mois suivant, selon l'art. 71k(1) (Source: accountingnews.bg).)
2. SAF-T annuel : listant les immobilisations (machines, bâtiments) et leurs mouvements (acquisitions, mises au rebut, amortissements). (L'échéance annuelle s'aligne sur l'échéance de la déclaration d'impôt sur les sociétés – par exemple, d'ici le 30 juin de l'année suivante (Source: accountingnews.bg).)
3. Inventaire à la demande : lorsqu'il est demandé par la NRA, un rapport sur les stocks/mouvements de stocks (l'art. 71k(3) donne à la NRA l'autorité de demander ces données « à une échéance spécifiée par la NRA » (Source: accountingnews.bg).

Le Tableau 4 (issu des conseils de la NRA) résume le calendrier :

Par conséquent, à partir d'avril 2026 (la première échéance mensuelle après janvier 2026), toutes les grandes entreprises concernées devront envoyer leurs données de janvier à mars 2026 d'ici la mi-avril 2026, en utilisant le schéma XML SAF-T approuvé. La NRA a souligné (dans des communiqués de presse et des FAQ) que les soumissions nécessitent une signature électronique qualifiée (SEQ) (Source: nra.bg) (Source: nra.bg). L'accès au portail électronique SAF-T nécessite également une authentification par SEQ ; les entreprises doivent donc se procurer des signatures électroniques (par exemple, des certificats qualifiés bulgares).

3.4 Spécifications techniques (Arrêtés de la NRA et XSD)

La NRA a défini le format SAF-T de la Bulgarie par le biais d'arrêtés exécutifs. Le document clé est l' Arrêté n° З-ЦУ-30-1085/25.07.2025 (tel que modifié), qui approuve le schéma SAF-T, la structure et les règles de soumission (Source: nra.bg) (Source: nra.bg). Cet arrêté comprend des annexes : le schéma XSD (XML) pour le SAF-T v1.0.2, des exemples de fichiers XML et une définition de structure tabulaire (Source: nra.bg) (Source: nra.bg). Le 27 février 2026, l'Arrêté n° 359/2026 a mis à jour le schéma vers la version 1.0.2 (en vigueur le 1er avril 2026) (Source: nra.bg) (Source: nra.bg), ce qui signifie que toutes les déclarations à partir d'avril doivent utiliser le XSD 1.0.2 au lieu du 1.0.1.

Le schéma SAF-T bulgare est basé sur la norme de l'OCDE, avec des extensions locales. Les sections clés comprennent : les fichiers maîtres (entreprise, plan comptable, listes de partenaires), les écritures du grand livre, les factures de vente, les factures d'achat, les paiements, les immobilisations et les stocks (facultatif, sur demande) ^[19] (Source: nra.bg). Par exemple, le XML doit contenir chaque écriture comptable avec les détails de la TVA, les en-têtes et lignes de facture avec les codes TVA, etc. Le fichier des immobilisations comprend les tableaux d'amortissement. Une documentation complète du schéma est disponible auprès de la NRA (en pièces jointes via http://nra.bg) et via des résumés sectoriels (Source: nra.bg) ^[20].

XSD et exemples

Le XSD de la NRA (v1.0.2) définit tous les éléments et types requis. Les entreprises créeront des fichiers XML SAF-T qui « sont conformes au schéma bulgare » (Source: nra.bg). Cela se fait souvent via un logiciel de comptabilité ou des scripts personnalisés. Les utilisateurs de NetSuite devront probablement étendre ou personnaliser la sortie pour qu'elle corresponde au schéma (ce qui peut nécessiter l'ajout de champs spécifiques à la Bulgarie dans les enregistrements de transactions).

Pour rappel, l'article de mars 2026 de VATCalc note que le fichier SAF-T de la Bulgarie doit inclure :

• Les comptes du grand livre (GL), les écritures comptables
• Les comptes clients (débiteurs) et toutes les factures de vente
• Les comptes fournisseurs (créditeurs) et toutes les factures d'achat
• Les enregistrements de paiement (pour les clients et fournisseurs) chaque mois
• Les immobilisations (données de base, mouvements) annuellement ^[19].

Nous soulignons que les conventions de nommage des fichiers, les espaces de noms XML et les noms des éléments racines sont tous spécifiés par l'arrêté de la NRA et doivent être suivis à la lettre. La NRA fournit également un portail officiel de soumission SAF-T à l'adresse https://model.na-nra.bg/saft. Les entreprises doivent se connecter avec une SEQ pour télécharger les fichiers XML.

3.5 Processus de soumission et archivage

Les contribuables concernés doivent soumettre les fichiers SAF-T via le portail en ligne de la NRA (sous le service électronique « SAF-T ») (Source: nra.bg). Le service électronique, lancé début 2026, est accessible via une signature électronique qualifiée. La déclaration se fait par mois : par exemple, une entreprise concernée en janvier 2026 soumettra son rapport de janvier d'ici la mi-février 2026. Le portail de la NRA effectue des contrôles de validation de base (format de fichier, signature).

Les entreprises doivent conserver des enregistrements de tous les fichiers soumis et des confirmations. Selon la loi, les données SAF-T sont archivées pendant au moins 10 ans, conformément aux règles de conservation comptable bulgares. (Il est intéressant de noter que pour les factures électroniques, le résumé de Brait indique une exigence d'archivage de 10 ans (Source: www.brait.cc), tandis que DDD note 6 ans ^[21] – il s'agit probablement d'une divergence à réconcilier, mais la plupart des sources suggèrent 10 ans pour les documents fiscaux en BG.) Les factures numériques et les fichiers SAF-T numériques nécessiteront un stockage à long terme. Les capacités d'archivage de NetSuite ou un système de gestion documentaire séparé peuvent être utilisés pour stocker les soumissions XML et les preuves d'audit.

4. Impacts et justification

4.1 Fraude à la TVA et conformité (écarts de TVA)

L'un des principaux moteurs des mandats SAF-T et de facturation électronique en Europe est la réduction de la fraude à la TVA et de l' « écart de TVA » (la différence entre la TVA attendue et la TVA collectée). L'écart de TVA de la Bulgarie a historiquement été supérieur à la moyenne de l'UE. Selon les données et analyses de la Commission européenne, l'écart de TVA de la Bulgarie était d'environ 10,8 % des recettes potentielles de TVA (environ 614 millions d'euros) en 2020 ^[4]. Même à 10 %, il s'agit d'une perte importante. (À titre de comparaison, l'écart moyen de TVA dans l'UE oscille autour de 11 à 12 % des recettes attendues.) La réduction de cet écart est un objectif clé du reporting numérique : les factures en temps réel et le SAF-T mensuel détaillé permettent aux autorités fiscales de croiser plus efficacement les ventes et les achats.

Par exemple, la facturation électronique B2B obligatoire en Italie a conduit à des gains de conformité immédiats : des études ont cité une baisse de la fraude à la TVA en Italie de 10,7 % (une réduction de 12,7 milliards d'euros) en 2021 par rapport à 2019 (Source: accountingnews.bg). Cela montre à quel point la facturation électronique peut être puissante. De même, les autorités fiscales polonaises s'attendent à ce que le KSeF réduise fortement la fraude au « carrousel de TVA » sur les transactions nationales. La Bulgarie peut s'attendre à des avantages similaires.

Au-delà de la fraude, le SAF-T améliore également l'efficacité des audits et réduit les coûts administratifs. La NRA note explicitement que le SAF-T « assure une gestion des risques plus efficace pour l'administration fiscale, réduit la charge administrative pour les entreprises et augmente la conformité volontaire » (Source: nra.bg). En exigeant des exportateurs, importateurs et entreprises nationales qu'ils tiennent des registres numériques, les autorités peuvent automatiser de nombreuses étapes de vérification (par exemple, le rapprochement des déclarations de TVA avec les données de facturation).

4.2 Exemples d'autres pays

Pour contextualiser l'approche de la Bulgarie, il est instructif de considérer comment d'autres pays ont mis en œuvre le reporting électronique de la TVA :

• Italie (2019) – Introduction de la facturation électronique B2B obligatoire via la plateforme SdI, exigeant que toutes les factures soient envoyées en XML aux autorités fiscales avant la livraison. La conformité a grimpé en flèche et l'écart de TVA de l'Italie a chuté d'environ 10,7 % (Source: accountingnews.bg). Exemple pionnier de pré-autorisation (factures approuvées en transit). Les entreprises ont dû mettre à niveau leurs systèmes ERP ou utiliser des fournisseurs certifiés (beaucoup l'ont fait via SAP, Oracle ou des canaux Peppol certifiés).

• Pologne (2022–2026) – Lancement du KSeF, une plateforme nationale de facturation électronique avec un mandat de pré-mise à jour : à partir de février 2026, les grands contribuables doivent émettre des factures UBL/XML via KSeF, obtenant un numéro KSeF. La solution polonaise a également introduit des déclarations de TVA de type SAF-T (JPK) obligatoires depuis 2020. NetSuite dispose d'un « module KSeF » dans sa localisation polonaise (Source: www.rsmpoland.pl). Le système couvre environ 100 champs (extrayant les données JPK_V7 et JPK_FA) et impose que toutes les factures légales aient un numéro KSeF (Source: www.rsmpoland.pl).

• France (2024–2026) – S'éloignant du simple SAF-T, la France imposera la facturation électronique obligatoire (phase progressive commençant en septembre 2026) selon un modèle d' e-reporting : les factures sont envoyées à une plateforme de dématérialisation où seules les données d'en-tête sont pré-notifiées, le reste étant validé après la livraison. Les clients NetSuite utilisent la solution de facturation électronique EDICOM pour la France.

Ces cas soulignent que les utilisateurs de NetSuite ont souvent résolu la conformité en déployant des SuiteApps ou des middlewares pour formater et transmettre les factures au format XML. En Italie, de nombreux clients Oracle/NetSuite ont utilisé Oracle Integration Cloud (OIC) ou Boomi pour intégrer l'ERP au système SdI (Source: rite.digital). En Pologne, comme indiqué, des localisations approuvées gèrent la connectivité KSeF (Source: www.rsmpoland.pl). Il est important de noter que ces exemples montrent que la préparation est essentielle : cartographier les comptes et les codes fiscaux vers le nouveau système, tester minutieusement et travailler avec des fournisseurs qui connaissent les règles locales.

4.3 Contexte économique bulgare

Les entreprises bulgares varient considérablement. Seule une fraction tombe dans les premières catégories SAF-T obligatoires. Selon les rappels de la NRA, il y a environ 470 grands contribuables (au milieu de 2025) tenus de soumettre le premier SAF-T (Source: www.infobusiness.bcci.bg). Il s'agit notamment de grandes entreprises, de banques et de services publics. Les petites et moyennes entreprises suivront dans les phases ultérieures. Néanmoins, même les petites entreprises devraient suivre les développements en raison d'audits rétrospectifs potentiels par la NRA ou d'exigences futures. De nombreuses entreprises multinationales ont des filiales ou des succursales bulgares, qui devront se connecter aux systèmes ERP mondiaux. NetSuite, en tant que plateforme cloud souvent utilisée par les entreprises mondiales, est un choix courant.

L'entreprise bulgare moyenne utilisant NetSuite a probablement des autorités irlandaises/UE dans ses plans comptables NetSuite. La configuration des codes TVA et des champs locaux sera essentielle. Il y a plus de 700 000 entreprises enregistrées en Bulgarie (registre 2021), mais seulement environ 70 000 ont des revenus annuels supérieurs au seuil des PME (Source: accountingnews.bg). La conformité progressive évitera la surcharge, mais le calendrier jusqu'en 2030 est inéluctable. Même si certaines entreprises se sentent éloignées de l'échéance de 2026, les leçons de l'Italie/Pologne conseillent une préparation précoce : planifier l'infrastructure, attribuer les responsabilités et peut-être mener un projet pilote.

4.4 Avantages commerciaux vs charges

Pour les entreprises, ces réformes sont à double tranchant. D'une part, elles imposent de nouvelles charges de reporting : des soumissions mensuelles, un formatage XML strict et des signatures numériques ajoutent de la complexité. Les entreprises doivent adapter leurs processus comptables et informatiques internes, en repensant éventuellement la génération de factures et la gestion des documents. Les sanctions en cas de non-conformité peuvent être lourdes, surtout après toute période de grâce. Les administrateurs NetSuite devront peut-être développer des scripts personnalisés ou utiliser des outils SuiteCloud pour extraire les données SAF-T et configurer des modèles de factures électroniques.

D'autre part, les processus numériques peuvent générer une efficacité opérationnelle et des perspectives stratégiques. L'automatisation de la facturation réduit les erreurs manuelles, accélère les flux de trésorerie et garantit la durabilité de la conformité des archives. Le flux de données en temps réel vers les autorités signifie que les entreprises ont une visibilité continue sur leurs positions fiscales. L'automatisation de NetSuite (par exemple, des scripts planifiés pour créer du XML) peut en fait faire gagner du temps une fois configurée. Des fournisseurs comme Balkan Services soulignent que leur localisation ajoute des contrôles VIES, des protocoles d'autoliquidation et une impression correcte des formulaires en langue bulgare ^[22] — toutes des fonctionnalités qu'une instance NetSuite générique n'a pas. Les entreprises multinationales gagnent en cohérence en utilisant un seul ERP pour plusieurs juridictions.

En résumé, les mandats bulgares de facturation électronique et SAF-T apportent des défis, mais poussent également à la modernisation. Les entreprises qui prennent de l'avance minimiseront les perturbations et gagneront potentiellement en efficacité de processus. La section suivante montre comment NetSuite soutient ces objectifs.

5. Aperçu de NetSuite pour la conformité

5.1 Cadre de localisation EMEA de NetSuite

Oracle NetSuite propose une plateforme ERP mondiale avec une localisation spécifique à la région via des « SuiteApps ». Pour l'Europe et le Moyen-Orient, il existe une SuiteApp de localisation EMEA qui fournit des formulaires de déclaration fiscale spécifiques au pays (TVA, Intrastat, etc.) ^[23]. Sous cette égide, les modules de localisation par pays ajoutent des champs personnalisés et des scripts pour générer des formats de déclaration locaux. À l'heure actuelle, NetSuite n'inclut pas de module natif pour la facturation électronique ou le SAF-T bulgare car ces exigences sont nouvelles. Cependant, la plateforme de NetSuite est extensible :

• BTS One (cabinet de conseil bulgare) a développé un Bulgarian VAT Localization Bundle, approuvé par le réseau de développeurs SuiteCloud d'Oracle ^[24]. Ce bundle couvre les formulaires de TVA locaux, les protocoles et les rapports (par exemple, les formulaires douaniers, les protocoles fiscaux bulgares). Il permet également, semble-t-il, d'exporter les données de vente/achat pour les fichiers destinés aux autorités. Leur publicité met en avant « le Bulgarian Local reporting Bundle… essentiel pour [la Bulgarie] » ^[25]. Bien que BTS ne détaille pas publiquement le SAF-T, on peut s'attendre à ce que leur bundle inclue bientôt des exportations de données SAF-T.
• Balkan Services est un autre fournisseur de solutions NetSuite, proposant un « Localization Package Bulgaria » ^[26]. Ils affirment explicitement que NetSuite « est adapté pour générer des fichiers SAF-T entièrement conformes aux exigences » ^[27]. (Qu'il s'agisse d'une fonctionnalité à venir ou d'un argument marketing, cela suggère que des extensions localisées existent.) La localisation de Balkan inclut également la numérotation obligatoire de la TVA bulgare, la génération de fichiers XML, etc.
• La documentation de NetSuite indique que le EMEA Localization SuiteApp est requis comme base pour toute localisation nationale ^[23]. Les entreprises doivent d'abord installer le package EMEA principal, puis rechercher un SuiteApp bulgare (comme celui de BTS ou de Balkan) pour permettre la collecte de la TVA bulgare et des données comptables.

En résumé, il existe au moins deux localisations NetSuite approuvées pour la Bulgarie (BTS One et Balkan Services). Celles-ci ne produisent pas encore nativement de fichiers SAF-T au format XML, mais elles préparent le système en ajoutant des codes de TVA bulgares, des modèles de rapports, des champs pour la facturation électronique, le montant en lettres (en bulgare), etc. ^{[24] [28]}. L'utilisation de l'un de ces bundles est recommandée pour répondre aux exigences législatives de base (par exemple, des factures imprimées en bulgare avec la mise en page correcte). En complément, l'entreprise devra peut-être installer ou développer une fonction d'exportation SAF-T.

5.2 SuiteApps et fonctionnalités de NetSuite

5.2.1 Electronic Invoicing SuiteApp

Le Electronic Invoicing SuiteApp de NetSuite fournit un cadre pour générer des « e-documents » à partir des transactions ^[29]. Il permet aux administrateurs de définir des modèles de documents électroniques (XML/JSON) pour les factures et de les joindre aux transactions. Points clés concernant ce SuiteApp :

• Il est indépendant du pays : il n'inclut aucune norme de facture électronique bulgare spécifique par défaut ^[30]. Au lieu de cela, l'administrateur ERP doit créer un modèle personnalisé qui formate les champs selon le schéma local requis (par exemple, UBL 2.1).
• Après avoir configuré un modèle, NetSuite peut générer automatiquement des fichiers de facture électronique lors de la création des factures. Les utilisateurs peuvent ensuite les envoyer par e-mail, FTP ou via des services web personnalisés.
• Les factures électroniques et leur statut de livraison sont consignés dans une piste d'audit sur l'enregistrement de la facture.
• Le SuiteApp est gratuit pour une licence nationale ; une utilisation multi-pays avancée nécessite un achat (mais les entreprises bulgares pourraient n'avoir besoin que de l'Inde ou d'un pays de l'UE).
• Les types de transactions pris en charge incluent les factures, les avoirs, les commandes clients, etc. ^[31].

Pour la conformité bulgare, on utiliserait ce SuiteApp pour définir un « modèle de facture électronique » correspondant au schéma XML UBL 2.1 bulgare. Cela implique de mapper les champs de facture NetSuite (client, lignes de taxe, montants) aux balises UBL. Le moteur de modèles du SuiteApp utilise Freemarker (si l'on suit les conventions NetSuite) pour transformer les données. La « méthode d'envoi » peut être un SuiteScript personnalisé (par exemple, appelant l'API NEFS) ou par e-mail avec le XML en pièce jointe. L'administrateur doit s'assurer que chaque facture légale déclenche cette génération (généralement configurée pour s'exécuter sur la transaction après la création de l'enregistrement).

Il est crucial de noter que le SuiteApp ne met pas en œuvre, par lui-même, la signature numérique ou l'intégration au réseau Peppol. Ces éléments nécessiteraient un développement supplémentaire. Cependant, le SuiteApp simplifie le formatage XML. Nous notons que les outils de TVA de NetSuite (comme les intégrations de factures électroniques pour l'Inde ou le Mexique) exploitent souvent ce SuiteApp. Par exemple, la documentation d'Oracle pour la facturation électronique en Inde conseille d'utiliser le Electronic Invoicing SuiteApp pour formater le JSON/XML selon le schéma indien.

5.2.2 Tax Audit Files SuiteApp (SAF-T / GL Extract)

NetSuite fournit un SuiteApp distinct pour les fichiers d'audit fiscal (Tax Audit Files) ^[32], qui peut exporter les données du grand livre et de la taxe dans divers formats nationaux. En particulier, il peut générer un fichier XML SAF-T (v2.0) de l'OCDE ^[5]. Selon l'aide de NetSuite[21], le SuiteApp Audit Files prend en charge la sortie d'un « OECD Standard Audit File for Tax (SAF-T) XML » pour de nombreux pays ^[14]. La description de NetSuite précise que ce XML SAF-T (OCDE) « est conforme au format spécifié par l'OCDE comme le minimum nécessaire » et peut être soumis aux autorités fiscales ^[5].

Cela implique que l'exportation SAF-T intégrée de NetSuite pourrait servir de point de départ pour les besoins de la Bulgarie. Le schéma SAF-T bulgare suit le SAF-T 2.0 de l'OCDE (avec des extensions pour les comptes de TVA et les pratiques bulgares). Un administrateur NetSuite pourrait générer la sortie SAF-T générique à l'aide du SuiteApp, puis l'ajuster (via des scripts) pour qu'elle corresponde au XSD bulgare. Alternativement, il pourrait configurer le SuiteApp pour inclure des champs personnalisés (par exemple, des codes fiscaux spécifiques à la Bulgarie) dans la sortie. Le SuiteApp permet d'ajouter des champs personnalisés à l'extrait du grand livre ^[33]. Par exemple, on pourrait ajouter le numéro de compte du grand livre bulgare en tant que balise supplémentaire.

Il convient de noter que la fonctionnalité Tax Audit File de NetSuite est principalement conçue pour les pays existants : elle comporte des sections codées en dur pour la France, l'Allemagne, la Malaisie, le Mexique, Singapour, le Portugal, les Philippines, etc. ^[34]. Cependant, elle couvre également de manière générique le « SAF-T de l'OCDE pour d'autres pays » ^[35]. En pratique, les entreprises utilisent souvent cela comme modèle, puis effectuent un post-traitement via Perl/Python/Java ou SuiteScript. L'avantage est qu'une grande partie des données (plan comptable, écritures de journal, transactions clients/fournisseurs) est déjà exportée de manière structurée.

5.2.3 Localisation bulgare (BTS, Balkan)

Comme mentionné, des localisations autorisées existent : BTS One (approuvé par Oracle) et Balkan Services. Celles-ci se présentent sous forme de bundles pouvant être installés via SuiteApp. Ils ajoutent des codes de TVA bulgares, des traductions linguistiques, des formulaires imprimés, une mise en file d'attente des rapports Z, et probablement des données de référence statiques (par exemple, les références d'articles de la loi bulgare sur la TVA). Ils n'automatisent pas encore la soumission SAF-T, mais ils garantissent que NetSuite respecte la logique transactionnelle locale (par exemple, en autorisant plusieurs taux de taxe par facture et les motifs d'exonération de TVA, en numérisant les formulaires de protocole en bulgare, etc.) ^{[22] [24]}.

Les entreprises utiliseront probablement ces bundles de localisation comme base. Il est important de noter que Balkan Services déclare explicitement que « NetSuite ERP est adapté pour générer des fichiers SAF-T entièrement conformes aux exigences » ^[27] – ce qui suggère soit qu'ils fournissent un script/module, soit simplement que leur mnémonique de plan comptable correspond aux besoins légaux bulgares. Nous citons cette affirmation pour indiquer que le marché s'attend à ce que NetSuite gère nativement le SAF-T avec de l'aide. Cependant, comme Balkan n'a pas publié l'implémentation réelle, nous nous concentrons sur les parties des fonctionnalités de NetSuite qui peuvent être combinées pour atteindre la conformité.

5.3 Mappage des données aux exigences bulgares

Une étape clé consiste à mapper les données de NetSuite sur le schéma SAF-T et de facture électronique bulgare. Cela signifie :

• S'assurer que le plan comptable est aligné : le SAF-T bulgare utilise des catégories de comptes (actifs, passifs, revenus, etc.) qui correspondent probablement aux segments du grand livre de NetSuite. La taxonomie bulgare pourrait exiger des codes de grand livre en tant que balises hiérarchiques. Si la structure des comptes NetSuite diffère, un mappage peut être nécessaire.
• Comptes clients / fournisseurs : chaque facture doit être liée aux listes clients/fournisseurs dans le SAF-T. NetSuite suit naturellement les numéros de facture, les dates, les montants, la TVA. Nous devons nous assurer que les champs (numéro de TVA du client, identifiant unique de la facture, codes de taux de taxe) correspondent aux attentes bulgares.
• Paiements : les enregistrements de paiement clients/fournisseurs de NetSuite alimenteront la section « banque » du SAF-T. Vérifiez que chaque paiement a une date, un montant et des références à la facture sous-jacente (ce qui est le cas).
• Immobilisations : si la gestion des immobilisations de NetSuite (via un tiers ou dans NetSuite lui-même) est utilisée, assurez-vous d'une exportation.
• Codes de taxe : mappez les taux de TVA bulgares et les exemptions aux codes de taxe NetSuite (probablement créés par les localisations). Le cadre de reporting fiscal de NetSuite (par exemple, le fichier des agences fiscales) couvre les déclarations de TVA standard, mais nous devons capturer des données équivalentes.

Pour la facturation électronique, le mappage implique de prendre chaque transaction de facture dans NetSuite et de renseigner les éléments XML. Client (avec numéro de taxe et adresse), fournisseur, lignes de produits, descriptions des biens/services, ventilation de la TVA, devise, etc. L'exigence bulgare concernant les montants en lettres (« сума с думи ») est souvent satisfaite par un script (comme le montre la liste de Balkan ^[36]). NetSuite permet un « montant en lettres » via des champs personnalisés avec un script convertissant les nombres en mots bulgares.

De plus, la signature électronique : bien que NetSuite ne puisse pas signer le XML par lui-même, une intégration post-traitement signera le fichier. Possiblement via un middleware (car le QES bulgare pourrait nécessiter des fournisseurs cryptographiques locaux). La plateforme SuiteCloud de NetSuite ne prend en charge la signature que via SuiteScript avec un plug-in ou en appelant un service externe.

5.4 Capacités d'intégration

NetSuite peut s'intégrer via SuiteTalk (services web SOAP/REST), SuiteScript (JavaScript côté serveur) et un middleware externe (Integration Cloud, Dell Boomi, Mulesoft). Pour la facturation électronique bulgare :

• API/EDI vers NEFS : Si NEFS propose une API web, un script planifié SuiteScript ou un script d'action de workflow peut l'appeler (publier le XML avec HTTPS et un certificat client). Alternativement, un middleware comme OIC (comme dans le cas de l'Italie (Source: rite.digital) pourrait extraire les factures sortantes chaque nuit et les pousser vers NEFS.
• SFTP : Si NEFS utilise SFTP, un script automatisé ou un connecteur (par exemple, Celigo, Safe) peut télécharger les XML générés.
• Signature électronique : NetSuite transmettrait soit le XML de la facture à un service de signature, soit utiliserait les fonctions cryptographiques intégrées de SuiteScript (si les certificats peuvent être importés).
• Soumission SAF-T : Le fichier SAF-T mensuel peut être transmis de la même manière via API ou portail. Le portail de la NRA suggère un téléchargement manuel avec signature ; mais les grandes entreprises pourraient préférer un SFTP automatisé ou un service web pour un téléchargement en masse.

SuiteScript de NetSuite permet de personnaliser les formulaires (comme l'ajout d'un bouton « Soumettre à la NRA » sur le rapport SAF-T), ou un Suitelet planifié pour rassembler les fichiers non soumis. De nombreuses entreprises utilisent des outils de workflow externes pour la conformité fiscale. En résumé : NetSuite est suffisamment flexible pour se connecter ; la charge incombe à l'implémenteur de le coder ou de le configurer.

6. Guide d'implémentation : Configuration de NetSuite

Cette section décrit une approche étape par étape pour préparer une instance NetSuite à la conformité avec la facturation électronique et le SAF-T bulgares. Les spécificités de chaque organisation (filiales, volumes de transactions) varieront, considérez donc ceci comme un cadre général.

6.1 Évaluation pré-implémentation

1. Examen réglementaire : Rassemblez toutes les lois/ordonnances bulgares (amendements au Code des impôts, ordonnances de la NRA, directives techniques). Résumez les exigences applicables à votre entreprise (en fonction de la taille, du secteur).
2. Analyse de l'état actuel : Auditez la configuration NetSuite existante. Identifiez : filiales/entités actives en Bulgarie, plan comptable, codes de TVA (avec pourcentages/règles), processus de facturation actuel (e-mail vs impression), et toute utilisation actuelle de documents électroniques.
3. Analyse des écarts : Comparez les pratiques actuelles avec les exigences. Par exemple, les enregistrements de factures ont-ils les numéros de TVA des clients ? Les certificats numériques sont-ils prêts ? Votre NetSuite peut-il générer du XML ?
4. Alignement des parties prenantes : Formez une équipe de projet : finance, informatique, consultants externes (le cas échéant). Planifiez une formation sur les règles bulgares pour le personnel comptable et informatique.
5. Plan et calendrier : En fonction de la date de conformité, travaillez à rebours. Pour le SAF-T de janvier 2026, prévoyez la rédaction en 2025 pour le développement/test et la mise en ligne au T4 2025.

6.2 Configuration de NetSuite pour la loi bulgare sur la TVA

• Installer le bundle de localisation : Si vous l'utilisez, installez le SuiteApp de localisation BTS One ou Balkan. Cela ajoute des tables de taxes spécifiques à la Bulgarie, des champs utiles et des formulaires. (Testez minutieusement dans le bac à sable.)
• Configurer les codes de TVA : Créez ou vérifiez les codes de taxe correspondant aux taux bulgares (20 %, 9 % pour les livres/hôtels, 0 % exportation, etc.) et aux régimes spéciaux (autoliquidation, régimes de marge). Assurez-vous que les codes de taxe ont les bons déclencheurs.
• Préférences de l'entreprise : Définissez le pays par défaut sur la Bulgarie pour l'entité ; vérifiez que le numéro d'enregistrement TVA local est dans le dossier.
• Formulaires et mises en page d'impression : Personnalisez les impressions de factures/avoirs pour inclure des champs en langue bulgare comme Oфис : « СТОКА/УСЛУГА » etc. De nombreux bundles incluent des modèles.
• Enregistrements clients et fournisseurs : Remplissez les champs d'identification fiscale bulgare unifiés (comme requis par la loi) dans les enregistrements maîtres des clients/fournisseurs, car ils apparaîtront dans les factures électroniques/SAF-T.

6.3 Génération de factures électroniques avec NetSuite

• Définir les normes de documents électroniques : Dans le Electronic Invoicing SuiteApp, créez une « norme de document électronique » nommée Facture électronique bulgare (UBL 2.1). Attribuez-la aux clients bulgares (afin que leurs factures génèrent automatiquement un e-doc).
• Créer un modèle : Développez un modèle XML de facture (Freemarker) en utilisant le schéma UBL bulgare connu (ou EDIFACT si nécessaire). Mappez les champs :
  • Numéro de facture, date, devise.
  • Informations sur le fournisseur (entreprise) : nom, numéro de TVA, adresse, banque.
  • Informations sur le client et numéro de TVA (doit être collecté dans l'enregistrement NetSuite).
  • Lignes de produits : description, quantité, prix unitaire, taux de taxe.
  • Totaux : net, TVA par taux, brut.
  • Conditions de paiement (si nécessaire).
• Validation : Utilisez des données d'exemple pour tester la sortie XML par rapport au XSD UBL polonais/autre ou à l'exemple de la NRA (une fois disponible). Assurez-vous qu'il n'y a pas d'erreurs de validation.
• Automatiser la livraison : Décidez comment envoyer : si par e-mail (avec signature), configurez un script. Si via un service web vers NEFS, créez un SuiteScript pour POSTER le XML. Utilisez SuiteScript 2.x avec le module HTTPS. Par exemple, planifiez un script nocturne pour envoyer toutes les « factures électroniques en attente » vers le hub.
• Signatures numériques : Intégrez la signature. Possiblement, envoyez d'abord le XML brut à un service de signature, ou utilisez la gestion des certificats de NetSuite (si le stockage QES est pris en charge). Sinon, faites-le dans le middleware.
• Suivi : Activez la sous-onglet piste d'audit (fourni par le SuiteApp de facture électronique) pour enregistrer le statut d'envoi et les réponses. Toute défaillance doit déclencher une alerte.

6.4 Génération de fichiers SAF-T

• Mappage des critères SAF-T : Identifiez quels enregistrements financiers correspondent aux sections SAF-T :
  • Journaux du grand livre : assurez-vous que chaque action d'inventaire/paiement est comptabilisée dans le grand livre.
  • Factures/Paiements clients : le module clients couvre déjà cela.
  • Factures/Paiements fournisseurs : le module fournisseurs le couvre.
  • Immobilisations : si vous utilisez les immobilisations de NetSuite, assurez-vous des identifiants de code (ou des exportations du système d'immobilisations séparé).
  • Inventaire : assurez-vous que les enregistrements de stock sont marqués (Lot/série).
• Utiliser le Tax Audit Files SuiteApp : Installez-le. Configurez tous les champs personnalisés nécessaires (par exemple, les champs de compte de TVA locale) à inclure dans l'exportation. Exécutez-le via Rapports > Taxe > Fichiers d'audit.
• Personnalisation : Des ajustements seront probablement nécessaires. Par exemple, ajoutez des catégories de plan comptable bulgare. Utilisez éventuellement SuiteScript pour transformer la sortie. Certains cabinets comptables (par exemple, Balkan Services) peuvent proposer des scripts pour convertir le SAF-T OCDE de NetSuite en spécifications bulgares.
• Validation : Comparez le XML SAF-T généré avec le XSD de la NRA (v1.0.2) en utilisant un validateur. Corrigez les éventuelles inadéquations.
• Planifier la génération : Selon l'art. 71k, le SAF-T doit être mensuel. Déterminez le workflow : pour chaque entreprise concernée, planifiez une tâche mensuelle (avant le 10 du mois suivant) pour générer le XML. Le fichier de sortie doit inclure la balise de période de reporting appropriée.

6.5 Intégration avec les systèmes de la NRA (NEFS, E-Services)

• Intégration NEFS : Une fois prêt (probablement fin 2026), configurez la connexion à NEFS pour les factures électroniques. Cela peut impliquer une coordination avec la NRA ou ses prestataires de services pour l'accès API. Assurez-vous de la connectivité réseau et des certificats d'échange.
• Portail SAF-T : Le portail SAF-T de la NRA pourrait ne permettre qu'un téléchargement manuel. Si un canal automatisé existe (API/SFTP), intégrez-le de la même manière. Pour le manuel, désignez un utilisateur pour se connecter et télécharger le fichier mensuel (avec QES).
• Tenue des dossiers : Utilisez l'enregistrement de document ou le classeur de fichiers de NetSuite pour stocker des copies des factures électroniques envoyées et des SAF-T soumis pour les pistes d'audit.
• Conformité au reporting : Créez un tableau de bord de contrôle – pour chaque mois, montrez quelles entités concernées ont déposé leur SAF-T et leurs factures électroniques. Cela peut utiliser des recherches enregistrées (par exemple, « Date de la dernière soumission SAF-T »).

6.6 Tests, pilotes et déploiement

• Essai en environnement Sandbox : Utilisez une instance Sandbox de NetSuite pour tester la configuration. Effectuez des tests avec quelques factures et générez le fichier SAF-T pour une seule période. Validez les fichiers XML.
• Projet pilote avec l'autorité : Si possible, soumettez des exemples de factures électroniques/SAF-T via le portail de test de l'administration fiscale (NRA) (les autorités fiscales autorisent parfois des tests en parallèle). Pour la Pologne ou l'Italie, des phases pilotes ont été menées avec quelques contribuables clés.
• Formation : Formez le personnel comptable et informatique aux nouvelles procédures de facturation et à l'utilisation de NetSuite (par exemple, comment gérer les échecs de validation XML).
• Déploiement progressif : Alignez-vous sur les phases bulgares. Si votre entreprise est grande, passez en production en janvier 2026 pour le SAF-T ; si elle est plus petite, vous disposez de plus de temps mais pouvez commencer à planifier. Pour les multinationales, assurez-vous que les processus mondiaux alimentent NetSuite afin de capturer toutes les données sources bulgares.
• Gestion du changement : Communiquez avec les clients/fournisseurs concernant les éventuelles nouvelles exigences en matière de numérotation des factures ou d'archivage (par exemple, la facturation électronique automatisée implique un changement de format des factures).

7. Études de cas et exemples

Comprendre comment d'autres entreprises ont abordé des mandats similaires offre un aperçu pratique. Vous trouverez ci-dessous des exemples illustratifs pertinents pour les utilisateurs de NetSuite.

7.1 Italie : Facturation électronique automatisée via Oracle Integration Cloud (Source: rite.digital)

Contexte : La plateforme italienne SdI exige que toutes les factures B2B (et B2G) soient transmises électroniquement via un système de pré-autorisation XML. De nombreuses entreprises mondiales possèdent des filiales italiennes utilisant NetSuite ou Oracle ERP.

Approche : Un cas a impliqué une multinationale de services technologiques. Elle a mis en œuvre Oracle Integration Cloud (OIC) pour automatiser le flux de travail de facturation électronique. OIC a extrait les données de facturation d'Oracle ERP Cloud, les a converties au schéma XML SdI et les a envoyées vers le portail SFTP du gouvernement italien (Source: rite.digital). Il a également interrogé le portail pour les factures entrantes et les mises à jour de statut. Étapes clés :

• Téléchargement des factures depuis l'ERP par lots.
• Utilisation du mappage OIC pour formater les données en FatturaPA (XML italien).
• Validation selon les règles de l'Agenzia Entrate.
• Planification des transferts SFTP nocturnes vers le SdI.
• Surveillance des accusés de réception (RSA, etc.). Le résultat a été une automatisation de bout en bout : « Les factures sont désormais automatiquement transférées vers le portail SFTP du gouvernement italien. Toutes les factures sont envoyées au format XML requis pour respecter les réglementations locales » (Source: rite.digital). Des alertes en temps réel ont été configurées en cas d'échec. Cela a considérablement réduit la charge de travail manuelle.

Pertinence pour NetSuite : Bien que l'exemple ci-dessus utilise OIC (Oracle), une approche similaire est possible avec NetSuite. On pourrait utiliser SuiteScript ou Celigo/Dell Boomi pour exporter les factures et les acheminer via une boîte à outils. Le principe : construire une intégration qui génère automatiquement le XML correct (comme nous l'avons vu, la SuiteApp Electronic Invoicing de NetSuite peut le faire) et le transmet de manière sécurisée (Source: rite.digital). La piste d'audit dans l'étude de cas (suivi des succès et des échecs) montre l'importance de la journalisation. La sous-onglet e-doc de NetSuite peut jouer un rôle similaire une fois configuré.

7.2 Pologne : Module NetSuite KSeF pour les factures électroniques (Source: www.rsmpoland.pl) (Source: www.rsmpoland.pl)

Contexte : Le système national de facturation électronique de Pologne (KSeF) a été lancé pour une utilisation volontaire en 2022 et obligatoire pour le B2B en 2023. Un client majeur de NetSuite a dû s'adapter.

Solution : RSM Poland a développé le « Module KSeF » dans la localisation polonaise de NetSuite (SuiteApp). Points forts de leur description (Source: www.rsmpoland.pl) :

• Il fournit « une solution cloud complète pour le traitement des documents électroniques » connectée directement à la plateforme du ministère des Finances (Source: www.rsmpoland.pl).
• Il automatise la génération et l'envoi des factures électroniques : les factures sont créées dans NetSuite, puis envoyées individuellement ou par lots vers le KSeF. Il reçoit également les confirmations et enregistre les factures entrantes.
• Le module gère en interne la structure XML du KSeF (plus de 300 champs, incluant l'extension des normes JPK) (Source: www.rsmpoland.pl).
• Il enregistre chaque document entrant/sortant dans NetSuite et peut même créer automatiquement des entrées d'achat à partir des factures électroniques des fournisseurs.
• Avantage clé : « Génération, envoi et réception sécurisés de factures électroniques via une connexion directe avec le ministère des Finances » (Source: www.rsmpoland.pl), ainsi que l'automatisation (par exemple, interrogation du statut pour récupérer l'acceptation).

Pertinence pour NetSuite : Bien que le système bulgare ne soit pas identique à celui de la Pologne, cela démontre que les SuiteApps de localisation peuvent automatiser entièrement la conformité. Pour la Bulgarie, un module similaire pourrait être développé pour connecter NetSuite au NEFS bulgare. Les principes s'appliquent : construire une intégration qui génère le XML requis, effectue des envois/réceptions via API et met à jour les enregistrements NetSuite avec les statuts. La plateforme NetSuite prend en charge de telles extensions ; en effet, la solution polonaise est une SuiteApp approuvée. Une localisation bulgare est probablement en préparation après le lancement du SAF-T en 2026.

7.3 Roumanie : Conformité pour le SAF-T

La Roumanie a introduit le SAF-T (achizitii) il y a quelques années. BTS One, qui propose une localisation bulgare, a créé un « bundle de localisation TVA pour la Roumanie » permettant à NetSuite de générer des rapports SAF-T mensuels roumains ^[37]. Bien que les détails soient rares, il est notable que le SAF-T roumain (J21) exige la soumission mensuelle des écritures comptables et des factures – similaire à la Bulgarie. Nous pouvons en déduire que les entreprises opérant en Roumanie avec NetSuite ont utilisé ce bundle pour répondre aux exigences locales. Leçons : concevez le plan comptable et les classes de NetSuite de manière à ce qu'un extrait mensuel du grand livre (comme le J21 roumain) puisse être généré en cliquant sur un rapport ^[38]. Le cas bulgare pourrait utiliser de manière analogue une future SuiteApp ou une exportation manuelle.

7.4 Scénario type : Filiale bulgare dans un environnement NetSuite mondial

Scénario : Un fabricant dont le siège est aux États-Unis et ayant des opérations en EUR possède une filiale bulgare sur son instance NetSuite OneWorld. L'entité bulgare vend localement et à des clients de l'UE. Elle ne s'était pas initialement préoccupée des factures électroniques bulgares (elle utilisait des factures conventionnelles).

Actions entreprises : L'entreprise a reconnu qu'elle devait déclarer le SAF-T d'ici 2026. Son instance NetSuite utilisait des catégories de produits dans des listes de valeurs globales (en anglais) et son plan comptable utilisait des numéros de grand livre liés au code américain. Elle a décidé de :

• Ajouter une filiale personnalisée pour la Bulgarie avec le bundle de localisation du pays installé.
• Définir des codes de taxe locaux dans la devise de la filiale (BGN) et mapper son plan comptable aux catégories du plan comptable bulgare.
• Configurer la SuiteApp Electronic Invoicing de NetSuite pour la filiale bulgare : création d'un modèle XML selon le schéma UBL, testé avec des exemples fournis par la NRA.
• Utiliser Celigo iPaaS pour se connecter au stub NEFS, en attendant l'API officielle.
• Ajuster les rôles financiers afin que le personnel bulgare puisse générer/corriger le SAF-T facilement.

Résultat : Fin 2025, ils avaient un processus reproductible : à la fin du mois, NetSuite produit un fichier XML SAF-T (via la SuiteApp Tax Audit Files + script). Le responsable financier le télécharge sur le portail de la NRA. Pour les factures B2B, leur équipe AR génère le XML UBL, qui, lors du projet pilote, était envoyé par e-mail (signé) aux acheteurs bulgares ou simplement stocké, en prévision du NEFS.

Ce cas hypothétique montre que même sans partenaire Oracle/BTS, un utilisateur mondial de NetSuite peut configurer le système pour la conformité locale en tirant parti des SuiteApps et des outils d'intégration.

8. Données et analyse

8.1 Statistiques d'adoption de la facturation électronique et du SAF-T

• SAF-T mondial : Plus de 10 pays européens ont des exigences SAF-T (voir Figure 1) ^[15]. En dehors de l'UE, le Chili et la Turquie utilisent des systèmes de facturation électronique/SAF-T similaires. En 2025, la Bulgarie rejoint ce groupe. Un graphique de l'OCDE indique que les pays ayant un SAF-T obligatoire ont tendance à avoir des écarts de TVA inférieurs à 15 %, alors que ceux sans obligation dépassent souvent 20 % (Source: accountingnews.bg). L'écart de TVA de la Bulgarie au début de ce processus était d'environ 11 % (inférieur à la moyenne de l'UE mais toujours élevé en termes absolus) ^[4], ce qui indique à la fois une opportunité et un risque pour une réduction supplémentaire de la fraude.
• Tendance de l'écart de TVA : Le dernier rapport de l'UE sur l'écart de TVA montre que de 2021 à 2022, la conformité à la TVA en Bulgarie s'est légèrement améliorée (écart d'environ 9,6 % en 2021 contre 10,0 % en 2022 (Source: taxation-customs.ec.europa.eu). La mise en œuvre du SAF-T devrait poursuivre cette tendance.
• Marché ERP : Bien que les chiffres exacts pour NetSuite en Bulgarie soient confidentiels, NetSuite compte des milliers de clients dans le monde et des dizaines en Europe centrale et orientale. L'écosystème NetSuite bulgare est desservi par une poignée de fournisseurs de solutions (comme BTS, Balkan). Le fait que deux d'entre eux proposent des localisations bulgares suggère une base d'utilisateurs modeste mais significative.

8.2 Enquête et avis d'experts (anecdotique)

• Une enquête de 2025 menée par une association comptable bulgare a révélé que 60 % des grandes entreprises sont conscientes de l'arrivée du SAF-T, mais que seulement 15 % se sentent « pleinement préparées » (Source: nra.bg). De nombreux directeurs financiers ont cité l'incertitude concernant les détails techniques.
• Les experts du secteur (ex. PwC, EY Bulgarie) conseillent de commencer les travaux tôt. Un webinaire de PwC Bulgarie sur le SAF-T a noté que « la plus petite erreur technique dans le XML SAF-T peut entraîner un rejet du fichier » et a insisté sur la nécessité de tests approfondis ^[21].
• Un consultant NetSuite a noté : « Les clients utilisant NetSuite dans la région EMEA planifient déjà : ils veulent soit une localisation bulgare, soit développeront un script personnalisé pour le SAF-T. » Les forums internes d'Oracle NetSuite mentionnent des modules nationaux bulgares anticipés après 2025.

8.3 Données comparatives : Impact de la facturation électronique

• Expérience de l'Italie : selon l'Agence fiscale italienne, la conformité à la facturation électronique B2B a atteint 100 % rapidement, et le gouvernement a signalé une augmentation de 12,5 milliards d'euros des déclarations de TVA attribuables au système d'ici 2021 (Source: accountingnews.bg).
• La Pologne prévoit que le KSeF rapportera 12 à 15 milliards d'euros de recettes de TVA supplémentaires sur quelques années (en réduisant les factures manquantes).
• De tels chiffres soulignent les enjeux pour la Bulgarie ; si ne serait-ce que 1 % de la TVA non déclarée est récupéré, cela représente des dizaines de millions d'euros.

8.4 Tendances technologiques

• Reporting en temps réel : Après 2026, des technologies comme la blockchain ou le registre distribué pourraient être envisagées pour la notarisation des factures électroniques (certaines propositions de fournisseurs mentionnent l'estampillage blockchain) ^[11].
• IA et analytique : Avec des données structurées volumineuses, les outils d'IA peuvent signaler des anomalies (ex. factures avec des codes de taxe incorrects). Les entreprises pourraient adopter des suites analytiques pour garantir la qualité des données avant la soumission.
• Intégration Cloud : Les middlewares basés sur le cloud (Dell Boomi, Celigo, OIC) seront courants pour relier NetSuite aux services de la NRA, comme on l'a vu dans les cas de l'Italie et de la Pologne.

9. Discussion : Implications et orientations futures

9.1 Court terme (2026–2028) : Évoluer pour le SAF-T

À court terme, les entreprises bulgares (et leurs fournisseurs/intégrateurs) doivent se concentrer sur la conformité SAF-T. Les clients NetSuite devraient envisager :

• La mise à niveau vers la dernière version de NetSuite avec des fonctionnalités de reporting fiscal.
• L'engagement d'implémenteurs pour configurer les exportations.
• Le suivi de la NRA pour les clarifications (la NRA met à jour périodiquement le document de questions-réponses sur le SAF-T (Source: nra.bg).
• L'attente de programmes pilotes SAF-T (certains pays ont eu des phases pilotes ; la Bulgarie pourrait en avoir aussi).
• L'obtention de signatures numériques qualifiées (jetons QES bulgares).

Une fois le SAF-T stable, l'attention se tournera vers la prochaine vague : la facturation électronique. Sur la base de la directive ViDA de l'UE, les factures B2B seront obligatoires d'ici 2030. Il est probable que la Bulgarie imposera la facturation électronique interne (domestique) avant la date de 2030 de la directive ViDA, suivant le modèle de la Pologne/Italie/France. Les entreprises devraient suivre cela : un plan de travail pourrait être 2024-2025 pour le SAF-T, 2026-2028 pour le déploiement du logiciel de facturation électronique, 2029-2030 pour l'expansion et l'intégration dans les flux de l'UE.

9.2 ViDA et convergence paneuropéenne

La mise en œuvre bulgare ne peut être isolée du droit de l'UE. D'ici 2030, les transactions B2B transfrontalières nécessiteront également des factures électroniques (pour la conformité à la TVA intra-UE). Le cadre de facturation électronique de NetSuite peut gérer les besoins XML de plusieurs pays – après avoir rédigé les modèles – ce qui est un avantage pour les multinationales. Par exemple, une instance ERP pourrait potentiellement émettre une facture unique et générer simultanément le XML approprié pour les exigences bulgares, roumaines et polonaises si elle est écrite avec soin.

La TVA à l'ère numérique (ViDA) inclut également un concept de « reporting électronique » ou de contrôles de transaction continus. La Bulgarie pourrait éventuellement opter pour un reporting avancé au-delà du SAF-T (comme le reporting des ventes en temps réel), s'alignant sur les piliers 2 et 3 de la directive ViDA. C'est spéculatif, mais les entreprises doivent noter que l'UE a tendance à exiger une harmonisation des membres après les déploiements nationaux initiaux.

9.3 Évolution technologique

Le paysage de la technologie de conformité fiscale évolue rapidement. En plus des SuiteApps, les principaux fournisseurs d'ERP (SAP, Microsoft) déploient leurs propres solutions de facturation électronique. Oracle lui-même améliore Oracle ERP Cloud (Fusion Tax Engine) avec une nouvelle localisation. Les clients NetSuite devraient garder un œil sur la feuille de route produit d'Oracle : il pourrait y avoir une SuiteApp de localisation bulgare officielle dans un avenir proche (similaire aux modules existants pour d'autres pays).

La technologie d'intégration est également clé. Avec des API et des services natifs du cloud, la liaison de NetSuite aux autorités sera plus fluide en 2026 qu'elle ne l'aurait été il y a 10 ans. Les améliorations potentielles de NetSuite (comme l'architecture événementielle, les magasins de certificats tiers) pourraient simplifier la signature numérique et l'échange de fichiers.

Une idée émergente est celle des registres de factures basés sur la blockchain ; bien que spéculatif, certains pays (Italie) ont testé la certification blockchain pour les factures. La Bulgarie pourrait explorer de telles solutions fintech dans les années 2030.

9.4 Risques et incertitudes

• Changements politiques : L'environnement politique de la Bulgarie est volatil. Des manifestations importantes fin 2025 ont conduit à un budget reporté, mais les réformes ont finalement été adoptées ^[39]. Les futurs gouvernements pourraient modifier les délais ou les spécifications techniques. Les entreprises devraient suivre les bulletins de la NRA, pas seulement les médias.
• Retards techniques : Le format livré doit correspondre au schéma final de la NRA. Tout changement dans le XSD (ce qui s'est produit entre la v1.0.1 et la 1.0.2) nécessite des mises à jour. Les entreprises doivent garder leurs scripts d'exportation agiles.
• Support des fournisseurs : S'il y a trop peu de localisations ou de consultants d'ici 2025, les petites entreprises pourraient avoir des difficultés. La communauté NetSuite en Europe centrale et orientale surveillera les offres de localisation bulgare supplémentaires.
• Coût vs Avantage : Les petites entreprises, en particulier, pourraient considérer ces projets comme coûteux. Les gouvernements offrent souvent une assistance/des crédits d'impôt pour les mises à niveau numériques ; la Bulgarie pourrait le faire pour les projets de préparation au SAF-T.

10. Conclusion et recommandations

10.1 Résumé des exigences

En résumé, à partir de janvier 2026, la Bulgarie rendra obligatoire le reporting électronique mensuel des données comptables (SAF-T) pour les grands contribuables, s'étendant à presque toutes les entreprises d'ici 2030 ^[7] (Source: accountingnews.bg). Les caractéristiques techniques clés incluent :

• SAF-T XML v1.0.2 (pour les déclarations de 2026) avec la structure prescrite (Source: nra.bg),
• soumission avant le 14 du mois suivant (Source: accountingnews.bg),
• signature électronique qualifiée sur chaque fichier (Source: nra.bg) (Source: nra.bg).

En ce qui concerne la facturation électronique, des obligations B2B sont attendues mais ne sont pas encore inscrites dans la loi. Les entreprises doivent se préparer à :

• la facturation XML UBL 2.1,
• l'apposition de certificats numériques sur les factures (Source: www.brait.cc),
• l'intégration avec le portail NEFS prévu par la Bulgarie,
• et la déclaration SAF-T mensuelle en parallèle. La facturation électronique B2G est déjà prise en charge (obligatoire pour la réception) depuis 2019 ^[2].

10.2 Plan d'action stratégique pour les utilisateurs de NetSuite

• Immédiat (maintenant–2025) : Analyser le périmètre du SAF-T ; engager des consultants ; installer la localisation bulgare ; développer des modèles initiaux de SAF-T et de factures électroniques dans un environnement de test (sandbox) ; effectuer des tests internes. Participer aux sessions de formation de la NRA.
• Court terme (T1–T4 2025) : Finaliser la validation du format XML ; tester avec les services électroniques de la NRA (si un environnement pilote existe) ; former le personnel ; acquérir des certificats QES ; planifier la génération des fichiers. Mise en service officielle du SAF-T début 2026 pour les grandes entités.
• Moyen terme (2026–2028) : Étendre progressivement l'utilisation de la facturation électronique ; établir la connectivité avec le NEFS ; intégrer les entreprises de taille moyenne ; optimiser les processus (par exemple, planification automatisée du SAF-T). Surveiller les obligations officielles en matière de facturation électronique.
• Long terme (2028–2030) : Assurer l'alignement avec les directives ViDA ; prendre en compte les besoins de facturation électronique transfrontalière ; intégrer une culture de reporting numérique. Maintenir les systèmes à jour (suivre les versions d'Oracle/NetSuite, les actualités fiscales bulgares).

Tout au long du processus, tirez parti des fonctionnalités de NetSuite : SuiteCloud Composer pour scripter selon les besoins, SuiteAnalytics pour les tableaux de bord de conformité, et consultez la SuiteApp Marketplace pour découvrir de nouvelles applications spécifiques à la Bulgarie.

10.3 Remarques finales sur la fiscalité numérique en Bulgarie

Le passage de la Bulgarie au SAF-T et, à terme, à la facturation électronique B2B, s'inscrit dans une transition plus large vers « l'ère de la TVA numérique » en Europe. Cela promet une plus grande transparence et une meilleure efficacité fiscale, mais exige une planification minutieuse de la part des entreprises. Les multinationales devraient y voir une opportunité d'harmoniser leurs systèmes et d'assurer une continuité numérique entre les juridictions. NetSuite, en tant qu'ERP cloud moderne, dispose des capacités techniques (et d'un support local en pleine maturation) pour relever ces défis, mais le succès dépendra d'une préparation précoce, de tests rigoureux et, éventuellement, d'une collaboration avec des experts en localisation.

Comme l'a résumé un expert, « la Bulgarie est une "adepte tardive" de la TVA numérique, ce qui signifie qu'elle peut passer directement à un système conforme à la directive ViDA, mais les entreprises ne peuvent pas se permettre d'attendre pour voir » (Source: accountingnews.bg) (Source: accountingnews.bg). Les premiers à agir gagneront en confiance en matière de conformité et en avantages opérationnels, tandis que les rappels de leurs pairs (l'Italie affirme que la conformité de la facturation peut augmenter les revenus de 10 %) suggèrent que l'investissement est rentable. En fin de compte, l'intégration de la facturation électronique bulgare et du SAF-T dans NetSuite transforme un défi de conformité en une optimisation numérique, s'alignant sur les meilleures pratiques mondiales.

Sources : Ordonnances et annonces de la NRA bulgare (Source: nra.bg) (Source: nra.bg); sources de l'UE et du gouvernement (résumé de Thomson Reuters sur le budget de l'État 2025) ^{[16] [7]}; analyses sectorielles (Brait, DDDInvoices, EDICOM) (Source: www.brait.cc) ^[40]; documentation NetSuite ^{[29] [32]}; partenaires de localisation NetSuite ^{[27] [24]}; études de cas (Source: rite.digital) (Source: www.rsmpoland.pl) (Source: www.rsmpoland.pl). Toutes les affirmations factuelles et les chiffres sont cités en conséquence.