Fiscal Requirements

Implementation of the electronic registration of sales (EET 2.0), using data interface version 4.

info

Production starts in pilot mode on 1 January 2027 and is fully binding from 1 February 2027. EFR currently sends to the tax authority's test environment (playground) only. See the EET 2.0 Roadmap.

Reference document: Elektronická evidence tržeb 2.0 – description of the data interface, version 1.2 of 25 August 2026. The Czech original is the only binding text.

Minimum Requirement for the Cash Register Application

After finishing positions and payment registration, the cash register application provides EFR with the transaction data. EFR signs the sale, sends it to the tax authority, and returns the acknowledgement code to the cash register.

Access to the configuration and control functions is provided via web browser, locally at http://localhost:5618/config or from a back-office PC.

Functions of the EFR

Generation of the registered sale data message from the ESR data delivered
Local signature of the message using the point-of-sale certificate (WS-Security, RSA-SHA256)
Request to the EET system over HTTPS, TLS 1.2 or higher
Verification of the electronic signature on the tax authority's acknowledgement
Response to the cash register application
Transaction protocol and journal
Retry handling according to regulations in case of network failure
Tamper-proof archiving (encrypted cloud storage)

What Gets Reported

What the tax authority wants to know about a sale is short. It answers five questions: who is reporting, which unit and register the sale was made on, which receipt number it carries, when it happened, and how much it was.

There is no VAT breakdown, no security code, and no sales regime in EET 2.0.

EFR assembles and signs the message itself. Nothing has to be decided per transaction: the taxpayer ID and the unit ID come from the profile, and everything else comes from the transaction you already send.

info

Voucher amounts, and recording sales on behalf of another taxpayer, are planned for a later release. If you need either, tell your contact at efsta — see EFR support status.

Registration with the Tax Portal

Before reporting to the productive EET system, the taxpayer registers in the Czech tax portal MOJE daně. There, each registrating unit — a branch, a store, a mobile sales point — is registered and receives a unit ID (id_jednotky).

The path through the portal is:

Sign in to MOJE daně and enter Online finanční úřad.
Open your tax information box, Daňová informační schránka plus (DIS+).
Go to the section Elektronická evidence tržeb.
On the Evidenční jednotky tab, choose Založit novou evidenční jednotku and register each unit.
Note the unit ID the portal assigns, then generate and install the certificate for it.

info

These functions appear in DIS+ from 1 November 2026 — before that date the section exists but cannot be used. See the EET 2.0 Roadmap.

warning

The unit ID is assigned by the portal. It is not identical with the ESR.TL (Transaction Location) field and it cannot be chosen freely, which is the main difference from the old id_provoz.

Portal unit IDs typically consist of at least two digits, the last one being 1, 2, 3 or 4. A value outside that shape is accepted by the tax authority but answered with warning 6.

Configure the unit ID in the profile at http://localhost:5618/profile as Loc.LegalId. It is validated locally as 1 to 999999999 without a leading zero.

ESR Format

Transaction data is sent to EFR as an XML or JSON web request. See request and response format.

The following fields have specific meaning when generating the message to the fiscal system:

Attribute	Name	Limits
ESR.D	Date Time	Seconds and time zone are mandatory
ESR.TT	Transaction Terminal	Up to 20 characters
ESR.TN	Transaction Number	Up to 25 characters
ESR.T	Total	Absolute value below 100 million CZK

If the cash register does not supply ESR.TN, EFR numbers the receipt itself and reports that counter as the sale's sequence number.

warning

ESR.TT and ESR.TN must use plain ASCII — letters, digits, and . , : ; / # - _ or a space. A Czech diacritic would break the message signature, so EFR rejects the transaction with #FORMAT rather than silently changing the value.

Fiscal Number

EFR assigns ESR.FN itself, in the form

[{type} ]{LegalId}/{TT}/{counter}

Part	Source
`type`	The non-fiscal document type, upper-cased. Left out entirely for a sale
`LegalId`	The portal unit ID, from the profile
`TT`	The register. A `TL/` prefix is stripped, so `001/1` becomes `1`
`counter`	Kept by EFR per register and fiscal year. Sales and non-fiscal documents are counted separately

For example 4303/1/39 for a sale, or ORDER 4303/1/12 for a non-fiscal document.

A fiscal number supplied by the cash register is never renumbered; if it does not name the configured unit and register, EFR warns.

Non-fiscal Transactions

Non-fiscal postings — operator log in and log out, cash deposits and withdrawals, closures — may be registered with EFR marked by NFS=. They are journalled, and together with cloud storage the journal fulfils the requirements for consistent, coextensive archiving.

EET 2.0 covers registered sales, so EFR currently does not send these postings to the tax authority. Should that requirement change, the behaviour will follow it.

Offline Transactions

If the acknowledgement cannot be obtained within the configured response-time limit, the sale completes normally and the response is returned to the cash register with ErrorCode="#OFFLINE" and no acknowledgement code. The operator is informed on the first offline transaction only, so as not to interfere with cashier actions.

EET 2.0 has no offline codes — nothing extra has to be printed or calculated. The sale is simply stored and resent.

Setting	Meaning	Default	Minimum
`Fiscal_timeout`	The taxpayer's statutory response-time limit. How long EFR waits for an answer before treating the sale as offline.	5000 ms	2000 ms — a lower value is raised to this

info

The law expects a buffered sale to reach the authority within 48 hours. Missing that window changes nothing operationally — EFR keeps resending and the authority still accepts a late sale — but EFR writes one note in the journal, so the delay is documented.

Retry Handling

Automatic retry is performed for all offline transactions. The retry interval increases up to one hour as long as the EET system is not reachable. Each attempt uses a new message ID and is flagged as a repeat submission, as the interface requires; because the authority identifies the sale by its business data, this never creates a duplicate.

A sale is also buffered when no answer at all arrives — the EET system deliberately stays silent for messages it interprets as an attack — and when the authority replies with error code -1, which officially means try again later.

The final, successful retry is logged into the fiscal journal, so the whole transaction is tracked. Queued transactions appear in the status viewer as RetryQueued.

Response and Acknowledgement

A successful registration returns an acknowledgement code (POK): 39 characters, for example 987a6be5-6af5-44f3-b4fc-987654321000-02.

Good to know

A POK issued by a non-production environment ends in -ff and is not a valid acknowledgement code under the law. EFR marks such transactions with a *** TEST *** tag.

Only the acknowledgement is signed by the tax authority, and EFR verifies that signature before accepting the POK as proof. Error responses are never signed.

info

EET 2.0 imposes no statutory obligation to print the acknowledgement code on the customer receipt. What EFR returns for printing is described under Receipt Layout.

Error codes

Code	Meaning	EFR behaviour
`-1`	Temporary technical error on the authority's side	Treated as offline, queued and resent
`0`	Message in verification mode processed successfully	Success — this is the expected answer for an Echo
`2`	XML encoding is not valid	Permanent error, transaction reported as `BAD`
`3`	Message failed the XML schema check	Permanent error
`4`	Invalid SOAP message signature	Permanent error — usually a certificate problem
`6`	EIC has an invalid structure	Permanent error — check `Cmp.TaxId`
`7`	Message is too big (over 12 kB)	Permanent error
`8`	Not processed because of a technical or data error	Permanent error

Error texts are returned in Czech without diacritics and are written to the journal.

Warning codes

Warnings do not prevent the registration — the POK is still issued — but they signal a configuration problem worth fixing. Up to 10 warnings can accompany one answer, and EFR journals each of them.

Code	Meaning	What to check
`1`	The EIC in the message differs from the EIC in the certificate	The right certificate is installed for this taxpayer
`4`	Transaction time is later than the time of receipt	Clock on the EFR machine is ahead (more than 2 hours is flagged)
`5`	Transaction time is far in the past	Clock is behind, or a very old transaction is being resent (more than 2 years is flagged)
`6`	The unit ID does not match the expected portal format	`Loc.LegalId` — see Registration with the Tax Portal

Codes 2 and 7 concern the authorizing taxpayer's EIC and cannot occur, because EFR does not send that field. Code 3 was retired with interface version 4.

Fiscal Certificate Handling

Each registered sale data message must be signed with a key for which an X.509 point-of-sale certificate has been issued.

	Production	Test
Certificate authority	EET CA 2	EET CA 2 Playground
Key	RSA-2048	RSA-2048
Validity	366 days	366 days
Issued via	MOJE daně / DIS+ portal	Simplified process; shared test certificates are published for developers

The certificate file (xxx.p12) and its password are confidential. Upload it on http://localhost:5618/control:

cert_upload

cert_ok

Good to know

The certificate was installed correctly if the green OK bar is shown. EFR warns when a certificate expires in less than 31 days — with a 366-day validity, that warning will fire once a year.

Certificate assignment

As long as only one certificate is installed, or the TaxId of all installed certificates is unique, that TaxId is automatically assigned to the transaction protocol and the appropriate certificate is used ('no touch installation').

If the TaxId of the installed certificates is not unique, or if multiple companies register over one EFR instance (for example running as a cloud service), the TaxId has to be specified in the client profile at http://localhost:5618/profile.

warning

A test certificate may only be used with the Fiscal_test attribute set, and a production certificate only without it. EFR refuses the mismatched combination rather than sending to the wrong environment.

Test/Playground Environment

For testing, transactions are sent to the playground. Set the Fiscal_test attribute in the profile and confirm with Save.

Test certificates

You do not order a test certificate through the portal. Everything needed for playground testing is published on the tax authority's downloads page, eet.gov.cz – dokumenty ke stažení: the playground CA certificates, the access and operational information for the playground, the WSDL, the XML schema and sample messages. The shared test certificates for developers, and their passwords, are obtained as described in that playground access document.

Install a test certificate exactly like a production one, through http://localhost:5618/control. EFR recognises it as a test certificate from its issuer and will only use it while Fiscal_test is set.

warning

These certificates are shared by every vendor testing against the playground, so expect to see other companies' test data on the server side. They are for the playground only and have no legal effect.

info

The playground is shared by all vendors, and its test certificates are shared as well — expect to see foreign test data on the server side. Maintenance window is typically Thursdays 20:00–06:00.

Network Access

Czech fiscal law requires the online registration of each sale transaction. The machine running EFR must therefore be able to reach the EET system. Network devices (router, firewall) have to be configured accordingly unless a web proxy is used.

The hosts for the firewall settings can be found in chapter firewall setting.

A proxy can be defined in the default profile at http://localhost:5618/profile.

The connection can be tested using the Echo feature on http://localhost:5618/control.

echo

Specifics

Rounding of Payment Amount

see Business Case Rounding

Legacy: EET 1.0 (valid until 2023)

The registration of sales under Act No. 112/2016 was discontinued at the end of 2022 and the interface it used (version 3) has been switched off. The chapters below are kept for reference only — the security codes, VAT breakdown, sales regime and establishment number they describe do not exist in EET 2.0 and must not be used for new integrations.

Legacy fiscal requirements (valid until 2023)

Implementation of "Act on Registration of Sales No. 112/2016"

Minimum Requirement for the Cash Register Application

After finishing positions and payment registration, the cash register application provides the EFR with the transaction data to be signed and then prints the sales slip, including the signature.
Access to the configuration to respectively control functions of the EFT is to be provided via web-browser locally http://localhost:5618/config or from a back-office PC.

Non-fiscal Transactions

In addition to revenues, all other non-fiscal postings like operator log in / log out, cash deposits / withdrawals, closure and so on may be registered using the EFR, marked by NF=. Thus, the journal kept in combination with cloud storage fulfills the requirements for consistent, coextensive archiving. Representation in XML is formless, but it is recommended to use predefined tags like <Pay> for payments / withdrawals nonetheless.

Functions of the EFR

The EFR fulfills the following functions:

Fiscal message generation upon ESR data delivered
Local message signature using the Fiscal Certificate
Request to the fiscal system EET over HTTPS TLS 1.2
Response to the cash register application
Transaction protocol
Protocol of Grand Totals per tax group
Retry handling according to regulations in case of network failure
Tamper-proof archiving (encrypted cloud-storage)

Registration with the Fiscal Portal

Before starting to report to the productive fiscal system, the company has to register with the Czech Fiscal Portal. There the fiscal certificate can be obtained.

danovy_portal

Also, the location of the store(s) has to be entered and the message to the Fiscal System has to refer to the corresponding Business premises ID "id_provoz" (Označení provozovny), which is NOT identical with the ESR.TL (Transaction Location) field.

The field id_provoz for the message can be assigned using different methods:

Field `ESR.CZ_id_provoz`

Value is determined by cash register software

Profile config `id_provoz`

Value can be specified in EFR configuration's profile form as:

Element	Example
Value	1-999999
`TL`	`id_provoz = ESR.TL`
`(TL=id_provoz)`	`CZ-001=101 CZ-002=102`

The business premises ID and the number the cash register terminal have to be printed on the receipt:
<Tag Label="provoz/pokl" Value="141/1" Name="TLT"/>

ESR Format

Transaction data is sent to EFR as XML or JSON web request. See request and response format.

The following fields have specific meaning when generating the message to the fiscal system:

Attribute	Name	Message fields affected
ESR.D	Date Time	dat_trzby
ESR.TT	Transaction Terminal	id_pokl
ESR.TN	Transaction Number	porad_cis
ESR.T	Total	celk_trzba
ESR.CZ_id_provoz	See chapter id_provoz	id_provoz
Pos.CZ_field Pay.CZ_field	CZ detail field	See chapter Detail Fields

Restrictions

As the underscore sign "_" is used as signature payload field separator, you may not use it in fields TL, TT, TN; any occurrence will be replaced by "/" within EFR.

Offline Transactions

If the fiscal acknowledge cannot be obtained within the timespan defined (5000 ms by default), the registration response is sent from EFR to the cash register software with an empty fiscal (FIK) tag. It is marked with Errorcode="#OFFLINE", contains a Sign/PKP tag instead of Fiscal/FIK, and the operator is informed with UserMessage="Systémem EET offline" during the first offline transaction (not to interfere with cashier actions).

Good to know

The offline transaction is stored in a separate folder and an automatic retry is performed after a delay.