Payment Channels

EET 2.0’s reportability test is unusual: it turns on where and how the payment happened, not on the payment instrument. A card payment can be reportable at the counter and not reportable in an e-shop. The Unified API carries this with the channel field on PaymentDetails.

The legal rule (Act §§ 5–7)

Payment	Recorded?
Cash	Always — including away from the premises and outside personal contact. One exception: cash taken by a postal intermediary (cash on delivery) and remitted to the taxpayer’s account
Anything not cash	Only in personal contact with the taxpayer, or in connection with supplying goods/services at their premises or in their vehicle

Worked examples, all from the authority’s published Q&A:

• Remote card or QR payment (payment gateway, QR on an e-shop page) — not recorded, even for a merchant who also runs a shop.
• Card or QR at the counter — recorded. Same instrument, opposite answer.
• What the invoice says is irrelevant: marked “by transfer” but paid in cash at the till → recorded; marked “cash” but actually paid remotely → not.
• Click-and-collect, paid online, merely collected — not recorded. Ordered online, paid at the counter — recorded.
• A tradesman paid on the spot records; invoiced and paid later does not.
• Self-service petrol stations and self-service grocery shops — recorded.
• Fleet cards at the pump — not recorded (dispensing only books a debt).

There is no binding assessment procedure: a taxpayer in doubt is directed to the authority’s informal infoline.

The channel field

{
  "amount": "250.00",
  "currency": "CZK",
  "type": "CARD",
  "channel": "REMOTE"
}

• channel is optional and defaults to CONTACT (= reportable).
• CARD / ONLINE / OTHER / VOUCHER payments are included in the reported total (celk_trzba) unless explicitly marked channel: "REMOTE". Excluding a genuinely remote payment is an explicit integrator action.
• CASH is always reported. A CASH payment marked REMOTE is rejected (4xx).
• OUTSTANDING is never reported, independent of channel — it books a debt.
• On a mixed-tender receipt, celk_trzba is the sum of the contact-reportable payments only. A receipt whose reportable sum is zero results in no message to the authority.

What this means for your POS

Your POS must know, per payment, whether it happened in contact or remotely. If your platform serves both in-store and e-commerce flows, this typically maps to the sales channel you already track.

💡Tip

When in doubt, the safe default is the API’s default: CONTACT (report it). Over-reporting is corrected later; silently under-reporting is not.

📘Note

Compliance guidance on the genuine edge cases (a terminal carried by a delivery driver, an on-premises order paid remotely, ONLINE/OTHER classification) is being finalised and will be added here.

Currency

• celk_trzba is always CZK, and the EET message carries no currency field.
• The API therefore rejects non-CZK receipts.
• currency on PaymentDetails is optional and defaults to EUR if omitted — always send "currency": "CZK" explicitly.
• Foreign-currency support via a merchant-declared conversion rate is planned; until that API surface exists, non-CZK sales cannot be reported through SIGN CZ.

Vouchers

The Act splits voucher flows into sell (reported when the voucher is sold) and redeem. The dedicated EET voucher fields are in scope but not yet mapped in the API. Until they are, avoid receipts that both sell and redeem vouchers in one transaction, as the total can double-count.