When a Greek business issues an invoice through myDATA, the invoice is not only reported as a document. It also needs to be classified. One of the most important parts of that classification is the E3 type.

For many freelancers and SMEs, E3 codes look confusing at first: E3_561_001, E3_561_003, E3_562, E3_563, and so on. They appear technical, but the idea behind them is simple: they help connect invoice revenue to the correct line of the Greek E3 tax form.

In this article, we explain what E3 types are, why they matter, and how businesses should think about them when issuing invoices through Greek myDATA.

What is the E3 form?

The E3 form is a Greek tax form used to report business income and expenses. It is part of the tax reporting framework for businesses and professionals in Greece.

In the myDATA environment, invoices are transmitted with structured data. That data does not only say that an invoice was issued for a certain amount plus VAT. It also needs to describe the nature of the income: wholesale revenue from services, retail revenue from goods, intra-community revenue, or another business-income category.

AADE's myDATA API documentation describes the transmission of issued invoices, income classifications, received invoice data, and expense classifications as core functions of the system.

What are E3 types in myDATA?

An E3 type is a myDATA classification code that links an invoice line or amount to a specific type of revenue or expense for tax-reporting purposes.

For income invoices, common E3 type codes include values such as:

AADE's documentation lists these E3 classification types, including wholesale, retail, intra-community, third-country, and other sales categories. The exact code matters because it affects how the transaction is reflected in the business's electronic books and later tax reporting.

E3 type vs. income category: what is the difference?

One of the most important things to understand is that an E3 type is usually not used alone.

In myDATA, income classification normally involves at least two concepts: the classification category and the classification type.

The classification category describes the broad nature of the revenue. The classification type is the E3 code, such as E3_561_001.

For a typical service invoice issued by a freelancer to a business customer, the classification may involve category1_3 and E3_561_001. In plain English, that can mean revenue from provision of services, classified as wholesale sales to a business customer.

This combination-based logic is why businesses often see myDATA errors when the invoice type, classification category, and E3 type do not match.

Why E3 classifications matter

E3 types matter because they help ensure that invoice data is reported correctly and consistently.

• how revenue appears in myDATA electronic books;
• how income is grouped for tax-reporting purposes;
• how the accountant reconciles invoice data;
• whether the invoice transmission is accepted or rejected;
• whether later corrections are needed.

The invoice amount is not enough. The type of revenue must also be classified correctly.

A clean classification reduces accounting corrections, avoids technical myDATA errors, and gives the accountant better data.

Common E3 income types explained

E3_561_001 — Wholesale sales to businesses

This is one of the most common income classifications. It generally applies to sales of goods or services to another business or professional, such as a consultant invoicing a company, a designer invoicing an agency, a software developer invoicing a business client, or a B2B service provider invoicing an SME.

E3_561_003 — Retail sales to private customers

This generally relates to sales of goods or services to private individuals. The distinction between B2B and B2C matters because a private customer sale is not classified the same way as a sale to a business customer.

E3_561_005 — Intra-community sales

This type generally relates to sales to customers in another EU Member State, such as a Greek business invoicing a VAT-registered customer in Germany or a consultant providing services to a company in France. These transactions may also involve special VAT treatment, so the E3 type should not be chosen in isolation.

E3_561_006 — Third-country foreign sales

This generally relates to sales outside the European Union, such as a Greek business invoicing a US customer or a freelancer providing services to a UK company. VAT treatment, customer status, place-of-supply rules, and document type all matter.

E3_561_007 — Other sales of goods and services

This is a broader other category. Because other classifications can be sensitive, businesses should avoid using them casually and should confirm the treatment with their accountant.

The same E3 type can appear with different categories

This is where myDATA becomes confusing. The E3 code E3_561_001 can appear in different contexts depending on whether the income category is goods, products, or services.

E3_561_001 alone does not fully describe the transaction. The classification category is also essential. This is why invoicing software should not treat E3 types as a simple dropdown with no context.

Example: freelancer issuing an invoice to a Greek company

Imagine a freelance designer issues an invoice to a Greek company for branding work.

The freelancer is not selling retail goods to a private individual. The freelancer is providing services to a business customer, so the system needs to classify the income accordingly.

Example: freelancer issuing an invoice to a private individual

Now imagine the same designer issues an invoice or retail-type document to a private person.

The work may be similar, but the customer type changes the classification.

Example: Greek consultant invoicing an EU business

A Greek consultant provides services to a VAT-registered business in another EU country.

This type of transaction may also require special VAT handling, depending on the facts. The E3 type should therefore be combined with correct VAT logic.

Why businesses get E3 errors in myDATA

Many myDATA errors happen because one part of the invoice says one thing, while the classification says another. For example, the invoice type may suggest a service invoice, but the classification category or E3 type may not be allowed for that invoice type.

AADE publishes combination rules for valid classification combinations, and software providers often need to check the invoice type, category, and E3 classification together. Official AADE materials include classification combination files, and myDATA validation errors can occur where a classification type is not allowed for a given category or invoice type.

E3 classification is not just accounting terminology. It is also validation logic.

A good invoicing system should prevent users from selecting impossible or incompatible combinations.

How should freelancers think about E3 types?

Freelancers do not need to become tax technicians, but they should understand the basic idea. The key questions are:

1. What am I selling? Goods, products, or services?
2. Who am I selling to? A business, a private individual, an EU customer, or a non-EU customer?
3. What type of invoice am I issuing? Sales invoice, service invoice, retail document, credit note, or another document?
4. What VAT treatment applies? Standard Greek VAT, exemption, reverse charge, intra-community, export, or another case?
5. What does my accountant expect? The accountant's mapping should be reflected in the invoicing system.

For most freelancers, the most common pattern will be service revenue to business clients. Once you add private customers, EU customers, non-EU customers, subscriptions, expenses, or mixed invoices, the classification logic becomes more important.

How should SMEs handle E3 mappings?

For SMEs, the best approach is to define mappings in advance.

This mapping should be reviewed with the accountant and then built into the invoicing software so users do not need to make technical decisions on every invoice.

Why easyTimi cares about E3 classifications

easyTimi is being built around the idea that invoicing should stay simple, even as Greek compliance becomes more technical.

E3 classifications are a perfect example. The user should not have to understand every myDATA rule in detail just to issue a normal invoice.

• suggesting the right classification based on invoice context;
• remembering accountant-approved mappings;
• preventing invalid combinations;
• distinguishing B2B, B2C, EU, and non-EU cases;
• keeping invoice data structured for myDATA reporting;
• making corrections easier when needed.

The goal is not to replace the accountant. The goal is to make daily invoicing cleaner and reduce preventable errors.

Practical checklist: choosing the right E3 type

• Is the customer a business or a private individual?
• Is the customer in Greece, the EU, or outside the EU?
• Are you selling goods, products, or services?
• Is the invoice wholesale, retail, intra-community, or third-country?
• Does the VAT treatment match the transaction?
• Has your accountant approved the classification mapping?
• Does your invoicing software prevent invalid myDATA combinations?

If the answer to any of these is unclear, ask your accountant before relying on a default classification.

Final thoughts

E3 types may look like technical codes, but they serve a practical purpose: they tell myDATA what kind of income or expense a transaction represents.

Correct invoicing is no longer just about creating a PDF. It is about creating structured, correctly classified invoice data.

As Greek invoicing becomes more digital, businesses that set up their E3 mappings properly will save time, avoid errors, and give their accountants better information. With the right software, E3 classification should happen mostly in the background: guided, consistent, and accountant-approved.