How to Verify MARK on Greek Supplier Invoices

MARK (Μοναδικός Αριθμός Καταχώρησης, or Unique Registration Number) is the 15-digit identifier AADE assigns when a Greek supplier transmits an invoice to the myDATA platform. To verify MARK on Greek supplier invoices is to confirm four things at once: the supplier actually transmitted the document, the issuer and amounts on the page match what AADE received, the document appears in the receiver's own Αντικριζόμενα Βιβλία (Antikrizomena Vivlia, Book B), and the input-VAT deduction the buyer is about to claim against this invoice is defensible on audit.

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. The distance between those two is the gap every AP function processing Greek supplier invoices has to close. Under the 2026 B2B mandate that distance has tightened from a recommended best practice into the operational floor: an unverified invoice from a mandated supplier is no longer a process miss; it is an invalid tax document.

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 must comply by 1 October 2026 under AADE Decision A.1044/2026. The dates frame the live regulatory ground this article is written into. They are also why receiver-side verification has moved from "nice control" to "the gate that protects every input-VAT claim from your Greek suppliers." 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 follows takes the receiver's seat through identification, manual verification, automation at AP volume, the intake gate, the exception paths, cadence, and the limits of what verification covers.

---

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 shape applies whether the supplier issued the invoice through an accredited Πάροχος Ηλεκτρονικής Τιμολόγησης (an e-invoicing service provider — EDICOM, Epsilon Net, Sovos, Comarch, SoftOne, Entersoft, and others) or through AADE's free timologio issuer app. There is no separate format for "small supplier" or "provider-issued" MARKs.

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 either succeed or stall. Template-based extraction breaks on the layout variation across providers; OCR-only approaches misread fifteen-digit numbers in noisy scans and produce silent failures. AI-powered invoice data extraction for AP-scale MARK verification is what we built for exactly this gap — a single natural-language prompt names MARK, UID, the authentication code, the QR payload, and every header and line field downstream AP needs, and the AI returns structured output across heterogeneous PDF and scanned-image inputs in Excel, CSV, or JSON. Each output row carries a reference back to the source file and page number, which is what lets an orphan or unmatched-Book-B case be cross-referenced against the original document during exception handling rather than getting lost in a queue. The extracted MARK, UID, and authentication code feed format-validation and the AADE-verify call directly, and the same prompt and configuration handle a Greek-supplier flow whether it carries fifty invoices a month or batches in the thousands.

The verification gate in AP intake

A pipeline that runs the four stages above is the substrate; an AP control needs the gate model on top of it. The gate is what turns "we extracted and verified" into "we made a posting decision based on the result, and we can show why." Five steps, each a control point rather than a process step.

1. Receipt. The invoice arrives — PDF in an inbox, Peppol BIS 3.0 delivery into the AP system, an accredited-provider portal pickup, an AADE free-app delivery, or paper for any cohort still outside the mandated phase. The control here is capture: every channel feeds the same intake queue, and nothing is processed outside it. Off-channel receipts (an invoice handed to procurement, an attachment forwarded to the wrong distribution list) are where verification gaps start.

2. Extraction. MARK, UID, the authentication code, the QR payload, header fields, and line data are pulled from the document. The control is completeness: the extraction step either returns a full identifier set or flags the document as identifier-incomplete. A document that exits this step missing an identifier moves to the exception queue, not to the next stage.

3. Format validation. Four format rules apply: MARK matches the 15-digit shape, UID (when present) matches the provider GUID format, QR payload parses as a well-formed AADE verification URL, and the authentication code has the expected length. The control is input quality. A document that fails format validation is not yet a verification failure — it is a sign that extraction may have misread something, and the document is routed for a re-extract or a manual identifier read before it returns to the queue.

4. Verification gate. The AADE call resolves; Book B is checked; issuer, amounts, and status are compared. This is the AP control for Greek myDATA invoices in the strict sense — the point at which the document becomes a verified receipt or does not.

5. Posting. The invoice books into ERP only if verification passed cleanly, or if a soft-fail was reviewed and cleared by an authorised approver. Posting from anywhere other than this exit point is how unverified documents end up in the input-VAT claim.

Two rule sets sit on the gate. Fail-closed rules block posting outright, and they apply when the document is not a defensible tax document under the regime:

• 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, and they apply where the failure mode is more likely a noise-or-timing issue than a regime violation:

• 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 produce an audit trail: a fail-closed produces a documented reason the document was not posted, a fail-open-with-flag produces a documented reason it was posted plus a reviewer signature on the cleared flag. An AP function audited on its myDATA controls is judged on whether its gate model exists, whether its rules are written down, and whether the audit trail shows the rules being applied — not on whether every invoice happened to verify cleanly. The AP controller in Greece, the finance ops lead at the international parent, and the internal auditor reviewing the receiving workflow are all looking at the same artefact: a defensible gate that turns MARK from a printed number into a verified receipt the input-VAT deduction can sit on.

Six exception cases and how AP handles them

Verification surfaces six recurring exception patterns. Each one has a specific decision rule, and walking them concretely is what separates an AP function that handles myDATA invoices defensibly from one that just runs the gate and hopes.

1. MARK missing entirely from an invoice from a mandated supplier. Post-2026, an invoice from a supplier in mandated phase that does not carry a MARK is not a valid tax document. The buyer cannot claim the full input-VAT deduction against it. Action: hold posting and request a corrected electronic invoice from the supplier with a valid MARK. If the supplier pushes back claiming non-mandated status, confirm against their turnover phase: large businesses (more than EUR 1 million in 2023 revenue) are mandated from 2 March 2026, every other business from 1 October 2026 under AADE Decision A.1044/2026. Accept the non-mandated claim only when it stands up against those dates and revenue thresholds. Do not paper over a missing MARK from a clearly mandated supplier; this is the missing-MARK AP handling case the regime is most punitive about.

2. MARK present but absent from Book B. This is the case AP teams hit most often, and the diagnosis matters. Two distinct sub-cases produce the same surface symptom. The first is a propagation lag: the supplier's accredited provider transmitted the invoice to AADE, but the entry has not yet appeared in your Book B. Propagation typically completes within minutes for direct-channel transmissions and within hours for some accredited providers; a small population takes longer. The second is a genuine omission: the supplier printed a MARK-shaped value but did not transmit, the transmission failed silently, or the document was transmitted with a wrong receiver AFM and never reached your Book B at all. Action: open a wait-and-retry window, typically 24 to 48 hours depending on the supplier's known propagation behaviour. Re-check Book B at the end of the window. If the entry is now present, clear the flag and post. If still absent, treat it as an omission and escalate to the receiver self-report workflow, which is what preserves the input-VAT claim against an invoice the supplier failed to file. The deep-dive on receiver discrepancies and self-reporting omissions, including the specific Book B χαρακτηρισμός (classification) steps the receiver runs to log the self-report, lives in our Greek-language deep-dive on receiver discrepancies and self-reporting omissions in myDATA; the depth there is in Greek because it serves the Greek-language practitioner audience, but the workflow it documents is the one a non-Greek AP function escalates to its Greek tax compliance partner to run.

3. MARK resolves to a different issuer than the invoice face. The QR endpoint returns one issuer AFM; the invoice prints another. Sometimes this is legitimate — a registered trade name on the invoice that maps to a different legal entity in AADE's records. More often it is a paperwork mismatch worth investigating, and occasionally it is a fraud signal. Action: hold posting; contact the supplier with the specific mismatch (the AFM AADE has on file versus the AFM printed on the invoice); if the supplier cannot account for it cleanly, escalate to tax compliance before posting. An identity mismatch is not a soft-fail.

4. Transmitted amounts diverge from invoice face (απόκλιση). AADE's record shows different net, VAT, or total amounts than the invoice the AP team holds. Hold posting; reconcile with the supplier. If the supplier corrects the transmission (cancelling the original MARK and reissuing, or transmitting a corrective entry), verification re-runs against the corrected MARK and the invoice posts against the new record. If the supplier insists the printed amounts are correct and refuses to amend, the receiver self-reports the correct-to-invoice amount in Book B to preserve the input-VAT claim against the discrepancy — the same Greek-language workflow referenced under case 2. The 5% net-value penalty regime under Greek tax procedure is the exposure at stake here; reconciliation effort is cheaper than the penalty.

5. MARK marked "cancelled" on AADE. The supplier transmitted, then cancelled. A cancelled MARK is not a valid receipt. Action: do not post; request a corrected invoice with a new MARK. The cancellation might be benign (issuer correcting a structural error and reissuing) or signal something the AP function needs to know about (delivery dispute, billing error the supplier has not communicated). Either way, posting against a cancelled MARK is not defensible, regardless of what the printed invoice says.

6. QR code physically illegible or absent on the printed page. Treat as MARK-missing for verification purposes and fall back to the manual two-step described earlier: read the printed 15-digit MARK by eye, look it up directly in Book B, and verify amounts against the AADE record retrieved via the portal rather than via the QR. If both the QR and the printed MARK are absent, this collapses into case 1: missing MARK, not a valid tax document, request a corrected invoice. A legible QR is the operational ideal; a missing one is recoverable; a missing MARK is not.

Verification cadence: how often to check

There are four cadence options, and choosing between them is mostly a question of how much exposure the AP function is willing to carry on the gap between receipt and verification.

Verify every invoice at receipt. The gold standard. Each document hits the gate before it enters the ledger; nothing posts unverified. Realistic only with automation once volume crosses roughly fifty Greek-supplier invoices a month — past that point, the receipt-time check is a structural commitment rather than a process anyone can sustain manually. Catches every problem at the earliest possible point and produces the cleanest audit trail.

Verify on supplier onboarding plus monthly Book B reconciliation. Run the full verification once when a new Greek supplier is added: confirm myDATA participation, confirm the AFM, confirm the document the supplier sends as a sample resolves cleanly. After onboarding, individual invoices flow through with a lighter format check, and a monthly Book B reconciliation surfaces drift — orphans, unmatched entries, status changes. This is a reasonable middle ground for low-to-mid volumes with stable supplier rosters. The blind spot is the within-month window: an individual invoice that fails verification will not be caught until the monthly reconciliation runs, which can be days to weeks after posting.

Risk-based sampling. Smallest teams, highest-trust suppliers — verify a sample of invoices and let the rest pass through on the strength of the printed MARK alone. The weakest of the four. A sampled-only approach exposes the buyer to the full discrepancy and omission penalty regime on whatever the sample missed: 5% net-value penalty exposure on undetected divergences under the Greek tax procedure framework, on top of the disallowed input VAT for documents that turn out not to have been transmitted at all. Sampling reads like a sensible trade-off until an audit picks the unsampled invoices.

Post-2026 zero tolerance for mandated suppliers. Once a supplier is in mandated phase, every invoice they issue must carry a verifiable MARK; an invoice from a mandated supplier that does not verify is not a valid tax document, full stop — not a process miss, not a soft-fail to be cleared by a reviewer. The 2026 mandate tightens the realistic policy floor for any AP function that processes Greek supplier invoices at meaningful volume. Onboarding-only and risk-based sampling are no longer defensible policies for mandated-supplier flows; the regime has effectively foreclosed them.

The honest read is that the choice is a trade-off between throughput and exposure, and the trade-off has shifted. Pre-mandate, sampling and onboarding-plus-reconciliation were operationally reasonable for many AP functions. Post-mandate, at meaningful Greek-supplier volume, anything other than verify-every-invoice with automation leaves audit defence to whatever the random invoice that gets pulled happens to look like. The cadence policy is one of the few AP-process decisions where the regulatory floor and the operationally sound choice have converged.

What MARK verification does not protect against

A clean MARK verification confirms two things: the invoice was transmitted to AADE, and the data on the page matches what AADE received. That is the perimeter. Anything beyond it is a separate control, and a clean verification does not stand in for any of them.

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 in the correct format, place of issuance, currency declaration, supply description specificity, exemption legend where applicable, and the rest. MARK verification does not check formal field correctness; it checks transmission and amount match. An invoice that posts cleanly through the gate but has a malformed receiver AFM or a missing exemption legend is still a defective tax document.

E3 classification correctness. Whether the receiver has classified the document correctly in their Book B for income-tax purposes — the χαρακτηρισμός step — is downstream of verification and entirely separate from it. Verification confirms the document; classification assigns it to the right E3 category. A cleanly verified invoice that is misclassified produces a tax-return defect that no amount of receipt-time verification can catch.

Post-transmission cancellation. Verification status is point-in-time. A MARK that resolves cleanly today can be cancelled tomorrow — the issuer corrects an error, withdraws an invoice, or replaces it with a corrective transmission. Receipt-time verification is silent on cancellations that happen after the check. The defence is a periodic re-verification pass before the VAT-return submission window closes; without it, a portion of the input-VAT claim could be sitting on cancelled MARKs the AP function never re-checked.

Adjacent document-type compliance. myDATA covers more than commercial invoices. Electronic delivery notes, retail receipts, and other document types have their own transmission and verification rules under the same regime. MARK verification on the invoice does not confirm anything about the delivery note that goods moved on, the receipts the same supplier issued at retail, or the corrective documents that flow through other myDATA channels. For the parallel control on the transport side of the same regime, see Greek electronic delivery note rules under the same myDATA regime.

MARK verification is the gate that keeps invalid documents out of the AP ledger. The rest of the compliance stack — invoice-field validation, Book B classification, periodic re-verification, related-document controls — runs on top of that gate. The gate is necessary; it is not, on its own, sufficient.