Greece — myDATA / AADE

Research and design document for the Greek fiscalization adapter (greece-mydata). Phase-1 Mediterranean cluster country (pairs with Italy SDI/DC). Approximately 700K active VAT-registered businesses. €0 certification cost — TIN-based credentials, no X.509 PKI for the API itself.

Status: Research only. No adapter code in this commit. Target crate path: rust/adapters/greece/ (candidate name greece-mydata).

1. Regulatory scope

myDATA (Mydata — Παρακολούθηση Συναλλαγών, "Transaction Tracking") is the AADE (Ανεξάρτητη Αρχή Δημοσίων Εσόδων / Independent Authority for Public Revenue) digital platform for mandatory submission of business books and invoices.

Concept (Greek)	English	Role
Παραστατικά	Invoices / accounting documents	Sales, expenses, credit/debit notes
Χαρακτηρισμοί	Classifications	E1/E3 income/expense category tags
Σύνοψη	Summary header	Aggregate VAT/total per document
Αναλυτικές Γραμμές	Detail lines	Per-line breakdown (Type B only)
MARK	Unique Registration Mark	AADE-issued identifier per invoice
Χαρακτηρισμός Συναλλαγής	Transaction classification	Income/expense category code
ΑΦΜ (AFM)	Tax Identification Number	9-digit VAT/business ID

Mandatory scope:

All Greek-resident issuers (legal persons + sole traders / freelancers).
All B2B, B2G, and B2C documents that are issued under Greek VAT law (Code of Books and Records — ΚΦΔ).
E-invoicing is not yet legally mandatory between B2B parties but is heavily incentivised (2 yr/3 yr extended statute of limitations, accelerated VAT refunds) and is being phased into mandatory status during 2026.

Submission tiers (per AADE Specifications v1.0.10 and POL provisions):

Issuer category	Channel	Window
Cash-register / FIM (Φορολογικός Ηλεκτρονικός Μηχανισμός) — retail	Real-time via FIM-A2A	At time of issue
Accredited e-invoicing provider (Πάροχος Ηλεκτρονικής Τιμολόγησης)	Provider gateway → AADE	Within 24h of issue (EOD batch typical)
ERP (own integration via REST)	Direct REST	Within 1 month of issue (B2B), EOD for retail
Manual portal entry	timologio.aade.gr	Same as ERP

⚠️ Hardware constraint. Issuers in the FIM/cash-register category must use a certified ΦΗΜ device (Greece's tax-stamped fiscal printer/cash register family) for the issuing leg. Zyntem cannot fully serve this category without an ECR partner: the device itself signs the receipt with its own AADE-registered key and pushes a one-shot transmission. Our addressable market is ERP-direct, accredited-provider, and B2B/B2G e-invoicing — explicit non-goal: replace the FIM. (See §10 Open Questions.)

2. API surface

Two production environments + sandbox. All HTTPS REST/JSON envelopes around XML payloads.

Environment	Base URL	Notes
Sandbox	`https://mydata-dev.azure-api.net/`	Public dev environment, free subscription via developer portal
Production	`https://mydatapi.aade.gr/myDATA/`	Live, requires production AFM-bound credentials
Provider sandbox	`https://mydataapidev.aade.gr/myDataProvider/`	For accredited e-invoicing providers

Sources: AADE myDATA developer portal (https://mydata-dev.azure-api.net/) and AADE Production Specs v1.0.10 (https://www.aade.gr/mydata).

Core endpoints

Method	Path	Purpose
POST	`SendInvoices`	Submit one or more `InvoicesDoc` (sales invoices, retail receipts, credit/debit notes)
POST	`CancelInvoice`	Cancel a previously transmitted invoice by MARK
GET	`RequestTransmittedDocs`	Pull invoices the issuer has previously transmitted (idempotency / reconciliation)
GET	`RequestDocs`	Pull invoices where the caller is the counter-party (received)
POST	`SendIncomeClassification`	Apply income classification (E3 codes) to issued invoices
POST	`SendExpensesClassification`	Apply expense classification (E1/E3 codes) to received invoices
POST	`SendPaymentMethod`	Report cash/card/credit payment method per invoice
POST	`SendBookKeepingEntries`	Send accounting book entries for accounting-period reporting
POST	`RequestMyExpenses`	Pull received-side expenses (counter-party view)
POST	`SendInvoiceCharacterization`	Update `invoiceType`/category on transmitted invoices

Common query parameters for Request*Docs: mark (>=, paging cursor), dateFrom, dateTo, entityVatNumber, nextPartitionKey + nextRowKey (continuation). All collection responses paginate.

Wire format

Request / response body: XML, Content-Type: application/xml, Accept: application/xml.
All payloads are typed by AADE-published XSDs (see §4).
Responses (success + error) use <ResponseDoc> envelopes with <response> elements per submitted invoice.

3. Authentication

✅ Key thesis-relevant fact: myDATA does not require X.509 client certificates. A pair of HTTP headers is sufficient. We've cross-checked this against AADE's developer portal API definition, the production specs PDF, and accredited-provider documentation — confirmed at production-grade volumes (provider TPS limits apply via Azure APIM, not certificate provisioning).

Header	Source	Meaning
`aade-user-id`	TaxisNet username — for ERPs the dedicated myDATA REST API user spawned via `myaade.gov.gr → Manage Web Services Authentication Users`	Identifies the calling subject
`Ocp-Apim-Subscription-Key` (sandbox) / `Subscription-Key` (production)	Azure APIM subscription key from AADE developer portal	Authorises the channel

Notes:

The aade-user-id is not the AFM. It is a TaxisNet sub-account explicitly created for API use, with its own password used to derive the subscription key.
Per-AFM scope: the sandbox subscription is bound to the developer's AADE account; production is bound to the issuer's AFM (or, for accredited providers, to the provider's AFM with downstream "on-behalf-of" semantics).
Provider on-behalf-of: when an accredited provider transmits for clients, the same headers are used and the issuer's AFM is carried in the payload (<issuer><vatNumber>). AADE separates provider-channel traffic by URL (/myDataProvider/).

Provider vs ERP path

Path	Headers	Endpoint base	Who pays	Throughput
Direct ERP	aade-user-id of the AFM	`/myDATA/`	Issuer	Per-AFM APIM quota (default modest; raise via AADE)
Accredited provider	aade-user-id of the provider	`/myDataProvider/`	Provider	Higher per-AFM via provider quota; provider is liable for transmission

Zyntem's launch path is direct ERP. Becoming an accredited provider unlocks (a) higher quotas and (b) the legal-statute-of-limitations incentive for issuers, and is a deliberate Phase-2 milestone (separate licence).

4. Payload shape

Schema family

myDATA payloads are AADE-proprietary XML. They are not UBL / EN 16931 (a frequent surprise for adapters that have UBL pipelines). The root types are:

XSD root	Purpose	XSD file
`<InvoicesDoc>`	Container for one or more invoices	`InvoicesDoc-v1.0.10.xsd`
`<RequestedDoc>`	Response payload for `RequestDocs`/`RequestTransmittedDocs`	`RequestedDoc-v1.0.10.xsd`
`<ResponseDoc>`	Per-invoice ack/error response	`ResponseDoc-v1.0.10.xsd`
`<IncomeClassificationsDoc>`	Income classification batch	`IncomeClassificationsDoc.xsd`
`<ExpensesClassificationsDoc>`	Expense classification batch	`ExpensesClassificationsDoc.xsd`
`<PaymentMethodsDoc>`	Payment method ledger	`PaymentMethodsDoc.xsd`
`<BookKeepingEntriesDoc>`	Accounting book entries	`BookKeepingEntriesDoc.xsd`

The shared base type is published as mydata-v1.0.10.xsd. All invoice schemas import this base.

Greek namespaces: xmlns="http://www.aade.gr/myDATA/invoice/v1.0", icls="http://www.aade.gr/myDATA/incomeClassificaton/v1.0", ecls="http://www.aade.gr/myDATA/expensesClassificaton/v1.0". (Note: Classificaton is misspelled in the official namespace URI — this is a known AADE quirk and must not be corrected in the wire format.)

`<invoice>` skeleton

<InvoicesDoc xmlns="http://www.aade.gr/myDATA/invoice/v1.0">
  <invoice>
    <issuer>
      <vatNumber>123456789</vatNumber>
      <country>GR</country>
      <branch>0</branch>
    </issuer>
    <counterpart>
      <vatNumber>987654321</vatNumber>
      <country>GR</country>
      <branch>0</branch>
    </counterpart>
    <invoiceHeader>
      <series>A</series>
      <aa>1024</aa>
      <issueDate>2026-04-26</issueDate>
      <invoiceType>1.1</invoiceType>          <!-- See §4.1 -->
      <currency>EUR</currency>
    </invoiceHeader>
    <paymentMethods>
      <paymentMethodDetails>
        <type>3</type>                        <!-- 3 = Cash / 5 = Card / 4 = Bank wire ... -->
        <amount>124.00</amount>
      </paymentMethodDetails>
    </paymentMethods>
    <invoiceDetails>
      <lineNumber>1</lineNumber>
      <netValue>100.00</netValue>
      <vatCategory>1</vatCategory>            <!-- 1 = 24% / 2 = 13% / 3 = 6% / 7 = 0% / 8 = sundry / 5 = exempt -->
      <vatAmount>24.00</vatAmount>
      <incomeClassification>
        <icls:classificationType>E3_561_001</icls:classificationType>
        <icls:classificationCategory>category1_3</icls:classificationCategory>
        <icls:amount>100.00</icls:amount>
      </incomeClassification>
    </invoiceDetails>
    <invoiceSummary>
      <totalNetValue>100.00</totalNetValue>
      <totalVatAmount>24.00</totalVatAmount>
      <totalWithheldAmount>0.00</totalWithheldAmount>
      <totalFeesAmount>0.00</totalFeesAmount>
      <totalStampDutyAmount>0.00</totalStampDutyAmount>
      <totalOtherTaxesAmount>0.00</totalOtherTaxesAmount>
      <totalDeductionsAmount>0.00</totalDeductionsAmount>
      <totalGrossValue>124.00</totalGrossValue>
      <incomeClassification>
        <icls:classificationType>E3_561_001</icls:classificationType>
        <icls:classificationCategory>category1_3</icls:classificationCategory>
        <icls:amount>100.00</icls:amount>
      </incomeClassification>
    </invoiceSummary>
  </invoice>
</InvoicesDoc>

4.1 `invoiceType` taxonomy (subset)

Code	Description
1.1	Sales invoice (B2B / B2G)
1.2	Sales invoice / intra-community supply
1.3	Sales invoice / third-country export
1.4	Credit invoice (associated)
1.5	Credit invoice (non-associated)
1.6	Self-billed sales invoice
2.1	Services rendering invoice
2.2	Intra-community services
2.3	Third-country services
2.4	Self-billed services
3.1	Title of acquisition (non-tax-liable seller)
3.2	Title of acquisition (paragraph 5, art. 39a)
5.1	Credit note — associated
5.2	Credit note — non-associated
6.1	Self-billing accounting record
6.2	Self-billing accounting record (returns)
7.1	Contract — income
8.1	Rents — income
8.2	Special record — duty/levy/etc.
8.4	Provider's stranded supplies
11.1	AADE retail receipt (B2C cash register, FIM only)
11.2	AADE simplified retail receipt
11.3	AADE retail receipt — credit
11.4	AADE retail receipt — sales return
11.5	AADE retail receipt — invoice for services
13.1	Expense — domestic / abroad — services
14.1–14.5	Foreign-issuer documents
15.1	Service receipt evidence
16.1	Lottery winnings settlement
17.x	Self-issued / contractor documents

(Full taxonomy in mydata-v1.0.10.xsd → InvoiceType.)

4.2 `vatCategory` taxonomy

Code	VAT rate / meaning
1	24% (standard)
2	13% (reduced — food, hotels, certain agriculture)
3	6% (super-reduced — medicines, books, newspapers, theatre)
4	17% (mainland reduced — historical / island reduced rates)
5	9% (special)
6	4% (special)
7	0% (zero-rated — exports)
8	"Records without VAT" (off-VAT-scope)

VAT exemption reasons (vatExemptionCategory 1–31) cover EU intra-community, exports, exempt healthcare, etc. Required when vatCategory is 7 or 8.

4.3 Classifications

Per-line and per-document classifications are mandatory for Type B. Code shape E3_xxx_yyy for income (E3 form lines) and E1/E3 for expenses. classificationCategory enumerates category1_1 … category1_95 and category2_1 …. Classifications can be deferred (omitted on SendInvoices, sent later via SendIncomeClassification / SendExpensesClassification).

4.4 Type A vs Type B

Aspect	Type A — issuer-only summary	Type B — full book entries
Submitting party	Issuer	Issuer and counterpart (separate flows)
Detail	Summary block only (`<invoiceSummary>`)	Full line breakdown + classifications
Use case	Domestic B2C, retail, simplified receipts	B2B, B2G, expense classifications
`invoiceType` examples	11.x, 8.x	1.x, 2.x, 5.x
Can be auto-classified	Yes (income side)	No (counterpart must classify expenses)
Submission window	Real-time / EOD	Same as A but classification can defer up to month-end

Implication for our prepare / submit flow: Type A → single submission, no counterpart wait. Type B → primary SendInvoices returns MARK, then a two-leg flow: (a) issuer's SendIncomeClassification, (b) counterpart's SendExpensesClassification. We model this as submit_primary → submit_classification (issuer) and a passive accept for received-side classification posted by counterparts. See §10 OQ-1.

5. Ordering / sequencing

myDATA assigns identity at three layers:

Issuer-side identity (we control) — <series> + <aa> (αα = αύξων αριθμός, sequential number). series is alphanumeric (1-50 chars, AADE recommends short codes per branch/POS), aa is a 1-50 digit sequential per series. Series + aa MUST be unique per AFM.
Submission-side identity (we control) — <invoiceMark> is only present on responses; we do not send it. Our SDK generates a per-call UUID for retry-correlation but it is not transmitted.
AADE identity (server returns) — <MARK>: 64-bit unsigned integer, monotonically increasing per AADE, returned in <ResponseDoc> per accepted invoice. This is the audit handle for cancellations, classifications, and counter-party retrieval.

Authentication code

AADE also assigns:

<authenticationCode> — SHA-1(MARK + issuer AFM + transmission timestamp), used as a tamper-evidence anchor (mostly for B2C/QR purposes).
<UID> — issuer-side correlation UID (we may set it, otherwise AADE generates).

Cash-register stamp (FIM only)

For invoiceType 11.x submitted by a FIM device, <fuelInvoice>/<currentBalance>/<RTSTransmissionDetails> carry the device's local sequence + signature. Out of scope for Zyntem launch (see hardware constraint, §1).

Idempotency

AADE does NOT honour client idempotency keys. Retransmitting a series+aa returns error 408 (already submitted) or 415 (validation differs). Our adapter must maintain a local submission_status per (afm, series, aa) and avoid re-SendInvoices after a 200.
For network-flake recovery, query RequestTransmittedDocs?mark=<lastSeenMark> to discover whether a previously-failed POST actually persisted.

6. Submission window

Document family	Hard deadline (per AADE specs §10 + POL)	Practical window we target
Retail / FIM (11.x)	Real-time at issue (≤ ~minutes) — FIM device push	n/a (not in Zyntem direct scope)
ERP-issued sales invoices (1.x, 2.x)	End of next month (T+1 month)	EOD batch (T+0) — well inside the deadline
Credit / debit notes (5.x)	Same as 1.x	EOD batch
Self-billing (1.6, 2.4)	T+1 month	EOD batch
Expense classification	End of accounting period	Weekly or monthly batch
Income classification	End of accounting period	Weekly or monthly batch
Cancellations	Within statutory amendment window (typically same fiscal year)	Best-effort same-day

Provider-channel issuers must transmit within 24 hours. If we run as accredited provider in Phase-2, our SLO becomes 24h.

7. Sandbox access

Create AADE developer account at the myDATA developer portal (https://mydata-dev.azure-api.net/). The account uses a TaxisNet credential pair (developer's personal AFM is sufficient for sandbox).
Subscribe to the myDATA REST API product. AADE issues a free Azure APIM subscription key (visible under "Profile → Subscriptions").
Create a sandbox aade-user-id by signing in to https://www1.aade.gr/saadeapps2/bookkeeper-web/ and provisioning a "myDATA Web Services Authentication User". This is independent of the live TaxisNet identity.
Headers: aade-user-id: <sandbox-user>, Ocp-Apim-Subscription-Key: <key>.
First call: GET RequestTransmittedDocs?dateFrom=2026-04-01&dateTo=2026-04-26. A successful 200 with empty <RequestedDoc> confirms wiring.
Sandbox AFMs: AADE provides public test AFMs (e.g., 123456789, 987654321, 094149139) — no real-PII risk.

Sandbox quota: ~60 RPM per subscription (Azure APIM default). Production quotas are negotiated per AFM.

Recorded round-trip

A canonical sandbox round-trip is captured in testdata/conformance/greece/mydata/sandbox/round-trip-b2b-td01.md (request body, headers redacted, response body). Live-credential capture is gated behind a Mayor-approved sandbox account (tracked in fi-fjm sibling). The committed example is structurally accurate but synthesised from AADE's published Postman collection — it has not yet been executed end-to-end. See §10 OQ-3.

8. Error model

AADE returns <ResponseDoc> envelopes with one <response> per submitted invoice. Each <response> carries either:

<response>
  <index>1</index>
  <invoiceUid>1A2B...</invoiceUid>
  <invoiceMark>400000123456789</invoiceMark>
  <authenticationCode>...sha1...</authenticationCode>
  <statusCode>Success</statusCode>
</response>

…or:

<response>
  <index>1</index>
  <statusCode>ValidationError</statusCode>
  <errors>
    <error>
      <message>VAT category and rate are not consistent</message>
      <code>215</code>
    </error>
  </errors>
</response>

Status outcomes

`statusCode`	Meaning	Adapter mapping
`Success`	Accepted, MARK assigned	`Submitted`
`XMLSyntaxError`	XML malformed	`RejectedClient` (do not retry without re-build)
`ValidationError`	Schema-pass, business-rule fail	`RejectedClient` (operator action)
`TechnicalError`	AADE-internal	`RejectedTransient` (retry with backoff)

Quarantined-with-warnings

Some validations return Success plus <errors> with code-class warning — the invoice is registered (MARK issued) but flagged. We map these to SubmittedWithWarnings (still acceptable, surface in dashboard; do not auto-resubmit).

Notable error codes

Code	Meaning
102	Counterpart AFM not registered with AADE
138	Series + aa already submitted
215	VAT amount inconsistent with category × net
217	Classification category not allowed for invoiceType
408	Duplicate transmission (use `RequestTransmittedDocs` to recover MARK)
415	Submitted invoice differs from previously-submitted one with same series/aa
500–599	AADE technical (retryable)

A complete code table is published as Annex IV of the AADE specs PDF; mirrored at testdata/conformance/greece/mydata/sandbox/error-codes.md.

9. Crate layout (proposal)

Candidate crate name: greece-mydata, located at rust/adapters/greece/. Workspace registration: add to [workspace]/members in rust/Cargo.toml.

rust/adapters/greece/
├─ Cargo.toml
├─ src/
│  ├─ lib.rs                 // pub use re-exports; impls `Adapter` trait from `core`
│  ├─ config.rs              // GreeceConfig: afm, branch, subscription_key, aade_user_id, env, type_a_or_b
│  ├─ client.rs              // reqwest async client; auth headers; retry/backoff (TechnicalError)
│  ├─ xml/
│  │  ├─ mod.rs              // serde-xml-rs envelope serialise/deserialise
│  │  ├─ invoices_doc.rs     // <InvoicesDoc> + <invoice> tree
│  │  ├─ response_doc.rs     // <ResponseDoc> parsing
│  │  ├─ requested_doc.rs    // <RequestedDoc> parsing (for retrieval / reconciliation)
│  │  ├─ income_class.rs     // <IncomeClassificationsDoc>
│  │  └─ expenses_class.rs   // <ExpensesClassificationsDoc>
│  ├─ codes/
│  │  ├─ mod.rs              // pub re-exports
│  │  ├─ invoice_type.rs     // enum InvoiceType (1.1, 2.1, 5.1, 11.x, ...)
│  │  ├─ vat_category.rs     // enum VatCategory (1..=8) + exemption reasons
│  │  ├─ payment_type.rs     // enum PaymentType (1=banking, 2=card, 3=cash, ...)
│  │  └─ classification.rs   // E3_xxx_yyy code enum + category enum
│  ├─ flow.rs                // prepare(); submit_primary(); submit_classification(); cancel(); pull()
│  └─ errors.rs              // AadeStatus enum + Code(u16) + maps to core::AdapterError
└─ tests/
   ├─ golden_b2c.rs           // verifies XML matches testdata golden
   ├─ golden_b2b_service.rs
   ├─ golden_credit_note.rs
   ├─ golden_expense_class.rs
   ├─ golden_multi_vat.rs
   └─ golden_cancellation.rs

Trait fit

The Greek flow maps cleanly onto the existing Adapter trait (core::Adapter) — proposal:

impl Adapter for GreeceMyDataAdapter {
    type PrepareOut = InvoicesDoc;     // Pure XML; no signature pass needed
    type SubmitOut  = AadeMark;         // newtype around u64 MARK
    type Receipt    = AadeReceipt;      // MARK + auth code + warnings

    async fn prepare(&self, tx: &Transaction) -> Result<InvoicesDoc>;
    async fn submit (&self, doc: InvoicesDoc) -> Result<AadeMark>;
    async fn fetch_receipt(&self, m: AadeMark) -> Result<AadeReceipt>;
    async fn cancel(&self, m: AadeMark, reason: CancelReason) -> Result<()>;
}

For Type B classification flow, we introduce Adapter::PostSubmitHook (already present for IT-DC pairing) and run SendIncomeClassification async-after SendInvoices. No new trait surface required.

Config shape

#[derive(Deserialize, Serialize, Debug, Clone)]
pub struct GreeceConfig {
    pub afm: String,                      // 9 digits
    pub branch: u16,                      // 0 = HQ
    pub legal_name: String,
    pub aade_user_id: String,             // sandbox or live web-services user
    pub subscription_key: SecretString,   // Azure APIM key (zeroize-on-drop)
    pub env: GreeceEnv,                   // Sandbox | Production | ProviderSandbox | ProviderProd
    pub document_class: DocumentClass,    // TypeA | TypeB
    pub default_series: String,           // Default invoice <series>
}

pub enum GreeceEnv { Sandbox, Production, ProviderSandbox, ProviderProduction }
pub enum DocumentClass { TypeA, TypeB }

Credentials loaded via the same CertStore analogue that Spain/Italy use today; for Greece the "cert store" degenerates to a kv-secret store (no X.509). This is a simplification vs. peers.

Test approach

Reuse existing testdata/conformance/<country>/golden/*.json + *.xml + *.meta.json triplet pattern (see Italy SDI).
Sandbox round-trip captured under sandbox/ and replayed via wiremock-backed integration test.

10. Open questions

ID	Question	Owner	Notes
OQ-1	Type A → Type B promotion semantics: if an issuer config flips mid-month, do we replay outstanding invoices?	mayor + adapter dev	AADE allows late classification; we likely model it as "always emit Type B and let counterpart pull"; needs alignment with `core::Transaction::Metadata` shape.
OQ-2	Provider mode (Phase-2): becoming an accredited e-invoicing provider unlocks 24h-deadline incentives but adds liability. Schedule?	mayor	Decision needed before EOY 2026.
OQ-3	Live-sandbox credential provisioning: who owns the `mydata-dev` developer account (Zyntem corp AFM vs. team account)?	mayor / ops	Tracked under fi-fjm sibling. The committed `sandbox/` file is structurally derived; replay against live sandbox is gated on this.
OQ-4	FIM (11.x) coverage: do we partner with an ECR vendor (e.g., Casio, ICS, Algotech) to expose FIM-issued retail receipts via myDATA, or do we exclude retail B2C cash-register entirely and stay ERP-only?	strategy	Hardware-constraint trade-off; Zyntem's wedge is API-first.
OQ-5	Counterpart classification: when our customer is a foreign AFM (intra-EU), expense-side classification is the foreign issuer's job under their own regime — we should NOT auto-emit `SendExpensesClassification`. Confirm flow.	adapter dev	Cross-border treatment, AADE specs §6.
OQ-6	Cancellation grace period: AADE allows cancellation by MARK only within the statutory amendment window. After window expiry, must use credit note (5.1/5.2). Confirm we surface this distinction in our `cancel()` API.	adapter dev	Affects SDK error contract.
OQ-7	XSD versioning: AADE bumps `mydata-v*.xsd` 2–3×/year (current v1.0.10, prior v1.0.9, v1.0.8). Decide pinning + upgrade cadence (likely "vendor-and-bump-via-PR").	adapter dev	Mirrors how we treat FatturaPA XSDs.
OQ-8	UTF-8 vs UTF-16 wire encoding: AADE accepts both but Greek-character handling differs in escaping. Pick UTF-8 + xml-encoded entities; verify AADE round-trip preserves Σύνοψη accents.	adapter dev	Affects line-description handling.
OQ-9	Sole-trader self-employed (ελεύθερος επαγγελματίας) vs corporate AFM: same API surface, but different `vatRegime` codes on `<invoiceHeader>`. Validate matrix vs. our `LegalForm` enum.	adapter dev	Minor schema mapping.
OQ-10	Throughput SLOs: Azure APIM default per-subscription quota is undocumented (anecdotally ~60 RPM); raising it requires AADE ticket. Need committed numbers before quoting B2B SLAs.	mayor / ops	Affects pricing & batch design.

Reference URLs

AADE official:

AADE myDATA homepage: https://www.aade.gr/mydata
Specifications PDF (current v1.0.10) — published from https://www.aade.gr/sites/default/files/2024-03/myDATA_API_Documentation_v1.0.10.pdf (and prior versions in the same directory).
myDATA developer portal (sandbox provisioning): https://mydata-dev.azure-api.net/
AADE invoice type taxonomy XSD: published in the dev portal under "Resources → XSD".
TaxisNet Web Services Authentication Users: https://www1.aade.gr/saadeapps2/bookkeeper-web/

Auxiliary:

AADE accredited e-invoicing providers list (Phase-2 reference): https://www.aade.gr/epicheireseis/forologikes-ypereseis/mhtroo/parochoi-elektronikis-timologisis
timologio.aade.gr (manual portal — useful for reverse-engineering payload shapes): https://www1.aade.gr/timologio/

Citations are mirrored at testdata/conformance/greece/mydata/sandbox/sources.md for traceability.

Change log

Date	Version	Description	Author
2026-04-26	1.0	Initial research document — myDATA API, AADE InvoicesDoc payload, Type A/B flow, crate layout `greece-mydata`, 10 open questions.	dementus (Polecat)

1. Regulatory scope​

2. API surface​

Core endpoints​

Wire format​

3. Authentication​

Provider vs ERP path​

4. Payload shape​

Schema family​

<invoice> skeleton​

4.1 invoiceType taxonomy (subset)​

4.2 vatCategory taxonomy​

4.3 Classifications​

4.4 Type A vs Type B​

5. Ordering / sequencing​

Authentication code​

Cash-register stamp (FIM only)​

Idempotency​

6. Submission window​

7. Sandbox access​

Recorded round-trip​

8. Error model​

Status outcomes​

Quarantined-with-warnings​

Notable error codes​

9. Crate layout (proposal)​

Trait fit​

Config shape​

Test approach​

10. Open questions​

Reference URLs​

Change log​