myDATA Validator
AADE myDATA 2.0.2Check a Greek myDATA transmission document against the official AADE v2.0.2 XML Schema — invoices, credit documents, retail receipts and digital goods movement. Your document never leaves your device, and this tool never contacts AADE.
Your document never leaves your device — the file is read and parsed in this browser tab.
Drop an XML document here, or choose a file
Read in your browser. Never uploaded. Up to 12.0 MB.
What this validator runs
It runs the official AADE schema package for myDATA v2.0.2, the production baseline since 10 September 2026. The package is committed to this project, verified by SHA-256, and served from this origin — so a result cannot change because a website changed, and nothing is fetched from AADE at any point.
A check runs in layers, and each reports separately rather than collapsing into one word:
- File — the bytes are well-formed XML and passed the security screen.
- Structure — the root element and its namespace identify one of the twenty structures the official package declares.
- XML Schema — the document conforms, or does not, to that structure.
- AADE rules — permanently reported as not checked. See below.
The limit that matters
A schema pass is not acceptance by myDATA, and this tool will never say it is. Nearly every AADE business rule depends on state that lives on the platform and nowhere else: whether a ΜΑΡΚ exists, whether a correlated document is real, whether the transmitting taxpayer is registered and permitted, whether this document has already been sent. A browser cannot know any of it.
So five sentences appear nowhere in this tool: AADE valid, accepted by myDATA, officially valid Greek invoice, provider-certified, and Peppol accepted. eDocument Tools is a viewer and validator. It is not a Πάροχος Ηλεκτρονικής Τιμολόγησης, it cannot transmit anything, and it is not an archiving service.
Three things that are not the same thing
Greek e-invoicing vocabulary collapses easily, and this tool keeps the three apart on purpose:
- The legally issued electronic invoice — the business document your counterparty receives.
- The myDATA transmission representation — the XML sent to and returned by the platform. An
InvoicesDocis this. Calling it "the Greek invoice" is wrong. - The detailed myDATA representation — the downloadable form a provider may publish, which AADE defines with its own stricter schema.
The version in the namespace is not the version
Every schema in the v2.0.2 package declares version="2.0.2", while the namespace still reads http://www.aade.gr/myDATA/invoice/v1.0. AADE versions the schemas without versioning the namespace, so a myDATA document carries no evidence of the release it was written for.
This tool therefore never infers a release from a document. The version you see is the contract being applied. It is the same discipline that keeps UN/CEFACT CII D16B and D22B apart elsewhere on this site, and for the same reason: guessing a release means checking someone's document against the wrong schema and reporting the answer as fact.
Digital goods movement
Greece's Ψηφιακό Δελτίο Αποστολής is covered by the same package, and its structures are checked the same way: register transfer, confirm delivery outcome, confirm delivery return, reject delivery note, delivery status responses and the group QR structures. Where a document declares a delivery status, a move purpose or a vehicle, those values are shown as declared — never as confirmation that a movement happened.
What it does not cover
- EN 16931 — the European semantic standard binds to UBL and to UN/CEFACT CII. It has no myDATA binding, so there is no rule set to run.
- Greek B2G and Peppol — public-sector invoicing runs on Peppol BIS Billing 3.0 through the National Interoperability Centre. Different specification, different artefacts, separate verdict. See the Greece page.
- AADE code-list rules that are not in the schema — several myDATA constraints are documented in AADE's specifications rather than enforced by the XSD. They are not reimplemented here, because a rule this project has not read at source is a rule it should not be enforcing.
Frequently asked questions
Is my document uploaded anywhere?
No. The file is read by your browser and checked in a background thread inside this page. The AADE schemas are downloaded from this site, because they are committed to it, but your document is never sent anywhere — not to AADE, not to us, not to a third party. Open your browser’s network panel while validating and you will see requests only for those schema files.
Does a clean result mean myDATA will accept my document?
No, and this is the most important limit to understand. A clean result means your document matches the official AADE XML Schema. It says nothing about whether AADE will accept the transmission. Most myDATA rules depend on platform state — whether a MARK exists, whether a correlated document is real, whether the sender is registered and permitted to transmit, whether the document has already been sent. A browser cannot know any of that, and this tool never contacts AADE. Only a real transmission establishes acceptance.
Which myDATA version does this validate against?
AADE myDATA v2.0.2, the production baseline since 10 September 2026. The official schema package is committed to this project with its SHA-256 checksum, so a result cannot change because a website changed. Note that the XML namespace still reads v1.0: AADE versions the schemas without versioning the namespace, so the release is the contract this tool applies and is never something read from your document.
Why does the result never simply say “valid”?
Because that would be a bigger claim than the evidence supports. The report shows each layer separately: the schema layer passes or fails, and the AADE rule layer is permanently reported as not checked. Collapsing those into one word would turn “your XML is well formed and correctly structured” into “your tax filing is fine”, which is not the same sentence and not one this tool can make.
Which myDATA structures can it check?
All twenty declared by the official v2.0.2 package. That includes the invoice transmission document and its detailed representation, requested documents, transmission responses, income, expense and payment-method characterisations, and the digital goods movement structures: register transfer, confirm delivery outcome, confirm delivery return, reject delivery note, delivery status and the group QR structures. The structure is identified from the root element and its namespace, never from the file name.
Why was I asked to choose between two InvoicesDoc schemas?
Because AADE ships two, both declaring the root element InvoicesDoc in the same namespace. One is the transmission form an ERP produces: many invoices, characterisations allowed, and a read-only delivery lifecycle. The other is the detailed myDATA representation: one invoice, no characterisations, and item code and description are mandatory. A document cannot be assigned to one of them from its root element alone, so this tool applies the transmission form by default and offers the other rather than guessing.
Does this tool transmit to myDATA, or make me compliant?
No to both. eDocument Tools is a viewer and validator. It is not a Πάροχος Ηλεκτρονικής Τιμολόγησης — a licensed electronic invoicing provider — and it cannot transmit, clear, store or archive anything. Being able to check a structure locally is not the same as being permitted to issue or transmit it.
Does it check Greek B2G or Peppol invoices?
No. Greek B2G e-invoicing runs on Peppol BIS Billing 3.0 through the National Interoperability Centre, which is a different specification with different artefacts from myDATA. A myDATA schema result says nothing about Peppol conformance, and nothing here says anything about whether a public body will accept an invoice.