Process Overview

⚠️Preview

SIGN CZ (Unified API) currently transmits to the tax authority’s playground only. Every confirmation carries test="true" and has no legal standing. Cancellation and correction operations are not yet available.

Your POS sends the sale as a Unified API record; fiskaly signs it, sends the EET message to the Financial Administration, verifies the authority’s signed response and stores the confirmation on the record.

┌─────────────┐              ┌──────────────────┐              ┌──────────────────┐
│   Your POS  │────────────▶ │  SIGN CZ         │────────────▶ │  Finanční správa │
│             │◀──────────── │  (fiskaly UAPI)  │◀──────────── │  (EET 2.0)       │
└─────────────┘              └──────────────────┘              └──────────────────┘
  You send:                    fiskaly:                          Returns:
  • INTENTION record           • maps UAPI → EET fields          • POK confirmation
  • TRANSACTION record         • signs (WS-Security)             • or error / warning
                               • stores transmission evidence

Supported operations

Operation	Supported	Behaviour
INTENTION (OPENING / TRANSACTION / CLOSING)	✅	Accepted. EET 2.0 has no register-open/close message, so these only signal the transaction lifecycle
TRANSACTION::RECEIPT	✅	The only operation that reports to the authority. One record = one EET message
CANCELLATION	⛔ not yet	The customer-facing contract is not final. Do not build against it yet
CORRECTION	⛔ not yet	Same

📘How cancellations work in EET 2.0

A cancellation does not reference the original sale. It is a new message with a negative amount, its own sequence number, and its own sale time. A cashless payment that was recorded but never actually happened (failed authorisation, reversed card payment) is always corrected by a negative message sent afterwards, never suppressed — the sale is recorded at payment authorisation, not settlement. The Unified API operation for this will be documented once it is final.

The POK

Every accepted sale is confirmed with a POK code, returned on the record’s compliance.data as EET,<POK>.

The POK identifies the accepted message, not the sale. Sending the same sale twice (as a resend after an outage does) is accepted both times and returns two different POKs. Keep the confirmation from your first success; do not read a fresh POK as evidence of a second sale. The authority deduplicates on a six-field sale identity: eic_popl, id_jednotky, id_pokl, porad_cis, dat_trzby, celk_trzba.

The taxpayer can see their recorded sales in DIS+, in summary and detail — that is the surface merchants reconcile against.

Record states on a send

Authority outcome	Record state	Meaning
Confirmed	recorded	POK on compliance.data
Retryable rejection (kod −1 / 8) or transport failure	FAILED	Resend required — the sale is not recorded. The 48-hour legal clock is running; see Outages & the 48-Hour Rule
Terminal rejection (kod 2 / 3 / 4 / 6 / 7) or unexpected response	REJECTED	A client defect; an identical resend cannot succeed. Fix the payload

Error codes (kod)

kod	Meaning	Classification
0	Verification-mode success — a dry run, nothing recorded, no POK. Success, despite arriving in an error element	n/a
−1	Temporary technical processing error — resend later	retry with backoff → FAILED
2	Encoding violation	REJECTED
3	XSD violation	REJECTED
4	Bad / invalid signature	REJECTED
6	Malformed EIČ	REJECTED
7	Message over the 12 kB size limit	REJECTED
8	Message not processed, technical or data error	retry → FAILED
(no response)	The input looked like an attack; the service deliberately stays silent	handle as timeout → FAILED

💡Tip

Rule of thumb: treat unknown negative codes as transient, unknown positive codes as terminal.

Warning codes (kod_varov)

Warnings never block a POK — the sale is accepted and flagged anyway. Every warning is appended to the record’s content.logs as a WARNING entry with the code.

kod_varov	Meaning
1	The message’s eic_popl does not match the EIČ in the signing certificate — the sale is recorded against the wrong taxpayer, and a POK is still issued. This is the one to alert on; it is silent by every other measure
2	Malformed eic_poverujiciho (delegation)
4	dat_trzby more than 2 hours in the future
5	dat_trzby significantly in the past (in practice the playground warns from about 6 months back)
6	id_jednotky does not match the assigned unit-number format. Soft rule only — expected for placeholder or mistyped values; a real DIS+-allocated number does not trip it
7	eic_poverujiciho equals eic_popl

Support

Every authority response carries an X-Global-Transaction-Id. When contacting support about a specific message — especially one that failed days earlier — quote this ID; it is the handle the Financial Administration expects vendors to use.