Catering order notes (myDATA 8.6): the 24-hour correlation rule and the API
An order note is not closed by anything your software does. It is closed by the value document that carries its ΜΑΡΚ, and it has 24 hours to get one. The full 8.6 lifecycle: payloads, correlation, cancellation, the error codes you will actually hit, and why a clean ΜΑΡΚ does not prove the correlation happened.
A restaurant takes an order at table 12. A restaurant software platform has to decide what it sends to myDATA and when. An accountant asks what exactly closes an order note. All three are looking at the same document: type 8.6, the catering order note.
An order note is not closed by anything you do in your own system. It is closed by the value document that carries its ΜΑΡΚ, and it has 24 hours to get one.
That is the whole of it, and it is also where the mistake happens. Closing the table is a state in your software. Correlation is an act in myDATA. The two states are unrelated, and a platform can perfectly well show a screen of tidily closed tables with open fiscal obligations sitting underneath.
What an 8.6 is, and what it is not
A catering order note is not a legal value document. It is a special document carrying the provider mark, it creates no payable amount, and it does not replace the receipt. It records the order, at the moment the order happens.
What closes it is stated plainly: it is correlated with value documents, meaning a retail sales receipt or a retail credit receipt for retail transactions, and an invoice or credit invoice for wholesale ones. There is no separate close step in myDATA. The correlation is the close.
Which of those two paths applies to you is not something this page answers. The text names both, and the choice follows the transaction and the books. That is your accountant's call.
The 24-hour rule
Order notes are transmitted to myDATA and take a ΜΑΡΚ. Their correlation with the revenue documents that relate to them is carried out within twenty-four hours of their issue.
The 24 hours are not a transmission deadline. This is misread constantly. Transmission is immediate and the note takes its ΜΑΡΚ as it is issued. The 24 hours measure something else: when the note has to have acquired the document that closes it.
And if it does not, the text says what follows. The provider is obliged to suspend the authentication and transmission of the entity's data as a whole, until the correlation of the open notes is completed.
That is worth reading twice. The obligation sits with the provider, not the business. But what gets suspended is the entity's data as a whole, meaning issuing stops for every document the business produces, not only for order notes. A data-modelling decision inside a piece of software reaches the till of a restaurant that way, on a Saturday night.
An open table is not the problem
This is the reassuring half, and it matters just as much. AADE requires the table number as a field of the document, and describes the 8.6 as carrying data for the management of open tables. What it does not do anywhere is define a table object, or an open and close lifecycle for one.
The table in your software is your own convenience. It is not a fiscal entity, and a table left open is not in itself a breach. What counts is an order note left uncorrelated.
The example this article follows throughout
| Step | Document | Net | VAT | Total |
|---|---|---|---|---|
| The kitchen accepts the order | 8.6, table 12 | 19.11 € | 2.99 € | 22.10 € |
| 2 × Briam, VAT 13% | line 1 | 17.70 € | 2.30 € | 20.00 € |
| 1 × Water 1lt, VAT 24% | line 2 | 1.41 € | 0.69 € | 2.10 € |
| The guest pays | 11.1, carrying the note's ΜΑΡΚ | 19.11 € | 2.99 € | 22.10 € |
Two VAT rates on one note deliberately: food at 13% beside a drink at 24% is the ordinary restaurant case, and the text asks for net values and VAT amounts per VAT rate. A single-rate example would show you none of that.
The note: what is actually mandatory in the body
Explicit per-line amounts
Every line needs its own net_total_price, vat_total and subtotal. They are not computed from quantity and unit price.
Explicit document totals
All four of them: net_total_amount, vat_total_amount, total_amount, payable_total_amount.
An open table
catering_table_id points at a table of yours, in an open state. It is a platform object, not a fiscal one.
{
"invoice_type_code": "8.6",
"billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"catering_table_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"counterpart": {
"name": "Τραπέζι 12",
"vat": "",
"city": "",
"street": "",
"number": "",
"postal_code": ""
},
"net_total_amount": 19.11,
"vat_total_amount": 2.99,
"total_amount": 22.10,
"payable_total_amount": 22.10,
"invoice_lines": [
{
"line_number": 1,
"name": "Μπριάμ",
"quantity": 2,
"quantity_type": 1,
"unit_price": 8.85,
"net_total_price": 17.70,
"vat_rate": 13,
"vat_total": 2.30,
"subtotal": 20.00
},
{
"line_number": 2,
"name": "Νερό 1lt",
"quantity": 1,
"quantity_type": 1,
"unit_price": 1.41,
"net_total_price": 1.41,
"vat_rate": 24,
"vat_total": 0.69,
"subtotal": 2.10
}
]
}
Replace billing_book_id with the id of your own billing book for type 8.6, from GET /billing_books, and catering_table_id with an open table from catering_tables.
The lines here carry no classifications, and that is worth a sentence. The note is not a value document, so it classifies no revenue. Classifications on a note do not cause a rejection: it issues clean with them too. They are simply not needed. Do not generalise in the other direction though: the receipt that closes the note is an ordinary revenue document and needs its own.
The receipt that closes it
Correlation happens from the receipt's side, with the note's ΜΑΡΚ inside correlated_invoices. On the issued document it appears as ΣΥΣΧ.
{
"invoice_type_code": "11.1",
"billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"payment_method_type": 3,
"correlated_invoices": ["400001900000000"],
"counterpart": {
"name": "Retail customer",
"country_code": "GR",
"city": "ΑΘΗΝΑ",
"street": "ΕΡΜΟΥ",
"number": "1",
"postal_code": "10563"
},
"invoice_lines": [
{
"line_number": 1,
"name": "Μπριάμ",
"quantity": 2,
"quantity_type": 1,
"unit_price": 8.85,
"vat_rate": 13,
"classification_category": "category1_1",
"classification_type": "E3_561_003"
},
{
"line_number": 2,
"name": "Νερό 1lt",
"quantity": 1,
"quantity_type": 1,
"unit_price": 1.41,
"vat_rate": 24,
"classification_category": "category1_1",
"classification_type": "E3_561_003"
}
]
}
If the bill is settled by two receipts, the same ΜΑΡΚ goes on each of them. It is not divided: the same value, twice. The text is plural, referring to the revenue documents that relate to the note, and technically both are accepted. There is no explicit AADE statement covering the split bill, so we are not telling you that you must. The conservative build correlates every receipt that settles the note.
A ΜΑΡΚ does not prove the correlation
correlated_invoices is write-only. No read endpoint returns it, so you cannot audit your own correlation by reading documents back. And a ΜΑΡΚ that does not exist is accepted without an error, as is an empty array.
Those two behaviours together are the dangerous case in this flow. The receipt issues clean, takes a valid ΜΑΡΚ of its own, the guest leaves with a perfectly ordinary document, and nothing indicates that the note stayed open. The next signal is the suspension, 24 hours later.
In practice: the record of what was correlated has to live in your own system. myDATA will not hand it back to you, and the API will not tell you that you missed.
How you see what is still open
{
"invoices": [
{
"id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"issued_at": "2026-08-25T21:45:07.739+03:00",
"my_data_mark": "400001900000000",
"catering_table_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
],
"total_pages": 1,
"current_page": 1
}
GET /invoices/list_open_catering_order_notes is the only visible picture of what is counting down. It returns the notes that have not been correlated, with the issue time next to the ΜΑΡΚ, so the age of each open obligation is a subtraction. If you build one thing on top of issuing itself, build this: a job that watches the list and raises an alert, rather than a person who remembers to look.
Cancellations, comps and guests who walked out
A document that has taken a ΜΑΡΚ is never unmade. It is not altered, not deleted, and any attempt to change it returns an error. A correction is always a new document.
{
"billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"correlated_invoices": ["400001900000000"]
}
The call issues a new 8.6 on the same table: one line, every amount zero, correlated to the original, with a ΜΑΡΚ of its own. The original keeps its own. billing_book_id is required and has to be the 8.6 book. catering_table_id is optional: when it is missing, the platform resolves it from the note you are cancelling.
Whether that satisfies the fiscal obligation in a given case is not something this page answers. The text describes correlation with value documents, and a guest who left without paying produces no value document at all. What is described here is the mechanism the platform provides. Whether it covers your case is a question for your accountant.
A comped item never sits beside charged lines. Every charged line has to carry a net value greater than zero, so a mixed note is rejected. The comped item goes on a note of its own with every amount at zero, under exactly the same constraint that produces the cancellation document.
What you see when it is wrong
| Mistake | Response |
|---|---|
| A line with no explicit net value, or a zero line beside charged ones | 222 «NetValue per line, which have recType != 6, must have value greater than 0 for this invoice type» |
| Document totals missing, or not matching the lines | 207 and 208, for the net and the gross value respectively |
| An attempt to change a document that already holds a ΜΑΡΚ | 249 |
| Cancelling without the 8.6 billing book, or with one of another type | Billing book not found. This is not a myDATA error, it is the platform |
Cancelling without correlated_invoices |
correlated_invoices is required, again from the platform |
That last distinction earns its space. The final two rows do not come from AADE. A developer who assumes every failure is myDATA will look in the wrong place, and the message does not resemble the others precisely because it is not one of them.
What has to appear on the slip
The fields the text sets out are mandatory on issue, on print and on scan: the issuer's VAT number, name and premises address, the document type, series and number, date and time of issue, item, quantity, net values per VAT rate, VAT amounts per rate, the table number, and the total amount of the transaction.
With one important exception, which looks contradictory and is not: the total amount is a mandatory field of the document but is not printed, neither for the current serving nor for anything carried over from a previous one. The amount travels in the data; it does not go on the paper.
On top of those, three more: a mandatory QR code whose scan leads to a provider page, the issue time clearly visible in a bold font, and the bilingual wording, verbatim:
«ΤΟ ΠΑΡΟΝ ΕΙΝΑΙ ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΤΟΙΧΕΙΟ ΚΑΙ ΔΕΝ ΑΠΟΤΕΛΕΙ ΝΟΜΙΜΗ ΦΟΡΟΛΟΓΙΚΗ ΑΠΟΔΕΙΞΗ/ΤΙΜΟΛΟΓΙΟ. THE PRESENT DOCUMENT IS ISSUED ONLY FOR INFORMATION PURPOSES AND DOES NOT STAND FOR A VALID TAX RECEIPT/INVOICE.»
Where the rule is written
In article 9 of A.1112/2025, Government Gazette B' 4206/1.8.2025, on the content of document type 8.6. Nine paragraphs, and it is the text in force.
You will find the reference «άρθρο 7Α of Α.1126/2024» everywhere. It is repealed. 7Α had been inserted into Α.1035/2020, and Α.1035/2020 ceased to apply when Α.1112/2025 came into force. The substance carried over almost unchanged, but the wording did not: the note is now correlated with value documents, where the old text said it closes with them.
The full text is published by AADE. The business analysis and the technical documentation for type 8.6 are posted by AADE at aade.gr/mydata.
How to start
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 8.6 and one for the receipt type that closes the note.
The full field schema, including catering_tables and the cancellation call, is in the REST API documentation. If you are building a hospitality platform that invoices on behalf of its own customers, partner API onboarding is the piece that creates their accounts, and the guide to the hospitality platform and the e-invoicing provider covers the wider picture. The accepted values are in the reference tables for invoice types and classification types.
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
What is a catering order note, and what closes it?
It is myDATA document type 8.6, the digital equivalent of the paper order slip. It is not a legal value document: it is a special document carrying the provider mark, and it creates no payable amount. What closes it is a value document that carries its ΜΑΡΚ: a retail receipt or credit receipt for retail, an invoice or credit invoice for wholesale. There is no separate close step in myDATA.
I close the table in my own system. Is that not enough?
No, and this is the most common misunderstanding. The table is an object in your software. The order note is a fiscal document in myDATA. Neither touches the other: you can have a screen full of tidily closed tables and a set of open notes underneath, or the reverse. An open table is not a compliance problem. An uncorrelated order note is.
What exactly do the 24 hours require?
That the order note is correlated with the revenue documents that relate to it within twenty-four hours of its issue. Read that carefully, because it circulates wrongly: the 24 hours are not a transmission deadline. Transmission is immediate and the note takes its ΜΑΡΚ straight away. The 24 hours are about correlation, meaning the note acquiring the document that closes it.
What happens when the 24 hours pass?
Article 9 of A.1112/2025 places an obligation on the provider to suspend authentication and transmission of the entity's data as a whole, until the correlation of the open notes is completed. In practice that means issuing stops, not only for order notes but for every document the business issues. The duty sits with the provider; the consequences land on the till.
The bill was split across two receipts. Which one carries the note's ΜΑΡΚ?
The text is plural, referring to the revenue documents that relate to the note, and technically both are accepted: the same ΜΑΡΚ goes on each receipt, it is not divided between them. There is no explicit AADE statement covering the split bill, so we are not telling you that you must. We are telling you that the conservative build puts the ΜΑΡΚ on every receipt that settles the note, and that this works.
The guest walked out without paying. What do I do with the note?
The note already has its ΜΑΡΚ and cannot be unmade: no document holding a ΜΑΡΚ is ever altered, a correction is always a new document. The platform gives you a cancellation call, which issues a new 8.6 on the same table with zero amounts, correlated to the original. Whether that satisfies your fiscal obligation in a given case is a question for your accountant: article 9 describes correlation with value documents and says nothing about a transaction that never happened.
Can I see which notes are still open through the API?
Yes, and it is the most useful endpoint in this flow. GET /invoices/list_open_catering_order_notes returns the notes that have not been correlated, with their ΜΑΡΚ, issue time and table. That list is the closest thing to a warning before the 24 hours run out, and it deserves something of yours watching it rather than a person remembering to look.
Can I read the correlation back to confirm it landed?
No, and you need to know that before you build on it. The correlated_invoices field is write-only: no read endpoint returns it. Worse, a ΜΑΡΚ that does not exist is accepted without an error, and so is an empty array. So the receipt issues clean, takes a valid ΜΑΡΚ of its own, and nothing tells you the correlation missed. The record of what was correlated has to live in your own system.
Do the 8.6 lines need classifications?
No, and they do no harm either. A note issues clean with them and without them. The examples here omit them because the note is not a value document and classifies no revenue. Do not generalise from that though: the receipt that closes the note is an ordinary revenue document and needs its own classifications.
Why am I getting error 222 on the note?
Because a line is not carrying its own net value. On an 8.6 every line needs an explicit net_total_price, vat_total and subtotal: they are not computed from quantity and unit price. The same error appears when a zero-value line sits beside charged ones, which is why a comped item goes on its own all-zero note. If the document-level totals are missing instead, the errors are 207 and 208 rather than 222.
What has to be printed on the slip?
The fields set out in article 9 are mandatory on issue, on print and on scan: issuer and premises details, document type, series and number, date and time, item, quantity, net values and VAT per VAT rate, and the table number. The transaction total is a mandatory field of the document but is not printed, neither for the current serving nor for anything carried over. The slip must carry a QR code leading to a provider page, the issue time clearly visible in bold, and the bilingual wording stating that it is not a valid tax receipt or invoice.
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.