Griekse e-factuur versus myDATA-rapportage

Dezelfde transactie, twee verschillende datasets

Griekenland heeft met myDATA (My Digital Accounting and Tax Application) een nationale digitale administratie ingericht waarin btw- en boekhoudkundige gegevens structureel worden aangeleverd. myDATA is daarmee meer dan “een rapportageportal”: het is het fundament onder een werkwijze waarin transacties sneller, consistenter en beter controleerbaar worden vastgelegd. In die context wordt ook verplichte B2B e-invoicing gefaseerd ingevoerd. Dat leidt in de praktijk tot een veelgestelde vraag: is een e-factuur hetzelfde als wat je aan myDATA rapporteert?

Het korte, maar belangrijke antwoord is: nee. De e-factuur en de myDATA-aanlevering beschrijven dezelfde onderliggende transactie, maar ze zijn ontworpen voor verschillende doelen en bevatten daarom andere soorten data. Wie dit verschil niet expliciet meeneemt in ontwerp en implementatie (ERP, e-invoicing provider, integratie), loopt vroeg of laat vast in mapping, validatie, classificatie en reconciliatie.

1) De e-factuur: juridisch handelsdocument met commerciële detailinformatie

De e-factuur is in de kern een juridisch document tussen leverancier en afnemer. Het document moet de transactie ondubbelzinnig vastleggen, zodat betaling, boeking en controle mogelijk zijn. Daarom bevat een compliant factuur doorgaans:

• Identificatie: factuurdatum en uniek factuurnummer (sequentieel, eventueel per reeks).
• Partijen: leverancier en klant (naam/adres) en relevante btw-identificatie.
• Prestatie: omschrijving van goederen/diensten en (waar relevant) hoeveelheid/eenheden.
• Datums: leveringsdatum/uitvoerdatum als die afwijkt van de factuurdatum.
• Bedragen en btw: netto bedragen, btw-tarieven, btw-bedragen en totalen.
• Bijzondere regimes: bijvoorbeeld verleggingsvermelding of verwijzing naar vrijstelling waar van toepassing.

Belangrijk: de factuur is bedoeld voor handelspartners en later voor auditors. Daarom bevat ze ook “menselijke” velden die de transactie begrijpelijk maken, zoals namen, adressen, regelomschrijvingen en commerciële context (betalingscondities, referenties, PO-nummers). Niet alles is juridisch verplicht, maar veel is wel functioneel voor samenwerking en dispute-preventie.

2) myDATA: fiscale extractie + verplichte classificatie (tax-ledger logic)

myDATA werkt anders. De myDATA-aanlevering is geen “kopie van de factuur”, maar een fiscale representatie waarmee de belastingdienst elektronische boeken bijwerkt en controles automatiseert. Dat zie je terug in drie ontwerpprincipes:

a) Identificatie via sleutels, niet via “menselijke” beschrijving

In myDATA staan sleutelvelden centraal: documentnummer, datum, btw-identificaties (Tax ID/AFM), en technische metadata. Waar de factuur namen en adressen toont voor juridische en commerciële duidelijkheid, gebruikt myDATA primair identificatoren die in het fiscale systeem al bekend zijn.

b) Verplichte codering en classificatie

myDATA vereist dat elke transactie wordt getagd met documenttypecodes en classificaties (inkomsten/uitgaven) volgens vaste taxonomie. Dit is typisch “boekhoudkundige taxonomie”: een transactie moet in een door de autoriteit gedefinieerd raster passen. Die codes staan doorgaans niet op de factuur zelf, omdat ze bedoeld zijn voor het fiscale systeem, niet voor de handelspartner.

c) Rapportage focust op fiscaal relevante samenvatting

In veel scenario’s is myDATA gericht op het doorgeven van de fiscale uitkomst (netto per btw-categorie, btw-bedragen, totalen), aangevuld met verplichte classificaties. De factuur kan (en zal) veel meer detail bevatten op regelniveau, maar dat detail is voor myDATA niet altijd nodig of zelfs gewenst.

3) Extra fiscale velden: wat myDATA wél wil, maar de factuur niet per se “moet” tonen

Een van de meest onderschatte verschillen: myDATA kan extra fiscale componenten verlangen die op de factuur niet altijd expliciet hoeven te staan of in elk geval niet tot de kern van “btw-factuurinhoud” worden gerekend. Denk aan:

• Withholding taxes (inhoudingen/bronheffingen),
• Stamp duty (zegelrecht),
• Overige heffingen/fees die fiscaal relevant zijn, los van btw.

Voor implementaties betekent dit: je mapping is niet alleen “UBL/EN-gegevens overzetten naar myDATA”, maar ook het expliciet modelleren van fiscale bijcomponenten en hun plaats in de myDATA-structuur.

4) MARK / unieke registratiecode en QR: de registratielaag bovenop de factuur

Naast inhoudelijke verschillen is er een belangrijk procedureel verschil. In een CTC-achtige keten ontstaat vaak een registratie-identificator vanuit het platform (of vanuit de providerflow). In Griekenland is dat de logica rond MARK / unieke registratiecode: na succesvolle rapportage wordt een identificator toegekend die als bewijs van registratie kan dienen en in de praktijk ook onderdeel wordt van de “finale” factuurpresentatie (bijvoorbeeld via een QR-verificatie).

Dat betekent: een factuur is niet alleen “gemaakt en verstuurd”, maar ook “geregistreerd en bevestigd”. De inrichting van monitoring, foutafhandeling en retries wordt hierdoor een kernonderdeel van compliance.

5) De kernverschillen in één oogopslag

• E-factuur (handelspartner/audit trail): juridisch document, detailrijk, menselijk leesbaar, gericht op betaling en bewijsvoering.
• myDATA-aanlevering (belastingdienst/e-books): fiscale dataset, sleutelvelden + codering, classificatieverplichtingen, gericht op verwerking in elektronische boeken en controles.

Het zijn twee representaties van dezelfde transactie, maar ze zijn niet uitwisselbaar en zelden “1-op-1 identiek”.

6) Waarom dit verschil ertoe doet voor ERP, integraties en processen

Voor organisaties (en zeker voor softwareleveranciers) is dit geen theoretisch onderscheid; het bepaalt je implementatie-aanpak:

1. Mapping is transformatie, geen kopieerwerk: je vertaalt factuurdata naar myDATA-velden (typecodes, classificaties, fiscale subcomponenten, totalenlogica).
2. Classificatiebeheer wordt een proces: je hebt eigenaarschap nodig (finance/tax) en rules (defaults + uitzonderingen) om classificaties consistent te houden.
3. Reconciliatie wordt continu: je moet aantoonbaar kunnen maken dat “wat de klant ziet” en “wat de autoriteit registreert” functioneel overeenkomt.
4. Monitoring is compliance: rejects, timeouts en schemawijzigingen vragen om operationele controles, niet alleen IT-logging.

7) Praktische checklist: zo word je implementatie “compliance-ready”

• Documenttypen & classificaties: definieer regels per scenario (invoice/credit note, domestic/export, reverse charge, etc.), test die scenario’s en leg governance vast.
• Fiscale bijcomponenten: modelleer met inhoudingen/fees/stamp duty expliciet; voorkom dat ze “uit het proces vallen”.
• Registratieflow (MARK/QR): verwerk de terugkoppeling van het platform; bouw een audit trail met statusovergangen (created → submitted → accepted/rejected → corrected).
• Error handling: ontwerp retries, correcties, en duidelijke “ownership” (wie corrigeert, wanneer, en hoe wordt dat vastgelegd?).
• Reconciliatie-rapportages: dashboards of exports waarmee finance kan aantonen dat factuurpopulatie en myDATA-populatie matchen binnen afgesproken toleranties.
• Transitieplanning: stem timing en scope af op de gefaseerde invoering; voorkom dat je “in productie” nog classificatie- of mappingkeuzes moet uitvinden.

Conclusie

In Griekenland zijn e-facturatie en myDATA-rapportage twee kanten van dezelfde medaille, maar ze zijn niet hetzelfde. De e-factuur is het juridische handelsdocument; myDATA is de fiscale dataset die de elektronische boeken voedt en controles mogelijk maakt. Succesvolle compliance vraagt daarom om een ontwerp dat expliciet rekening houdt met: (1) verschillende datadoelen, (2) verplichte codering en classificatie, (3) extra fiscale componenten, en (4) een registratie- en feedbackloop (MARK/QR) met robuuste monitoring. Wie dat vanaf het begin meeneemt, voorkomt later dure correctietrajecten en operationele frictie.