Zum Inhalt springen
Section navigation

FAQ

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

Do I have to print anything on the receipt?

Section titled “Do I have to print anything on the receipt?”

No. EET 2.0 has no customer receipt obligation — no POK on the receipt, no QR code, no signature codes. EET 1.0’s FIK/PKP/BKP codes do not exist in 2.0. Articles describing receipt codes or a “five-day offline mode” refer to the abolished first generation.

There is no certification regime in EET 2.0 — anyone may ship a compatible solution. What fiskaly provides is that you do not have to build or operate any of it: certificates, SOAP/WS-Security signing, Czech field mapping, confirmation verification, and the resend obligations.

The obligation starts on 2027-01-01 for all taxpayers at once — no phasing, no pilot. Real onboarding (DIS+ declarations, cash certificates) opens on 2026-11-01. Until then, integrate against the playground as described in the Step-by-Step Integration.

I resent a sale after an outage and got a different POK. Is the sale now recorded twice?

Section titled “I resent a sale after an outage and got a different POK. Is the sale now recorded twice?”

No. The POK identifies the accepted message, not the sale. The authority deduplicates on the six-field sale identity (eic_popl, id_jednotky, id_pokl, porad_cis, dat_trzby, celk_trzba). Keep the confirmation from your first success. Two things do break deduplication: changing the amount between attempts, and resending under a different id_pokl — both report a second sale.

In EET 2.0, a cancellation is a new message with a negative amount — it does not reference the original. The Unified API operation for this is not yet available; it will be documented once the contract is final. Until then, a wrong amount cannot be remedied through the API.

A customer’s card payment failed after authorisation or was reversed. What now?

Section titled “A customer’s card payment failed after authorisation or was reversed. What now?”

The sale was recorded at authorisation, so it stays recorded. It is corrected afterwards by a negative message — never by suppressing the original.

Which of my sales must be reported at all?

Section titled “Which of my sales must be reported at all?”

Cash always. Non-cash only when paid in personal contact or at the taxpayer’s premises or vehicle. The same card can be reportable at the counter and not in your e-shop — see Payment Channels.

No. celk_trzba is always CZK and carries no currency field, so non-CZK receipts are rejected. Also note that currency defaults to EUR if omitted — send "CZK" explicitly. Merchant-declared conversion for foreign-currency sales is planned.

What happens during the authority’s maintenance window?

Section titled “What happens during the authority’s maintenance window?”

The Financial Administration takes planned downtime roughly every Thursday 20:00–06:00. Sales complete normally; the messages must be stored and resent — the outage is an explicitly covered cause under the 48-hour rule. Note that SIGN CZ does not yet resend automatically: FAILED records must currently be re-driven by the integrator. See Outages & the 48-Hour Rule.

One payment covers goods from several taxpayers (delegation). One message?

Section titled “One payment covers goods from several taxpayers (delegation). One message?”

No — one payment owed to several taxpayers must be sent as several messages (the authority’s example: fuel sold under delegation plus own coffee, one payment, two messages). Your data model cannot assume one payment → one message.

Where can the merchant see what was recorded?

Section titled “Where can the merchant see what was recorded?”

In DIS+, in summary and detail. That is the reconciliation surface.

What should I quote when contacting support about a failed message?

Section titled “What should I quote when contacting support about a failed message?”

The X-Global-Transaction-Id from the authority’s response — it is the only handle on a message that failed inside a queue days earlier.