Data on a Greek E-Invoice vs. Data Reported to myDATA (Tax Authority) – Key Differences

• Legal Content Requirements (E-Invoice Document): Under Greek law (Law 4308/2014, aligned with the EU VAT Directive), a valid VAT invoice must include a comprehensive set of details for the transaction. These mandatory fields on the invoice (whether paper or electronic) include: [elte.org.gr]
  • Invoice Identification: the date of issue and a unique sequential invoice number (from one or more series). [elte.org.gr]
  • Supplier and Customer Details: the full name and address of the supplier and the customer, and their VAT identification numbers (Tax ID numbers). (The VAT number of the seller under which the goods/services are supplied, and the VAT number of the buyer if they are liable for VAT on the supply, must both appear.) [elte.org.gr], [elte.org.gr]
  • Transaction Details: a description of the quantity and nature of the goods supplied or the extent and nature of services rendered. If it’s a service, the description of what was provided; if goods, the product description and quantity. [elte.org.gr]
  • Dates: the date of supply of the goods or completion of services if different from the invoice date (e.g. delivery date). [elte.org.gr], [elte.org.gr]
  • Pricing and Tax Breakdown: the unit price (exclusive of VAT), any discounts (if not included in the unit price), and the taxable amount for each VAT rate or exemption category. For each applicable VAT rate, the invoice must show the rate (%) and the corresponding VAT amount charged. If an invoice is VAT-exempt or under a special VAT scheme, it should include a reference to the legal provision for the exemption or the notation of the special scheme (e.g. “Reverse charge”, margin scheme references, etc.). [elte.org.gr]
  • Other mandatory notations: If the invoice is issued by the buyer (self-billing) or if a tax representative’s VAT number is used, those must be indicated. In practice, a compliant Greek e-invoice (especially B2B) mirrors these requirements, ensuring all legally required content is present in the electronic format (often a structured XML adhering to the European e-invoice standard EN 16931). [elte.org.gr] [flick.network], [flick.network]
  • What’s not mandatory on the invoice: Greek law does not require certain fiscal details such as withholding tax amounts, stamp duties, or other government fees to be printed on the invoice (these are often handled separately in contracts or payment). Also, while invoices can include payment terms or bank information, these are commercial details, not strictly mandated by VAT law. In summary, the e-invoice itself must contain all the information necessary to serve as a complete VAT document for the transaction (identification of parties, description, values, tax due, etc.), as outlined above. [e-forologia.gr] [elte.org.gr]
• Data Required in myDATA Reporting (Tax Authority Submission): When transmitting invoice information to the Greek tax authority’s myDATA platform, the focus is on a structured summary of the invoice rather than an exact replica of every line item detail. The required data, as specified by IAPR’s technical schema (Decision Α.1138/2020 and updates), includes the key fiscal elements needed to update the taxpayer’s electronic books: [snitechnology.net], [snitechnology.net]
  • Invoice Identification and Parties: The submission must include the invoice number, invoice date, the supplier’s Tax ID (VAT number) and the customer’s Tax ID (AFM). (If the customer is foreign with no Greek AFM, that is indicated accordingly.) Notably, the full name and address of the parties, while on the invoice, are not necessarily transmitted in the myDATA summary – the Tax IDs serve to identify the parties in the tax system. The myDATA system already has master data for taxpayers, so reporting the VAT number is sufficient to identify the customer/supplier; including the name/address is either optional or not required for submission. This is a contrast to the invoice document, which must show names/addresses for legal validity. [snitechnology.net] [elte.org.gr], [elte.org.gr]
  • Transaction Summary Values: The reported data essentially captures the monetary totals needed for accounting and VAT. This includes the net taxable amount of the invoice (or multiple amounts if different VAT rates apply), the applicable VAT rate(s) and the VAT amount(s) for each rate, and the invoice’s total value. If an invoice has multiple VAT categories, the myDATA submission will include a breakdown by tax rate (e.g., €100 net at 24% VAT => €24 VAT, €50 net at 13% => €6.50 VAT, etc.). These figures correspond to what’s on the invoice, but myDATA does not necessarily require the detailed per-line breakdown – it requires the aggregated amounts per VAT category and overall totals. In other words, the tax authority cares about the summary financial outcome of the invoice (for updating sales/purchase ledgers and VAT calculations), not each individual product line’s description. [snitechnology.net], [snitechnology.net] [snitechnology.net]
  • Invoice Type and Classification Codes: Unlike the invoice document (which simply might be titled “Invoice” or “Credit Note”), the myDATA system requires each reported document to be tagged with specific “invoice type” codes and classifications. Taxpayers must classify each invoice according to categories defined by AADE before uploading. For example, an ordinary sales invoice might be coded as type “1.1” (Standard Sales Invoice), a credit note as “1.3”, etc., and each transaction is further characterized as revenue or expense of a certain nature (e.g. “income from domestic B2B sales”, “income from intra-EU supply”, “expense – import of services”, etc.). These classification codes (for both income and expense) are a reporting requirement unique to myDATA. They do not appear on the invoice sent to the customer – they are purely for the tax system to categorize the transaction. In practice, when an invoice is reported via myDATA, the business’s software or service provider attaches the proper codes in the XML submission (for example, an invoice might be marked as revenue classification code 1.1 for domestic taxable sale, or 1.95 for certain non-taxable info items). The customer, when confirming their purchase records, uses corresponding expense classification codes. This granular classification (required by the Decision A.1138/2020 framework) goes beyond the human-readable invoice: the invoice itself doesn’t say “Transaction Type: 1.1”, but the myDATA reporting must include that metadata. [wts.com], [wts.com] [wts.com] [e-forologia.gr], [e-forologia.gr]
  • Additional Tax Details (Withholdings/Fees): The myDATA report must include certain fiscal details that Greek law does not mandate on the invoice face. A prime example: withholding taxes and other levies. If a transaction involves withheld income tax (e.g. 20% on freelancers) or stamp duty or other contributions, Greek invoicing law doesn’t force the invoice to show these amounts (they’re often handled in payment or separate statements). However, the myDATA platform requires those amounts to be reported as part of the invoice’s data. In other words, even if the invoice doesn’t list the €X of withheld tax, the supplier’s myDATA submission must include that information (so that the authorities know, for instance, that a certain portion of the payment is a withheld tax to be remitted by the customer). The AADE clarified this in guidance: “charges other than VAT (withholding taxes, stamp duty, fees, etc.), although not mandatory content on the invoice per Law 4308/2014, must be transmitted to the myDATA platform”. This is a crucial difference: the e-invoice focuses mainly on VAT and transaction info, whereas the e-reporting encompasses a broader set of tax-related data points for that invoice. [e-forologia.gr]
  • Document References and Metadata: The myDATA submission will include references like whether the invoice was issued by the seller or is self-billing by the buyer, and links to any related documents (for example, if it’s a credit note adjusting a specific invoice, that reference is included). Many of these references are implicit or noted textually on the invoice but need structured reporting. For instance, an invoice might note “Payment subject to 4% stamp duty” in text; in myDATA, there would be a dedicated field/flag to report that stamp duty amount. Similarly, if an invoice is under the reverse-charge mechanism, the invoice text will say “Reverse charge – VAT to be accounted by recipient”; in myDATA, the transaction would be classified appropriately (e.g. a code for reverse charge sale, and no VAT amount reported by the issuer aside from marking it as reverse-charged).
  • Transmission Metadata (not on invoice): Each myDATA submission, once accepted, generates a unique identifier (the MARK code) and a QR code link for the invoice. The MARK (Μοναδικός Αριθμός Καταχώρισης) is returned by AADE upon successful reporting and must then appear on the e-invoice document (usually as a QR code or alphanumeric string) given to the buyer. This is a procedural difference: you don’t decide the MARK; the tax system assigns it. The invoice as finally delivered includes it (to prove reporting), but it’s not something the issuer originally “had” as part of invoice data – it comes after reporting. Conversely, the myDATA report you send obviously doesn’t include the MARK (since that’s what you’re trying to obtain), and it doesn’t include a QR code image – those are returned from the platform. Technically, the invoice document ends up containing a bit of data (MARK/QR) that wasn’t there at creation time and isn’t something you “report” but rather receive. [wts.com]
• Structural Format Differences: The electronic invoice file and the myDATA reported data are not identical in format, even if they convey overlapping information. Greece’s e-invoicing adheres to the EU’s semantic standard EN 16931, typically implemented via an XML format like UBL or UN/CEFACT CII for each invoice. This e-invoice XML is a self-contained document including all invoice elements (buyer, seller, line items, totals, etc.). By contrast, the myDATA submission is a set of specific structured fields sent via API (often also XML or JSON payload, but following AADE’s own schema definitions). Some distinctions: [flick.network], [flick.network] [snitechnology.net], [snitechnology.net]
  • An EN16931-compliant invoice file will list each invoice line with item name, quantity, unit price, line amount, etc., plus all the totals and legal statements. The myDATA reporting does not require sending each line item – it is more of a “summary document” record. For example, if an invoice has 10 lines of different products all at 24% VAT, the e-invoice XML will have 10 <InvoiceLine> entries; the myDATA submission might just have one aggregate figure for the 24%-VAT taxable amount and the VAT due. The level of granularity differs: myDATA cares about totals per tax category and certain flags, not the product catalog numbers or detailed descriptions. (One notable exception is if parts of the invoice have different treatment – e.g. an invoice that charges a service fee and a reimbursement – these might be split into separate reported components with different classifications, but still not as granular as every line on the invoice.) [snitechnology.net], [snitechnology.net]
  • The e-invoice XML and the myDATA XML use different schemas. The e-invoice structure is pan-European and designed to be exchanged between supplier and buyer (and, for B2G, via Peppol) – it contains all the commercial fields for an invoice as per Article 9 of Law 4308/2014. The myDATA schema is designed for tax reporting: it has fields for things like “document type code”, “income classification”, “expense classification”, and it ties into the electronic books (Records) that AADE maintains. For instance, where an e-invoice XML has <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> to denote a regular invoice in UBL, the myDATA API might expect a field like “typology 1.1” to denote the same. The data reported to AADE is essentially a mapped subset of the invoice data, transformed to meet tax authority specs. Companies using certified providers or ERP integrations rely on software to automatically map the detailed e-invoice into the required myDATA summary format. From a technical perspective, the e-invoice file is what the buyer receives (often as a PDF with an embedded XML or just the XML), whereas the myDATA data is what the tax authority’s system receives – both originate from the same source information, but structured differently for their purposes (partner communication vs. government ledger update). [elte.org.gr], [elte.org.gr] [snitechnology.net] [edicomgroup.com]
  • Example – Buyer’s address: The EN16931 invoice has a field for the customer’s address (because the buyer needs that info on the invoice). The myDATA submission has no dedicated “address” field for the buyer; the buyer is identified by VAT number, and AADE’s system already knows the official address from the taxpayer registry. So, the address is present in the invoice document but typically omitted from the reported data as redundant for the tax system’s needs.
  • Example – Line item descriptions: The invoice will list “Product X, 5 units, €20 each, total €100”. In myDATA, there’s no requirement to send the text “Product X” or “5 units” – instead, the company would send a single record for the invoice with a net amount of €100 classified under the correct revenue category. If the tax authority ever needs detail, they can inspect the actual invoice (which is archived and can be retrieved by its MARK code), but for automated processing, the description isn’t used – the classification code serves to tell AADE what kind of sale it was.
  • Additional data in myDATA only: As highlighted, things like withholding tax amounts or stamp duty are captured in myDATA fields which have no direct equivalent on a standard invoice. Similarly, myDATA requires reporting of certain accounting entries (like payroll, depreciation) which are not invoices at all – they obviously aren’t on any invoice, but they must be sent to complete the “books”. This extends beyond invoice content differences, but it underlines that myDATA’s scope is a bit broader than just invoicing: it’s a comprehensive tax record system. [snitechnology.net], [snitechnology.net]
• Summary of Key Differences: In essence, the overlap between an e-invoice’s content and the myDATA-reported data is significant – both include core details like invoice identifiers, party tax IDs, and monetary amounts needed for VAT. However, differences exist in both scope and format:
  • An e-invoice (legal VAT invoice) must contain all information required by law to document the transaction for the buyer and seller’s records (including names, addresses, item details, etc.). It is a complete document intended for the trading parties and audit trail. [elte.org.gr]
  • The myDATA report is a tax-focused extraction of that invoice: it pulls out the fiscal elements (values, tax, VAT number, etc.) and adds metadata like classifications and tax sub-codes that are required by the authority but not shown on the invoice. Conversely, it generally does not transmit some of the “human-readable” descriptive elements that are on the invoice (addresses, line descriptions, etc.) since those are not needed for calculating taxes or updating ledgers. [e-forologia.gr], [wts.com]
  • Regulatory vs Technical View: Legally, the invoice must meet content requirements for it to be valid; failure to include a required field (say, missing buyer VAT or invoice number) makes the invoice non-compliant. Those same fields, if missing in myDATA, would mean the data submission is incomplete (and will be rejected or cause errors). But there are regulatory requirements in myDATA that are extra (e.g. classification coding of each invoice, or reporting of non-VAT taxes) which have no effect on the invoice’s validity but are mandatory for tax reporting compliance. In short: the invoice is governed by Greek accounting/VAT law content rules, while the myDATA submission is governed by digital reporting regulations – the latter extends the former in certain areas. [e-forologia.gr]
  • Practical outcome: After issuing an e-invoice, a business must ensure that all the required data from that invoice (and some additional info derived from it) is correctly transmitted to AADE. The invoice the customer sees and the data AADE receives are two sides of the same coin, but not identical. For example, the customer’s invoice might not show “Category: 1.1” or a withheld tax line – but AADE’s system will have a record that invoice #123 is categorized as type 1.1 (domestic sale) with €X withheld tax reported. Conversely, the customer’s invoice shows a detailed item list and perhaps the company logo – none of which AADE needs in the data feed. The table below (in text form) highlights a few of these differences:
    • Counterparty Identity: Invoice shows name, address, VAT; myDATA reports VAT number (name is implicit in their system). [elte.org.gr], [snitechnology.net]
    • Line-item Details: Invoice lists each item or service; myDATA reports aggregated totals (by VAT rate/category). [snitechnology.net]
    • Tax breakdown: Invoice shows VAT rates and amounts, possibly other taxes if chosen; myDATA requires VAT amounts and also any other taxes (withholding, etc.) separately. [e-forologia.gr]
    • Classification: Invoice doesn’t show transaction type codes (it may include a textual note like “VAT exempt under art. X”); myDATA requires specific codes for type of document and nature of transaction. [wts.com]
    • Format: Invoice is often a PDF + XML (EN16931) document sent to buyer; myDATA data is an XML/JSON submission to AADE’s portal following its own schema (e.g., fields for “Series” and “InvoiceNo”, “IncomeClassification”, etc.). [snitechnology.net]
    • Unique ID: Invoice gets a MARK/QR after reporting (printed on invoice as proof); myDATA generates that ID (it’s not something the business provides). [wts.com]

• Greek Accounting Standards Law 4308/2014 – Article 9, detailing required invoice content. [elte.org.gr]
• AADE myDATA FAQs (Nov 2020) – clarifying that certain charges (withholding taxes, stamp duties, etc.) are not required on invoices but must be reported in myDATA. [e-forologia.gr]
• WTS Global update on Greece (Feb 2024) – notes that all invoices must be categorized per IAPR specifications before upload to myDATA. [wts.com]
• SNI Greece myDATA overview – explains that companies send a summary of invoices (key figures and classifications) in XML to update the e-books. [snitechnology.net], [snitechnology.net]
• AADE/Ministry guidance (2023) via tax press – requirement for QR code on e-invoices containing a link to myDATA record (the code is provided upon successful data transmission). [wts.com]

Briefing Document & Podcast – Greece E‑Invoicing, E‑Reporting, and E‑Transport: Scope, Timeline & Requirements – VATupdate