Retail and e-commerce digitisation: from the order to the invoice
If the sale already happened digitally, the invoice should not need a human touching it. See which levels the market keeps confusing, where the chain breaks today between the order and myDATA, what actually goes wrong in production, and what to ask before you sign.
In a retail shop or an online store, the sale is almost always digital already. The customer places the order, the customer types in their own details, the payment clears electronically. Then, in the last metre, somebody sits down and retypes the same data so the document can be issued.
If the sale already happened digitally, the invoice should not need a human touching it.
That is the whole idea of digitising this part of the business. It is not about doing manual work faster, it is about the manual work not existing.
The chain you want, end to end:
Sales channel → automation layer → ΥΠΑΗΕΣ provider → myDATA
One direction, no re-entry anywhere along it. The rest of this article explains that line: what each link does, where it breaks today, and what to ask about each one.
The chain, link by link
Each link does one job and does not do the others. The first one is where your channels sit, meaning WooCommerce, Shopify, Skroutz or Stripe. Nearly every bad supplier decision comes from treating two links as one.
| Link | What it does | What it does not do |
|---|---|---|
| Sales channel | Takes the order, holds the customer details, collects the money | Does not issue a legal document, does not know your tax mappings |
| Automation layer | Collects the order data, applies your rules, monitors the flow | Does not issue or transmit, and is not certified to |
| ΥΠΑΗΕΣ provider | Issues the document as a certified provider, marks it with ΜΑΡΚ and a QR code, transmits it | Does not take orders, does not manage your store or your catalogue |
| myDATA | Receives the document and registers it with ΑΑΔΕ | Does not issue, and is not a point of issue |
One thing that is not a link in this chain: the card POS terminal. It accepts the payment and nothing else. It does not know what the customer bought and it does not issue a document, so it replaces none of the four links.
This is also where the most expensive misunderstanding sits: a business management program, an ERP, is not an accepted method of issuing. Issuing requires a licensed Provider of Electronic Invoice Issuing (ΥΠΑΗΕΣ) that authenticates and transmits the document. Watch the scope of that claim: your program is not retired, it becomes the system that feeds the provider, normally over an API. Everything else it does today, it keeps doing.
Where the chain breaks today
The usual picture in a store selling online is not chaos. It is a flow that works, with one manual step in the middle that nobody has got round to solving: the order arrives from the channel, then somebody retypes it into another program so the document can be issued, and often uploads the resulting PDF back to the channel by hand.
Two entries for the same transaction means double the time, room for human error on a tax document, and two different versions of the same day. And the burden is not fixed: it grows linearly with order count. At ten documents a day it is an annoyance. At a thousand a month it is a salary you are paying to copy data from one system into another.
That is also how you tell whether automation is worth it in your case. The threshold is not turnover, it is the number of documents and how fast that number is climbing.
One channel is not one shop
Very few retailers still sell from a single place. The same stock leaves through your own online store, through a marketplace, through a subscription, sometimes across the counter as well. Every channel has its own panel, its own logic and its own fields.
- WooCommerce and Shopify for your own store.
- Skroutz and other marketplaces, where customer details often arrive in a different shape than they do from your own checkout.
- Stripe and subscriptions, where the charge repeats on its own and the document has to follow it.
- The physical counter, if you also run a shop.
The costly mistake here is not failing to automate. It is automating each channel separately, with a different process and a different place to check for each one. Then you do not have one flow, you have four, and four places where something can break without you hearing about it. The goal is one flow that accepts many sources, and one picture covering all of them.
The physical shop in the same flow
If you also have a counter, it does not need a second world of its own. Issuing through a certified provider is a legal alternative to the cash register, under article 12 §10 of law 4308/2014 (ΕΛΠ) and the provider framework: the provider's marking, meaning the ΜΑΡΚ with a QR code and real-time transmission to myDATA, substitutes for the ΦΗΜ's marking.
In practice: no cash register, no marking on a separate machine, no daily Z report. Watch the scope again: a provider removes the ΦΗΜ. It does not remove your business's obligations towards ΑΑΔΕ, nor the provider declaration. The counter joins the same chain and ends at the same point of issue, rather than becoming a second process.
Sending it to myDATA is only half the job
Most integration conversations stop at "it sends to myDATA". That is half the work. The other half is knowing what happened, without having to go looking.
- Which document was issued for which order. The mapping between order and document has to be unambiguous and visible, not something you reconstruct from dates and amounts.
- Whether it completed. Issued, marked, transmitted.
- What happened when it failed. With a clear reason and the next action, not a red icon.
A flow that is working silently and a flow that has stopped silently look identical, right up until month end. The difference only shows if somebody can see it.
What actually goes wrong
Four things, drawn from real integrations. None of them is exotic, and each one is a reason to question your supplier before you go live rather than after.
- Wrong customer details on the document. The customer asked for a company invoice, but the document was issued to the details attached to the order. This is not fixed by editing: you issue a credit note and then the correct document with the counterpart's full details. The root cause is almost always how the data arrives from the channel, so that is where it gets fixed.
- Connected, but nothing was issued. The most common "fault" that is not a fault: the store setting is still on manual issuing. It is also the right place to start, as long as you know you are there.
- Two flows running at once. When migrating off an older solution, switching on automatic issuing while the previous connection is still live produces duplicate documents for the same order. Lock the order of the steps before you flip the switch.
- The wrong document type. A retail receipt, an invoice and a delivery note are different things with different obligations. A connection that only covers one of them does not cover your business.
The dates that affect retail
| What | When |
|---|---|
| Mandatory e-invoicing for B2B documents, meaning wholesale, invoices to businesses, B2G | 1 October 2026 |
| End of the transitional period, conditional on a declaration filed on time | 31 December 2026 |
Retail receipts to consumers, which are the volume in an online store, do not fall under the B2B obligation. In practice though, businesses that already have a provider issue both categories from the same place, because the alternative is running two processes for the same thing.
And one clarification that costs money because it gets read wrong: the transitional period is not automatic. It applies only where the Declaration of Commencement of Electronic Invoice Issuing was filed on time, with a start date no later than 1/10/2026. The full timeline and the penalties are in the guide to 1 October 2026.
What to watch for when you digitise
Six questions that separate real automation from a manual process that merely went digital:
- Does it automate, or just digitise? If somebody still clicks through every order at the end of the flow, you did not save the time, you moved it.
- Is it a native integration? Avoid anything built on CSV, exports and imports, or copying data across. Those work in the demo and break the first time the channel changes.
- What happens when something fails? Ask to see the failures screen, not to have it described. Wrong customer details and connection problems will happen.
- Is there a clear order-to-document mapping? In both directions, so you can answer a customer's question in seconds.
- Does it cover the next channel? Not just the ones you sell through today. The answer should not be "a new integration from scratch".
- Is the separation of levels clean? Who holds the store, who holds the automation, who holds certified issuing. When that is blurry, nobody owns the problem the first time there is one.
How it works in practice: my-data.app
The same chain, with names on it. my-data.app is the second link, the automation layer between the sales channels and issuing. It connects to the platforms where your sales already happen, without changing how your online store works, and takes on the integration, the automation and the monitoring of the flow.
WooCommerce / Shopify / Skroutz / Stripe → my-data.app → Wrapp.ai → myDATA
There are four direct connections supported today: WooCommerce, Shopify, Skroutz and Stripe. Order and customer details pass through once, with no re-entry, and the business sees in one place the state of its connections, the history of issued documents, any failures with their reason, and the next action.
Two things worth knowing before you start. You can test and configure the flow in a test environment before using it in production, and the recommended path is to issue manually once and switch the automation on after that passes. There is also a ten-day trial, so you can watch your own flow run.
Where Wrapp fits
Wrapp is a certified ΥΠΑΗΕΣ provider, code 029. It takes the third level, issuing and transmission, so that the sales channel and the automation layer can do what they each do best. The split is not an architectural preference, it is a question of responsibility: certified issuing is regulated work.
- Full document coverage: retail receipts, invoices, credit notes, delivery notes, public sector invoices.
- No cash register, with ΜΑΡΚ and QR marking and real-time transmission to myDATA.
- Issuing through the REST API when the order starts in another system, with a staging environment for testing.
- The provider declaration to ΑΑΔΕ filed by us, within the ten days. You accept it through myAADE.
If you sell online or from a shop, start with a free account and look at the available integrations. The steps for issuing inside the app are in the guide on how to issue an invoice. If you build software for retail, the next step is integrating through the API. And if your business is in hospitality, the same logic with a different flow is in the article on digitising a hospitality business.
Frequently asked questions
I sell through my own store and through Skroutz. Do I need a different solution per channel?
No, and this is the mistake that costs the most. If you automate each channel separately you end up with as many processes as you have channels, and just as many places where something can break without you hearing about it. What you want is one flow that accepts many sources, meaning your online store, marketplaces, subscriptions and the physical counter, and one picture covering all of them. Issuing then works the same way regardless of where the sale happened.
Today I issue in another program and upload the PDF by hand. What changes?
The second entry disappears. Order and customer details pass through once, from the channel to issuing, with nobody retyping them. The gain is not fixed, it grows with the number of documents: at ten a day it is an annoyance, at a thousand a month it is paid human time spent copying data between systems. The room for human error on a tax document goes with it.
Can I test before going to production?
Yes, and it is the right way to start. There is a test environment where you connect your store and watch orders arrive before you touch real data. The recommended path is three steps in this order: connect in the test environment, issue one document manually to confirm it comes out correct, and only then switch the automation on.
I connected my store but no document was issued. Why?
In most cases this is not a fault: the store setting is still on manual issuing, so the order arrives normally but waits for you before anything is issued. You can issue the document manually from the same screen and switch the setting to automatic when you are ready. If the setting is already automatic, then the reason for the failure should be visible on the failures screen, along with the next action.
What do I do if a document was issued with the wrong customer details?
A document that has been issued and transmitted cannot be fixed by editing it. You issue a credit note to cancel it, then the correct document with the counterpart's full details. The most common cause is that the customer asked for a company invoice but the order carried their personal details, so the permanent fix is in how the data arrives from the channel, not in correcting each document one by one.
Do I need a cash register for my online store or my shop?
No. Issuing through a certified ΥΠΑΗΕΣ provider is a legal alternative to the cash register, under article 12 §10 of law 4308/2014 (ΕΛΠ) and the provider framework. The provider's marking, meaning the ΜΑΡΚ with a QR code and real-time transmission to myDATA, substitutes for the ΦΗΜ's marking, so there is no daily Z report. Watch the scope: a provider removes the ΦΗΜ, it does not remove your obligations towards ΑΑΔΕ nor the provider declaration.
Does the 1 October 2026 e-invoicing mandate apply to my online store?
It applies to the documents you issue to businesses, meaning wholesale, invoices to companies and B2G. Retail receipts to consumers, which are the volume in an online store, do not fall under the B2B obligation, but in practice businesses that already have a provider issue both categories from the same place. There is a transitional period until 31/12/2026, and it is not automatic: it applies only where the declaration was filed on time, with a start date no later than 1/10/2026.
What is the difference between my-data.app and Wrapp?
They are two different levels of the same flow. my-data.app is the automation layer: it connects to WooCommerce, Shopify, Skroutz and Stripe, collects the order data, applies your rules and shows you the state of the flow. Wrapp is the certified ΥΠΑΗΕΣ provider, code 029, that issues the document, marks it with ΜΑΡΚ and a QR code and transmits it to myDATA. The split is not a technical detail: certified issuing is regulated work and cannot be done by the automation layer.
Are delivery notes covered as well?
Yes. A retail receipt, an invoice, a credit note and a delivery note are different document types with different obligations, and all of them are covered from the same point of issue. It is worth checking this explicitly when comparing solutions: a connection that covers only one type, for example only delivery notes, does not cover your business.
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.