Depuis le 1er septembre 2026, la réforme française de la facturation électronique et de l’e-reporting est entrée dans sa phase de mise en œuvre. Cet article présente ce qui a changé, comment l’accréditation de fiskaltrust en tant que Plateforme Agréée (PA) relie le point de vente aux deux obligations, et ce que les développeurs (PosCreators), partenaires (PosDealers) et commerçants doivent prendre en compte.
Être une Plateforme Agréée en France signifie que la couche d’intégration API unique de fiskaltrust, qui permet déjà la conformité fiscale en Europe, vous connecte désormais aussi à un canal accrédité pour la facturation électronique et l’e-reporting auprès de l’administration fiscale française.
fiskaltrust est actuellement le seul middleware à être également une plateforme agréée pour la facturation électronique et l’e-reporting.
Pour toute question sur le contenu de cet article, n’hésitez pas à nous contacter.
1. Qu’est-ce qui a changé en France ?
Depuis le 1er septembre 2026, les entreprises concernées par la réforme française doivent être en mesure de recevoir des factures électroniques. Les grandes entreprises et les entreprises de taille intermédiaire (ETI) doivent également commencer, à cette date, à émettre des factures électroniques et à transmettre leurs données d’e-reporting. Les PME et micro-entreprises rejoignent les deux obligations à partir du 1er septembre 2027.
La réforme ne se limite pas à remplacer une facture papier ou un PDF par un autre fichier. Les factures électroniques contiennent des données structurées que les systèmes d’information peuvent traiter directement, et l’e-reporting étend cette même logique aux données de transaction et de paiement, y compris les données de vente B2C enregistrées au point de vente (Ticket Z). La France utilise des plateformes accréditées, les Plateformes Agréées, pour échanger à la fois les factures électroniques et les données d’e-reporting.
| Date | Ce qui change |
|---|---|
| 1er septembre 2026 | Toutes les entreprises concernées par la réforme doivent être en mesure de recevoir des factures électroniques. |
| 1er septembre 2026 | Les grandes entreprises et les ETI doivent émettre des factures électroniques et transmettre leurs données d’e-reporting. |
| 1er septembre 2027 | Les PME et micro-entreprises rejoignent à la fois l’obligation d’émission des factures et l’obligation d’e-reporting. |
2. Qu’est-ce qu’une Plateforme Agréée ?
Une Plateforme Agréée (PA) est une plateforme accréditée utilisée dans le système français de facturation électronique et d’e-reporting. Elle échange les factures électroniques et les données d’e-reporting, et assure l’ensemble des fonctions exigées des plateformes accréditées dans le cadre de la réforme.
Elle se distingue de la Solution Compatible. Une solution compatible connecte l’application métier d’une entreprise au système français, mais elle ne constitue pas elle-même une plateforme accréditée. Pour les éditeurs et les fournisseurs de middleware, cela signifie qu’une Plateforme Agréée, un tiers, se trouve toujours derrière la connexion, même lorsque le commerçant ne voit que sa caisse ou son middleware habituel.
fiskaltrust.eu est une Plateforme Agréée accréditée en France. Pour les éditeurs de logiciels de caisse et les commerçants utilisant fiskaltrust, cela signifie une connexion directe entre la vente et le système français de facturation électronique et d’e-reporting.
3. De la transaction en caisse à la conformité facturation électronique et e-reporting
Le moment de la vente est le point de départ naturel, puisque les deux obligations reposent sur les mêmes données de transaction. Pour les commerçants fiskaltrust, les données de transaction transitent déjà par fiskaltrust.Middleware.
Pour chaque vente, ces données constituent la base de l’e-reporting. Lorsque la vente nécessite une facture interentreprises, ces mêmes données deviennent également le point de départ de la facture électronique structurée, de sorte que développeurs, partenaires et commerçants n’ont pas à gérer un second processus déconnecté.
- Vente
- Les données de transaction sont transmises (e-reporting)
- Le cas échéant, identification du client professionnel
- Création de la facture structurée
- Transmission via le canal approprié et suivi de son statut
Derrière ces étapes, plusieurs tâches techniques doivent s’exécuter correctement : l’acheteur doit être identifié lorsqu’une facture est requise, le bon format structuré doit être généré, la facture doit être acheminée via l’infrastructure appropriée, son statut doit rester visible, et les données de transaction sous-jacentes doivent, dans tous les cas, atteindre le canal d’e-reporting.
L’objectif des modules fiskaltrust de facturation électronique et d’e-reporting est de conserver ces tâches spécifiques à chaque pays du côté fiskaltrust de l’intégration. La caisse fournit la transaction commerciale ; fiskaltrust prend en charge la couche de conformité propre au marché.
4. Un seul processus, trois manières de l’utiliser
Tous les commerçants n’ont pas besoin du même parcours de facturation électronique. Une petite boutique qui émet occasionnellement une facture B2B n’a pas les mêmes besoins qu’une plateforme de caisse traitant les factures automatiquement, à grande échelle.
| Où | Comment |
|---|---|
| En back-office | Créer la facture électronique à partir d’une transaction existante dans fiskaltrust.Portal. |
| Au comptoir | fiskaltrust.InStoreApp permet de capturer les informations de l’acheteur directement pendant la vente. |
| Dans la caisse | Utiliser le flux API fiskaltrust existant lorsque le PosCreator souhaite l’expérience complète intégrée à son propre logiciel. |
L’e-reporting s’exécute automatiquement en arrière-plan pour chaque transaction, indépendamment du parcours choisi par le commerçant pour la facturation.
5. Pour les PosCreators : étendre l’intégration existante
Pour les développeurs, le point essentiel est que la facturation électronique et l’e-reporting en France prolongent l’intégration fiskaltrust existante pour la conformité fiscale, plutôt qu’ils ne constituent une intégration de caisse distincte, propre au pays.
Le modèle technique actuel utilise le compte fiskaltrust, le Middleware et les identifiants déjà en place. La caisse marque la transaction selon le cas de facture B2B approprié dans le flux /sign existant, fournit les informations de l’acheteur, puis utilise /issue pour la transmission et le suivi du statut. Les données d’e-reporting sont transmises via cette même connexion, sans intégration de reporting distincte.
- Aucun SDK distinct n’est requis pour la facturation électronique ou l’e-reporting.
- Le même modèle de CashBox et d’authentification reste valable.
- La caisse n’a pas à implémenter elle-même les formats de facture, les formats d’e-reporting ou l’infrastructure de transmission français.
- Pour la France, PosSystem API v2 est l’interface pertinente pour la facturation électronique comme pour l’e-reporting.
Cette séparation dépasse le cadre français. Les formats nationaux, le routage et les modèles réglementaires diffèrent d’un marché à l’autre. Le processus métier côté caisse peut rester cohérent, pendant que ces mécanismes propres à chaque marché sont gérés derrière l’intégration.
6. Documentation technique pour les PosCreators
- eInvoicing : vue d’ensemble technique
- France eInvoicing : vue d’ensemble technique
- France : configuration et tests en bac à sable
7. Pour les PosDealers : tous les commerçants n’ont pas besoin d’un projet de développement
Lorsqu’un commerçant demande ce qu’il doit changer pour la facturation électronique et l’e-reporting en France, la réponse ne doit pas automatiquement être « demandez à votre développeur ». Le produit est conçu pour que les besoins des différents commerçants puissent être traités à différents niveaux.
- Factures B2B occasionnelles : un parcours back-office peut suffire.
- Factures demandées au comptoir : un parcours InStoreApp pourra rapprocher la capture des informations de l’acheteur du moment de la vente.
- Environnements B2B à fort volume ou très automatisés : une intégration directe à la caisse peut être mieux adaptée.
- L’e-reporting ne dépend d’aucun de ces parcours : il s’appuie sur les données de transaction déjà transmises via fiskaltrust.
Le partenaire (PosDealer) reste proche du commerçant : il aide à l’activation et à la configuration, vérifie que la configuration fiskaltrust du commerçant est prête pour la facturation électronique comme pour l’e-reporting, et explique quel parcours convient à son activité. Les formats nationaux, les réseaux et les mises à jour réglementaires restent une responsabilité fiskaltrust, dans le cadre du service fourni.
8. Pour les commerçants : qu’est-ce qui change au quotidien ?
La technologie derrière la facturation électronique et l’e-reporting est complexe. Le travail quotidien du commerçant ne doit pas l’être.
Imaginons un restaurant, un commerce ou une entreprise de services utilisant déjà une caisse connectée à fiskaltrust pour la conformité fiscale. Ses données de transaction sont déjà transmises comme requis. Lorsqu’un client professionnel demande une facture, la transaction déjà enregistrée via fiskaltrust devient le point de départ, au lieu de ressaisir la vente dans un système de facturation séparé.
Le client professionnel est identifié, la facture est créée dans la forme structurée requise, et elle est acheminée via l’infrastructure appropriée. Le commerçant peut ensuite suivre son statut.
Le commerçant doit se concentrer sur la vente et le client, pas sur les formats XML, les protocoles de routage ou les points d’accès API.
Le commerçant conserve certaines responsabilités. Les informations client doivent être exactes, et l’entreprise doit finaliser l’enregistrement requis auprès de la plateforme française. Mais les détails techniques des formats et de la transmission, pour la facturation électronique comme pour l’e-reporting, ne doivent pas devenir des tâches d’encaissement.
9. Les données acheteur comptent
Un aspect de la facturation électronique concerne spécifiquement les trois publics : les données client.
Une facture électronique ne peut pas être simplement adressée à un nom d’entreprise. Le destinataire doit être identifié correctement et acheminé via l’infrastructure appropriée. En France, cela signifie que les identifiants d’entreprise et les informations de routage doivent être disponibles et exacts.
Pour les commerçants, cela signifie maintenir des informations client professionnelles exactes. Pour les partenaires (PosDealers), cela signifie aider les commerçants à comprendre quelles informations sont requises. Pour les développeurs, cela signifie concevoir un moyen adéquat de capturer et de réutiliser les données acheteur, plutôt que de les traiter comme un détail secondaire.
10. Qu’est-ce que le statut de Plateforme Agréée change pour fiskaltrust ?
Cette accréditation compte parce qu’elle relie la transaction en caisse à l’infrastructure sur laquelle repose le système français de facturation électronique et d’e-reporting.
Pour les éditeurs de logiciels de caisse utilisant déjà fiskaltrust, l’objectif n’est pas d’ajouter un système de conformité indépendant supplémentaire à côté de la caisse. Il s’agit d’étendre le flux de transaction existant, afin que la facturation électronique et l’e-reporting reposent sur le même socle technique.
Le même principe s’applique à mesure que la facturation électronique et l’e-reporting se généralisent en Europe. La France utilise son modèle de Plateforme Agréée ; d’autres marchés utilisent Peppol ou des systèmes de contrôle national, et les formats et identifiants de routage varient. Ces différences sont réelles. L’objectif est d’éviter que chaque différence ne devienne une nouvelle intégration de caisse indépendante.
11. Quelles sont les prochaines étapes ?
| Rôle | Prochaine étape |
|---|---|
| PosCreator | Consulter la documentation technique, confirmer PosSystem API v2, et tester le parcours français de facturation électronique et d’e-reporting B2B en bac à sable. |
| PosDealer | Passer en revue votre portefeuille de commerçants, identifier ceux qui ont besoin d’un parcours back-office ou d’une intégration directe à la caisse pour la facturation, et confirmer que l’e-reporting fonctionne correctement pour chacun d’eux. |
| Commerçant | Vérifier vos obligations françaises de réception, d’émission et d’e-reporting, et échanger avec votre éditeur de caisse ou votre contact fiskaltrust sur votre configuration actuelle. |
12. L’essentiel n’est pas le format de facture ou d’e-reporting
La réforme française introduit de nouveaux formats, une nouvelle terminologie et une nouvelle infrastructure. Ces détails comptent, mais pour la plupart des entreprises, ils ne doivent pas devenir le processus métier lui-même.
Un commerçant doit pouvoir se concentrer sur la transaction et le client. Un partenaire (PosDealer) doit pouvoir accompagner les commerçants sans devenir expert de chaque format national de facture ou de reporting. Un développeur de caisse doit pouvoir intégrer le processus métier sans reconstruire l’infrastructure réglementaire à chaque fois qu’un autre marché européen fait évoluer ses règles.
C’est le rôle de fiskaltrust facturation électronique et e-reporting : relier la transaction qui a déjà lieu au point de vente à l’infrastructure de facturation électronique et de reporting qui la suit.
En France, l’accréditation de fiskaltrust en tant que Plateforme Agréée est un élément important pour rendre cette connexion possible, pour les deux obligations. fiskaltrust couvre à la fois la conformité fiscale et la réforme de la facturation électronique et de l’e-reporting, dans une seule couche.
13. Pour aller plus loin
Pour les détails d’implémentation, les flux API et les exigences techniques actuelles, consultez la documentation fiskaltrust.
- Vue d’ensemble technique eInvoicing
- Vue d’ensemble eInvoicing France
- France : configuration et tests en bac à sable
14. Note éditoriale
Le module fiskaltrust de facturation électronique couvre la création, la transmission et le suivi des factures B2B structurées en France. L’e-reporting, qui couvre les données de transaction et de paiement, y compris les ventes B2C (Ticket Z), est tout aussi central dans le rôle de Plateforme Agréée de fiskaltrust en France, et s’appuie sur la même connectivité PA décrite tout au long de cet article.
fiskaltrust is an accredited Plateforme Agréée in France: what it means for e-invoicing, e-reporting, and your POS
Since 1 September 2026, France’s e-invoicing and e-reporting reform has entered its implementation phase. This article covers what changed, how fiskaltrust’s accreditation as a Plateforme Agréée (PA) connects the point of sale to both obligations, and what Developers (PosCreators), Partners (PosDealers), and Merchants should take into account.
Being a Plateforme Agréée in France means that fiskaltrust’s single API integration layer that already provides fiscal compliance across Europe now also connects POS to an accredited channel for e-invoicing and e-reporting to the French tax administration.
fiskaltrust is currently the only fiscalisation compliance middleware which is also an approved Plateforme Agréée for e-invoicing and e-reporting.
Should you have any questions about the content in this article, please contact us.
1. What has changed in France?
Since 1 September 2026, businesses within the scope of the French reform must be able to receive electronic invoices. Large companies and intermediate-sized enterprises (ETIs) must also begin issuing electronic invoices and transmitting e-reporting data from this date. SMEs and micro-enterprises join both obligations from 1 September 2027.
The reform is about more than replacing a paper invoice or PDF with another file. Electronic invoices carry structured data that business systems can process directly, and e-reporting extends the same logic to transaction and payment data, including B2C sales data recorded at the point of sale (Ticket Z). France uses accredited platforms, Plateformes Agréées, to exchange both e-invoices and e-reporting data.
| Date | What changes |
|---|---|
| 1 September 2026 | All businesses concerned by the reform must be able to receive electronic invoices. |
| 1 September 2026 | Large companies and ETIs must issue electronic invoices and transmit e-reporting data. |
| 1 September 2027 | SMEs and micro-enterprises join both the invoice-issuing obligation and the e-reporting obligation. |
2. What is a Plateforme Agréée?
A Plateforme Agréée (PA) is an accredited platform used in the French e-invoicing and e-reporting system. It exchanges e-invoices and e-reporting data, and performs all the functions required of accredited platforms within the reform.
It differs from a Solution Compatible. A compatible solution connects a company’s business application to the French system, but it is not itself an accredited platform. For publishers and middleware providers, this means a Plateforme Agréée, a third party, always sits behind the connection, even where the merchant only sees their existing POS or middleware.
fiskaltrust.eu is an accredited Plateforme Agréée in France. For POS companies and merchants using fiskaltrust, this means a direct connection between the sale and the French e-invoicing and e-reporting system.
3. From a POS transaction to compliant e-invoicing and e-reporting
The sale is the natural starting point, since both obligations build on the same transaction data. For fiskaltrust merchants, transaction data already flows through fiskaltrust.Middleware.
For every sale, that data becomes the basis for e-reporting. Where the sale requires a business-to-business invoice, the same data also becomes the starting point for the structured e-invoice, so developers, partners, and merchants are not left running a second, disconnected process.
- Sale
- Transaction data is reported (e-reporting)
- Where applicable, identify the business customer
- Create the structured invoice
- Deliver it through the appropriate channel and track its status
Behind those steps, several technical tasks have to happen correctly: the buyer must be identified where an invoice is required, the right structured format must be created, the invoice must be routed through the correct infrastructure, its status must remain visible, and the underlying transaction data must reach the e-reporting channel regardless.
The purpose of the fiskaltrust e-invoicing and e-reporting add-ons is to keep those country-specific tasks on the fiskaltrust side of the integration. The POS provides the business transaction; fiskaltrust handles the compliance layer supported for the market.
4. One process, three ways to use it
Not every merchant needs the same e-invoicing workflow. A small shop that creates an occasional B2B invoice has different needs from a POS platform processing invoices automatically at scale.
| Where | How |
|---|---|
| Back office | Create the e-invoice from an existing transaction in fiskaltrust.Portal. |
| At the counter | fiskaltrust.InStoreApp is available in France, to capture buyer information directly during the sale. |
| Inside the POS | Use the existing fiskaltrust API flow when the PosCreator wants the complete experience inside its own software. |
e-Reporting itself runs automatically in the background for every transaction, independent of which of these three workflows a merchant uses for invoicing.
5. For POS creators: extend the integration you already have
For developers, the key point is that French e-invoicing and e-reporting are an extension of the existing fiskaltrust integration for fiscal compliance, rather than a separate country-specific POS integration.
The current technical model uses the existing fiskaltrust account, Middleware and credentials. The POS marks the transaction as the appropriate B2B invoice case in the existing /sign flow, supplies the buyer information, and uses /issue for delivery and status handling. e-Reporting data is transmitted through the same connection, without a separate reporting integration.
- No separate e-invoicing or e-reporting SDK is required.
- The same CashBox and authentication model remain relevant.
- The POS does not need to implement France’s invoice formats, e-reporting formats, or delivery infrastructure independently.
- For France, PosSystem API v2 is the relevant interface for both e-invoicing and e-reporting.
This separation matters beyond France. National formats, routing and regulatory models differ. The POS-facing business process can remain consistent while those market-specific mechanisms are handled behind the integration.
6. Technical documentation for POS creators
- eInvoicing: technical overview
- France eInvoicing: technical overview
- France: setup and sandbox testing
7. For POS dealers: not every merchant needs a development project
When a merchant asks what they need to change for French e-invoicing and e-reporting, the answer should not automatically be “ask your developer.” The product is designed so that different merchant needs can be handled at different levels.
- Occasional B2B invoices: a back-office workflow may be sufficient.
- Invoices requested at the counter: an InStoreApp workflow can bring buyer capture closer to the transaction.
- High-volume or highly automated B2B environments: direct POS integration may be the better fit.
- e-Reporting does not depend on which of these workflows a merchant chooses: it runs on the transaction data already flowing through fiskaltrust.
The dealer remains close to the merchant: helping with activation and configuration, checking that the merchant’s fiskaltrust setup is ready for both e-invoicing and e-reporting, and explaining which workflow fits the operation. National formats, networks and regulatory updates remain a fiskaltrust responsibility within the supported service.
8. For merchants: what changes in everyday work?
The technology behind e-invoicing and e-reporting is complex. The merchant’s daily workflow should not be.
Imagine a restaurant, retailer or service business already using a fiskaltrust-connected POS. Its transaction data is already being reported as required. When a business customer asks for an invoice, the transaction already recorded through fiskaltrust, for fiscal compliance, becomes the starting point, instead of entering the sale again in a separate invoicing system.
The business customer is identified, the invoice is created in the required structured form, and it is routed through the appropriate infrastructure. The merchant can then follow its status.
The merchant should work with the sale and the customer, not with XML formats, routing protocols or API endpoints.
The merchant still has responsibilities. Customer information needs to be correct, and the business needs to complete the required French platform onboarding. But the technical details of formats and transmission, for both e-invoicing and e-reporting, should not become checkout tasks.
9. Buyer data matters
One part of e-invoicing specifically affects all three audiences: customer master data.
An electronic invoice cannot simply be addressed to a company name. The recipient needs to be identified correctly and routed through the appropriate infrastructure. In France, this means that business identifiers and routing information must be available and correct.
For merchants, this means maintaining accurate business-customer information. For dealers, it means helping merchants understand what information is required. For developers, it means designing a sensible way to capture and reuse buyer data instead of treating it as an afterthought.
10. What does fiskaltrust being a Plateforme Agréée change?
The accreditation matters because it connects the POS transaction with the infrastructure through which the French e-invoicing and e-reporting system operates.
For POS companies already using fiskaltrust, the objective is not to add another independent compliance system beside the POS. It is to extend the existing transaction flow so that electronic invoicing and e-reporting can use the same technical foundation.
The same principle is relevant as e-invoicing and e-reporting expand across Europe. France uses its Plateforme Agréée model; other markets use Peppol or national clearance systems, and formats and routing identifiers vary. Those differences are real. The aim is to prevent every difference from becoming another independent POS integration.
11. What should I do next?
| Role | Next step |
|---|---|
| PosCreator | Review the technical documentation, confirm PosSystem API v2, and test the French B2B e-invoicing and e-reporting flow in the sandbox. |
| PosDealer | Review your merchant base, identify which customers need back-office or direct POS workflows for invoicing, and confirm e-reporting data is flowing correctly for all of them. |
| Merchant | Check your French receiving, issuing, and e-reporting obligations, and speak with your POS provider or fiskaltrust contact about your existing setup. |
12. The important part is not the invoice or e-reporting format
France’s reform introduces new formats, terminology and infrastructure. Those details matter, but for most businesses they should not become the business process.
A merchant should be able to concentrate on the transaction and the customer. A dealer should be able to support merchants without becoming an expert in every national invoice or reporting format. A POS developer should be able to integrate the business process without rebuilding the regulatory infrastructure every time another European market changes its rules.
That is the role of fiskaltrust e-invoicing and e-reporting: connecting the transaction that already happens at the point of sale with the electronic invoicing and reporting infrastructure that follows it.
In France, fiskaltrust’s accreditation as a Plateforme Agréée is an important part of making that connection possible, for both obligations. fiskaltrust covers fiscal compliance and the e-invoicing and e-reporting reform in a single layer.
13. Go deeper
For implementation details, API flows and current technical requirements, use the fiskaltrust documentation.
14. Editorial note
fiskaltrust’s e-invoicing add-on covers the creation, transmission and tracking of structured B2B invoices in France. e-Reporting, covering transaction and payment data including B2C sales (Ticket Z), is equally central to fiskaltrust’s Plateforme Agréée role in France, and uses the same PA connectivity described throughout this article.