EET 2.0 Roadmap
Czechia is reintroducing the electronic registration of sales. This page shows the route to 1 January 2027 — what happens when, and what you have to do before each stop.
The dates below follow the tax authority's published interface documentation, Elektronická evidence tržeb 2.0 – Format and structure of registered sale information and description of the data interface, version 1.2 of 25 August 2026. The Czech original is the only binding text. Source: eet.gov.cz – dokumenty k EET 2.0
The route
The onboarding window is November and December 2026. Certificates cannot be issued before 1 November, and a company can obtain at most 10 per day per establishment — so a fleet of registers cannot be done in an afternoon. Do not leave it to the last week.
Certificates are valid for 366 days. One ordered in November 2026 expires in November 2027, so plan renewal as a recurring annual task rather than a one-off. EFR warns when a certificate has less than 31 days left.
What changes for you compared with EET 1.0
If you integrated with EFR for the old EET, the good news is that the new message asks for less, not more.
| EET 1.0 (until 2023) | EET 2.0 (from 2027) | |
|---|---|---|
| VAT breakdown per rate | Required | Not sent at all |
| Security codes PKP / BKP | Required, PKP printed when offline | Do not exist |
Sales regime (rezim) | Required | Does not exist |
| Margin-scheme amounts | Required where applicable | Do not exist |
| Acknowledgement code | FIK | POK |
| Taxpayer identifier | dic_popl, DIČ | eic_popl, EIC — CZ + 8 to 10 digits |
| Establishment identifier | id_provoz, chosen by you | id_jednotky, assigned by the DIS+ portal |
| Offline deadline | 48 hours | 48 hours (unchanged) |
| Receipt print obligation | FIK or PKP had to be printed | No statutory print requirement |
In practice: the sale is now reported as who, which unit and register, which receipt number, when, and how much. Everything EFR needs for that, it already has.
Because there is no VAT breakdown in the message any more, Czech tax groups (TaxG) no longer feed fiscalisation. They remain relevant for your own totals and Z reports.
EFR support status
| Capability | Status |
|---|---|
| Signed v4 sale sent to the playground, acknowledgement verified | available |
Transaction data mapping (ESR → v4 message) | available |
| Offline buffering, automatic resend, 48-hour deadline note | available |
| New certificate authorities (EET CA 2 / Playground), profile migration | available |
| Production endpoint | waiting — the production environment does not exist yet |
| Voucher amounts: charging and redeeming purses, cards, coupons | planned |
| Recording sales for another taxpayer (delegation) | planned |
Planned means it will be implemented, but not in the first release. If you need it earlier, tell your contact at efsta — that is what moves it up the plan.
Until the production environment exists, EFR requires the Fiscal_test profile attribute and sends only to the playground. A POK returned by the playground ends in -ff and is not a valid acknowledgement code under the law.
Preparing your rollout
- Now — integrate and test against the playground. See Fiscal Requirements.
- Now — check that
*.trzbyeet.gov.czis reachable from every machine running EFR. See Firewall Settings. - From 1 November 2026 — register units in DIS+, note each unit ID, order certificates, install them via
http://localhost:5618/control, and enter the unit ID asLoc.LegalIdin the profile. - From 1 November 2026 — run a verification-mode Echo and one real sale per register against the production transitional environment.
- Before 1 January 2027 — confirm every register answers with a POK.
If you operate many registers or several legal entities through one EFR instance, start at step 3 early: unit IDs are per taxpayer and per unit, and each one has to be entered somewhere.