What is a MARK in ΑΑΔΕ myDATA?

A MARK is the unique registration number the Greek tax authority returns when a document is transmitted successfully to myDATA. It is the proof of registration and must be stored on the invoice, because credit notes and corrections reference the original document by its MARK.

Does a Greek ISP need a certified e-invoicing provider for myDATA?

Not necessarily. Transmitting directly to the ΑΑΔΕ API from the billing platform is permitted and is usually preferable at ISP volumes because certified providers charge per document. A provider mainly reduces implementation work.

← Back to Blog

AADE e-Invoicing for Greek ISPs: Compliance Guide

Q: Can an invoice already transmitted to myDATA be deleted?

No. Once transmitted, a document cannot be deleted. Corrections are made by issuing a credit note that references the original document, so deleting an invoice in the billing system is never a valid correction.

Q: Is myDATA the same as ΔΙΑΣ direct debit?

No. myDATA transmits the tax data of documents to the ΑΑΔΕ, while ΔΙΑΣ collects money through the Greek banking system. They are independent: an invoice can be transmitted but unpaid, or paid but untransmitted.

May 25, 2025 · 7 min read · By Veloxiom Team

Every business in Greece has to transmit its invoice data to the ΑΑΔΕ through myDATA. For an ISP the requirement is not conceptually hard, but the volume makes it unforgiving: a few hundred subscribers means a few hundred documents a month, every one of which must be transmitted, must come back with a MARK, and must be reconcilable afterwards. This guide covers what a provider actually has to send, where the process breaks, and what to check every month.

A note on scope: this is an operational guide, not tax advice. Deadlines and classification rules change, and your accountant is the authority on which codes apply to your revenue. Verify anything time-sensitive against the current ΑΑΔΕ documentation.

What myDATA Actually Requires

myDATA is the ΑΑΔΕ's electronic bookkeeping platform. Every issued document — invoice, credit note, receipt — is transmitted as structured data. The tax authority returns a MARK, a unique registration number that is the proof of transmission. A document without a MARK is, for practical purposes, not registered.

Each transmitted document carries, at minimum:

Issuer and counterparty tax identification (ΑΦΜ), with the counterparty omitted for retail documents.
Document series and number, and the issue date.
Line items with net value, VAT category and VAT amount.
A classification of income per line — the code that tells the ΑΑΔΕ what kind of revenue this is.
Payment method.

Classification is where ISPs most often need their accountant. Subscription service revenue, one-off installation work, hardware sold to the subscriber and reseller commission are not necessarily the same category, and getting them consistently right from the first month is much easier than correcting a year of submissions later.

The Three Ways to Transmit

Directly through the REST API from your billing platform, authenticated with credentials issued for your ΑΦΜ. This is the right choice at ISP volumes: no manual step and no third party between you and the authority.
Through a certified provider (πάροχος ηλεκτρονικής τιμολόγησης), which issues and transmits on your behalf. Less work, an extra cost per document, and one more dependency.
Manually in the ΑΑΔΕ portal. Viable for a handful of documents a month, unworkable for an ISP.

e-Invoicing Built Into Billing

Veloxiom submits invoices to myDATA from the same records that produced them, stores the returned MARK on the invoice, and shows submission state per document. Failures stay visible next to the invoice — not buried in a connector's log — and can be retried without re-issuing the document.

Where It Goes Wrong in Practice

The mechanics of a single successful submission are the easy part. These are the failure modes that cost real time:

Silent partial failure. A run of 400 invoices where 12 were rejected is the classic problem. If your system does not report the count of documents without a MARK, you will discover the gap at year end.
Retry that re-issues. A retry must resend the same document, never generate a new invoice number. Duplicated numbering is far harder to unwind than a missing submission.
Cancellation done wrong. A transmitted invoice cannot be deleted. The correction is a credit note that references the original — which means you must have stored the original's MARK.
Rounding disagreements. VAT computed per line and summed can differ by a cent from VAT computed on the total. Decide which one your invoices use and make the transmission match the printed document exactly.
Expired credentials. API credentials and certificates expire. Nothing announces it; submissions simply start failing, so the monthly check has to include authentication.
Time zones and cut-offs. A document issued at 23:50 on the last day of the month must be transmitted within the deadline for that period, not the next one.

The Monthly Reconciliation Check

This is the single most valuable habit, and it takes minutes if the data is in one place. Every month, confirm:

The number of invoices issued equals the number of documents with a MARK.
Every credit note references an original document that itself has a MARK.
Total net and VAT per classification match your accounting figures.
No document remains in a pending or failed state from a previous period.
Invoice numbering has no gaps — and if there is a gap, you know exactly why.

A billing system that cannot answer these five questions on one screen will cost you the difference in accountant hours.

ΔΙΑΣ Direct Debit and myDATA Are Separate Problems

These are frequently confused because both involve files and both are Greek. They are unrelated: myDATA transmits the tax data of a document to the ΑΑΔΕ, while ΔΙΑΣ collects the money through the banking system. An invoice can be transmitted successfully and never paid, or paid and never transmitted. Both states are real and both need to be visible per invoice, which is the practical argument for having billing, e-invoicing and payment collection in one system rather than three.

What Your Billing System Must Store

Compliance is mostly a data-retention problem. Whatever platform you use, these fields have to exist per document and survive backups, migrations and staff changes:

The MARK and the transmission timestamp.
The UID of the document, so a retry is provably the same document rather than a new one.
The submission state: pending, transmitted, rejected — with the rejection reason kept verbatim, because the ΑΑΔΕ messages are specific and paraphrasing them loses the diagnosis.
The classification codes as they were sent, not as they are configured today. Codes change; historical documents must reflect what was actually transmitted.
The link from every credit note to the original document.

If any of this lives only in a log file that rotates after two weeks, you do not have an audit trail.

Foreign Customers, Resellers and Reverse Charge

Most ISP revenue is domestic retail and B2B, which is straightforward. Two cases routinely need explicit handling:

EU business customers — for example transit, IP or colocation sold to a company in another member state. These are frequently subject to reverse charge, meaning VAT is not charged and the document must indicate why. A VAT-exempt document with no exemption reason is a rejection waiting to happen.
Resellers — if you invoice a reseller who invoices the end subscriber, your document is B2B with the reseller's ΑΦΜ, and the end subscriber never appears in your submissions. Multi-tenant installations make this mistake easy: the tax identity that issues the document must be the one that actually holds the contract.

Both cases are decided by your accountant once, then configured once. What matters technically is that the platform can hold a different VAT treatment and exemption reason per customer and per product rather than applying a single global rate.

What to Ask a Vendor Before You Rely on Them

Is the MARK stored on the invoice record and visible in the interface?
What does a failed submission look like, and how is it retried without re-issuing?
Can you produce a report of documents without a MARK for any period?
Are credit notes linked to the original document's MARK automatically?
Are the classification codes configurable per plan and per product?
Is transmission direct to the ΑΑΔΕ, or through a provider that charges per document?

Any vendor who cannot demonstrate the failed-submission report on a live screen has not operated this at ISP volume.

Frequently Asked Questions

What is a MARK in myDATA?

It is the unique registration number the ΑΑΔΕ returns when a document is successfully transmitted. It is the proof of registration and must be stored, because credit notes and corrections reference it.

Can a transmitted invoice be deleted?

No. Corrections are made by issuing a credit note that references the original document. This is why deleting an invoice inside your billing system is never an acceptable correction path once it has been transmitted.

Does an ISP need a certified e-invoicing provider?

Not necessarily. Transmitting directly through the ΑΑΔΕ API from your billing platform is permitted and is usually preferable at ISP volumes, since a per-document fee adds up quickly. A certified provider mainly buys you less implementation work.

What happens if a submission fails?

The document is not registered until it is transmitted successfully. The correct handling is to retry the same document, preserving its number, and to keep a report of everything still lacking a MARK so nothing is forgotten at period close.

Is myDATA the same as ΔΙΑΣ direct debit?

No. myDATA transmits tax data of documents to the ΑΑΔΕ. ΔΙΑΣ collects payments through the banking system. They are independent, and an invoice can be transmitted but unpaid, or paid but untransmitted.