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

> Who issues what and when, the order of steps from taking in the goods to settling up, the three fields that keep a 1.5 valid, and complete payloads you can copy.
>
> AI-friendly Markdown version. HTML version: https://wrapp.ai/en/resources/mydata-sales-on-behalf-of-third-parties-api
> EL version: https://wrapp.ai/el/resources/poliseis-gia-logariasmo-triton-mydata-api.md

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.

**The 1.4 goes to the buyer, at the moment of sale. The 1.5 goes to the principal afterwards, to settle up.**

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

01

### You take delivery

The principal delivers the goods to you, with a delivery note where one is required. Ownership stays with them.

02

### You sell: the 1.4

You invoice the buyer in your own name, for the full sale value, with the classification that says the income is not yours.

03

### You settle: the 1.5

You issue the principal one document with two lines, the clearance and your fee, and pay them the balance.

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

| Issuer | 1.4 to | 1.5 to |
| --- | --- | --- |
| Agricultural cooperative, producer group | wholesaler, retail chain | the member producer |
| Olive mill | the oil buyer | the producer |
| Fish market, produce market | the winning bidder | the fisherman or grower |
| Agency or representative selling in its own name | the customer | the principal |
| Marketplace or platform that invoices the buyer itself | the end buyer | the merchant |
| Consignment, retail sale-or-return | the consumer | the supplier |

### 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`.

POST /api/v1/invoices

```json
{
  "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.

| Field | Where | What it does, and what happens without it |
| --- | --- | --- |
| `invoice_detail_type` | On **every** line | Integer. `1` the clearance, `2` the fee. Missing it gives **246** plus **204** |
| `expense` | Clearance line | Boolean `true`. Routes the pair into `expensesClassification`. Without it, a **101** on every line |
| `classification_type` | Clearance line | The literal value `"_"`, meaning "no E3 code". `""` and `null` do **not** work |

**`expense` is not decoration, and leaving it out does not fail silently.** Omit it, or send `false`, while keeping `category2_9`, and both lines are serialised as `incomeClassification`, where `category2_9` is not in the list of values. myDATA answers **101**, once per line, with "The Enumeration constraint failed". If you see `incomeClassificaton` in the message on a 1.5, you forgot `expense`.

`"_"` 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%.

| Leg | Amount |
| --- | --- |
| Real sale to the buyer, the 1.4 | 1,000 plus VAT at 13% = **130** |
| Agreed fee, 20% | 200 |
| Deemed delivery, the clearance line | 800 plus VAT at 13% = **104** |
| VAT remitted by the cooperative | **26** |
| VAT remitted by the farmer | **104** as output tax |

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`.

POST /api/v1/invoices

```json
{
  "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"
    }
  ]
}
```

**Why the value `2` in our example.** VAT exemption reason `2` is «Άρθρο 5 (Παράδοση αγαθών)», article 5 on the supply of goods, which is **the very article the whole scheme rests on**: under article 5(2) the second transaction is a supply of goods and not a supply of services, so the fee carries no VAT of its own. The reason you declare says *why* the line sits at 0%, and here that reason is precisely that article.

The full list of reasons and their codes comes from the API: `GET /api/v1/vat_exemptions`, which returns code and description pairs, for example `"2": "Άρθρο 5 (Παράδοση αγαθών)"`. The same values are in the reference table for [VAT exemption reasons](https://wrapp.ai/en/resources/vat-exemption-reasons). **Which one fits your case is a tax decision, not a technical one**, and myDATA does not check it.

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.

| Code | When you get it |
| --- | --- |
| `101` | `category2_9` inside `incomeClassification`, meaning a forgotten `expense: true` |
| `208` | `payable_total_amount` does not equal the sum of the lines |
| `222` | A fee line valued at `0.00`: a nil fee is not possible |
| `231` | An E3 classification on the clearance line, where it is forbidden |
| `246` | A 1.5 without one line of each `invoice_detail_type` |
| `313` | `E3_881_*` on a 1.5, or `"_"` on the fee line: the combination is not permitted |
| `331` | `category1_7` on the fee line: no validation document exists for the pair |

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:

notes on the header

```json
{
  "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.

| Case | Liable party |
| --- | --- |
| Clearance issued **beyond the month** of the real sale | the **commission agent**, for the whole tax. The amount paid to the principal carries no VAT |
| Clearance issued **within the same month** | **both**, each on their own delivery, real and deemed |
| Farmers under the **special regime**, article 48 | the **commission agent**, in every case, regardless of timing |

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](https://wrapp.ai/en/api/becomeapartner) 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](https://wrapp.ai/api/documentation), and the sibling guide to [fuel codes](https://wrapp.ai/en/resources/mydata-fuel-codes-api-fuel-stations) 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](https://wrapp.ai/api/partnersonboarding) is the piece that creates their accounts. The accepted values referenced here are in the reference tables for [invoice types](https://wrapp.ai/en/resources/invoice-types), [classification types](https://wrapp.ai/en/resources/classification-types) and [VAT exemption reasons](https://wrapp.ai/en/resources/vat-exemption-reasons).

If the broader question is what changes across the board for issuing invoices from [1 October 2026](https://wrapp.ai/en/resources/mandatory-e-invoicing-greece-october-2026), the timeline and the obligations are there.

*The examples and payloads in this article show **structure**: which fields you send and where each one goes. The **classifications**, the **VAT rates**, the **exemption reasons** and the **line values** are tax decisions belonging to each entity, and they are made **solely on the direction of that entity's accountant**, never on the basis of an article or an example, including this one. myDATA does not validate them: it will accept a wrong choice without an error.*

## Frequently asked questions

### Which of the two do I issue, a 1.4 or a 1.5?

Both, at different moments and to different recipients. The 1.4 goes to the buyer, at the moment of sale. The 1.5 goes to the principal afterwards, to settle up. Same issuer, two recipients. That distinction is the one people get wrong most often.

### When do I issue neither of them?

When you own the goods. If you bought the stock and resell it on your own account you are not a commission agent: you issue an ordinary 1.1 invoice and separately hold a purchase document, either a purchase invoice or a 3.1 title of acquisition where the supplier has no obligation to issue. Whether an entity is a commission agent or a buyer-reseller is a call for its accountant, not for the API.

### Why do I get a 313 when I put E3_881_001 on a 1.5?

Because the E3_881_* family means "sales on behalf of third parties" and they are income codes belonging to the 1.4. On a 1.5 the combination of type, category and document type is not permitted, so myDATA answers 313. This is the most common mistake on this pair. The correct clearance line wants category2_9 with the "_" classification, and the accepted combinations are in the reference tables for classification types.

### What is the "_" classification?

It means "no E3 code". On the clearance line of a 1.5 it is the only accepted value under category2_9, and it is mandatory. An empty string and null both fail, because neither is a member of the permitted list. On the fee line it is the other way round: "_" is rejected with a 313, because a real E3 code is required there.

### What does a 1.5 absolutely need in order to pass?

Three things. First, invoice_detail_type on every line: 1 for the clearance, 2 for the fee. Leave them out and you get a 246 plus a 204. Second, expense: true on the clearance line, which routes the pair into expensesClassification. Without it the lines go out as incomeClassification, where category2_9 does not exist, and you get a 101 on every line. Third, the "_" classification on that same line.

### How do I confirm the fields landed correctly?

By reading the document back. Both find_invoice_by_id and find_all_invoices return invoice_detail_type and expense alongside the classifications, the amounts, quantity_type and the exemption reason. Check that the clearance line came back with invoice_detail_type 1, expense true and category2_9, that the fee line came back with invoice_detail_type 2 and a real E3 code, and that a ΜΑΡΚ is present. GET /invoices/{id} is deliberately lean, so it is not the right endpoint for this check.

### What value goes on the clearance line, and what VAT on the fee?

Article 5(2) of the Greek VAT Code (ν.5144/2024) deems a supply of goods to take place between the commission agent and the principal, and Ε.2181/2020 explains that this supply is valued at the sale less the fee, while the fee is not a supply of services: its VAT already sits inside the taxable base of the real sale, so it is not taxed again. In the article's example, a sale of 1,000 with a fee of 100, the clearance line goes in at 900. The final choices are tax decisions and are made with the entity's accountant.

### Why does the 1.5 total not match what I pay the producer?

Because myDATA requires payable_total_amount to equal the sum of the lines, or it answers 208. The fee adds to the document total while economically it is deducted from what the principal receives. The document cannot state the amount genuinely payable, which is why many clearance documents in the wild carry a separate free-text line with the net payable.

### Who remits the VAT on a commission sale of agricultural products?

It depends on when the clearance is issued and on the principal's VAT regime. Under article 40(1)(a) of the Greek VAT Code (ν.5144/2024) and Ε.2181/2020, where the clearance is issued beyond the month of the real sale, the commission agent is liable for the whole tax and the amount paid to the principal carries no VAT. Within the same month both are liable, each on their own delivery. For farmers under the special regime of article 48 the commission agent remits in every case. Which regime applies to a particular producer is a question for the accountant, not for the API.

### How do I test before going to production?

Need help? Contact us: https://wrapp.ai/contact