Hospitality platforms and myDATA: why issuing runs through a ΥΠΑΗΕΣ provider
You built software that takes the order. Now every customer asks about the receipt. Why transmitting to myDATA does not cover issuing, what that means for your architecture, and what integrating with a ΥΠΑΗΕΣ provider actually involves.
Your software takes the order, sends it to the kitchen, keeps the table's bill open and produces reports. And then comes the question that shows up in every sale: "how do I issue the receipt?"
The answer determines architecture, timeline and compliance risk, so it is worth settling before it lands on the roadmap. Below is the distinction that gets skipped, the two roads available to you, and what integrating actually involves.
Transmitting is not issuing
Plenty of platforms get as far as sending data to myDATA and consider the problem solved. It is not, and the distinction is regulatory rather than a technical detail.
Transmission informs ΑΑΔΕ of a document's data. Issuing is the whole cycle: creating the document in a structured electronic format, authenticating it, delivering it to the recipient and archiving it.
ΑΑΔΕ has stated it explicitly: business management programs, commercial, accounting and ERP, are not an accepted method of issuing documents. Issuing runs through a licensed electronic invoicing provider (ΥΠΑΗΕΣ).
In practice this does not retire your software. It stops being the point of issue and becomes the system that feeds the provider, normally over an API. The same logic applies to every category of software that produces transactions, as we explain in the article on connecting SaaS and ERP systems to myDATA.
The two roads
| Become a provider | Integrate with a provider | |
|---|---|---|
| What you build | Compliance infrastructure, authentication, archiving | One REST integration into the product you already have |
| What you take on | Licensing and continuous compliance with the ΑΑΔΕ framework | Your own application. Responsibility for authentication and transmission sits with the provider |
| Time to market | A project with a roadmap of its own | Usually 2 to 3 days of development, then staging tests |
| Where your time goes | Into infrastructure that is not your product | Into the product you sell |
Becoming a provider is not the wrong choice. It is, however, a different business from building hospitality software, and usually not the one a product team set out to build.
What the integration involves
- A REST API for real-time issuing, with documentation and clear myDATA error codes.
- A staging environment to test every document type end to end before you go to production.
- Coverage of every type hospitality needs: retail and service receipts, invoices, credit notes, the Catering Order Note (type 8.6), delivery notes for supplies, public sector invoices for B2G.
- ΜΑΡΚ marking with a QR code and real-time transmission to myDATA, so your customer needs no cash register.
- A partner programme for the commercial side, depending on who bills the end customer.
The declaration that affects your customers
One point that often gets missed in planning: choosing a provider comes with a declaration to ΑΑΔΕ, and the provider files it, through myAADE, within 10 days of the contract taking effect.
The customer is notified through e-notifications and by email and has 10 days to accept or reject it. If that deadline passes with no action, the declaration is presumed accepted. If the provider fails to file on time, the obligation passes to the business. The steps, with screenshots, are in the guide on the ΥΠΑΗΕΣ provider declaration.
Why this matters commercially: it is paperwork neither you nor your customer carries. In a sale where your competitor says "you will sort that out with your accountant", that counts.
The timing window
From 1 October 2026 e-invoicing becomes mandatory for the B2B documents of all remaining businesses, with a transitional period until 31/12/2026 that is conditional on a declaration filed on time. For a hospitality platform that means your customers will ask in the coming weeks, not at some point in the future. The full timeline and the penalties are in the guide to 1 October 2026.
The same picture from your customer's side
What connected operation actually means for a hospitality business, from order taking through to the tax document, is described from the owner's point of view in the article on restaurant digitisation. Useful as material for your own sales conversations too: those are the questions your customer will ask you.
How to start
For access to the staging environment, fill in the form on the API partnership page with your VAT number. The account is created automatically and we follow up with your credentials, so you can test every document type before going to production. If you already have a view of your annual document volume, send it along: it shapes the commercial conversation.
Frequently asked questions
I already send data to myDATA. Is that not enough?
No, because transmitting and issuing are two different things. Transmission informs ΑΑΔΕ of a document's data. Issuing covers creating the document in a structured format, authenticating it, delivering it to the recipient and archiving it. ΑΑΔΕ states explicitly that business management programs, commercial, accounting and ERP, are not an accepted method of issuing. Your software is not retired: it stops being the point of issue and becomes the system that feeds the provider.
Could I become a provider myself instead of integrating with one?
That path exists, but it is a different product from yours. Being an electronic invoicing provider requires licensing and continuous compliance with the ΑΑΔΕ framework, meaning infrastructure, certifications and responsibility for authentication, transmission and data retention. For most software vendors the question is not technical but strategic: do you want to build and maintain compliance infrastructure, or spend your time on the product you actually sell?
Which document types does the API cover?
Retail receipts, service receipts, sales and service invoices, credit notes, the Catering Order Note (myDATA type 8.6), delivery notes and public sector invoices (B2G). For a hospitality platform that means one integration covers both the retail sale on the floor and the catering invoice.
How long does the integration take?
Integrating with the REST API is usually completed in 2 to 3 days, with testing in a staging environment before going to production. The timeline depends less on the API and more on how many document types your customers issue.
Who files the declaration with ΑΑΔΕ for my customers?
The provider does, through myAADE, within 10 days of the contract taking effect. The business is notified through myAADE e-notifications and by email and has 10 days to accept or reject it. If that deadline passes with no action, the declaration is presumed accepted. If the provider fails to file on time, the obligation passes to the business. In practice, it is paperwork you do not carry.
Is there a staging environment, and how do I get access?
Yes. Fill in the form at wrapp.ai/en/api/becomeapartner with your VAT number and the staging account is created automatically. We follow up with your credentials so you can start testing.
My customers have cash registers. What changes for them?
Issuing through a certified provider is a legal alternative to a cash register: the provider marking, ΜΑΡΚ with a QR code and real-time transmission, substitutes for the ΦΗΜ marking, with no daily Z report. A provider removes the ΦΗΜ, it does not remove the business's obligations towards ΑΑΔΕ.
How does the commercial relationship work?
It is agreed case by case through the partner programme, depending on whether the end customer is billed by you or by us, and on document volume. Start from the partner page and tell us the annual volume you expect.
Need help?
If you have a question about this topic or want to make sure everything is set up correctly, contact us and we will look at it together.