Integrating with the Greek tax authority’s myDATA platform is not hard in the happy path: you send a document, you get an approval, done. The real work hides in the unhappy paths — rejections, outages, duplicate submissions and cancellations. An implementation that has not planned for those works for the first month and then turns into daily manual labour.
This article covers only the technical side of the implementation. For what applies to you in tax and accounting terms, including deadlines and obligations, your accountant and the official tax authority announcements are the authoritative sources.
What the integration actually does
The system that issues your documents — commercial software, an online store or a custom application — sends the details of each document to the platform and receives unique identifiers back. Those identifiers must be stored alongside the document, because they are the proof of transmission.
The critical design point is that transmission must not block issuing. A customer at the till cannot wait because an external service is slow. The correct architecture issues the document locally and transmits asynchronously through a queue.
Mistake 1: Synchronous transmission inside the user flow
This is the most common and most expensive mistake. When transmission happens inside the issuing flow, every delay in the external service becomes a delay at the till, and every outage becomes an inability to issue documents.
The fix is a work queue: the document is issued and recorded locally, queued for transmission, and a separate worker handles sending with retries. The user experience stops depending on third-party availability.
Mistake 2: No protection against duplicate submission
If a submission fails with a timeout, you do not know whether the document was recorded or not. A naive retry can produce a duplicate entry, which is far harder to correct than a failure.
Every document needs a stable, unique identifier in your own system and a recorded transmission state before sending. Before each retry the actual state is checked, so the same action is never performed twice.
Mistake 3: Rejections that end up in a log file
Rejections are expected: wrong counterparty VAT number, value mismatches, disallowed classification combinations. The problem is not the rejection — it is when it is only recorded in a log nobody reads.
Every rejection should surface in a visible pending list, with the error in readable form and the ability for a user to correct and resubmit without a developer getting involved.
Mistake 4: Testing directly in production
The tax authority provides a sandbox environment and it exists to be used. Development and testing of every scenario — issuing, cancellation, classifications, rejections — happens there, with separate credentials and a separate database.
Going live should be a configuration change, not a code change. If switching environments requires touching code, the implementation has a design problem.
What a solid implementation includes
Beyond basic functionality, the points that distinguish an implementation that will leave you alone are few and specific:
- A queue with automatic retries and exponential backoff on failure
- Duplicate protection through stable per-document identifiers
- A visible pending and rejection screen for users, not only for developers
- A full exchange history, so “what was sent and when” always has an answer
- Alerting when transmission stalls for an extended period
- Separate sandbox and production environments switched by configuration only
How to assess your own implementation
If you already have an integration, two questions give you a first picture. First: where does your staff member see rejected documents, and what do they do to fix them? Second: what happens if the tax authority service is down for two hours at peak time?
If the answers are “we email the developer” and “we stop issuing”, the implementation needs work — and that work usually costs less than what you already pay in manual corrections every month.