myDATA fuel codes (fuel_code): issuing fuel station documents through the API

A fuel station issues the same documents as any other business, with one difference: myDATA wants to know which fuel was sold on each line. That takes two fields, a switch in the header and a code on the line.

{
  "fuel_invoice": true,
  "invoice_lines": [
    { "fuel_code": 20 }
  ]
}

Those two are the whole foundation. The rest of this article is where each field belongs, what it accepts, what ΑΑΔΕ rejects, and two complete payloads you can copy.

First, the question underneath: is retail through a provider allowed?

The common assumption is that a station is tied to a fiscal device and that providers are for wholesale and fleet sales only. That is not the case, and the answer sits in the text of the decision itself.

Two qualifications worth as much as the conclusion. First, that decision governs transmission. The right to issue a marked retail document requires a licensed ΥΠΑΗΕΣ provider, which is a different thing from a myDATA connection. The distinction is set out in the article on connecting a SaaS or ERP to myDATA.

Second, and this is where most of the confusion lives: the εισροές-εκροές input-output measuring system is a separate obligation and none of the above touches it. The provider handles the marking and the transmission of the document. Measuring the fuel in the tanks and at the pumps stays exactly where it was.

The four fields, and where each one lives

Placement is half the work here, because a field at the wrong level does not raise an error. It is simply ignored.

The myDATA fuel codes

Twenty eight fuel codes, plus the value 999 for other service charges. They are sent as integers, not strings. A code outside the list is rejected by Wrapp at draft creation, with HTTP 422.

Forecourt: a retail receipt with two fuels and one service

The typical pump document: a retail receipt (type 11.1), a counterpart with a name only, more than one fuel on the same receipt, and a single 999 line for whatever is not fuel. Replace billing_book_id with the id of your own series, from GET /billing_books.

{
  "invoice_type_code": "11.1",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "payment_method_type": 1,
  "fuel_invoice": true,
  "net_total_amount": 91.00,
  "vat_total_amount": 21.84,
  "total_amount": 112.84,
  "payable_total_amount": 112.84,
  "counterpart": {
    "name": "Retail sale",
    "country_code": "GR"
  },
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Unleaded 95",
      "quantity": 40,
      "unit_price": 1.40,
      "net_total_price": 56.00,
      "vat_rate": 24,
      "vat_total": 13.44,
      "subtotal": 69.44,
      "classification_category": "category1_1",
      "classification_type": "E3_561_003",
      "fuel_code": 10
    },
    {
      "line_number": 2,
      "name": "Road diesel",
      "quantity": 20,
      "unit_price": 1.50,
      "net_total_price": 30.00,
      "vat_rate": 24,
      "vat_total": 7.20,
      "subtotal": 37.20,
      "classification_category": "category1_1",
      "classification_type": "E3_561_003",
      "fuel_code": 20
    },
    {
      "line_number": 3,
      "name": "Car wash",
      "quantity": 1,
      "unit_price": 5.00,
      "net_total_price": 5.00,
      "vat_rate": 24,
      "vat_total": 1.20,
      "subtotal": 6.20,
      "classification_category": "category1_3",
      "classification_type": "E3_561_003",
      "fuel_code": 999
    }
  ]
}

Note the 999 line. One per document is allowed, and its net value (5.00) must not exceed the sum of the net values of the other lines (56.00 + 30.00). The classification codes and the payment method code are your own tax decisions per case: the accepted values are in the API documentation.

The three ΑΑΔΕ validation rules

ΑΑΔΕ enforces three rules around these fields, and all three are checked at issue rather than at draft creation.

Heating oil: four mandatory data points

This is where the schema gets demanding, and the demand is not ours. Α.1139/2025 (ΦΕΚ Β΄ 5464/13.10.2025) added a paragraph to Α.1138/2020 providing that, in the case of transmission through a provider of electronic issuing services, heating oil purchase documents used for the heating allowance must carry four additional data points.

The fourth is the one that gets misread. The decision says «επιλέγεται η ένδειξη «Επίδομα Θέρμανσης» της στήλης 40 [Παρατηρήσεις - Επισημάνσεις]», and it reads literally: this is a discrete value in a coded column, not free text. Writing it into notes does not satisfy the requirement. The decision names document types 1.1, 1.4, 1.6, 5.1, 5.2, 11.1 and 11.4.

{
  "invoice_type_code": "11.1",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "payment_method_type": 1,
  "fuel_invoice": true,
  "special_invoice_category": 11,
  "net_total_amount": 800.00,
  "vat_total_amount": 192.00,
  "total_amount": 992.00,
  "payable_total_amount": 992.00,
  "counterpart": {
    "name": "Giannis Ioannou",
    "country_code": "GR",
    "vat": "123456789",
    "supply_account_no": "12345678"
  },
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Heating oil",
      "quantity": 800,
      "unit_price": 1.00,
      "net_total_price": 800.00,
      "vat_rate": 24,
      "vat_total": 192.00,
      "subtotal": 992.00,
      "classification_category": "category1_1",
      "classification_type": "E3_561_003",
      "fuel_code": 30
    }
  ]
}

For a sale to a business rather than a private buyer the structure is the same and the classification changes: invoice type 1.1 with classification_type E3_561_001, because an invoice is always a wholesale document. The four data points still apply, and credit notes are covered too.

The mistake that raises no error

One payload is worth seeing the wrong way round. Below is the most common error in this schema: supply_account_no at the top level instead of inside counterpart.

{
  "fuel_invoice": true,
  "special_invoice_category": 11,
  "supply_account_no": "12345678",
  "counterpart": {
    "name": "Giannis Ioannou",
    "vat": "123456789"
  }
}

The document issues normally. You get no error, and the electricity supply number is simply missing: the API ignores unknown top-level fields rather than rejecting them. The Α.1139/2025 requirement goes unmet with no visible sign. The only way to catch it is to read the document back and confirm the field came with it.

Reading the fields back

fuel_invoice and fuel_code come back from find_invoice_by_id and from find_all_invoices. supply_account_no returns inside counterpart, exactly where you sent it. GET /invoices/{id} is deliberately lean, a fiscal-status projection with ΜΑΡΚ, UID, QR, series and number, so it is not the right endpoint for this check.

Useful for idempotency: external_id is unique per account and a duplicate is rejected at draft creation, so retrying a call after a timeout does not produce a second document. The same field is accepted by find_invoice_by_id in place of the id, so you can read a document back by your own identifier.

What the document itself shows

These fields do not stop at myDATA. The document your customer receives prints the «(Παραστατικό Καυσίμων)» fuel-document marking next to the title, the code with its description on each line, for example «(30 - Diesel Heat)», the «Ειδική Κατηγορία Παραστατικού: Επίδομα Θέρμανσης» category and the «Αρ. Παροχής Ηλ. Ρεύματος» supply number.

Getting started

For access to the staging environment, fill in the form on the API partnership page with your ΑΦΜ. Your staging account is created automatically and we will come back to you with your credentials, so you can test every document type before going to production. The full field schema is in the REST API documentation.

If the question behind all this is broader, namely what changes across the board for issuing 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.