Sales on behalf of third parties: issuing myDATA 1.4 and 1.5 documents through the API

A cooperative sells oil belonging to its members. An olive mill sells the producer's output. A marketplace invoices the end buyer for a merchant's goods. In all three, one entity sells, in its own name, goods owned by someone else. myDATA has two documents for exactly that, 1.4 and 1.5, and this guide shows how to send them correctly through the API.

Who issues them, when, and in what order

Who: the commission agent, meaning whoever sells in their own name for someone else's account. They issue both documents. The principal is the owner of the goods: the producer, the cooperative member, the merchant.

When: at two different moments, to two different recipients.

How: the order of steps is fixed, and each step has its own document.

With numbers, so you have something concrete in mind for what follows: you sell 1,000 kilos of oil for 1,000 euro plus VAT at 13%, you keep a fee of 100 euro, and you pay the producer 900 euro plus the VAT due. The 1.4 carries the 1,000. The 1.5 carries both legs, the clearance and the fee.

Before anything else: ownership, and goods or services

Two tests, and they come before all the others. The first is ownership. If you bought the goods and resell them on your own account you are not a commission agent, and you issue neither of these. You issue an ordinary 1.1 invoice and separately hold a purchase document: a purchase invoice, or a 3.1 title of acquisition where the supplier has no obligation to issue one.

The second is goods or services. The 1.4 and 1.5 pair is for goods. If what you intermediate is a service rather than goods, this is not the mechanism you are looking for, and the treatment is a question for your accountant. Your own fee is a different matter: it is invoiced as a service inside the 1.5 itself, as you will see below.

Whether an entity is a commission agent or a buyer-reseller is not something the API answers, and it is not something this article answers. It is a call for its accountant. Everything below assumes that call has been made.

Who issues what, by case

The 1.4: a sale on behalf of a third party

The easy half. One invoice to the buyer, with the classification that says the income is not yours. Replace billing_book_id with the id of your own series, from GET /billing_books.

{
  "invoice_type_code": "1.4",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "payment_method_type": 1,
  "currency": "EUR",
  "net_total_amount": 1000.00,
  "vat_total_amount": 130.00,
  "total_amount": 1130.00,
  "payable_total_amount": 1130.00,
  "counterpart": {
    "name": "ΧΟΝΔΡΕΜΠΟΡΟΣ Α.Ε.",
    "country_code": "GR",
    "vat": "059686915",
    "city": "ΑΘΗΝΑ",
    "street": "ΛΙΟΣΙΩΝ",
    "number": "298",
    "postal_code": "10445"
  },
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Πώληση για λογαριασμό τρίτου",
      "quantity": 1000,
      "quantity_type": 2,
      "unit_price": 1.00,
      "net_total_price": 1000.00,
      "vat_rate": 13,
      "vat_total": 130.00,
      "subtotal": 1130.00,
      "classification_category": "category1_7",
      "classification_type": "E3_881_001"
    }
  ]
}

category1_7 ("income on behalf of third parties") is the only category that works here: category1_1 and category1_3 both return 331, and category1_95 returns 313. Within it, the code changes with the destination: E3_881_001 for domestic wholesale, E3_881_003 for intra-community, E3_881_004 for third countries. No invoice_detail_type here: that field belongs to the 1.5 alone.

And this is where the pair's most common mistake starts: these codes stay in mind and get carried over to the 1.5. The E3_881_* family means "sales on behalf of third parties" and belongs to the 1.4 alone, so on a 1.5 myDATA answers 313. A 1.5 wants entirely different classifications, one per line, and that is what comes next.

The 1.5: the three fields that decide whether it passes

A 1.5 carries two lines, the clearance and the fee, and three fields work together to keep it valid. Leave any of them out and myDATA rejects the document, so they are worth seeing together.

"_" is the one that unblocks most people. Under category2_9 ("expenses on behalf of third parties") it is the only permitted value, and it is mandatory: an empty string and null are not members of the list. On the fee line the reverse applies, "_" is rejected with a 313, because a real E3 code is required there. And the fee line accepts category1_1, category1_2 or category1_3, never category1_7, which returns 331.

What the law says about the values and the VAT

The 1.5's structure is settled. The values on its two lines and their VAT do not follow from the schema, they follow from the law, and myDATA does not enforce them: it will accept numbers that do not stand up for tax purposes.

The Greek VAT Code, ν.5144/2024 (ΦΕΚ Α΄ 162/11.10.2024), governs it in article 5(2):

«Κατά την πώληση ή αγορά αγαθών από παραγγελιοδόχο που ενεργεί στο όνομά του, θεωρείται ότι συντελείται παράδοση αγαθών μεταξύ αυτού και του παραγγελέα (εντολέα).»

"Where goods are sold or bought by a commission agent acting in their own name, a supply of goods is deemed to take place between that agent and the principal."

So two supplies of the same goods take place: the real one, from you to the buyer, and a second one, from the principal to you. How that second supply is valued, and what happens to the fee, is set out in the interpretative circular Ε.2181/2020, "Application of VAT provisions to commission sales", verbatim:

«στις παραγγελιοδοχικές πωλήσεις αγαθών πραγματοποιούνται δύο παραδόσεις αγαθών και δεν πραγματοποιείται παροχή υπηρεσιών από τον παραγγελιοδόχο προς τον παραγγελέα (εντολέα)»

"in commission sales of goods there are two supplies of goods and no supply of services takes place from the agent to the principal"

Two consequences, and they are what fix the numbers in the payload. First, the second supply is valued at the sale less the fee. Second, the fee is not a service: it is the margin between the two supplies, and its VAT already sits inside the taxable base of the real sale. Taxing it again, the circular says, «θα συνιστούσε διπλή φορολόγηση», would constitute double taxation.

The regulator's own worked example

Example 2 in Part B of the circular: an agricultural cooperative, a farmer under the normal VAT regime, clearance issued within the month, fee of 20%.

The 26 needs care, because it is the point that gets misread. The circular calls it the amount «που αντιστοιχεί στην προμήθειά του», corresponding to its commission, and it is a net remittance, 130 minus 104. It is not VAT charged on a fee line. The cooperative never invoices 200 plus VAT to anybody.

The same ratio holds at any amount: the commission agent remits VAT on their fee as the difference between two supplies, not as additional VAT on a fee line. That is also the key to the numbers in the payload that follows.

The 1.5 payload

Sale of 1,000, fee of 100, the numbers from the top of the article. Clearance line at 900, which is the sale less the fee, and fee line at 0% with vat_exemption_code set to 2.

{
  "invoice_type_code": "1.5",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "payment_method_type": 1,
  "currency": "EUR",
  "net_total_amount": 1000.00,
  "vat_total_amount": 117.00,
  "total_amount": 1117.00,
  "payable_total_amount": 1117.00,
  "counterpart": {
    "name": "ΠΑΡΑΓΩΓΟΣ",
    "country_code": "GR",
    "vat": "059686915",
    "city": "ΑΘΗΝΑ",
    "street": "ΛΙΟΣΙΩΝ",
    "number": "298",
    "postal_code": "10445"
  },
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Εκκαθάριση πωλήσεων τρίτων",
      "quantity": 1,
      "quantity_type": 1,
      "unit_price": 900.00,
      "net_total_price": 900.00,
      "vat_rate": 13,
      "vat_total": 117.00,
      "subtotal": 1017.00,
      "invoice_detail_type": 1,
      "expense": true,
      "classification_category": "category2_9",
      "classification_type": "_"
    },
    {
      "line_number": 2,
      "name": "Αμοιβή από πωλήσεις τρίτων",
      "quantity": 1,
      "quantity_type": 1,
      "unit_price": 100.00,
      "net_total_price": 100.00,
      "vat_rate": 0,
      "vat_total": 0.00,
      "subtotal": 100.00,
      "vat_exemption_code": "2",
      "invoice_detail_type": 2,
      "classification_category": "category1_3",
      "classification_type": "E3_561_001"
    }
  ]
}

Net VAT for the issuer: 130 from the 1.4, less 117 of input from the clearance, less nothing from the fee, equals 13. That is 13% of the 100 fee, the same relationship the regulator's example produces at 200 and 26.

What myDATA validates, and what it does not

Every rule on this pair, with the code you get when you break it. Worth checking on your own side before you send.

And the reverse, which is just as useful: myDATA validates structure, not tax interpretation. It will accept a VAT exemption reason that does not fit and values that do not stand up, with no error at all. The numbers are your responsibility, not the API's.

The total that does not match the amount payable

One practical point, and the most useful one for anybody who hands the document to a producer. Because payable_total_amount must equal the sum of the lines, or a 208 comes back, the fee adds to the document total while economically it is deducted from what the principal receives.

In the payload above the document totals 1,117.00 while the producer receives 1,017.00: the fee of 100 adds to the total instead of being deducted from it.

The document cannot state the amount genuinely payable, even though it exists precisely to tell a producer what they will receive. It is myDATA's rule 208 as it appears on paper, and it applies to every provider. It is why many clearance documents in the wild carry a separate free-text line with the net payable.

The field for that is notes on the header, a free-text string printed on the document:

{
  "invoice_type_code": "1.5",
  "payable_total_amount": 1117.00,
  "notes": "Καθαρό πληρωτέο προς τον εντολέα: 1.017,00 EUR (εκκαθάριση 1.017,00 μείον αμοιβή 100,00)",
  "invoice_lines": [ ... ]
}

notes is text and nothing more: it enters no total, it is not transmitted as an amount, and it changes nothing in myDATA. It serves the person holding the document, not the audit.

Agricultural products: the timing of the clearance changes who is liable

For cooperatives, olive mills and fish markets, the first rows of the table further up, there is one further distinction the other cases do not have. It is not structural: it changes who remits the tax. It comes from article 40(1)(a) of the Greek VAT Code (ν.5144/2024), which names the liable party explicitly.

Two limits, both important. The test is when the clearance is issued relative to the month of the real sale, not any filing deadline. And article 40 names the principal: they must be a farmer who is a natural person, an agricultural cooperative, or a legal person whose activity is exclusively agricultural. This is not a rule about "agricultural products" in general.

Which regime applies to a particular producer is not something your API knows, and not something this article answers. You now know the question exists and that it changes the answer, which is half the work.

How you get started

To get 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 billing books for both document types, 1.4 and 1.5, before you send your first draft.

The full field schema is in the REST API documentation, and the sibling guide to fuel codes covers fuel station documents the same way, and if you are building a platform that invoices on behalf of its own customers, the partner onboarding API 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.

If the broader question is what changes across the board for issuing invoices from 1 October 2026, the timeline and the obligations are there.

Frequently asked questions

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.