How to Verify MARK on Greek Supplier Invoices

MARK is the 15-digit registration number AADE assigns when a Greek supplier transmits an invoice to myDATA. For AP, verifying a supplier invoice means checking that the MARK resolves on AADE, the issuer and amounts match the invoice, the document appears in the receiver's Book B, and the related input-VAT claim can be defended.

That last point is the AP control. A MARK printed on an invoice is an input claim by the supplier; a verified MARK is a confirmed receipt the buyer can post against. Under the 2026 B2B mandate, AP should treat an invoice from a mandated supplier without a verifiable MARK as not postable until corrected or resolved through the appropriate receiver-side myDATA workflow.

According to KPMG's analysis of the Greek e-invoicing postponement under AADE Decision A.1044/2026, mandatory B2B e-invoicing for large Greek businesses (those with more than EUR 1 million in 2023 revenue) starts on 2 March 2026 with a transitional period until 3 May 2026; all other businesses are scheduled for 1 October 2026, with KPMG noting the broader transition period for that later cohort. For the broader regime context — issuer obligations, transmission channels, accreditation requirements — see the broader 2026 myDATA B2B e-invoicing mandate and its phased deadlines.

What MARK, UID, and the authentication code actually are

Four printed strings travel with a Greek supplier invoice once it has been through myDATA. They are not interchangeable, they do not all appear on every invoice, and verification depends on knowing which is which.

MARK (ΜΑΡΚ) is the 15-digit numeric identifier AADE returns the moment a supplier successfully transmits an invoice to myDATA. The format is fixed — fifteen digits, no dashes, no letters, regex shape ^\d{15}$ — and it is issuer-agnostic. The same 15-digit MARK format applies whether the supplier used an accredited e-invoicing provider or AADE's free timologio issuer app.

UID is the accredited provider's own unique identifier for the document — a 40-character alphanumeric string in GUID shape, generated by the issuing provider before transmission and travelling with the invoice through Peppol or direct delivery. UID is present when the invoice was issued through an accredited provider and absent when it was issued through the AADE free apps. It is the provider's tracking handle, distinct from MARK, and it is not what AADE uses to identify the document in Book B — that role belongs to MARK.

The authentication code is a 40-character hash AADE returns alongside MARK on successful transmission. Functionally, it is a cryptographic receipt: it confirms that AADE received and registered the document, and it is the value an integrity check pairs against to detect any post-transmission tampering with the printed metadata. AP teams rarely interact with it directly during manual verification, but format-validation logic in an automated gate checks its length and shape as a cheap input-quality signal.

The QR code is the operationally important printed asset. It encodes a URL to AADE's public verification endpoint specific to that invoice's MARK. Scanning the QR resolves to AADE's view of the transmission — issuer details, amounts, transmission timestamp, and current status. It is the receiver's fastest single-step path to "what does AADE say about this document?" without logging into TAXISnet at all.

Where these identifiers sit on the invoice face is not standardised. Some accredited providers print a clean dedicated e-invoice identifiers block in the footer; others scatter MARK, UID, and authentication code across the header, footer, and a stamp area; the AADE timologio app uses its own layout. Peppol BIS 3.0 Greek CIUS invoices carry MARK in a structured Peppol extension field rather than a fixed visual position. Native myDATA XML invoices carry it in the structured envelope. PDFs and scans — the formats most AP functions actually receive Greek supplier invoices in — inherit whatever layout the issuing system produced, and that layout varies invoice to invoice and supplier to supplier. The placement variation is the extraction problem AP teams have to solve before any verification step can begin, and it is what gates whether automated verification scales at all.

For the full mandatory-fields list a Greek tax invoice must carry alongside MARK and the QR code, see our reference on Greek VAT invoice mandatory fields including MARK and the QR code.

Manual verification: QR scan and Book B lookup

For a small Greek-supplier portfolio, manual verification is the fastest path to "is this MARK real and is it ours?" There are two checks, and the receiver runs both.

The first is the QR scan. Every myDATA-transmitted invoice prints a QR code that encodes a URL to AADE's public verification endpoint for that specific MARK. A phone camera, a scanner app, or any QR reader that follows the URL returns AADE's view of the transmission — MARK number, issuer details (legal name and AFM, the Greek tax registration number), transmission timestamp, authentication code, and the document's current status. Status is the field AP cares about: a transmission can be marked transmitted (live and valid), rejected (AADE refused it for a structural reason), cancelled (the issuer transmitted and then withdrew), or corrected (a later replacement transmission supersedes this one). The QR scan is the single check that confirms the document was registered and shows what AADE has on file for it without anyone signing into anything.

The second check goes deeper. Receivers with TAXISnet access enter the myDATA portal under their organisation's credentials, open Αντικριζόμενα Βιβλία (Book B — the receiver-side mirrored document ledger AADE maintains for every entity that receives a myDATA invoice), and search by MARK to confirm the document appears under the receiver's own VAT ID. Book B is where AADE expects the receiver to find the invoice; if it is not there, either it was not transmitted to your VAT ID or the propagation has not yet completed.

Across both checks, the verifier's actual decision logic is five validation tests, all of which must pass for verification to clear:

1. MARK resolves to a valid transmission when the QR endpoint is hit — not "rejected", not "404 not found".
2. Issuer identity matches. The legal name and AFM AADE has on file match the issuer printed on the invoice face. A trade-name on the invoice that resolves to a different legal entity is a flag, not a pass.
3. Amounts match. Net amount, VAT amount, and totals on the invoice face equal what AADE has on file for the transmission. Rounding differences within a cent are tolerable; line-level structural mismatches are not.
4. Status is not cancelled as of the transaction date. A MARK that was live at receipt but cancelled before posting is no longer a valid receipt.
5. The document appears in Book B under the receiver's expected VAT ID. A MARK that resolves to the AADE endpoint but is missing from your Book B is either propagating or was transmitted with the wrong receiver VAT ID.

That procedure works at roughly a dozen invoices a month. A Greek SME with a handful of regular suppliers, a non-Greek finance team with one or two Greek vendors, an outsourced bookkeeper handling a small client — the manual two-step holds up at this volume because the cognitive overhead per invoice is acceptable and the Book B lookup is fast.

It does not scale. At a hundred Greek supplier invoices a month, scanning QR codes by hand and reconciling against Book B becomes a half-day weekly task that produces no audit artefact and depends on a human remembering to do it. At a thousand it is impossible. Vendor compliance overviews tend to soft-pedal this — a QR-can-be-scanned bullet sits comfortably in marketing copy and avoids confronting the volume problem directly. The reality is that any AP function processing more than a few dozen Greek invoices a month is either running an automated verification gate or accepting that some portion of supplier invoices is going into the ledger unverified.

Manual verification does not become obsolete at scale, though — it shifts role. In an automated pipeline, the manual two-step is what an AP clerk runs against the small pool of exceptions a gate flags for human review: the missing-from-Book-B case still in the propagation window, the field mismatch the validator could not auto-resolve, the supplier the system has not seen before. Knowing the procedure cold is what makes the soft-fail review queue something other than a black box.

Automating verification at AP volume

At AP shared-services volume, verification has to be a pipeline rather than a procedure. The structural pattern that holds up across international firms with Greek subsidiaries, λογιστικά γραφεία (Greek bookkeeping practices) handling many clients, and Greek SME shared-services functions has four stages: extract, format-validate, verify, reconcile.

Extract. An OCR layer or a structured parser pulls MARK, UID, authentication code, and the QR payload off the invoice, alongside the header fields (issuer AFM, receiver AFM, invoice number, date, currency) and the line-level data the rest of AP needs. This is the limiting step, and not for the reason most procurement docs assume. The Greek e-invoicing regime mandates which identifiers must appear on the invoice; it does not mandate where on the page they appear or how the issuing system has to format the surrounding layout. Accredited providers print MARK in different places. ERP outputs vary. The AADE timologio app uses its own template. PDFs are received from email, accredited-provider portals, Peppol delivery, and supplier upload portals — each with its own structural quirks. A missed MARK at the extract step is a verification failure regardless of what AADE actually has on file, because nothing downstream has anything to verify against.

Format-validate. Cheap, fast, and worth running before any AADE call. MARK matches ^\d{15}$. UID, when present, matches the provider GUID format. The QR payload parses as a well-formed AADE verification URL. The authentication code has the expected 40-character length. Format validation catches malformed inputs (an OCR error that turned a 0 into O, a missing digit, a misread QR) and prevents the AADE endpoint from being hit on garbage. A handful of regex checks save the noisier downstream calls.

Verify against AADE. The extracted QR URL resolves to AADE's transmission record. The validator compares extracted invoice-face data against the transmission metadata: issuer match against the AFM AADE has on file, amount match against the transmitted totals, status check against the AADE state machine. Anything other than transmitted-and-matching is an exception by definition.

Reconcile against Book B. A nightly pull of the receiver's own Book B — via the AADE API or via the ERP's myDATA connector — is matched against the invoices AP has actually received. Two surface conditions matter:

• Orphans. An invoice in your AP system has a verified MARK, but Book B has no entry under your VAT ID. Either propagation is still in flight (timing) or the supplier transmitted with a wrong receiver AFM (omission affecting your audit position). Either way, the orphan needs to be tracked until it resolves.
• Unmatched Book B entries. Book B shows an invoice transmitted to your VAT ID, but AP has not received the document. This is the missed-receipt case — the supplier filed against you, but the invoice never reached the AP inbox. It is a different exposure: not a posting risk on a document you have, but a potential exposure on a document you do not. AP needs to chase the missing invoice from the supplier before the VAT-return window closes.

Three integration patterns get used in practice. A pre-posting hook in AP intake fires verification at receipt and gates posting on the result — catches problems at the earliest point but slows throughput; well suited to low-margin-for-error sectors. A nightly Book B reconciliation job runs verification as a batch and surfaces orphans and unmatched entries on a daily cadence, decoupled from the posting flow. A pre-VAT-return sweep runs everything one final time before the monthly classification window closes — the last chance to resolve anything still open, and the fallback every other pattern depends on. Most mature AP functions run two of the three.

The extract step is where most automation projects succeed or fail: template-based extraction breaks on provider layout variation, and OCR-only approaches can misread 15-digit MARK values. AI-powered invoice data extraction for AP-scale MARK verification can pull MARK, UID, authentication code, QR payload, header fields, and line data from heterogeneous PDFs and scans into structured output for the verification gate.

The gate turns the pipeline result into a posting decision. Every channel feeds the same intake queue; documents missing identifiers go to exception review; format failures route for re-extraction or manual read; AADE and Book B results determine whether the invoice can post. Posting from anywhere else is how unverified documents end up in the input-VAT claim.

Two rule sets sit on that gate. Fail-closed rules block posting outright:

• MARK missing on an invoice from a mandated supplier post-2026.
• MARK present but absent from Book B beyond a reasonable propagation window.
• The issuer AADE has on file does not match the issuer printed on the invoice.
• AADE returns "cancelled" as the transmission status as of the transaction date.

Fail-open-with-flag rules let the document continue to posting but route it for review afterwards where the failure mode is more likely noise or timing:

• Minor field mismatch within rounding tolerance — typically VAT amounts off by a cent on multi-line invoices, or net totals affected by line-rounding noise.
• Transmission-to-Book-B propagation lag where AADE confirms the transmission but Book B has not yet populated, and the document is otherwise verified.

The point of separating the two rule sets is that fail-closed is policy and fail-open-with-flag is operational tolerance. Both need an audit trail: a documented reason, a reviewer signature where posting was allowed, and a clear link back to the source document and AADE or Book B result.

Cadence policy belongs in the same control design. Verify at receipt for mandated-supplier invoices whenever volume makes automation practical, run nightly Book B reconciliation where volume requires it, and re-check open or high-value items before the VAT-return window closes. Onboarding-only checks and risk-based sampling leave too much exposure once a supplier is in a mandated phase.

Six exception cases and how AP handles them

Verification surfaces six recurring exception patterns. Each needs a posting decision and a next action.

1. MARK missing from a mandated supplier invoice. Hold posting and request a corrected electronic invoice with a valid MARK. If the supplier claims non-mandated status, confirm the relevant phase against the 2026 revenue thresholds and dates before accepting the claim.

2. MARK present but absent from Book B. Open a wait-and-retry window, often 24 to 48 hours depending on known supplier propagation. If Book B populates, clear the flag. If it remains absent, escalate to the receiver self-report workflow so the Greek tax owner can protect the input-VAT position; use the Greek-language receiver-discrepancy workflow for the Book B classification steps.

3. MARK resolves to a different issuer than the invoice face. Hold posting, send the supplier the AFM mismatch, and escalate to tax compliance if the supplier cannot explain it. A registered trade name may be harmless; a different legal issuer is not a soft-fail.

4. Transmitted amounts diverge from invoice face (απόκλιση). Hold posting and reconcile with the supplier. If the supplier corrects or replaces the transmission, re-run verification against the corrected MARK. If the supplier refuses to amend, the receiver self-reports the correct-to-invoice amount in Book B through the same Greek tax workflow.

5. MARK marked "cancelled" on AADE. Do not post against the cancelled MARK. Request the corrected invoice and new MARK, then verify the replacement before posting.

6. QR code illegible or absent. Read the printed 15-digit MARK by eye, look it up in Book B, and verify amounts through the portal. If both QR and MARK are absent on a mandated-supplier invoice, treat it as missing MARK and request a corrected document.

What MARK verification does not protect against

A clean MARK verification confirms transmission and data match. It does not prove the invoice satisfies every VAT-formality, classification, cancellation, or adjacent-document requirement.

Greek VAT-invoice formal requirements. A document can resolve cleanly through the gate and still fail the mandatory-fields list a Greek tax invoice has to satisfy under VAT law: issuer and receiver tax IDs, place of issuance, currency, supply description, exemption legend where applicable, and the rest. MARK verification checks transmission and amount match, not every field.

E3 classification correctness. Verification confirms the document; classification assigns it to the right E3 category in Book B. A cleanly verified invoice can still be misclassified for income-tax reporting.

Post-transmission cancellation. Verification status is point-in-time. A MARK that resolves cleanly today can be cancelled tomorrow. Periodic re-verification before the VAT-return window closes catches cancelled MARKs that receipt-time checks miss.

Adjacent document-type compliance. Electronic delivery notes, retail receipts, and corrective documents have their own transmission and verification rules. MARK verification on the invoice does not confirm the transport-side control; for that, see Greek electronic delivery note rules under the same myDATA regime.

MARK verification is the gate that keeps unverified documents out of the AP ledger. Invoice-field validation, Book B classification, periodic re-verification, and related-document controls still run on top of that gate.