Fiscal Software Certification

An Italian Experience of Certification Against the Fiscal Legislation

Isabella Biscoglio, Giuseppe Lami and Gianluca Trentanni

Institute of Information Science and Technologies “Alessandro Faedo” of the National Research Council, Pisa, Italy

Keywords: Certification, Requirements, Legislation, Cash Register.

Abstract: This paper describes an experience of software certification in the specific fiscal software domain. The

Italian Fiscal Software Certification scenario and the cash register, as specific kind of fiscal device running

fiscal software, are outlined. Besides, some requirements, extracted from the current legislation, are shown.

As the Italian legislation does not provide it, a Business Process Model (BPM) presenting the fiscal software

certification process is illustrated. The BPM was built by means of a study of the current legislation and it

constitutes the original contribution to the paper. Finally, the challenges of the further technological

adjustments according to the Italian legislation are discussed.

1 INTRODUCTION

The certification of products, processes or services

plays different roles according to the specific

application domain. In the global market, the

certification by independent and reliable bodies can

be an economical and social benefit. Indeed, the

assurance that a product, process or service is

compliant with the requirements expressed by

international standards or national legislation, can

represent a real added value.

However, in specific domains the certification is

mandatory before a product can be put into

operation. E.g. in aviation, the new aircrafts must be

certified before they are allowed to fly.

In the Italian fiscal domain, the certification of

the fiscal software by a third party accredited body

(an accredited University Lab or the National

Research Council) is mandatory. Therefore, the

fiscal software running into electronic devices

suitable for storing, managing and tracing

commercial transactions called fiscal meters, must

be compliant with a set of requirements specified by

the related national legislation (L. 18, 1983) and

must be certified before being put on the market. To

this aim, by further laws and decrees (D.M. 03/23,

1983 et seq.), the Italian national legislation

established modalities and terms for the release of

fiscal meters, regulating both the record of the

commercial transactions and the certification

process. They shall follow to get the final approval

by the Italian income revenue authority.

The software of a fiscal meter may implement

also functionalities not directly related to the

incomes record (the so-called fiscal functions), such

software part is called “non-fiscal” software. The

non-fiscal software usually carries out tasks related

to goods management, accounting capabilities and

so on. In this case it must not affect the correct fiscal

behaviour of the remaining fiscal software and the

non-fiscal software is not an object for the

certification.

About the fiscal software, it is also opportune to

specify that it runs on two types of fiscal meters:

cash registers and automated ticketing systems. In

this paper, only the first one will be considered.

Usually this certification process is carried out

by accredited University Lab or the National

Research Council, and it consists of inspection,

evaluation and verification activities of both

hardware and software components of the fiscal

meter; it follows quite similar steps to be performed

and differentiates mainly by the kind of the test

cases applied. The final approval for the market

release of a cash register is up to Italian income

revenue authority, and it requires that both the

certifications (the hardware one and the software

one) end successfully. Nevertheless, for simplicity,

this paper only addresses the steps required for the

fiscal software certification.

The aims of this paper are the followings:

Biscoglio, I., Lami, G. and Trentanni, G.

Fiscal Software Certiﬁcation - An Italian Experience of Certiﬁcation Against the Fiscal Legislation.

DOI: 10.5220/0005844800540061

In Proceedings of the International Workshop on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn (AMARETTO 2016), pages 54-61

ISBN: 978-989-758-166-3

1) to present the Italian fiscal software

certification scenario along with the involved actors

and the set of requirements to be tested.

2) to describe a specific kind of fiscal device to

be certified namely cash register.

3) to illustrate the fiscal software certification

process by means of a Business Process Model

(BPM, Brocke and Rosemann, 2014).

4) to highlight the challenges implied in the

technological advancements according to the Italian

evolution of the Italian legislation.

In the following, the fiscal software certification

scenario will be described. In Sections 3 the cash

Section 4 some cash register software requirements

will be listed and in section 5 a Business Process

Model for the fiscal software certification process

will be illustrated. Finally, some questions on

technological evolution of the cash registers will be

discussed and the conclusions will be provided.

2 FISCAL SOFTWARE

CERTIFICATION SCENARIO

In this section, some general concepts about

certification are introduced.

Starting from the general concept of certification,

one more specific kind of software certification is

considered along with involved actors, requirements

to be met and objects to be certified.

2.1 Certification Basic Concepts

A generally accepted definition of certification can

be taken from ISO (ISO/IEC Guide 2, 1996): “a

procedure by which a third party gives written

assurance that a product, process or service

conforms to specified requirements”.

Applied to the software area, the software

certification is a procedure by which a third party

gives written assurance that a software product,

process or service conforms to specified software

requirements.

The “assurance” can be given as a result of an

activity, the “conformity assessment”, defined in the

same Guide but refined by the standard (ISO/IEC

DIS 17000, 2004) as “an activity that provides

demonstration that specified requirements relating

to a product, process, system, person or body are

fulfilled”.

Nothing such as a “guarantee” is wanted. The

“demonstration” should be perceived as

“confidence” instead of “proof”. The “confidence” is

something one can try to achieve and in many cases

can never be achieved.

In the software certification context, the purpose

of this activity is to increment the confidence about

the conformance of software products, processes or

services towards some defined requirements.

Finally, the third-party certification should be

meant as an independent assessment asserting that

specified requirements pertaining to a product,

person, process or management system have been

met.

2.2 Actors, Requirements and Objects

of the Fiscal Software Certification

The actors involved in the certification process can

be divided in two groups, who want to give

confidence on the object of certification

(certification and accreditation bodies, suppliers,

sellers, standard makers…) and who want to get

confidence on the object of certification (customers,

users, end users, government…).

Among the first group, the most important

subjects are the certification body and the

accreditation body.

A certification body is an organism with internal

rules, human/infrastructure resources and specific

skills apt to perform certification procedures. In

some cases, the internal rules themselves might be

required to be compliant to defined standards. In

such a case, the certification bodies should be

“accredited”, that is declared capable of performing

certification activities, upon periodical surveillance,

by special organisms called accreditation bodies.

The accreditation increases the value of the

product, process or service to be certified. The

accreditation bodies are specialized per product

category, and, since even the accreditation bodies

need the accreditation, they can accredit each other

by executing periodical conformity assessments with

a “peer reviews” mechanism.

The certification body referred here is the

System and Software Evaluation Centre (SSEC) of

the National Research Council, and the accreditation

body is the Minister of Finances. The SSEC has

been working for a couple of decades in the 3rd

party software products and processes assessment,

improvement and certification.

In the Italian fiscal software certification

scenario, the certification process is approved by the

Minister of Finances, and on its behalf the

certification against the Italian fiscal legislation is

provided. The Minister of Finances appoints the

Fiscal Software Certiﬁcation - An Italian Experience of Certiﬁcation Against the Fiscal Legislation

certification bodies and performs a sort of control on

their certification activities.

Generally speaking, the certification

requirements are substantially standards or

legislation. The standards should meet the criteria of

suitability. Therefore, they should be easy to

understand and to use, grounded on scientific bases,

cost effective, able to capture user needs and to

support evolving techniques. In the case of the fiscal

software certification, the Italian Fiscal Legislation

is the reference as requirements collection. The

above cited suitability criteria are not always

satisfied since in many cases the legislation (as it

will be reported in the Sec.6) is obsolete and not

completely able to support evolving techniques. This

is a challenge that the legislation should handle as

soon as possible.

About the objects of certification, they are

usually processes, products, services or

organizations, and the certification concerns

properties or attributes of the objects. In the case

here considered, the object to be certified is the

fiscal software of a cash register.

The graphic representation of the Certification

and Accreditation scenario for the cash registers is

depicted in Fig. 1.

Figure 1: SSEC Certification and Accreditation Scenario.

3 CASH REGISTERS

First of all, it is opportune to define what a cash

The current Italian legislation specifies what is a

cash register, why it was introduced, which are its

components, what kind of documents it must issue,

and the specific normative requirements that each

issued document should satisfy.

What it is: The cash register is a fiscal device

designed to record and process numerical data

entered by the keyboard or other suitable functional

unit of information acquisition, equipped with the

device to print on special supports the same data,

and their total (D.M. 03/23 all. A, 1983).

Why it was Introduced: in 1972 Italy has adjusted

its tax policies to the other countries tax policies

introducing the value added tax (V.A.T.) (D.P.R.

633, 1972). By V.A.T. introduction, a supplier of

goods or services must charge to the customer the

payment of a tribute, and in turn the supplier must

pay that tribute to the Government. Subsequently to

the V.A.T. introduction, the phenomenon of the tax

evasion quickly increased. It was necessary to

monitor the revenues of the commercial activities in

order to check the regularity of their transactions in

terms of data integrity and security. In this context,

the fiscal receipt was considered the instrument to

oppose the tax evasion since it allowed to keep trace

of the payments and to monitor the revenues of the

commercial activities. As result of this exigency, the

law (L. 18, 1983) established the duty for the cash

payment, for the sale of goods, not being subject to

the emission of an invoice and occurring in shops or

open public places.

Consequently, the cash register must satisfy

some requirements of security and, in particular, of

integrity in order to prevent “unauthorized access to,

or modification of, computer programs or data”

(ISO/IEC 25010, 2011).

Its Components: The cash register is composed

of indicating devices (typically screens), a printing

device, a fiscal memory and the casing. Each

component must satisfy specific normative

requirements. In particular, the indicating devices

must be two and must be placed on the two opposite

sides of the cash register in order to allow to the

purchaser an easy reading of the displayed amounts.

The displayed characters must be at least seven

millimetres high.

The printing device provides for the release of

the fiscal receipt, daily fiscal closing report and of

the electronic transactions register. Printed

characters must be at least twenty-five millimetres

high and must present appropriate requirements of

clarity and easy readability.

The fiscal memory is an immovable affixed

memory that contains fiscal data. It must record and

store the fiscal logotype, the serial number, the

progressive accumulation of the amount, etc. In

order to guarantee the integrity of its data, the fiscal

memory must allow, without the possibility of

cancellation, only progressive increasing

AMARETTO 2016 - International Workshop on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

accumulations and the preservation of their contents

over time.

Finally, the casing must foresee a unique fiscal

seal by means of a single screw that ensures the

inaccessibility of all hardware components involved

in the fiscal functionalities of the cash register,

except for the paper management. Also, onto the

casing, must be applied in a well visible place on the

front toward the buyer, a slab with reported data as

mark of the manufacturer, machine serial number,

data of the model approval document and the service

centre.

What Kind of Documents it Must Issue: The cash

registers have to be able to print a fiscal receipt, a

daily fiscal closing report, and an electronic

transactions register. Each document must contain

mandatory information specified for single

indention, for instance: company name, owner name

and surname, V.A.T. percentage and company

address, accounting data, date and time of the fiscal

receipt issue, the fiscal logotype, the total amount of

the payments of the day, the cumulative total of the

amounts of the daily payments, etc.

The Italian legislation provides a detailed

refinement of this generic descriptions providing

hardware and software requirements that better

characterize the structure and functionalities of a

valid cash register (D.M. 03/23 all. A, 1983). In

particular, the legislation requires two separate

certification processes: one for the hardware

components and one for the software layer. The two

processes are quite similar in the steps to be

performed and differentiate mainly by the kind of

the test cases to be applied. Only for aims of

clarifying, the hardware components testing

requires, for instance, water tightness or battery

capacity, and evaluations of HW reliability,

measured by Mean Time Between Failure (MTBF).

For the software components, black-box tests are

performed, according to the software requirements

required by legislation and below reported.

The certification of a cash register needs that

both the processes terminate with successful results.

For aim of simplicity this paper only details the steps

required for the fiscal software certification.

4 FISCAL REQUIREMENTS FOR

CASH REGISTER SOFTWARE

The cash register industrial life-cycle includes

different situations like regular functioning,

exhausted fiscal memory, disconnected devices, etc.

From the ministerial decree (D.M. 03/23, 1983) on,

the Italian legislation has disciplined these different

situations imposing precise technological constraints

with a subtle level of detail.

The complete list of requirements that the cash

legislation, even though it is sometimes obscure and

misunderstood. Anyway the legislation remains the

reference point for fiscal software developers and

certifiers.

In the following some extracted requirements

will be introduced. These are organized according to

the specific situations of the cash registers life-cycle.

During the Regular Fiscal Functioning (that is

with a fiscal memory that records and storages

accounting data), a cash register must issue:

• a fiscal receipt with some of the following

information specified for single indention:

company, company name, name and surname

of owner, V.A.T. number and site of the

company, accounting data, date, time of

issuing of the fiscal receipt, fiscal logotype

(compliant with the model that the legislation

requires) etc. 

• a daily fiscal closing report with some of the

following information specified for single

indention: V.A.T. number and site of the

company, eventual amounts of sales, number

of issued fiscal receipts, number of issued

non-fiscal receipts, date and time of issuing

of the fiscal receipt, number of the fiscal

resets, fiscal logotype (compliant with the

model that the legislation requires). 

• an electronic transactions register with some

of the following information specified for

single indention: accounting data, date, time

of issuing of the fiscal receipt, number of

issued non-fiscal receipts, etc. The

transactions electronic register was

introduced by the (P.M. 31/05, 2002). Before

this date, the transaction register was papery.

During the Data Input, it must not be possible:

• To change time in impossible formats (for

instance: 26:44).

• To change date in impossible formats (for

instance: 31/09/2012).

• To issue the fiscal receipt with a series of

articles whose sum is greater than fixed max

value per total of receipt (MAXSF).

Fiscal Memory Close to the Exhaustion

(possible only from 2 to 5 closures to the

exhaustion):

Fiscal Software Certiﬁcation - An Italian Experience of Certiﬁcation Against the Fiscal Legislation

• In the daily fiscal closing report must appear

the message “memory close to the point of

exhaustion”. 

• In the last daily fiscal closing report must

appear the message “memory exhausted”.

With Exhausted Fiscal Memory: 

• The command of issuing a fiscal receipt must

not be executed. 

After an Interruption of the Electricity: 

• The fiscal receipt must be compliant to the

legislation. Therefore, it must be report all

information cited above. 

• The last daily fiscal closing report must be

compliant to the legislation. Therefore, it

must report all information cited above. 

If the Printing Device is Disconnected: 

• Any issuing of fiscal documents by the cash

• Congruent warnings must be reported.

If the Indicating Device is Disconnected: 

• Any issuing of fiscal documents by the cash

• Congruent warnings must be reported.

If the Fiscal Memory is Disconnected: 

• Any issuing of fiscal documents by the cash

• Congruent warnings must be reported.

As mentioned above, these are only an extract of

a broader collection of cash register software

requirements that the legislation requests. They have

been reported in order to underline the level of detail

that the Italian legislation has identified in this

matter.

The global collection constitutes a Requirements

Repository that the SSEC keeps continuously

updated and aligned to the continuous modifications

in the legislation imposed by the designate

authorities.

To each requirement collected in the

requirements repository a set of specific test cases

and responses is associated and executed during the

test phase.

5 A BUSINESS PROCESS MODEL

FOR THE CASH REGISTERS

CERTIFICATION

In this section, a Business Process Model of the

fiscal software certification process is presented.

For clarity purposes, it is important to specify

that the BPM is not provided by the Italian

legislation but it is an original contribution of this

paper and is based on the analysis of the legislation

itself.

The certification process of the fiscal software

involves three important stakeholders: the

enterprise, the certification centre, the income

revenue authority.

• The enterprise develops the target cash

to both the certification centre and the

validation authority. The developed software

has to be already in-house tested.

• The certification centre performs the

legislation compliance check by means of ad-

hoc generated software testing suites. The

results of the testing phase are summarized in

a testing report. 

• The income revenue authority executes

additional test cases mainly targeting special

cases and exceptions and provides the final

approval. 

In the following, the Business Process Model of

the cash registers certification is illustrated (Fig. 2)

and the tasks executed by the different stakeholders

during the certification process are shown.

5.1 The Business Process Model

As shown in Fig. 2, the process starts with the Cash

target enterprise develops and provides to the

certification centre the fiscal software to be certified.

In particular, during this phase the enterprise

provides to the certification centre the following

materials:

1) the software documentation:

• the architectural model that contains the

description of the hardware and software

components of the cash register

• the functional model that contains the

specification of functionalities implemented

in the source code

• the end user manual with the description of

the interface and the functionalities available

to the final user

• the maintenance procedures necessary during

the cycle life of cash register;

2) the source code of the cash register completed

with the libraries that could be used during the on-

line testing activity;

3) any additional information that can be requested

as completion of the mandatory documentation.

These data are used by the certification centre to

refine the collection of test cases and the

AMARETTO 2016 - International Workshop on domAin speciﬁc Model-based AppRoaches to vEriﬁcaTion and validaTiOn

corresponding correct results to be executed in order

to verify the compliance against the current

legislation. Indeed, on the bases of the architectural

and functional models, subsets of software

requirements are identified and, for each of them,

specific test objectives are selected.

In particular, the SSEC considers five different

test objectives corresponding to different cash

memory of the cash register is not recording data

(fiscal memory is not jet active); fiscal functioning,

i.e. the fiscal memory is activated; abnormal

conditions, i.e. possible anomalous behaviour due to

misinterpretation or incorrect time and data input;

boundary condition, i.e. boundary values for the

fiscal memory use are considered, for example close

to the exhaustion or exhausted; malfunctioning, i.e.

accidental and malicious situations are considered.

According to the selected test objectives, a

customized test plan is built and therefore it can be

executed.

During this phase, the test environment is set up

and it will be reported in the final product of the

certification process, that is a compliance certificate.

By the test plan execution, the selected test cases

are executed and the test results are collected and

compared with the correct results associated to each

of the executed test cases. If the expected result is

the same of that obtained by the cash register, then

the test case is considered as pass, otherwise the test

case is classified as fail. The set of verdicts (pass or

fail) is organized in a Test Report.

In cases of non-compliance of some of the cash

centre notifies to the enterprise the discovered

issues. For these errors of non-compliance a

modification of the source code is requested to the

cash register developers and an optional phase of

regression testing (Pezze` and Young, 2008) is

considered.

In case of total compliance to the Italian

legislation, a Compliance Certificate is issued and

sent to the income revenue authority for further

investigations.

The Compliance Certificate is the final product

of the certification process. It is the collection of the

provided documentation, test report and eventual

remarks and comments of the certification centre.

This certificate can be only successful.

In case of a failed testing session, a report of

detected issues is drawn up in order to lead the

enterprise during its software improvement. After

this, the stakeholder may apply again to a new

testing session.

In the second phase of this process, the income

revenue authority analyses the Compliance

Certificate provided from the certification centre,

and decides if additional test cases could be

necessary or not. Finally, it releases the official

approval for the cash register certification and its

relative commercialization.

6 DISCUSSION

The paper reports an Italian experience of fiscal

software certification inferring from the background

knowledge collected over several decades of

activity. In this long experience many exceptions

with respect the normal process execution have been

experienced. They highlighted some important

challenges that deserve to be reported.

The first challenge concerns the legislation.

Although it plays a central role in the certification

process, often it is still too generic to cover all the

possible exceptions and issues. Such a vagueness

and incompleteness of the requirements determines

misunderstandings, and may cause troubles in

software development and errors in the final

product.

Figure 2: Cash Registers Certification Business Process Model.

Fiscal Software Certiﬁcation - An Italian Experience of Certiﬁcation Against the Fiscal Legislation

In order to reduce this risk, the SSEC tries to keep

updated and aligned with the norms a proprietary

Requirements Repository, that is the collection of

cash register normative requirements, both from the

hardware and software point of view, so to keep

track of any possible non-compliance against the

legislation. Besides, the SSEC collects and updates a

set of practices provided by the designate authorities

to avoid additional errors.

The second challenge concerns the

documentation provided by the producers. Many

times it is not thus complete and accurate so to allow

that specific subsets of software requirements are

identified and, for each of them, specific test

objectives are selected. In these cases, the SSEC is

forced to ask for important integrations to well know

the software to be certified and build up a

customized test plan to be executed.

The third challenge concerns the error handling

discovered during the test plan execution. Although

there are the above cited interventions to limit

eventual misunderstandings, possible problems may

arise during the testing session. In case of non-

compliances, the correction of the source code is

required to the cash register developers. This

intervention has a rather high cost, in terms of time

and effort, spent by both the certification body and

the producer. stakeholders. In more severe cases, it

could be necessary the execution of an additional

phase of regression testing in order to verify that the

source code corrections do not invalidate the already

tested functionalities. For these problems, the SSEC

has adopted the compartmentation of the source, i.e.

wherever possible, by the analysis of the available

documentations as well as code inspection, source

code is sliced into separate components so that only

the test cases related to a specific part are selected

and re-executed. However, this approach for test

case selection and prioritization cannot be easily

adopted because most of times the source code is

implemented as firmware or middleware. Therefore,

strengthening the actions in the previous directions

(updating of the legislation and integration of the

missing documentation) can further limit new

problems during the testing session.

Beyond these issues on the current fiscal

software certification process, it is important to

report that the Italian legislators are trying to

strengthen the transactions traceability as strategy to

improve the effectiveness of the fight against tax

evasion. From this point of view, the abolition of the

fiscal receipt and the adoption of tools for the

electronic invoice and the telematic transmission of

the incomes are considered an effective solution.

These changes require technological

advancement and normative adjustments for the

stakeholders involved in the certification process.

The developers must adapt the fiscal software of

their cash registers to the new normative issues, and

the certification bodies must reorganize their

certification process for the legislation compliance

check. These new challenges advise that the fiscal

receipt is more and more becoming the symbol of a

historic moment destined already to the quick end

(Prokin and Prokin, 2013).

7 CONCLUSION

In the paper the Italian fiscal software certification

scenario has been illustrated. After having

considered the main concepts of the software

certification, its actors and its requirements, the cash

introduced and some its software requirements have

been presented. Subsequently, a Business Process

Model for the cash registers certification has been

shown, and a discussion about the most current

challenges on this specific kind of software

certification closes the paper.

REFERENCES

Brocke, J. v. and Rosemann, M., 2014. Handbook on

business process management 1: Introduction,

methods and information systems. Springer, Berlin,

Germany.

D.L. 326, 1987. Decreto Legge 4 Agosto 1987, n. 326.