Requirements for Fiscal Electronic Signature Device - FESD in Kenya

1. Who is obliged to use Fiscal Electronic Signature Device (FESD)?

1.1   Every person or company that uses a computer accounting system and issues financial documents need to fiscalize the procedure by the use of FESD.

1.2   Persons or Companies that issue exclusively retail receipts are not obliged to use FESD but can use Fiscal Cash Registers or Printers. They may, however, be required to use FESD instead if they use a PC to issue retail receipts. The other alternative is to use a Fiscal Printer or Fiscal Cash Register.

1.3   Persons or Companies that issue both retail receipts and financial documents such as invoices and transport documents using a PC have to choose between using a FESD for all documents or choose a combination of Fiscal Cash Register or Fiscal Printer for the retail receipts and FESD for the invoices and other accounting documents.

1.4   Persons or Companies that issue only retail receipts using a computer may use Fiscal Printer with Electronic Journal and keep electronic copies of the retail transactions instead of paper copies. The Fiscal Printer with Electronic Journal is approved if its specifications are as described below.

2. What are the software and hardware specifications of a FESD?:

2.1   Hardware Specifications

2.1.1   An FESD is a PC peripheral device that contains one printer, a simple keyboard and display and offers at least one serial port and one Ethernet port for connection with the host PC.

2.1.2   An FESD has a fiscal memory securely fitted permanently inside the plastic case and the plastic case is sealed exactly like the Fiscal Cash Register is sealed.

2.1.3   The keyboard and display should allow the tax inspection teams from KRA, using the FESD detached from the PC, to get printouts of the contents of the fiscal memory showing the electronic signatures that are kept in fiscal memory for each working day.

2.1.4   The internal working memory of the FESD has to have the capacity to hold at least 10,000 single document signatures before it requires a Z signature.

2.1.5   The FESD as a PC peripheral does not need an internal battery for operation without mains power, but it must have adequate internal battery so that it will not lose any data during sudden power failures and be also supplied with internal Real Time Clock that will keep time even when the device is turned off.

2.1.6   The display of the device must be alphanumeric and provide easy to understand messages for the user and the tax inspection authorities.

2.1.7  The permitted network configuration is where one SSFDRS shall operate several computers based on the fact that the overall processing speed of one ESD is established by the manufacturer to be 20KBytes/sec using the Ethernet port’s inbuilt data security features.

2.2   Software Specifications

The FESD, being a PC peripheral device, can only get approval if it is accompanied by software capable of the following:

2.2.1   An FESD has to be accompanied by appropriate Software Driver for Windows 98, 2000 and XP allowing the easy installation and operation of the device in such operating environments.

2.2.2   The above Software Drivers have to communicate with the FESD, capture data from windows applications running on the PC, get the electronic signature for each document, create electronic copies in the form of files in the PC for every document and each relative signature, provide for automatic backup of such files and handle the end-of-day Z report and signature files.

2.2.3   An FESD has to be accompanied also by software libraries that allow Software Developers to modify their software using the libraries so that they can integrate the Fiscal Electronic Signature Operation with new versions of their software.

2.2.4   Fiscal ESDs must use international standard algorithm SHA-1 to produce the electronic signature of one entire financial document whether this may be a one line text document or a multi-paged detailed invoice.

3. Back up of PC data

3.1   Any PC that uses the FESD as it fiscal peripheral must be backed up on a daily basis. The responsibility of the trader is to maintain two copies of data processed by their PC. Technically a backup should occur after a record has been issued a signature by the FESD.

3.2   KRA shall enforce the daily backing up of PC information as the day's 'Z' signature report is taken at close of day. Online backup is also desirable.





Many countries today have special laws in place that make it obligatory for anyone who is selling goods or services to consumers to use approved by the tax authorities cash registers that have special security features that enable the authorities to check in a reliable way the totals of tax that the retailer has to pay.


Common in all fiscal countries the security features for the approved tax registers are as follows:
1. The fiscal cash register is sealed with the so-called fiscal seal. This seal is placed in a visible place and is a simple lead seal that has to be broken in order for someone to open the case and gain access to the internals of the Electronic Tax Registers - ETRs
2. All sensitive data such as the totals of each tax category and the total turn over for each day are permanently stored in a special non-volatile PROM (programmable, read only memory) memory which is also permanently fixed to the plastic case of the cash register. This memory is called fiscal memory and it is a trusted device by the authorities.
3. Each cash register has a unique serial number securely written in the fiscal memory and assigned to the owner of the cash register when he buys it
4. There is a set of specifications that the software and hardware of the ETR must follow in order to get the official approval.


In Europe only Greece has passed a special law that takes the concept of retail fiscal units into the realm of Business to Business transactions covering any financial document such as invoices, transportation documents etc in the form of electronic signature.


For a tax authority the concept of electronic signature has the following key characteristics:
1. The electronic signature device (ESD) has a fiscal memory, just like the retail ETRs
2. The electronic signature device (ESD) has a unique serial number just like the retail ETRs and is uniquely assigned to the business that buys it
3. The electronic signature device (ESD) is used in conjunction with the PC system of a company that is running the accounting software normally used to print the financial documents such as invoices etc.
4. Each and every financial document, to be valid and acceptable, must bear at the end of it the electronic signature
5. Each and every financial document is kept as electronic copy in computer files, together with its electronic signature as issued by the ESD
6. The companies do not need anymore to keep paper copies of their financial documents since now the tax authorities have a trusted device (the fiscal memory in the Electronic Signature Device) which can certify beyond doubt the authenticity of the computer file

E-Signature Device

Electronic Digital Signature is an intelligent means that computers are used to sign documents using 77 digits that are computer generated based on the combination of all sales transactions generated that particular day. A hashed (calculated) value that is generated from the ESD stored in both the computer and ESD.s memory. If any change is made on the stored sales transactions of any day, no matter how slight the change is, the signature stored in the ESD and one stored in the computer will not match. That makes ESD evidence of data integrity that is sufficiently admissible in the court of law. Electronic Signature is an AUTOMATIC proof of guilt.


This law applies to any computer based, printed tax documents issued to a third party. Here 'tax documents' include every document that previously had to have the tax authorities' stamp of approval, which is the punch-holes on the paper document.

These tax documents mainly are invoices and transportation documents. If your accounting software issues (prints) invoices to third parties or goods transportation documents, it certainly needs to be upgraded to the new law. If your accounting software does not issue such documents you don't need to do anything. If you issue such documents by hand, again you do not need to do anything.


Now, supposing you do issue invoices by computer and not by hand. You certainly need to comply with this law. This law in a nutshell has three requirements:

Suppose you are to print an invoice.
1. The text of the invoice passes through the 'Electronic Signature Device' and gets a signature created by algorithm HASH-1. The electronic signature is 40 bytes long and is printed at the last line of the invoice document.
2. The text of the invoice is saved in a file named DDMMSSSSS_a.txt, the digital signature is saved in a file named DDMMSSSSS_b.txt, the DDMMSSSSS part of the name meant to contain day, month, serial number of document and serial number of ESD.
3. You do that for every invoice of a day.
4. The end of the working day you request from the ESD to perform the HASH-1 algorithm over all the _b.txt signatures of the day. The electronic signature thus created is saved in a file under the name DDMMSSSSS_c.txt and also kept in ESD's fiscal memory (PROM memory). This is called a 'Z' report.

So, for every working day you keep in your computer (or server) a number of _a.txt and _b.txt files which correspond to the tax documents you issued that day and one _c.txt file that contains the signature of all _b.txt signatures of that day.

The idea is that now you do not keep paper copies of your tax documents and you issue tax documents on plain paper with no tax authority stamp (as previously required). The _a.txt and _b.txt files are enough.

The tax authority will read from the ESD fiscal memory the _c.txt permanent record for any given day, then this _c.txt signature will verify all the _b.txt signatures kept in your computer for that day, which in turn will verify the _a.txt document which is the copy of the original issued invoice.


To comply with this law a software developer can follow two roads: one, he can implement a TYPE A (as the law says) solution, and two, he can implement a TYPE B solution.

TYPE A means the software developer does nothing to his software and he simply installs a so-called 'fiscal printer driver' to which he redirects his printing. This driver takes care of everything, handles the interface with the ESD, prints out the signature and keeps the necessary _a, _b and _c.txt files.

TYPE B means the software developer integrates the communication with a given ESD into his application by modifying his sources.

We supply both solutions. The TYPE A driver can now handle even graphics printouts such as those coming out of Crystall Reports. If you wish to work for a TYPE B approval, then you can download a .dll library which will provide you with all necessary function calls to communicate with the ESD and maintain the _a, _b and _c.txt files.

20 October 2005

Copyright © 2005, Kenya Revenue Authority. All Rights Reserved.