How to Guide - Fiscal Czech

Fiscal Overview

Fiscalisation is a legal requirement imposed by the Tax Authorities (TA) of an increasing number of countries, but particularly prevalent in the European Union. The common reason, between countries, for fiscal legislation is to record sales in such a way that an inalterable record of each transaction and the VAT due is available to the TA.

Enactor have fiscal solutions available for the majority of European Fiscal countries and continue to work on additional country solutions both inside and outside Europe. Enactor found that a common complaint from retailers was, POS providers and Fiscal Software Solutions providers blaming each other when things went wrong. Enactor’s approach to fiscal is to avoid reliance on third parties wherever possible. This allows Enactor to provide solutions that do not have hidden third party software costs and also give customers a single point of contact.

Whilst Enactor have avoided relying on software partners to provide pre-packed solutions, we recognise the importance of in country experts. We have therefore built a network of partners that both help us initially understand legislation and technical requirements for each country but are also kept on retainer to inform us of any legislation changes and guide us through their implementation. This allows us to keep our solutions up to date and compliant in what is often a fast-changing area in terms of legislation.

While the reasons for Fiscal legislation are common between countries, unfortunately the approach taken differs from one to the next, although there are a number of common patterns outlined below:

Device Based

When each transaction is finalised, it is also sent to physical device which records the transaction in an inalterable way. In some countries, the device also functions as a printer; in others it is USB or network connected device.

Devices contain a fiscal module which will both sign and record each transaction in a write once read many, fiscal memory. The signature produced by the device is usually printed on the receipt so that the customer, or a TA inspector, can see the transaction has been recorded properly. Devices will also have some mechanism to provide the data held to the TA, commonly one of:

• Extract in a defined format, tiggered by the POS

• Internal GPRS connections

• Device requires an ethernet internet connection

• Memory Card that can be given to the TA on request

These Fiscal Devices are certified by the TA and this usually, although not always, means that the POS solution does not need certification.

Service Based

Transactions are sent to an online service provided by the TA which will record the transaction detail and provide a signature back as part of the response. This signature is usually required to be printed on the receipt, in some countries in the form of a QR code. Some TA’s offer an incentive where retail customers can scan the QR code to be entered in a regular lottery, thus encouraging reporting of retailers who are not compliant.

Each country has its own provisions for how to deal with a loss of connection to the service, but it is usual to permit offline sales which, must either be manually recorded or electronically submitted to the TA within a defined timeframe.

Signature Based

In this type of scheme, it becomes the responsibility of the POS to record the transactions in an inalterable way and provide a record of the transactions to the TA. The usual approach is to sign and record each transaction, including the signature of the previous transaction as part of the signed data. This has the effect of producing a chain of signed transactions where a transaction modified at a later date would be detectable, as either the altered transaction or all subsequent transactions would have incorrect signatures.

The second requirement of this type of solution is for the POS solution to be able to provide the transaction data, including signatures, to the TA. This data is usually provided in an XML file often in the common SAF-T format.

Again, it’s common for the signature, or part of it, to be printed on the customer receipt.

Clearly this type of solution requires the TA to have a certain level of trust in the POS provider that they will, properly protect the private key used to sign the transactions and that they will not provide the retailer with a mechanism to alter transactions. It is therefore common for these types of solution to require either a declaration of conformity or formal certification process.

Other Requirements

As well as the above each country has a number of other fiscal requirements that must be adhered to, some of which are common between countries, for example:

• Sales and Returns are not permitted in the same transaction

• Transaction value must be positive

• Ability to produce X and Z reports in a prescribed manner

• Items may not be discounted to zero or negative values

• Particular handling of deposit and balance transactions

• Requirement to produce invoices for transactions that meet particular criteria, over a set value, B2B

• Particular handling of tax for bottle returns

Description

The fiscal approach in the Czech Republic is service based and does not require any specific hardware. Each transaction is both signed locally by the POS to produce a PKP code which is also tokenised to produce a BKP code as well as being transmitted in real time to the tax authority who will return an Authorization code (FIK). Both FIK and BKP codes should be printed on the receipt.

In event of the POS being unable to contact the authorities it is still possible to perform sales and the BKP should be printed in place of the FIK on the receipt. Offline transactions have to subsequently be reauthorised with the tax authority once connectivity is restored but within 48 hours.

Certification of the solution is not required.

Notes

Prior to configuring the solution, the retailer will need to apply for a production certificate with which to sign transactions. The retailer should allow several days for this application to be processed. Similarly, all trading locations will need to be registered in the EET portal.

https://www.daneelektronicky.cz/

Configuration Overview

The following configuration changes are required and should be broadcast to all Czech devices in preparation for go live.

POS Terminal Template

The POS Terminal Template used by all devices in the Czech Republic should be configured to have the fiscalisation Type set to Czech Republic. Currency should be set to Czech Koruna and Locale to Czech (Czech Republic). Configuration of price group is dependent on the approach taken for pricing and the relevant how guide relating to price integration should be consulted.

The Czech Receipt Locale should be added on the printing > receipt locales tab.

The ‘Print Tax Details on Receipt’ flag withing the printing > flags tab should be ticked.

The above changes will need to be broadcast to the relevant devices.

Location

Each location in the Czech Republic should have its Fiscal Location Reference configured within the EM and broadcast out. The Fiscal Location Reference is the ID provided in the EET portal when registering a new trading location.

Tax Groups

The following tax groups should be configured and broadcast to the appropriate Czech devices.

Tax Group ID	Description	Fiscal Tax Rate Reference
CZ_1	CZ Standard 21%	CZ-1
CZ_2	CZ Reduced 1 15%	CZ-2
CZ_3	CZ Reduced 2 10%	CZ-3
CZ_4	CZ Exemption	CZ-4

Tax Schema

The following tax schema should be configured and broadcast to the appropriate Czech devices.

Tax Schema ID	Description	Price Include Tax
CZ	The Czech Republic Tax Scheme	TRUE

Tax Rates

The following tax rates should be configured and broadcast to the appropriate Czech devices.

Tax Rate ID	Description	Display Code	Percentage
CZ_1	CZ Standard 21%	STANDARD	21%
CZ_2	CZ Reduced 15%	REDUCED_1	15%
CZ_3	CZ Reduced 10%	REDUCED_2	10%
CZ_4	CZ Exemption	ZERO	0%

Tax Group Tax Methods

The following tax group tax methods should be configured and broadcast to the appropriate Czech devices.

Tax Group ID	Tax Scheme ID	Tax Rate ID
CZ_1	CZ	CZ_1
CZ_2	CZ	CZ_2
CZ_3	CZ	CZ_3
CZ_4	CZ	CZ_4

Account Credentials

The following Account Credentials should be configured and broadcast to the appropriate Czech devices.

General Tab

Account Credential ID	Name	Use System Key
FISCAL_CZECH	The Czech Republic Fiscal Key Store	TRUE

Other Properties

Property Name	Type	Value
CERT_PW	String	eet
X509_CERT	File	{Signing Certificate provided by tax authority}

Receipt

The format of the receipt is not prescribed by the Czech authorities although receipts should be provided to customers and there are some requirements that must be met.

The following are required to be shown on the receipt:

• The items sold and the amount charged for each item

• Tax breakdown by tax rate

• The fiscal identification code (FIK)

• Tax identification number

• The identification of the business premises (given by EET)

• The identification of the POS

• The serial number of the receipt

• The date and time the sale was received, or the receipt was issued

• The total amount of the sale

• The taxpayer’s security code

• Information on sale regime

Within the POS Terminal Template there is a receipt available named ‘Fiscal 44 Standard Receipt’ which meets all of the above requirements. Although it is likely that a retailer will choose to customise this receipt to meet their needs it should form a good starting point that contains all of the mandatory information. An example of this receipt is shown below.