Le 2 mars 2026, la Grèce a activé la première phase de son mandat B2B d’e-invoicing via la plateforme MyData de l’IAPR (Autorité Indépendante pour les Recettes Publiques, connue en grec sous l’acronyme AADE). Pour les groupes européens ayant une filiale, une succursale ou un numéro de TVA grec, ce mandat n’est pas une contrainte lointaine : c’est une obligation opérationnelle active, avec des pénalités qui courent depuis le 3 mai 2026 pour les grandes entités.
Cet article démêle ce que MyData impose réellement — et en quoi ce système diffère d’un système d’e-invoicing classique comme le SDI italien ou le PPF français — afin que votre équipe ERP sache exactement quoi paramétrer.
Qu’est-ce que MyData — et pourquoi ce n’est pas “juste un système d’e-invoicing”
MyData (My Digital Accounting and Tax Application) est la plateforme centrale de l’IAPR pour l’e-reporting fiscal en temps réel (aade.gr/en/mydata). Sa mission : créer un “miroir comptable numérique” de chaque entreprise assujettie à la TVA grecque directement dans les systèmes de l’administration.
La distinction fondamentale que beaucoup de DSI ratent : MyData n’est pas un hub de transmission de factures entre entreprises. Les factures ne “transitent” pas nécessairement par MyData avant d’arriver chez le client. En revanche, les données de chaque facture émise ou reçue doivent être transmises à MyData — en temps réel ou quasi-temps réel pour les grosses transactions — et l’IAPR retourne en échange un identifiant unique : le MARK.
Le système repose sur trois couches complémentaires :
- e-Reporting MyData : transmission des données comptables et fiscales à l’IAPR pour chaque facture, crédit note ou reçu. Obligatoire depuis 2021 pour les grandes entreprises, étendu progressivement aux PME.
- e-Invoicing B2B : depuis le 2 mars 2026, les factures B2B doivent être émises dans un format électronique structuré (EN 16931/Peppol) via un prestataire accrédité (Y.PA.H.E.S.) ou les outils gratuits de l’AADE.
- e-Transport : déclaration des mouvements de marchandises à l’IAPR avant tout transport physique. Couche distincte, hors périmètre de cet article.
Le MARK : l’identifiant que votre ERP doit absolument gérer
Chaque document transmis à MyData reçoit un MARK (Μοναδικός Αριθμός Καταχώρησης) — un numéro d’enregistrement unique à 14 chiffres assigné par l’IAPR (clearvo.io). Ce MARK est la preuve que la transaction a bien été enregistrée dans les systèmes de l’administration.
Conséquences pratiques pour l’ERP :
- Sans MARK valide, une facture n’est pas légalement conforme en droit grec.
- Le MARK doit figurer sur le document remis au client, accompagné d’un QR code liant vers le registre IAPR (obligatoire depuis janvier 2024 pour tous les documents PDF).
- Le MARK apparaît également dans les e-Books (journaux comptables numériques) que chaque entité doit tenir à jour dans MyData.
Les factures B2C (retail) relèvent du type de document 11.1 dans la nomenclature MyData. Les factures B2B standard domestiques relèvent du type 1.1 ; les services B2B du type 2.1 ; les ventes intra-UE du 1.2 ; les exports hors UE du 1.3. Ce système de codes de classification — distinct des catégories comptables françaises ou allemandes — nécessite un mapping explicite dans l’ERP.
Calendrier des obligations MyData 2024-2026
| Obligation | Public cible | Date effective |
|---|---|---|
| e-Reporting MyData (e-Books) | Grandes entreprises grecques | Depuis 2021 |
| e-Reporting MyData (e-Books) | Toutes les PME grecques | Depuis 2023 |
| e-Invoicing B2G via Peppol | Fournisseurs de l’État grec | Depuis septembre 2025 |
| e-Invoicing B2B — Phase 1 | Entités avec CA 2023 > 1 M EUR | 2 mars 2026 (pénalités : 3 mai 2026) |
| e-Invoicing B2B — Phase 2 | Toutes les autres entités assujetties | 1er octobre 2026 |
La Phase 1 a inclus une période d’ajustement du 2 mars au 3 mai 2026 pendant laquelle les entreprises pouvaient fonctionner en parallèle (ancien et nouveau système). Depuis le 3 mai 2026, les pénalités sont actives pour toutes les entités de Phase 1 (rtcsuite.com).
Qui est concerné parmi les entreprises étrangères ?
C’est la question que posent le plus souvent les DAF de groupes franco-grecs, italo-grecs ou germaniques. La règle est simple :
Vous êtes dans le périmètre MyData si votre entité dispose d’un numéro de TVA grec (préfixe EL), que ce soit via :
- une filiale de droit grec (société Anonyme ou SARL grecque) ;
- une succursale (établissement stable fiscal en Grèce) ;
- une représentation fiscale grecque (pour les entreprises étrangères enregistrées à la TVA grecque sans présence physique).
Si votre entreprise française facture ponctuellement un client grec sans être enregistrée à la TVA en Grèce, vous n’êtes pas directement soumis aux obligations MyData. En revanche, votre client grec devra déclarer la transaction de son côté.
Les transactions intra-UE ont un traitement particulier : pour les ventes à des entreprises établies dans d’autres États membres de l’UE, le format électronique structuré n’est pas imposé au destinataire étranger (celui-ci peut légalement refuser). La transmission à MyData reste cependant obligatoire côté grec (edicomgroup.com).
Le cas des groupes franco-grecs est potentiellement le plus complexe : une filiale grecque d’un groupe français doit satisfaire simultanément les obligations MyData côté grec ET contribuer aux flux RFE/PDP côté français pour les transactions transfrontalières. Le mapping comptable et la codification des flux doivent être pensés en amont dans l’ERP de groupe.
Les flux concernés et leur traitement dans l’ERP
Factures de vente (e-invoicing sortant)
La facture doit être générée en format XML structuré (EN 16931 / Peppol BIS Billing 3.0), transmise à l’IAPR via un prestataire Y.PA.H.E.S. accrédité ou l’outil gratuit Timologio, et recevoir son MARK avant d’être envoyée au client. L’ERP doit intégrer cette boucle de validation : émettre la facture, appeler l’API IAPR (ou le connecteur EDIP), récupérer le MARK et l’intégrer au PDF final.
Factures d’achat (e-invoicing entrant)
À partir de la Phase 2 (octobre 2026), les entreprises grecques Phase 1 ont l’obligation d’accepter les e-factures structurées de leurs fournisseurs grecs. L’ERP doit être capable de recevoir des factures au format Peppol et de valider la présence du MARK — sans lequel la déductibilité TVA peut être remise en cause lors d’un contrôle IAPR.
Livres comptables numériques (e-Books)
Les e-Books sont la colonne vertébrale de MyData avant même le mandat d’e-invoicing. Ils comprennent le grand livre (général ledger), les enregistrements de caisse, les immobilisations et les dotations aux amortissements (pikon.com). La transmission se fait mensuellement ou trimestriellement, avec une échéance avant le 20 du mois suivant la période. Depuis janvier 2024, les factures de gros (wholesale) requièrent une transmission en temps réel.
Données de paie
Les données sociales et de paie transitent par ERGANI, le système grec des déclarations sociales — distinct de MyData. Ne confondez pas les deux : MyData couvre le fiscal/comptable, ERGANI le social. Un ERP SIRH déployé en Grèce doit alimenter ERGANI via son propre connecteur, indépendamment du paramétrage MyData.
Ce que votre ERP doit couvrir pour être conforme
Checklist opérationnelle par composant :
- Connecteur API IAPR ou prestataire Y.PA.H.E.S. : choix structurant entre développement en direct sur l’API AADE et délégation à un prestataire accrédité. Les EDIPs grecs les plus actifs incluent EntersoftONE (filiale de la fusion Entersoft/SoftOne, premier certifié AADE), ainsi que des acteurs internationaux comme EDICOM.
- Génération du format XML IAPR à partir des documents de l’ERP (SD billing pour SAP, factures de vente pour Odoo, AR invoice pour Dynamics).
- Codification MyData : attribution des types de documents (1.1, 1.2, 1.3, 2.1, etc.) et des catégories de TVA grecques (24 % standard, 13 % réduit, 6 % super-réduit) en fonction des paramétres de l’ERP.
- Récupération et stockage du MARK : le MARK retourné par l’API IAPR doit être enregistré dans l’ERP et inclus dans le PDF facture + le QR code.
- Archivage conforme : la durée légale grecque est de 5 ans minimum. L’archivage électronique doit garantir l’intégrité du document et la présence du MARK.
- Gestion des crédits notes (avoirs) : les avoirs ont leur propre type de document (5.1) et doivent être transmis séparément à MyData avec référence à la facture d’origine.
Support des principaux ERP
SAP S/4HANA et SAP ECC : le module SAP Document Compliance (eDocument Cockpit) gère nativement le workflow MyData — génération XML, appel API IAPR, récupération du MARK. Compatible ECC 6.0 et S/4HANA (pikon.com).
Oracle Fusion / ERP Cloud : Oracle Tax Reporting Cloud couvre les obligations e-reporting MyData. Vérifier que le module “Greece Localization” est activé dans votre instance.
Microsoft Dynamics 365 Finance : une localisation ISV partenaire est nécessaire (pas de localisation Microsoft native sur MyData au moment de la rédaction). Plusieurs partenaires certifiés proposent des extensions pour le marché grec.
Odoo : des modules tiers MyData sont disponibles sur l’Odoo Apps Store. Valider que le module supporte la version Odoo déployée et que le fournisseur du module est effectivement accrédité AADE ou passe par un EDIP certifié.
Les pièges pour les groupes étrangers
La double obligation réglementaire : une filiale grecque d’un groupe français est soumise à MyData (Grèce) ET contribue aux obligations de e-reporting de groupe côté France (RFE/PDP). Les flux transfrontaliers intra-groupe doivent être correctement codés dans les deux systèmes — avec des classifications qui ne se correspondent pas nativement.
Le mapping des codes de classification : les types de documents MyData (1.1, 1.2, etc.) n’ont pas d’équivalent direct dans les plans comptables français ou allemand. Un travail de mapping spécifique est requis lors du paramétrage ERP, surtout pour les transactions intra-groupe ou les autofacturations.
Les factures auto-liquidées (autofacturation ou “self-billing”) : elles ont un traitement spécifique dans MyData. L’entreprise qui reçoit le service peut émettre la facture à la place du prestataire, à condition que les deux parties aient formalisé cet accord. Le type de document et les codes associés diffèrent.
Les pénalités sont asymétriques : pour les transactions avec TVA, la pénalité est de 50 % du montant de TVA non déclaré (saft-validator.com). Pour les transactions hors TVA, les amendes fixes s’élèvent à 500 EUR ou 1 000 EUR par infraction selon le type de comptabilité tenu. Les pénalités sont actives pour les entreprises Phase 1 depuis le 3 mai 2026.
Les représentants fiscaux jouent un rôle clé pour les entreprises étrangères sans établissement stable mais enregistrées à la TVA grecque : ils sont souvent responsables contractuellement de la conformité MyData, ce qui implique de les intégrer dans votre workflow de transmission.
Comment se mettre en conformité : les 5 étapes
Étape 1 — Cartographier les entités grecques du groupe : identifier chaque entité avec un numéro EL actif (filiale, succursale, représentation fiscale) et son chiffre d’affaires 2023 pour déterminer si elle est Phase 1 (> 1 M EUR) ou Phase 2 (toutes les autres, deadline octobre 2026).
Étape 2 — Auditer les flux de facturation impactés : B2G (déjà actif via Peppol), B2B domestique, ventes intra-UE, exports hors UE, factures d’achat, autofacturations, avoirs. Chaque type a son code MyData et son délai de transmission.
Étape 3 — Choisir le mode de transmission : API directe IAPR (recommandé pour les gros volumes avec un ERP international supporté) ou délégation à un EDIP accrédité (plus rapide à mettre en oeuvre pour les structures moyennes). Pour les très petites entités grecques du groupe : les outils gratuits AADE (Timologio, myDATAapp) suffisent en volume faible.
Étape 4 — Paramétrer les codes de classification dans l’ERP : travail à faire en collaboration avec l’équipe comptable grecque ou le cabinet fiscal local. Le mapping entre vos codes de TVA ERP et les catégories MyData (1 à 8) doit être documenté et validé avant mise en production.
Étape 5 — Tester sur l’environnement sandbox IAPR : l’AADE met à disposition un environnement de test. Valider chaque type de flux avant le déploiement en production, et conserver les logs de MARK pour chaque test — ils serviront de preuve lors d’un audit.
Pour aller plus loin sur le contexte réglementaire européen, consultez notre analyse de Peppol comme infrastructure commune d’e-invoicing en Europe, notre décryptage de VIDA et la feuille de route TVA numérique UE 2025-2035 et notre tour d’horizon de l’e-invoicing en Europe centrale et orientale (KSeF, RTIR, e-Factura).
