OSS and EU distance sales to consumers: issuing myDATA documents through the API
myDATA has no OSS field. The document is composed instead: a 0% line with a VAT exemption reason, and the destination country VAT carried as a line of its own. Full payloads, the error codes you get when you do it the obvious way, and why a clean ΜΑΡΚ does not mean the coding was right.
An e-shop ships a parcel to a private buyer in Rome. A marketplace passes the order through with the destination country's rate sitting on the line item. An ERP sees a rate field that reads 22 and has to decide what to do with it. In all three cases the question is the same: how does a retail distance sale to a consumer in another member state get transmitted to myDATA?
The answer is not in a field, because myDATA has no OSS mechanism: no field, no flag, no separate document type. The document is composed. This guide shows what from.
Foreign VAT is not Greek VAT. The document goes out at 0% with a VAT exemption reason, and the destination country's VAT is carried as a line of its own.
When this applies to you
While your sales to consumers in other member states stay small, they are taxed in Greece and you invoice as usual. The threshold is €10,000 a year, measured across the EU in aggregate, not per country: three countries at three thousand euro each count together. Above it, the place of taxation shifts to the customer's country, so that country's VAT is what is due.
Whether you have crossed the threshold is not something this page can tell you. It is a question about your own books, and your accountant answers it. Everything that follows assumes the answer is yes.
One distinction is worth stating, because it is often put the wrong way round. What becomes compulsory above the threshold is the destination country's VAT. OSS is the simplification that lets you declare and remit it through a single return, instead of registering separately in every member state you sell into. The alternative to OSS is not carrying on with Greek VAT. It is twenty-six registrations.
The worked example, followed all the way through
A retail sale of goods worth €100 to a private buyer in Italy, where VAT is 22%.
| Component | Amount |
|---|---|
| Value of goods | €100.00 |
| Greek VAT | €0.00 (0%, with a VAT exemption reason) |
| Destination country VAT, as its own line | €22.00 |
| Total net value | €122.00 |
| Total VAT on the document | €0.00 |
| Payable | €122.00 |
The totals read oddly at first glance and deserve a sentence. The customer pays €122, which is exactly what they were quoted, while the document declares zero Greek VAT, because nothing is owed in Greece. The €22 is remitted to Italy through the OSS return, not through the Greek VAT return. The document is the record of the transaction, not the mechanism that pays the tax.
The document: type 11.1, two lines
The document type is 11.1, a retail receipt, the same as for a Greek customer. There is no OSS type. What changes is the lines.
The goods line
The value of the sale, with vat_rate zero and a VAT exemption reason. An income classification, as on any retail sale of goods.
The foreign VAT line
The destination country's VAT, again with vat_rate zero and a VAT exemption reason, classified as category1_95, the «λοιπά πληροφοριακά» category.
The totals
Sent complete at both levels: net 122, VAT 0, total 122, payable 122.
The VAT exemption reason for the Union OSS scheme is code 30, «Χωρίς ΦΠΑ – άρθρο 57 του Κώδικα ΦΠΑ (OSS ενωσιακό καθεστώς)». Under the older ν.2859/2000 numbering it was άρθρο 47γ, and you will still meet it that way in older material and in order feeds. The full code table is in the reference tables for VAT exemption reasons, and live per account from GET /vat_exemptions.
{
"invoice_type_code": "11.1",
"billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"payment_method_type": 3,
"counterpart": {
"name": "Giulia Rossi",
"country_code": "IT",
"city": "MILANO",
"street": "VIA DANTE",
"number": "12",
"postal_code": "20121"
},
"net_total_amount": 122.0,
"vat_total_amount": 0,
"total_amount": 122.0,
"payable_total_amount": 122.0,
"invoice_lines": [
{
"line_number": 1,
"name": "Πώληση αγαθών εξ αποστάσεως (OSS)",
"quantity": 1,
"quantity_type": 1,
"unit_price": 100.0,
"net_total_price": 100.0,
"vat_rate": 0,
"vat_exemption_code": 30,
"vat_total": 0,
"subtotal": 100.0,
"classification_category": "category1_1",
"classification_type": "E3_561_003"
},
{
"line_number": 2,
"name": "ΦΠΑ χώρας προορισμού (IT 22%)",
"quantity": 1,
"quantity_type": 1,
"unit_price": 22.0,
"net_total_price": 22.0,
"vat_rate": 0,
"vat_exemption_code": 30,
"vat_total": 0,
"subtotal": 22.0,
"classification_category": "category1_95",
"classification_type": "_"
}
]
}
Replace billing_book_id with the id of your own billing book for type 11.1, from GET /billing_books.
The part that does not discover itself
Line 2 needs a VAT exemption reason too. This is where most of the time goes, and the reason is that the opposite assumption is entirely reasonable: on other document types, such as an advance-collection receipt, category1_95 is a genuinely VAT-less line that takes no code. On an 11.1 it is an ordinary VAT category 7 line, and without a code the document is rejected with 217.
The failure has nothing to do with the counterpart's country_code. Same line, same error, whether the buyer is Italian or Greek.
The minimum shape, and why it is not the one you build
The document also goes through clean with a single line, the goods line, and no foreign VAT line at all. It is worth knowing as the minimum valid shape. But it leaves the document's payable total at 100 while the customer paid 122, and that gap is what makes the two-line form the one you want in production.
A ΜΑΡΚ does not mean the coding was right
myDATA does not validate the VAT exemption reason semantically. The same document carrying the wrong code, for instance the generic code for supplies of goods outside Greece instead of the Union OSS code, goes through equally clean: it gets a ΜΑΡΚ, produces a valid document and a QR the customer can scan, and nothing signals a problem.
The mistake surfaces in the VAT return and the OSS return, months later, not at transmission. It is the most useful thing on this page, because it generalises well past OSS: it holds for every exemption reason. A ΜΑΡΚ proves the document was accepted. It never proves the coding was right.
In practice that means you cannot use myDATA as a safety net for the tax decision. The check has to be yours, before transmission.
What you see when it is wrong
| Mistake | myDATA response |
|---|---|
The foreign rate passed straight through as a Greek vat_rate, e.g. 22 |
216 «Vat category must have value other than 8 for this invoice type» and 229 «vatAmount is not correct according to the given: vatCategory(invoice line: 1» |
The category1_95 foreign VAT line at 0% with no exemption reason |
217 «When vatCategory has value 7, element vatExemptionCategory is mandatory» |
The mechanism behind 216 is worth one line, for anyone who would rather understand than copy: an unrecognised rate does not raise «unknown rate». It falls through to VAT category 8, «άνευ ΦΠΑ», which the retail document type forbids. That is why the error names a category you never sent.
Both are terminal. A myDATA rejection burns the draft: it cannot be re-issued, the number is gone, and a fresh document has to be built. This is not the retry-and-move-on class of error.
No cash register required
For distance sales falling under OSS, retail documents may be issued by any suitable means, even in cases where ΦΗΜ use is otherwise compulsory. The data then reaches myDATA through the other transmission channels, and the first of those named is certified electronic issuing providers.
For an e-shop that is the practical takeaway: the receipt can come straight out of your order flow, through a provider, with no cash register in the middle. The same holds for e-shops and marketplaces automating the path from order to document.
What this guide does not cover
| Out of scope | Why |
|---|---|
| Registering for OSS, the quarterly return, and paying the tax | ΑΑΔΕ covers this on its own OSS pages. This page is about the document. |
| Which country's rate applies to a given sale | Place-of-supply determination depends on the goods, the thresholds and the shipping arrangement. Your accountant's call. |
| Sales to a business in another member state | A different transaction and a different document: an invoice rather than a receipt, with its own exemption reason. The intra-community invoice guide covers it. |
| Non-Union OSS and IOSS | Separate schemes with their own exemption reasons. Non-Union covers taxable persons not established in the EU; IOSS covers imported goods in consignments of intrinsic value up to €150. |
| Whether a particular business has crossed the threshold | That is a fact about its books, not something a page can assert. |
How you get started
For access to the staging environment, fill in the form on the API partnership page with your VAT number. Your staging account is created automatically and we will come back to you with your credentials. You will need a billing book for type 11.1 before you send the first draft.
The full field schema is in the REST API documentation. If you are building a platform that invoices on behalf of its own customers, partner API onboarding is the piece that creates their accounts. The accepted values referenced here are in the reference tables for invoice types, classification types and VAT exemption reasons.
The structure given in this article is what we typically see in practice. The classifications, the VAT rates and the exemption reasons are an accounting decision though, so confirm them with the end customer or their accountant before going to production. myDATA does not validate them and will accept a wrong choice without an error.
Frequently asked questions
I sold to a private buyer in Italy. Which document do I issue?
A retail receipt, type 11.1, exactly as you would for a Greek customer. What changes is not the document type but the VAT on it: the goods line goes out at 0% with a VAT exemption reason, because no Greek VAT is due, and the Italian VAT becomes a line of its own. myDATA has no separate document type for OSS.
Why can I not just put 22% in vat_rate?
Because that field declares a Greek rate, and 22 is not a Greek rate. An unrecognised rate does not raise «unknown rate»: it falls through to VAT category 8, «άνευ ΦΠΑ», which the retail document type forbids. You get 216 and 229, and the rejection burns the document along with its number. It is the most natural mistake in this flow, because 22 looks obviously correct.
Where does the destination country VAT actually go?
On a second line of the same document, at 0%, with a VAT exemption reason, and classification category1_95, the «λοιπά πληροφοριακά» category. The customer then sees and pays the amount they were quoted, while the document declares zero Greek VAT, which is correct: nothing is owed in Greece. That amount is remitted to the destination country through the OSS return, not through the Greek VAT return.
Does the destination VAT line need an exemption reason too?
Yes, and this is the part that does not discover itself. On other document types category1_95 is a genuinely VAT-less line that takes no code, so assuming the same here is entirely reasonable. On an 11.1 it is an ordinary VAT category 7 line, and without a code the document dies with 217. The failure has nothing to do with the counterpart country.
If I pick the wrong exemption reason, will myDATA catch it?
No. myDATA does not validate the exemption reason semantically. A document with the wrong code goes through clean, gets a ΜΑΡΚ, produces a valid QR the customer can scan, and nothing signals a problem. The mistake surfaces in the VAT return and the OSS return, months later. A ΜΑΡΚ proves the document was accepted. It never proves the coding was right.
From what point must I charge the customer country VAT?
The threshold is €10,000 a year and it is measured across the EU in aggregate, not per country. Above it the place of taxation shifts to the customer country, so that country VAT becomes due. Whether you have crossed it is a question about your own books and your accountant answers it, not a web page.
Is OSS itself compulsory?
No, and the distinction matters. Above the threshold, what becomes compulsory is the destination country VAT. OSS is the simplification that lets you declare and remit it through a single return instead of registering in every member state you sell into. The alternative to OSS is not carrying on with Greek VAT, it is registering separately everywhere.
Do I need a cash register for these receipts?
Not necessarily. For distance sales falling under OSS, retail documents may be issued by any suitable means even where ΦΗΜ use is otherwise compulsory, and the data reaches myDATA through the other transmission channels. The first of those listed is certified electronic issuing providers. In practice that means the receipt can come straight out of your e-shop flow through a provider, with no cash register involved.
What about sales to a business in another member state?
That is a different transaction and a different document. Intra-EU B2B is an invoice, not a retail receipt, and it carries its own exemption reason. The intra-community invoice guide covers it separately. OSS is about sales to private consumers.
What about non-Union OSS, or low-value imports?
Those are separate schemes with their own exemption reasons. The non-Union scheme covers taxable persons not established in the EU. IOSS covers distance sales of goods imported from third countries, in consignments of intrinsic value up to €150. The full code list is in the reference tables for VAT exemption reasons.
How do I test before going to production?
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.