Outages & the 48-Hour Rule

EET 2.0 has no offline receipt, no offline signature and no reduced-obligation mode. The entire offline story is: complete the sale, keep the message, resend until the authority confirms. Refusing customers during an outage (“fail closed”) is not what the law asks for — and it still leaves the sale unrecorded afterwards.

The legal rule (Act §§ 17, 20, 21)

• A sale is recorded by sending it, at the latest when the sale occurs.
• The sale “occurs” on receipt of payment — or on issuing the payment order if that came first. For card, QR, transfer, e-wallets and electronic gift vouchers, the clock starts at terminal authorisation, not settlement.
• The taxpayer must configure a response-time limit (mezní doba odezvy) of more than 2 seconds — a configurable timeout, not a constant.
• On exceeding it: resend without undue delay once the cause has ceased, and at the latest within 48 hours of the sale occurring. The 48 hours run from the sale, not from when connectivity returns.
• The duty to send survives the deadline. A late message is still sent, never dropped. There is no field to declare or excuse lateness; the authority reads it from the timestamps. Late sends are not rejected — at most flagged with a warning, and a POK is still issued.
• Penalty ceiling: CZK 500,000 for failing to send.
• A failure on the tax administration’s own side is an explicitly covered cause — including the planned maintenance window every Thursday 20:00–06:00, which every Czech till hits weekly. On outages longer than 48 hours: keep sending, never discard.

Resend mechanics

Resend the original message body with a fresh header, repeatedly, until a POK arrives. You don’t assemble the message yourself — fiskaly constructs and signs each EET message from your Unified API record; the Czech field names below are shown for transparency.

EET field	On resend
uuid_zpravy	New UUID on every attempt — it identifies the message, not the sale
prvni_zaslani	true → false
dat_odesl	New send timestamp
dat_trzby	Unchanged — the original sale time, never refreshed
Everything else	Unchanged

The authority deduplicates on the six-field sale identity — all of which come from the record you create:

EET field	UAPI source
eic_popl	taxpayer tax_id_number
id_jednotky	Location.label
id_pokl	System.label
porad_cis	document.number
dat_trzby	document.issued_at (else send time)
celk_trzba	sum of the receipt’s contact-reportable payments, gross

Consequences:

• Never change the amount between attempts — a resend with a different celk_trzba reports a second, different sale. A queued sale is sent exactly as recorded and only then corrected.
• A resend from a replacement device must keep the original id_pokl — resending under a different register identifier reports a second sale.
• A resend is issued a different POK; keep the first successful confirmation.
• Queued messages are signed at send time (the certificate must be valid when the authority processes the message, not when the sale happened).

Current state in SIGN CZ

⚠️No automatic resend yet

There is no durable queue and no automatic resend in SIGN CZ yet. A failed send leaves the record in FAILED, and nothing re-drives it automatically.

Until the queue ships:

• FAILED means “resend required” — the integrator must implement their own retry against the FAILED state.
• The Thursday maintenance window will produce FAILED records every week; plan the retry for it.
• Retry retryable outcomes (kod −1 / 8, transport failures, timeouts) with backoff. Do not retry REJECTED — an identical resend of a client defect cannot succeed. See the Process Overview for the classification.

📘Note

An automatic store-and-forward queue with per-record message tracking is planned. This page will be updated when it ships.