Why retailers and POS vendors should begin preparing now for a connected, certificate-based sales-recording model planned for January 2027
A sale becomes a live compliance message
At a checkout in Prague, Brno or Ostrava, the decisive change proposed by Czech EET 2.0 is not that a retailer will again have to record a sale. Retailers have always recorded sales. The decisive change is that a qualifying sale becomes a communication event with the tax administration at the moment it happens. A payment completed in the retail operation is no longer only an internal POS transaction, an accounting event or a receipt printed for the customer. Under the draft, it is also data that must be transmitted, authenticated and capable of being checked by the state in a connected compliance system.
This is why describing EET 2.0 as a simple revival of an earlier cash-register obligation would be misleading. The proposed Act states that its purpose is the uniform and automated collection of information on recorded sales, intended to support fair business conditions and more effective verification of tax obligations. The Czech Financial Administration describes the prepared model in similar terms, emphasizing modernisation, digitalisation, automation and a simpler operating approach built on experience with the previous system.
The available draft requires a taxpayer to record a sale no later than when it is made by sending sales data to the tax administrator through a data message authenticated by a sales-recording certificate. The data is to be sent in XML, using a data structure published by the tax administrator, and the required information includes the taxpayer identifier, the registration unit in which the sale occurs, the cash register identifier, the serial number of the sale, the date and time, the total amount in Czech currency and the identification of the message itself.
For anyone responsible for implementation, this creates an immediate architectural conclusion. EET 2.0 is not a finance department reporting project that can be handled after the sales day is closed. It is a live retail system requirement. It reaches the POS application, fiscal middleware, network availability, store configuration, certificate management, monitoring and support operations because the compliant event is generated where the customer transaction takes place.
The law is designed for modern retail, not only for the physical till
The most strategic definition in the proposal may not be the definition of the sale itself, but the definition of the registration unit. In a traditional fiscalization model, many people still imagine a shop, a cash register and a paper receipt. The Czech draft and the Financial Administration guidance use a broader concept. A registration unit can be a conventional establishment, including a mobile establishment, but it can also be a website, a part of a website or an application on which goods or services are offered. Where the taxpayer conducts business outside such units, the taxpayer itself becomes relevant for registration purposes.
That wording matters for international retailers because the modern sales landscape is no longer organised around one fixed counter. A retailer can have a traditional staffed POS, self-checkout, mobile POS, assisted sales, an app, a website and sales processes in which the customer moves between digital and physical environments. Each of these channels creates configuration, identification, data-routing and operational questions. A country-specific fiscal requirement that recognises websites and applications as registration units must be mapped against the retailer’s channel architecture rather than treated as an isolated store patch.
The draft also defines recorded sales through the character of the payment and the decisive income it creates. Its provisions address contact payments made in cash, through non-cash transfer of funds, through virtual assets and through other specified or similar forms, while also containing detailed rules and exemptions that must be interpreted carefully against the official Czech text. The practical lesson for implementation teams is clear: the scope analysis cannot stop at cash. Each payment scenario must be tested against the legal definition, the sales context and the operational channel in which the payment is received.
For a retailer with several countries and several POS or commerce platforms, this is exactly the point at which fragmented development becomes expensive. A Czech implementation should fit into a common fiscal architecture that can distinguish business entities, registration units, devices, channels and payment flows without forcing every sales channel to invent its own compliance logic.
The customer queue is where real-time compliance is tested
Real-time compliance becomes real only when it is placed in front of a customer waiting to pay. A legal obligation can define transaction reporting in a single paragraph, but a retail operation must still complete the sale during network delays, device failures, software incidents and periods of heavy store traffic. The most practical provisions in the Czech draft therefore concern response time and what happens when the response is not received in time.
The draft defines response time as the period between an attempt by the cash register to send the recorded-sales data and the receipt of a confirmation code from the tax administrator’s technical equipment. It requires the taxpayer to set a response-time limit longer than two seconds, taking the type of activity and network quality into account, so that recording does not hinder the sales process. If the response-time limit is exceeded, the data must be sent as soon as the cause disappears, and no later than 48 hours after the recorded sale.
This is an operational rule with architectural consequences. A POS implementation must know when a transaction has been transmitted, when a confirmation has been received, when a sale is placed into a controlled fallback state and when delayed data must be resubmitted. A retail organisation will need monitoring that makes failed or delayed transmissions visible, reconciliation that confirms every relevant sale has been reported, and support procedures that do not depend on store staff understanding technical communication failures.
The Financial Administration’s guidance reinforces this practical approach. It states that an appropriate device can include a conventional cash register, a computer, a notebook or a mobile device, provided that it can connect to the internet, transmit sales data and receive confirmation from the authority’s system. It also states that where a device fails and immediate transmission is impossible, the data on received payments must subsequently be sent from a functional device after the fault has been removed.
For retailers, the objective must be double: comply with the reporting obligation while protecting checkout continuity. An implementation that reports perfectly in a test environment but creates queues, blocked sales or unresolved offline records in live operation is not a successful compliance implementation.
Certificates and registration units become part of retail rollout management
EET 2.0 also turns tasks that are often treated as technical administration into formal go-live dependencies. Before receiving the first recorded sale, a taxpayer is required under the draft to obtain the necessary sales-recording certificates through the tax information box. The taxpayer must report data on all relevant registration units before obtaining the certificate if recorded sales are carried out in at least one of them. When registration-unit data changes, the change must be notified before the first recorded sale made through that unit after the change, and no later than 15 days from the change.
The Financial Administration explains that EET 2.0 is intended to operate through the DIS+ tax information environment on the MOJE daně portal. Its May guidance states that the registration-unit process will allocate an unchangeable identification number to the unit, which will become part of the transmitted information about the completed sale. It also explains that cash-register certificates are generated through the EET area, can be issued for the enterprise, individual units or devices, and are used for secure transmission, source authentication and protection of data integrity.
This matters greatly for large rollouts. A new store opening, a new app channel, a replacement POS, a relocation, a legal-entity change, a device refresh or a certificate renewal can affect the compliance state of the operation. Certificate ownership and renewal should not be left to local improvisation. Retailers and POS vendors need a controlled inventory of registration units and cash-register identifiers, an agreed certificate distribution model, secure renewal procedures and clear responsibility for emergency revocation and replacement.
The official guidance currently says that certificates for EET 2.0 will be valid for one year and that 2048-bit certificates are supported at present, while future changes may follow security recommendations and stronger key requirements. It also states that technical documentation is planned for publication in mid-June 2026 and that a Playground test environment is planned from 1 July 2026. [4] For solution providers and retail IT teams, this means that the preparation window has already moved from strategic assessment to technical readiness planning.
Scope, exemptions and delegated sales cannot be treated as footnotes
Every fiscal rollout fails in one of two ways: the system does not report transactions that should have been reported, or it reports transactions and processes that should have been handled differently. The Czech draft therefore requires careful scope analysis before development begins. It lists categories of taxpayers and activities excluded from sales recording, including selected public entities, financial-sector bodies and particular activities. It also contains exemptions for vending machines and certain special self-service situations, together with other specific exclusions.
The proposed model also addresses situations in which one taxpayer acts in its own name on behalf of another or where a taxpayer authorises another taxpayer to record revenue on its behalf. Such provisions are particularly relevant for retail groups, concession models, franchise arrangements, marketplaces, shop-in-shop concepts and other operating structures in which the commercial sale, receipt of payment and legal income attribution may not be handled by only one entity.
These rules should not be interpreted from a generic system template. Before implementation, each retailer should create a Czech-specific scope map that connects legal entities, stores, digital channels, payment types, delegated models, exempt activities, returns and corrections to the systems that create, transmit and reconcile the transaction data. The draft provides that returns or corrections are recorded in a comparable manner as negative sales, which makes the treatment of post-sale flows a central design topic rather than an afterthought.
The enforcement model gives the implementation real weight
The proposal is not only a data-transmission framework. It also gives authorities powers to verify compliance, including control purchases, and it establishes offences for serious obstruction of sales recording and for breaches of the obligation to send recorded-sales data to the tax administrator. The draft provides for fines of up to CZK 500,000.
For a retailer, the risk is broader than the value of a fine. A failure identified during a control purchase can trigger internal investigation, urgent remediation, reputational concern and questions about whether other stores or channels have the same defect. In international retail, a compliance failure rarely remains a local software ticket. It becomes a governance issue that needs evidence, traceability and a demonstrably controlled response.
This is why auditability must be included in the first design of an EET 2.0 implementation. The system should retain the relationship between the source transaction, the registered sale, its transmitted message, the confirmation code or fallback state, subsequent resubmission where necessary, and any correction or reversal. Technical logging alone is not enough; the business and compliance teams must be able to reconstruct what happened to a specific sale and why.
An implementation agenda for retailers and POS providers
The first priority is not coding but classification. Retailers should identify all Czech sales processes that may result in recorded sales and map them to their legal entities, registration units, payment forms, POS or commerce systems and correction flows. Stores, mobile POS, websites, apps and non-standard operating models should be examined together because the draft treats the operating landscape more widely than a traditional fixed cash register.
The next priority is architecture. International retailers should avoid pushing all responsibility into each local POS variant. A fiscal middleware or central compliance interface can provide a controlled place for certificate communication, XML message creation, response handling, monitoring, reconciliation and future changes in technical specifications, while the POS remains focused on creating a correct sale and maintaining a fast customer journey. POS software vendors should likewise design the Czech integration as a reusable compliance capability rather than a set of local screen changes.
Continuity testing must be conducted as a retail operation, not only as an interface test. Implementers should deliberately test slow networks, authority timeouts, certificate expiry, device replacement, store opening, registration-unit change, delayed resubmission, returns and corrections. A successful test does not merely show that one XML message is accepted; it proves that a store can continue trading, that every required transaction ultimately reaches the authority, and that the retailer can demonstrate this later.
Finally, preparation must follow the legislative and technical calendar. The draft proposes entry into force for the main operational provisions on 1 January 2027, while some provisions would apply from the day following promulgation. The Czech Financial Administration has publicly described EET 2.0 as planned for launch on 1 January 2027 and has stated that more detailed technical documentation and a testing environment are planned during 2026. [1] [3] [4] Even though final adoption and technical detail may still change, waiting for the final weeks before go-live would leave little time for architecture, rollout, certificate lifecycle design and realistic store testing.
A modern fiscalization law for a connected retail world
The Czech Republic is proposing more than the reintroduction of an earlier reporting regime. EET 2.0 places transaction-level communication back at the centre of retail compliance, but it does so in a market where stores, websites, applications, mobile devices and connected payment methods operate together. A sale can be simple for a customer while becoming highly structured for the retailer responsible for recording it correctly.
For implementation teams, the central message is practical. The Czech draft should be treated as an enterprise retail architecture project whose consequences reach from the legal entity and sales channel design to POS transaction handling, network resilience, certificate governance, monitoring, audit evidence and rollout control. Those who treat it only as a cash-register interface will risk building compliance on a foundation that is too narrow for modern retail operations.
The proposed start date may still appear distant, but the design decisions are immediate. The implementation that best protects retailers will be the one that keeps checkout reliable, makes compliance transparent and builds a reusable architecture for a European retail environment in which real-time fiscal reporting is no longer an exception, but an increasingly important direction of travel.
Sources used
The article is based on the currently available draft legislation and supporting guidance. Because the legal framework is still developing, final implementation decisions should be validated against the adopted Czech law, technical documentation and official instructions applicable at the time of rollout.
[1] Draft of the Act on Sales Records and on Amendments to Certain Other Laws (EET 2.0 fiscalization). Czech Republic / ODOK source document, English machine-translated working version supplied for analysis, 2026. Source link Used as the primary source for draft legal provisions, technical requirements, exemptions, enforcement and proposed effective date.
[2] EET 2.0 – Informace o připravovaném projektu. Financial Administration of the Czech Republic, 2026. Source link Official project overview describing EET 2.0 as a prepared modernised, digital and automated sales-recording model.
[3] Nejčastější otázky k elektronické evidenci tržeb (EET 2.0). Financial Administration of the Czech Republic, 6 March 2026. Source link Official statement describing the planned 1 January 2027 launch and the role of DIS+ and the free web application for the smallest taxpayers.
[4] EET 2.0 – Questions: Technical, Security and Operational Guidance. General Financial Directorate / Financial Administration of the Czech Republic, 5 May 2026. Source link Official FAQ document used for registration-unit, certificate, device, technical-documentation and test-environment information.
[5] Czech: EET 2.0 Timeline and Requirements. Fiscal Solutions Fiscal Portal, 7 May 2026. Source link Supporting overview reporting government approval of the draft and the broader implementation roadmap; legal facts should remain subject to official verification.
Disclaimer: This article is provided for general industry information and technology-planning purposes. It does not constitute legal or tax advice. Official Czech legislation, adopted technical rules and instructions from the competent authority remain the binding sources for implementation.