Czech Republic: Financial Administration publishes guide to EET 2.0 data message items

The Czech Financial Administration has published a methodological guide to the EET 2.0 data message, explaining how each item is completed, with examples for rounding, vouchers, representation, delegation, storno, deposits, and advances. Vendors should check POS logic against it before EET 2.0 starts in 2027.

The Czech Financial Administration has published a new methodological document titled "Popis položek
datové zprávy" (Description of Data Message Items) in the "For Developers – Documents for Download"
section of eet.gov.cz. The document, version 1.0 dated 5 October 2026, clarifies the content of the
individual items of the data message on a recorded sale. Personal and corporate income taxpayers send
this message to the tax administrator under Section 16 et seq. of Act No. 180/2026 Coll., on the Recording
of Sales (ZoET).
The material supplements the technical specification "Format and Structure of Data on Recorded Sales
and Description of the Data Interface for Receiving Data Messages on Recorded Sales". Through that
specification, the tax administrator determines the data structure of the message under Section 16(5)(b)
ZoET.

What the document covers
The 34-page document describes the sales data message item by item and the confirmation message
returned by the tax administration. It then sets out how sales are recorded under representation and
delegation, how storno and corrections work, and how specific situations such as deposits, advances and
discounts are handled. According to its table of contents, it also covers returnable packaging, tips, the
procedure when the response time limit is exceeded and cloud solutions. Each topic is illustrated with
sample XML messages.

Key clarifications on the data message

Several clarifications directly affect software logic. 

1. The message UUID (uuid_zpravy) identifies the message, not the sale. A new UUID is generated for
   every message, including repeated sending, storno, and corrections.
2. The prvni_zaslani flag is "true" for the first attempt to send a sale, whether or not it succeeds, and
   "false" for every repeated attempt. A repeated attempt is needed only when no confirmation code
   (POK) was received.
3. The time of sale (dat_trzby) is the moment the payment is received or, if earlier, the moment of the
   payment order, for example, a card or QR payment. Recording a sale "in advance" without a specific. The payment order is not acceptable.
4. The total amount (celk_trzba) is the amount actually received, in CZK, and including taxes. For a
   purchase of CZK 81.60, a cash payment rounded to CZK 82 is recorded as 82, while a card payment is
   recorded as 81.60. The message contains no separate VAT data, no item-level data, and no customer.
   data.
5. Optional items that do not apply must be omitted entirely, not sent empty.
6. The sequence number (porad_cis) must form a logical series. Gaps are allowed, but the taxpayer must
   be able to explain them on request.
7. Top-ups and drawdowns of stored-value instruments with a limited network, such as e-wallets or
   Vouchers for unspecified goods are reported in urceno_cerp_zuct and cerp_zuct. A gift voucher for a
   A specific service is recorded only when it is purchased.

Representation and delegation

The document describes five situations. In the first, a taxpayer records its own sales. In direct
representation, the agent uses the principal's EIČ, evidence unit and certificate. In indirect representation,
such as a commission sale, the agent records the full amount under its own identity. In delegation by one
taxpayer under Section 10 ZoET, the delegated taxpayer also states the delegator's EIČ in eic_poverujiciho.
Where a sale accrues to several taxpayers, povereni_vice_popl is set to "true". As a rule, each situation
requires its own message, with two stated exceptions for combining indirect representation with other
sales in one payment.

Storno, corrections and other situations

Returns and corrections are recorded as a negative sale. The storno message does not refer to the UUID
of the original message. It carries its own sequence number, and the evidence unit and cash register
where the refund takes place. Refunds made without personal contact, such as bank transfers, and
Refunds of sales that were not subject to recording do not have to be recorded. A deposit is recorded only
when it is retained as payment and was originally paid in person. An advance and the final payment are
separate sales. A discount is reflected only in the amount actually received.

The document is valuable mainly for software vendors and integrators, because most of the rules it
clarifies are implemented in POS logic rather than decided at the till. These include UUID generation, the
repeated sending flag, the handling of empty items, and the independence of storno messages. The
worked examples can serve as ready-made test cases.

It should be kept in mind that the document is a methodological material. In our reading, it expresses the
tax administration's interpretation and practice, and the binding rules remain those of ZoET and the
technical specification. This is our interpretation; the notice itself does not state the legal status of the
document. In several places the document states that an alternative approach "will not be disputed," for
example recording an exchange as a negative and a positive sale instead of recording only the balance.
Vendors should make such choices deliberately and document them.

What should vendors and businesses do?

Vendors should check their EET 2.0 implementation against the document before production use:

1. Compare the generation of uuid_zpravy, prvni_zaslani, dat_trzby, and porad_cis, and the omission of
   empty optional items, with the clarified rules.
2. Review amount and rounding logic for cash and card payments, combined payments, vouchers, and
   stored-value instruments.
3. Map the representation and delegation scenarios used by clients, such as fuel stations, commission
   sales and shared sales to the correct fields, evidence units, and certificates.
4. Implement storno as an independent negative sale, and decide which accepted approach to use for
   exchanges. Use the examples as test cases in the Playground environment or in verification mode.
5. Businesses should confirm with their vendor that the software follows the document and train staff.
   to recognize situations such as deposits, advances, and commission sales.

This article is based on the notice of the technical team of the Czech Financial Administration and on the
document "Popis položek datové zprávy", version 1.0, published on eet.gov.cz

Here is the link to the official source

Aleksandra Vukić, Business Analyst at Fiscal Solutions

Linkedin profile