PROCUREMENT DOCUMENTS

Bidding Documents
for
Procurement of
Information Systems Design,
Supply and Installation

Procurement of:
An Integrated Revenue Management
System

Issued on: November 18th, 2015

ICB No: RAMP/5
Purchaser: National Agency for Fiscal Administration
Country: Romania
 Table of Contents

PART 1 – Bidding Procedures................................................................................................1

Section I. Instructions to Bidders (ITB).................................................................................................2
Section II. Bid Data Sheet (BDS).........................................................................................................43
Section III. Sample Bidding Forms..................................................................................................61
Section IV. Eligible Countries for the Provision of Goods, Works, and Services in Bank-Financed
Procurement........................................................................................................................................191
PART 2 – Purchaser’s Requirements................................................................................193
Section V. Requirements of the Information System..........................................................................195
PART 3 – Conditions of Contract and Contract Forms..................................................577
Section VI. General Conditions of Contract......................................................................................579
Section VII. Special Conditions of Contract (SCC)...........................................................................649
Section VIII. Sample Contractual Forms...........................................................................................662
PART I. BIDDING PROCEDURES 1

PART 1 – BIDDING
PROCEDURES
2 Section I. Instructions to Bidders

SECTION I. INSTRUCTIONS TO BIDDERS (ITB)

Table of Clauses
A. General................................................................................................................................4
1. Scope of Bid and Bidding Process..............................................................................4
2. Source of Funds..........................................................................................................4
3. Fraud and Corruption......................................................................................................4
4. Eligible Bidders..........................................................................................................7
5. Eligible Goods and Services.......................................................................................8
6. Qualifications of the Bidder........................................................................................9
7. Cost of Bidding.........................................................................................................12
8. Site Visit....................................................................................................................12
B. The Bidding Documents..................................................................................................12
9. Content of Bidding Documents................................................................................12
10. Clarification of Bidding Documents and Pre-bid Meeting.......................................13
11. Amendment of Bidding Documents.........................................................................14
C. Language of Bids..............................................................................................................14
12. Language of Bids......................................................................................................14
D. Preparation of First Stage Technical-Only Bids...........................................................15
13. Documents Comprising First Stage Technical-Only Bid.........................................15
14. Documents Establishing the Conformity of the Information System to the
Bidding Documents..................................................................................................17
15. First Stage Technical-Only Bid Submission Form...................................................18
16. Format and Signing of First Stage Bid.....................................................................18
E. Submission of First Stage Technical-Only Bids............................................................19
17. Sealing and Marking of First Stage Technical-Only Bid..........................................19
18. Deadline for Submission of First Stage Technical-Only Bids..................................20
F. Opening and Evaluation of First Stage Technical-Only Bids......................................20
19. Opening of First Stage Technical-Only Bids by Purchaser......................................20
20. Preliminary Examination of First Stage Technical-Only Bids.................................20
21. Technical Evaluation of First Stage Technical-Only Bids.......................................20
22. Detailed Evaluation of Bidder’s Qualification.........................................................21
23. Clarification of First Stage Technical-Only Bids and Review of Bidders’
Proposed Deviations and Alternative Solutions.......................................................22
G. Invitation to Second Stage Combined Technical and Financial Bids.........................24
24. Invitation to Submit Second Stage Combined Technical and Financial Bids..........24
H. Preparation of Combined Technical and FinancialBids..............................................25
25. Documents Comprising the Combined Technical and Financial Bid.......................25
Section I. Instructions to Bidders 3

26. Bid Prices..................................................................................................................27

27. Bid Currencies..........................................................................................................29
28. Documents Establishing the Conformity of the Information System to the
Bidding Documents..................................................................................................29
29. Securing the Bid........................................................................................................30
30. Period of Validity of Bids.........................................................................................32
31. Format and Signing of Combined Technical and Financial Bid...............................32
I. Submission of Combined Technical and Financial Bids................................................33
32. Sealing and Marking of Bids....................................................................................33
33. Deadline for Submission of Bids..............................................................................34
34. Late Bids...................................................................................................................34
35. Withdrawal, Substitution, and Modification of Bids................................................34
J. Combined Technical and Financial Bid Opening and Evaluation...............................35
36. Opening of Combined Technical and Financial Bids by Purchaser.........................35
37. Clarification of Bids..................................................................................................36
38. Preliminary Examination of Bids..............................................................................36
39. Conversion to Single Currency.................................................................................37
40. Evaluation and Comparison of Bids.........................................................................37
41. Domestic Preference.................................................................................................39
42. Contacting the Purchaser..........................................................................................39
K. Post-qualification and Award of Contract....................................................................40
43. Post-qualification......................................................................................................40
44. Award Criteria..........................................................................................................40
45. Purchaser’s Right to Accept Any Bid and to Reject Any or All Bids......................40
46. Notification of Award...............................................................................................41
47. Signing of Contract...................................................................................................41
48. Performance Security................................................................................................41
49. Adjudicator...............................................................................................................42
4 Section I. Instructions to Bidders

Instructions to Bidders

A. GENERAL
1. Scope of Bid 1.1 The Purchaser named in the Bid Data Sheet (BDS), or its
and Bidding duly authorized Purchasing Agent if so specified in the BDS
Process (interchangeably referred to as “the Purchaser” in these
Bidding Documents), invites bids for the supply and
installation of the Information System, as briefly described in
the BDS and specified in greater detail in these Bidding
Documents.
1.2 The title and identification number of the Invitation for Bids
(IFB) and resulting Contract(s) are provided in the BDS.
1.3 Throughout the Bidding Documents, the term "in writing"
means communicated in written form (e.g. by mail, e-mail,
fax, telex) with proof of receipt, and the term "days" means
calendar days unless a different meaning is evident from the
context.
1.4 Unlessspecified in the BDS, alternative procedures forming
part or all of what is commonly known as “e-Tendering” are
not available.
2. Source of 2.1 The Borrower named in the BDS has applied for or received a
Funds loan or credit (as identified in the BDS, and called a “loan” in
these Bidding Documents) from the International Bank for
Reconstruction and Development or the International
Development Association (called “the Bank” in these Bidding
Documents) equivalent to the amount indicated in the BDS
toward the cost of the Project specified in the BDS. The
Borrower intends to apply a portion of the proceeds of this
loan to eligible payments under the Contract for which these
Bidding Documents are issued.
2.2 Payment by the Bank will be made only at the request of the
Borrower, or the Borrower’s executing agency, and upon
approval by the Bank in accordance with the terms and
conditions of the Loan Agreement, and will be subject in all
respects to the terms and conditions of that agreement. The
Loan Agreement prohibits a withdrawal from the loan account
for the purpose of any payment to persons or entities, or for
any import of goods, if such payment or import, to the
knowledge of the Bank, is prohibited by a decision of the
United Nations Security Council taken under Chapter VII of
the Charter of the United Nations. No party other than the
Borrower should derive any rights from the Loan Agreement
or have any claim to the loan proceeds.
3. Fraud and 3.1 It is the Bank’s policy to require that Borrowers (including
Section I. Instructions to Bidders 5

Corruption beneficiaries of Bank loans), as well as Bidders, Suppliers,

contractors and their agents (whether declared or not),
personnel, subcontractors, sub-consultants, service providers
and suppliers, under Bank-financed contracts, observe the
highest standard of ethics during the procurement and
execution of such contracts.1 In pursuance of this policy, the
Bank:
(a) defines, for the purposes of this provision, the terms set
forth below as follows:
(i) “corrupt practice” is the offering, giving, receiving
or soliciting, directly or indirectly, of anything of
value to influence improperly the actions of another
party2;
(ii) “fraudulent practice” is any act or omission,
including a misrepresentation, that knowingly or
recklessly misleads, or attempts to mislead, a party
to obtain a financial or other benefit or to avoid an
obligation3;
(iii) “collusive practice” is an arrangement between two
or more parties4 designed to achieve an improper
purpose, including to influence improperly the
actions of another party;
(iv) “coercive practice” is impairing or harming, or
threatening to impair or harm, directly or indirectly,
any party or the property of the party to influence

1
In this context, any action taken by a bidder, supplier, contractor, or any of its personnel, agents,
subcontractors, sub-consultants, service providers, suppliers and/or their employees to influence the
procurement process or contract execution for undue advantage is improper.
2
“Another party” refers to a public official acting in relation to the procurement process or contract
execution]. In this context, “public official” includes World Bank staff and employees of other
organizations taking or reviewing procurement decisions.
3
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement process
or contract execution; and the “act or omission” is intended to influence the procurement process or
contract execution.
4
“Parties” refers to participants in the procurement process (including public officials) attempting to
establish bid prices at artificial, non competitive levels.
6 Section I. Instructions to Bidders

improperly the actions of a party1;

(v) “obstructive practice "is
(aa) deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
investigators in order to materially impede a
Bank investigation into allegations of a
corrupt, fraudulent, coercive or collusive
practice; and/or threatening, harassing or
intimidating any party to prevent it from
disclosing its knowledge of matters relevant to
the investigation or from pursuing the
investigation, or
(bb) acts intended to materially impede the exercise
of the Bank’s inspection and audit rights
provided for under sub-clause 3.2 below.
(b) will reject a proposal for award if it determines that the
Bidder recommended for award has, directly or through
an agent, engaged in corrupt, fraudulent, collusive,
coercive or obstructive practices in competing for the
contract in question;
(c) will cancel the portion of the loan allocated to a contract
if it determines at any time that representatives of the
Borrower or of a beneficiary of the loan engaged in
corrupt, fraudulent, collusive, or coercive practices
during the procurement or the execution of that contract,
without the Borrower having taken timely and
appropriate action satisfactory to the Bank to address
such practices when they occur; and
(d) will sanction a firm or an individual, at any time, in
accordance with prevailing Bank’s sanctions
proceduresa, including by publicly declaring such firm or
individual ineligible, either indefinitely or for a stated
period of time: (i) to be awarded a Bank-financed
contract; and (ii) to be a nominated b sub-contractor,
1
“Party” refers to a participant in the procurement process or contract execution.
a a
A firm or an individual may be declared ineligible to be awarded a Bank-financed contract upon
completion of the Bank’s sanctions proceedings as per its sanctions procedures, including inter alia: (i)
temporary suspension in connection with an ongoing sanctions proceeding; (ii) cross-debarment as
agreed with other International Financial Institutions, including Multilateral Development Banks; and
(iii) the World Bank Group corporate administrative procurement sanctions procedures for fraud and
corruption.
b b
A nominated sub-contractor, consultant, manufacturer or supplier, or service provider (different names
are used depending on the particular bidding document) is one which either has been: (i) included by
the bidder in its pre-qualification application or bid because it brings specific and critical experience
and know-how that are accounted for in the evaluation of the bidder’s pre-qualification application or
Section I. Instructions to Bidders 7

consultant, manufacturer or supplier, or service provider

of an otherwise eligible firm being awarded a Bank-
financed contract.
3.2 In further pursuance of this policy, Bidders shall permit the
Bank to inspect any accounts and records and other documents
relating to the Bid submission and contract performance, and to
have them audited by auditors appointed by the Bank.
3.3 Furthermore, Bidders should be aware of the provision stated in
Clause 9.8 and Clause 6.2 in the General Conditions of
Contract.
4. Eligible 4.1 A Bidder, and all parties constituting the Bidder, may have the
Bidders nationality of any country, subject to the restrictions specified
in Section IV, Eligible Countries. A Bidder should be
deemed to have the nationality of a country if the Bidder is a
citizen or is constituted, incorporated, or registered and
operates in conformity with the provisions of the laws of that
country.
4.2 If a prequalification process has been undertaken for the
Contract(s) for which these Bidding Documents have been
issued, only those Bidders may participate that had been
prequalified and continue to meet the eligibility criteria of this
Clause. A prequalified Joint Venture may not change partners
or its structure when submitting a bid.
4.3 A firm may be excluded from bidding if:
(a) it was engaged by the Purchaser to provide consulting
services for the preparation of the design, specifications,
or other documents to be used for the procurement of the
Information System described in these Bidding
Documents; or
(b) it is a government-owned enterprise in the Borrower’s
country, unless it can establish that it (i) is legally and
financially autonomous and (ii) operates under
commercial law. No dependent agency of the Borrower
or Sub-Borrower should be permitted to bid.
4.4 A firm that has been sanctioned by the Bank in accordance
with the above ITB Clause 3.1 (d), or in accordance with the
Bank’s Guidelines on Preventing and Combating Fraud and
Corruption in Projects Financed by IBRD Loans and IDA
Credits and Grants, shall be ineligible to be awarded a
Bank-financed contract, or benefit from a Bank-financed
contract, financially or otherwise, during such period of
time as the Bank shall determine. The list of debarred firms
is available at the electronic address specified in the BDS
the bid; or (ii) appointed by the Borrower.
8 Section I. Instructions to Bidders

(http://www.worldbank.org/debarr).
4.5 A firm or individual is or will be disqualified from
participation in this bidding if, at any time from
advertisement of the bidding until and including contract
award, the firm or individual is under:
(a) a suspension by the Purchaser agreed by the Bank as a
result of execution of a Bid-Securing Declaration
pursuant to ITB Clause 29.6 in another Bank-financed
procurement, or under a suspension by the Purchaser for
other reasons that have been agreed by the Bank; or
(b) a declaration of ineligibility by the Bank in accordance
with ITB Clause 3.1 (d). The list of individuals and
firms debarred from participating in World Bank projects
is available at http://www.worldbank.org/debarr/, or
(c) a sanction imposed by the United Nations Security
Council, as mentioned in ITB Clause 2.2.
4.6 A firm or other entity that is ineligible according to any of the
above provisions of this Clause, may also not participate as a
Joint Venture partner, or as Subcontractor for or supplier of
goods, works or services. If a bid becomes materially
incomplete after removing ineligible entities, the bid may be
disqualified.
4.7 Bidders should provide such evidence of their continued
eligibility satisfactory to the Purchaser, as the Purchaser
should reasonably request.
5. Eligible Goods 5.1 For the purposes of these Bidding Documents, the Information
and Services System means all:
(a) the required information technologies, including all
information processing and communications-related
hardware, software, supplies, and consumable items that
the Supplier is required to design, supply and install
under the Contract, plus all associated documentation,
and all other materials and goods to be designed,
supplied, installed, integrated, and made operational
(collectively called “the Goods” in some clauses of the
ITB); and
(b) the related software development, transportation,
insurance, installation, customization, integration,
commissioning, training, technical support,
maintenance, repair, and other services necessary for
proper operation of the Information System to be
provided by the selected Bidder and as specified in the
Contract.
Section I. Instructions to Bidders 9

5.2 Funds from Bank loans are disbursed only for expenditures
for an Information System made up of goods and services
provided by nationals of, and produced in or supplied from,
eligible source countries as defined in BDS for ITB Clause
4.1. An Information System is deemed to be produced in a
certain country when, in the territory of that country,
through software development, manufacturing, or
substantial and major assembly or integration of
components, a commercially recognized product results that
is substantially different in basic characteristics or in
purpose or utility from its components.
5.3 For purposes of this clause, the nationality of the Bidder is
distinct from the country in which the Information System and
its goods components are produced or from which the related
services are supplied.
5.4 At the time of bidding, Bidders should document the origin of
the Goods and Services in the Price Schedules. At the time of
shipment, the Supplier should confirm theses by a certificate
of origin.
6. Qualifications 6.1 By submission of documentary evidence in its bid, the Bidder
of the Bidder must establish to the Purchaser’s satisfaction:
(a) that it has the financial, technical, and production
capability necessary to perform the Contract, meets the
qualification criteria specified in the BDS, and has a
successful performance history. If a prequalification
process has been undertaken for the Contract(s) for
which these Bidding Documents have been issued, the
Bidder should, as part of its bid, update any information
submitted with its application for prequalification;
Unless admittedand specified in the BDS, the
experience and/or resources of any Subcontractor will
NOT count towards establishing a Bidder’s
qualifications for Information System components.
Otherwise, only the Bidder’s qualifications (including
Joint Venture Partners) will be considered.
(b) that – unless otherwise specified in the BDS– forall
powered (active) hardware and/or software components
of the Information System which the Bidder does not
itself produce, the Bidder must be duly authorized by the
producer to supply those components in the Purchaser’s
country under the Contract(s) that may result from this
bidding. This must be documented by including
Manufacturer’s Authorizations in the bid (based on the
sample found in the Sample Bidding Forms in Section
III.)
10 Section I. Instructions to Bidders

(c) that – unless otherwise specified in the BDS – if a

Bidder proposes Subcontractors for design,
implementation, data conversion, training, warranty
repair, maintenance and/or technical support (or other
such key services)the Bidder must document that these
Subcontractors have agreed in writing to serve for the
Bidder under the Contract(s) that may result from this
bidding by including Subcontractor Agreement in the
bid (based on the sample found in the Sample Bidding
Forms in Section III.)
and
(d) that, in the case of a Bidder not doing business within
the Purchaser’s country, the Bidder is or will be (if
awarded the Contract) represented by an Agent in that
country who is equipped and able to carry out / manage
the Bidder’s maintenance, technical support, training,
and warranty repair obligations Technical Requirements
(including any response time, problem-resolution norms
or other aspects that may be specified in the Contract).
6.2 Bids submitted by a Joint Venture of two or more firms as
partners should also comply with the following requirements:
(a) the bid should be signed so as to be legally binding on
all partners;
(b) one of the partners should be nominated as being in
charge, and this nomination should be evidenced by
submitting a power of attorney signed by legally
authorized signatories of all the partners;
(c) the partner in charge should be authorized to incur
liabilities and receive instructions for and on behalf of
any and all partners of the Joint Venture, and the entire
execution of the Contract, including payment, should be
done exclusively with the partner in charge;
(d) the partner or combination of partners that is responsible
for a specific component of the Information System
must meet the relevant minimum qualification criteria
for that component;
(e) a firm may submit bids either as a single Bidder on its
own, or as partner in one, and only one, Joint Venture.
If, as a result of the bid opening pursuant to ITB Clause
19 and/or 36, this requirement is not met, all bids
involving the firm as a single Bidder or Joint Venture
partner will be disqualified;
(f) all partners of the Joint Venture should be liable jointly
Section I. Instructions to Bidders 11

and severally for the execution of the Contract in

accordance with the Contract terms, and a statement to
this effect should be included in the authorization
mentioned under ITB Clause 6.2 (b) above, in the bid as
well as in the Contract (in case of a successful bid).
6.3 If a Bidder intends to subcontract major items of supply or
services, it should include in the bid details of the name and
nationality of the proposed Subcontractor for each of those
items and should be responsible for ensuring that any
Subcontractor proposed complies with the requirements of ITB
Clause 4, and that any Goods or Services components of the
Information System to be provided by the Subcontractor
comply with the requirements of ITB Clause 5 and the related
evidence required by ITB Clause 13.1 (c) (iii) and/or 25.1 (e)
(iii) is submitted. Bidders are free to list more than one
Subcontractor against each item. Quoted rates and prices will
be deemed to apply, whichever Subcontractor is appointed,
and no adjustment of the rates or prices will be permitted. The
Purchaser reserves the right to delete any proposed
Subcontractor from the list. This should be done prior to
Contract signature, by deleting such unacceptable
Subcontractors from Appendix 3 to the Contract Agreement,
which should list the approved Subcontractors for each item
prior to Contract signature. Subsequent additions and
deletions from the list of approved Subcontractors should be
performed in accordance with GCC Clause 20 (as revised in
the SCC, if applicable) and Appendix 3 to the Contract
Agreement.
For the purposes of these Bidding Documents, a Subcontractor
is any vendor or service provider with whom the Bidder
contracts for the supply or execution of any part of the
Information System to be provided by the Bidder under the
Contract (such as the supply of major hardware, software, or
other components of the required Information Technologies
specified, or the performance of related Services, e.g., software
development, transportation, installation, customization,
integration, commissioning, training, technical support,
maintenance, repair, etc.).
6.4 A firm which is a Bidder, whether as a single Bidder or as a
partner in a Joint Venture, cannot be a Subcontractor in other
bids, except for the supply of commercially available hardware
or software by the firm, as well as purely incidental services
such as installation/configuration, routine training, and
ongoing maintenance/support.
However, if the BDS for ITB Clause 6.1 (a) allows the
qualification of Subcontractors nominated for certain
components to be taken into account in assessing the Bidder’s
12 Section I. Instructions to Bidders

overall qualifications, any Subcontractor so nominated by any

Bidder is automatically disqualified from being a Bidder itself
or a partner in a Joint Venture. The same will normally apply
to firms that have provided Subcontractor agreements for
certain services pursuant to ITB Clause 6.1 (c). Non-
compliance may result in the rejection of all bids in which the
affected firm participates as Bidder or as partner in a Joint
Venture. As long as in compliance with these provisions, or as
long as unaffected by them due to not participating as Bidder
or as partner in a Joint Venture, a firm may be proposed as a
Subcontractor in any number of bids.
7. Cost of 7.1 The Bidder should bear all costs associated with the
Bidding preparation and submission of its bid, and the Purchaser will in
no case be responsible or liable for those costs.
8. Site Visit 8.1 The Bidder may wish to visit and examine the site or sites of
the Information System and obtain for itself, at its own
responsibility and risk, all information that may be necessary
for preparing the bid and entering into the Contract. The costs
of visiting the site or sites should be at the Bidder’s own
expense.
8.2 The Purchaser will arrange for the Bidder and its personnel or
agents to gain access to the relevant site or sites, provided that
the Bidder gives the Purchaser adequate notice of a proposed
visit of at least fourteen (14) days. Alternatively, the
Purchaser may organize a site visit or visits concurrently with
the pre-bid meeting, as specified in the BDS for ITB Clause
10.2. Failure of a Bidder to make a site visit will not be a
cause for its disqualification.
8.3 No site visits should be arranged or scheduled after the
deadline for the submission of the Combined Technical and
Financial Bids and prior to the award of Contract.

B. THE BIDDING DOCUMENTS

9. Content of 9.1 The contents of the Bidding Documents are listed below and
Bidding should be read in conjunction with any addenda issued in
Documents accordance with ITB Clause 11:
PART 1: BIDDING PROCEDURES
Section I Instructions to Bidders (ITB)
Section II Bid Data Sheet (BDS)
Section III Sample Bidding Forms
Section IV Eligible Countries
PART 2: PURCHASER’S REQUIREMENTS
Section I. Instructions to Bidders 13

Section V Requirements of the Information System,

including:
 Technical Requirements
 Implementation Schedule
 System Inventory Tables
 Background and Informational
Materials
PART 3: CONDITIONS OF CONTRACT AND CONTRACT FORMS
Section VI General Conditions of Contract (GCC)
Section VII Special Conditions of Contract (SCC)
Section VIII Sample Contractual Forms
9.2 Bidders are expected to examine all instructions, forms, terms,
specifications, and other information in the Bidding Documents.
Failure to furnish all information required by the Bidding
Documents or to submit a bid not substantially responsive to the
Bidding Documents in every respect will be at the Bidder’s risk
and may result in the rejection of its bid.
9.3 The Invitation for Bids is not formally part of the Bidding
Documents and may be included for reference only. In case of
inconsistencies, the published Bidding Documents should
prevail.
10. Clarification of 10.1 A prospective Bidder requiring any clarification of the Bidding
Bidding Documents may notify the Purchaser in writing as specified in
Documents the BDS. Similarly, if a Bidder feels that any important
and Pre-bid provision in the documents will be unacceptable, such an issue
Meeting should be raised as soon as possible. The Purchaser will respond
in writing to any request for clarification or modification of the
Bidding Documents that it receives no later than twenty-one (21)
days prior to the deadline for submission of bids prescribed by
the Purchaser. Copies of the Purchaser’s response (including an
explanation of the query but not identifying its source) will be
sent to all prospective Bidders that received the Bidding
Documents from the Purchaser.
10.2 When indicated in the BDS, the Purchaser will organize a pre-
bid meeting at the time and place specified in the BDS, which
the Bidders are encouraged to attend. The purpose of the
meeting will be to clarify issues and answer questions on any
matter that may be raised at this stage, with particular attention
to issues related to the Technical Requirements. Bidders are
requested to submit any questions in writing to reach the
Purchaser not later than one week before the meeting. Questions
and answers will be transmitted in accordance with ITB
Clause 10.1. Minutes of the meeting, including the questions
raised and responses given, together with any responses prepared
14 Section I. Instructions to Bidders

after the meeting, will be transmitted without delay to all those

that received the Bidding Documents from the Purchaser. Any
modification to the Bidding Documents listed in ITB Clause 9.1,
which may become necessary as a result of the pre-bid meeting,
should be made by the Purchaser exclusively by issuing an
Addendum pursuant to ITB Clause 11 and not through the
minutes of the pre-bid meeting.
11. Amendment of 11.1 At any time prior to the deadline for submission of bids, the
Bidding Purchaser may, for any reason, whether at its own initiative or in
Documents response to a clarification requested by a prospective Bidder,
amend the Bidding Documents. Later amendments on the same
subject modify or replace earlier ones.
11.2 Amendments will be provided in the form of Addenda to the
Bidding Documents, which will be sent in writing to all
prospective Bidders that received the Bidding Documents from
the Purchaser. Addenda will be binding on Bidders. Bidders are
required to immediately acknowledge receipt of any such
Addenda. It will be assumed that the amendments contained in
such Addenda will have been taken into account by the Bidder in
its bid.
11.3 To afford prospective Bidders reasonable time in which to take
the amendment into account in preparing their bids, the
Purchaser may, at its discretion, extend the deadline for the
submission of bids, in which case, the Purchaser will notify all
Bidders in writing of the extended deadline.

C. LANGUAGE OF BIDS
12. Language of 12.1 Unless otherwise specified in the BDS, the bid prepared by the
Bids Bidder and all correspondence and documents related to the bid
exchanged by the Bidder and the Purchaser should be written in
the English Language, or, if the BDS so provides, in either one
of two languages specified there. Any printed literature
furnished by the Bidder as part of its bid may be in a language
not specified in the BDS, as long as such literature is
accompanied by a translation of its pertinent passages into the
language of the bid, in which case, for purposes of interpretation
of the bid, the translation should govern.
Section I. Instructions to Bidders 15

D. PREPARATION OF FIRST STAGE TECHNICAL-ONLY BIDS

13. Documents 13.1 The First Stage Technical-Only Bid submitted by the Bidder
Comprising should comprise:
First Stage (a) First Stage Technical-Only Bid Submission Form, duly
Technical- completed and signed by a person or persons duly
Only Bid authorized to bind the Bidder to the bid;

(b) written confirmation authorizing the signatory of the bid to

commit the Bidder, in accordance with ITB Clause 16.2;
(c) Attachments:
(i) Attachment 1: Bidder’s Eligibility
In the absence of prequalification, documents
establishing to the Purchaser’s satisfaction the
Bidder’s eligibility to bid, including but not limited
to documentary evidence that the Bidder is legally
incorporated in a territory of an eligible source
country as defined under ITB Clause 4;
(ii) Attachment 2: Bidder’s Qualifications
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 6, that the Bidder is qualified to perform the
Contract if its bid is accepted. In the case where
prequalification of Bidders has been undertaken, and
pursuant to ITB Clause 6.1 (a), the Bidder must
provide evidence on any changes in the information
submitted as the basis for prequalification or, if there
has been no change at all in said information, a
statement to this effect;
Any Manufacturer’s Authorizations and Subcontractor
Agreements specified as required in the BDS for ITB
Clauses 6.1 (b) and 6.1 (c);
Documentary evidence regarding the Joint Venture
partnership (if any) in accordance with ITB Clause 6.2.
(iii) Attachment 3: Proposed Subcontractors
A list of all major items of Goods or Services that the
Bidder proposes to purchase or subcontract from
others, and the name and nationality of the proposed
Subcontractor, including vendors, for each of those
items;
(iv) Attachment 4: Intellectual Property
A list of:
16 Section I. Instructions to Bidders

(1) all Software included in the Bidder’s bid,

assigning each item to one of the software
categories defined in GCC Clause 1.1 (c):
(A) System, General Purpose, and Application
Software; and
(B) Standard and Custom Software.
(2) all Custom Materials, as defined in GCC Clause
1.1 (c), included in the Bidder’s bid.
All Materials not identified as Custom Materials
should be deemed Standard Materials, as defined in
GCC Clause 1.1 (c).
Re-assignments among the Software and Materials
categories, if necessary, will be made during the
implementation of the Contract according to GCC
Clause 39 (Changes to the Information System).
(v) Attachment 5: Conformity of the Information System
to the Bidding Documents
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 14, that the Goods and Services components
of the Information System to be supplied, installed,
and/or performed by the Bidder conform to the
Bidding Documents;
(vi) Attachment 6: Deviations
Bidders should give details of all deviations in their
First Stage Technical-Only Bid with respect to the
contractual terms and conditions contained in the
GCC and/or the SCC (including, but not restricted
to, Intellectual Property Rights, Software licenses,
liabilities, amount of performance security,
governing law, etc.) and/or to the required technical
features specified in the Technical Requirements,
that they would like the Purchaser to consider during
the evaluation of First Stage Technical-Only Bids
and any Clarification Meeting(s) with the Bidder,
pursuant to ITB Clauses 20 through 23. The
Purchaser will consider such proposed deviations,
pursuant to ITB Clause 21.1 (g);
Pursuant to ITB Clause 23.8, the bidder-specific
memorandum titled “Changes Required Pursuant to
First Stage Evaluation” should indicate the Bidder’s
deviations that are not acceptable to the Purchaser
and which the Bidder must withdraw in its Second
Stage Combined Technical and Financial Bid –
Section I. Instructions to Bidders 17

failure to do so would constitute grounds for the bid

to be rejected pursuant to ITB Clause 38.5;
Deviations that are acceptable to the Purchaser
should be incorporated into the Bidding Documents
in the form of an Addendum to be distributed,
together with the Invitation for Bids – Second Stage
Combined Technical and Financial Bids, to all
Bidders invited to submit a Second Stage Bid;

14. Documents 14.1 Pursuant to ITB Clause 13, the Bidder should furnish, as part of
Establishing its First Stage Technical-Only Bid documents establishing the
the Conformity conformity to the Bidding Documents of the Information
of the System that the Bidder proposes to design, supply and install
Information under the Contract.
System to the 14.2 The documentary evidence of conformity of the Information
Bidding System to the Bidding Documents including:
Documents
(a) a Preliminary Project Plan describing, among other things,
the methods by which the Bidder will carry out its overall
management and coordination responsibilities if awarded
the Contract, and the human and other resources the Bidder
proposes to use. The Preliminary Project Plan must also
address any other topics specified in the BDS. In addition,
the Preliminary Project Plan should state the Bidder’s
assessment of what it expects the Purchaser and any other
party involved in the implementation of the Information
System to provide during implementation and how the
Bidder proposes to coordinate the activities of all involved
parties;
(b) written confirmation that the Bidder accepts responsibility
for the successful integration and inter-operability of all
components of the Information System as required by the
Bidding Documents;
(c) an item-by-item commentary on the Purchaser’s Technical
Requirements, demonstrating the substantial
responsiveness of the Information System offered to those
requirements. In demonstrating responsiveness, the Bidder
is encouraged to use the Technical Responsiveness
Checklist(or Checklist Format) in the Sample Bidding
Forms (Section III). The commentary should include
explicit cross-references to the relevant pages in the
supporting materials included in the bid. Whenever a
discrepancy arises between the item-by-item commentary
and any catalogs, technical specifications, or other
preprinted materials submitted with the bid, the item-by-
item commentary should prevail;
18 Section I. Instructions to Bidders

(d) Support material (e.g., product literature, white papers,

narrative descriptions of technologies and/or technical
approaches), as required and appropriate.
(e) Any separate and enforceable contract(s) for Recurrent
Cost items which the BDS for ITB Clause 26.2 required
Bidders to bid.
14.3 References to brand names or model numbers or national or
proprietary standards designated by the Purchaser in the Bidding
Documents are intended to be descriptive and not restrictive.
Except where explicitly prohibited in the BDS for specific
items or standards, the Bidder may substitute alternative
brand/model names or standards in its bid, provided that it
demonstrates to the Purchaser’s satisfaction that the use of the
substitute(s) will result in the Information System being able to
perform substantially equivalent to or better than that specified
in the Technical Requirements.
14.4 For their Second Stage Combined Technical and Financial Bids,
the invited Bidders are expected to offer the same brands,
models, Subcontractors and other material provisions as
proposed in the First Stage Technical-Only Bid, unless changes
are explicitly permitted or required in the bidder-specific
memorandum entitled “Changes Required Pursuant to First
Stage Evaluation” pursuant to ITB Clause 23.8, or are implied or
triggered by Addenda to the Bidding Documents issued in the
second stage of bidding. Bidders that deviate from their First
Stage Technical-Only Bids without specific endorsement by
their memorandum or without a reason clearly established by
Addenda issued in the second bidding-stage, place their bid at
risk of being rejected.
15. First Stage 15.1 The Bidder should complete the First Stage Technical-Only Bid
Technical- Submission Form furnished in the Sample Bidding Forms
Only Bid (Section III) in the manner and detail indicated in this section
Submission and submit this form with the bid.
Form
16. Format and 16.1 The Bidder should prepare an original and the number of
Signing of copies/sets of the bid specified in the BDS, clearly marking
First Stage Bid each one as: “FIRST STAGE TECHNICAL-ONLY BID –
ORIGINAL,” “FIRST STAGE TECHNICAL-ONLY BID – COPY
NO. 1,” “FIRST STAGE TECHNICAL-ONLY BID -- COPY NO. 2,”
etc., as appropriate. In the event of any discrepancy between
the original and any copy, the original should govern.
16.2 The original and all copies of the bid should be typed or written
in indelible ink and should be signed by a person or persons
duly authorized to sign on behalf of the Bidder. The
authorization must be in writing and included in the bid
pursuant to ITB Clause 13.1 (b). The name and position held
Section I. Instructions to Bidders 19

by each person signing the authorization must be typed or

printed below the signature. All pages of the bid, except for
unamended printed literature, should be initialed by the person
or persons signing the bid.
16.3 The bid should contain no interlineations, erasures, or
overwriting, except to correct errors made by the Bidder, in
which case such corrections should be initialed by the person or
persons signing the bid.
16.4 Signing and submission of a First Stage Technical-Only Bid
should not bind or obligate the Bidder to submit a Second Stage
Combined Technical and Financial Bid.

E. SUBMISSION OF FIRST STAGE TECHNICAL-ONLY BIDS

17. Sealing and 17.1 The Bidder should seal the original First Stage Bid and each
Marking of copy of the bid in separate envelopes, each containing the
First Stage documents specified in ITB Clause 13, and should mark the
Technical- envelopes as “FIRST STAGE TECHNICAL-ONLY BID –
Only Bid ORIGINAL,” and “FIRST STAGE TECHNICAL-ONLY BID – COPY
NO.  [number],” all duly marked as required in ITB
Clause 16.1. The envelopes should be sealed in an outer
envelope.
17.2 The inner and outer envelopes should
(a) be addressed to the Purchaser, at the address given in the
BDS for ITB Clause 18.1 and
(b) bear the Contract(s) name, the Invitation for Bids (IFB)
title and number, as specified in the BDS for ITB
Clause 1.2 , and the statement “FIRST STAGE TECHNICAL-
ONLY BID – DO NOT OPEN BEFORE [time and date],” to be
completed with the time and date specified in the BDS for
ITB Clause 19.1.
17.3 The inner envelopes should each indicate the name and address
of the Bidder to enable the bid to be returned unopened in case
it is declared “late.”
17.4 If the outer envelope is not sealed and marked as required by
ITB Clauses 17.2 and 17.3, the Purchaser will assume no
responsibility for the bid’s misplacement or premature opening.
If the outer envelope discloses the Bidder’s identity, the
Purchaser will not guarantee the anonymity of the bid
submission, but this disclosure will not constitute grounds for
bid rejection.
20 Section I. Instructions to Bidders

18. Deadline for 18.1 First Stage Technical-Only Bids must be received by the
Submission of Purchaser at the address specified, and no later than the time
First Stage and date specified, in the BDS. Late bids will be rejected and
Technical- returned unopened to the Bidder.
Only Bids
18.2 The Purchaser may, at its discretion, extend the deadline for
submission of bids by amending the Bidding Documents in
accordance with ITB Clause 11.3, in which case all rights and
obligations of the Purchaser and Bidders will thereafter be
subject to the deadline as extended.

F. OPENING AND EVALUATION OF FIRST STAGE TECHNICAL-

ONLY BIDS
19. Opening of 19.1 The Purchaser will open the First Stage Technical-Only Bids at
First Stage the date, time and place indicated in the BDS. Bidders’
Technical- representatives may attend the opening and should sign a
Only Bids by register as proof of their attendance. The names of all Bidders
Purchaser who submitted bids, and other such details as the Purchaser, at
its discretion, may consider appropriate will be announced at
the opening and recorded in minutes of the First Stage
Technical-Only Bid opening. The Purchaser will promptly
convey these minutes in writing to all Bidders that met the
deadline for submitting bids.
20. Preliminary 20.1 The Purchaser will examine the First Stage Technical-Only
Examination of Bids, to determine whether they have been properly signed and
First Stage are substantially complete (e.g., not missing key parts of the bid
Technical- or silent on excessively large portions of the Technical
Only Bids Requirements). In the case where a pre-qualification process
was undertaken for the Contract(s) for which these Bidding
Documents have been issued, the Purchaser will ensure that
each bid is from a pre-qualified bidder and, in the case of a Joint
Venture, that partners and structure of the Joint Venture are
unchanged from those in the pre-qualification.
21. Technical 21.1 The Purchaser will carry out a detailed technical evaluation of
Evaluation of each First Stage Technical-Only Bid that was not rejected during
First Stage preliminary examination pursuant to ITB Clause 20, to
Technical- determine whether the technical aspects of the bid are responsive
Only Bids to the requirements set forth in the Bidding Documents. To
reach such a determination, the Purchaser will examine the
information supplied by the Bidders, pursuant to ITB Clauses 13
and 14, and in response to other requirements in the Bidding
Documents, taking into account the following factors:
(a) overall completeness and compliance with the Technical
Requirements; and deviations from the Technical
Section I. Instructions to Bidders 21

Requirements;
(b) suitability of the Information System offered in relation to
the conditions prevailing at the site; and the suitability of
the implementation and other services proposed, as
described in the Preliminary Project Plan included in the
bid;
(c) achievement of specified performance criteria by the
Information System;
(d) compliance with the time schedule called for by the
Implementation Schedule and any alternative time
schedules offered by Bidders, as evidenced by a milestone
schedule provided in the Preliminary Project Plan
included in the bid;
(e) type, quantity, quality, and long-term availability of
maintenance services and of any critical consumable items
necessary for the operation of the Information System;
(f) any other relevant technical factors that the Purchaser
deems necessary or prudent to take into consideration;
(g) any proposed deviations in the bid to the contractual and
technical provisions stipulated in the Bidding Documents.
22. Detailed 22.1 In the absence of a pre-qualification process, the Purchaser will
Evaluation of ascertain to its satisfaction whether a Bidder having submitted a
Bidder’s First Stage Technical-Only Bid is qualified to satisfactorily
Qualification perform the Contract. Conversely, if a pre-qualification process
had been carried out for the Contract(s) for which these Bidding
Documents have been issued, the Purchaser should ascertain to
its satisfaction that, on the basis of updated documentary
evidence submitted in accordance with ITB Clause 13.1 (c) (ii),
the Bidder remains qualified to satisfactorily perform the
Contract.
22.2 This determination will take into account the Bidder’s financial,
technical, and production capabilities, and past performance. It
will be based upon an examination of the documentary evidence
of the Bidder’s qualifications submitted by the Bidder, pursuant
to ITB Clauses 6.1 and 13.1 (c) (ii), as well as such other
information as the Purchaser deems necessary and appropriate.
22.3 The Purchaser will identify any divergences from the
qualification requirements as stated in the Bidding Documents,
which - during the possible Clarification Meeting(s) pursuant to
ITB Clause 23 - the Purchaser may explore with the Bidder as
to whether and how the divergences could be overcome.
22 Section I. Instructions to Bidders

23. Clarification of 23.1 The Purchaser may conduct a bidder-specific Clarification

First Stage Meeting/Meetings with the Bidder to clarify aspects of the
Technical- Bidder’s First Stage Technical-Only Bid that require
Only Bids and explanation or are not considered fully responsive by the
Review of Purchaser. During these meetings, the Purchaser should bring
Bidders’ to the attention of the Bidder any matters, technical or
Proposed otherwise, where for whatever reason, the Purchaser requires
Deviations and changes to be made to the Bidder’s First Stage Technical-Only
Alternative Bid to make that bid conform to the requirements of the
Solutions Bidding Documents. Conversely, in these meeting(s), the
Bidder should bring to the Purchaser’s attention any changes it
would like to make in the Second Stage Combined Technical
and Financial Bid, such as replacement of certain brands or
models, Subcontractors, Services and others.
23.2 There is no obligation upon the Bidder to attend a Clarification
Meeting. If the Bidder is unable, or declines, to attend a
Clarification Meeting, the Purchaser will undertake a reasonable
effort to achieve the required clarification by correspondence
with the Bidder or by other means such as telephone or
videoconference as may be available. Any reduction in the
scope for obtaining complete clarification of a First Stage
Technical-Only Bid due to having to use these alternative
methods is at the Bidder’s risk of its bid being rejected.
23.3 Unless specified in the BDS, the First Stage Technical-Only
Bid clarification stage will NOT include live demonstrations
and/or tests of the Bidder’s proposed solution and products.
However, if the BDS specifies such demonstrations and/or test
they will be as described in the BDS, including whether they are
mandatory - at the risk of otherwise having the bid rejected - for
Bidders invited to stage them, and the place for them. If the
BDS permits Bidders to stage the tests and demonstrations
away from the Purchaser’s location, including outside the
Purchaser’s country, the Purchaser will bear all staff, travel and
subsistence costs of its own team of attendees. However, the
Purchaser will not be responsible for any and all costs of the
Bidder in preparing, conducting and dismantling the tests and
demonstrations.
23.4 The Purchaser will advise the Bidder, pursuant to ITB
Clause 13.1 (c) (vii), of any deviations the Bidder made or
proposed in the First Stage Technical-Only Bid that the
Purchaser finds
(a) unacceptable and that must be withdrawn in the Second
Stage Combined Technical and Financial Bid;
(b) acceptable and that will be incorporated into the Bidding
Documents by way of an Addendum that should be sent to
all Bidders invited to submit a Second Stage Bid.
Section I. Instructions to Bidders 23

No deviation can be waived for just one or for certain bidders

invited for the second bidding-stage.
23.5 Each Clarification Meeting must be attended by a person or
persons that, through a written power of attorney, is/are duly
authorized to represent Bidder in the discussions and to reach
formal agreement with the Purchaser on the specific changes in
the Bidder’s First Stage Technical-Only Bid that are required if
the Bidder is to submit a Second Stage Combined Technical and
Financial Bid. The Purchaser will not be responsible for any
costs incurred by the Bidder’s party for and in attending the
Clarification Meeting(s). An invitation for, and attendance at,
Clarification Meetings does not necessarily imply that the
Bidder will be invited for the second bidding-stage. However,
if Clarification Meetings are held, all Bidders receiving an
invitation for the second bidding-stage will be offered the
opportunity of such a meeting, even if their bids, in the
Purchaser’s opinion, do not require face to face clarification.
23.6 Neither the bidder-specific memorandum pursuant to ITB
Clause 23.7, nor any minutes written of the Clarification
Meeting(s) or any correspondence exchanged between a specific
Bidder and the Purchaser, will be shared with other Bidders.
Except for the memorandum, no requirements upon the Bidder’s
Second Stage Combined Technical and Financial Bid will be
implied from any additional bidder-specific minutes of meetings
or correspondence. However, Purchaser and Bidder might use
these documents, as appropriate, as clarification information in
the second stage of bid preparation or evaluation, respectively.
23.7 For each Bidder not rejected during Preliminary Evaluation in
accordance with ITB 20 the Purchaser will prepare a bidder-
specific memorandum entitled “Changes Required Pursuant to
First Stage Evaluation” and conveyed this to the relevant Bidder
as part of the Invitation for Bids – Second Stage Combined
Technical and Financial Bid.
The Purchaser will record in each bidder-specific memorandum:
(a) all changes to the First Stage Technical-Only Bid and
further elaborations required in the Second Stage
Combined Technical and Financial Bid ;
(b) list any deviations pursuant to ITB Clauses 13.1 (c) (vii)
and 23.4 which are unacceptable to the Purchaser and
which the Bidder must withdraw in the Second Stage
Combined Technical and Financial Bid;
(c) any Subcontractors which the Bidder must delete or
replace, including justification for the
deletion/replacement pursuant to ITB Clause 6.3,
(d) the agreement between Purchaser and Bidder on the name
of the Adjudicator; or the Purchaser’s proposal for
24 Section I. Instructions to Bidders

replacing the previously nominated Adjudicator; or

indicate no Adjudicator will be nominated, pursuant to
ITB Clause 50.
If there is no requirement for any bidder-specific changes for a
Bidder, the Invitation for Bids -- Second Stage will state so.

G. INVITATION TO SECOND STAGE COMBINED TECHNICAL AND

FINANCIAL BIDS
24. Invitation to 24.1 Having concluded the First Stage Technical-Only evaluation
Submit Second (including any Clarification Meetings), the Purchaser:
Stage (a) may issue an Addendum to the Bidding Documents
Combined amending, inter alia, BDS, the SCC, and the Technical
Technical and Requirements with the objective of improving competition
Financial Bids without compromising essential project objectives (e.g.,
acceptable deviations brought to the Purchaser’s attention
by one or more Bidders; sharpened formulation of certain
Technical Requirements; adjustments to the
Implementation Schedule; etc.)
(b) will either
(i) invite the Bidder to submit Second Stage Combined
Technical and Financial Bid, with an updated
technical bid (reflecting the bidder-specific
memorandum entitled “Changes Required Pursuant
to First Stage Technical-Only Evaluation” and/or in
Addenda to the Bidding Documents) and a
corresponding financial bid, or
(ii) notify the Bidder that its bid has been rejected for
having failed the Preliminary Examination pursuant
to ITB Clause 20 (i.e., on the grounds of being
improperly signed, or missing significant parts of the
bid materials or silent on excessively large portions
of the Technical Requirements), or that the Bidder
does not meet the minimum qualification
requirements set forth in the Bidding Documents (or
in the Prequalification Documents, if a
prequalification process was used).
24.2 Bidders invited to submit Second Stage Combined Technical
and Financial Bids are required to promptly acknowledge to the
Purchaser the receipt of the Invitation for Bids -- Second Stage
Combined Technical and Financial Bid and the attachments, if
any, listed in it.
24.3 The deadline and address for the submission of Second Stage
Combined Technical and Financial Bids will be specified in the
Invitation for Bids – Second Stage Combined Technical and
Section I. Instructions to Bidders 25

Financial Bid, which the Purchaser will communicate to firms it

has selected to participate in the Second Stage Combined
Technical and Financial Bid process. Similarly, required Bid-
securing Declaration or the amount of the required Bid Security
will also be communicated in the same Invitation.
24.4 Bidders are not allowed to form a Joint Venture or consortium
with other Bidders, nor change the partner(s) or structure of the
Joint Venture or consortium if the Bidder in the First Stage was
a Joint Venture or consortium.

H. PREPARATION OF COMBINED TECHNICAL AND FINANCIAL

BIDS
25. Documents 25.1 The Combined Technical and Financial Bid submitted by the
Comprising Bidder should comprise:
the Combined
Technical and (a) A Combined Technical and Financial Bid Submission
Financial Bid Form completed and signed by a person or persons duly
authorized to bind the Bidder to the Contract;
(b) written confirmation authorizing the signatory of the bid to
commit the Bidder, in accordance with ITB Clause 21.2;
(c) if required, Bid-securing Declaration or Bid Security
furnished in accordance with ITB Clause 29;
(d) all Price Schedules duly completed in accordance with ITB
Clauses 26 and 27, and signed by a person or persons duly
authorized to bind the Bidder to the Contract;
(e) Attachments (or updates thereto):
(i) Attachment 1: Bidder’s Eligibility
In the absence of prequalification, documents
establishing to the Purchaser’s satisfaction the
Bidder’s eligibility to bid, including but not limited
to documentary evidence that the Bidder is legally
incorporated in a territory of an eligible source
country as defined under ITB Clause 4;
(ii) Attachment 2: Bidder’s Qualifications
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 6, that the Bidder is qualified to perform the
Contract if its bid is accepted. In the case where
prequalification of Bidders has been undertaken, and
pursuant to ITB Clause 6.1 (a), the Bidder must
provide evidence on any changes in the information
submitted as the basis for prequalification or, if there
26 Section I. Instructions to Bidders

has been no change at all in said information, a

statement to this effect;
Any Manufacturer’s Authorizations and Subcontractor
Agreements specified as required in the BDS for ITB
Clauses 6.1 (b) and 6.1 (c);
Documentary evidence regarding the Joint Venture
partnership (if any) in accordance with ITB Clause 6.2
(iii) Attachment 3: Proposed Subcontractors
A list of all major items of Goods or Services that the
Bidder proposes to purchase or subcontract from
others, and the name and nationality of the proposed
Subcontractor, including vendors, for each of those
items;
(iv) Attachment 4: Intellectual Property
A list of:
(1) all Software included in the Bidder’s bid,
assigning each item to one of the software
categories defined in GCC Clause 1.1 (c):
(A) System, General Purpose, and Application
Software; and
(B) Standard and Custom Software.
(2) all Custom Materials, as defined in GCC Clause
1.1 (c), included in the Bidder’s bid.
All Materials not identified as Custom Materials
should be deemed Standard Materials, as defined in
GCC Clause 1.1 (c).
Re-assignments among the Software and Materials
categories, if necessary, will be made during the
implementation of the Contract according to GCC
Clause 39 (Changes to the Information System).
(v) Attachment 5: Conformity of the Information System
to the Bidding Documents
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 28, that the Goods and Services components
of the Information System to be designed, supplied,
installed, and/or performed by the Bidder conform to
the Bidding Documents (and any Addendum and
bidder-specific memorandum “Changes Required
Pursuant to First Stage Technical-Only Evaluation”.
Section I. Instructions to Bidders 27

26. Bid Prices 26.1 All Goods and Services identified in the Supply and Installation
Cost Sub-Tables in System Inventory Tables in Section V, and
all other Goods and Services proposed by the Bidder to fulfill
the requirements of the Information System, must be priced
separately and summarized in the corresponding cost tables in
the Sample Bidding Forms (Section III), in accordance with the
instructions provided in the tables and in the manner specified
below.
26.2 Unless otherwise specified in the BDS, the Bidder must also
bid Recurrent Cost Items specified in the Technical
Requirements, Recurrent Cost Sub-Table of the System
Inventory Tables in Section V (if any). These must be priced
separately and summarized in the corresponding cost tables in
the Sample Bidding Forms (Section III), in accordance with the
instructions provided in the tables and in the manner specified
below.
If specified in the BDS, the Bidder must also bid separate
enforceable contracts for the Recurrent Cost Items not included
in the main Contract.
Prices for Recurrent Costs are all-inclusive of the costs of
necessary Goods such as spare parts, software license renewals,
labor, etc., needed for the continued and proper operation of the
Information System and, if appropriate, of the Bidder’s own
allowance for price increases.
26.3 Unit prices must be quoted at a level of detail appropriate for
calculation of any partial deliveries or partial payments under
the contract, in accordance with the Implementation Schedule in
Section V), and with GCC and SCC Clause 12 – Terms of
Payment. Bidders may be required to provide a breakdown of
any composite or lump-sum items included in the Cost Tables.
26.4 The price of items that the Bidder has left blank in the cost
tables provided in the Sample Bid Forms (Section III) should be
assumed to be included in the price of other items. Items
omitted altogether from the cost tables should be assumed to be
omitted from the bid and, provided that the bid is substantially
responsive, an adjustment to the bid price will be made during
bid evaluation in accordance with ITB Clause 30.6 (c) (iii).
26.5 The prices for Goods components of the Information System are
to be expressed and should be defined and governed in
accordance with the rules prescribed in the edition of Incoterms
specified in the BDS, as follows:
(a) Goods supplied from outside the Purchaser’s country:
Unless otherwise specified in the BDS, the prices should
be quoted on a CIP (named place of destination) basis,
exclusive of all taxes, stamps, duties, levies, and fees
28 Section I. Instructions to Bidders

imposed in the Purchaser’s country. The named place of

destination and special instructions for the contract of
carriage are as specified in the SCC for GCC 1.1 (e) (iii).
In quoting the price, the Bidder should be free to use
transportation through carriers registered in any eligible
countries. Similarly, the Bidder may obtain insurance
services from any eligible source country.
(b) Locally supplied Goods:
Unit prices of Goods offered from within the Purchaser’s
Country, should be quoted on an EXW (ex factory, ex
works, ex warehouse or off-the-shelf, as applicable) basis,
including all customs duties, levies, fees, sales and other
taxes incurred until delivery of the Goods, but excluding
all VAT or sales and other taxes and duties/fees incurred
for the Goods at the time of invoicing or sales transaction,
if the Contract is awarded.
(c) Inland transportation:
Unless otherwise stated in the BDS, inland
transportation, insurance and related local costs incidental
to the delivery of the Goods to the designated Project Sites
must be quoted separately as a Service item in accordance
with ITB Clause 14.5, whether the Goods are to be
supplied locally or from outside the Purchaser’s country,
except when these costs are already included in the price of
the Goods, as is, e.g., the case, when ITB Clause 14.4 (a)
specifies CIP, and the named places of destination are the
Project Sites.
26.6 The price of Services should be separated into their local and
foreign currency components and where appropriate, broken
down into unit prices. Prices must include all taxes, duties,
levies and fees whatsoever, except only VAT or other indirect
taxes, or stamp duties, that may be assessed and/or apply in the
Purchaser’s country on/to the price of the Services invoiced to
the Purchaser, if the Contract is awarded.
Unless otherwise specified in the BDS, the prices must include
all costs incidental to the performance of the Services, as
incurred by the Supplier, such as travel, subsistence, office
support, communications, translation, printing of materials, etc.
Costs incidental to the delivery of the Services but incurred by
the Purchaser or its staff, or by third parties, must be included in
the price only to the extent such obligations are made explicit in
these Bidding Documents (as, e.g., a requirement for the Bidder
to include the travel and subsistence costs of trainees).
26.7 Unless otherwise specified in the BDS, prices quoted by the
Bidder should be fixed during the Bidder’s performance of the
Section I. Instructions to Bidders 29

Contract and not subject to increases on any account. Bids

submitted that are subject to price adjustment will be rejected.
27. Bid Currencies 27.1 Prices should be quoted in the following currencies:
(a) The Bidder may quote its prices for all Information
Technologies, associated Goods, and Services to be
supplied from outside the Purchaser’s Country in the
currencies of countries eligible according to the BDS for
ITB Clause 4.1. If the Bidder wishes to be paid in a
combination of different currencies, it must quote unit
prices accordingly, but no more than three foreign
currencies may be used.
(b) The Bidder should express its prices for such Information
Technologies, associated Goods, and Services to be
supplied locally (i.e., from within the Purchaser’s Country)
in the currency of the Purchaser’s Country OR in any other
currency of the bid unless otherwise specified in the
BDS.
28. Documents 28.1 Pursuant to ITB Clause 25.1 (e) (vi), the Bidder should furnish,
Establishing as part of its bid, documents establishing the conformity to the
the Conformity Bidding Documents of the Information System that the Bidder
of the proposes to supply and install under the Contract.
Information
System to the 28.2 The documentary evidence of conformity of the Information
Bidding System to the Bidding Documents including:
Documents
(or updates thereto)
(a) a Preliminary Project Plan describing, among other things,
the methods by which the Bidder will carry out its overall
management and coordination responsibilities if awarded
the Contract, and the human and other resources the Bidder
proposes to use. The Preliminary Project Plan must also
address any other topics specified in the BDS. In addition,
the Preliminary Project Plan should state the Bidder’s
assessment of what it expects the Purchaser and any other
party involved in the implementation of the Information
System to provide during implementation and how the
Bidder proposes to coordinate the activities of all involved
parties;
(b) written confirmation that the Bidder accepts responsibility
for the successful integration and inter-operability of all
components of the Information System as required by the
Bidding Documents;
(c) an item-by-item commentary on the Purchaser’s Technical
Requirements, demonstrating the substantial
responsiveness of the Information System offered to those
30 Section I. Instructions to Bidders

requirements. In demonstrating responsiveness, the Bidder

is encouraged to use the Technical Responsiveness
Checklist (or Checklist Format) in the Sample Bidding
Forms (Section III). The commentary should include
explicit cross-references to the relevant pages in the
supporting materials included in the bid. Whenever a
discrepancy arises between the item-by-item commentary
and any catalogs, technical specifications, or other
preprinted materials submitted with the bid, the item-by-
item commentary should prevail;
(d) Support material (e.g., product literature, white papers,
narrative descriptions of technologies and/or technical
approaches), as required and appropriate.
(e) Any separate and enforceable contract(s) for Recurrent
Cost items which the BDS for ITB Clause 26.2 required
Bidders to bid.
28.3 References to brand names or model numbers or national or
proprietary standards designated by the Purchaser in these
Bidding Documents are intended to be descriptive and not
restrictive. Except where explicitly prohibited in the BDS for
ITB 14.3 and/or Addenda to the Bidding Documents, the Bidder
may substitute alternative brand/model names or standards in its
bid, provided that it demonstrates to the Purchaser’s satisfaction
that the use of the substitute(s) will result in the Information
System being able to perform substantially equivalent to or
better than that specified in the Technical Requirements.
29. Securing the 29.1 Unless otherwise specified in the BDS bids must be secured.
Bid As specified in the BDS, the Bidder must provide a Bid-
Securing Declaration or Bid Security in the amount is specified
in theBDS.
29.2 Securing the bids should be substantially in accordance with the
related sample forms included in the Sample Bidding Forms
(Section III) or other forms approved by the Purchaser prior to
bid submission. Bids must remain secured for a period of
twenty-eight (28) days beyond the validity period of the bids, as
extended, if applicable, in accordance with ITB Clause 30.2. In
case of a Bid Security, it should also:
(a) at the Bidder’s option, be in the form of either a certified
check, letter of credit, or a bank guarantee from a banking
institution, or a bond issued by a surety;
(b) be issued by a reputable institution selected by the Bidder
and located in any eligible country; if the institution
issuing the security is located outside the Purchaser’s
Country, it should have a correspondent financial
institution located in the Purchaser’s Country to make the
Section I. Instructions to Bidders 31

security enforceable;
(c) be payable promptly upon written demand by the
Purchaser in case any of the conditions listed in ITB
Clause 29.6 is/are invoked;
(d) be submitted in its original form; copies will not be
accepted.
29.3 The Bid-Securing Declaration or the Bid Security of a Joint
Venture should be issued in the name of the Joint Venture
submitting the bid provided the Joint Venture has legally been
constituted, or else it should be issued in the name of all partners
proposed for the Joint Venture in the bid. Sanctions due to a
breach of the terms of a Bid-Securing Declaration pursuant to
ITB Clause 29.6 will apply to all partners to the Joint Venture.
29.4 If a Bid-Securing Declaration or Bid Security is required in
accordance with ITB Clause 29.1, any bid not accompanied by a
substantially acceptable Bid-Securing Declaration or Bid
Security in accordance with ITB Clauses 29.2 and 29.3, should
be rejected by the Purchaser as non-responsive.
29.5 Unless executed or forfeited pursuant to ITB Clause 29.6, Bid-
Securing Declarations, if any, will expire for, or Bid Securities,
if any, will be returned as promptly as possible to,
(a) all Bidders upon annulment of the bidding pursuant to ITB
Clause 46;
(b) Bidders refusing a request to extend the period of validity
of their bids pursuant to ITB Clause 30.2;
(c) the successful Bidder once it has signed the Contract
Agreement and furnished a valid Performance Security as
required;
(d) the unsuccessful Bidders at the same time as in (c), that is,
when they are informed about the successful establishment
of the contract with the successful Bidder.
29.6 The Bid-Securing Declaration, if any, may be executed, or the
Bid Security, if any, may be forfeited:
(a) if a Bidder withdraws its bid during the period of bid
validity specified by the Bidder on the Bid Submission
Form or any extension of validity the Bidder has agreed to
pursuant to ITB Clause 30.2; or
(b) in the case of the successful Bidder, if the Bidder fails to:
(i) sign the Contract Agreement in accordance with ITB
Clause 48; or
32 Section I. Instructions to Bidders

(ii) furnish the Performance Security in accordance with

ITB Clause 49.
29.7 If a bid security is not required in the BDS, and
(a) if a Bidder withdraws its bid during the period of bid
validity specified by the Bidder on the Letter of Bid Form,
except as provided in ITB 30.2, or
(b) if the successful Bidder fails to: sign the Contract in
accordance with ITB 48; or furnish a performance security
in accordance with ITB 49;
the Borrower may, declare the Bidder disqualified to be
awarded a contract by the Borrower for a period of three (3)
years or as otherwise specified in the BDS.
30. Period of 30.1 Bids should remain valid, at a minimum, for the period specified
Validity of in the BDS after the deadline date for bid submission prescribed
Bids by the Purchaser, pursuant to ITB Clause 33. A bid valid for a
shorter period should be rejected by the Purchaser as non-
responsive. For the convenience of Bidders, the BDS spells out
the minimal original expiration dates for the validity of the bid
and, if applicable pursuant to ITB Clause 29.1, for securing the
bid.  However, Bidders are responsible for adjusting the dates in
the BDS in accordance with any extensions to the deadline date
of bid submission pursuant to ITB Clause 33.2.
30.2 In exceptional circumstances, prior to expiry of the bid validity
period, the Purchaser may request that the Bidders extend the
period of validity for a specified additional period.  The request
and the responses to the request should be made in writing. A
Bidder may refuse the request without risking execution of the
Bid-Securing Declaration or forfeiting the Bid Security, but in
this case the bid will be out of the competition for the award.
Except as provided in ITB Clause 30.3, a Bidder agreeing to the
request will not be required or permitted to modify its bid, but
will be required to ensure that the bid remains secured for a
correspondingly longer period, pursuant to ITB Clause 29.2.
30.3 In the case of fixed price contracts, if the award is delayed by a
period exceeding fifty-six (56) days beyond the expiry of the
initial bid validity, the contract price will be adjusted as
specified in the request for extension. Bid evaluation will be
based on the bid prices without taking into consideration the
above correction.
31. Format and 31.1 The Bidder should prepare an original and the number of
Signing of copies/sets of the bid specified in the BDS, clearly marking
Combined each one as “ORIGINAL COMBINED TECHNICAL AND FINANCIAL
Technical and BID,” “COPY 1,” “COPY 2,” etc., as appropriate. In the event of
Financial Bid any discrepancy between them, the original should govern.
Section I. Instructions to Bidders 33

31.2 The original and all copies of the bid, each consisting of the
documents listed in ITB Clause 25.1, should be typed or written
in indelible ink and should be signed by a person or persons duly
authorized to sign on behalf of the Bidder. The authorization
must be in writing and included in the bid pursuant to ITB
Clause 25.1 (d). The name and position held by each person
signing the authorization must be typed or printed below the
signature. All pages of the bid, except for unamended printed
literature, should be initialed by the person or persons signing
the bid.
31.3 The bid should contain no interlineations, erasures, or
overwriting, except to correct errors made by the Bidder, in
which case such corrections should be initialed by the person or
persons signing the bid.
31.4 The Bidder should furnish in the Combined Technical and
Financial Bid Submission Form (a sample of which is provided
in the Sample Bidding Forms and Material (Section III)
information regarding commissions or gratuities, if any, paid or
to be paid to agents relating to this procurement and to the
execution of the Contract should the Bidder be successful.

I. SUBMISSION OF COMBINED TECHNICAL AND FINANCIAL BIDS

32. Sealing and 32.1 The Bidder should seal the original and each copy of the bid in
Marking of separate envelopes, duly marking the envelopes as “ORIGINAL
Bids COMBINED TECHNICAL AND FINANCIAL BID ” and “COPY NO.
[number].” The envelopes should then be sealed in an outer
envelope.
32.2 The inner and outer envelopes should
(a) be addressed to the Purchaser as specified in the Invitation
for Bids – Second Stage Combined Technical and
Financial Bid, and
(b) bear the loan/Project name indicated in the BDS for ITB
Clause 2.1, the Invitation for Bids title and number, and
the Contract name(s), as indicated in the BDS for ITB
Clause 1.2, and the statement “DO NOT OPEN BEFORE
[  time and date],” to be completed with the time and date
specified in the BDS for ITB Clause 36.1.
32.3 The inner envelopes should also indicate the name and address
of the Bidder so that the bid can be returned unopened in case it
is declared “late.”
32.4 If the outer envelope is not sealed and marked as required by
ITB Clause 32.2 above, the Purchaser will assume no
responsibility for the bid’s misplacement or premature opening.
34 Section I. Instructions to Bidders

If the outer envelope discloses the Bidder’s identity, the

Purchaser will not guarantee the anonymity of the bid
submission, but this disclosure will not constitute grounds for
bid rejection.
33. Deadline for 33.1 Bids must be received by the Purchaser at the address as
Submission of specified in the Invitation for Bids – Second Stage Combined
Bids Technical and Financial Bid no later than the time and date
specified in the Invitation for Bids – Second Stage Combined
Technical and Financial Bid.
33.2 The Purchaser may, at its discretion, extend this deadline for
submission of bids by amending the Bidding Documents in
accordance with ITB Clause 11.3, in which case all rights and
obligations of the Purchaser and Bidders will thereafter be
subject to the deadline as extended.
34. Late Bids 34.1 Any bid received by the Purchaser after the bid submission
deadline as specified in the Invitation for Bids – Second Stage
Combined Technical and Financial Bid, will be rejected and
returned unopened to the Bidder.
35. Withdrawal, 35.1 The Bidder may withdraw, substitute, or modify its bid after
Substitution, submission, provided that written notice of the withdrawal,
and substitution, or modification is received by the Purchaser prior to
Modification of the deadline prescribed for bid submission. All notices must be
Bids duly signed by an authorized representative and should include a
copy of the authorization (the power of attorney) in accordance
with ITB Sub-Clause 31.2.
35.2 All notices of withdrawal, substitution, or modification should
(a) be addressed to the Purchaser at the address as specified in
the Invitation for Bids – Second Stage Combined
Technical and Financial Bid, and
(b) bear the Contract name, the IFB Title and IFB Number,
and the words “BID WITHDRAWAL NOTICE", BID
SUBSTITUTION NOTICE”, or “BID MODIFICATION NOTICE”.
35.3 A notice may also be sent by electronic means such as fax or e-
mail, but in this case must include a scan of the mailing receipt
showing both the sender's and receiver's addresses for the signed
hardcopy of the notice, and a scan of the power of attorney.
35.4 Bids requested to be withdrawn in accordance with ITB 35.1
should be returned unopened to the Bidders. Bid withdrawal
notices received after the bid submission deadline will be
ignored, and the submitted bid will be deemed to be a validly
submitted bid.
35.5 The substitution or modification of the bid should be prepared,
Section I. Instructions to Bidders 35

sealed, marked, and dispatched as follows:

(a) The Bidders should provide an original and the number of
copies specified in the BDS for ITB Clause 31.1 of any
substitution or modification to its bid, clearly identified as
such, in two inner envelopes duly marked “BID
SUBSTITUTION – ORIGINAL” or “BID MODIFICATION –
ORIGINAL” and “BID SUBSTITUTION – COPIES” or “BID
MODIFICATION – COPIES.” The inner envelopes should be
sealed in an outer envelope, which should be duly marked
“BID SUBSTITUTION” or “BID MODIFICATION”.
(b) Other provisions concerning the marking and dispatch of a
bid substitution or modification should be in accordance
with ITB Clauses 32.2, 32.3, and 32.4.
35.6 No bid may be withdrawn, substituted, or modified in the
interval between the bid submission deadline and the expiration
of the bid validity period specified by the Bidder in the
Combined Technical and Financial Bid Submission Form, or
any extension thereof agreed to by the Bidder. Withdrawal of a
bid during this interval may result in the execution of the Bid-
Securing Declaration, if any, or forfeiture of the Bid Security, if
any, pursuant to ITB Clause 29.6.

J. COMBINED TECHNICAL AND FINANCIAL BID OPENING AND

EVALUATION
36. Opening of 36.1 The Purchaser will open all bids, including withdrawals,
Combined substitutions, and modifications, in public, in the presence of
Technical and Bidders’ representatives who choose to attend, at the time, on
Financial Bids the date and at the place Invitation for Bids – Second Stage
by Purchaser Combined Technical and Financial Bid. Bidders’
representatives should sign a register as proof of their
attendance.
36.2 First, envelopes marked “BID WITHDRAWAL NOTICE” should be
opened and read out and the envelope with the corresponding
bid should not be opened, but returned to the Bidder. No bid
withdrawal should be permitted unless the corresponding
withdrawal notice contains a valid authorization to request the
withdrawal and is read out at bid opening. Next, envelopes
marked “BID SUBSTITUTION NOTICE” should be opened and read
out and exchanged with the corresponding bid being substituted,
and the substituted bid should not be opened, but returned to the
Bidder. No bid substitution should be permitted unless the
corresponding substitution notice contains a valid authorization
to request the substitution and is read out at bid opening.
Envelopes marked “BID MODIFICATION NOTICE” should be
36 Section I. Instructions to Bidders

opened and read out with the corresponding bid. No bid

modification should be permitted unless the corresponding
modification notice contains a valid authorization to request the
modification and is read out at bid opening. Only bids that are
opened and read out at bid opening should be considered further.
36.3 Bids should be opened one at a time, reading out: the name of
the Bidder and whether there is a modification; the total bid
price including any unconditional discounts, and the presence or
absence of a Bid-Securing Declaration or a Bid Security if one
was required; and any other such details as the Purchaser may
consider appropriate.
36.4 Bids and modifications that are not opened and read out at bid
opening should not be considered for further evaluation,
irrespective of the circumstances. These bids, including any
bids validly withdrawn in accordance with ITB Clause 36.2, will
promptly be returned, unopened, to their Bidders.
36.5 The Purchaser will prepare minutes of the bid opening,
including the information disclosed to those present in
accordance with ITB Clause 36.3. The minutes will promptly be
distributed to all Bidders that met the deadline for submitting
bids.
37. Clarification of 37.1 During the bid evaluation, the Purchaser may, at its discretion,
Bids ask the Bidder for a clarification of its bid. The request for
clarification and the response should be in writing, and no
change in the price or substance of the bid should be sought,
offered, or permitted.
38. Preliminary 38.1 The Purchaser will examine the bids to determine whether they
Examination are complete, whether any computational errors have been
of Bids made, whether required sureties have been furnished, whether
the documents have been properly signed, and whether the bids
are generally in order. In the case where a prequalification
process has been undertaken for the Contract(s) for which these
Bidding Documents have been issued, the Purchaser will ensure
that each bid is from a prequalified Bidder and, in the case of a
Joint Venture, that partners and structure of the Joint Venture
are unchanged from those in the prequalification.
38.2 Arithmetical errors will be rectified on the following basis.  If
there is a discrepancy between the unit price and the total price,
which is obtained by multiplying the unit price and quantity, or
between added or subtracted subtotals and totals, the unit or
subtotal price should prevail and the total price should be
corrected, unless in the opinion of the Purchaser there is an
obvious misplacement of the decimal point in the unit or
subtotal prices, in which case the line item total as quoted should
govern and the unit price or sub-total should be corrected.  If
Section I. Instructions to Bidders 37

there is a discrepancy between words and figures, the amount in

words will prevail, unless the discrepancy is the result of a
typo/error for which the correction is self-evident to the
Purchaser.  If the Bidder with the Lowest Evaluated Bid does
not accept the correction of errors, the bid should be rejected.
38.3 The Purchaser may waive any minor informality,
nonconformity, or irregularity in a bid that does not constitute a
material deviation, provided such waiver does not prejudice or
affect the relative ranking of any Bidder.
38.4 Prior to the detailed evaluation, the Purchaser will determine
whether each bid is of acceptable quality, is complete, and is
substantially responsive to the Bidding Documents. For
purposes of this determination, a substantially responsive bid is
one that conforms to all the terms, conditions, and specifications
of the Bidding Documents without material deviations,
exceptions, objections, conditionalities, or reservations. A
material deviation, exception, objection, conditionality, or
reservation is one: (i) that limits in any substantial way the
scope, quality, or performance of the Information System; or
(ii) that limits, in any substantial way that is inconsistent with
the Bidding Documents, the Purchaser’s rights or the successful
Bidder’s obligations under the Contract; or (iii) the acceptance
of which would unfairly affect the competitive position of other
Bidders who have submitted substantially responsive bids.
38.5 If a bid is not substantially responsive, it will be rejected by the
Purchaser and may not subsequently be made responsive by the
Bidder by correction of the nonconformity. The Purchaser’s
determination of bid responsiveness will be based on the
contents of the bid itself.
39. Conversion to 39.1 For evaluation and comparison purposes, the Purchaser should
Single convert all bid prices expressed in various currencies and
Currency amounts into a single currency specified in the BDS, using the
selling exchange rate established by the source and on the date
also specified in the BDS.
40. Evaluation and 40.1 The Purchaser will evaluate and compare the bids that have been
Comparison of determined to be substantially responsive, pursuant to ITB
Bids Clause 38. The evaluation will be performed assuming that the
Contract will be awarded to the Bidder with the Lowest
Evaluated Bid for the entire Information System:
40.2 To be considered for Contract award, Bidders must have
submitted bids
(a) for which detailed bid evaluation using the same standards
for compliance determination as listed in ITB Clauses 38.3
and 38.4 confirms that the bids are commercially and
technically responsive, and include the hardware,
38 Section I. Instructions to Bidders

Software, related equipment, products, Materials, and

other Goods and Services components of the Information
System in, substantially, the full required quantities for the
entire Information System; and
(b) that offer Information Technologies that are proven to
perform up to the standards promised in the bid by having
successfully passed the performance, benchmark, and/or
functionality tests the Purchaser may require, pursuant to
ITB Clause 43.2.
40.3 The Purchaser’s evaluation of a bid will be made on the basis of
prices quoted in accordance with ITB Clause 26 (Bid Prices).
40.6 The Evaluated Bid Price (C) for each responsive bid will be
determined as the sum of the Adjusted Supply and Installation
Costs (P) plus the Recurrent Costs (R);
where the Adjusted Supply and Installation Costs (P) are
determined as:
(a) The price of the hardware, Software, related equipment,
products, Materials and other Goods offered from within
or from outside the Purchaser’s Country, in accordance
with ITB 26.4; plus
(b) The total price for all software development,
transportation, insurance, installation, customization,
integration, Commissioning, testing, training, technical
support, repair, and other Services, in accordance with ITB
26.5;
(c) with adjustments for:
(i) Deviations proposed to the Implementation Schedule
resulting in delayed completion of the entire
Information System, up to the maximum permissible
delay specified in the BDS. For evaluation
purposes, a pro rata increase of the total Supply and
Installation Costs will be added using the
percentage(s) specified in the BDS for each week of
delay. Bids offering deliveries beyond the maximum
permissible delay specified may be rejected.
(ii) Unless otherwise permitted in the BDS, deviations
taken to the Contract payment schedule specified in
the SCC will NOT be permitted. However, if
deviations are permitted in the BDS, for evaluation
purposes the total Supply and Installation Costs will
be increased pro rata by the amount of interest that
could otherwise be earned on the amount of any
payments that would fall due under the proposed
schedule earlier than the schedule stipulated in the
Section I. Instructions to Bidders 39

SCC, at the interest rate specified in the BDS.

(iii) Goods and Services that are required for the
Information System but have been left out or are
necessary to correct minor deviations of the bid will
be added to the total Supply and Installation Costs
using costs taken from the highest prices from other
responsive bids for the same Goods and Services, or
in the absence of such information, the cost will be
estimated at prevailing list prices. If the missing
Goods and Services are a scored technical feature,
the relevant score will be set at zero.
(iv) Corrections to errors in arithmetic, in accordance
with ITB Clause 38.2.
40.7 The Recurrent Costs (R) are reduced to net present value and
determined using the following formula:
N Rx
R 
x  1 1  I  x
where
N = number of years of Recurrent Cost items specified
in the Technical Requirements and recorded in the
Recurrent Cost Sub-Table of the System Inventory
Tables (in Section V)
x = an index number 1, 2, 3, ... N .
Rx = total Recurrent Costs for year “x,” as recorded in
the Recurrent Cost Sub-Table.
I = discount rate to be used for the Net Present Value
calculation, is five (5) percent per annum – unless
otherwise specified in the BDS.
41. Domestic 41.1 No margin of domestic preference will apply.
Preference
42. Contacting the 42.1 From the time of bid opening to the time of Contract award, if
Purchaser any Bidder wishes to contact the Purchaser on any matter related
to the bid, it should do so in writing.
42.2 If a Bidder tries to directly influence the Purchaser or otherwise
interfere in the bid evaluation process and the Contract award
decision, its bid may be rejected.
40 Section I. Instructions to Bidders

K. POST-QUALIFICATION AND AWARD OF CONTRACT

43. Post- 43.1 The Purchaser will determine at its own cost and to its
qualification satisfaction whether the Bidder (including Joint Venture
Partners, and any Subcontractors for which the BDS for ITB
Clause 6.1 (a) permits that their qualifications count towards the
required Bidder qualifications) that is selected as having
submitted the Lowest Evaluated Bid is qualified to perform the
Contract satisfactorily, in accordance with ITB Clause 6. If a
prequalification process was undertaken for the Contract(s) for
which these Bidding Documents were issued, the Purchaser will
determine in the manner described above that no material
changes have occurred after the prequalification that negatively
affect the ability of the Bidder that has submitted the Lowest
Evaluated Bid to perform the Contract.
43.2 Pursuant to ITB Clauses 6 and 28, the determination will
evaluate the Bidder’s financial, technical, design, integration,
customization, production, management, and support
capabilities and will be based on an examination of the
documentary evidence of the Bidder’s qualifications, as well as
other information the Purchaser deems necessary and
appropriate. This determination may include visits or interviews
with the Bidder’s clients referenced in its bid, site inspections,
and any other measures. Unless otherwise specified in the
BDS, the Purchaser will NOT carry out tests at the time of post-
qualification to determine that the performance or functionality
of the Information System offered meets those stated in the
Technical Requirements. However, if so specified in the BDS
the Purchaser may carry out such tests as detailed in the BDS.
43.3 An affirmative post-qualification determination will be a
prerequisite for award of the Contract to the Lowest Evaluated
Bidder. A negative determination will result in rejection of the
Bidder’s bid, in which event the Purchaser will proceed to the
next lowest evaluated Bidder to make a similar determination of
that Bidder’s capabilities to perform satisfactorily.
44. Award 44.1 Subject to ITB Clause 46, the Purchaser will award the Contract
Criteria to the Bidder whose bid has been determined to be substantially
responsive and the Lowest Evaluated Bid, provided further that
the Bidder has been determined to be qualified to perform the
Contract satisfactorily, pursuant to ITB Clause 43.
45. Purchaser’s 45.1 The Purchaser reserves the right to accept or reject any bid or to
Right to annul the bidding process and reject all bids at any time prior to
Accept Any Contract award, without thereby incurring any liability to the
Bid and to Bidders.
Reject Any or
All Bids
Section I. Instructions to Bidders 41

46. Notification of 46.1 Prior to the expiration of the period of bid validity, the Purchaser
Award should notify the successful Bidder, in writing, that its bid has
been accepted.
46.2 Until a formal Contract is prepared and executed, the
notification of award should constitute a binding Contract.
46.3 The Purchaser should promptly publish in UNDB online and in
dgMarket the results, identifying the bid and the following
information: (i) name of each Bidder who submitted a bid; (ii)
bid prices as read out at bid opening; (iii) name, evaluated price
and (iv) name of Bidders whose bids were rejected and the
reasons for their rejection; and (v) name of the winning Bidder,
the price it offered, as well as the duration and summary scope
of the contract awarded. After publication of the award,
unsuccessful Bidders may make a request in writing to the
Purchaser for a debriefing to seek explanations of the grounds
on which their bids were not selected. The Purchaser should
promptly respond in writing to any unsuccessful Bidder who,
after publication of contract award, requests a debriefing.
46.4 Upon the successful Bidder furnishing the signed Contract
Agreement and the Performance Security pursuant to ITB
Clause 48, the Purchaser will promptly notify each unsuccessful
Bidder, and will discharge all remaining Bid Securities, if any,
as provided in ITB Clause 29.5 (c) and (d).
47. Signing of 47.1 At the same time as the Purchaser notifies the successful Bidder
Contract that its bid has been accepted, the Purchaser will send the Bidder
the Contract Agreement provided in the Bidding Documents,
incorporating all agreements between the parties.
47.2 As soon as practically possible, but no more than twenty-eight
(28) days following receipt of the Contract Agreement, the
successful Bidder should sign and date it, and return it to the
Purchaser.
48. Performance 48.1 As soon as practically possible, but no more than twenty-eight
Security (28) days following receipt of notification of award from the
Purchaser, the successful Bidder should furnish the Performance
Security in accordance with the GCC, using the Performance
Security form provided in the Bidding Documents or another
form acceptable to the Purchaser.
48.2 Failure of the successful Bidder to comply with the requirements
of ITB Clause 47 or ITB Clause 48.1 should constitute sufficient
grounds for the annulment of the award and, if and as
applicable, execution of the Bid-Securing Declaration or
forfeiture of the Bid Security, in which event the Purchaser may
make the award to the next lowest evaluated bid submitted by a
qualified Bidder or call for new bids.
42 Section I. Instructions to Bidders

49. Adjudicator 49.1 Unless otherwise stated in the BDS, the Purchaser proposes that
the person named in the BDS be appointed as Adjudicator under
the Contract to assume the role of informal Contract dispute
mediator, as described in GCC Clause 43. In this case, a résumé
of the named person is attached to the BDS. The proposed
hourly fee for the Adjudicator is specified in the BDS. The
expenses that would be considered reimbursable to the
Adjudicator are also specified in the BDS.
If a Bidder does not accept the Adjudicator proposed by the
Purchaser, it should state its non-acceptance in its Bid
Submission Form and make a counterproposal of an Adjudicator
and an hourly fee, attaching a résumé of the alternative. If the
successful Bidder and the Adjudicator nominated in the BDS
happen to be from the same country, and this is not the country
of the Purchaser too, the Purchaser reserves the right to cancel
the Adjudicator nominated in the BDS and propose a new one.
If by the day the Contract is signed, the Purchaser and the
successful Bidder have not agreed on the appointment of the
Adjudicator, the Adjudicator should be appointed, at the request
of either party, by the Appointing Authority specified in the
SCC clause relating to GCC Clause 43.1.4, or if no Appointing
Authority is specified there, the Contract will be implemented
without an Adjudicator.
Section II. Bid Data Sheet 43

SECTION II. BID DATA SHEET (BDS)

The following specific information relate to the Information System to be procured and
the procurement procedures that will be used. They complement, supplement, or amend
the provisions in the Instructions to Bidders (ITB). Whenever there is a conflict, the
provisions in the Bid Data Sheet (BDS) should prevail over those in the ITB.

A. GENERAL

ITB 1.1 Name of Purchaser: National Agency for Fiscal Administration

(NAFA / ANAF)

Description of the Information System for which bids are invited:

An integrated Revenue Management System (RMS) for
administering all the taxes, levies, and social insurance
contributions specified under Romanian Law (excluding
customs duties and excise taxes) – under a single-
responsibility contract encompassing all the necessary
software and services (but excluding ICT hardware).

ITB 1.2 Title of IFB: Integrated Revenue Management System

Number of IFB: RAMP/5

Name of resulting Contract(s): RAMP/5 - Integrated Revenue

Management System

ITB 1.4 There is no additional bid data for ITB 1.4

ITB 2.1 Name of the Borrower: Romania

Loan or credit number: No. 8261 – RO

Loan or credit amount: 70 million €

Name of Project: Revenue Administration Modernization Project

(RAMP)
44 Section II. Bid Data Sheet

ITB 6.1 (a) Qualification requirements for Bidders are:

A. The Bidder MUST demonstrate that within the seventy-two

months prior to bid submission (i.e. years 2010, 2011, 2012,
2013, 2014 and 2015) it has successfully implemented the
bid Revenue Management System (RMS) software product
(including previous versions) for at least one (1) integrated
revenue management system (covering minimally personal
and enterprise income taxes, value-added or sales taxes)
withtheimplementation covering at least one million
(1,000,000) taxpayer accounts. The successful
implementation shall be documented by an Operational
Acceptance Certificate issued by the previous Purchaser of
the bid RMS product. In the case of a joint venture, the
Partner in Charge MUST demonstrate the above successful
experience. Any other JV partner(s) MUST demonstrate that
within the seventy-two months prior to bid submission (i.e.
years 2010, 2011, 2012, 2013, 2014 and 2015) it has
participated in the successful implementation of at least one
(1) financial transactions/management system (e.g., social
insurance, treasury, customs, banking, etc.) with at least five
hundred thousand (500,000) accounts. Note: Bidding Form
5.3.1 specifies the format for required acknowledgement by
the references of successful implementation1.

B. The Bidder must document having ready access to at least

two million (2,000,000) Euro equivalent in liquid assets
(bank balances, unencumbered securities, lines of credit
etc.). In the case of a joint venture, the requirement can be
met by the sum of the JV partners' contribution or by the JV
itself.

C. The Bidder must prove that in each of the last three (3)
financial years prior to the bid, generated an overall
turnover of no less than ten million (10,000,000) Euro. In
the case of a joint venture, the requirement can be met by the
sum of the JV partners' contribution or by the JV itself.

ITB 6.1 (b) There is no additional bid data for ITB 6.1(b)

1
Please note that the Purchaser reserves the right to undertake visits at any implementation
sites of the System or request written references regarding the bid RMS system from the
previous purchasers indicated in the Bid.
Section II. Bid Data Sheet 45

ITB 6.1 (c) There is no additional bid data for ITB 6.1(c)

ITB 6.3 The Bidder MUST provide a Subcontractor Agreement (in the form
included in the Bidding Sample Forms Section) for ALL proposed
Subcontractors.

B. THE BIDDING DOCUMENTS

ITB 9.1 These Bidding Documents should NOT include System Inventory
Tables in PART 2: PURCHASER’S REQUIREMENTS.

ITB 10.1 Purchaser’s address: 17, Apolodor Street, Sector 5, Bucharest,

Romania

Purchaser’s contact information:

Phone: +4021 387 20 57 or +4021 38720 58

Facsimile: +4021 319 96 71

E-mail: [email protected]

Purchasers contact person: Mrs. Daniela Manoli – Project

Manager of RAMP Project Management Unit.

ITB 10.2 Dates, times, and places for the pre-bid meeting:
10:00 local time on January 20th, 2016 at 17, Apolodor
Street (“Registratura” Entrance (ground floor)), Sector 5,
Bucharest

C. LANGUAGE OF BIDS

ITB 12.1 There are no additional bid data for ITB Clause 12.1
46 Section II. Bid Data Sheet

D. PREPARATION OF FIRST STAGE TECHNICAL-ONLY BIDS

ITB 14.2 (c) In line with the Bidder’s methodologies and in accordance with the
Service requirements (see Paragraph6 of the Technical
Requirements Section), the Preliminary Project Plan MUST
address at least the following topics.

 Project Organization and Management Sub-Plan

 Testing and Quality Assurance Sub-Plan
 Analysis and Detailed Design Sub-Plan
 Installation, Configuration, Customization and
Integration Sub-Plan
 Data Migration Sub-Plan
 Production Transition and Roll-out Sub-Plan
 Human Capacity Building Sub-Plan
 Warranty Defect Repair and Technical Support
Service Sub-Plan
In the interest of effective integration, cost-effective technical
support, and reduced re-training and staffing costs, Bidders
ITB 14.3 are required to offer specific brand names and models for the
following limited number of specific items: none.

ITB 16.1 Required number of bid copies, besides the original two (2) hard
copies and one (1) digital “soft” copy. (In the event of any
discrepancies, the hard copy original should prevail.)To the
extent practical, revisable versions of the digital files would
be appreciated – to facilitate timely bid evaluation and
clarification dialog.

E. SUBMISSION OF FIRST STAGE TECHNICAL-ONLY BIDS

ITB 18.1 The address for bid submission is: 17 Apolodor Street, Sector 5,
(“Registratura” Entrance (ground floor))Bucharest,
Romania – Mrs. Daniela Manoli – RAMP Project
Manager.

Deadline for the submission of the First State Technical-Only Bid is:
10:00 local time on February 25th, 2016.
Section II. Bid Data Sheet 47

F. OPENING AND EVALUATION OF FIRST STAGE TECHNICAL-

ONLY BIDS

ITB 19.1 Time, date, and place for the opening of the Technical-Only Bid are:
10:30 local time on February 25th, 2016 at 17, Apolodor
Street, Sector 5, (“Registratura” Entrance (ground floor))
Bucharest, Romania].

ITB 23.3 Demonstrations of the bid RMS product WILL form part of the First
Stage Technical-Only Bid clarification meetings. In
particular, the Bidder MUST be prepared to demonstrate bid
RMS product’s support of the main business functions
specified in the Technical Requirements (see Paragraphs 1
and 2) – and/or discuss how the bid RMS product would be
configured, localized, or customized to meet the
requirements. If appropriate, the Bidder may indicate
alternative approaches to the Purchaser’s business functions,
based on the Bidder’s experience and/or the RMS product’s
capabilities. The Bidder MUST also present and discuss the
licensing agreements for all COTS products bid. The
Purchaser reserves the right to reject and require
replacements (in the second stage bid) of any COTS, if the
conveyed terms and conditions are onerous or
inappropriately restrictive.

G. INVITATION TO SECOND STAGE COMBINED TECHNICAL AND

FINANCIAL BIDS

ITB 24 There are no additional bid data for ITB Clause 24.
48 Section II. Bid Data Sheet

H. PREPARATION OF COMBINED TECHNICAL AND FINANCIAL

BIDS
Separate enforceable contract(s) for the Recurrent Cost Items will
NOT be required. Instead the Technical Support Services
ITB 26.2 specified in the Technical Requirements for the period
specified in the Technical Requirements should be included in
the all-inclusive Bid Price (and paid out as a pre-specified
percentage of the Total Contract Price in accordance with
SCC 12).
Nevertheless, the Bidder MUST provide a written commitment that,
if the Purchaser requests continued Technical Support
Services after the conclusion of the Contract (i.e., following
the end of the Warranty Period), the Bidder will submit an
offer on the same technical and financial terms (adjusted, as
appropriate and agreed, for exchange rate and labor cost
developments) as those that prevailed during the Warranty
Period under the Contract for a period of at least five years
following the end of the Contract.
The Incoterms edition is Incoterms 2010 — “ICC Official Rules for
the Interpretation of Trade Terms” published by the
ITB 26.5 International Chamber of Commerce, 38 Cours Albert 1er,
75008 Paris, France.

ITB 26.5 (a), (b), The Contract envisions few – if any – tangible products (instead it
& (c) comprises software licenses and services). Hence bid pricing
will not be built up from individual quantities and items.
Instead the Bid Price will be a single, all-inclusive price (in a
“turnkey” style).

Nevertheless, the Bidder MUST submit an informational table forth

software licenses, including units, unit prices, quantities and
sub-totals. This is required to support the Purchaser’s asset
management accounting obligations and to inform any in-
contract change orders.

ITB 26.6 The Bid Price will be a single, all-inclusive price (in a “turnkey”
style).

Nevertheless, the Bidder is required to submit an informative table

detailing any daily reference fees for all specialist profiles
included in the bid and for any additional resources
considered necessary for the successful implementation of
the System (including management and support functions).
Section II. Bid Data Sheet 49

The fees presented in the informative table will be negotiated

and decided upon in the Project Planning phase. The fees
established during the planning phase will become binding
for the Supplier in the provision of additional services under
the contract.

Daily fees will be adjusted annually on January 1 st of each year after

the date of contract signing for remuneration in foreign and
local currency respectively (first adjustment will be done
after minimum 12 months). Remuneration in foreign
currency should be adjusted by using a relevant index linked
to labor costs in the country of the respective foreign
currency; and remuneration in local currency by using the
index related to labour costs (monthly average gross earnings
- Total) as published by the Romanian National Institute for
Statistics.

Adjustments shall be made using the following formula:

Rn=R o × In
Io
where
Rn is the adjusted fee;
Ro is the remuneration payable on the basis of the fees as per
the Bidder’s Bid;
In is the official index for the first month for which the
adjustment is supposed to have effect; and
Io is the official index for the month of the date of the
Contract signing.

ITB 26.7 There are no additional bid data for ITB 26.7

ITB 27.1 (b) There are no additional bid data for ITB 27.1 (b)

ITB 29.1 Bids need to be secured by a Bid Security of at least three hundred
twenty thousand Euro (320,000€) equivalent in a freely
convertible currency.

ITB 29.7 There are no additional bid data for ITB 29.7
50 Section II. Bid Data Sheet

ITB 30.1 The bid validity period should be 150 (one hundred and fifty) days
after the deadline for bid submission, as specified below in
reference to ITB Clause 33. Accordingly, each bid should be
valid through July 24th, 2016.

Accordingly, a bid with a Bid Security that expires before August

21st, 2016 should be rejected as non-responsive.

ITB 31.1 Required number of bid copies, besides the original two (2) hard
copies and one (1) digital “soft” copy. (In the event of any
discrepancies, the hard copy original should prevail.) To the
extent practical, revisable versions of the digital files would
be appreciated to facilitatetimely bid evaluation and
clarification dialog.

I. SUBMISSION OF COMBINED TECHNICAL AND FINANCIAL BIDS

There is no additional bid data for ITB 32-35

ITB 32-35

J. COMBINED TECHNICAL AND FINANCIAL BID OPENING AND

EVALUATION

ITB 39.1 The currency chosen for the purpose of converting to a common
currency is: Euro.

The source of exchange rate is: National Bank of Romania

(http://www.bnro.ro/Home.aspx).

The date of exchange rate determination is: the last business day
prior to the bid submission deadline. In case that no
exchange rates are available on this date from the source
indicated above, the latest available exchange rates from the
same source prior to this date will be used.
Section II. Bid Data Sheet 51

ITB 40.6 (c) (i) The maximum proposed delay in the Implementation Schedule may
be twenty-six (26) weeks

The percentage for adjustment of a bid offering to complete

installation and commissioning later than the specified date,
but earlier than the maximum delay, is one quarter of one
percent of the bid price per week.

ITB 40.6 (c) (ii) There is no additional bid data for ITB 40.6 (c) (ii).

ITB 40.7 Recurrent Cost items will not be priced separately from the overall
Bid Price and will not be discounted.

K. POST-QUALIFICATION AND AWARD OF CONTRACT

ITB 43.2 There will be no post-qualification tests of the bid system.

ITB 49.1 The proposed Adjudicator is Mr. Shanti P. Namballa (see résumé
below).

The proposed Adjudicator’s fees and reimbursables will be

established during Contract Finalization.
 52 Section II. Bid Data Sheet

Annex to Section II. Bid Data Sheet (BDS)

Clause ITB 3: The provisions in ITB 3.1 to 3.3 are replaced with the following, including
relevant footnotes:

3. Fraud and 3.1 It is the Bank’s policy to require that Borrowers

Corruption (including beneficiaries of Bank loans), as well as
bidders, suppliers, and contractors and their agents
(whether declared or not), personnel, subcontractors,
sub-consultants, service providers and suppliers under
Bank-financed contracts, observe the highest standard
of ethics during the procurement and execution of such
contracts.1 In pursuance of this policy, the Bank:
(a) defines, for the purposes of this provision, the terms set
forth below as follows:
(i) “corrupt practice” is the offering, giving, receiving
or soliciting, directly or indirectly, of anything of
value to influence improperly the actions of another
party2;
(ii) “fraudulent practice” is any act or omission,
including a misrepresentation, that knowingly or
recklessly misleads, or attempts to mislead, a party
to obtain a financial or other benefit or to avoid an
obligation3;
(iii) “collusive practice” is an arrangement between two
or more parties4 designed to achieve an improper
purpose, including to influence improperly the
actions of another party;
(iv) “coercive practice” is impairing or harming, or
threatening to impair or harm, directly or indirectly,
any party or the property of the party to influence
improperly the actions of a party5;
1
In this context, any action taken by a bidder, supplier, contractor, or any of its personnel,
agents, subcontractors, sub-consultants, service providers, suppliers and/or their employees
to influence the procurement process or contract execution for undue advantage is improper.
2
“Another party” refers to a public official acting in relation to the procurement process or
contract execution. In this context, “public official” includes World Bank staff and employees
of other organizations taking or reviewing procurement decisions.
3
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement
process or contract execution; and the “act or omission” is intended to influence the
procurement process or contract execution.
4
“Parties” refers to participants in the procurement process (including public officials)
attempting to establish bid prices at artificial, non- competitive levels.
5
“Party” refers to a participant in the procurement process or contract execution.
Section II. Bid Data Sheet 53

(v) “obstructive practice” is

(aa) deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
investigators in order to materially impede a
Bank investigation into allegations of a corrupt,
fraudulent, coercive or collusive practice;
and/or threatening, harassing or intimidating
any party to prevent it from disclosing its
knowledge of matters relevant to the
investigation or from pursuing the
investigation; or
(bb) acts intended to materially impede the exercise
of the Bank’s inspection and audit rights
provided for under sub-clause 3.2 below.
(b) will reject a proposal for award if it determines that the
bidder recommended for award has, directly or through an
agent, engaged in corrupt, fraudulent, collusive, coercive
or obstructive practices in competing for the contract in
question;
(c) will cancel the portion of the loan allocated to a contract if
it determines at any time that representatives of the
Borrower or of a beneficiary of the loan engaged in
corrupt, fraudulent, collusive, or coercive practices during
the procurement or the execution of that contract, without
the Borrower having taken timely and appropriate action
satisfactory to the Bank to address such practices when
they occur; and
(d) will sanction a firm or an individual, at any time, in
accordance with prevailing Bank’s sanctions proceduresa,
including by publicly declaring such firm or individual
ineligible, either indefinitely or for a stated period of time:
(i) to be awarded a Bank-financed contract; and (ii) to be a
nominatedb subcontractor, consultant, manufacturer or
supplier, or service provider of an otherwise eligible firm
being awarded a Bank-financed contract.

a a
A firm or an individual may be declared ineligible to be awarded a Bank-financed contract
upon completion of the Bank’s sanctions proceedings as per its sanctions procedures,
including inter alia: (i) temporary suspension in connection with an ongoing sanctions
proceeding; (ii) cross-debarment as agreed with other International Financial Institutions,
including Multilateral Development Banks; and (iii) the World Bank Group corporate
administrative procurement sanctions procedures for fraud and corruption.

b b
A nominated sub-contractor, consultant, manufacturer or supplier, or service provider
(different names are used depending on the particular bidding document) is one whicheither
has been:(i) included by the bidder in its pre-qualification application or bid because it brings
specific and critical experience and know-how that are accounted for in the evaluation of the
bidder’s pre-qualification application or the bid; or (ii) appointed by the Borrower.
54 Section II. Bid Data Sheet

3.2 In further pursuance of this policy, Bidders shall permit the

Bank to inspect any accounts and records and other documents
relating to the Bid submission and contract performance, and to have
them audited by auditors appointed by the Bank.
3.3 Furthermore, Bidders shall be aware of the provision stated in
Clause 9.8 and Clause 41.2 in the General Conditions of Contract.

Clause ITB 4 (Eligible bidders): The provision in ITB 4.3 is replaced with the
following, including relevant footnotes:
4.3 Afirm that has been sanctioned by the Bank in accordance with the
above ITB Clause 3.1 (d), or in accordance with the Bank’s Guidelines on
Preventing and Combating Fraud and Corruption in Projects Financed by
IBRD Loans and IDA Credits and Grants, shall be ineligible to be awarded
a Bank-financed contract, or benefit from a Bank-financed contract,
financially or otherwise, during such period of time as the Bank shall
determine. The list of debarred firms is available at the electronic
address specified in the BDS (http://www.worldbank.org/debarr).
Section II. Bid Data Sheet 55

Résumé of the proposed Adjudicator.

56 Section II. Bid Data Sheet
Section II. Bid Data Sheet 57
58 Section II. Bid Data Sheet
Section II. Bid Data Sheet 59

of SAP to the international organizations community and managed a portfolio of 20 international

agencies

NexCell Systems, Inc. April 2000 - Nov 2003

Managing Principal, VA, USA

As the founder and head of the IT consulting firm, held P&L responsibility and was responsible for the
business strategy, growth and operations. I defined the company’s vision, goals, strategy, service and
solution portfolio and identified niche solution areas such as Enterprise Architecture Planning, Data
Analytics and Business Performance Measurement. Some of the key engagements were:
• Conducted a comprehensive implementation review of the global financials and logistics systems for
UNICEF and prepared a set of recommendations to simply the processes, improve efficiencies and a
roadmap for future upgrades of the SAP implementation
• Developed the procurement strategy and the RFP for an enterprise wide portal and content
management System under institutional procurement for the World Bank Group
• Proposed and supported the implementation of data analytics for the Development Gateway of the
World Bank
• Conducted an implementation review of the SAP budgetary ledger implementation for Ministry of
Finance, Colombia
• As an advisor to the PMO at US Government General Services Administration, formulated a strategic
plan and reengineered business processes for the freight and household goods transportation
services to enable a financially self-sustaining by improving revenue streams
• Established the government contracting credentials by obtained certifications and contract vehicles
for the company such as the US GSA schedule 70, 8(a) and SDB.

The World Bank Group Jan 1989 - Mar 2000

Information Officer, Washington DC

• In various capacities executed several assignments including project management, software

development and technical advisory services in Treasury, Controllers and Information Solutions
Group vice presidencies.
• As a member of the technical evaluation committee was responsible for evaluation of software
capabilities and vendor scoring of leading ERP vendors
• As the technical lead, responsible for the implementation and rollout of Financials, HR and
procurement modules of SAP ERP for a 10,000 user global project in 140 country offices budgeted at
USD 70 million As a technical lead, I was responsible for leading a team for the implementation of
SAP financials for the International Finance Corporation
• Conducted a comprehensive security audit and vulnerability test for all institutional systems and
drafted the first security policy which became the cornerstone of subsequent security overhaul and
best practices
• Engaged in various assignments such as products evaluation and selection for data warehousing,
ERP, enterprise wide reporting strategy, security audits, business continuity and policies
• As a member of a task force, proposed a department wide internet/intranet strategy addressing the
development of web based applications and extending the scope of existing client/server
applications.

Resume: Shanti Namballa Page 5

60 Section II. Bid Data Sheet

• Developed an enterprise level reporting framework for developing, deploying and web enabling a
large number of financial reports using Crystal Reports.
• Responsible for the security of all financial applications in the controllers vice presidency, defining
new policies and procedures and coordinating with the Institutional security group.
• Developed the Loan Receipt Module and Debt Service Trust Funds modules of the Loan
Administration System, a GUI driven client/server based financial. The multi-currency applications
included: loan management, debt servicing, receivables and payments.
• Designed and implemented the message handling system application interface for an internal
internetworking system to connect the IBM, DEC, Unisys and Unix platforms to the SWIFT network.
• Designed and implemented the Loan Service Payment System on Unisys A Series and subsequently
as a team lead supported the application.
• Developed a mission critical multi-currency cash transaction processing system the hub of all
incoming and outgoing electronic financial messages. The system was interfaced with the SWIFT
network and was capable of conducting foreign exchange conversions, executing deals via electronic
messages with the currency traders, receiving and making payments to banks worldwide.
• Designed and developed the IMF exchange rate captures & inter-bank reconciliatory systems for
payments through SWIFT.

Prior Employment:

JKTechnosoft, India, Manager (Projects) Jan 1987 – Oct 1988

As a member of the management team for a startup software consulting company funded by a large
manufacturing company, was entrusted to setup all operations for the company. Responsible for a wide
range of activities including: strategic planning, budgeting, facilities planning, procurement, government
and Banking relations.

HCL, India, Industry Specialist Oct 1986 - Dec 1986

Responsible for directing a team of developers and providing technology solutions and presales support
to the marketing department for oil, coal and steel industries modernization

TCS, USA/ Germany/ India Jun 1982 – Sep 1986

Held various positions and developed applications on a wide range of hardware. Some of the key
projects were in the areas of event management, production control, accounting, securities, banking,
utility billing and education.

Education:
M.S. Civil Engineering (Transportation Systems), IIT Kanpur, India, 1982
B.S. Civil Engineering, VNIT, Nagpur, India, 1979
Certified IT Management Professional, 2002

Resume: Shanti Namballa Page 6

Section III: Sample Bidding Forms 61

SECTION III. SAMPLE BIDDING FORMS

62 Section III: Sample Bidding Forms

Notes to Bidders on working with the Bidding Forms

The Purchaser has prepared the forms in this section of the Bidding Documents to
suit the specific requirements of the System being procured. They are derived from the
forms contained in the World Bank’s Standard Bidding Documents for the Supply and
Installation of Information Systems. In its bid, the Bidder must use these forms (or forms
that present in the same sequence substantially the same information). Bidders should not
introduce changes without the Purchaser’s prior written consent (which may also require
the clearance of the World Bank). If the Bidder has a question regarding the meaning or
appropriateness of the contents or format of the forms and/or the instructions contained in
them, these questions should be brought to the Purchaser’s attention as soon as possible
during the bid clarification process, either at the pre-bid meeting or by addressing them to
the Purchaser in writing pursuant to ITB Clause 10.
The Purchaser has tried to provide explanatory text and instructions to help the
Bidder prepare the forms accurately and completely. The instructions that appear directly
on the forms themselves are indicated by use of typographical aides such as italicized text
within square brackets – as is shown in the following example taken from the Bid
Submission Form:
“Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]”
In preparing its bid, the Bidder must ensure all such information is provided and
that the typographical aides are removed.
Section III: Sample Bidding Forms 63

Table of Sample Bidding Forms

1. Invitation for Bids (IFB).........................................................................................64

1.1 Invitation for Bids (IFB) – First Stage Technical-Only Bid....................................65
1.2 Invitation for Bids (IFB) – Second Stage Combined Technical and Financial
Bid.............................................................................................................................68
2. Bid Submission Forms............................................................................................70
2.1 Bid Submission Form – First Stage Technical-Only Bid........................................71
2.2 Bid Submission Form Second Stage Combined Technical and Financial Bid........74
3. Bid Securing Forms................................................................................................79
3.1 Bid Security (Bank Guarantee)................................................................................80
3.2 Bid Security (Bid Bond)..........................................................................................82
4. Bidder’s Eligibility Forms......................................................................................84
4.1 General Information Form.......................................................................................85
5. Bidder’s Qualification Forms................................................................................86
5.1 General Information Systems Experience Record...................................................87
5.2 Particular Information Systems Experience Record.................................................88
5.3 Details of Contracts of Similar Nature and Complexity..........................................89
5.3.1 Bidder Past Performance Reference.........................................................................90
5.4 Summary Sheet: Current Contract Commitments / Work in Progress...................92
5.5 Financial Capabilities...............................................................................................93
5.9 Litigation History.....................................................................................................95
5.10 Manufacturer’s Authorization...................................................................................96
5.11 Joint Venture Summary............................................................................................97
6. Proposed Subcontractor Forms.............................................................................98
6.1 List of Proposed Subcontractors..............................................................................99
6.2 Subcontractor’s Agreement....................................................................................100
7. Intellectual Property Forms.................................................................................101
7.1 Software List..........................................................................................................102
7.2 List of Custom Materials.......................................................................................103
8. Conformance of Information System Materials................................................104
8.1 Format of the Technical Bid..................................................................................105
8.2 Technical Responsiveness Checklist.....................................................................107
64 Section III: Sample Bidding Forms

1. INVITATION FOR BIDS (IFB)

Section III: Sample Bidding Forms 65

1.1 Invitation for Bids (IFB) – First Stage Technical-Only Bid

Romania
Revenue Administration Modernization Project (RAMP)
An integrated Revenue Management System (RMS) for administering all the taxes,
levies, and social insurance contributions specified under Romanian Law (excluding
customs duties and excise taxes) – under a single-responsibility contract encompassing
all the necessary software and services (but excluding ICT hardware)
No. 8261 – RO
Integrated Revenue Management System
RAMP/5

1. This Invitation for Bids (IFB) follows the General Procurement Notice (GPN) for
this project that appeared in UNDB online on 20 August 2013.
2. The Romania has received a loanfrom the International Bank for Reconstruction
and Development toward the cost of the Revenue Administration Modernization
Project (RAMP), and it intends to apply part of the proceeds of this loan to
payments under the agreement(s) resulting from this IFB: Integrated Revenue
Management System (RAMP/5).
3. The National Agency for Fiscal Administration serves as the implementing agency
for the project now invites sealed bids from eligible Bidders for an integrated
Revenue Management System (RMS) for administering all the taxes, levies, and
social insurance contributions specified under Romanian Law (excluding customs
duties and excise taxes) – under a single-responsibility contract encompassing all
the necessary software and services (but excluding ICT hardware).
4. Bidding will be conducted using the International Competitive Bidding (ICB)
procedures in accordance with the World Bank’s Guidelines: Procurement under
IBRD Loans and IDA Credits. It is open to all Bidders from eligible source
countries as defined in the Guidelinesthat meet the following minimum
qualification criteria.
A. The Bidder MUST demonstrate that within the seventy-two months prior to bid
submission (i.e. years 2010, 2011, 2012, 2013, 2014 and 2015) it has successfully
implemented the bid Revenue Management System (RMS) software product
(including previous versions) for at least one (1) integrated revenue management
system (covering minimally personal and enterprise income taxes, value-added or
sales taxes) with the implementation covering at leastone million (1,000,000)
taxpayer accounts. The successful implementation shall be documented by an
Operational Acceptance Certificate issued by the previous Purchaser of the bid
RMS product. In the case of a joint venture, the Partner in Charge MUST
demonstrate the above successful experience. Any other JV partner(s) MUST
demonstrate that within the seventy-two monthsprior to bid submission (i.e. years
2010, 2011, 2012, 2013, 2014 and 2015) it has participated in the successful
implementation of at least one (1) financial transactions/management system (e.g.,
social insurance, treasury, customs, banking, etc.) with at least five hundred
thousand (500,000) accounts.
66 Section III: Sample Bidding Forms

B. The Bidder must document having ready access to at least two million(2,000,000)
Euro equivalent in liquid assets (bank balances, unencumbered securities, lines of
credit etc.). In the case of a joint venture, the requirement can be met by the sum
of the JV partners' contribution or by the JV itself.
C. The Bidder must prove that in the last three (3) financial years prior to the bid,
generated an overall turnover of no less than ten million (10,000,000) Euro). In
the case of a joint venture, the requirement can be met by the sum of the JV
partners' contribution or by the JV itself.
5. Interested eligible Bidders may obtain further information from Mrs. Daniela
Manoli – Project Manager of RAMP Project Management Unit; Agency for Fiscal
Administration; 17, Apolodor Street, Sector 5, Bucharest, Romania; Phone: +4021
387 20 57 or +4021 38720 58; Facsimile: +4021 319 96 71; E-mail:
[email protected]. A pre-bid meeting which potential bidders may attend
will be held 10:00 local time on January 20th, 2016 at 17, Apolodor Street
(“Registratura” Entrance (ground floor)), Sector 5, Bucharest .
6. A complete set of bidding documents in the English Languagemay be downloaded
from www.anaf.ro/RAMP. The Bidders should register their contact information
(e-mail and mailing address) by sending an e-mail to: [email protected].
The same e-mail address should be used for submitting any clarification
questions.  Registration is necessary to receive answers to clarification questions
as well as addenda to the bidding documents (if any). The downloadable version
of the bidding documents, and any addenda to it, will be the binding one.
7. A Two-stage Bidding Procedure will be adopted and will proceed as follows:
(a) The First Stage Technical-Only Bid will consist of a technical bid only,
without any reference to prices, and a list of any deviations to the technical
and commercial conditions set forth in the Bidding Documents or any
alternative technical solutions a Bidder wishes to offer, and a justification
therefore, always provided that such deviations or alternative solutions do
not change the basic requirements specified in the Bidding Documents.
Following evaluation by the Purchaser of the First Technical-Only Stage
Bids, the Purchaser will invite each Bidder who adequately meets the
minimum acceptable qualification criteria and who has submitted a
sufficiently technically responsive First Stage Bid to a Clarification
Meeting(s), during which the Bidder’s bid will be reviewed and all required
amendments, additions, deletions and other adjustments will be noted and
recorded in a Memorandum. The Purchaser reserves the right to decline to
invite a Bidder to submit a Second Stage Combined Technical and Financial
Bid, if the Bidder’s First Stage Technical-Only Bid contains departures from
the Purchaser’s requirements in such numbers or such nature that it cannot
be reasonably expected that it can become a fully responsive bid within the
time frame of the two-stage process. Other suitably qualified and eligible
Bidders should receive invitations to submit Second Stage Bids.
(b) The Second Stage Combined Technical and Financial Bid will consist of:
(i) an updated technical bid incorporating all changes required by the
Purchaser as recorded in the Memorandum to the Clarification Meeting(s) or
as necessary to reflect any amendment to the Bidding Documents issued
subsequent to submission of the First Stage Bid; and (ii) a commercial bid.
Section III: Sample Bidding Forms 67

8. First Stage Technical-Only Bids must be delivered to the address below at or before
10:00 local time on February 25th, 2016. Second stage bids will be opened in the
presence of the Bidders’ representatives who choose to attend at the time and date
and at the address given in the letter of invitation to submit Second Stage Combined
Technical and Financial Bids. Any Second Stage Combined Technical and
Financial Bid received by the Purchaser after the bid submission deadline will be
rejected and returned unopened to the Bidder. Second Stage Combined Technical
and Financial Bids need to be securedby a Bid Security of at least three hundred
twenty thousand Euro (320,000 €) equivalent in a freely convertible currency.
9. The attention of prospective Bidders is drawn to: (i) the fact that they will be
required to certify in their bids that all software is either covered by a valid license
or was produced by the Bidder; and (ii) that violations are considered fraud which,
among other remedies, can result in the ineligibility to be awarded World Bank-
financed contracts
Mrs. Daniela Manoli – Project Manager of RAMP Project Management Unit;
Agency for Fiscal Administration;
17, Apolodor Street, Sector 5, Bucharest, Romania;
Phone: +4021 387 20 57 or +4021 38720 58;
Facsimile: +4021 319 96 71;
E-mail: [email protected]
68 Section III: Sample Bidding Forms

(letterhead of the Purchaser)

1.2 Invitation for Bids (IFB) – Second Stage Combined Technical and
Financial Bid
[ insert: Issuing date of the IFB ]
Romania
Revenue Administration Modernization Project (RAMP)
An integrated Revenue Management System (RMS) for administering all the taxes,
levies, and social insurance contributions specified under Romanian Law (excluding
customs duties and excise taxes) – under a single-responsibility contract encompassing
all the necessary software and services (but excluding ICT hardware)
No. 8261 – RO
Integrated Revenue Management System
RAMP/5

To: [Name and address of the Bidder]

Dear Ladies and/or Gentlemen,

1. We hereby inform you that you are invited to submit a sealed Second Stage Bid
for the execution and completion of the cited contract for which you submitted a
First Stage Bid on [  insert: date of submission of First Stage Bid ], that was
reviewed during the Clarification Meeting(s) held on [ insert: date(s) ] and has
been found technically responsive.
2. Your Second Stage Bid should include an updated technical and commercial bid
based on [ if appropriate, insert: “attached amendment and” ] the
modifications, if any, listed in the “Changes Required Pursuant to the First Stage
Evaluation” Annex to the Memorandum of the Clarification Meeting(s) held with
you on [ insert: date(s) ].
3. Second Stage Bids should be submitted [ insert: time, date and address for
Second Stage Bid submission ] and will be opened in the presence of the
Bidder’s representatives who choose to attend at [  insert: time, date and address
for Second Stage Bid opening ].
4. Second Stage Bids should remain valid for [  insert: number (N) of days ] after
the date of bid opening prescribed above. Accordingly, each bid should be valid
through [ insert: the actual date of the expiration of the bid validity period (i.e.,
X days after the date of bid opening) ].
Section III: Sample Bidding Forms 69

5. Bids need to be secured by a Bid Security of at least three hundred twenty

thousand Euro (320,000 €) equivalent in a freely convertible currency.
6. The currency chosen for the purpose of converting to a common currency is:
Euro. The source of exchange rate is: National Bank of Romania
(http://www.bnro.ro/Home.aspx). The date of exchange rate determination is: the
last business day prior to the bid submission deadline. In case that no exchange
rates are available on this date from the source indicated above, the latest available
exchange rates from the same source prior to this date will be used.
8. Please confirm receipt of this letter immediately in writing by electronic mail,
cable, fax or telex. If you do not intend to bid, we would appreciate being so
notified again in writing at your earliest opportunity.

Yours truly,

Authorized signature:

[ insert: Name and title  ]

[ insert: name of Purchaser ]

ENCLOSURE [ if appropriate, insert: “Amendment(s) and” ] Memorandum of

“Changes Required Pursuant to First Stage Evaluation”)
70 Section III: Sample Bidding Forms

2. BID SUBMISSION FORMS

Notes to Bidders on Bid Submission Forms

Bid Submission Form: In addition to being the place where official confirmation
of the bid price and the currency breakdown (in case of a Combined Technical and
Financial Bid), the completion date(s), and other important Contract details are expressed,
the Bid Submission Form is also used by the Bidder to confirm - in case adjudication
applies in this Contract - its acceptance of the Purchaser’s proposed Adjudicator, or to
propose an alternative. If the bid is being submitted on behalf of a Joint Venture, it is
essential that the Bid Submission Form be signed by the partner in charge and that it be
supported by the authorizations and power of attorney required pursuant to ITB Clause
6.2. Given widespread concern about illegal use of licensed software, Bidders will be
asked to certify in the Bid Submission Form that either the Software included in the bid
was developed and is owned by the Bidder, or, if not, the Software is covered by valid
licenses with the proprietor of the Software.
Section III: Sample Bidding Forms 71

2.1 Bid Submission Form – First Stage Technical-Only Bid

Date: [ Bidder insert: date of bid  ]
Loan/Credit No.: 8261 – RO
IFB: Integrated Revenue Management System RAMP/5
Contract: RAMP/5

To: Agency for Fiscal Administration; 17, Apolodor Street, Sector 5, Bucharest,
Romania
Dear Sir or Madam:
Having examined the Bidding Documents, including Addenda Nos. [ insert
numbers ], the receipt of which is hereby acknowledged, we, the undersigned, offer to
supply, install, achieve Operational Acceptance of, and support the Information System
under the above-named Contract in full conformity with the said Bidding Documents.
We confirm that if you invite us to attend a Clarification Meeting(s) for the
purpose of reviewing our First Stage Bid at a place and date of your choice, we will
endeavor to attend this/these meeting(s) at our own cost, and will duly note the
amendments and additions to, and omissions from, our First Stage Bid that you may
require. We accept that we alone carry any risk for failing to reach clarification of our bid
in case this failure is due to our inability to attend duly scheduled Clarification
Meeting(s).
We undertake, upon receiving your written invitation, to proceed with the
preparation of our Second Stage Bid, updating the First Stage Bid in accordance with the
requirements, if any, specified in (a), the memorandum, specific for our First Stage Bid,
titled “Changes Required Pursuant to First Stage Evaluation” and any updates to this
memorandum, and (b), Addenda to the Bidding Documents issued together or after the
invitation for the second bidding-stage. The Second Stage Bid will also include our
commercial bid in accordance with the requirements of the Bidding Documents for
Second Stage Bids, for performing the Information System in accordance with our
updated technical bid.
We accept the appointment of Shanti P. Namballaas the Adjudicator.
[ and delete the following paragraph, or, as appropriate, delete the above and
include the following, or, if no Adjudicator is stated in the Bid Data Sheet,
delete both the above and the following ]
We do not accept the appointment of Shanti P. Namballaas the Adjudicator, and
we propose instead that [ insert: name ] be appointed as Adjudicator, whose résumé and
hourly fees are attached.
We propose [ insert: organization ]as the Appointing Authority.
We hereby certify that the Software offered in this bid and to be supplied under
the Contract (i) either is owned by us, or (ii) if not owned by us, is covered by a valid
license from the proprietor of the Software.
We, along with any of our subcontractors, suppliers, consultants, manufacturers,
or service providers for any part of the contract, are not subject to, and not controlled by
any entity or individual that is subject to, a temporary suspension or a debarment imposed
72 Section III: Sample Bidding Forms

by a member of the World Bank Group or a debarment imposed by the World Bank
Group in accordance with the Agreement for Mutual Enforcement of Debarment
Decisions between the World Bank and other development banks. Further, we are not
ineligible under the Purchaser’s country laws or official regulations or pursuant to a
decision of the United Nations Security Council.
We agree to abide by this First Stage Bid, which, in accordance with ITB Clauses
13 and 14, consists of this letter (First Stage Bid Form) and the enclosures listed below.
Together with the above written undertakings, the bid should remain binding on us. We
understand that we may withdraw our bid, or any alternative bid included in it, at any
time by so notifying you in writing. However, we accept that if invited to the second
bidding-stage, once we have submitted a Second Stage Bid, this bid (and the parts of the
First Stage Bids it includes and updates) can only be withdrawn before the deadline for
submission of Second Stage Bids, and only by the formal Second Stage Bid withdrawal
procedure stipulated in the Bidding Documents.

Dated this [ insert: ordinal ]day of [ insert: month ],[ insert: year ].

Signed:
Date:

In the capacity of [ insert: title or position ]

Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]

ENCLOSURES:
Signature Authorization [plus, in the case of a Joint Venture Bidder, list all other
authorizations pursuant to ITB Clause 6.2]
Attachment 1 Bidder’s Eligibility
Attachment 2 Bidder’s Qualifications (including Manufacturer’s Authorizations
and Subcontractor Agreements if and as required)
Attachment 3 Proposed Subcontractors
Attachment 4 Intellectual Property (Software and Materials Lists)
Attachment 5 Conformity of the Information System to the Bidding Documents
Attachment 6 Deviations
[ list any further attachments or other enclosures ]
Section III: Sample Bidding Forms 73

Bid Table of Contents and Checklist

Note: Bidders should expand and (if appropriate) modify and complete the following table. The
purpose of the table is to provide the Bidder with a summary checklist of items that must
be included in the First Stage Bid, as described in ITB Clauses 13 and 14. It also
provides a summary page reference scheme to ease and speed the Purchaser’s bid
evaluation process.

item present: y/n page no.

First Stage Technical-Only Bid Submission Form..........

Signature Authorization (for Joint Ventures additionally

including the authorizations listed in ITB Clause 6.2)....

Attachment 1: Bidder’s Eligibility ..................................

Attachment 2: Bidder’s Qualifications ...........................

Manufacturer’s Authorizations..................................

Subcontractor’s Agreements......................................

Attachment 3: Proposed Subcontractors..........................

Attachment 4: Intellectual Property.................................

Attachment 5: Conformity of the Information System to

the Bidding Documents....................................................

Attachment 6: Deviations................................................

..........................................................................................
74 Section III: Sample Bidding Forms

2.2 Bid Submission Form Second Stage Combined Technical and

Financial Bid
Date: [ Bidder insert: date of bid  ]
Loan/Credit No.: 8261 – RO
IFB: Integrated Revenue Management System RAMP/5
Contract: RAMP/5

To: Agency for Fiscal Administration; 17, Apolodor Street, Sector 5, Bucharest,
Romania
Dear Sir or Madam:
Having examined the Bidding Documents, the Addenda issued during the first
bidding-stage, Addenda Nos. [ insert: numbers ] issued with or after the Invitation for
Bids – Second Stage, the receipt of which is hereby acknowledged, as well as the
requirements listed in the memorandum titled “Changes Required Pursuant to First Stage
Evaluation” specific to our First Stage Bid, and any updates to this memorandum, we, the
undersigned, offer to supply, install, achieve Operational Acceptance of, and support the
Information System under the above-named Contract in full conformity with the said
Bidding Documents, Addenda and memorandum, for the total sum of:
plus [  insert: amount of currency A
in words ]
[ as appropriate, add the following ]
plus [ insert: amount of currency B
in words ]
plus [ insert: amount of currency C
in words ]

or such other sums as may be determined in accordance with the terms and conditions of
the Contract.
We undertake, if our bid is accepted, to commence work on the Information
System and achieve Installation and Operational Acceptance within the respective times
stated in the Bidding Documents.
If our bid is accepted, we undertake to provide a performance security in the form,
in the amounts, and within the times specified in the Bidding Documents.
[  As appropriate, include or delete the following paragraph ]
We confirm our agreement with the appointment of Shanti P. Namballa from, as
applicable, the Bid Data Sheet or the memorandum titled “Changes Required Pursuant
to First Stage Evaluation  ]as the Adjudicator.
We do not accept the appointment of Shanti P. Namballa from the memorandum
titled “Changes Required Pursuant to First Stage Evaluation” ]as the Adjudicator, and
we propose instead that [ insert: name ] be appointed as Adjudicator, whose résumé and
hourly fees are attached.
Section III: Sample Bidding Forms 75

We propose [ insert: organization ] as the Appointing Authority.

We hereby certify that the Software offered in this bid and to be supplied under
the Contract (i) either is owned by us, or (ii) if not owned by us, is covered by a valid
license from the proprietor of the Software.
We, along with any of our subcontractors, suppliers, consultants, manufacturers,
or service providers for any part of the contract, are not subject to, and not controlled by
any entity or individual that is subject to, a temporary suspension or a debarment imposed
by a member of the World Bank Group or a debarment imposed by the World Bank
Group in accordance with the Agreement for Mutual Enforcement of Debarment
Decisions between the World Bank and other development banks. Further, we are not
ineligible under the Purchaser’s country laws or official regulations or pursuant to a
decision of the United Nations Security Council.
We agree to abide by this bid, which, in accordance with ITB Clauses 25 and 28,
consists of this letter (Second Stage Bid Form) and the enclosures listed below, for a
period of [ insert: number from Invitation for Bids -- Second Stage ]days from the date
fixed for submission of bids as stipulated in the Invitation for Bids -- Second Stage or
subsequent Addenda to the Bidding Documents, and it should remain binding upon us
and may be accepted by you at any time before the expiration of that period.
Commissions or gratuities, if any, paid or to be paid by us to agents relating to this
bid, and to Contract execution if we are awarded the Contract, are listed below:
Name and Address Amount and Purpose of
of Agent Currency Commission or
Gratuity

etc. [if none, state “none”]

Until the formal final Contract is prepared and executed between us, this bid,
together with your written acceptance thereof and your notification of award, should
constitute a binding contract between us. We understand that you are not bound to accept
the lowest or any bid you may receive.

Dated this [ insert: ordinal ]day of [ insert: month ],[ insert: year ].

Signed:
Date:

In the capacity of [ insert: title or position ]

Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]
76 Section III: Sample Bidding Forms

ENCLOSURES:
Signature Authorization [plus, in the case of a Joint Venture Bidder, list all other
authorizations pursuant to ITB Clause 6.2]
Bid Security
Confirmation of willingness to propose (if requested) a contract for continued
Technical Support Services following the conclusion of the Warranty Period (as
per the Bid Data for ITB 26.2)
Informational table on COTS licensing (units, quanties, sub-totals)
Attachment 1 Bidder’s Eligibility
Attachment 2 Bidder’s Qualifications (including Manufacturer’s Authorizations
and Subcontractor Agreements if and as required)
Attachment 3 Proposed Subcontractors
Attachment 4 Intellectual Property (Software and Materials Lists)
Attachment 5 Conformity of the Information System to the Bidding Documents

[ if appropriate, specify further attachments or other enclosures ]

Section III: Sample Bidding Forms 77

Second Stage Bid Table of Contents and Checklist

Note: Bidders should expand and (if appropriate) modify and complete the following
table. The purpose of the table is to provide the Bidder with a summary checklist
of items that must be included in the Second Stage Bid as described in ITB Clause
25 and 28, in order for the bid to be considered for Contract award. The table also
provides a summary page reference scheme to ease and speed the Purchaser’s bid
evaluation process.

Item present: y/n page no.

Second Stage Combined Technical and Financial Bid

Submission Form.............................................................

Signature Authorization (for Joint Ventures additionally

including the authorizations listed in ITB Clause 6.2)....

Bid Security.....................................................................

Confirmation of willingness to propose (if requested) a

contract for continued Technical Support Services
following the conclusion of the Warranty Period (as per
the Bid Data for ITB 26.2)...............................................

Informational table on COTS licensing (units, quanties,

sub-totals).........................................................................

Informational table on daily reference fees for the

specialist profiles (as per ITB 26.6)

Attachment 1: Bidder’s Eligibility ..................................

General Information...................................................

Attachment 2: Bidder’s Qualifications ...........................

General Information Systems Experience Record.....

Particular Information Systems Experience Record. .

Details of Contracts of Similar Nature and

Complexity.................................................................

Past Performance Reference......................................

Current Contract Commitments / Work in Progress..

Financial Capabilities.................................................
78 Section III: Sample Bidding Forms

Litigation History.......................................................

Manufacturer’s Authorizations..................................

Subcontractor’s Agreements......................................

Attachment 3: Proposed Subcontractors..........................

Attachment 4: Intellectual Property.................................

Attachment 5: Conformity of the Information System to

the Bidding Documents....................................................

..........................................................................................
Section III: Sample Bidding Forms 79

3. BID SECURING FORMS

Notes to Bidders on working with the Bid Securing Forms

As per BDS for ITB Clause 29 the Bidder should do so in accordance with the
type and details specified in the same ITB/BDS Clause, either using the form(s) included
in these Sample Forms or using another form acceptable to the Purchaser. If a Bidder
wishes to use an alternative form, it should ensure that the revised format provides
substantially the same protection as the standard format; failing that, the Bidder runs the
risk of rejection for commercial non-responsiveness.
80 Section III. Sample Bidding Forms

3.1 Bid Security (Bank Guarantee)

[ Guarantor letterhead or SWIFT identifier code]

Beneficiary: National Agency for Fiscal Administration; 17, Apolodor Street, Sector 5,
Bucharest, Romania

IFB No:RAMP/5
Date:[ insert: date ]

BID GUARANTEE No.:[ insert: Bid Guarantee Number ]

Guarantor: [insert: name and address of place of issue, unless indicated in the
letterhead]
We have been informed that [ insert: name of the Bidder, which in the case of a joint
venture shall be the name of the joint venture (whether legally constituted or
prospective) or the names of all members thereof] (hereinafter called "the Applicant")
has submitted to the Beneficiary itsbid (hereinafter called "the Bid") for the execution of
[ insert: name of contract ] under Invitation for Bids No. RAMP/5.
Furthermore, we understand that, according the Beneficiary's conditions, bids must be
supported by a bid guarantee.
At the request of the Applicant, we as Guarantor, hereby irrevocably undertake to pay the
Beneficiary any sum or sums not exceeding in total an amount of [ insert: amount in
figures ] ([ insert: amount in words ]) upon receipt by us of the Beneficiary’s
complyingdemand,supported by the Beneficiary’s statement, whether in the demand itself
or a separate signed document accompanying or identifying the demand, stating that
either the Applicant:
(a) has withdrawn the Bid during the period of bid validity set forth in the Applicant’s
Letter of Bid (“the Bid Validity Period”), or any extension thereto provided by the
Applicant; or
(b) having been notified of the acceptance of the Bid by the Beneficiary duringthe Bid
Validity Period or any extension thereto provided by the Applicant, (i) has failed
to execute the Contract Agreement, or (ii) failed to furnish the performance
security in accordance with the Instructions to Bidders(“ITB”) of the
Beneficiary’s bidding document.
This guarantee will expire: (a) if the Applicantis the successful bidder, upon our receipt of
copies of the contract signed by the Applicant and the performance security issued to the
Beneficiary in relation to such contract agreement; or (b) if the Applicantis not the
successful bidder, upon the earlier of (i) our receipt of a copy of the Beneficiary's
notification to the Applicant of the results of the bidding process; or (ii) twenty-eight days
after the end of the Bid Validity Period.
Consequently, any demand for payment under this guarantee must be received by us at
the office on or before that date.
This guarantee is subject to the Uniform Rules for Demand Guarantees(URDG) 2010
Revision, ICC Publication No. 758.
_____________________________
[Signature(s)]
Note: All italicized text is for use in preparing this form and shall be deleted from the final product.
82 Section III. Sample Bidding Forms

3.2 Bid Security (Bid Bond)

BOND NO.:[ insertNumber ]

BY THIS BOND, [ insert: name of Bidder ] as Principal (hereinafter called “the
Principal”), and [ insert: name, legal title, and address of surety ], authorized to transact
business in Romania, as Surety (hereinafter called “the Surety”), are held and firmly
bound unto Agency for Fiscal Administration as Obligee (hereinafter called “the
Purchaser”) in the sum of [ insert amount of Bond in currency, figures and words ]1, for
the payment of which sum, well and truly to be made, we, the said Principal and Surety,
bind ourselves, our successors and assigns, jointly and severally, firmly by these presents.
WHEREAS the Principal has submitted a written Bid to the Purchaser dated the[ insert:
ordinal  ] day of [ insert: month ],[  insert: year ], for the execution of [ insert: name of
contract ] (hereinafter called "the Bid”).
NOW, THEREFORE, THE CONDITION OF THIS OBLIGATION is such that if the
Principal:
(a) has withdrawn its Bid during the period of the Bid's validity specified in the
Principal’s Letter of Bid (“the Bid Validity Period”), or any extension thereto
provided by the Principal; or
(b) having been notified of the acceptance of the Bid by the Purchaser during the Bid
Validity Period or any extension thereto provided by the Principal: (i) failed to
execute the Contract Agreement, or (ii) has failedto furnish the Performance
Security in accordance with the Instructions to Bidders(“ITB”) of the Purchaser’s
bidding document;
then the Surety undertakes to immediately pay to the Purchaser up to the above amount
upon receipt of the Purchaser's first written demand, without the Purchaser having to
substantiate its demand, provided that in its demand the Purchaser shall state that the
demand arises from the occurrence of any of the above events, specifying which event(s)
has/have occurred.
The Surety hereby agrees that its obligation will remain in full force and effect up to and
including the date 28 days after the date of expiration of the Bid Validity Period set forth
in the Principal’s Letter of Bid or any extension thereto provided by the Principal.
IN TESTIMONY WHEREOF, the Principal and the Surety have caused these presents to
be executed in their respective names this [ insert: ordinal ] day of [ insert: month ],
[ insert: year ].

Principal: _______________________ Surety: _____________________________

[add Corporate Seal(s) (where appropriate)]
_______________________________ ____________________________________
[Signature] [Signature]
_______________________________ ____________________________________
[state: printed name and title] [state: printed name and title]

1
The amount of the Bond shall be denominated in the currency of the Purchaser’s country or the
equivalent amount in a freely convertible currency.
[Note to Bidders: Instructions on amount and currency can be found in the ITB Clause and BDS for
"Securing the Bid." Joint Ventures need to also ensure that their Bid Bond meets the requirements for Joint
Ventures as provided in the same Clause.]
 4. BIDDER’S ELIGIBILITY FORMS

Notes to Bidders on working with the Bidder Eligibility Forms

None.
 4.1 General Information Form

All individual firms and each partner of a Joint Venture that are bidding must complete the
information in this form. Nationality information should be provided for all owners or
Bidders that are partnerships or individually owned firms.
Where the Bidder proposes to use named Subcontractors for highly specialized components
of the Information System, the following information should also be supplied for the
Subcontractor(s).

1. Name of firm
2. Head office address
3. Telephone Contact
4. Fax Telex
5. Place of incorporation / registration Year of incorporation / registration

Nationality of owners¹
Name Nationality
1.
2.
3.
4.
5.
¹/ To be completed by all owners of partnerships or individually owned firms.
86 Section III. Sample Bidding Forms

5. BIDDER’S QUALIFICATION FORMS

Notes to Bidders on working with the Bidder Qualification Forms

The Forms in this subsection are aimed to elicit the necessary information on the
Bidder’s Qualifications as specified in the BDS for ITB Clause 6.1. It is essential that the
Bidder review the forms and submitted materials to ensure the information is adequate for the
Purchaser determine the Bidder’s Qualification on the basis of the documents.
Where the Bidder proposes to name Subcontractors to for key components of the
System (as identified in the BDS for ITB Clause 6.1 (a) and 6.1 (c)), Forms 5.1 through 5.5
should be provided for the named Subcontractors.
In accordance with ITB Clauses 6.1 (b) and (c), a Bidder may be required to submit,
as part of its bid, Manufacturer’s Authorizations in the format provided in the Bidding
Documents, and agreements by Subcontractors proposed for key services, for all items
specified in the Bid Data Sheet (i.e., where those Subcontractor’s qualifications will count
towards the qualifications of the Bidder). The content and format of the Manufacturer’s
Authorization must be followed closely. The format of the Subcontractor’s Agreements is
suggestive.
 5.1 General Information Systems Experience Record

Name of Bidder or partner of a Joint Venture

All individual firms and all partners of a Joint Venture must complete the information in this
form with regard to the management of Information Systems contracts generally. The
information supplied should be the annual turnover of the Bidder (or each member of a Joint
Venture), in terms of the amounts billed to clients for each year for work in progress or
completed, converted to U.S. dollars at the rate of exchange at the end of the period reported.
The annual periods should be calendar years, with partial accounting for the year up to the
date of submission of applications. This form may be included for Subcontractors only if the
Bid Data Sheet for ITB Clause 6.1 (a) explicitly permits experience and resources of (certain)
Subcontractors to contribute to the Bidder’s qualifications.
A brief note on each contract should be appended, describing the nature of the Information
System, duration and amount of contract, managerial arrangements, purchaser, and other
relevant details.
Use a separate page for each partner of a Joint Venture, and number these pages.
Bidders should not enclose testimonials, certificates, and publicity material with their
applications; they will not be taken into account in the evaluation of qualifications.
Annual turnover data (applicable activities only)
Year¹ Turnover US$ equivalent
1.
2.

3.
4.
5.

¹/ Commencing with the partial year up to the date of submission of bids

88 Section III. Sample Bidding Forms

5.2 Particular Information Systems Experience Record

Name of Bidder or partner of a Joint Venture

On separate pages, using the format of Form 5.3, the Bidder is requested to list contracts of a
similar nature, complexity, and requiring similar information technology and methodologies
to the contract or contracts for which these Bidding Documents are issued, and which the
Bidder has undertaken during the period, and of the number, specified in the BDS for ITB
Clause 6.1 (a). Each partner of a Joint Venture should separately provide details of its own
relevant contracts. The contract value should be based on the payment currencies of the
contracts converted into U.S. dollars, at the date of substantial completion, or for ongoing
contracts at the time of award.
 5.3 Details of Contracts of Similar Nature and Complexity

Name of Bidder or partner of a Joint Venture

Use a separate sheet for each contract.

1. Number of contract
Name of contract
Country
2. Name of Purchaser
3. Purchaser address
4. Nature of Information Systems and special features relevant to the contract for which the
Bidding Documents are issued
5. Contract role (check one)

Prime Supplier  Management Contractor  Subcontractor  Partner in a Joint

Venture
6. Amount of the total contract/subcontract/partner share (in specified currencies at completion, or
at date of award for current contracts)
Currency Currency Currency
7. Equivalent amount US$
Total contract: $_______; Subcontract: $_______; Partner share: $_______;
8. Date of award/completion
9. Contract was completed _____ months ahead/behind original schedule (if behind, provide
explanation).
10. Contract was completed US$ _________ equivalent under/over original contract amount (if over,
provide explanation).
11. Special contractual/technical requirements.
12. Indicate the approximate percent of total contract value (and US$ amount) of Information
System undertaken by subcontract, if any, and the nature of such Information System.
90 Section III. Sample Bidding Forms

5.3.1 Bidder Past Performance Reference

This Form should be filled in and signed by authorized representatives for each entity
that the Bidder/Joint Venture Partners has referenced as a successful implementation (as
per the requirements specified in Bid Data for ITB 6.1(a)(B)).
1. Number of contract Name of the Supplier
Name of contract
Country
2. Name of Purchaser
3. Purchaser address
4. Scope of Contract (software licenses, customization of applications, integration
services, hardware infrastructure, technical services provided, etc.)

5. Contract Price - Equivalent amount US$

6. Contract was completed _____ months ahead/behind original schedule (please

provide details).
7. Contract was completed US$ _________ equivalent under/over original contract
amount (please provide details).
8. Major issues during contract implementation (claims, disputes, failures, early
termination etc.)
9. Categories oftaxescovered by the RMS System (which was actually
implemented)
10. Major functionalities supported by the implemented System (registration,
reporting, online services, inspection, Business Intelligence, ...)
11. The average number of the Supplier’s staff involved in the implementation of the
System
12. An estimate of the workload (number of man-days) developed by Supplier
during the implementation
13. How would you rate the Supplier’s overall performance? Please select one of the
following:

[ ] Outstanding [ ] Very Good [ ] Adequate [ ] Unacceptable

14. Purchaser’s Authorized Representative(s)
Full Name:
Contact details:
Signature:
Date:

Note to the Supplier: the current format is only an indicative one; the Purchaser will
accept any other document or format as long as it duly presents the information asked
above.
92 Section III. Sample Bidding Forms

5.4 Summary Sheet: Current Contract Commitments / Work in

Progress

Name of Bidder or partner of a Joint Venture

Bidders and each partner to an Joint Venture bid should provide information on their current
commitments on all contracts that have been awarded, or for which a letter of intent or
acceptance has been received, or for contracts approaching completion, but for which an
unqualified, full completion certificate has yet to be issued.
Name of contract Purchaser, contact Value of outstandingEstimated completion
Average monthly
address/tel./fax Information System date invoicing over last six
(current US$ months
equivalent) (US$/month)
1.
2.
3.
4.
5.
etc.
 5.5 Financial Capabilities

Name of Bidder or partner of a Joint Venture

Bidders, including each partner of a Joint Venture, should provide financial information to
demonstrate that they meet the requirements stated in the BDS for ITB Clause 6.1 (a). Each
Bidder or partner of a Joint Venture should complete this form. If necessary, separate sheets
should be used to provide complete banker information. A copy of the audited balance sheets
should be attached.
Autonomous subdivisions of parent conglomerate businesses should submit financial
information related only to the particular activities of the subdivision.
Banker Name of banker
Address of banker

Telephone Contact name and title

Fax Telex
Summarize actual assets and liabilities in U.S. dollar equivalent (at the rates of exchange
current at the end of each year) for the previous five calendar years. Based upon known
commitments, summarize projected assets and liabilities in U.S. dollar equivalent for the next
two calendar years, unless the withholding of such information by stock market listed public
companies can be substantiated by the Bidder.
Financial Actual: Projected:
information in Previous five years Next two years
US$ equivalent
5 4 3 2 1 1 2
1. Total assets
2. Current assets
3. Total
liabilities
4. Current
liabilities
5. Profits before
taxes
6. Profits after
taxes
Specify proposed sources of financing, such as liquid assets, unencumbered real assets, lines
of credit, and other financial means, net of current commitments, available to meet the total
construction cash flow demands of the subject contract or contracts as indicated in the BDS
for ITB Clause 6.1 (a).
 94 Section III. Sample Bidding Forms

Source of financing Amount (US$ equivalent)

1.
2.
3.
4.

Attach audited financial statements—including, as a minimum, profit and loss account,

balance sheet, and explanatory notes—for the period stated in the BDS for ITB Clause 6.1 (a)
(for the individual Bidder or each partner of a Joint Venture).
If audits are not required by the laws of Bidders' countries of origin, partnerships and firms
owned by individuals may submit their balance sheets certified by a registered accountant,
and supported by copies of tax returns,
 5.9 Litigation History

Name of Bidder or partner of a Joint Venture

Bidders, including each of the partners of a Joint Venture, should provide information on any
history of litigation or arbitration resulting from contracts executed in the last five years or
currently under execution. A separate sheet should be used for each partner of a Joint
Venture.

Year Award FOR or Name of client, cause of litigation, and matter in Disputed amount
AGAINST dispute (current value, US$
Bidder equivalent)
96 Section III. Sample Bidding Forms

5.10 Manufacturer’s Authorization

Note: This authorization should be written on the letterhead of the Manufacturer and be signed by a
person with the proper authority to sign documents that are binding on the Manufacturer.

Invitation for Bids Title and No.: Integrated Revenue Management System RAMP/5

To: Mrs. Daniela Manoli – Project Manager of RAMP Project Management Unit.

WHEREAS [ insert: Name of Manufacturer ] who are official producers of [ insert: items
of supply by Manufacturer ] and having production facilities at [ insert: address of
Manufacturer ] do hereby authorize [ insert: name of Bidder or Joint Venture ] located at
[ insert: address of Bidder or Joint Venture ] (hereinafter, the “Bidder”) to submit a bid and
subsequently negotiate and sign a Contract with you for resale of the following Products
produced by us:

We hereby confirm that, in case the bidding results in a Contract between you and the Bidder,
the above-listed products will come with our full standard warranty.

Name [ insert: Name of Officer ] In the capacity of [ insert: Title of Officer ]

Signed ______________________________

Duly authorized to sign the authorization for and on behalf of: [ insert: Name of
Manufacturer ]

Dated this [ insert: ordinal ]day of [ insert: month ],[ insert: year ].

[add Corporate Seal (where appropriate)]
 5.11 Joint Venture Summary

Names of all partners of a Joint Venture

1. Partner in charge
2. Partner
3. Partner
4. Partner
5. Partner
6. etc.

Total value of annual turnover, in terms of Information System billed to clients, in US$
equivalent, converted at the rate of exchange at the end of the period reported:

Annual turnover data (applicable activities only; US$ equivalent)

Partner Form 3.5.2
Year 1 Year 2 Year 3 Year 4 Year 5
page no.
1. Partner in
charge
2. Partner
3. Partner
4. Partner
5. Partner
6. Etc.
Totals
98 Section III. Sample Bidding Forms

6. PROPOSED SUBCONTRACTOR FORMS

Notes to Bidders on working with the Proposed Subcontractor Forms

In accordance with ITB Clause 6.3, a Bidder must submit, as part of its bid, a list of
proposed subcontracts for major items of Technologies, Goods, and/or Services. The list
should also include the names and places of registration of the Subcontractors proposed for
each item and a summary of their qualifications.
 6.1 List of Proposed Subcontractors

Item Proposed Subcontractor Place of Registration &

Qualifications
100 Section III. Sample Bidding Forms

6.2 Subcontractor’s Agreement

Note: This agreement should be written on the letterhead of the Subcontractor and be signed by a
person with the proper authority to sign documents that are binding on the Subcontractor.

Invitation for Bids Title and No.: Integrated Revenue Management System RAMP/5

To: Mrs. Daniela Manoli – Project Manager of RAMP Project Management Unit.

WHEREAS [ insert: Name of Subcontractor ], having head offices at [ insert: address of

Subcontractor ], have been informed by [ insert: name of Bidder or Joint Venture ] located
at [ insert: address of Bidder or Joint Venture ] (hereinafter, the “Bidder”) that it will
submit a bid in which [ insert: Name of Subcontractor ] will provide [ insert: items of
supply or services provided by the Subcontractor ]. We hereby commit to provide the
above named items, in the instance that the Bidder is awarded the Contract.

Name [ insert: Name of Officer ] In the capacity of [ insert: Title of Officer ]

Signed ______________________________

Duly authorized to sign the authorization for and on behalf of: [ insert: Name of
Subcontractor ]

Dated this [ insert: ordinal ]day of [ insert: month ],[ insert: year ].

[add Corporate Seal (where appropriate)]
 7. INTELLECTUAL PROPERTY FORMS

Notes to Bidders on working with the Intellectual Property Forms

In accordance with ITB Clause 13.1 (c) (iv) and 25.1 (e) (iv), Bidders must submit, as
part of their bids, lists of all the Software included in the bid assigned to one of the following
categories: (A) System, General-Purpose, or Application Software; or (B) Standard or
Custom Software. Bidders must also submit a list of all Custom Materials. These
categorizations are needed to support the Intellectual Property in the GCC and SCC.
102 Section III. Sample Bidding Forms

7.1 Software List

(select one per item) (select one per item)

General-
System Purpose Application Standard Custom
Software Item Software Software Software Software Software
7.2 List of Custom Materials

Custom Materials
104 Section III. Sample Bidding Forms

8. CONFORMANCE OF INFORMATION SYSTEM MATERIALS

 8.1 Format of the Technical Bid

In accordance with ITB 14.2 and ITB 28.2, the documentary evidence of conformity
of the Information System to the Bidding Documents includes (but is not restricted to):

(a). The Bidder’s Preliminary Project Plan, including, but not restricted, to the topics
specified in the BDS for ITB Clause 14.2 and/or 28.2 (c). The Preliminary Project
Plan should also state the Bidder’s assessment of the major responsibilities of the
Purchaser and any other involved third parties in System supply and installation, as
well as the Bidder’s proposed means for coordinating activities by each of the
involved parties to avoid delays or interference.
(b). A written confirmation by the Bidder that, if awarded the Contract, it should accept
responsibility for successful integration and interoperability of all the proposed
Information Technologies included in the System, as further specified in the
Technical Requirements.
(c). Item-by-Item Commentary on the Technical Requirements demonstrating the
substantial responsiveness of the overall design of the System and the individual
Information Technologies, Goods, and Services offered to those Technical
Requirements.
In demonstrating the responsiveness of its bid, the Bidder must use the Technical
Responsiveness Checklist (Format). Failure to do so increases significantly the risk
that the Bidder’s Technical Bid will be declared technically non-responsive. Among
other things, the checklist should contain explicit cross-references to the relevant
pages in supporting materials included in the Bidder’s Technical Bid.
Note: The Technical Requirements are voiced as requirements of the Supplier and/or the
System. The Bidder’s response must provide clear evidence for the evaluation team to
assess the credibility of the response. A response of “yes” or “will do” is unlikely to
convey the credibility of the response. The Bidder should indicate that – and to the
greatest extent practical –how the Bidder would comply with the requirements if
awarded the contract. Whenever the technical requirements relate to feature(s) of
existing products (e.g., hardware or software), the features should be described and
the relevant product literature referenced. When the technical requirements relate to
professional services (e.g., analysis, configuration, integration, training, etc.) some
effort should be expended to describe how they would be rendered – not just a
commitment to perform the [cut-and-paste] requirement. Whenever a technical
requirement is for the Supplier to provide certifications (e.g., ISO 9001), copies of
these certifications must be included in the Technical Bid.
Note: The Manufacturer’s Authorizations (and any Subcontractor Agreements) are to be
included in Attachment 2 (Bidder Qualifications), in accordance with and ITB 13.1
(c)(ii) and ITB 25.1 (e)(ii).
Note: As a matter of practice, the contract cannot be awarded to a Bidder whose Technical
Bid deviates (materially) from the Technical Requirements – on any Technical
Requirement. Such deviations include omissions (e.g., non-responses) and responses
106 Section III. Sample Bidding Forms

that do not meet the requirement. Extreme care must be exercised in the preparation
and presentation of the responses to all the Technical Requirements.
(d). Supporting materials to underpin the Item-by-item Commentary on the Technical
Requirements (e.g., product literature, white-papers, narrative descriptions of
technical approaches to be employed, etc.). In the interest of timely bid evaluation
and contract award, Bidders are encouraged not to overload the supporting materials
with documents that do not directly address the Purchaser’s requirements.
(e). Any separate and enforceable contract(s) for Recurrent Cost items which the BDS for
ITB Clause 26.2 required Bidders to bid.

Note: To facilitate bid evaluation and contract award, Bidders encouraged to provide
electronic copies of their Technical Bid – preferably in a format that the evaluation
team can extract text from to facilitate the bid clarification process and to facilitate the
preparation of the Bid Evaluation Report.
 8.2 Technical Responsiveness Checklist

Note to Bidders: The following Checklist is provided to help the Bidder organize and
consistently present its Technical Bid. For each of the following Technical
Requirements, the Bidder must describe how its Technical Bid responds to each
Requirement. In addition, the Bidder must provide cross references to the relevant
supporting information, if any, included in the bid. The cross reference should identify
the relevant document(s), page number(s), and paragraph(s). The Technical
Responsiveness Checklist does not supersede the rest of the Technical Requirements (or
any other part of the Bidding Documents). If a requirement is not mentioned in the
Checklist that does not relieve the Bidder from the responsibility of including supporting
evidence of compliance with that other requirement in its Technical Bid. One- or two-
word responses (e.g. “Yes,” “No,” “Will comply,” etc.) are normally not sufficient to
confirm technical responsiveness with Technical Requirements.

1–Revenue Types

Tech. Require. No. Revenue Types. The System MUST embody a functional
1 model for ANAF’s administration all the taxes, duties, levies,
social contributions and deductions in the Romanian Tax
Code – including all functions distributed across:
Headquarters, Regional Offices, District/County Offices,
Municipal/Town/Communal Offices.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

2–Functional Scope

Tech. Require. No. Functional Scope. The System MUST provide fully
2 integrated automation support for the following business
segments:
 TAXPAYER REGISTRATION (TR)
 RETURNS PROCESSING (RP)
 PAYMENT PROCESSING (PP)
 TAXPAYER ACCOUNTS / LEDGER (AL)
 REFUNDS PROCESSING (RF)
 RECONCILIATION (RR)
108 Section III. Sample Bidding Forms

 REVENUE COLLECTION (RC)

 REVENUE ENFORCEMENT(RE)
 TAXPAYER AUDIT (AU)
 ANTI-FRAUD / CRIMINAL INVESTIGATION (FR)
 OBJECTIONS AND APPEALS (AP)
 REVENUE ACCOUNTING (AC)
 REVENUE RISK ANALYSIS (RM)
 INTERNAL AUDIT (IA)
 INTERNAL CONTROL (IC)
 MANAGEMENT INFORMATION / DECISION SUPPORT
(REP)
 TAXPAYER SERVICES INTERFACE (TS)
The System MUST provide full support for the following
general requirements, on all its business segments:
MUST interface and provide comprehensive operations
logs for tax audit, taxpayer audit, internal control and
internal audit. MUST push data in a timely manner to the
MIS for executive and operational reports, for the
dashboard of the Ministry of the Public Finances /
National Agency for Fiscal Administration, and for the
calculation of the key performance indicators. MUST
provide advanced reporting and notification of the
interested parties (internal control staff, ANAF
management, and other ANAF structures) regarding the
defined and approved revenue collection objectives, risks,
KPIs and targets. MUST generate all the administrative
documents legally specified. MUST interface with
ANAF’s Mass Printing Facility to print, mail and
distribute the administrative documents to the taxpayers.
MUST file the administrative documents (e.g.
notifications, etc.) in the taxpayer file in the Document
Management System. MUST provide interfaces for data
exchange with third party data sources, including format
conversion and data extraction functions. The System
MUST accept data from 3rd party sources at least in
following file formats: .TXT, .CSV, .XLS, .XLSX, .ODF,
.XML, .PDF (including intelligent forms and digitally
signed documents) etc. MUST implement multiple
currencies (i.e. at least Romanian New Leu and Euro) and
multiple denomination of the local currency (i.e.
Romanian Leu (ROL) and Romanian New Leu (RON)).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Taxpayer Registration (TR) – MUST support the following
2.1 business processes:

 TR01 – Initial Taxpayer Registration

 TR02 – Registration Maintenance

 TR03 – Registration Maintenance – update based on

return processing

 TR04 – Re-Classify Taxpayer

 TR05 – Inactivate / Reactivate / Radiate Taxpayer

(voluntary)

 TR06 – Inactivate Taxpayer (suo-moto) / Reactivate

Taxpayer

 TR07 – Managing Taxpayer Risk History and Profile

 TR08 – Taxpayer Registration Audit

The System MUST provide complete workflows for

business processes above. MUST implement a Taxpayer
Register for all the categories of taxpayers and the related
categories databases. MUST provide flexible interactive
functions for the tax officers for pre-filling, validation,
filling, verification, crosschecking, and correction of
taxpayers’ applications. MUST manage the Taxpayer
administrative information specific to all the states of
Taxpayer in relation to ANAF (i.e. new applicant,
registered, active, inactive, suspended, radiated, etc.,).
MUST verify and validate the taxpayer information with
ANAF and 3rd party public data sources (e.g. address and
postal codes catalogs, police records, taxpayer register,
other). MUST provide a user interface for the taxpayer
registration process on the Internet Portal, for pre-filling
the applications. MUST provide on-line and off-line
electronic filling of the applications with secure multipage
intelligent forms, able to attach multiple large support
110 Section III. Sample Bidding Forms

documents in digitized format in the Internet Portal.

MUST provide taxpayer assistance information on the
Internet Portal, to guide the applicants in the registration
process. MUST maintain the information about the
taxpayer for the taxpayer office via the Intranet Portal and
for the taxpayer via the Internet Portal, including logging
of the changes made in the taxpayer information. MUST
record all the changes in the Taxpayer status and interface
with Returns Processing (RP), Payment processing (PP),
Taxpayer Accounts / Ledger (AL), Refunds processing
(RF), Revenue Collection (RC), Revenue Enforcement
(RE), Taxpayer Audit (TA) and Revenue Risk
Management (RM) to activate, deactivate, recalculate,
set / reset the related tax obligations and their deadline for
collection. MUST provide notifications via e-mail to the
taxpayer and to the tax officer about all the changes made
in the taxpayer information. MUST enroll taxpayers in
the WebSpace, with unique user identity and security
information. MUST interface with the Trade Register via
the existing IT solution (Web-service) to complete the
registration of the taxpayer. MUST generate unique
TIN/PIN for each new taxpayer. MUST create taxpayer
records in the Taxpayer Register, including the initial
taxpayer risk history and profile data for all the new
taxpayers. MUST initialize the taxpayer risk history and
profile data for existing taxpayers from upload files
migrated from the legacy systems, containing historical
records. MUST calculate and record the risk score for all
the categories of taxpayers migrated from the legacy
systems, considering all the historical records and the new
scoring rules defined in the system at initialization.
MUST recalculate the risk score, when changes or
updates are made in the taxpayer’s registered information.
MUST create a taxpayer account in the taxpayer accounts
ledger. MUST build the taxpayer file with all the taxpayer
documents in digital format, proofed and signed
electronically, and stored in the Document Management
System. MUST provide taxpayer registration audit
(registration record validation), including but not limited
to notices to taxpayer registration auditors, sorting of the
incoming audit work by type, assigning registration
notices by area, registration audit prioritization,
scheduling the registration audit, assign auditor, register
audit result, update taxpayer risk history and profile
database.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:
Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Returns Processing (RP) – MUST support the following
2.2 business processes:

 RP01 – Pre-Filing Return Preparation Process

 RP02 – Receiving the tax / informative return

 RP03 – Pipeline Processing

 RP04 – Data verification / Matching

 RP05 – Converting Returns’ Data to Postable Format

The System MUST provide complete workflow for
Returns Processing, with a dialog on the tax returns
submitted via all the taxpayer communications channels
(i.e., digitally signed intelligent forms via the WebSpace,
paper signed documents presented over the counter or via
post mail, secured records via the IT interfaces for
taxpayers accounting systems, other applicable). MUST
assist the taxpayers with timely feed-back regarding the
returns submitted, including status of the return
processing, errors or unconformities to be corrected, etc.
MUST provide programmatic and manual tools to view,
add, correct, or change the returns submitted in the
System by the taxpayers. MUST provide history and
activity logs for all the user and System actions on the
returns. MUST store all the returns records in the returns
database. MUST convert all the returns and documents
into digitally signed .PDF files (with appropriate
112 Section III. Sample Bidding Forms

metadata) and file them in the Document Management

System. MUST provide unique identifiers for all the
returns and all the documents submitted for processing,
visible both to the taxpayer and the tax officers in the
System and via the WebSpace. MUST provide pre-filled
return forms to the taxpayer based the taxpayer’s
registration record. MUST support all the existing tax
returns formats and communications channels, as
described in the Informational Annex 4. MUST provide
error checks, with automatic and manual correction and
validation. MUST provide acknowledgements to the
taxpayer and to the tax officers via selected
communication channels. MUST refer to a tax officer in
case the automatic corrections are not possible. MUST
record the error types and exceptions for further
processing improvement. MUST provide revenue
statistics, work performance of the tax officers, other
statistics as appropriate. MUST populate the tax audit
folder of the taxpayer with at least the following
documents: an unique case number, the audit referral
document, the current state of the taxpayer account, the
returns documents for a number of years (e.g. the past
five years), the taxpayer’s risk history and profile rating.
MUST provide data verification / matching for VAT –
purchaser vs. supplier, based on the summary purchases
and supplier VAT invoices. MUST provide data
reconciliation for domestic and international transactions,
including operations between EU member states and
between EU Member states and third states.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:
Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Payments Processing (PP) – MUST support the following
2.3 business processes:

 PP01 – Payment by Taxpayer

 PP02–System Verification against Payments

 PP03 – Payment Reconciliation

The System MUST provide complete workflow of

Payments Processing, using at least the existing payments
channels via the State Treasury (unique channel): cash
payments (over the counter), bank transfers (from
commercial banks to the State Treasury Accounts),
treasury transfers (intra-Treasury transfers from the
existing taxpayer accounts with the State Treasury to the
collection accounts), and electronic funds transfers via the
commercial banks (including payments with banking
cards – debit and credit cards, and Internet banking).
MUST interoperate with the existing payment processing
system of the Romanian State Treasury (an application
called TREZOR). MUST implement the algorithms to
cover the fiscal obligations of the taxpayer from
consolidated payments made by taxpayer in its unique
account in the State Treasury or from individual payments
per each fiscal obligation. MUST process partial
payments and payments in excess of the fiscal
obligations. MUST identify all the payments with a
unique ID, correlated with the taxpayer, payment and
payment destination. MUST be able to offset a payment
against a payment due, fully or partially and indicate the
amount due correlated with the reference number of the
payment. MUST allow the user to link a specific
payment made to a specific payment due, in the case the
System is not able to make the link automatically. MUST
provide acknowledgements to the taxpayer of all the
payments done, via any of the valid communications
channels. MUST implement revenue accounting. MUST
track all the payments processed. MUST post all the
information about the payments in the WebSpace. MUST
interoperate with the tax refund functions of the System,
for adjustments against tax liabilities.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply
114 Section III. Sample Bidding Forms

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Taxpayer Accounts/Ledger (AL) – MUST support the

2.4 following business processes:

 AL01 – Post Liabilities to the Accounts

 AL02 – Filer / Stop Filer

 AL03 – Arrears Management

 AL04 – Recalculating Liabilities based on Amended

Return

 AL05 – Issuing Fiscal Certificates / Fiscal Records

 AL06 – Managing Arrears for and from Other

Institutions
The System MUST provide complete workflow of
accounting the fiscal credit and payment operations in a
unique account for each taxpayer. MUST provide
subaccounts for credits constructed by tax type (See
Informational Annex 2), for each taxpayer. MUST
provide a single taxpayer accounts ledger, accessible
based on the unique TIN/PIN of the taxpayer. MUST
implement flexible algorithms for posting liabilities to the
taxpayer accounts, for all the categories of revenues.
 MUST support adding new categories of revenues and
operations in the taxpayer accounts / ledger. MUST
provide complete logs of the operations in the ledger.
MUST provide several posting files formats to interface
with other systems for data exchange (e.g. systems or
functionalities for revenue enforcement, enforced
collections, Tax Court, Internal Audit, Internal Control,
Returns Processing, WebSpace, etc.). MUST implement
Directed (ex-officio) Returns on behalf of selected
categories of taxpayers. MUST acknowledge the
operation to the users at least via the WebSpace, e-mail,
operational reports and / or Short Messages (SMS). The
system MUST provide arrears management with a full
workflow to calculate interests and penalties, and on a
predetermined schedule, calculate interest on amounts
subject to interest and post this interest to the taxpayers’
current account for the affected tax type and by tax
period. MUST record in the taxpayer account the
necessary changes to enforce legal provisions of the
administrative documents and the relevant amounts.
MUST provide complete workflow and algorithms to
calculate the amounts for the amended returns, the
liabilities and penalties due, restitutions and refunds due,
etc. MUST interface with the risk analysis, taxpayer risk
history and risk profile to inform decisions for restitutions
and tax refunds (i.e., VAT refund). MUST interface with
the audit and fiscal inspection functions, to pass tax
refund cases to their workflows. MUST provide fiscal
certificates / income certificates / certificates for
budgetary obligations eligibility and other administrative
documents in digital format (on the WebSpace) and in
printed format to the taxpayers. MUST interface with the
IT systems of the other institutions ANAF is in relation
for the collection of taxes, contributions and / or
deductions. (See Informational Annex 2 and Annex 4).
MUST manage arrears and the enforced collection for the
other institutions that delegated the collection to ANAF.
MUST implement full workflow to centralize, consolidate
and redirect the payments received via the State Treasury,
on the behalf of the beneficiary institutions that has
delegated collection to ANAF (e.g., National Health
Insurance House, Social Pensions House, Social
Assistance House, etc.) – see Informational Annex 4.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:
116 Section III. Sample Bidding Forms

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Refunds Processing (RF) – MUST support the following
2.5 business processes:

 RF01 – Pre-refund Processing and Refund Claim

 RF02 – Processing of Refunds

 RF03 – Post-refund Processing

The System MUST provide complete workflow of
Refund Processing, from the refund / restitution demand
filling to the posting of refund for processing. MUST
process all the categories of refunds (i.e. provisional
refund, annual assessment refund or refund through a
court order). MUST implement all administrative
verifications (e.g. check of arrears, risk profile, risk score,
etc.) required to approve the restitutions and refunds.
MUST implement the hierarchy of approvals in the
workflow. MUST interoperate with the existing payment
processing system of the Romanian State Treasury (an
application called TREZOR) to operate refunds. MUST
facilitate online submission of refund claim and of the
supporting documents, secured with digital signature.
MUST post acknowledgements, errors, differences, and
results of the processing of the refund claim on the
WebSpace. MUST secure the submitted refunds claim
with read only format for the ANAF staff, to enforce that
all the changes and corrections needed are made on the
taxpayer end only. MUST generate letters for claim
approval and / or reject. MUST interface with the
WebSpace, ANAF’s Mass Printing Facility and any other
 communications channel (e.g. e-mail, SMS, etc.) to
communicate the decisions to the taxpayer in a timely
manner. MUST file the claim and all the support
documents in the taxpayer file in the Document
Management System.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Reconciliation (RR) – MUST support the following business
2.6 processes:

 RR01 – Third Party Data Repository / Matching

 RR02 – Posting Payments

 RR03– Reconciling Unpostable Payments

The System MUST provide complete workflow for
Reconciliation of payments with fiscal obligations.
MUST interface with the State Treasury for receiving and
posting the information about the payments and the
reconciled records. MUST implement all the calculations,
algorithms, and methods of reconciliations. MUST
interface with the WebSpace to post information (e.g.
notifications, revenue date, etc.) in the taxpayer private
space. MUST log all the actions and operations in the
taxpayer account, all the rules applied for reconciliation in
the order of execution, the results of the reconciliations,
118 Section III. Sample Bidding Forms

for audit purposes. MUST acknowledge the important

processing steps to the taxpayer (e.g. taxpayer notification
about an unpostable payment was credited in his account
and verification is needed). MUST allow manual checks
and corrections.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Revenue Collection (RC) – MUST support the following
2.7 business processes:

 RC01 - Automated Collections Notice

 RC02 - Collection Process Preparatory Activities

 RC03 – Collection Process

 RC04 – Alerts and MIS

The System MUST provide complete workflow to
generate collection administrative documents for all
taxpayers, all due payments and all periods of time
applicable, based on a pre-programmed schedule. MUST
generate users support documents for the revenue
collection activity, including but not limited to debt lists,
due payment notices, tax liabilities reports, taxpayer
history, list of cases, list of updates, collection lists /
reports grouped per taxpayer categories, tax offices,
 posting files for enforced collection, etc. MUST provide
integration with the Taxpayer Register, the taxpayer
accounts / ledger, Revenue Enforcement (RE) module,
Objections and Appeals (AP) module, Mass Printing Unit,
Management of Information System, Document
Management System, Case Management System,
WebSpace and other communication channels. MUST
provide system alerts for all the process deviations, errors,
unconformities and / or important events.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Revenue Enforcement (RE) – MUST support the following
2.8 business processes:

 RE01 – Automated Enforced Collection

 RE02 - Resource Planning
 RE03 - Payment Facilities
 RE04 – Guarantees
 RE05 - Precautionary Measures
 RE06 - Summons and Writs of Execution
 RE07 – Garnishments
 RE08 - Seizure of Goods
 RE09 - Transfer of Property
 RE10 - Auctions
 RE11 - Suspension of Enforcement Procedure
120 Section III. Sample Bidding Forms

 RE12 - Failure to Pay / Debt Write-off

 RE13 - Joint/Subsidiary liability
 RE14 - Collection from/to Other States
 RE15 - Enforced Collection Reporting
 RE16 – Release and Allocation of the Amounts
Collected by Enforcement
 RE17 – Insolvency
 RE18 – Referral to the Competent Bodies
 RE19 – Application of Fines by the Enforcement
Units
 RE20 – Write-off tax Records
 RE21 – Management and Sale of Seized Goods
 RE22 – Application of International Sanctions
The System MUST provide complete workflow for
Enforced Collection. The System MUST manage the
categories of taxes and budgetary obligations issued by
other institutions and sent to NAFA in order to be
recovered. MUST provide case management for each
enforced collection case. MUST provide unique ID
number for each enforced collection case. MUST
maintain a collections case folder for each enforced
collection case, identified by its unique ID number.
MUST implement an interface between taxpayer account,
Revenue Collection (RC) and the enforced collection, to
move automatically the collection folder from accounts
arrears management to enforced collection. MUST
maintain individual process performance and
administration data. MUST monitor all workflows.
MUST maintain arrears in enforced collection inventory.
MUST provide operational reports regarding the
performance of the enforced collection processes per each
local, county, regional office and consolidate national
wide, with filters and views. MUST provide real time
collections amounts secured (arrears collected and posted
to the accounts). MUST interface with IT systems of the
banks in Romania, to check the accounts the taxpayers
with arrears and to secure the amounts to be collected
from these taxpayers’ accounts. MUST prepare and
generate individual enforced collection administrative
documents that define how the debt is satisfied (e.g.
payment in installments, bank payment, garnishment,
seizure, another party held liable, insolvency, business
bankruptcy, other as per the case). MUST file all the
administrative documents in the taxpayer file in the
Document Management System. MUST interface with
the WebSpace and ANAF’s Mass Printing Facility to
communicate the administrative documents to the
taxpayer, via WebSpace, e-mail, SMS, postal mail and /
or other available communication channels. MUST
provide resource planning (annual and monthly plan) for
enforced collection activities for the department. MUST
provide automatic planning with manual adjustments of
the cases, staff, etc. MUST correlate estimated workload
for each case with the resources available. MUST
automatically recalculate workload estimates and adjust
plans. MUST maintain an enforced collection database.
MUST provide complete workflow for resource planning,
including case creation, case assignment, case manual
changes, case review and monitoring. MUST provide
complete workflow for payment facilities management,
with individual cases per each taxpayer. MUST define,
parameterize and change the legal conditions when
payment facilities may be granted and under which
conditions. MUST provide global and individual
configurations of the payment facilities conditions, to be
adjusted globally as per the debt collection strategy.
MUST integrate with the Risk Scoring Module to sort the
taxpayer and all type of revenue enforcement cases
(including payment facilities) according to the criteria,
parameters, profiles and benchmarks designed by ANAF
at the national, regional and county level. MUST
interface with the taxpayer account to process the requests
for payment facilities. MUST provide payment requests
with intelligent documents using the same technology as
the tax returns, the same security features (digital
signature, etc.), and capabilities to attach supporting
documents. MUST provide online requests processing in
the WebSpace and manual processing over the counter or
via postal mail. MUST acknowledge the status of the
payment facilities requests processing to the taxpayer and
the tax officers in charge with the case via the valid
communications channels. MUST provide flexible
parameterization for the eligibility checks, guarantee
amounts, risk ladder, automatic approval / refusal
conditions, interest and penalties calculations, installment
calculation, etc. MUST provide complete guarantees
management workflow, including options management
and guarantees in kind with correlated values, cash
guarantees, and others as per the case. MUST provide a
full workflow to manage the precautionary measures
applied to a taxpayer in enforced collection, including but
not limited to legal due notification, patrimonial
evaluation, patrimonial seizure or garnishment. MUST
provide a complete workflow to manage the summons
and the writs of execution, with all the necessary legal
and operational steps. MUST interface with ANAF’s
Mass Printing Facility to print, mail and distribute the
122 Section III. Sample Bidding Forms

administrative documents by postal mail with

confirmations of receipt. MUST provide a complete
workflow to manage garnishments, from the
identifications of the taxpayers under garnishment
procedure, to (but not limited to) identification of their
bank/treasury accounts (issue and send by electronic
means of the garnishment orders, confirmations of the
execution of the garnishments, in full or partial, from one
or more accounts, from one or more than one bank, etc.),
or third parties, etc. MUST provide a complete workflow
and set of functions (“instruments”) to manage the seizure
of goods for enforced collection, with all the legal binding
steps and procedures. MUST maintain inventories of
seized goods, and the deposit conditions. MUST extract
relevant information about the patrimony of the taxpayer
in default from its financial statements and balance sheets,
from the other public registers (cadastre, car register,
etc.). MUST manage the physical inspections and
evaluations of the immobile goods in scope, to assign
custodians, or other. MUST manage the goods as
individual items or in lots. MUST manage the transfer of
properties, with a complete workflow including at least
the approval and/or the rejection of the transfer, the debt
settling, the recording of the proceedings, the duly legal
notifications. MUST manage mortgage information
related to the goods in scope for enforcement. MUST
manage a pipeline of sale procedures for the good seized
for liquidation of tax debts, including the public auctions
preparation and follow-up. MUST interface with the
WebSpace and the Internet Portal to post public seizure,
sales and other public notifications. MUST manage the
replacement of the seized goods and / or other activities
related to the goods seized. MUST provide a complete
workflow for the auctions (sale of seized goods) including
but not limited to inventory of the goods seized,
evaluation of the goods, update of the seized goods
database, internal and external evaluations, preparation of
the documents for the sale of the goods, management of
the pre-auction proceedings, public information,
verifications of the bidder’s, updates of the risk history for
the taxpayer, the bidders and the buyer(s), bidding
proceeding, auction closing (with/without success),
contracting with the winner of the bid, management of the
bid bonds, and other guarantees, follow-up with the
payments and the transfer of the goods. MUST update
the taxpayer file in the Document Management System
with all the administrative documents related to the
auction (sale) of the seized goods. MUST provide a
complete workflow to release and allocate the amounts
collected by enforcement, case-by-case, good by good,
procedure by procedure. MUST interface with the
communications channels to notify all the interested
parties about the amounts resulted from enforced
collection, the existence of other debts, and all the legal
procedures. MUST provide collected amounts
distribution, according to the legal provisions in force.
MUST manage the amounts left undistributed, and
manage the restitutions with duly legal taxpayer and
public notifications and legal proceedings. MUST
provide alternative workflow for suspension of the
enforcement procedures, with automatic and manual
steps. MUST provide complete workflows to manage the
case of failure to pay, using all the information in the
System and in the 3rd party data sources to analyze the
debt and the sources of income of the taxpayer to be used
to extinguish the debt. MUST provide workflow to
manage the insolvency situations and the recovery of the
bad debts from the taxpayer, from the joint liabilities, and
from other sources. MUST provide complete workflow
for insolvency proceedings from the notification of the
opening of the insolvency procedure to de-registration of
the taxpayer. MUST provide workflows to manage the
joint and or subsidiary liabilities, including but not limited
to the identification of the jointly liable parties, data
analysis, prepare the hearings, prepare the supporting
information for the resolutions, manage the dialogue with
the liable parties, all the other legal proceedings related to
the debts extinguishing from the joint or subsidiary party.
MUST provide workflow for referring the enforcement
cases to the competent bodies, according to the legislation
in force. MUST implement all the legal steps and
proceedings in the Case Management, for each individual
case and for cases correlated (grouped). MUST provide
complete workflow for cases of fines applied by the
enforcement units, with all the legal steps and
proceedings. MUST provide complete workflow for the
write-off of the tax records impossible to collect (for the
legal or natural reasons). MUST implement a case
workflow for the collection from/to other states,
compliant with the international proceedings for bad debts
recovery from taxpayers with Romanian and international
tax residency, or from jointly responsible taxpayers.
MUST prepare the requests for information to other states
authorities, of the legal documents for the precautionary
measures for taxpayers from other states, of all the legally
binding communication (post mails, digitally signed
support documents, etc.). MUST report enforced
collection activities, with reports generated automatically
124 Section III. Sample Bidding Forms

or ad-hoc, in secured .PDF format, filed in the Document

Management System, containing statistics about the
collections activities, the allocation of the resources and
the collection results achieved by organizational unit,
area, and case category. MUST provide workflow to
manage the seized goods and its sales, fully implementing
the seized goods valuation procedures, with all the legal
and operational steps. MUST provide a workflow for
ANAF’s role in the application of the international
sanctions (i.e., seizure of the goods, garnishment, legally
due communications, etc.,) with respect to both resident
persons registered in Romania or non-residents from
states that Romania has agreements for the automatic
exchange of fiscal information. MUST capture the results
of the manual steps performed by the Ministry of External
Affairs regarding the legal compliance with applicable
international law. MUST interface with the WebSpace, to
post notifications for the residents enrolled in the
WebSpace. MUST deliver the notifications via all the
communication channels active for the tax payer which is
subject to an international sanction – post mail, e-mail,
WebSpace, SMS, etc. MUST provide back-office
statistical totalizer.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Taxpayer Audit (AU) – MUST support the following
2.9 business processes:

 AU01 – National Audit Planning

 AU02 – Auditee Selection

 AU03 – Auditor Selection

 AU04 – Audit Scheduling and Budgeting

 AU05 – Audit Preparation

 AU06 – Taxpayer Audit

 AU07 – Audit Resolution

 AU08 – Audit Quality Assurance

 AU09 – Monitoring
The System MUST provide configurable case
management and complete workflows for taxpayer audit,
including the fiscal verification, for each audit case by
type of taxpayer, including but not limited to companies,
high net worth individuals, small and medium businesses,
etc. MUST provide unique ID number for each audit case.
MUST maintain an audit case folder for each audit case,
identified by its unique ID number. MUST provide yearly
audit cycles, traceable individually, broken down by sub-
periods – quarters and months. MUST provide rules
setting for the audit plans, on all parameters, criteria,
profiles and benchmarks. MUST integrate with the Risk
Scoring Module to generate the selection of audit
candidates according to the criteria, parameters, profiles
and benchmarks designed by ANAF at the national,
regional and county level. MUST maintain the history
and results of the previous’ years audit activity. MUST
maintain historical records of all legacy audit cases
undertaken before the implementation of the System. The
Purchaser will be responsible to correct the data quality
problems regarding the historical records of all the audit
cases undertaken before the implementation of the
System, like missing information, multiple records, other
as per the case. MUST manage the resources and time
budget for audit for each yearly audit plan. MUST record
the audit time budget during the execution of the audit
mission, and consolidate it in an annual time budget
utilization report available for multi-year comparisons.
MUST provide workflow for taxpayer selection for audit,
in segment groups of revenue, types, industries, taxes, and
risk score. MUST provide workflow for the selection of
126 Section III. Sample Bidding Forms

individuals for audit, in segment of revenue, types, taxes,

and individual heritage and patrimony. MUST provide
workflow for the fiscal audit of the individuals using the
indirect fiscal verification method. MUST provide
management of the cases selected for audit, and the
allocation of the tax auditors per each case. MUST
provide functions to flag cases for discrepancies or
mismatch to be subjected for audit by authorized users.
MUST provide templates for administrative documents
like notifications to auditees, authorization letters, tax
audit forms, minutes of inspection, audit files, other as per
the case. MUST allow routing of the cases between
available and designated officers and staff members.
MUST perform automatic allocation of the cases
depending on the risk level and the workload both for
inspectors and tax inspectors structures. MUST allow
supplement / modification / replacement of the tax audit
team members for the audit missions. MUST provide
workflow for audit scheduling and time budgeting, based
on the availability of the human resources for audit
activities and the current priorities. MUST provide
flexible allocation of the cases in between the
organizational units to optimize the utilization of the
auditor resources. MUST provide individual work plans
for each auditor (user). MUST provide audit preparation
functionalities, including but not limited to selections, tax
audit file preparation, pre-filling of the tax audit file with
the information about the taxpayer and its history,
including for the audit of cases identified by ANAF and
for taxpayers in the registration process. MUST interface
with the Document Management System and other
information sources in the System to retrieve all auditee’s
related information and attach it into the audit case folder.
MUST provide complete workflow for tax audit mission,
including checklists, arithmetic and analysis tools (e.g.
automatic calculations of the accessories, penalties,
differences and additional amounts, etc.) to be used
during the audit execution. MUST provide workflow for
audit resolution, including all the procedural steps.
MUST log all the activity of the auditors, per each audit
case. MUST monitor and report the audit activity,
calculate quantitative and qualitative performance
indicators, collect statistical information and activity logs.
MUST file the audit file in the Document Management
System, with limited and secured access.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:
Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Anti-Fraud / Criminal Investigation (FR) – MUST support

2.10 the following business process:

 FR01 – Conducting Investigations

The System MUST provide case management and
complete workflow for conducting Anti-Fraud / Criminal
Investigations, including but not limited to allocation of
cases based on the risk criteria and the past experience,
skills, and qualifications of the staff members. MUST
interface with the other components of the Case
Management System to automatically suspend other
actions in ANAF organization when a case is allocated for
Anti-Fraud investigation. Automatic suspension of the
other actions within ANAF MUST not be visible to other
ANAF staff than the investigation team. MUST open
cases with unique ID, electronically update the case files,
manage a case status through its various states (e.g.
opened, assigned, pending, resolved). MUST
acknowledge to the investigations team and to the
organizational hierarchy the changes in the status of a
case (e.g. via e-mail and alerts in the System). MUST
provide case deadlines reminders and alerts, allow
changes in the milestones and extend the deadlines by an
authorized user. MUST do automatic posting of the tax
calculations in the taxpayer case file to the taxpayer’s
ledger if one exists, once established and confirmed,
without waiting for the case file to be closed. MUST
manage the closure of the case file in orderly manner.
MUST provide document templates (i.e. assessment
128 Section III. Sample Bidding Forms

notes), attach support documents in the case file, etc.

MUST allow supervisors and managers to monitor and
control activity, to comment or edit the submitted
assessment notes, to submit the documents to quality
control by approval (e.g. “marked as prepared”). MUST
implement version control for the case files and the
assessment notes.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Objections and Appeals (AP) – MUST support with legally
2.11 compliant and complete workflows the following business
processes:

 AP01 – Appeal / Application Submission

 AP02 – Appeal proceeding process

 AP03 – Appeal Notice / Order Generation

 AO04 – Appeal Rectification / revision processing

 AP05 – Record maintenance

 AP06 – Legal Case Management

 AP07 – Insolvency Management

The System MUST provide complete workflow and case
management files for appeals, disputes, reviews and other
legal proceeding, at multiple levels with standard steps for
processing, including but not limited to submit online
memorandum for appeal, review or application for
reference, re-certifications, check validity and eligibility
of the applications, based on predefined criteria at the
time of submission, etc. MUST link the appeal
application with the unique case number (e.g. assessment
case number / penalty order / cancellation order number,
etc.) against which the remedy is sought. MUST allow
logging (entry) of a dispute (objection or appeal)
manually. MUST allow the ANAF staff members to post
comments on ground of appeal if directed by the appellate
authority. MUST recognize an objection to the whole or a
part of an audit assessment. MUST interface with the
collection functions to monitor for collection the part that
is not on dispute, while the part in dispute is held in
abeyance while the objection is processed. MUST route a
case through a manager to an authorized tax office for
processing. MUST acknowledge concerned authorities
about the appeals. MUST collect in the case folder the
supporting administrative documents regarding the tax in
dispute, the scheduled hearing dates for the cases on
appeal. MUST provide a document upload function to
the taxpayer, to load the documents required by the courts
to be handed over to ANAF. MUST trace the disputed
administrative document from its issue date until the final
solution regarding the tax obligations. MUST generate
notices / orders in predefined formats with inputs from the
assessing authority, including a summary of the appeal
case decision, history of the cause, legal clauses used in
the final decision. MUST publish on ANAF’s portal the
resolutions without any particular reference to the
taxpayer. MUST provide the taxpayer with a version of
the decision without any personal information regarding
the decision makers, via the WebSpace. MUST record
information in the case file on appeal rectification and
revisions processing by the courts. MUST maintain
records regarding the appeals filled in courts in Romania.
MUST provide complete workflow for the legal cases
processing, including but not limited to preparation of the
case folder, review of the case folder, capture of the
judgment note, interface online with the court
communication system. MUST provide complete
workflow to check validity and eligibility of the
applications, manage cases for disputes, linking of the
case folder with the case from the court, joining and
disjoining of cases, notifications. MUST provide
130 Section III. Sample Bidding Forms

complete workflow for manual and automatic case

assignment to the reviewer and via a manager to the
authorized legal advisers, notifications, resolutions and
comments. MUST provide complete workflow for
tracking a disputed administrative document online by
both parties for appeals. MUST extract and exchange data
with other institutions, as described in informational
Annex 4. Legacy Systems for Integration, section
“External Systems and Interfaces”. MUST provide
workflow for the processing of the insolvency cases, with
all the duly legal communication with taxpayer, creditors,
authorities, public registers, and courts.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Revenue Accounting (AC) – MUST support the following
2.12 business process:

 AC01 – Revenue Accounting

The System MUST provide complete workflow for
Accounting and General Ledger, including but not limited
to accounting of the voluntary payments, calculation and
charging of interest on late paid amounts, accounting of
reimbursable amounts, accounting of the offsetting and
deductions of taxpayers liabilities, recording of the
deferred and extended taxpayer liabilities, imposed
freezing accounts, accounting treatment, reversals, etc.
 (See Informational Annex 2.) MUST perform budgetary
accounting in accordance with the Romanian Ministry of
Public Finances requirements. MUST provide reporting,
collection, periodic reports, MIS reporting, automatic and
manual queries. MUST provide complete workflow for
submission of accounts, manual generation of accounting
notes, accounting warranties and garnishments,
consolidated balance sheet for all levels of detail,
management of the accounting information, changes in
the taxpayer status and period end reconciliations.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Revenue Risk Analysis (RM) – MUST support the
2.13 following business processes:

 RA01 – Risk Identification

 RA02 – Risk Analysis

 RA03 – Risk Prioritization

 RA04 – Rating and Selection of Risky Taxpayers

 RA05 –Risk Evaluation Reporting

 RA06 – Rule Engine

132 Section III. Sample Bidding Forms

 RA07 – Risk Management

 RA08 – Managing Risk Indicators

The System MUST provide advanced analytics and
business intelligence to select from multiple data sources
(both internal and external to ANAF) information about
risk factors associated with the collection of the fiscal
revenue, trends and patterns in taxpayers behavior related
to their returns, payments and discrepancies in their fiscal
activity. MUST create and maintain a risk factors
database, populated with data extracted from ANAF
operational databases (OLTP), internal and other external
sources. MUST provide at least one working fiscal risk
model. MUST provide data mining functionality. MUST
integrate with the Data Warehouse, to process data from
data marts dedicated to risk analysis, risk management
and risk monitoring. MUST integrate with the
Management Information System (MIS) to process
reports for risk analysis, selection and planning. MUST
maintain rule-based mass data collection, management
and analysis using data from the data warehouse. MUST
provide custom designed rules and flags to be specified
and built into the System to highlight risk areas and sort
data into risk and other specific components. MUST
provide a graphical user interface (GUI) with an
interactive dashboard for the tax officers, with flexible
data views, query builder with drag and drop, sample,
drill, pivot and filter directly the data to be analyzed.
MUST provide templates, timers, risk registry, risk
indicators and risk parameters for risk indicators. MUST
provide a complete workflow to churn data to determine
the value of the risk indicators for individuals, companies
or groups. MUST provide manual and rules-based ad-hoc
query, sampling and drilling. MUST create and maintain
parameterizable risk profiles for each taxpayer, store the
values of the risk indicators in a risk indicators database
and calculate a dynamic risk score for each taxpayer.
MUST analyze the risk associated to the individuals using
a comparative balance of the amounts spent by each
individual, based on the information from the ANAF
internal databases (like PATRIMVEN), information from
the financial institutions (e.g. lists of bank transfers, etc.),
information from open sources, versus the income
declared by the individual, for a certain fiscal period of
time. MUST create risk profiles on risk indicators, using a
combination of matching techniques such as wildcards,
thesaurus, calculations and formulas (e.g. economic size
of the taxpayer, profit and VAT refund claims, etc.),
 stored in a database with risks treatments modeled with
user-defined parameters. MUST store the risk calculation,
the rules and the results of the risk assessments in the risk
indicators database. MUST flag inconsistencies found in
the data to be analyzed (if any). MUST provide automatic
risk treatment recommendation, manual selection of the
risk treatment for a taxpayer or a group of taxpayers,
establish a hierarchy of risks, and build risk maps,
recommendations of risk treatment strategies using a
models library. MUST provide capabilities to define risk
plans, risk limits, risk score, KPIs, taxpayer segment risk
models, random selection of taxpayers for risk analysis,
score-based confidence factors regarding the revenue
collection risks, risk evaluation reporting, and
management of the risk reports within the Case
Management system. MUST integrate with Revenue
Enforcement (RE), Anti-Fraud (AF), Taxpayer Audit
(TA) – including the High Net worth Individuals Audit,
and other functions that use risk analysis. MUST “push”
reports related to the accuracy of the risk information
collected and processed, based on user defined Key
performance Indicators (KPI’s), in the Case Management
System. MUST provide workflow for continuous risk
management at least with the following steps: risk
identification, risk assessment and prioritization, analysis
of the compliance behavior causes. MUST provide
predictive risk analysis.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

134 Section III. Sample Bidding Forms

Tech. Require. No. Internal Audit (IA) – MUST support the following business
2.14 processes:

 IA01 – Internal Audit Planning

 IA02 – Making Audit Mission

 IA03 – Tracking and Reporting the Implementation of

Recommendations
The System MUST facilitate the creation of a 3-5 year
rolling strategic plan for auditing ANAF’s internal
systems and business processes (department-by-
department), with tactical 1 year audit plans. MUST
provide the necessary alerts after completion of 3 years of
audit activity. MUST integrate the risk analysis results in
the audit plan, at least annual deficiencies, changes in the
fiscal code, and information in the risk register. MUST
prevent multiple audit activities, by synchronizing the
common ANAF activities in Internal Audit, Internal
Control, etc. in a common plan. MUST allow to manual
highlight other entities (e.g. Court of Accounts) control
missions in an entity / business unit. MUST provide
preparation, referral and approval workflow for the
annual internal audit plan. MUST generate individual
work plans per upcoming audit cycle, both online and
offline. MUST manage the audit missions, in the Case
Management System, with control reports, reminders of
the audit cycles, electronic workflow and checklists, audit
candidates, audit reports, scheduler, document
management, access to historic information, log of
activities, management of the time budget, follow up on
the implementation of the audit recommendations, etc.
MUST integrate with the risk analysis and the Document
Management System.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:
Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Internal Control (IC) – MUST support the following
2.15 business processes:

 IC01 – Resource Availability

 IC02 – Resource Usage

 IC03 – Work Plan Execution

 IC04 – Alerts - General

 IC05 – Alerts Related to Taxpayer Services

 IC06 – Alerts Related to Taxpayer Registration

 IC07 – Alerts Related to Returns Processing

 IC08 – Alerts Related to Taxpayer Records

 IC09 – Alerts Related to Enforcement

 IC10 – Alerts Related to Tax Audit

 IC11 – Alerts Related to Appeals

 IC12 – Alerts Related to Fiscal Information

 IC13 – Alerts Related to Antifraud Function

The System MUST plan and implement the internal
control for business unit and individual tax officer, with
adherence to the legal norms. MUST plan the work
program, including resource utilization, time
management, and calendar. MUST support resource
allocation, based on the available resources, with skills,
specialization, seniority and availability, against the risks
to be addressed with internal control mission and the
estimated workload. MUST define, maintain and execute
136 Section III. Sample Bidding Forms

integrated work plans for Internal Control. MUST

collect, store, log, filter and drill alerts about the activity
of all the other departments and System components, like
but not limited to taxpayer services, taxpayer registration,
returns processing, management of the taxpayer records,
enforcement, tax audit, appeals, management of the fiscal
information, and anti-fraud. MUST verify process
compliance.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Management Information / Decision Support (REP) –

2.16 MUST provide the following tools:

 MIS 01 – Report Engine

 MIS 02 – Decision Support System (DSS)

 MIS 03 – Executive Information Subsystem (EIS)

The System MUST provide reporting and KPI
measurements. MUST provide data marts and MIS
databases, populated with information copied from the
production databases (OLTP). MUST integrate with the
Revenue Risk Analysis (RM) and Anti-Fraud / Criminal
Investigation (FR) functional modules, for functions like
data analysis, data analytics and risk scoring. MUST
include a complete documented Data Dictionary for the
 MIS databases and data marts. MUST provide functions
for administration of the MIS, MIS databases
management, back-up and restore of the data, analysis of
the legacy data retained for 10 or 20 years historical
periods, query by example (QBE), data formatting, data
filtering, report generator, MIS scheduler for the MIS
jobs, reports scheduler, report formatting, report editor,
report dash board, report dissemination, report posting,
secure sensitive reports, report data stamp. MUST
support multiple data marts for decision support.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

Tech. Require. No. Taxpayer Services Interface (TS) – MUST provide and
2.17 integrate the following taxpayer services tools:

 Call Center

 Automatic Call Distribution

 Interactive Voice Response Systems

 Computer Telephone Integration

 Call Logger

 Call Handler
138 Section III. Sample Bidding Forms

 SMS Gateway

 Fax Gateway

 E-Mail Gateway
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box”:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented with the existing
RMS product (and/or underlying COTS products) “out-of-the box” together with
configuration tables or rules tables:

Bidder’s cross-references to supporting materials in the Technical Bid:

Bidder’s indication of what functional requirements will be implemented via to-be-

developed extensions to the RMS product (and/or underlying COTS products) or other
custom development:

Bidder’s cross-references to supporting materials in the Technical Bid:

3 - General and Non-Functional Requirements

TR 3.1 - Software Architecture

Tech. Require. No. Components: The System MUST include the following
3.1.1 components/functionalities (including, as appropriate,
complete libraries, up-to-date versions, and paid, up-to-date
licenses). Each component must provide its own interface
(and tool set), to allow configuration, integration and
customization. These components must be fully integrated in
the sense that any element of any component can be accessed
by another element of any other component and that data are
captured and stored once and available system-wide – within
the relevant parameters of security and business process rules.
 DOCUMENT MANAGEMENT SYSTEM.
 BUSINESS INTELLIGENCE.
 ENTERPRISE REPORTING ENGINE.
  WORKFLOW ENGINE.
 RULES ENGINE.
 FORMS MANAGEMENT.
 ON-LINE HELP (on-line documentation, chat, wiki,
etc.).
 DISTANCE LEARNING.
 INTRANET PORTAL.
 INTERNET PORTAL.
 ON-LINE AUCTION.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Software Infrastructure Elements: The System MUST

3.1.2 include the following software infrastructure
elements/functionalities (including, as appropriate, complete
libraries, up-to-date versions, and paid, up-to-date licenses).
Each element must provide its own interface (and tool set), to
allow configuration, integration and customization.
 RELATIONAL DATABASE MANAGEMENT SYSTEM
(RDBMS), INCLUDING ON-LINE ANALYTIC PROCESSING
(OLTP), DATA WAREHOUSE, and ELECTRONIC
ARCHIVE.
 APPLICATION SERVER.
 IDENTITY MANAGEMENT AND ACCESS MANAGEMENT.
 CLUSTERING AND VIRTUALIZATION.
 ENTERPRISE SERVICE BUS.
 MANAGEMENT INFORMATION SYSTEM.
 CUSTOMER RELATIONSHIP MANAGEMENT AND
INTERACTIVE VOICE RECOGNITION (CRM-IVR).
 MASSIVE PRINTING UNIT INTERFACE.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

140 Section III. Sample Bidding Forms

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Technical Management Tools: The System MUST include
3.1.3 the following technical management tools/functionalities
(including, as appropriate, complete libraries, up-to-date
versions, and paid, up-to-date licenses). Each tool must
provide its own interface, to allow configuration, integration
and customization.
 REQUIREMENTS MANAGEMENT AND DEFINITION.

 SOFTWARE RELEASE MANAGEMENT.

 INCIDENT AND PROBLEM MANAGEMENT.

 FUNCTIONAL AND PERFORMANCE TESTING.

 INTEGRATED DEVELOPMENT ENVIRONMENT.

 BUSINESS PROCESS MANAGEMENT SUITE.

 PROGRAMMING LANGUAGES COMPILERS AND/OR

INTERPRETERS USED IN THE DEVELOPMENT OF THE RMS
PRODUCT/S.

 LIBRARIES AND API’S USED IN THE DEVELOPMENT OF

THE RMS.

 DATA MIGRATION (I.E., DATA EXTRACTION, DATA

FILTERING, DATA CONVERSION, OTHER DATA
PREPARATION STEPS FOR THE TEST AND PRODUCTION
DATA)

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. SOA. The System MUST implement a Service Oriented
3.1.4 Architecture (SOA) for all external transactions and all inter-
component transactions.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply
Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ICT Platform Compatibility. The System MUST reliably
3.2 and effectively run on the ICT platform technologies of
ANAF’s Test and Development Platform (See Informational
Annex 3 for more details).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Language Support. The System MUST handle multi-byte
3.3 character sets – specifically: Unicode Latin Extended A and
B, UTF-8, and UTF-16 in display in at least the data and
document management functions, rules and workflow
specifications, system audit, system security, and on-line
help. Case-sensitive sorting must conform to the standards
for the Romanian Language (see DEX “Explicative
Dictionary of the Romanian Language”). All systems
documentation MUST be provided in digital revisable copies,
PDF ready-to-print copies, and hard copies. User manuals
MUST be provided in the Romanian and English Languages.
All other system and implementation documentation MUST
be provided in at least the English Language.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. DOCUMENT MANAGEMENT SYSTEM. MUST exchange and

3.4.1 manage documents received from and sent to taxpayers.
MUST exchange and manage documents transmitted between
functional modules as well as with the main software
components/elements (e.g., e-mail, document repositories,
142 Section III. Sample Bidding Forms

databases). MUST map and insert metadata in any digital

document. MUST create templates for common digital
documents and assign metadata sets for each template.
MUST manage a document’s metadata in accordance with
specified rules. MUST provide an integrated document
storage facility. MUST provide the capacity to create digital
documents and to create them from scanned images,
including imaging processing. MUST provide a personal
workspace, where draft documents can reside until they are
either deleted or registered as digital documents by the user.
MUST create and manage multiple versions of digital
documents. MUST provide an integrated workflow engine
(including an editor for creating rules) or be integrated with
the WORKFLOW ENGINE (specified below). MUST be
integrated with the BUSINESS PROCESS MANAGEMENT SUITE
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. BUSINESS INTELLIGENCE. MUST handle data from multiple
3.4.2 databases. MUST provide dashboards and data visualization
facilities. MUST provide for self-service of selection,
analysis and presentation functions. MUST allow
presentation on mobile devices (i.e., tablets, smart phones,
etc.), in addition to conventional desktop/laptop devices.
MUST provide enterprise search, balanced scorecard,
predictive analytics, forecasting, decision-support, data
mining and online analytical processing, functions. MUST
provide for configurable display design, including timeline,
RSS feed features, design templates, scorecard wizards, and
key performance indicator (KPI) templates. MUST integrate
with the ENTERPRISE REPORTING ENGINE. MUST utilize the
overall System Security facilities.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ENTERPRISE REPORTING ENGINE. MUST generate reports

 from multiple data sources (e.g., databases, flat files, .XLS, or
similar) to multiple document formats (e.g., .DOC, .PDF,
3.4.3
.CSV, etc.,) using predefined or customized report templates.
MUST generate and edit report templates. MUST support
data consolidation from RMS platform databases and other
data sources (e.g., ERP, BI, Analytics, and Data Warehouse)
using standard database interfaces and protocols (e.g., ODBC,
OLEDB, JDBC, etc.,). MUST provide concurrent users
simultaneous view of the same records, documentation,
and/or template. MUST provide role-based access control at
the operation level. MUST control for admissible client
applications before allowing such application to use the
ENTERPRISE REPORTING ENGINE capabilities.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. WORKFLOW ENGINE. The System MUST use the WORKFLOW
3.4.4 ENGINE to execute all business process workflows. The
WORKFLOW ENGINE MUST integrate with the RMS
application. The RMS application MUST create and manage
the business process workflows. The WORKFLOW ENGINE
MUST provide user and administrative control over the
execution of standard and custom workflows, without
limitation regarding the number of workflows and steps in the
workflows. The WORKFLOW ENGINE MUST provide
permissions to users and groups, so that they may re-assign
tasks/activities/actions in a workflow under the control of the
system administrator. The WORKFLOW ENGINE MUST allow
a user to check status of own-tasks, to suspend and resume a
task for a determined period of time, and to redirect a task to
another user. The WORKFLOW ENGINE MUST provide
reporting and notification functions covering workload and
exceptions (e.g., tasks suspended, tasks delayed beyond norm
for each task, tasks approaching the statuary 30 day limit,
etc.). The WORKFLOW ENGINE MUST trigger workflows
automatically based on appropriate events, provide
conditional and parallel workflow execution, prioritize
workflows in the queues, and track the entire workflow
process. MUST manage an unlimited number of versions of
the same workflow each with specific time limits. MUST
utilize the overall System Security facilities.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply
144 Section III. Sample Bidding Forms

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. RULES ENGINE. MUST manage the execution of all business
3.4.5 process workflows. The RULES ENGINE MUST integrate with
the RMS application. The RULES ENGINE MUST create and
manage the business rules for workflow execution and
reporting. The RULES ENGINE MUST recognize and organize
textual statements of a business rule (or groups of rules) into
a repository with associated metadata, reports, and guidance
for maintenance and management of the rule/rules. The
RULES ENGINE repository MUST provide a structured,
hierarchical view of the rules. The RULES ENGINE MUST
import and export rules, statements, metadata and associated
information in a standard format (e.g., Semantics of Business
Vocabulary and Business Rules (SBVR), Production Rule
Representation (PRR), etc.,). The RULES ENGINE MUST
provide a structured rules language and provide patterns for
rules that help the business user and/or administrator create
new rules. MUST manage an unlimited number of versions
of the same rule each with specific time limits. MUST utilize
the overall System Security facilities.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. FORMS MANAGEMENT. MUST allow administrators to create,

3.4.6 edit, import, export forms, XML and XSLD schemas and
bind the forms and XML schemas together. MUST support
at least Adobe .PDF formats and XML compatible layout
schemas. MUST manage multiple versions of the same form
with specific time limits. MUST work with digital
signatures. MUST allow on-line and off-line interaction with
the forms. The RMS application MUST integrate the forms
with the functional modules using standard web-service
protocols (e.g., WSLD, SOAP, HTTP, ADO, JDBC). The
FORMS MANAGEMENT MUST store and archive unlimited
 number of digital forms. The FORMS MANAGEMENT MUST
utilize the overall System Security facilities. The electronic
forms generated by the FORMS MANAGEMENT MUST support
local settings for the Romanian, Hungarian, German and
English Languages. The language of the user interface within
the electronic forms MUST be at least Romanian and
English. The electronic forms must correct misuse of non-
ASCII special characters in Romanian, Hungarian, and
German.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ON-LINE HELP (on-line documentation, chat, wiki, etc.).
3.4.7 MUST search and index all articles (e.g., HTML pages, etc.)
using keywords and highlight results in the retrieved articles.
MUST integrate with Internet Portal and Intranet Portal and
provide “tool tips” (i.e., context-based guidance). MUST
allow video tutorials to be embedded in the help articles.
MUST allow user to export articles as .PDF documents.
MUST monitor and report user query statistics. MUST
provide on-line chat help desk functionality. MUST allow
users to select large display font sizes. The on-line help
articles and user interface must be selectable between the
Romanian and English Languages (with full support for the
Romanian character set).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. DISTANCE LEARNING. MUST administer the full lifecycle of
3.4.8 training (planning, curricula, registration, attendance, testing,
evaluation, and trainee feedback, etc.). MUST deliver
through Computer Base Training (CBT), Instructor Lead
Training (ILT) classroom, and virtual classroom channels.
MUST provide individualized access to trainee profile, job
role, training track (past and future), class schedule, class
materials, class enrollment and class access. MUST utilize
146 Section III. Sample Bidding Forms

the overall System Security facilities. MUST provide

training management control over course definition,
curricula, mapping of job role and courses, class schedule,
training resource availability (including trainers, classrooms,
pedagogical equipment, inventory of printed manuals, and
consumables, etc.). MUST provide training management
monitoring of trainee evaluation and trainee compliance
testing, class evaluation, and course evaluation. MUST
provide capacity for virtual and distance classes (i.e.,
multimedia streaming, voice and video conferencing, desktop
sharing/remote control of the trainee’s workstations). MUST
catalog training content for classrooms and CBT. MUST
provide search and selection of training content from the
catalog based on trainee profile, job role, topics of interest,
and schedule. MUST track and notify trainees and training
administrators regarding compulsory courses and test base on
the job role. MUST upload and download CBT. MUST
provide and manage CBT using the SCORM 2004
international standard (or equivalent standard). MUST
provide a web-interface and the option to download and run
the CBT on the trainee’s workstation. MUST provide an user
interface in the Romanian and English Languages.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. INTRANET PORTAL. MUST provide an enrollment function

3.4.9 that can interoperate with ANAF’s existing IBM Tivoli
Identity Manager and IBM Tivoli Access Manager systems
and integrate with the IDENTITY MANAGEMENT AND ACCESS
MANAGEMENT. MUST provide a user profile editing and
update function to establish and maintain details about the
internal user (e.g., mail stop, extension number, access
privileges for the business applications) that provide self-
service and supervisory control functions. MUST utilize the
overall System Security facilities. MUST provide controlled
access to all RMS modules, software components, software
elements and system management tools. MUST provide a
visual user interface in the Romanian and English Language.
MUST present personalized access points to the authorized
business applications. MUST present information of general
interest to ANAF personnel (e.g., news, updates, broadcast
internal communication, etc.). MUST present user-specific
information (e.g., task lists, late or delayed tasks,
 notifications, etc.,). During the analysis and development
stages, the Intranet Portal MUST provide an indication of
what business applications are running on the production
system and what business application are running on the
test/training system.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. INTERNET PORTAL. MUST provide an enrollment function

3.4.10 that can interoperate with ANAF’s existing IBM Tivoli
Identity Manager and IBM Tivoli Access Manager systems
and integrate with the IDENTITY MANAGEMENT AND ACCESS
MANAGEMENT. MUST provide a user profile editing and
update function to establish and maintain details about the
external user (taxpayer register number, name of
taxpayer/firm, addresses, contact information, etc.,) that
provide self-service and supervisory control functions.
MUST provide controlled taxpayer-specific access to specific
taxpayer services (inquiry, registration, returns filing,
taxpayer account, appeals and complaints, on-line help, on-
line training, chat, selection of SMS versus e-mail
communications channels, etc.). MUST present taxpayer
personalized access points to the authorized on-line services.
MUST present information of general interest to taxpayer
(e.g., news, updates, broadcast external communication, etc.).
MUST present taxpayer-specific information (e.g., taxpayer
specific documents released by ANAF, notifications, access
logs, etc.,). MUST utilize ANAF’s Internet security system.
(See Informational Annex 4 for details.) MUST provide a
visual user interface in the Romanian, German, Hungarian
and English Languages.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ON-LINE AUCTION. MUST provide functions to automate

publicity and transactions with goods from enforced
148 Section III. Sample Bidding Forms

3.4.11 collection, seized goods and other categories of goods (like

old ANAF equipment for disposal), over secured Internet.
MUST integrate with the Taxpayer Registration, Internet
Portal, Intranet Portal and Identity Management and Access
Management components. MUST authenticate and log-in the
participants to the on-line auctions in e-auction rooms, over
the Internet and the Intranet or from auctions room located on
the premises of ANAF, over the Intranet. MUST provide at
least the following roles for the participants: bidders, auction
president (only one participant), lead-secretary (only one
participant for the e-auction room), secretaries (at least one
for each auction room), independent witnesses, and auditors.
MUST authenticate the participants at least with user name,
password and qualified digital certificate, in order to sign the
auction documents (i.e. auction terms and conditions, consent
for the processing of the personal data, auction forms, and
auction session minutes) during the trade session. MUST log
with certified time stamp and digital signature all the
activities of the participants, in an auditable activity log and
in the auction session minutes document. MUST time on all
the phases and steps of the auction, locking and unlocking the
processes as per the auction scenario in place. MUST
implement flexible and editable parameters for the duration
of all the steps of the auction, the advertising periods of time,
the deadlines to enroll for an auction and pay the participation
fees or the auction security bond, etc. MUST interface with
Revenue Enforcement functional module and with the
Document Management System, to import the information
regarding the goods on sale from the auction case folder into
the publicity and the transaction. MUST interface with the
Revenue Enforcement functional module and with the
Document Management System to export the results and the
logs of the auction (i.e. all the auction documents digitally
signed, transactions logs, activity logs, image and sound
captures from the physical auction rooms on ANAF premises,
etc.). MUST interface with the WebSpace to post information
for the taxpayers enrolled or participating in e-auctions and to
collect the documents uploaded by the taxpayer to enroll for
the e-auctions. MUST interface with the Taxpayer
Accounting functional module to check the payments made
for the participation security and/or participation fee, for the
payments of the adjudicated goods, etc. MUST implement
auction workflows compliant with the regulations in place at
least forward e-auction, for non-perishable non- perishable
goods, and low value goods. MUST implement a secured
mechanism to make all transactions non-reputable, with the
step-by-step granularity. The Supplier MUST provide
functions to manage the events that may happen during the e-
auction session (i.e. presentation of the participants,
participant unexpectedly leaves the auction room, technical
 incidents, etc.,). MUST distribute notifications and
documents regarding the results of the auctions, the upcoming
auctions, the goods to be auctioned again at discounted
starting price, etc. MUST disseminate information regarding
the goods to be auctioned via a public web section in the
ANAF public portal. MUST disseminate reminders to the
participants enrolled in the e-auction platform via e-mail and
WEB. MUST provide secured and encrypted communication
sessions over the Internet for all the participants on-line (see
more details in Informational Annex 4 – Online Auction).
MUST utilize ANAF’s Internet security system. (See
Informational Annex 4 for details.) MUST provide a visual
user interface in the Romanian and English Languages.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS),

INCLUDING ON-LINE TRANSACTIONS PROCESSING (OLTP).
3.5.1
MUST implement the entity relation model with relational or
object-relational technology. MUST provide at least one of
SQL:2011 or ISO/IEC 9075:2011 or noSQL query languages.
MUST provide programmatic interfaces for all the
programming languages used in the RMS applications.
MUST provide standard database interfaces and protocols –
at least one of ODBC, OLEDB, JDBC, JSON, or API
interfaces. MUST provide JAVA and/or Microsoft .Net
application development platforms. MUST provide an
application development environment with a graphical
integrated development environment (IDE) from the RDBMS
manufacture or using open source technologies (e.g.,
Eclipse). MUST provide high-scalability, high-availability,
disaster-recovery function either built-in or products from the
RDBMS manufacture. MUST provide adjustable multi-level
query optimizer. MUST provide parallel query processing
(i.e., to process multiple table partitions simultaneously).
MUST point-in-time recovery (i.e., recovery to a specified
moment in time). MUST provide on-line and off-line back-
up functionality. MUST provide data encryption within a
table (i.e., column-based data encryption). MUST provide
row-level security functions. MUST provide native support
for multi-byte character set – specifically: Unicode Latin
Extended A and B, UTF-8, and UTF-16. MUST provide
selectable, multi-level audit trails. MUST provide database
150 Section III. Sample Bidding Forms

partitioning. MUST manage databases of at least 500 (five

hundred) TB.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. DATA WAREHOUSE. MUST integrate with the RELATIONAL
3.5.2 DATABASE MANAGEMENT SYSTEM (RDBMS), ON-LINE
TRANSACTIONS PROCESSING (OLTP), and BUSINESS
INTELLIGENCE. MUST acquire, organize, analyze, ingest, and
present data. MUST provide Analytics 3.0 standards in the
domains of deeper analysis, different types of data, and
operational elements incorporated with design patterns (e.g.,
dashboards and scorecards). MUST handle structured, semi-
structured, and unstructured data with the data types,
including master and reference data, transactional data,
machine-generated data, social media data, text, image, video
and audio. MUST provide data acquisition from DBMS, flat
files, NoSQL files, DMP files, etc. MUST provide data
organization with at least ETL/ELT rules. MUST analyze
data with at least Open Data Sets (ODS), warehouse, graph
model, in database analysis, in-memory database processing.
MUST provide data decision functions for: score cards,
dashboards, query reporting, real-time decisions, CPM, BI,
social applications, text analytics and search, advanced
analytics, and interactive discovery. MUST provide DBA
productivity tools, monitoring features, parallel utilities,
robust query optimizer, locking schemes, security
methodology, and remote maintenance capabilities. MUST
provide data integrity, back-up and recovery functions, with
ability to restore databases at any point in time, to ensure data
integrity Write Data to Disaster Recovery after data is
committed at Primary (performance at the Primary must not
be interrupted by data replication at the Disaster Recovery /
Business Continuity Sites). MUST interoperate with
ANAF’s existing DBMS system software (i.e., Oracle 8, 9,
10i, 11g, IBM DB2, Microsoft SQL Server, Lotus Notes and
Domino). MUST provide multiple data marts (to segregate
risk management, fiscal audit and internal control functions
from the main data stores).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ELECTRONIC ARCHIVE. MUST preserve the collection of

3.5.3 ANAF’s signed digital documents and other artifacts
(unsigned documents, messages, transactions logs, scanned
images, presentations, new feeds, press releases, system
images, etc., etc.,). MUST monitor and insure the integrity of
digital documents and artifacts during day-in-and-day-out
operations. MUST manage the physical security of the
digital documents and artifacts. MUST facilitate the
discovery information about the archived digital documents
and artifacts and enforce access control. MUST manage
digital objects made up of multiple components,
versions/generations, and files. MUST maintain relationship
between digital objects with multiple components to ensure
that the constituent parts are delivered in the proper order.
MUST maintain the reference, the provenience, the context
and fixity information required to preserve the integrity of the
digital object. MUST provide an open, extensible and
standard method of packaging metadata for digital objects,
including at least Metadata Encoding and Transmission
Standard (METS). MUST allow new versions of descriptive
metadata alongside older versions of metadata attached to a
digital object. MUST run continuously with no scheduled
downtime. MUST provide remote administration using
secure and unsecure communication protocols. MUST
provide a workflow for digital document and artifact
registration (or utilize the WORKFLOW ENGINE). MUST
provide search-driven structured and dynamic navigation and
filtering. MUST allow subsets of documents of search results
to be selected for downloading.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. APPLICATION SERVER. MUST deploy applications developed

3.5.4 with Java or Microsoft .Net application frameworks. MUST
integrate with the RELATIONAL DATABASE MANAGEMENT
SYSTEM (RDBMS), DATA WAREHOUSE, CLUSTERING AND
VIRTUALIZATION, and ENTERPRISE SERVICE BUS, as well as the
152 Section III. Sample Bidding Forms

RMS functional modules. MUST be accessible via an

Application Programmer Interface (API) defined by the
APPLICATION SERVER itself. MUST provide native
functionality for clustering, fail-over, and load-balancing.
MUST implement either Java Platform Enterprise Edition or
Microsoft .Net Framework for applications. MUST serve
web applications and services via standard interfaces (e.g.,
RMI, EJD, JMS, SOAP, ASP.NET, COM+, WCF). MUST
provide all necessary libraries, scripting languages and
interpreters, and APIs for the RMS functional modules and
the above named software components. MUST provide
application services for 25,000 concurrent users.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. IDENTITY MANAGEMENT AND ACCESS MANAGEMENT. MUST

3.5.5 provide the management of the individual principals, of their
identification, authentication and authorization, as well as of
their access privileges across the IT systems and applications
of ANAF, within the enterprise architecture boundaries.
MUST manage the identification, authentication and
authorization information that defines the operations an entity
(user) can perform in the context of any specific application
(part of the RMS system) at any point in time. MUST provide
the components of the identity management system for the
RMS system, including (but not limited to): functionalities
for internal directory services, meta-directory and federation
services, password and alternative credentials lifecycle
management, agent less single sign-on services. MUST
provide consolidated dynamic role- and attribute-based
authorization services for the proposed RMS application
modules and to existing NAFA applications, as well as to the
underlying Web-Services, APIs and IT infrastructure
components. MUST provide ongoing governance for the
identity management process itself, including of the creation,
initial provisioning, subsequent changes and de-provisioning
of the identity profiles and of the resource access entitlements
granted to the users. MUST provide a core component
providing an internal user registry able to hold and operate
with detailed information sets for more than 5 million
external users and for up to 50,000 internal and extranet
users. MUST provide standards-based directory and
authorization services with support for high concurrency
 environments (hundreds of thousands of concurrent requests)
and with a rich set of identity management interoperability
focused features. MUST provide interfaces and methods to
implement both single-factor authentication (e.g. user name
and password) and multi—factor authentication (e.g. user
name and any of: password, digital certificate/token or one-
time password code/token). MUST provide full support for
the use of the digital signatures as well as for the concurrent
connection to more than one back-end (internal and/or third
party) certification and/or validation authority at a time.
MUST provide support for digital certificates, at a minimum
from: the ones issued by a Certification Service Provider on
the list of EU Trusted Lists of Certification Services
(available on
https://ec.europa.eu/informationsociety/policy/esignature/trus
ted-list/), or the ones from a Qualified Certificate Service
Providers registered in Romania (the list is available
on:http://www.mcsi.ro/Minister/Domenii-de-activitate-ale-
MCSI/Tehnologia-Informatiei/Servicii-
electronice/Semnatura-electronica/ROMANIATrustedList-
v7-PDF). MUST support centralized administration, via
central administrator roles, as well as the delegation of
authority functions for local administrators and supervisors.
MUST support the interchange of the identity related
information between two or more identity domains via the
Security Assertion Markup Language (SAML 1.0, 1.1 and
2.0) OpenID and WS-Trust protocols. MUST enable the use
of delegated authorization in the ANAF applications via
OAuth (1.0 and 2.0) and WS-Trust protocols and enable the
use of standards-based machine-readable fine-grained
resource access policies via the eXtensible Access Control
Markup Language (XACML 2.0 and 3.0) protocols. MUST
support and at least substantially implement the core
principles of the following international standards specific for
identity and access management: ISO/IEC 24760-1:2011 and
ISO/IEC 24760-2:2015 Framework for Identity Management;
ISO/IEC 29100 Privacy Framework, ISO/IEC 29101 Privacy
Architecture; ISO/IEC 29115:2013 Entity Authentication
Assurance. MUST run at least on any of the following
operating system platforms (with reference to the versions
respectively supported at the time of the offering and for the
duration of the contract): Unix (multivendor), Linux
(multivendor) or Microsoft Windows.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

154 Section III. Sample Bidding Forms

Tech. Require. No. CLUSTERING AND VIRTUALIZATION. MUST deploy images of

3.5.6 the software stack (e.g., operating system, RDBMS,
application server, business applications) over two or more
physical servers in a High Availability and Load Balancing
configuration, separating the components using virtual
machines. MUST integrate with the software stack used by
the RMS, including all components in a fully virtualized
environment.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ENTERPRISE SERVICE BUS. MUST implement Service Oriented
3.5.7 Architecture (SOA) communications between the software
components and software elements. MUST fully integrate
with the software stack (e.g., operating system, RDBMS,
application server, business applications). MUST implement
interfaces for applications, software components and software
elements based on the following standards: Java, BPEL,
SOAP, RNI, REST, JNI, and others as needed for the RMS.
MUST provide functions to monitor and control routing of
messages exchanged between the services integrated by the
ENTERPRISE SERVICE BUS. MUST provide resolution
containment between the communicating service
components. MUST provide marshaling of redundant
services in the RMS. MUST provide commodity services to
the RMS components (i.e., event handling, data
transformation and mapping, message and event queuing and
sequencing, message security, exception handling, protocol
conversion, and file transfer). MUST provide process
choreography and service orchestration. MUST implement
interfaces for ANAF’s legacy systems, specifically: Oracle
RDBMS, Oracle BPEL, IBM DB2, IBM Websphere, Lotus
Notes and Domino, JBOSS, Spring, and Hibernate.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. MANAGEMENT INFORMATION SYSTEM. MUST provide timely,
3.5.8 accurate and consistent data for management and budget
decision-taking for the agency level policy decisions. MUST
integrate revenue collection data with activity resource usage
and cost information. MUST provide reports for budget
planning, analysis and government wide reporting, based on
ANAF’s customized formats and EU standard formats.
MUST prepare financial statements in the International
Financial Reporting Standard (IFRS) formats (in accordance
with DEP 2003/51/CE and other applicable legislation).
MUST provide at least budget reports and statutory financial
reports. MUST provide a complete audit trail. MUST
provide a general ledger module, with the Romanian Chart of
Accounts. MUST interface with ANAF’s existing accounts
payable, accounts receivable, cash management, assets,
procurement, and budget planning modules. MUST interface
with fiscal information in the RMS, payment information in
the Treasury system (TREZOR), and taxes, duties, levies and
excises in Customs systems (EMCS-RO, NCTS-RO, ECS-
RO, ICS, EORI-RO, TARIC, TARIF, ROC-DPS, RO-DAI,
APS-RO, and RVEDF). (See Informational Annex 4 for
descriptions of ANAF’s to-be Legacy Systems and
interfaces.)
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. CUSTOMER RELATIONSHIP MANAGEMENT AND INTERACTIVE

3.5.9 VOICE RECOGNITION (CRM-IVR).MUST provide information
to the ANAF taxpayer support staff regarding general topics
and taxpayer specific fiscal topics, using the information from
knowledge database (supported today with the application
ANAFI) and the help system. MUST integrate with the tax
payer register, to check the identity of caller versus the
existing information about the respective taxpayer. MUST
track and measure the taxpayer support staff interaction with
the taxpayers using the active communication channels, for
activity analysis. MUST provide interactive functions to
handle the calls of the taxpayers, including taxpayer identity,
taxpayer incoming phone number (caller ID), taxpayer
156 Section III. Sample Bidding Forms

verification (password, PIN, and other security information)

via voice or dual tone multi frequency signal (DTMF).
MUST interact via the following channels: voice, voice over
IP, Chat, SMS, fax and e-mail. MUST integrate with the
existing ANAF’s Taxpayer Services Contact
Center(described in Informational Annex 4). MUST integrate
with the WebSpace for the chat function, available to the tax
payers logged in the WebSpace to get support from ANAF
specialists. MUST log all calls and capture at least the
following information: caller id, date, time and duration,
caller name, taxpayer support staff id and name, subject(s) of
the call, content, call closure, call evaluation, call recording
and record of all the chat sessions, for later review, quality
control and trends analysis. MUST provide pre-recorded
incoming call message and waiting message. MUST provide
call-monitoring functions. MUST provide statistical reports
regarding the calls – by topic, by categories, by period, by
taxpayer support staff. MUST report on trends over time.
MUST report on the activity of the tax payer support staff in
detail and grouped by areas and activity type. MUST push
activity statistics to the Data Warehouse and MIS.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. MASSIVE PRINTING UNIT INTERFACE. MUST provide access to
3.5.10 the massive printing facilities of ANAF for all the
applications part of the System. The Massive Printing Unit
prepares for mass mailing the ANAF administrative
documents (e.g. notifications, summons, fiscal notices,
executive titles, deduction notices, ANAF decisions, etc.).
The Massive Printing Unit distributes the administrative
documents to the tax payers based on a protocol with the
Romanian Post, from this single location. The receipt of the
administrative documents by the taxpayer is confirmed via
the postal service, based on distribution lists managed by the
Massive Printing Unit. The Massive Printing Unit of ANAF
consists of a printing server located in the Primary Data
Center (in Bucharest), connected via Intranet to the printers
(manufactured by Xerox) and the inserting equipment
(manufactured by the company Kern (www.kern.ch), 2 units
of Kern 686 and 1 unit of Kern 3500), located in Ramnicu
Valcea, Romania. MUST handle output from the System
applications in Oracle .DMP file format. MUST capture the
 output of the System applications at least in the following file
formats: .PDF, .TXT, .CSV, .XML, Oracle, .DMP. MUST
transfer the output files to the application SIAD – “Sistem
informatic de administrare a documentelor administrative” –
(IT system for the administration of the administrative
documents), via simple file sharing on NFS protocol or via
FTP protocol. MUST provide automatic and manual file
transfers. MUST provide the administrative information
about the documents to be printed, folded and inserted in
envelopes for mass mailing in a structured format (e.g. format
of the document to be printed, name of the document
template from the existing library of formats, destination
address, distribution lists per regions, tally sheets,
confirmation letters, etc.) together with the files to be printed.
MUST provide the option to handle directly the printers
located in the Massive Printing Unit, using virtual printer
ports over the Intranet. MUST support direct printing on the
existing printer drivers or using an universal virtual printing
driver, supporting at least one of the following printer control
languages: PCL5, PCL6 and/or Postscript. MUST provide
complete mailing and formatting information for the
documents printed directly (if any) on the printers of the
Massive Printing Units, including the folding and inserting
commands for the inserting equipment. MUST provide
mailing information (if any) sorted and grouped per regions,
localities, and postal codes. MUST capture the information
about the administrative document delivery status (e.g.
delivered to tax payer, not delivered to tax payer, posted on
the ANAF public web, accepted by default, etc.) from the
files in Oracle .DMP format produced by the SIAD
application and update the status of the administrative
document in the System.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. REQUIREMENTS MANAGEMENT AND DEFINITION. MUST be the

3.6.1 repository and management tool for documents, requests and
change requests. MUST compile the business requirements
and configuration change requests in a standardized form.
MUST ensure the validation business requirements and
configuration change requests with the relevant business
owners and technical departments. MUST trace requirements
to system functions and test cases. MUST ensure that the
158 Section III. Sample Bidding Forms

integrity of the requirements is preserved (i.e., all comments,

changes and approvals are recorded). MUST maintain
accountability of the change requests to the initiating
department. MUST provide customizable standardized forms
for business requests, change requests, and configuration
change requests. MUST log change requests and all
processing steps. MUST notify (via e-mail) stakeholders
regarding events and step approvals. MUST allow an
unlimited number of change requests, items, processes – each
with their own workflow logic and data capture requirements.
MUST provide consolidated views of the individual work-
items, showing total effort and cost by group, team,
application, or other attribute. MUST provide audit trails for
all actions, approvals, and data updates. MUST provide
access to authorized users via a web-based interface. MUST
provide version control for application software, software
components, software elements, and technical management
tools (either integral to the REQUIREMENTS MANAGEMENT AND
DEFINITION tool or by the SOFTWARE RELEASE MANAGEMENT
tool). MUST integrate with RMS applications, software
components, software elements, and technical management
tools.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. SOFTWARE RELEASE MANAGEMENT. MUST control the

3.6.2 acquisition, installation and testing of all new software
releases. MUST provide a repository and necessary tools to
manage the development and test environments (i.e., system
images and virtual machines) and conduct the installation and
testing processes. MUST manage the deployment of the
software release into the production environment. MUST
integrate with the FUNCTIONAL AND PERFORMANCE TESTING
tools.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. INCIDENT AND PROBLEM MANAGEMENT. MUST record and
3.6.3 log all incidents and problems arising during implementation,
configuration, testing deployment, production operations and
maintenance phases. MUST be accessible via secure Internet
connection by the Supplier and the ANAF. MUST provide a
unique ID for all incidents and problems. MUST track
resolution process steps until closure, using the unique ID.
MUST classify incidents as either “existing problems”
(without a known root cause) or “known errors”. MUST
implement the Supplier’s problem management process.
MUST register incidents and problems in a “know error”
database accessible to both the Supplier and ANAF. MUST
provide templates for incident and problems registration.
MUST assign incident ownership, monitoring, tracking, and
communication responsibilities. MUST track and report on
the status of incidents and problems resolution. MUST notify
the stakeholders of an incident or problem via e-mail
regarding changes and overdue actions.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. FUNCTIONAL AND PERFORMANCE TESTING. MUST allow

3.6.4 authorized users to define test cases for module-specific or
system-wide functions, for performance testing, and for stress
testing. MUST manage the performance threshold
requirement detailed in the analysis and design phase. MUST
automate functional and regression testing. MUST define
tests by recording actual business activities using Java, .NET,
HTTP, and HTTPS. MUST provide a repository for
requirements, test cases, automated test scripts, and revealed
defects. MUST generate reports on requirements, test cases,
automated test scripts, revealed defects, release status, release
coverage, etc. MUST define and control the visibility of the
testing process for different groups of users. MUST manage
the full cycle of performance testing (i.e., stress and load
testing) for web-based applications.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

160 Section III. Sample Bidding Forms

Tech. Require. No. INTEGRATED DEVELOPMENT ENVIRONMENT. MUST integrate

3.6.5 PROGRAMMING LANGUAGES COMPILERS AND/OR INTERPRETERS
USED IN THE DEVELOPMENT OF THE RMS PRODUCT/S .
LIBRARIES AND API’S USED IN THE DEVELOPMENT OF THE
RMS. MUST provide at least Eclipse, Hibernate, Spring,
Oracle JDeveloper, and generic SQL development
frameworks.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. BUSINESS PROCESS MANAGEMENT SUITE. MUST integrate with
3.6.6 the following software elements and components: Intranet
Portal, Internet Portal, Workflow Engine, Rules Engine and
Enterprise Service Bus. MUST provide integration for
applications made in different technologies, based on open
interfacing standards. MUST provide a process orchestration
engine to coordinate all type of actors for structured and
unstructured data flows. MUST provide the ability to
connect mainstream, commercial of the shelf (COTS)
applications. MUST support rule-driven and ad-hoc
workflows, and response to human and system responses.
MUST provide logs documenting the changes of the state of
the coordinated resources (e.g. processes, interfaces, data
workflows, etc.). MUST schedule and prioritize work in a
flexible way. MUST integrate in an Integrated Development
Environment, with graphical interface. MUST natively
manage or integrate with enterprise content management
tools (ECM) to manage documents and other type of
unstructured content (e.g. graphical images, audio or video).
MUST provide on-demand analytics functions on the
processes and workflows managed, to improve the process
model or its execution by the user. MUST provide business
rules processing. MUST manage and execute rules that
represent business policies. MUST provide connectivity at
least via HTTP, REST, SOAP, WSDL, ODBC, JDBCand
/or .NET protocols. MUST provide functions to configure
deploy and administer the platform and the application
artifacts, as well as versioning control. MUST provide
integration with the IT security framework, at least at the
 level of application, user, role, group, department and
function. MUST provide process monitoring and alerts for
the users and the administrators regarding the processes
execution. MUST support desktop, laptop and mobile end–
user devices. MUST provide integration with the social
media applications, at least Facebook, Google+, LinkedIn,
YouTube, Instagram, other as per the case.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. PROGRAMMING LANGUAGES COMPILERS AND/OR INTERPRETERS

USED IN THE DEVELOPMENT OF THE RMS PRODUCT/S .
3.6.7
LIBRARIES AND API’S USED IN THE DEVELOPMENT OF THE
RMS. MUST provide a complete set of up-to-date media,
licenses and documentation for all compliers, interpreters,
libraries and API necessary for customization and
maintenance of the System. MUST integrate these tools in
the INTEGRATED DEVELOPMENT ENVIRONMENT. MUST
integrate these tools with SOFTWARE RELEASE MANAGEMENT.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. DATA MIGRATION. MUST provide tools for data extraction,
3.6.8 data filtering, data cleaning, data conversion, other
preparation steps for migrating the test and production data
from ANAF’s existing systems and databases into the RMS.
MUST use the PROGRAMMING LANGUAGES COMPILERS
AND/OR INTERPRETERS USED IN THE DEVELOPMENT OF THE
RMS PRODUCT/S,LIBRARIES AND API’S USED IN THE
DEVELOPMENT OF THE RMS. MUST upload the test and
production data into the RELATIONAL DATABASE MANAGEMENT
SYSTEM (RDBMS) and THE DATA WAREHOUSE
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

162 Section III. Sample Bidding Forms

Bidder’s cross-references to supporting materials in Technical Bid:

4–Sizing

Tech. Require. No. MUST provide a perpetual enterprise license for the RMS
4.1 product.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST handle (including, as appropriate,

4.2 licenses):
The minimum number of end users per functional
modules are as follows:
o At least 5,000 users for the TAXPAYER REGISTRATION
functional module.
o At least 5,000 users for the RETURNS PROCESSING
functional module.
o At least 5,000 users for the PAYMENTS PROCESSING
functional module.
o At least 5,000 users for the TAXPAYER
ACCOUNTS/LEDGER functional module.
o At least 5,000 users for the REFUNDS PROCESSING
functional module.
o At least 5,000 users for the RECONCILIATION
functional module.
o At least 5,000 users for the REVENUE COLLECTION
functional module.
o At least 1,000 users for the REVENUE ENFORCEMENT
functional module.
o At least 3,500 users for the TAXPAYER AUDIT
functional module.
o At least 2,000 users for ANTI-FRAUD / CRIMINAL
 INVESTIGATION functional module.
o At least 1050 users for the OBJECTIONS AND APPEALS
functional module.
o At least 30 users for the REVENUE ACCOUNTING
functional module.
o At least 120 users forREVENUERISK MANAGEMENT
advanced analytics functional module.
o At least 10 users forREVENUERISK MANAGEMENT
business intelligence and data mart functional module.
o At least 2,000 users forREVENUERISK MANAGEMENT
enterprise reporting functional module.
o At least 100 users for the INTERNAL AUDIT functional
module.
o At least 100 users for the INTERNAL CONTROL
functional module.
o At least 2,500 users for the MANAGEMENT
INFORMATION / DECISION SUPPORT functional module.
o At least 12,000 users for the TAXPAYER SERVICES
INTERFACE functional module.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST handle (including, as appropriate,

4.3 licenses):
The minimum number of registered identities for the
underlying software components are as follows:
o At least 18,000 run-time users for DOCUMENT
MANAGEMENT.
o At least 2,500 run-time users for BUSINESS
INTELLIGENCE.
o At least 250 full users for BUSINESS INTELLIGENCE.
o At least 2,500 users for ENTERPRISE REPORTING
ENGINE.
o At least 18,000 run-time users for WORKFLOW
ENGINE.
164 Section III. Sample Bidding Forms

o At least 18,000 run-time users for RULES ENGINE.

o At least 18,000 run-time users for FORMS
MANAGEMENT.
o At least 18,000 users for ON-LINE HELP.
o At least 18,000 users for DISTANCE LEARNING.
o At least 18,000 users for the INTRANET PORTAL.
o At least 500,000 users for the INTERNET PORTAL.
o At least 1,000 run-time registered internal users. At
least 50,000 run-time registered external users for ON-
LINE AUCTION.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST handle (including, as appropriate,

4.4 licenses):
The sizing of the software infrastructure elements are as
follows:
o RELATIONAL DATABASE MANAGEMENT SYSTEM,
including OLTP, DATA WAREHOUSE, and
ELECTRONIC ARCHIVEsufficient to run all the required
applications, users, performance requirements, and
data volumes (including at least ten years of records
of 2,500,000 corporate taxpayers/contributor accounts
and at least 4,700,000 individual taxpayer/contributor
accounts for the OTLP Database, at least 500 (five
hundred) TB for the Data Warehouse, and at least 100
(one hundred) TB for the Electronic Archive.)
o APPLICATION SERVER sufficient to run all the required
applications, users, data volumes, performance
requirements.
o IDENTITY MANAGEMENT AND ACCESS MANAGEMENT
sufficient to run all the required applications, 30,000
internal users, 500,000 external users (tax payers,
individuals and companies, that will access systems’
functionalities via the Internet), implemented in a high
availability and disaster recovery configuration with 3
sites – Primary Data Center (PDC), Secondary Data
Center (SDC) and Data Warehouse Data Center
 (DWDC).
o CLUSTERING AND VIRTUALIZATION, sufficient to run all
the required applications, users, data volumes,
performance requirements.
o ENTERPRISE SERVICE BUS that can handle at least
15,000 one-kilobyte messages per hour with a mean
response time of no more than 1 second per message.
o MANAGEMENT INFORMATION SYSTEM (MIS) that can
handle at least 2,500 reporting users, 500 ad hoc
users, 120 advanced analytic users, and 15 Business
Intelligence developers.
o CUSTOMER RELATIONSHIP MANAGEMENT AND
INTERACTIVE VOICE RECOGNITION (CRM-IVR) that can
handle at least 150 client services support users with
voice over IP (VoIP) calls, chat, SMS gateway, and
Fax gateway.
o MASSIVE PRINTING UNIT INTERFACE - sufficient
number of instances of this interface (software
component) to run all the printing tasks of the System
applications using the facilities of the Massive
Printing Unit, implemented in a high availability and
disaster recovery configuration with 3 sites – Primary
Data Center (PDC), Secondary Data Center (SDC)
and Massive Printing Unit (MPU) and collect the
information regarding the administrative documents
delivery status.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST handle (including, as appropriate,

4.5 licenses):
The minimum number of end users for the technical
management tools are as follows:
o At least 16 users for REQUIREMENTS MANAGEMENT
AND DEFINITION.

o At least 2 users for SOFTWARE CONFIGURATION

MANAGEMENT(with versioning, software component
information management, software and document
versioning functions).
166 Section III. Sample Bidding Forms

o At least 130 users for INCIDENT AND PROBLEM

MANAGEMENT.
o At least 2 users for FUNCTIONAL AND PERFORMANCE
TESTING.
o At least 5 users for INTEGRATED DEVELOPMENT
ENVIRONMENT (IDE) (including source code control
functions, local and central repository, and repository
synchronization).
o At least at least 6 servers for BUSINESS PROCESS
MANAGEMENT SUITE.
o At least 10 users for the PROGRAMMING LANGUAGES
COMPILERS and/or INTERPRETERS used in the
development of the RMS product/s.
o At least 18,000 run-time users for the LIBRARIES AND
API’S used in the development of the RMS.
o At least 1 enterprise license for theDATA
MIGRATIONtools (i.e., data extraction, data filtering,
data conversion, other data preparation steps for the
test and production data).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

5–Performance

Tech. Require. No. The System MUST achieve the following performance
5.1 norms:
Allow at least 10,000 external visitors per day (aggregate,
not individual IP addresses).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST achieve the following performance
5.2 norms:
Allow at least 100,000 page impressions (PI) per day, for
the documents delivered to the external users in the
respective electronic format (e.g., Adobe .PDF digital
signed).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST achieve the following performance
5.3 norms:
At least 99.9% uptime (i.e., 9 hours of unplanned
downtime per year). At least 720 hours Mean Time
Between Failures (MTBF).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST achieve the following performance
5.4 norms:
Performance standards given above must be reached with
at most this many concurrent users using the system at
any given time with 50% of them performing data feeding
and 50% of them performing database queries.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST provide sufficient capacity to support
5.5 concurrent users for each functional module as follows:
o At least 25,000 concurrent users for the CLIENT
168 Section III. Sample Bidding Forms

SERVICES INTERFACE functional module.

o At least 500 concurrent users for the TAXPAYER
REGISTRATION functional module.
o At least 500 concurrent users for the RETURNS
PROCESSING functional module.
o At least 500 concurrent users for thePAYMENTS
PROCESSING functional module.
o At least 500 concurrent users for the REFUNDS
PROCESSING functional module.
o At least 500 concurrent users for the (VAT)
RECONCILIATION functional module.
o At least 500 concurrent users for the TAXPAYER
ACCOUNTS/LEDGER functional module.
o At least 500 concurrent users for theREVENUE
COLLECTION functional module.
o At least 100 concurrent users for the REVENUE
ENFORCEMENT functional module.
o At least 350 concurrent users for the TAXPAYER AUDIT
functional module.
o At least 200 concurrent users for ANTI-FRAUD
functional module.
o At least 100 concurrent users for the OBJECTIONS AND
APPEALS functional module.
o At least 30 concurrent users for the REVENUE
ACCOUNTING functional module.
o At least 30 concurrent users forRISK MANAGEMENT
functional module.
o At least 100 concurrent users for the INTERNAL
CONTROL functional module.
o At least 100 concurrent users for theINTERNAL AUDIT
functional module.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST provide sufficient capacity to support
5.6 concurrent users for each software component as follows:
o At least 3,600 concurrent run-time users for
DOCUMENT MANAGEMENT.
o At least 250 concurrent users for BUSINESS
INTELLIGENCE.
o At least 1,800 concurrent users for ENTERPRISE
REPORTING ENGINE.
o At least 1,800 concurrent run-time users for
WORKFLOW ENGINE.
o At least 4,500 concurrent run-time users for RULES
ENGINE.
o At least 1,800 concurrent run-time users for FORMS
MANAGEMENT and to retrieve forms and associated
metadata within 30 seconds.
o At least 1,800 concurrent users for ON-LINE HELP
(i.e., on-line documentation, chat, wiki, etc.,).
o At least 100 concurrent users for DISTANCE LEARNING.
o At least 9,000 concurrent users for the INTRANET
PORTAL.
o At least 25,000 concurrent users for the INTERNET
PORTAL.
o At least 500 concurrent users for the ON-LINE
AUCTION.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. The System MUST provide sufficient capacity to support
5.7 concurrent users for each software elements as follows:
o At least 250 concurrent users for RELATIONAL
DATABASE MANAGEMENT SYSTEM, including OLTP. At
least 50 concurrent users for DATA WAREHOUSE. At
least 100 concurrent users for ELECTRONIC ARCHIVE.
o At least 25,000 concurrent users for APPLICATION
SERVER.
o At least a sufficient number of virtual server instances
to run on virtual machines each of the instances of the
170 Section III. Sample Bidding Forms

software elements (for CLUSTERING AND

VIRTUALIZATION),
o At least 500 concurrent users for MANAGEMENT
INFORMATION SYSTEM (MIS).
o At least 150 concurrent users for CUSTOMER
RELATIONSHIP MANAGEMENT AND INTERACTIVE VOICE
RECOGNITION (CRM-IVR).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

6–Services

Tech. Require. No. Project Planning. In accordance with GCC/SCC 19 and by

6.1 the delivery deadline stated in the Implementation Schedule,
(in close dialog with the Purchaser) the Supplier MUST
prepare, present, revise and finalize the Agreed Project Plan
(based on the Supplier’s Preliminary Project Plan submitted
as part of its bid). The Agreed Project Plan MUST present at
least the following time and resource bound sub-plans (as
well as others sub-plans as necessary and appropriate)::
o Project Organization and Management Sub-Plan
o Testing and Quality Assurance Sub-Plan
o Analysis and Detailed Design Sub-Plan
o Installation, Configuration, Customization and
Integration Sub-Plan
o Data Migration Sub-Plan
o Production Transition and Roll-out Sub-Plan
o Human Capacity Building Sub-Plan
o Warranty Defect Repair and Technical Support
Service Sub-Plan
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Project Organization and Management. In accordance with
6.2 the Project Organization and Management Sub-Plan of the
Agreed Project Plan – with the close involvement of the
Purchaser – the Supplier MUST establish a project delivery
organization with sufficient resource to accomplish the
technical, administrative and manager tasks required to
perform the Contract. MUST include at a minimum key
experts as specified below (see Paragraph 7). MUST
establish and perform project management functions in
accordance with a formal project management method (e.g.,
PMI-PMBOK, PRINCE-2, TEMPO, or equivalent). MUST
prepare and maintain a high-level phased project plan to
deliver and implement the System. MUST prepare and
maintain task time and resource schedules. MUST prepare
and maintain progress reporting and problem escalation
mechanisms. MUST prepare and maintain a Change Order
Management system supported by a table of all-inclusive
daily fee rates for the main categories of expert input (as
appropriate for the technical characteristics of the System and
the Supplier’s methodologies) – to be agreed with the
Purchaser as part of the Project Organization and
Management Sub-Plan of the Agreed Project Plan.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Testing and Quality Assurance. In accordance with the
6.3 Testing and Quality Assurance Sub-Plan of the Agreed
Project Plan – with the close involvement of the Purchaser –
the Supplier MUST establish and perform the Verification,
Validation and Quality Assurance Processes for each of the
major work streams required to realize the System: Project
Organization and Management; Analysis and Detailed
Design; Installation, Configuration and Customization;
Production Transition and Roll-Out; Data Migration; Human
Capacity Building; as well as Warranty and Technical
Support. As appropriate, the Verification, Validation and
Quality Assurance Processes MUST conform to:
ISO/IEC/IEEE 29119 Software Testing Standard (parts 1-5);
ISO/IEC 15504 Information Technology-Process
Assessment; ISO/IEC 12207:2008 Systems and Software
172 Section III. Sample Bidding Forms

Engineering – Software Lifecycle Processes; ISO/IEC 15288

Systems Engineering.

Among many other things, as part of the detailed Testing

Design, the Supplier MUST document in detail the test
data that will be required at each critical stage of the
Verification and Validation Process. These data –
appropriately anonymized – will be sourced from the
Purchaser’s systems.

In addition to the Installation and Operation Acceptance

Test specified below in Paragraph 8, the Supplier must
demonstrate functional and performance the System /
Subsystems as a control to the transition from the Pre-
Production versions to the Production Version (in
accordance with the Implementation Schedule). In
particular, the performance tests MUST demonstrate the
System performance requirements specified in
Paragraph 5 above on the Purchaser’s production platform
(i.e., the software components, elements, etc. supplied
under the Contract plus the hardware elements as
specified by the Supplier in accordance with
Paragraph 6.5below). The Supplier MUST provide any
additional software, equipment, and tools, (i.e.,
“Supplier’s Equipment” as defined in the GCC/SCC) as
well as staff inputs, required to simulate the loads and
record the results. The performance tests MUST be
performed on the following set-ups:

o Simultaneous 12,000 internal users accessing the

System data with read-only capabilities and a setup of
simultaneous 3,000 internal users accessing the
system data with write and edit capabilities (the “Peak
System Load for Internal Access” set-up).

o Simultaneous 100,000 external users accessing the

System data with read-only capabilities and a setup of
simultaneous 10,000 external users accessing the
system data with write and edit capabilities (the “Peak
System Load for External Access” set-up).

The System tests MUST demonstrate that under Peak

System Load for Internal Access and External Access set-
ups:

o All queries must generate and retrieve a document in

no more than 5 seconds (on average for at least 100
test runs).

o All queries must deliver 100% application

 functionality.

o All user interfaces (for internal and external access)

must deliver a 99.9% uptime (i.e., no more than 9
hours of unplanned downtime annually).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Testing and Quality Assurance. In accordance with the
6.4 Testing and Quality Assurance Sub-Plan of the Agreed
Project Plan – with the close involvement of the Purchaser –
the Supplier MUST establish and perform the Verification,
Validation and Quality Assurance Processes for each of the
major work streams required to realize the System: Project
Organization and Management; Analysis and Detailed
Design; Installation, Configuration and Customization;
Production Transition and Roll-Out; Data Migration; Human
Capacity Building; as well as Warranty and Technical
Support. As appropriate, the Verification, Validation and
Quality Assurance Processes MUST conform to:
ISO/IEC/IEEE 29119 Software Testing Standard (parts 1-5);
ISO/IEC 15504 Information Technology-Process
Assessment; ISO/IEC 12207:2008 Systems and Software
Engineering – Software Lifecycle Processes; ISO/IEC 15288
Systems Engineering.

Among many other things, as part of the detailed Testing

Design, the Supplier MUST document in detail the test data
that will be required at each critical stage of the Verification
and Validation Process. These data – appropriately
anonymized – will be sourced from the Purchaser’s systems.

In addition to the Installation and Operation Acceptance Test

specified below in Paragraph 8, the Supplier must
demonstrate functional and performance the System /
Subsystems as a control to the transition from the Pre-
Production versions to the Production Version (in accordance
with the Implementation Schedule). In particular, the
performance tests MUST demonstrate the System
performance requirements specified in Paragraph 5 above on
the Purchaser’s production platform (i.e., the software
components, elements, etc. supplied under the Contract plus
the hardware elements as specified by the Supplier in
174 Section III. Sample Bidding Forms

accordance with Paragraph 6.5below). The Supplier MUST

provide any additional software, equipment, and tools, (i.e.,
“Supplier’s Equipment” as defined in the GCC/SCC) as well
as staff inputs, required to simulate the loads and record the
results. The performance tests MUST be performed on the
following set-ups:

o Simultaneous 12,000 internal users accessing the

System data with read-only capabilities and a setup of
simultaneous 3,000 internal users accessing the
system data with write and edit capabilities (the “Peak
System Load for Internal Access” set-up).

o Simultaneous 100,000 external users accessing the

System data with read-only capabilities and a setup of
simultaneous 10,000 external users accessing the
system data with write and edit capabilities (the “Peak
System Load for External Access” set-up).

The System tests MUST demonstrate that under Peak System

Load for Internal Access and External Access set-ups:

o All queries must generate and retrieve a document in

no more than 5 seconds (on average for at least 100
test runs).

o All queries must deliver 100% application

functionality.

o All user interfaces (for internal and external access)

must deliver a 99.9% uptime (i.e., no more than 9
hours of unplanned downtime annually).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ICT Platform Specification. On the basis of the detailed
6.5 System design and the work-load/sizing analysis, the Supplier
MUST prepare a open-system, vendor neutral ICT platform
specification that will achieve the System performance norms
specified above in Paragraph 5.Furthermore the specification
MUST allow the System with 2,500 concurrent users to
achieve no more than 3 (three) second response time for 95%
of all application-related transactions other than MIS queries,
 MIS report generations and all login operations. The
specification MUST ensure ICT platform reliability of 99.9%.
The specification MUST ensure ICT platform recovery time
objective (RTO) of 15 (fifteen) minutes for disaster-recovery.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. ICT Platform Specification. The Supplier MUST provide
6.6 the specifications in sufficient depth and detail as to form the
Technical Requirements Section of a international
competitive bidding process under World Bank procurement
guidelines.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Data Preparation for Migration. In accordance with the Data
6.7 Migration Sub-Plan of the Agreed Project Plan, the Purchaser
will provide access for the Supplier to the production data.
With the close support of the Purchaser, the Supplier MUST
centralize, clean, normalize and convert (to data migration
formats) the production data. The Purchaser will be
responsible for the quality of the input data. The Supplier
will be responsible for the quality of the data prepared for
migration. The Supplier and the Purchaser will be jointly
responsible to identifying residual quality/alignment
problems in the data prepared for migration. The Supplier
will be responsible to correct the quality/alignment problems
in the prepared data. Informational Annex 6 describes the
various datasets that will need preparation/migration.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

176 Section III. Sample Bidding Forms

Tech. Require. No. Test Data Migration. In accordance with the Testing and
6.8 Quality Assurance Sub-Plan of the Agreed Project Plan, the
Purchaser will make available – appropriately anonymized –
test data extracted from its various systems. The Supplier
MUST work with the Purchaser to ensure the test data are
properly structured/formatted to be migrated into the data
model of the System. (As soon as possible in the execution
of the Contract, the Supplier MUST share the data model of
the System with the Purchaser, to accelerate the data cleaning
and preparation activities by the Supplier.) The migration
will be the responsibility of the Supplier. The Supplier will
be responsible for the quality of the test data (i.e., cleaned and
centralized in preparation) using inputs from the Purchaser’s
systems. The Supplier and the Purchaser will be jointly
responsible to identifying residual quality/alignment
problems in the test data prepared. The Purchaser will be
responsible to correct the quality/alignment problems in the
test data extracted.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Pre-Production Implementation. In accordance with the

6.9 Installation, Configuration, Customization and Integration
Sub-Plan – and as reflected in the Implementation Schedule –
the Supplier MUST Install, Configure, Customize and
Integrate the Pre-Production System in a phased/sequenced
manner. For example: Configuration V.1 = Full
functionality “out-of-the-box” configuration; Configuration
V.2 = Customized and Localized version and interfaces. As
reflected in the Implementation Schedule, the Configuration
V.1 would be loaded with test data set 1 (anonymized test
data) and then tested. Configuration V.2 should be first
loaded with test data set 1, retested to confirm the new
functionality, then loaded with tests data set 2 (pre-production
real data) and then tested to reconfirm functionality and
capacity. Systems Integration should also be staged, with the
Pre-Production Versions using mock-up interfaces for the
internal and external systems The Purchaser will provide the
development and test hardware platform (and relevant system
software) to run and test the Pre-Production versions of the
System. The technical description of the Test and
Development hardware platform is presented in Informational
 Annex 3.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. System Integration. In accordance with the Installation,

6.10 Configuration, Customization and Integration Sub-Plan, the
Supplier should be responsible for the technical integration of
the System with of the Purchaser’s internal business systems
as well as external systems that the System will receive
and/or transmit information to. The Suppler MUST analysis
the technical and logical features of the systems to be
integrated in sufficient depth and detail that the Purchaser can
ready the internal systems to realize the technical interface as
well as align the semantics, syntax and coverage of the
logical interface. Similarly, the Supplier’s analysis MUST be
of sufficient depth and detail to allow the Purchaser to
coordinate/negotiate the technical and logical alignment of
external business systems. The Supplier and the Purchaser
should be jointly responsible for achieving the alignment, as
well as monitoring the continued alignment of the various
systems through the Operational Acceptance Processes. The
inventory of internal and external systems that MUST be
integrated is presented in Informational Annex 4 - Table
"Existing Systems to be Interoperable with RMS". The
Purchaser will provide further detailed descriptions in the
technical document of ANAF’s Enterprise Architecture (in
the format of TOGAF 9®).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Production Transition and Roll-Out. In accordance with the
6.11 Production Transition and Roll-out Sub-Plan of the Agreed
Project Plan, the Supplier (with the active assistance of the
Purchaser) MUST:

 Install and configure the System on the production

ICT platform (including, but not restricted to,
178 Section III. Sample Bidding Forms

implementing the systems and security administration

features).
 Migrate the data from the cleaned data stores (and, as
appropriate, from the Purchaser’s production systems)
to the production systems installed on the production
ICT platform.
 Manage and closely monitor the system roll-out in the
agreed functional, organizational/geographical
sequence – with the agreed stock-taking, review and
revision mechanisms.

 Implement follow-up/refresher training for the system

and business administration personnel, as well as the
line-of-business user trainers.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Production Data Migration. In accordance with the

6.12 Production Transition and Roll-out Sub-Plan of the Agreed
Project Plan, the Purchaser will be responsible to ensure the
full inventory of the data required to put the System into
Production Operation is properly cleaned and structured to
allow a timely migration and an orderly parallel operation
(during Operational Acceptance Testing). Once the
customizations are implemented in Configuration V.2, the
Supplier MUST provide the revised full data model of the
RMS to the Purchaser. The migration of the production data
will be the responsibility of the Supplier. The Supplier and
the Purchaser will be jointly responsible to identifying
residual quality/alignment problems in the production data.
The Purchaser will be responsible to correct the
quality/alignment problems (including any ad hoc business
rule changes required). The Supplier will be responsible for
quality of the production data (i.e., cleaned and centralized).
Pending residual migration issues related to the quality
/alignement data (up to 0.1 % (onetenthofapercent) of the
total data to be migrated) would not affect the completion of
the acceptance procedures.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Continuous Production Data Quality Control and Cleaning.
6.13 Testing and Quality Assurance Sub-Plan of the Agreed
Project Plan, the Supplier MUST prepare a facility to monitor
the quality of the production data and to perform
corrections/data cleaning in joint cooperation with the
Purchaser. The facility to monitor the quality of the
production data MUST be handed over to the Purchaser at the
end of the Technical Support phase.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Human Capacity Building. In accordance with the Human
6.14 Capacity Building Sub-Plan of the Agreed Project Plan, the
Supplier MUST develop and formally document the scheme
of roles and jobs required to manage, operate and sustain the
System (including required roles of the Purchaser’s personnel
for design, development, review, verification and validation
processes). In documenting the scheme of roles and jobs, the
Supplier MUST develop formal job descriptions in the
Purchaser’s institutional standard format. For each of the
operational jobs, the Supplier MUST develop and document a
workload model (to inform the Purchaser’s staffing plans, as
well as inform the transition planning into full system
operation).
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Training Development. On the basis of the scheme of roles
6.15 and jobs, and in accordance with the Human Capacity
Building Sub-Plan of the Agreed Project Plan, the Supplier
MUST prepare curriculum, materials, course-plans and
180 Section III. Sample Bidding Forms

certification processes to cover each of the roles and jobs in

the scheme. These MUST be delivered in hard copy and
digital format in the Romanian Language. These MUST be
delivered with a limited not-for-resale copyright agreement,
that will allow the Purchaser to further to replicate, change,
adapt and use the training materials, for future training
programs, for existing and future users of the RMS
Information System. All the copyrighted materials, inserts,
citations and other references to copyrighted materials part of
the training materials to be delivered by the Supplier, MUST
be marked appropriately, and described as such. The roles
and jobs in the scheme include, but are not restricted to:

 Business line managers

 Business functions administrative
 Line-of-business users
 System administration
 Technical support
 Trainers
The subject areas also MUST cover:
 The Supplier’s formal system development
methodology and documentation (including the
Verification, Validation and Quality Assurance
processes).
 The technical features and configuration of the major
components of the System.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Training. On the basis of the roles/jobs scheme and in
6.16 accordance with the Human Capacity Building Sub-Plan of
the Agreed Project Plan, the Supplier MUST implement the
developed training programs. The Supplier must perform the
training in classroom/laboratory settings established on
premises in Bucharest provided/contracted by the Purchaser.

The training on the Supplier’s formal systems development

methodology and on the technical features of the major
components of the System MUST be provided as soon as
practical, to prepare the Purchaser’s key personnel to be
effective counterparts to the Supplier in the development and
testing processes. The participants in these courses should
include approximately:
 12 functional area managers (representing the
business line departments at headquarters)

 12 regional office managers (i.e., representing a

selection of the regional offices)

 4 RAMP project management personnel

 12 senior staff and mangers of the General Directorate

of IT (DGIT)

The training on business function administration MUST be

synchronized with the timing of the implementation and
testing of the sequence of pre-production versions of the
System – i.e., sufficiently in advanced to ensure the
Purchaser’s personnel are ready to participate, but not so
advanced that the knowledge imparted depreciates. The
participants in these courses should include approximately:
 32 functional area managers and senior specialists

The training on system administration MUST be

synchronized with the timing of the implementation and
testing of the sequence of pre-production versions of the
System – i.e., sufficiently in advanced to ensure the
Purchaser’s personnel are ready to participate, but not so
advanced that the knowledge imparted depreciates. The
course/participants should include approximately:
 5 database designers

 5 database administrators

 5 system engineers/system administrators

 30 application developers/designers

 64 first-line technical support staff

 80 technical trainers (for training end-users)

The training for line-of-business users MUST be

synchronized with the timing of the implementation and
testing of the sequence of pre-production versions of the
System, as well as during the production roll-out phase. The
training must implement a train-the-trainers model. The
courses need to be segmented by the main business function
areas. The participants in these courses should include
182 Section III. Sample Bidding Forms

approximately:
 160 training specialists

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Technical Support (Warranty Period). In accordance with the
6.17 Warranty Defect Repair and Technical Support Service Sub-
Plan of the Agreed Project Plan, during the Warranty Period
the Supplier MUST:

 Maintain 24x7x365 a single integrated point of

contact for trouble reporting, technical queries and
assistance requests (with voice, e-mail, chat, SMS and
web portal channels). Provide monthly logs of in-
coming and out-going communications with five
working days of the close of the respective month.
 Maintain 12x5x52 (Romanian time) Help Desk.
 Provide continuous access to software versions,
releases, and updates, as well as commentaries and
bodies of knowledge for the System and all of its
components (inclusive of any third-party components
of the System). Ensure all relevant software licenses
are paid-up, up-to-date and continuously valid for the
configuration of the System.
 Provide at least 8x5x52 on-site system monitoring,
trouble-shooting and defect repair technical support
by at least one (1) qualified System Specialist,
working according to the business hours of ANAF.
 Provide up to two hundred twenty (220) person-days
of technical assistance (on site and remote) by Senior
System Specialists/Analysts to ensure the System
properly functions and remains consistent with the
Romanian Legislation and Regulations and up-to-date
with then current version of the System (software).
Following a formal request from the Purchaser, the
Supplier must respond to the request within one (1)
business day and mobilize the appropriate team within
five (5) business days.
Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply
 Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

7–The Supplier’s Team

Tech. Require. No. Supply and Install Period. The Supplier MUST establish and
7.1 maintain a team during the Supply and Install Period with the
following minimum composition and minimum experience.
The team MUST maintain a presence on-site as required to
perform the above services in a timely manner consistent with
the Implementation Schedule.

 Team Leader with documented experience in leading

large teams and leading the interactions with senior
client management in at least two successful
implementations of integrated revenue administration
systems using the System’s core RMS product.
General qualifications must include an university
degree in the field of Business Administration /
Business Management / Economics / ICT /
Engineering and fluency in English language (spoken
and written).
 Senior Functional Specialists with documented
experience in the analysis and successful
implementation in at least two revenue administration
projects. Expertise may be combined in any
combinations of Senior Functional Specialists,
provided all functional areas list below are covered
(with the minimum number of successful
implementations).
o Taxpayer Registration
o Returns Processing
o Payments Processing
o Taxpayer Accounts / Ledger
o Refunds processing
o Revenue collection
o Reconciliation
o Revenue Accounting
o Revenue Enforcement
184 Section III. Sample Bidding Forms

o Taxpayer Audit
o Risk Management and monitoring
General qualifications must include a university
degree in the field of Business Administration /
Business Management / Economics / ICT /
Engineering and fluency in English language (spoken
and written).
 Business Process Analysts (at least 3 specialists) with
documented three years successful experience in the
formal process analysis/documentation employed by
the Supplier. General qualifications must include a
university degree in the field of Economics / Business
Administration / Business Management / ICT /
Engineering and fluency in English language (spoken
and written).
 Senior ICT Implementation Specialist with
certification(s) in the formal project management
processes employed by the Supplier and documented
experience in at least one successful implementation
of an integrated revenue administration system using
the System’s core RMS product. General
qualifications must include a university degree in the
field of Economics / Business Administration /
Business Management / ICT / Engineering and
fluency in English language (spoken and written).
 Senior Validation and Verification (QA) Specialist
with certification(s) in the formal validation and
verification (QA) processes employed by the Supplier
and documented experience in at least one successful
implementation of an integrated revenue
administration system using the System’s core RMS
product. General qualifications must include a
university degree in the field of Economics / Business
Administration / Business Management / ICT /
Engineering and fluency in English language (spoken
and written).
 Senior Software Developers with documented
successful experience in the deployment and
customization of at least one successful
implementations of an integrated revenue
administration system using the System’s core RMS
product (in sufficient number to demonstrate
successful experience in interface development for all
the functional areas noted above). General
qualifications must include a university degree in the
field of Economics / ICT / Engineering and fluency in
 English language (spoken and written).
 Senior ICT Platform Specialists with documented
successful experience in the installation and
integration of the software element and technical
management tools provided under the Contract (in
sufficient number to demonstrate successful
experience in interface development for all software
element and technical management tools provided
under the Contract). General qualifications must
include a university degree in the field of ICT /
Engineering and fluency in English language (spoken
and written).
 Senior Training Specialists with documented
experience in the development and implementation of
technical and user training programs in at least one
successful implementation of an integrated revenue
administration systems using the System’s core RMS
product. General qualifications must include a
university degree in the field of Economics / Business
Administration / ICT / Engineering and fluency in
English language (spoken and written).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Candidate & Candidate’s Experience – Team Leader:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidates &Candidates’ Experience – Senior Functional Specialists:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidates &Candidates’ Experience – Business Process Analysts:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior ICT Implementation Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):
186 Section III. Sample Bidding Forms

Candidate(s) &Candidate’s(s’) Experience – Senior Validation and Verification (QA)

Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior Software Developer(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior ICT Platform Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior Training Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to CVs and appropriate written recommendations):

Tech. Require. No. Supplier’s Team (Warranty Period). The Supplier MUST
7.2 establish and maintain a stable team with the same minimum
skills and minimum experience as during the Supply and
Installation Period – except that the Team Leader, instead,
MUST have documented experience in managing technical
support teams (including client relations) in at least one
successful implementation of an integrated revenue
administration systems using the System’s core RMS
product. General qualifications must include an university
degree in the field of Business Administration / Business
Management / Economics / ICT / Engineering and fluency in
English language (spoken and written).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Candidate & Candidate’s Experience – Team Leader:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidates &Candidates’ Experience – Senior Functional Specialists:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidates &Candidates’ Experience – Business Process Analysts:

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior ICT Implementation Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior Validation and Verification (QA)

Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior Software Developer(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior ICT Platform Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):

Candidate(s) &Candidate’s(s’) Experience – Senior Training Specialist(s):

Bidder’s cross-references to supporting materials in Technical Bid (including, but not

restricted to, CVs and appropriate written recommendations):
188 Section III. Sample Bidding Forms

8 - Inspections, Installation and Operational Acceptance Testing and Control of

Technical Support Services

Tech. Require. No. Delivery. The one-time and all-encompassing Delivery

8.1 milestone should be achieved when:

 The Purchaser formally confirms and documents the

completeness (and validity) of the software licenses
for all components of the System (inclusive of
certificates of origin, manufactures’ certificates of
conformity, manufactures’ certificates of quality, and
license certificates).
 The Purchaser formally accepts the Supplier’s
submission of final Verification and Validation
reports for all the planning, analysis, design and
training documentation(and verify that the Supplier
grants to the Purchaser not-for-resale unrestricted
rights to store, duplicate and communicate the various
documents/materials created and supplied under the
Contract).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Installation. The one-time and all-encompassing Installation

8.2 milestone should be achieved when:

 The Purchaser formally accepts the Supplier’s

submission of final Verification and Validation
reports for the last pre-production version of the
System and the provision of the corresponding agreed
training programs.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Operational Acceptance. The one-time and all-encompassing
8.3 Operational Acceptance milestone should be achieved when:

 The Purchaser formally accepts the Supplier’s

submission of final Verification and Validation
reports for the last iteration of the production version
of the System required to complete the phased
national roll-out (including, but not restricted, to the
overall system performance and capacity requirements
specified above).

 The Purchaser formally confirms that all System and

implementation related documentation is complete,
up-to-date and subject to not-for-resale unrestricted
rights to store, duplicate and communicate.

 The Purchaser formally confirms the Technical

Support arrangements are established and
satisfactorily pass initial testing.

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Tech. Require. No. Technical Support. Technical Support Services (during the
8.4 Warranty Period) should be controlled on a monthly and
twice-yearly basis. In accordance with the with the Warranty
Defect Repair and Technical Support Service Sub-Plan of the
Agreed Project Plan:

 On a monthly basis, the Purchaser MUST formally

accept and document the provision of the Supplier’s
monthly reports, including, but not restricted to: the
contact center’s monthly logs of in-coming and out-
going communications; a comprehensive summary of
the Supplier’s support activities (requested,
commenced, completed and on-going); issues
requiring the Purchaser’s management attention
and/or action; etc.

 On at least a twice yearly basis, the Purchaser MUST

review the Supplier’s monthly reports for the
preceding six months, meet with the Supplier’s Team
190 Section III. Sample Bidding Forms

Leader to discuss the performance of the past six

months and expectations for the subsequent six
months, and review the Supplier’s minutes of the
review meeting. The Purchaser’s formal acceptance
of the meeting minutes should constitute satisfactory
performance of the Supplier’s Technical Support
Services for the period (and trigger the corresponding
payment under the Contract).The Purchaser reserves
the right to shorten the six-month review period to, for
example, address any quality or performance concerns
the Purchaser may have. With appropriate advance
notice, the Purchaser shall inform the Supplier in
writing of the change in this requirement and the
ramifications for the payment schedule.

 For the final six month period under the Contract, in

addition to the above six-month requirements, the
Supplier MUST demonstrate to the Purchaser’s
satisfaction that the system documentation (hard copy
and digital) is complete and up-to-date (i.e., that it
reflects all the changes implemented during the
Warranty Period). Moreover, the Supplier MUST
deliver to the Purchaser the up-to-date, fully
documented and commented source code or all
Custom Software developed under the Contract (and
formally designated as such). The Purchaser should
formally document to the Supplier that the Purchaser
will NOT to transfer the code to any other external
party and will use it ONLY for the purpose of
updating/further developing NAFA's IT system(s).

Bidder’s confirmation of requirement: ☐ - comply ☐ - non-comply

Bidder’s technical reasons supporting compliance/non-compliance:

Bidder’s cross-references to supporting materials in Technical Bid:

Section IV: Eligible Countries 191

SECTION IV. ELIGIBLE COUNTRIES FOR THE PROVISION

OF GOODS, WORKS, AND SERVICES IN BANK-FINANCED
PROCUREMENT
192 Section IV: Eligible Countries

Eligible Countries for the Provision of Goods, Works, and Services in

Bank-Financed Procurement

1. Eligible for this procurement are firms of, and goods manufactured in, all countries
except countries, if any, listed in the following restrictions.
2. In accordance with paragraph 1.8 (a) of the Guidelines: Procurement under IBRD
Loans and IDA Credits, firms of a Country or goods manufactured in a Country may
be excluded if
(i) as a matter of law or official regulation, the Borrower’s Country prohibits
commercial relations with that Country, provided that the Bank is satisfied that
such exclusion does not preclude effective competition for the supply of the
goods or works required, or
(ii) by an Act of Compliance with a Decision of the United Nations Security
Council taken under Chapter VII of the Charter of the United Nations, the
Borrower’s Country prohibits any import of goods from that Country or any
payments to persons or entities in that Country.
PART 2 – PURCHASER’S REQUIREMENTS 193

PART 2 – PURCHASER’S
REQUIREMENTS
Section V. Requirements of the Information System 195

SECTION V. REQUIREMENTS OF THE INFORMATION

SYSTEM
(INCLUDING TECHNICAL REQUIREMENTS, IMPLEMENTATION SCHEDULE,
AND INFORMATIONAL ANNEXES)

Table of Contents: Technical Requirements

Acronyms Used in The Technical Requirements..............................................................196
Functional Requirements....................................................................................................196
General and Non-Functional Requirements.....................................................................213
Sizing and Performance......................................................................................................228
Service Specifications...........................................................................................................232
The Supplier’s Team............................................................................................................239
Testing and Quality Assurance Requirements..................................................................241

Implementation Schedule
A. Implementation Schedule.....................................................................................244
B. Site Table...............................................................................................................247
C. Table of Holidays and Other Non-Working Days.............................................277

Informational Annexes
Annex 1: The Purchaser’s Organization..........................................................................279
Annex 2: Romanian Tax System (2015)............................................................................293
Annex 3: ANAF’s Test and Development Platform.........................................................338
Annex 4: Legacy Systems for Integration.........................................................................341
Annex 5: Detailed Functional Design Goals.....................................................................406
Annex 6: Databases for Migration....................................................................................558
Annex 7: Selected Acronyms..............................................................................................571
196 Section V: Requirements of the Information System

Technical Requirements

ACRONYMS USED IN THE TECHNICAL REQUIREMENTS

See Informational Annex 7 for a list of selected acronyms.

FUNCTIONAL REQUIREMENTS

1. Revenue Types. The System MUST embody a functional model for ANAF’s
administration all the taxes, duties, levies, social contributions and deductions in the
Romanian Tax Code – including all functions distributed across: Headquarters,
Regional Offices, District/County Offices, Municipal/Town/Communal Offices. (See
Informational Annex 1 for detailed organograms; also see Informational Annex 2fora
description of the Romanian Tax System and the Tax Nomenclature as of 2015.
Further details about all the present and past categories are available at:
www.anaf.ro.)

2. Functional Scope. The System MUST provide fully integrated automation support
for the following business segments:

 TAXPAYER REGISTRATION (TR)

 RETURNS PROCESSING (RP)
 PAYMENT PROCESSING (PP)
 TAXPAYER ACCOUNTS / LEDGER (AL)
 REFUNDS PROCESSING (RF)
 RECONCILIATION (RR)
 REVENUE COLLECTION (RC)
 REVENUE ENFORCEMENT(RE)
 TAXPAYER AUDIT (AU)
 ANTI-FRAUD / CRIMINAL INVESTIGATION (FR)
 OBJECTIONS AND APPEALS (AP)
 REVENUE ACCOUNTING (AC)
 REVENUE RISK ANALYSIS (RM)
 INTERNAL AUDIT (IA)
 INTERNAL CONTROL (IC)
Section V. Requirements of the Information System 197

 MANAGEMENT INFORMATION / DECISION SUPPORT (REP)

 TAXPAYER SERVICES INTERFACE (TS)
The System MUST provide full support for the following general requirements,
on all its business segments:
MUST interface and provide comprehensive operations logs for tax audit,
taxpayer audit, internal control and internal audit. MUST push data in a timely
manner to the MIS for executive and operational reports, for the dashboard of the
Ministry of the Public Finances / National Agency for Fiscal Administration, and
for the calculation of the key performance indicators. MUST provide advanced
reporting and notification of the interested parties (internal control staff, ANAF
management, and other ANAF structures) regarding the defined and approved
revenue collection objectives, risks, KPIs and targets. MUST generate all the
administrative documents legally specified. MUST interface with ANAF’s Mass
Printing Facility to print, mail and distribute the administrative documents to the
taxpayers. MUST file the administrative documents (e.g. notifications, etc.) in the
taxpayer file in the Document Management System. MUST provide interfaces for
data exchange with third party data sources, including format conversion and data
extraction functions. The System MUST accept data from 3rd party sources at
least in following file formats: .TXT, .CSV, .XLS, .XLSX, .ODF, .XML, .PDF
(including intelligent forms and digitally signed documents) etc. MUST
implement multiple currencies (i.e. at least Romanian New Leu and Euro) and
multiple denomination of the local currency (i.e. Romanian Leu (ROL) and
Romanian New Leu (RON)).

2.1. Taxpayer Registration (TR) –MUST support the following business processes:

 TR01 – Initial Taxpayer Registration

 TR02 – Registration Maintenance

 TR03 – Registration Maintenance – update based on return processing

 TR04 – Re-Classify Taxpayer

 TR05 – Inactivate / Reactivate / Radiate Taxpayer (voluntary)

 TR06 – Inactivate Taxpayer (suo-moto) / Reactivate Taxpayer

 TR07 – Managing Taxpayer Risk History and Profile

 TR08 – Taxpayer Registration Audit

The System MUST provide complete workflows forbusiness processes above.
MUST implement a Taxpayer Register for all the categories of taxpayers and the
related categories databases. MUST provide flexible interactive functions for the
tax officers for pre-filling, validation, filling, verification, crosschecking, and
correction of taxpayers’ applications. MUST manage the Taxpayer
administrative information specific to all the states of Taxpayer in relation to
ANAF (i.e. new applicant, registered, active, inactive, suspended, radiated, etc.,).
198 Section V: Requirements of the Information System

MUST verify and validate the taxpayer information with ANAF and 3 rd party
public data sources (e.g. address and postal codes catalogs, police records,
taxpayer register, other). MUST provide a user interface for the taxpayer
registration process on the Internet Portal, for pre-filling the applications. MUST
provide on-line and off-line electronic filling of the applications with secure
multipage intelligent forms, able to attach multiple large support documents in
digitized format in the Internet Portal. MUST provide taxpayer assistance
information on the Internet Portal, to guide the applicants in the registration
process. MUST maintain the information about the taxpayer for the taxpayer
office via the Intranet Portal and for the taxpayer via the Internet Portal, including
logging of the changes made in the taxpayer information. MUST record all the
changes in the Taxpayer status and interface with Returns Processing (RP),
Payment processing (PP), Taxpayer Accounts / Ledger (AL), Refunds processing
(RF), Revenue Collection (RC), Revenue Enforcement (RE), Taxpayer Audit
(TA) and Revenue Risk Management (RM) to activate, deactivate, recalculate,
set / reset the related tax obligations and their deadline for collection. MUST
provide notifications via e-mail to the taxpayer and to the tax officer about all the
changes made in the taxpayer information. MUST enroll taxpayers in the
WebSpace, with unique user identity and security information. MUST interface
with the Trade Register via the existing IT solution (Web-service) to complete the
registration of the taxpayer. MUST generate unique TIN/PIN for each new
taxpayer. MUST create taxpayer records in the Taxpayer Register, including the
initial the taxpayer risk history and profile data for all the new taxpayers. MUST
initialize the taxpayer risk history and profile data for existing taxpayers from
upload files migrated from the legacy systems, containing historical records.
MUST calculate and record the risk score for all the categories of taxpayers
migrated from the legacy systems, considering all the historical records and the
new scoring rules defined in the system at initialization. MUST recalculate the
risk score, when changes or updates are made in the taxpayer’s registered
information. MUST create a taxpayer account in the taxpayer accounts ledger.
MUST build the taxpayer file with all the taxpayer documents in digital format,
proofed and signed electronically, and stored in the Document Management
System. MUST provide taxpayer registration audit (registration record
validation), including but not limited to notices to taxpayer registration auditors,
sorting of the incoming audit work by type, assigning registration notices by area,
registration audit prioritization, scheduling the registration audit, assign auditor,
register audit result, update taxpayer risk history and profile database.

2.2. Returns Processing (RP) – MUST support the following business processes:

 RP01 – Pre-Filing Return Preparation Process

 RP02 – Receiving the tax / informative return

 RP03 – Pipeline Processing

 RP04 – Data verification / Matching

 RP05 – Converting Returns’ Data to Postable Format

Section V. Requirements of the Information System 199

The System MUST provide complete workflow for Returns Processing, with a
dialog on the tax returns submitted via all the taxpayer communications
channels (i.e., digitally signed intelligent forms via the WebSpace, paper
signed documents presented over the counter or via post mail, secured records
via the IT interfaces for taxpayers accounting systems, other applicable).
MUST assist the taxpayers with timely feed-back regarding the returns
submitted, including status of the return processing, errors or unconformities
to be corrected, etc. MUST provide programmatic and manual tools to view,
add, correct, or change the returns submitted in the System by the taxpayers.
MUST provide history and activity logs for all the user and System actions on
the returns. MUST store all the returns records in the returns database.
MUST convert all the returns and documents into digitally signed .PDF files
(with appropriate metadata) and file them in the Document Management
System. MUST provide unique identifiers for all the returns and all the
documents submitted for processing, visible both to the taxpayer and the tax
officers in the System and via the WebSpace. MUST provide pre-filled return
forms to the taxpayer basedthe taxpayer’s registration record. MUST support
all the existing tax returns formats and communications channels, as described
in the Informational Annex 4. MUST provide error checks, with automatic
and manual correction and validation. MUST provide acknowledgements to
the taxpayer and to the tax officers via selected communication channels.
MUST refer to a tax officer in case the automatic corrections are not possible.
MUST record the error types and exceptions for further processing
improvement. MUST provide revenue statistics, work performance of the tax
officers, other statistics as appropriate. MUST populate the tax audit folder of
the taxpayer with at least the following documents: an unique case number,
the audit referral document, the current state of the taxpayer account, the
returns documents for a number of years (e.g. the past five years), the
taxpayer’s risk history and profile rating. MUST provide data verification /
matching for VAT – purchaser vs. supplier, based on the summary purchases
and supplier VAT invoices. MUST provide data reconciliation for domestic
and international transactions, including operations between EU member
states and between EU Member states and third states.

2.3. Payments Processing (PP) – MUST support the following business processes:

 PP01 – Payment by Taxpayer

 PP02–System Verification against Payments

 PP03 – Payment Reconciliation

The System MUST provide complete workflow of Payments Processing, using
at least the existing payments channels via the State Treasury (unique
channel): cash payments (over the counter), bank transfers (from commercial
banks to the State Treasury Accounts), treasury transfers (intra-Treasury
transfers from the existing taxpayer accounts with the State Treasury to the
collection accounts), and electronic funds transfers via the commercial banks
(including payments with banking cards – debit and credit cards, and Internet
banking). MUST interoperate with the existing payment processing system of
200 Section V: Requirements of the Information System

the Romanian State Treasury (an application called TREZOR). MUST

implement the algorithms to cover the fiscal obligations of the taxpayer from
consolidated payments made by taxpayer in its unique account in the State
Treasury or from individual payments per each fiscal obligation. MUST
process partial payments and payments in excess of the fiscal obligations.
MUST identify all the payments with a unique ID, correlated with the
taxpayer, payment and payment destination. MUST be able to offset a
payment against a payment due, fully or partially and indicate the amount due
correlated with the reference number of the payment. MUST allow the user to
link a specific payment made to a specific payment due, in the case the System
is not able to make the link automatically. MUST provide acknowledgements
to the taxpayer of all the payments done, via any of the valid communications
channels. MUST implement revenue accounting. MUST track all the
payments processed. MUST post all the information about the payments in
the WebSpace. MUST interoperate with the tax refund functions of the
System, for adjustments against tax liabilities.

2.4. Taxpayer Accounts/Ledger (AL) – MUST support the following business

processes:

 AL01 – Post Liabilities to the Accounts

 AL02 – Filer / Stop Filer

 AL03 – Arrears Management

 AL04 – Recalculating Liabilities based on Amended Return

 AL05 – Issuing Fiscal Certificates / Fiscal Records

 AL06 – Managing Arrears for and from Other Institutions

The System MUST provide complete workflow of accounting the fiscal credit
and payment operations in a unique account for each taxpayer. MUST
provide subaccounts for credits constructed by tax type (See Informational
Annex 2), for each taxpayer. MUST provide a single taxpayer accounts
ledger, accessible based on the unique TIN/PIN of the taxpayer. MUST
implement flexible algorithms for posting liabilities to the taxpayer accounts,
for all the categories of revenues. MUST support adding new categories of
revenues and operations in the taxpayer accounts / ledger. MUST provide
complete logs of the operations in the ledger. MUST provide several posting
files formats to interface with other systems for data exchange (e.g. systems or
functionalities for revenue enforcement, enforced collections, Tax Court,
Internal Audit, Internal Control, Returns Processing, WebSpace, etc.). MUST
implement Directed (ex-officio) Returns on behalf of selected categories of
taxpayers. MUST acknowledge the operation to the users at least via the
WebSpace, e-mail, operational reports and / or Short Messages (SMS). The
system MUST provide arrears management with a full workflow to calculate
interests and penalties, and on a predetermined schedule, calculate interest on
amounts subject to interest and post this interest to the taxpayers’ current
Section V. Requirements of the Information System 201

account for the affected tax type and by tax period. MUST record in the
taxpayer account the necessary changes to enforce legal provisions of the
administrative documents and the relevant amounts. MUST provide complete
workflow and algorithms to calculate the amounts for the amended returns, the
liabilities and penalties due, restitutions and refunds due, etc. MUST interface
with the risk analysis, taxpayer risk history and risk profile to inform decisions
for restitutions and tax refunds (i.e., VAT refund). MUST interface with the
audit and fiscal inspection functions, to pass tax refund cases to their
workflows. MUST provide fiscal certificates / income certificates /
certificates for budgetary obligations eligibility and other administrative
documents in digital format (on the WebSpace) and in printed format to the
taxpayers. MUST interface with the IT systems of the other institutions
ANAF is in relation for the collection of taxes, contributions and / or
deductions. (See Informational Annex 2 and Annex 4.)MUST manage arrears
and the enforced collection for the other institutions that delegated the
collection to ANAF. MUST implement full workflow to centralize,
consolidate and redirect the payments received via the State Treasury, on the
behalf of the beneficiary institutions that has delegated collection to ANAF
(e.g., National health Insurance House, Social Pensions House, Social
Assistance House, etc.) – see Informational Annex 4.

2.5. Refunds Processing (RF) – MUST support the following business processes:

 RF01–Pre-refund Processing and Refund Claim

 RF02–Processing of Refunds

 RF03 – Post-refund Processing

The System MUST provide complete workflow of Refund Processing, from
the refund / restitution demand filling to the posting of refund for processing.
MUST process all the categories of refunds (i.e. provisional refund, annual
assessment refund or refund through a court order). MUST implement all
administrative verifications (e.g. check of arrears, risk profile, risk score, etc.)
required to approve the restitutions and refunds. MUST implement the
hierarchy of approvals in the workflow. MUST interoperate with the existing
payment processing system of the Romanian State Treasury (an application
called TREZOR) to operate refunds. MUST facilitate online submission of
refund claim and of the supporting documents, secured with digital signature.
MUST post acknowledgements, errors, differences, and results of the
processing of the refund claim on the WebSpace. MUST secure the submitted
refunds claim with read only format for the ANAF staff, to enforce that all the
changes and corrections needed are made on the taxpayer end only. MUST
generate letters for claim approval and / or reject. MUST interface with the
WebSpace, ANAF’s Mass Printing Facility and any other communications
channel (e.g. e-mail, SMS, etc.) to communicate the decisions to the taxpayer
in a timely manner. MUST file the claim and all the support documents in the
taxpayer file in the Document Management System.
202 Section V: Requirements of the Information System

2.6. Reconciliation (RR) – MUST support the following business processes:

 RR01 – Third Party Data Repository / Matching

 RR02 – Posting Payments

 RR03– Reconciling Unpostable Payments

The System MUST provide complete workflow for Reconciliation of

payments with fiscal obligations. MUST interface with the State Treasury for
receiving and posting the information about the payments and the reconciled
records. MUST implement all the calculations, algorithms, and methods of
reconciliations. MUST interface with the WebSpace to post information (e.g.
notifications, revenue date, etc.) in the taxpayer private space. MUST log all
the actions and operations in the taxpayer account, all the rules applied for
reconciliation in the order of execution, the results of the reconciliations, for
audit purposes. MUST acknowledge the important processing steps to the
taxpayer (e.g. taxpayer notification about an unpostable payment was credited
in his account and verification is needed). MUST allow manual checks and
corrections.

2.7. Revenue Collection (RC) – MUST support the following business processes:

 RC01 - Automated Collections Notice

 RC02 - Collection Process Preparatory Activities

 RC03 – Collection Process

 RC04 – Alerts and MIS

The System MUST provide complete workflow to generate collection
administrative documents for all taxpayers, all due payments and all periods of
time applicable, based on a pre-programmed schedule. MUST generate users
support documents for the revenue collection activity, including but not
limited to debt lists, due payment notices, tax liabilities reports, taxpayer
history, list of cases, list of updates, collection lists / reports grouped per
taxpayer categories, tax offices, posting files for enforced collection, etc.
MUST provide integration with the Taxpayer Register, the taxpayer accounts /
ledger, Revenue Enforcement (RE) module, Objections and Appeals (AP)
module, Mass Printing Unit, Management of Information System, Document
Management System, Case Management System, WebSpace and other
communication channels. MUST provide system alerts for all the process
deviations, errors, unconformities and / or important events.

2.8. Revenue Enforcement (RE) – MUST support the following business processes:
 RE01 – Automated Enforced Collection
 RE02 - Resource Planning
Section V. Requirements of the Information System 203

 RE03 - Payment Facilities

 RE04 – Guarantees
 RE05 - Precautionary Measures
 RE06 - Summons and Writs of Execution
 RE07 – Garnishments
 RE08 - Seizure of Goods
 RE09 - Transfer of Property
 RE10 - Auctions
 RE11 - Suspension of Enforcement Procedure
 RE12 - Failure to Pay / Debt Write-off
 RE13 - Joint/Subsidiary liability
 RE14 - Collection from/to Other States
 RE15 - Enforced Collection Reporting
 RE16 – Release and Allocation of the Amounts Collected by Enforcement
 RE17 – Insolvency
 RE18 – Referral to the Competent Bodies
 RE19 – Application of Fines by the Enforcement Units
 RE20 – Write-off tax Records
 RE21 – Management and Sale of Seized Goods
 RE22 – Application of International Sanctions
The System MUST provide complete workflow for Enforced Collection. The
System MUST manage the categories of taxes and budgetary obligations
issued by other institutions and sent to NAFA in order to be recovered. MUST
provide case management for each enforced collection case. MUST provide
unique ID number for each enforced collection case. MUST maintain a
collections case folder for each enforced collection case, identified by its
unique ID number. MUST implement an interface between taxpayer account,
Revenue Collection (RC) and the enforced collection, to move automatically
the collection folder from accounts arrears management to enforced collection.
MUST maintain individual process performance and administration data.
MUST monitor all workflows. MUST maintain arrears in enforced collection
inventory. MUST provide operational reports regarding the performance of
the enforced collection processes per each local, county, regional office and
consolidate national wide, with filters and views. MUST provide real time
collections amounts secured (arrears collected and posted to the accounts).
MUST interface with IT systems of the banks in Romania, to check the
accounts the taxpayers with arrears and to secure the amounts to be collected
from these taxpayers’ accounts. MUST prepare and generate individual
enforced collection administrative documents that define how the debt is
satisfied (e.g. payment in installments, bank payment, garnishment, seizure,
another party held liable, insolvency, business bankruptcy, other as per the
case). MUST file all the administrative documents in the taxpayer file in the
Document Management System. MUST interface with the WebSpace and
ANAF’s Mass Printing Facility to communicate the administrative documents
to the taxpayer, via WebSpace, e-mail, SMS, postal mail and / or other
available communication channels. MUST provide resource planning (annual
and monthly plan) for enforced collection activities for the department.
MUST provide automatic planning with manual adjustments of the cases,
204 Section V: Requirements of the Information System

staff, etc. MUST correlate estimated workload for each case with the
resources available. MUST automatically recalculate workload estimates and
adjust plans. MUST maintain an enforced collection database. MUST
provide complete workflow for resource planning, including case creation,
case assignment, case manual changes, case review and monitoring. MUST
provide complete workflow for payment facilities management, with
individual cases per each taxpayer. MUST define, parameterize and change
the legal conditions when payment facilities may be granted and under which
conditions. MUST provide global and individual configurations of the
payment facilities conditions, to be adjusted globally as per the debt collection
strategy. MUST integrate with the Risk Scoring Module to sort the taxpayer
and all type of revenue enforcement cases (including payment facilities)
according to the criteria, parameters, profiles and benchmarks designed by
ANAF at the national, regional and county level. MUST interface with the
taxpayer account to process the requests for payment facilities. MUST
provide payment requests with intelligent documents using the same
technology as the tax returns, the same security features (digital signature,
etc.), and capabilities to attach supporting documents. MUST provide online
requests processing in the WebSpace and manual processing over the counter
or via postal mail. MUST acknowledge the status of the payment facilities
requests processing to the taxpayer and the tax officers in charge with the case
via the valid communications channels. MUST provide flexible
parameterization for the eligibility checks, guarantee amounts, risk ladder,
automatic approval / refusal conditions, interest and penalties calculations,
installment calculation, etc. MUST provide complete guarantees management
workflow, including options management and guarantees in kind with
correlated values, cash guarantees, and others as per the case. MUST provide
a full workflow to manage the precautionary measures applied to a taxpayer in
enforced collection, including but not limited to legal due notification,
patrimonial evaluation, patrimonial seizure or garnishment. MUST provide a
complete workflow to manage the summons and the writs of execution, with
all the necessary legal and operational steps. MUST interface with ANAF’s
Mass Printing Facility to print, mail and distribute the administrative
documents by postal mail with confirmations of receipt. MUST provide a
complete workflow to manage garnishments, from the identifications of the
taxpayers under garnishment procedure, to (but not limited to) identification of
their bank/treasury accounts (issue and send by electronic means of the
garnishment orders, confirmations of the execution of the garnishments, in full
or partial, from one or more accounts, from one or more than one bank, etc.),
or third parties, etc. MUST provide a complete workflow and set of functions
(“instruments”) to manage the seizure of goods for enforced collection, with
all the legal binding steps and procedures. MUST maintain inventories of
seized goods, and the deposit conditions. MUST extract relevant information
about the patrimony of the taxpayer in default from its financial statements
and balance sheets, from the other public registers (cadastre, car register, etc.).
MUST manage the physical inspections and evaluations of the immobile
goods in scope, to assign custodians, or other. MUST manage the goods as
individual items or in lots. MUST manage the transfer of properties, with a
complete workflow including at least the approval and/or the rejection of the
transfer, the debt settling, the recording of the proceedings, the duly legal
Section V. Requirements of the Information System 205

notifications. MUST manage mortgage information related to the goods in

scope for enforcement. MUST manage a pipeline of sale procedures for the
good seized for liquidation of tax debts, including the public auctions
preparation and follow-up. MUST interface with the WebSpace and the
Internet Portal to post public seizure, sales and other public notifications.
MUST manage the replacement of the seized goods and / or other activities
related to the goods seized. MUST provide a complete workflow for the
auctions (sale of seized goods) including but not limited to inventory of the
goods seized, evaluation of the goods, update of the seized goods database,
internal and external evaluations, preparation of the documents for the sale of
the goods, management of the pre-auction proceedings, public information,
verifications of the bidder’s, updates of the risk history for the taxpayer, the
bidders and the buyer(s), bidding proceeding, auction closing (with/without
success), contracting with the winner of the bid, management of the bid bonds,
and other guarantees, follow-up with the payments and the transfer of the
goods. MUST update the taxpayer file in the Document Management System
with all the administrative documents related to the auction (sale) of the seized
goods. MUST provide a complete workflow to release and allocate the
amounts collected by enforcement, case-by-case, good by good, procedure by
procedure. MUST interface with the communications channels to notify all
the interested parties about the amounts resulted from enforced collection, the
existence of other debts, and all the legal procedures. MUST provide
collected amounts distribution, according to the legal provisions in force.
MUST manage the amounts left undistributed, and manage the restitutions
with duly legal taxpayer and public notifications and legal proceedings.
MUST provide alternative workflow for suspension of the enforcement
procedures, with automatic and manual steps. MUST provide complete
workflows to manage the case of failure to pay, using all the information in
the System and in the 3rd party data sources to analyze the debt and the sources
of income of the taxpayer to be used to extinguish the debt. MUST provide
workflow to manage the insolvency situations and the recovery of the bad
debts from the taxpayer, from the joint liabilities, and from other sources.
MUST provide complete workflow for insolvency proceedings from the
notification of the opening of the insolvency procedure to de-registration of
the taxpayer. MUST provide workflows to manage the joint and or subsidiary
liabilities, including but not limited to the identification of the jointly liable
parties, data analysis, prepare the hearings, prepare the supporting information
for the resolutions, manage the dialogue with the liable parties, all the other
legal proceedings related to the debts extinguishing from the joint or
subsidiary party. MUST provide workflow for referring the enforcement
cases to the competent bodies, according to the legislation in force. MUST
implement all the legal steps and proceedings in the Case Management, for
each individual case and for cases correlated (grouped). MUST provide
complete workflow for cases of fines applied by the enforcement units, with
all the legal steps and proceedings. MUST provide complete workflow for the
write-off of the tax records impossible to collect (for the legal or natural
reasons). MUST implement a case workflow for the collection from/to other
states, compliant with the international proceedings for bad debts recovery
from taxpayers with Romanian and international tax residency, or from jointly
responsible taxpayers. MUST prepare the requests for information to other
206 Section V: Requirements of the Information System

states authorities, of the legal documents for the precautionary measures for
taxpayers from other states, of all the legally binding communication (post
mails, digitally signed support documents, etc.) MUST report enforced
collection activities, with reports generated automatically or ad-hoc, in secured
.PDF format, filed in the Document Management System, containing statistics
about the collections activities, the allocation of the resources and the
collection results achieved by organizational unit, area, and case category.
MUST provide workflow to manage the seized goods and its sales, fully
implementing the seized goods valuation procedures, with all the legal and
operational steps. MUST provide a workflow for ANAF’s role in the
application of the international sanctions (i.e., seizure of the goods,
garnishment, legally due communications, etc.,) with respect to both resident
persons registered in Romania or non-residents from states that Romania has
agreements for the automatic exchange of fiscal information. MUST capture
the results of the manual steps performed by the Ministry of External Affairs
regarding the legal compliance with applicable international law. MUST
interface with the WebSpace, to post notifications for the residents enrolled in
the WebSpace. MUST deliver the notifications via all the communication
channels active for the tax payer which is subject to an international sanction –
post mail, e-mail, WebSpace, SMS, etc. MUST provide back-office statistical
totalizer.

2.9. Taxpayer Audit (AU) – MUST support the following business processes:

 AU01 – National Audit Planning

 AU02 – Auditee Selection

 AU03 – Auditor Selection

 AU04 – Audit Scheduling and Budgeting

 AU05 – Audit Preparation

 AU06 – Taxpayer Audit

 AU07 – Audit Resolution

 AU08 – Audit Quality Assurance

 AU09 – Monitoring
The System MUST provide configurable case management and complete
workflows for taxpayer audit, including the fiscal verification, for each audit
case by type of taxpayer, including but not limited to companies, high net
worth individuals, small and medium businesses, etc. MUST provide unique
ID number for each audit case. MUST maintain an audit case folder for each
audit case, identified by its unique ID number. MUST provide yearly audit
cycles, traceable individually, broken down by sub-periods – quarters and
months. MUST provide rules setting for the audit plans, on all parameters,
Section V. Requirements of the Information System 207

criteria, profiles and benchmarks. MUST integrate with the Risk Scoring
Module to generate the selection of audit candidates according to the criteria,
parameters, profiles and benchmarks designed by ANAF at the national,
regional and county level. MUST maintain the history and results of the
previous’ years audit activity. MUST maintain historical records of all legacy
audit cases undertaken before the implementation of the System. The
Purchaser will be responsible to correct the data quality problems regarding
the historical records of all the audit cases undertaken before the
implementation of the System, like missing information, multiple records,
other as per the case. MUST manage the resources and time budget for audit
for each yearly audit plan. MUST record the audit time budget during the
execution of the audit mission, and consolidate it in an annual time budget
utilization report available for multi-year comparisons. MUST provide
workflow for taxpayer selection for audit, in segment groups of revenue,
types, industries, taxes, and risk score. MUST provide workflow for the
selection of individuals for audit, in segment of revenue, types, taxes, and
individual heritage and patrimony. MUST provide workflow for the fiscal
audit of the individuals using the indirect fiscal verification method. MUST
provide management of the cases selected for audit, and the allocation of the
tax auditors per each case. MUST provide functions to flag cases for
discrepancies or mismatch to be subjected for audit by authorized users.
MUST provide templates for administrative documents like notifications to
auditees, authorization letters, tax audit forms, minutes of inspection, audit
files, other as per the case. MUST allow routing of the cases between
available and designated officers and staff members. MUST perform
automatic allocation of the cases depending on the risk level and the workload
both for inspectors and tax inspectors structures. MUST allow supplement /
modification / replacement of the tax audit team members for the audit
missions. MUST provide workflow for audit scheduling and time budgeting,
based on the availability of the human resources for audit activities and the
current priorities. MUST provide flexible allocation of the cases in between
the organizational units to optimize the utilization of the auditor resources.
MUST provide individual work plans for each auditor (user). MUST provide
audit preparation functionalities, including but not limited to selections, tax
audit file preparation, pre-filling of the tax audit file with the information
about the taxpayer and its history, including for the audit of cases identified by
ANAF and for taxpayers in the registration process. MUST interface with the
Document Management System and other information sources in the System
to retrieve all auditee’s related information and attach it into the audit case
folder. MUST provide complete workflow for tax audit mission, including
checklists, arithmetic and analysis tools (e.g. automatic calculations of the
accessories, penalties, differences and additional amounts, etc.) to be used
during the audit execution. MUST provide workflow for audit resolution,
including all the procedural steps. MUST log all the activity of the auditors,
per each audit case. MUST monitor and report the audit activity, calculate
quantitative and qualitative performance indicators, collect statistical
information and activity logs. MUST file the audit file in the Document
Management System, with limited and secured access.
208 Section V: Requirements of the Information System

2.10. Anti-Fraud / Criminal Investigation (FR) – MUST support the

following business process:

 FR01 – Conducting Investigations

The System MUST provide case management and complete workflow for
conducting Anti-Fraud / Criminal Investigations, including but not limited to
allocation of cases based on the risk criteria and the past experience, skills,
and qualifications of the staff members. MUST interface with the other
components of the Case Management System to automatically suspend other
actions in ANAF organization when a case is allocated for Anti-Fraud
investigation. Automatic suspension of the other actions within ANAF MUST
not be visible to other ANAF staff than the investigation team. MUST open
cases with unique ID, electronically update the case files, manage a case status
through its various states (e.g. opened, assigned, pending, resolved). MUST
acknowledge to the investigations team and to the organizational hierarchy the
changes in the status of a case (e.g. via e-mail and alerts in the System).
MUST provide case deadlines reminders and alerts, allow changes in the
milestones and extend the deadlines by an authorized user. MUST do
automatic posting of the tax calculations in the taxpayer case file to the
taxpayer’s ledger if one exists, once established and confirmed, without
waiting for the case file to be closed. MUST manage the closure of the case
file in orderly manner. MUST provide document templates (i.e. assessment
notes), attach support documents in the case file, etc. MUST allow
supervisors and managers to monitor and control activity, to comment or edit
the submitted assessment notes, to submit the documents to quality control by
approval (e.g. “marked as prepared”). MUST implement version control for
the case files and the assessment notes.

2.11. Objections and Appeals (AP) – MUST support with legally compliant
and complete workflows the following business processes:

 AP01 – Appeal / Application Submission

 AP02 – Appeal proceeding process

 AP03 – Appeal Notice / Order Generation

 AO04 – Appeal Rectification / revision processing

 AP05 – Record maintenance

 AP06 – Legal Case Management

 AP07 – Insolvency Management

The System MUST provide complete workflow and case management files for
appeals disputes, reviews and other legal proceeding, at multiple levels with
standard steps for processing, including but not limited to submit online
memorandum for appeal, review or application for reference, re-certifications,
check validity and eligibility of the applications, based on predefined criteria
Section V. Requirements of the Information System 209

at the time of submission, etc. MUST link the appeal application with the
unique case number (e.g. assessment case number / penalty order /
cancellation order number, etc.) against which the remedy is sought. MUST
allow logging (entry) of a dispute (objection or appeal) manually. MUST
allow the ANAF staff members to post comments on ground of appeal if
directed by the appellate authority. MUST recognize an objection to the whole
or a part of an audit assessment. MUST interface with the collection functions
to monitor for collection the part that is not on dispute, while the part in
dispute is held in abeyance while the objection is processed. MUST route a
case through a manager to an authorized tax office for processing. MUST
acknowledge concerned authorities about the appeals. MUST collect in the
case folder the supporting administrative documents regarding the tax in
dispute, the scheduled hearing dates for the cases on appeal. MUST provide a
document upload function to the taxpayer, to load the documents required by
the courts to be handed over to ANAF. MUST trace the disputed
administrative document from its issue date until the final solution regarding
the tax obligations. MUST generate notices / orders in predefined formats
with inputs from the assessing authority, including a summary of the appeal
case decision, history of the cause, legal clauses used in the final decision.
MUST publish on ANAF’s portal the resolutions without any particular
reference to the taxpayer. MUST provide the taxpayer with a version of the
decision without any personal information regarding the decision makers, via
the WebSpace. MUST record information in the case file on appeal
rectification and revisions processing by the courts. MUST maintain records
regarding the appeals filled in courts in Romania. MUST provide complete
workflow for the legal cases processing, including but not limited to
preparation of the case folder, review of the case folder, capture of the
judgment note, interface online with the court communication system. MUST
provide complete workflow to check validity and eligibility of the
applications, manage cases for disputes, linking of the case folder with the
case from the court, joining and disjoining of cases, notifications. MUST
provide complete workflow for manual and automatic case assignment to the
reviewer and via a manager to the authorized legal advisers, notifications,
resolutions and comments. MUST provide complete workflow for tracking a
disputed administrative document online by both parties for appeals. MUST
extract and exchange data with other institutions, as described in informational
Annex 4. Legacy Systems for Integration, section “External Systems and
Interfaces". MUST provide workflow for the processing of the insolvency
cases, with all the duly legal communication with taxpayer, creditors,
authorities, public registers, and courts.

2.12. Revenue Accounting (AC) – MUST support the following business

process:

 AC01 – Revenue Accounting

The System MUST provide complete workflow for Accounting and General
Ledger, including but not limited to accounting of the voluntary payments,
calculation and charging of interest on late paid amounts, accounting of
reimbursable amounts, accounting of the offsetting and deductions of
210 Section V: Requirements of the Information System

taxpayers liabilities, recording of the deferred and extended taxpayer

liabilities, imposed freezing accounts, accounting treatment, reversals, etc.
(See Informational Annex 2.) MUST perform budgetary accounting in
accordance with the Romanian Ministry of Public Finances requirements.
MUST provide reporting, collection, periodic reports, MIS reporting,
automatic and manual queries. MUST provide complete workflow for
submission of accounts, manual generation of accounting notes, accounting
warranties and garnishments, consolidated balance sheet for all levels of
detail, management of the accounting information, changes in the taxpayer
status and period end reconciliations.

2.13. Revenue Risk Analysis (RM) – MUST support the following business
processes:

 RA01 – Risk Identification

 RA02 – Risk Analysis

 RA03 – Risk Prioritization

 RA04 – Rating and Selection of Risky Taxpayers

 RA05 –Risk Evaluation Reporting

 RA06 – Rule Engine

 RA07 – Risk Management

 RA08 – Managing Risk Indicators

The System MUST provide advanced analytics and business intelligence to
select from multiple data sources (both internal and external to ANAF)
information about risk factors associated with the collection of the fiscal
revenue, trends and patterns in taxpayers behavior related to their returns,
payments and discrepancies in their fiscal activity. MUST create and maintain
a risk factors database, populated with data extracted from ANAF operational
databases (OLTP), internal and other external sources. MUST provide at least
one working fiscal risk model. MUST provide data mining functionality.
MUST integrate with the Data Warehouse, to process data from data marts
dedicated to risk analysis, risk management and risk monitoring. MUST
integrate with the Management Information System (MIS) to process reports
for risk analysis, selection and planning. MUST maintain rule-based mass
data collection, management and analysis using data from the data warehouse.
MUST provide custom designed rules and flags to be specified and built into
the System to highlight risk areas and sort data into risk and other specific
components. MUST provide a graphical user interface (GUI) with an
interactive dashboard for the tax officers, with flexible data views, query
builder with drag and drop, sample, drill, pivot and filter directly the data to be
analyzed. MUST provide templates, timers, risk registry, risk indicators and
risk parameters for risk indicators. MUST provide a complete workflow to
Section V. Requirements of the Information System 211

churn data to determine the value of the risk indicators for individuals,
companies or groups. MUST provide manual and rules-based ad-hoc query,
sampling and drilling. MUST create and maintain parameterizable risk profiles
for each taxpayer, store the values of the risk indicators in a risk indicators
database and calculate a dynamic risk score for each taxpayer. MUST analyze
the risk associated to the individuals using a comparative balance of the
amounts spent by each individual, based on the information from the ANAF
internal databases (like PATRIMVEN), information from the financial
institutions (e.g. lists of bank transfers, etc.), information from open sources,
versus the income declared by the individual, for a certain fiscal period of
time. MUST create risk profiles on risk indicators, using a combination of
matching techniques such as wildcards, thesaurus, calculations and formulas
(e.g. economic size of the taxpayer, profit and VAT refund claims, etc.), stored
in a database with risks treatments modeled with user-defined parameters.
MUST store the risk calculation, the rules and the results of the risk
assessments in the risk indicators database. MUST flag inconsistencies found
in the data to be analyzed (if any). MUST provide automatic risk treatment
recommendation, manual selection of the risk treatment for a taxpayer or a
group of taxpayers, establish a hierarchy of risks, and build risk maps,
recommendations of risk treatment strategies using a models library. MUST
provide capabilities to define risk plans, risk limits, risk score, KPIs, taxpayer
segment risk models, random selection of taxpayers for risk analysis, score-
based confidence factors regarding the revenue collection risks, risk evaluation
reporting, and management of the risk reports within the Case Management
system. MUST integrate with Revenue Enforcement (RE), Anti-Fraud (AF),
Taxpayer Audit (TA) – including the High Net worth Individuals Audit, and
other functions that use risk analysis. MUST “push” reports related to the
accuracy of the risk information collected and processed, based on user
defined Key performance Indicators (KPI’s), in the Case Management System.
MUST provide workflow for continuous risk management at least with the
following steps: risk identification, risk assessment and prioritization, analysis
of the compliance behavior causes. MUST provide predictive risk analysis.

2.14. Internal Audit (IA) – MUST support the following business processes:

 IA01 – Internal Audit Planning

 IA02 – Making Audit Mission

 IA03 – Tracking and Reporting the Implementation of Recommendations

The System MUST facilitate the creation of a 3-5 year rolling strategic plan
for auditing ANAF’s internal systems and business processes (department-by-
department), with tactical 1 year audit plans. MUST provide the necessary
alerts after completion of 3 years of audit activity. MUST integrate the risk
analysis results in the audit plan, at least annual deficiencies, changes in the
fiscal code, and information in the risk register. MUST prevent multiple audit
activities, by synchronizing the common ANAF activities in Internal Audit,
Internal Control, etc. in a common plan. MUST allow to manual highlight
other entities (e.g. Court of Accounts) control missions in an entity / business
212 Section V: Requirements of the Information System

unit. MUST provide preparation, referral and approval workflow for the
annual internal audit plan. MUST generate individual work plans per
upcoming audit cycle, both online and offline. MUST manage the audit
missions, in the Case Management System, with control reports, reminders of
the audit cycles, electronic workflow and checklists, audit candidates, audit
reports, scheduler, document management, access to historic information, log
of activities, management of the time budget, follow up on the implementation
of the audit recommendations, etc. MUST integrate with the risk analysis and
the Document Management System.

2.15. Internal Control (IC) – MUST support the following business processes:

 IC01 – Resource Availability

 IC02 – Resource Usage

 IC03 – Work Plan Execution

 IC04 – Alerts - General

 IC05 – Alerts Related to Taxpayer Services

 IC06 – Alerts Related to Taxpayer Registration

 IC07 – Alerts Related to Returns Processing

 IC08 – Alerts Related to Taxpayer Records

 IC09 – Alerts Related to Enforcement

 IC10 – Alerts Related to Tax Audit

 IC11 – Alerts Related to Appeals

 IC12 – Alerts Related to Fiscal Information

 IC13 – Alerts Related to Antifraud Function

The System MUST plan and implement the internalcontrol for business unit
and individual tax officer, with adherence to the legal norms. MUST plan the
work program, including resource utilization, time management, and calendar.
MUST support resource allocation, based on the available resources, with
skills, specialization, seniority and availability, against the risks to be
addressed with internal control mission and he estimated workload. MUST
define, maintain and execute integrated work plans for Internal Control.
MUST collect, store, log, filter and drill alerts about the activity of all the
other departments and System components, like but not limited to taxpayer
services, taxpayer registration, returns processing, management of the
taxpayer records, enforcement, tax audit, appeals, management of the fiscal
information, and anti-fraud. MUST verify process compliance.
Section V. Requirements of the Information System 213

2.16. Management Information / Decision Support (REP) – MUST provide

the following tools:

 MIS 01 – Report Engine

 MIS 02 – Decision Support System (DSS)

 MIS 03 – Executive Information Subsystem (EIS)

The System MUST provide reporting and KPI measurements. MUST provide
data marts and MIS databases, populated with information copied from the
production databases (OLTP). MUST integrate with the Revenue Risk
Analysis (RM) and Anti-Fraud / Criminal Investigation (FR) functional
modules, for functions like data analysis, data analytics and risk
scoring.MUSTinclude a complete documented Data Dictionary for the MIS
databases and data marts. MUST provide functions for administration of the
MIS, MIS databases management, back-up and restore of the data, analysis of
the legacy data retained for 10 or 20 years historical periods, query by
example (QBE), data formatting, data filtering, report generator, MIS
scheduler for the MIS jobs, reports scheduler, report formatting, report editor,
report dash board, report dissemination, report posting, secure sensitive
reports, report data stamp. MUST support multiple data marts for decision
support.

2.17. Taxpayer Services Interface (TS) – MUST provide and integrate the
following taxpayer services tools:

 Call Center

 Automatic Call Distribution

 Interactive Voice Response Systems

 Computer Telephone Integration

 Call Logger

 Call Handler

 SMS Gateway

 Fax Gateway

 E-Mail Gateway
214 Section V: Requirements of the Information System

GENERAL AND NON-FUNCTIONAL REQUIREMENTS

3. General and Non-Functional Requirements

3.1. Software Architecture

3.1.1. Components: The System MUST include the following

components/functionalities (including, as appropriate, complete libraries, up-
to-date versions, and paid, up-to-date licenses). Each component must
provide its own interface (and tool set), to allow configuration, integration
and customization. These components must be fully integrated in the sense
that any element of any component can be accessed by another element of
any other component and that data are captured and stored once and
available system-wide – within the relevant parameters of security and
business process rules.
 DOCUMENT MANAGEMENT SYSTEM.
 BUSINESS INTELLIGENCE.
 ENTERPRISE REPORTING ENGINE.
 WORKFLOW ENGINE.
 RULES ENGINE.
 FORMS MANAGEMENT.
 ON-LINE HELP (on-line documentation, chat, wiki, etc.).
 DISTANCE LEARNING.
 INTRANET PORTAL.
 INTERNET PORTAL.
 ON-LINE AUCTION.
3.1.2. Software Infrastructure Elements: The System MUST include the
following software infrastructure elements/functionalities (including, as
appropriate, complete libraries, up-to-date versions, and paid, up-to-date
licenses). Each element must provide its own interface (and tool set), to
allow configuration, integration and customization.
 RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS),
INCLUDING ON-LINE ANALYTIC PROCESSING (OLTP), DATA
WAREHOUSE, and ELECTRONIC ARCHIVE.
 APPLICATION SERVER.
 IDENTITY MANAGEMENT AND ACCESS MANAGEMENT.
 CLUSTERING AND VIRTUALIZATION.
 ENTERPRISE SERVICE BUS.
 MANAGEMENT INFORMATION SYSTEM.
Section V. Requirements of the Information System 215

 CUSTOMER RELATIONSHIP MANAGEMENT AND INTERACTIVE VOICE

RECOGNITION (CRM-IVR).
 MASSIVE PRINTING UNIT INTERFACE.
3.1.3. Technical Management Tools: The System MUST include the following
technical management tools/functionalities (including, as appropriate,
complete libraries, up-to-date versions, and paid, up-to-date licenses). Each
tool must provide its own interface, to allow configuration, integration and
customization.
 REQUIREMENTS MANAGEMENT AND DEFINITION.

 SOFTWARE RELEASE MANAGEMENT.

 INCIDENT AND PROBLEM MANAGEMENT.

 FUNCTIONAL AND PERFORMANCE TESTING.

 INTEGRATED DEVELOPMENT ENVIRONMENT.

 BUSINESS PROCESS MANAGEMENT SUITE.

 PROGRAMMING LANGUAGES COMPILERS AND/OR INTERPRETERS USED

IN THE DEVELOPMENT OF THE RMS PRODUCT/S.

 LIBRARIES AND API’S USED IN THE DEVELOPMENT OF THE RMS.

 DATA MIGRATION (I.E., DATA EXTRACTION, DATA FILTERING, DATA

CONVERSION, OTHER DATA PREPARATION STEPS FOR THE TEST AND
PRODUCTION DATA)

3.1.4. SOA. The System MUST implement a Service Oriented Architecture

(SOA) for all external transactions and all inter-component transactions.

3.2. ICT Platform Compatibility. The System MUST reliably and effectively run on
the ICT platform technologies of ANAF’s Test and Development Platform (See
Informational Annex 3 for more details).

3.3. Language Support. The System MUST handle multi-byte character sets –
specifically: Unicode Latin Extended A and B, UTF-8, and UTF-16 in display in
at least the data and document management functions, rules and workflow
specifications, system audit, system security, and on-line help. Case-sensitive
sorting must conform to the standards for the Romanian Language (see DEX
“Explicative Dictionary of the Romanian Language”). All systems documentation
MUST be provided in digital revisable copies, PDF ready-to-print copies, and
hard copies. User manuals MUST be provided in the Romanian and English
Languages. All other system and implementation documentation MUST be
provided in at least the English Language.

3.4. Software Components (functionalities). MUST be supplied, configured and

integrated to provide the following capabilities.
216 Section V: Requirements of the Information System

3.4.1. DOCUMENT MANAGEMENT SYSTEM. MUST exchange and manage

documents received from and sent to taxpayers. MUST exchange and
manage documents transmitted between functional modules as well as with
the main software components/elements (e.g., e-mail, document repositories,
databases). MUST map and insert metadata in any digital document. MUST
create templates for common digital documents and assign metadata sets for
each template. MUST manage a document’s metadata in accordance with
specified rules. MUST provide an integrated document storage facility.
MUST provide the capacity to create digital documents and to create them
from scanned images, including imaging processing. MUST provide a
personal workspace, where draft documents can reside until they are either
deleted or registered as digital documents by the user. MUST create and
manage multiple versions of digital documents. MUST provide an
integrated workflow engine (including an editor for creating rules) or be
integrated with the WORKFLOW ENGINE (specified below). MUST be
integrated with the BUSINESS PROCESS MANAGEMENT SUITE.

3.4.2. BUSINESS INTELLIGENCE. MUST handle data from multiple databases.

MUST provide dashboards and data visualization facilities. MUST provide
for self-service of selection, analysis and presentation functions. MUST
allow presentation on mobile devices (i.e., tablets, smart phones, etc.), in
addition to conventional desktop/laptop devices. MUST provide enterprise
search, balanced scorecard, predictive analytics, forecasting, decision-
support, data mining and online analytical processing, functions. MUST
provide for configurable display design, including timeline, RSS feed
features, design templates, scorecard wizards, and key performance indicator
(KPI) templates. MUST integrate with the ENTERPRISE REPORTING ENGINE.
MUST utilize the overall System Security facilities.

3.4.3. ENTERPRISE REPORTING ENGINE. MUST generate reports from multiple

data sources (e.g., databases, flat files, .XLS, or similar) to multiple
document formats (e.g., .DOC, .PDF, .CSV, etc.,) using predefined or
customized report templates. MUST generate and edit report templates.
MUST support data consolidation from RMS platform databases and other
data sources (e.g., ERP, BI, Analytics, and Data Warehouse) using standard
database interfaces and protocols (e.g., ODBC, OLEDB, JDBC, etc.,).
MUST provide concurrent users simultaneous view of the same records,
documentation, and/or template. MUST provide role-based access control at
the operation level. MUST control for admissible client applications before
allowing such application to use the ENTERPRISE REPORTING ENGINE
capabilities.

3.4.4. WORKFLOW ENGINE. The System MUST use the WORKFLOW ENGINE to
execute all business process workflows. The WORKFLOW ENGINE MUST
integrate with the RMS application. The RMS application MUST create and
manage the business process workflows. The WORKFLOW ENGINE MUST
provide user and administrative control over the execution of standard and
custom workflows, without limitation regarding the number of workflows
and steps in the workflows. The WORKFLOW ENGINEMUST provide
permissions to users and groups, so that they may re-assign
Section V. Requirements of the Information System 217

tasks/activities/actions in a workflow under the control of the system

administrator. The WORKFLOW ENGINE MUST allow a user to check status
of own-tasks, to suspend and resume a task for a determined period of time,
and to redirect a task to another user. The WORKFLOW ENGINE MUST
provide reporting and notification functions covering workload and
exceptions (e.g., tasks suspended, tasks delayed beyond norm for each task,
tasks approaching the statuary 30 day limit, etc.,). The WORKFLOW ENGINE
MUST trigger workflows automatically based on appropriate events, provide
conditional and parallel workflow execution, prioritize workflows in the
queues, and track the entire workflow process. MUST manage an unlimited
number of versions of the same workflow each with specific time limits.
MUST utilize the overall System Security facilities.

3.4.5. RULES ENGINE. MUST manage the execution of all business process
workflows. The RULES ENGINE MUST integrate with the RMS application.
The RULES ENGINE MUST create and manage the business rules for
workflow execution and reporting. The RULES ENGINE MUST recognize and
organize textual statements of a business rule (or groups of rules) into a
repository with associated metadata, reports, and guidance for maintenance
and management of the rule/rules. The RULES ENGINE repository MUST
provide a structured, hierarchical view of the rules. The RULES ENGINE
MUST import and export rules, statements, metadata and associated
information in a standard format (e.g., Semantics of Business Vocabulary
and Business Rules (SBVR), Production Rule Representation (PRR), etc.,).
The RULES ENGINE MUST provide a structured rules language and provide
patterns for rules that help the business user and/or administrator create new
rules. MUST manage an unlimited number of versions of the same rule each
with specific time limits. MUST utilize the overall System Security
facilities.

3.4.6. FORMS MANAGEMENT. MUST allow administrators to create, edit, import,

export forms, XML and XSLD schemas and bind the forms and XML
schemas together. MUST support at least Adobe .PDF formats and XML
compatible layout schemas. MUST manage multiple versions of the same
form with specific time limits. MUST work with digital signatures. MUST
allow on-line and off-line interaction with the forms. The RMS application
MUST integrate the forms with the functional modules using standard web-
service protocols (e.g., WSLD, SOAP, HTTP, ADO, JDBC). The FORMS
MANAGEMENT MUST store and archive unlimited number of digital forms.
The FORMS MANAGEMENT MUST utilize the overall System Security
facilities. The electronic forms generated by the FORMS MANAGEMENT
MUST support locale settings for the Romanian, Hungarian, German and
English Languages. The language of the user interface within the electronic
forms MUST be at least Romanian and English. The electronic forms must
correct misuse of non-ASCII special characters in Romanian, Hungarian, and
German.

3.4.7. ON-LINE HELP (on-line documentation, chat, wiki, etc.). MUST search and
index all articles (e.g., HTML pages, etc.,) using keywords and highlight
results in the retrieved articles. MUST integrate with Internet Portal and
218 Section V: Requirements of the Information System

Intranet Portal and provide “tool tips” (i.e., context-based guidance). MUST
allow video tutorials to be embedded in the help articles. MUST allow user
to export articles as .PDF documents. MUST monitor and report user query
statistics. MUST provide on-line chat help desk functionality. MUST allow
users to select large display font sizes. The on-line help articles and user
interface must be selectable between the Romanian and English Languages
(with full support for the Romanian character set).

3.4.8. DISTANCE LEARNING. MUST administer the full lifecycle of training

(planning, curricula, registration, attendance, testing, evaluation, and trainee
feedback, etc.). MUST deliver through Computer Base Training (CBT),
Instructor Lead Training (ILT) classroom, and virtual classroom channels.
MUST provide individualized access to trainee profile, job role, training
track (past and future), class schedule, class materials, class enrollment and
class access. MUST utilize the overall System Security facilities. MUST
provide training management control over course definition, curricula,
mapping of job role and courses, class schedule, training resource
availability (including trainers, classrooms, pedagogical equipment,
inventory of printed manuals, and consumables, etc.). MUST provide
training management monitoring of trainee evaluation and trainee
compliance testing, class evaluation, and course evaluation. MUST provide
capacity for virtual and distance classes (i.e., multimedia streaming, voice
and video conferencing, desktop sharing/remote control of the trainee’s
workstations). MUST catalog training content for classrooms and CBT.
MUST provide search and selection of training content from the catalog
based on trainee profile, job role, topics of interest, and schedule. MUST
track and notify trainees and training administrators regarding compulsory
courses and test base on the job role. MUST upload and download CBT.
MUST provide and manage CBT using the SCORM 2004 international
standard (or equivalent standard). MUST provide a web-interface and the
option to download and run the CBT on the trainee’s workstation. MUST
provide an user interface in the Romanian and English Languages.

3.4.9. INTRANET PORTAL. MUST provide an enrollment function that can

interoperate with ANAF’s existing IBM Tivoli Identity Manager and IBM
Tivoli Access Manager systems and integrate with the IDENTITY
MANAGEMENT AND ACCESS MANAGEMENT. MUST provide a user profile
editing and update function to establish and maintain details about the
internal user (e.g., mail stop, extension number, access privileges for the
business applications) that provide self-service and supervisory control
functions. MUST utilize the overall System Security facilities. MUST
provide controlled access to all RMS modules, software components,
software elements and system management tools. MUST provide a visual
user interface in the Romanian and English Language. MUST present
personalized access points to the authorized business applications. MUST
present information of general interest to ANAF personnel (e.g., news,
updates, broadcast internal communication, etc.). MUST present user-
specific information (e.g., task lists, late or delayed tasks, notifications, etc.,).
During the analysis and development stages, the Intranet Portal MUST
provide an indication of what business applications are running on the
Section V. Requirements of the Information System 219

production system and what business application are running on the

test/training system.

3.4.10. INTERNET PORTAL. MUST provide an enrollment function that can

interoperate with ANAF’s existing IBM Tivoli Identity Manager and IBM
Tivoli Access Manager systems and integrate with the IDENTITY
MANAGEMENT AND ACCESS MANAGEMENT.MUST provide a user profile
editing and update function to establish and maintain details about the
external user (taxpayer register number, name of taxpayer/firm, addresses,
contact information, etc.,) that provide self-service and supervisory control
functions. MUST provide controlled taxpayer-specific access to specific
taxpayer services (inquiry, registration, returns filing, taxpayer account,
appeals and complaints, on-line help, on-line training, chat, selection of SMS
versus e-mail communications channels, etc.). MUST present taxpayer
personalized access points to the authorized on-line services. MUST present
information of general interest to taxpayer (e.g., news, updates, broadcast
external communication, etc.). MUST present taxpayer-specific information
(e.g., taxpayer specific documents released by ANAF, notifications, access
logs, etc.,). MUST utilize ANAF’s Internet security system. (See
Informational Annex 4 for details.) MUST provide a visual user interface in
the Romanian, German, Hungarian and English Languages.

3.4.11. ON-LINE AUCTION. MUST provide functions to automate publicity and

transactions with goods from enforced collection, seized goods and other
categories of goods (like old ANAF equipment for disposal), over secured
Internet. MUST integrate with the Taxpayer Registration, Internet Portal,
Intranet Portal and Identity Management and Access Management
components. MUST authenticate and log-in the participants to the on-line
auctions in e-auction rooms, over the Internet and the Intranet or from
auctions room located on the premises of ANAF, over the Intranet. MUST
provide at least the following roles for the participants: bidders, auction
president (only one participant), lead-secretary (only one participant for the
e-auction room), secretaries (at least one for each auction room), independent
witnesses, and auditors. MUST authenticate the participants at least with user
name, password and qualified digital certificate, in order to sign the auction
documents (i.e. auction terms and conditions, consent for the processing of
the personal data, auction forms, and auction session minutes) during the
trade session. MUST log with certified time stamp and digital signature all
the activities of the participants, in an auditable activity log and in the
auction session minutes document. MUST time on all the phases and steps of
the auction, locking and unlocking the processes as per the auction scenario
in place. MUST implement flexible and editable parameters for the duration
of all the steps of the auction, the advertising periods of time, the deadlines
to enroll for an auction and pay the participation fees or the auction security
bond, etc. MUST interface with Revenue Enforcement functional module
and with the Document Management System, to import the information
regarding the goods on sale from the auction case folder into the publicity
and the transaction. MUST interface with the Revenue Enforcement
functional module and with the Document Management System to export the
results and the logs of the auction (i.e. all the auction documents digitally
220 Section V: Requirements of the Information System

signed, transactions logs, activity logs, image and sound captures from the
physical auction rooms on ANAF premises, etc.). MUST interface with the
WebSpace to post information for the taxpayers enrolled or participating in
e-auctions and to collect the documents uploaded by the taxpayer to enroll
for the e-auctions. MUST interface with the Taxpayer Accounting functional
module to check the payments made for the participation security and/or
participation fee, for the payments of the adjudicated goods, etc. MUST
implement auction workflows compliant with the regulations in place at least
forward e-auction, for non-perishable non- perishable goods, and low value
goods. MUST implement a secured mechanism to make all transactions non-
reputable, with the step-by-step granularity. The Supplier MUST provide
functions to manage the events that may happen during the e-auction session
(i.e. presentation of the participants, participant unexpectedly leaves the
auction room, technical incidents, etc.,).MUST distribute notifications and
documents regarding the results of the auctions, the upcoming auctions, the
goods to be auctioned again at discounted starting price, etc. MUST
disseminate information regarding the goods to be auctioned via a public
web section in the ANAF public portal. MUST disseminate reminders to the
participants enrolled in the e-auction platform via e-mail and WEB. MUST
provide secured and encrypted communication sessions over the Internet for
all the participants on-line (see more details in Informational Annex 4 –
Online Auction). MUST utilize ANAF’s Internet security system. (See
Informational Annex 4 for details.) MUST provide a visual user interface in
the Romanian and English Languages.

3.5. Software Elements (functionalities). MUST be supplied, configured and

integrated to provide the following capabilities.

3.5.1. RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS), INCLUDING ON-

LINE TRANSACTIONS PROCESSING (OLTP). MUST implement the entity
relation model with relational or object-relational technology. MUST
provide at least one of SQL:2011 or ISO/IEC 9075:2011 or noSQL query
languages. MUST provide programmatic interfaces for all the programming
languages used in the RMS applications. MUST provide standard database
interfaces and protocols – at least one of ODBC, OLEDB, JDBC, JSON, or
API interfaces. MUST provide JAVA and/or Microsoft .Net application
development platforms. MUST provide an application development
environment with a graphical integrated development environment (IDE)
from the RDBMS manufacture or using open source technologies (e.g.,
Eclipse). MUST provide high-scalability, high-availability, disaster-
recovery function either built-in or products from the RDBMS manufacture.
MUST provide adjustable multi-level query optimizer. MUST provide
parallel query processing (i.e., to process multiple table partitions
simultaneously). MUST point-in-time recovery (i.e., recovery to a specified
moment in time). MUST provide on-line and off-line back-up
functionality. MUST provide data encryption within a table (i.e., column-
based data encryption). MUST provide row-level security functions. MUST
provide native support for multi-byte character set – specifically: Unicode
Latin Extended A and B, UTF-8, and UTF-16. MUST provide selectable,
Section V. Requirements of the Information System 221

multi-level audit trails. MUST provide database partitioning. MUST

manage databases of at least 500 (five hundred) TB.

3.5.2. DATA WAREHOUSE. MUST integrate with the RELATIONAL DATABASE

MANAGEMENT SYSTEM (RDBMS), ON-LINE TRANSACTIONS PROCESSING
(OLTP), and BUSINESS INTELLIGENCE. MUST acquire, organize, analyze,
ingest, and present data. MUST provide Analytics 3.0 standards in the
domains of deeper analysis, different types of data, and operational elements
incorporated with design patterns (e.g., dashboards and scorecards). MUST
handle structured, semi-structured, and unstructured data with the data types,
including master and reference data, transactional data, machine-generated
data, social media data, text, image, video and audio. MUST provide data
acquisition from DBMS, flat files, NoSQL files, DMP files, etc. MUST
provide data organization with at least ETL/ELT rules. MUST analyze data
with at least Open Data Sets (ODS), warehouse, graph model, in database
analysis, in-memory database processing. MUST provide data decision
functions for: score cards, dashboards, query reporting, real-time decisions,
CPM, BI, social applications, text analytics and search, advanced analytics,
and interactive discovery. MUST provide DBA productivity tools,
monitoring features, parallel utilities, robust query optimizer, locking
schemes, security methodology, and remote maintenance capabilities.
MUST provide data integrity, back-up and recovery functions, with ability to
restore databases at any point in time, to ensure data integrity Write Data to
Disaster Recovery after data is committed at Primary (performance at the
Primary must not be interrupted by data replication at the Disaster
Recovery / Business Continuity Sites). MUST interoperate with ANAF’s
existing DBMS system software (i.e., Oracle 8, 9, 10i, 11g, IBM DB2,
Microsoft SQL Server, Lotus Notes and Domino). MUST provide multiple
data marts (to segregate risk management, fiscal audit and internal control
functions from the main data stores).

3.5.3. ELECTRONIC ARCHIVE. MUST preserve the collection of ANAF’s signed

digital documents and other artifacts (unsigned documents, messages,
transactions logs, scanned images, presentations, new feeds, press releases,
system images, etc., etc.,). MUST monitor and insure the integrity of digital
documents and artifacts during day-in-and-day-out operations. MUST
manage the physical security of the digital documents and artifacts. MUST
facilitate the discovery information about the archived digital documents and
artifacts and enforce access control. MUST manage digital objects made up
of multiple components, versions/generations, and files. MUST maintain
relationship between digital objects with multiple components to ensure that
the constituent parts are delivered in the proper order. MUST maintain the
reference, the provenience, the context and fixity information required to
preserve the integrity of the digital object. MUST provide an open,
extensible and standard method of packaging metadata for digital objects,
including at least Metadata Encoding and Transmission Standard (METS).
MUST allow new versions of descriptive metadata alongside older versions
of metadata attached to a digital object. MUST run continuously with no
scheduled downtime. MUST provide remote administration using secure
and unsecure communication protocols. MUST provide a workflow for
222 Section V: Requirements of the Information System

digital document and artifact registration (or utilize the WORKFLOW ENGINE).
MUST provide search-driven structured and dynamic navigation and
filtering. MUST allow subsets of documents of search results to be selected
for downloading.

3.5.4. APPLICATION SERVER. MUST deploy applications developed with Java or

Microsoft .Net application frameworks. MUST integrate with the
RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS), DATA WAREHOUSE,
CLUSTERING AND VIRTUALIZATION, and ENTERPRISE SERVICE BUS, as well as
the RMS functional modules. MUST be accessible via an Application
Programmer Interface (API) defined by the APPLICATION SERVER itself.
MUST provide native functionality for clustering, fail-over, and load-
balancing. MUST implement either Java Platform Enterprise Edition or
Microsoft .Net Framework for applications. MUST serve web applications
and services via standard interfaces (e.g., RMI, EJD, JMS, SOAP, ASP.NET,
COM+, WCF). MUST provide all necessary libraries, scripting languages
and interpreters, and APIs for the RMS functional modules and the above
named software components. MUST provide application services for 25,000
concurrent users.

3.5.5. IDENTITY MANAGEMENT AND ACCESS MANAGEMENT.MUST provide the

management of the individual principals, of their identification,
authentication and authorization, as well as of their access privileges across
the IT systems and applications of NAFA, within the enterprise architecture
boundaries. MUST manage the identification, authentication and
authorization information that defines the operations an entity (user) can
perform in the context of any specific application (part of the RMS system)
at any point in time. MUST provide the components of the identity
management system for the RMS system, including (but not limited to):
functionalities for internal directory services, meta-directory and federation
services, password and alternative credentials lifecycle management, agent
less single sign-on services. MUST provide consolidated dynamic role- and
attribute-based authorization services for the proposed RMS application
modules and to existing NAFA applications, as well as to the underlying
Web-Services, APIs and IT infrastructure components. MUST provide
ongoing governance for the identity management process itself, including of
the creation, initial provisioning, subsequent changes and de-provisioning of
the identity profiles and of the resource access entitlements granted to the
users. MUST provide a core component providing an internal user registry
able to hold and operate with detailed information sets for more than
5 million external users and for up to 50,000 internal and extranet users.
MUST provide standards-based directory and authorization services with
support for high concurrency environments (hundreds of thousands of
concurrent requests) and with a rich set of identity management
interoperability focused features. MUST provide interfaces and methods to
implement both single-factor authentication (e.g. user name and password)
and multi—factor authentication (e.g. user name and any of: password,
digital certificate/token or one-time password code/token). MUST provide
full support for the use of the digital signatures as well as for the concurrent
connection to more than one back-end (internal and/or third party)
Section V. Requirements of the Information System 223

certification and/or validation authority at a time. MUST provide support for

digital certificates, at a minimum from: the ones issued by a Certification
Service Provider on the list of EU Trusted Lists of Certification Services
(available on
https://ec.europa.eu/informationsociety/policy/esignature/trusted-list/), or the
ones from a Qualified Certificate Service Providers registered in Romania
(the list is available on:http://www.mcsi.ro/Minister/Domenii-de-activitate-
ale-MCSI/Tehnologia-Informatiei/Servicii-electronice/Semnatura-
electronica/ROMANIATrustedList-v7-PDF). MUST support centralized
administration, via central administrator roles, as well as the delegation of
authority functions for local administrators and supervisors. MUST support
the interchange of the identity related information between two or more
identity domains via the Security Assertion Markup Language (SAML 1.0,
1.1 and 2.0) OpenID and WS-Trust protocols. MUST enable the use of
delegated authorization in the NAFA applications via OAuth (1.0 and 2.0)
and WS-Trust protocols and enable the use of standards-based machine-
readable fine-grained resource access policies via the eXtensible Access
Control Markup Language (XACML 2.0 and 3.0) protocols. MUST support
and at least substantially implement the core principles of the following
international standards specific for identity and access management:
ISO/IEC 24760-1:2011 and ISO/IEC 24760-2:2015 Framework for Identity
Management; ISO/IEC 29100 Privacy Framework, ISO/IEC 29101 Privacy
Architecture; ISO/IEC 29115:2013 Entity Authentication Assurance. MUST
run at least on any of the following operating system platforms (with
reference to the versions respectively supported at the time of the offering
and for the duration of the contract): Unix (multivendor), Linux
(multivendor) or Microsoft Windows.

3.5.6. CLUSTERING AND VIRTUALIZATION. MUST deploy images of the software

stack (e.g., operating system, RDBMS, application server, business
applications) over two or more physical servers in a High Availability and
Load Balancing configuration, separating the components using virtual
machines. MUST integrate with the software stack used by the RMS,
including all components in a fully virtualized environment.

3.5.7. ENTERPRISE SERVICE BUS. MUST implement Service Oriented

Architecture (SOA) communications between the software components and
software elements. MUST fully integrate with the software stack (e.g.,
operating system, RDBMS, application server, business applications).
MUST implement interfaces for applications, software components and
software elements based on the following standards: Java, BPEL, SOAP,
RNI, REST, JNI, and others as needed for the RMS. MUST provide
functions to monitor and control routing of messages exchanged between the
services integrated by the ENTERPRISE SERVICE BUS. MUST provide
resolution containment between the communicating service components.
MUST provide marshaling of redundant services in the RMS. MUST
provide commodity services to the RMS components (i.e., event handling,
data transformation and mapping, message and event queuing and
sequencing, message security, exception handling, protocol conversion, and
file transfer). MUST provide process choreography and service
224 Section V: Requirements of the Information System

orchestration. MUST implement interfaces for ANAF’s legacy systems,

specifically: Oracle RDBMS, Oracle BPEL, IBM DB2, IBM Websphere,
Lotus Notes and Domino, JBOSS, Spring, and Hibernate.

3.5.8. MANAGEMENT INFORMATION SYSTEM. MUST provide timely, accurate and

consistent data for management and budget decision-taking for the agency
level policy decisions. MUST integrate revenue collection data with activity
resource usage and cost information. MUST provide reports for budget
planning, analysis and government wide reporting, based on ANAF’s
customized formats and EU standard formats. MUST prepare financial
statements in the International Financial Reporting Standard (IFRS) formats
(in accordance with DEP 2003/51/CE and other applicable legislation).
MUST provide at least budget reports and statutory financial reports. MUST
provide a complete audit trail. MUST provide a general ledger module, with
the Romanian Chart of Accounts. MUST interface with ANAF’s existing
accounts payable, accounts receivable, cash management, assets,
procurement, and budget planning modules. MUST interface with fiscal
information in the RMS, payment information in the Treasury system
(TREZOR), and taxes, duties, levies and excises in Customs systems
(EMCS-RO, NCTS-RO, ECS-RO, ICS, EORI-RO, TARIC, TARIF, ROC-
DPS, RO-DAI, APS-RO, and RVEDF). (See Informational Annex 4 for
descriptions of ANAF’s to-be Legacy Systems and interfaces.)

3.5.9. CUSTOMER RELATIONSHIP MANAGEMENT AND INTERACTIVE VOICE

RECOGNITION (CRM-IVR).MUST provide information to the ANAF taxpayer
support staff regarding general topics and taxpayer specific fiscal topics,
using the information from knowledge database (supported today with the
application ANAFI) and the help system. MUST integrate with the tax payer
register, to check the identity of caller versus the existing information about
the respective taxpayer. MUST track and measure the taxpayer support staff
interaction with the taxpayers using the active communication channels, for
activity analysis. MUST provide interactive functions to handle the calls of
the taxpayers, including taxpayer identity, taxpayer incoming phone number
(caller ID), taxpayer verification (password, PIN, and other security
information) via voice or dual tone multi frequency signal (DTMF). MUST
interact via the following channels: voice, voice over IP, Chat, SMS, fax and
e-mail. MUST integrate with the existing ANAF’s Taxpayer Services
Contact Center(described in Informational Annex 4). MUST integrate with
the WebSpace for the chat function, available to the tax payers logged in the
WebSpace to get support from ANAF specialists. MUST log all calls and
capture at least the following information: caller id, date, time and duration,
caller name, taxpayer support staff id and name, subject(s) of the call,
content, call closure, call evaluation, call recording and record of all the chat
sessions, for later review, quality control and trends analysis. MUST provide
pre-recorded incoming call message and waiting message. MUST provide
call-monitoring functions. MUST provide statistical reports regarding the
calls – by topic, by categories, by period, by taxpayer support staff. MUST
report on trends over time. MUST report on the activity of the tax payer
support staff in detail and grouped by areas and activity type. MUST push
activity statistics to the Data Warehouse and MIS.
Section V. Requirements of the Information System 225

3.5.10. MASSIVE PRINTING UNIT INTERFACE. MUST provide access to the massive
printing facilities of ANAF for all the applications part of the System. The
Massive Printing Unit prepares for mass mailing the ANAF administrative
documents (e.g. notifications, summons, fiscal notices, executive titles,
deduction notices, ANAF decisions, etc.). The Massive Printing Unit
distributes the administrative documents to the tax payers based on a
protocol with the Romanian Post, from this single location. The receipt of the
administrative documents by the taxpayer is confirmed via the postal service,
based on distribution lists managed by the Massive Printing Unit. The
Massive Printing Unit of ANAF consists of a printing server located in the
Primary Data Center (in Bucharest), connected via Intranet to the printers
(manufactured by Xerox) and the inserting equipment (manufactured by the
company Kern (www.kern.ch), 2 units of Kern 686 and 1 unit of Kern 3500),
located in Ramnicu Valcea, Romania. MUST handle output from the System
applications in Oracle .DMP file format. MUST capture the output of the
System applications at least in the following file formats: .PDF, .TXT, .CSV,
.XML, Oracle, .DMP. MUST transfer the output files to the application
SIAD – “Sistem informatic de administrare a documentelor administrative”
– (IT system for the administration of the administrative documents), via
simple file sharing on NFS protocol or via FTP protocol. MUST provide
automatic and manual file transfers. MUST provide the administrative
information about the documents to be printed, folded and inserted in
envelopes for mass mailing in a structured format (e.g. format of the
document to be printed, name of the document template from the existing
library of formats, destination address, distribution lists per regions, tally
sheets, confirmation letters, etc.) together with the files to be printed. MUST
provide the option to handle directly the printers located in the Massive
Printing Unit, using virtual printer ports over the Intranet. MUST support
direct printing on the existing printer drivers or using an universal virtual
printing driver, supporting at least one of the following printer control
languages: PCL5, PCL6 and/or Postscript. MUST provide complete mailing
and formatting information for the documents printed directly (if any) on the
printers of the Massive Printing Units, including the folding and inserting
commands for the inserting equipment. MUST provide mailing information
(if any) sorted and grouped per regions, localities, and postal codes. MUST
capture the information about the administrative document delivery status
(e.g. delivered to tax payer, not delivered to tax payer, posted on the ANAF
public web, accepted by default, etc.) from the files in Oracle .DMP format
produced by the SIAD application and update the status of the administrative
document in the System.

3.6. Technical Management Tools (functionalities). MUST be supplied, configured

and integrated to provide the following capabilities

3.6.1. REQUIREMENTS MANAGEMENT AND DEFINITION. MUST be the repository

and management tool for documents, requests and change requests. MUST
compile the business requirements and configuration change requests in a
standardized form. MUST ensure the validation business requirements and
configuration change requests with the relevant business owners and
technical departments. MUST trace requirements to system functions and
226 Section V: Requirements of the Information System

test cases. MUST ensure that the integrity of the requirements is preserved
(i.e., all comments, changes and approvals are recorded). MUST maintain
accountability of the change requests to the initiating department. MUST
provide customizable standardized forms for business requests, change
requests, and configuration change requests. MUST log change requests and
all processing steps. MUST notify (via e-mail) stakeholders regarding
events and step approvals. MUST allow an unlimited number of change
requests, items, processes – each with their own workflow logic and data
capture requirements. MUST provide consolidated views of the individual
work-items, showing total effort and cost by group, team, application, or
other attribute. MUST provide audit trails for all actions, approvals, and data
updates. MUST provide access to authorized users via a web-based
interface. MUST provide version control for application software, software
components, software elements, and technical management tools (either
integral to the REQUIREMENTS MANAGEMENT AND DEFINITION tool or by the
SOFTWARE RELEASE MANAGEMENT tool). MUST integrate with RMS
applications, software components, software elements, and technical
management tools.

3.6.2. SOFTWARE RELEASE MANAGEMENT. MUST control the acquisition,

installation and testing of all new software releases. MUST provide a
repository and necessary tools to manage the development and test
environments (i.e., system images and virtual machines) and conduct the
installation and testing processes. MUST manage the deployment of the
software release into the production environment. MUST integrate with the
FUNCTIONAL AND PERFORMANCE TESTING tools.

3.6.3. INCIDENT AND PROBLEM MANAGEMENT. MUST record and log all incidents
and problems arising during implementation, configuration, testing
deployment, production operations and maintenance phases. MUST be
accessible via secure Internet connection by the Supplier and the ANAF.
MUST provide a unique id for all incidents and problems. MUST track
resolution process steps until closure, using the unique id. MUST classify
incidents as either “existing problems” (without a known root cause) or
“known errors”. MUST implement the Supplier’s problem management
process. MUST register incidents and problems in a “know error” database
accessible to both the Supplier and ANAF. MUST provide templates for
incident and problems registration. MUST assign incident ownership,
monitoring, tracking, and communication responsibilities. MUST track and
report on the status of incidents and problems resolution. MUST notify the
stakeholders of an incident or problem via e-mail regarding changes and
overdue actions.

3.6.4. FUNCTIONAL AND PERFORMANCE TESTING. MUST allow authorized users

to define test cases for module-specific or system-wide functions, for
performance testing, and for stress testing. MUST manage the performance
threshold requirement detailed in the analysis and design phase. MUST
automate functional and regression testing. MUST define tests by recording
actual business activities using Java, .NET, HTTP, and HTTPS. MUST
provide a repository for requirements, test cases, automated test scripts, and
Section V. Requirements of the Information System 227

revealed defects. MUST generate reports on requirements, test cases,

automated test scripts, revealed defects, release status, release coverage, etc.
MUST define and control the visibility of the testing process for different
groups of users. MUST manage the full cycle of performance testing (i.e.,
stress and load testing) for web-based applications.

3.6.5. INTEGRATED DEVELOPMENT ENVIRONMENT. MUST integrate

PROGRAMMING LANGUAGES COMPILERS AND/OR INTERPRETERS USED IN THE
DEVELOPMENT OF THE RMS PRODUCT/S . LIBRARIES AND API’S USED IN THE
DEVELOPMENT OF THE RMS. MUST provide at least Eclipse, Hibernate,
Spring, Oracle JDeveloper, and generic SQL development frameworks.

3.6.6. BUSINESS PROCESS MANAGEMENT SUITE.MUST integrate with the

following software elements and components: Intranet Portal, Internet Portal,
Workflow Engine, Rules Engine and Enterprise Service Bus. MUST provide
integration for applications made in different technologies, based on open
interfacing standards. MUST provide a process orchestration engine to
coordinate all type of actors for structured and unstructured data flows.
MUST provide the ability to connect mainstream, commercial of the shelf
(COTS) applications. MUST support rule-driven and ad-hoc workflows, and
response to human and system responses. MUST provide logs documenting
the changes of the state of the coordinated resources (e.g. processes,
interfaces, data workflows, etc.). MUST schedule and prioritize work in a
flexible way. MUST integrate in an Integrated Development Environment,
with graphical interface. MUST natively manage or integrate with enterprise
content management tools (ECM) to manage documents and other type of
unstructured content (e.g. graphical images, audio or video). MUST provide
on-demand analytics functions on the processes and workflows managed, to
improve the process model or its execution by the user. MUST provide
business rules processing. MUST manage and execute rules that represent
business policies. MUST provide connectivity at least via HTTP, REST,
SOAP, WSDL, ODBC, JDBCand /or .NET protocols. MUST provide
functions to configure deploy and administer the platform and the application
artifacts, as well as versioning control. MUST provide integration with the
IT security framework, at least at the level of application, user, role, group,
department and function. MUST provide process monitoring and alerts for
the users and the administrators regarding the processes execution. MUST
support desktop, laptop and mobile end–user devices. MUST provide
integration with the social media applications, at least Facebook, Google+,
LinkedIn, YouTube, Instagram, other as per the case.

3.6.7. PROGRAMMING LANGUAGES COMPILERS AND/OR INTERPRETERS USED IN THE

DEVELOPMENT OF THE RMS PRODUCT/S . LIBRARIES AND API’S USED IN THE
DEVELOPMENT OF THE RMS. MUST provide a complete set of up-to-date
media, licenses and documentation for all compliers, interpreters, libraries
and API necessary for customization and maintenance of the System. MUST
integrate these tools in the INTEGRATED DEVELOPMENT ENVIRONMENT.
MUST integrate these tools with SOFTWARE RELEASE MANAGEMENT.
228 Section V: Requirements of the Information System

3.6.8. DATA MIGRATION. MUST provide tools for data extraction, data filtering,
data cleaning, data conversion, other preparation steps for migrating the test
and production data from ANAF’s existing systems and databases into the
RMS. MUST use the PROGRAMMING LANGUAGES COMPILERS AND/OR
INTERPRETERS USED IN THE DEVELOPMENT OF THE RMS PRODUCT/S .
LIBRARIES AND API’S USED IN THE DEVELOPMENT OF THE RMS. MUST
upload the test and production data into the RELATIONAL DATABASE
MANAGEMENT SYSTEM (RDBMS) and THE DATA WAREHOUSE.

SIZING AND PERFORMANCE

4. Sizing. The System MUST handle (including, as appropriate, licenses):
4.1. MUST provide a perpetual enterprise license for the RMS product.
4.2. The minimum number of end users per functional modules are as follows:
o At least 5,000 users for the TAXPAYER REGISTRATION functional module.
o At least 5,000 users for the RETURNS PROCESSING functional module.
o At least 5,000 users for thePAYMENTS PROCESSING functional module.
o At least 5,000 users for the TAXPAYER ACCOUNTS/LEDGER functional
module.
o At least 5,000 users for the REFUNDS PROCESSING functional module.
o At least 5,000 users for the RECONCILIATION functional module.
o At least 5,000 users for theREVENUE COLLECTION functional module.
o At least 1,000 users for the REVENUE ENFORCEMENT functional module.
o At least 3,500 users for the TAXPAYER AUDIT functional module.
o At least 2,000 users for ANTI-FRAUD / CRIMINAL INVESTIGATION functional
module.
o At least 1050 users for the OBJECTIONS AND APPEALS functional module.
o At least 30 users for the REVENUE ACCOUNTING functional module.
o At least 120 users forREVENUERISK MANAGEMENT advanced analytics
functional module.
o At least 10 users forREVENUERISK MANAGEMENT business intelligence and
data mart functional module.
o At least 2,000 users forREVENUERISK MANAGEMENTenterprise reporting
functional module.
o At least 100 users for theINTERNAL AUDIT functional module.
o At least 100 users for the INTERNAL CONTROL functional module.
Section V. Requirements of the Information System 229

o At least 2,500 users for the MANAGEMENT INFORMATION / DECISION

SUPPORT functional module.
o At least 12,000 users for the TAXPAYER SERVICES INTERFACE functional
module.
4.3. The minimum number of registered identities for the underlying software
components are as follows:
o At least 18,000 run-time users for DOCUMENT MANAGEMENT.
o At least 2,500 run-time users for BUSINESS INTELLIGENCE.
o At least 250 full users for BUSINESS INTELLIGENCE.
o At least 2,500 users for ENTERPRISE REPORTING ENGINE.
o At least 18,000 run-time users for WORKFLOW ENGINE.
o At least 18,000 run-time users for RULES ENGINE.
o At least 18,000 run-time users for FORMS MANAGEMENT.
o At least 18,000 users for ON-LINE HELP.
o At least 18,000 users for DISTANCE LEARNING.
o At least 18,000 users for the INTRANET PORTAL.
o At least 500,000 users for the INTERNET PORTAL.
o At least 1,000 run-time registered internal users. At least 50,000 run-time
registered external users for ON-LINE AUCTION.
4.4. The sizing of the software infrastructure elements are as follows:
o RELATIONAL DATABASE MANAGEMENT SYSTEM, including OLTP, DATA
WAREHOUSE, and ELECTRONIC ARCHIVEsufficient to run all the required
applications, users, performance requirements, and data volumes
(including at least ten years of records of 2,500,000 corporate
taxpayers/contributor accounts and at least 4,700,000 individual
taxpayer/contributor accounts for the OTLP Database, at least 500 (five
hundred) TB for the Data Warehouse, and at least 100 (one hundred) TB
for the Electronic Archive.)
o APPLICATION SERVER sufficient to run all the required applications, users,
data volumes, performance requirements.
o IDENTITY MANAGEMENT AND ACCESS MANAGEMENT sufficient to run all the
required applications, 30,000 internal users, 500,000 external users (tax
payers, individuals and companies, that will access systems’ functionalities
via the Internet), implemented in a high availability and disaster recovery
configuration with 3 sites – Primary Data Center (PDC), Secondary Data
Center (SDC) and Data Warehouse Data Center (DWDC).
o CLUSTERING AND VIRTUALIZATION, sufficient to run all the required
applications, users, data volumes, performance requirements.
230 Section V: Requirements of the Information System

o ENTERPRISE SERVICE BUS that can handle at least 15,000 one-kilobyte

messages per hour with a mean response time of no more than 1 second
per message.
o MANAGEMENT INFORMATION SYSTEM (MIS) that can handle at least 2,500
reporting users, 500 ad hoc users, 120 advanced analytic users, and 15
Business Intelligence developers.
o CUSTOMER RELATIONSHIP MANAGEMENT AND INTERACTIVE VOICE
RECOGNITION (CRM-IVR) that can handle at least 150 client services
support users with voice over IP (VoIP) calls, chat, SMS gateway, and Fax
gateway.
o MASSIVE PRINTING UNIT INTERFACE - sufficient number of instances of this
interface (software component) to run all the printing tasks of the System
applications using the facilities of the Massive Printing Unit, implemented
in a high availability and disaster recovery configuration with 3 sites –
Primary Data Center (PDC), Secondary Data Center (SDC) and Massive
Printing Unit (MPU) and collect the information regarding the
administrative documents delivery status.
4.5. The minimum number of end users for the technical management tools are as
follows:
o At least 16 users for REQUIREMENTS MANAGEMENT AND DEFINITION.
o At least 2 users for SOFTWARE CONFIGURATION MANAGEMENT(with
versioning, software component information management, software and
document versioning functions).
o At least 130 users for INCIDENT AND PROBLEM MANAGEMENT.
o At least 2 users for FUNCTIONAL AND PERFORMANCE TESTING.
o At least 5 users for INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)
(including source code control functions, local and central repository, and
repository synchronization).
o At least at least 6 servers for BUSINESS PROCESS MANAGEMENT SUITE.
o At least 10 users for the PROGRAMMING LANGUAGES COMPILERS and/or
INTERPRETERS used in the development of the RMS product/s.
o At least 18,000 run-time users for the LIBRARIES AND API’S used in the
development of the RMS.
o At least 1 enterprise license forthe DATA MIGRATIONtools (i.e., data
extraction, data filtering, data conversion, other data preparation steps for
the test and production data).
5. Performance. The System MUST achieve the following performance norms:
5.1. Allow at least 10,000 external visitors per day (aggregate, not individual IP
addresses)
5.2. Allow at least 100,000 page impressions (PI) per day, for the documents
delivered to the external users in the respective electronic format (e.g., Adobe
.PDF digital signed).
Section V. Requirements of the Information System 231

5.3. At least 99.9% uptime (i.e., 9 hours of unplanned downtime per year). At least
720 hours Mean Time Between Failures (MTBF).
5.4. Performance standards given above must be reached with at most this many
concurrent users using the system at any given time with 50% of them
performing data feeding and 50% of them performing database queries.
5.5. The System MUST provide sufficient capacity to support concurrent users for
each functional module as follows:
o At least 25,000 concurrent users for the CLIENT SERVICES INTERFACE
functional module.
o At least 500 concurrent users for the TAXPAYER REGISTRATION functional
module.
o At least 500 concurrent users for the RETURNS PROCESSING functional
module.
o At least 500 concurrent users for the PAYMENTS PROCESSING functional
module.
o At least 500 concurrent users for the REFUNDS PROCESSING functional
module.
o At least 500 concurrent users for the (VAT) RECONCILIATION functional
module.
o At least 500 concurrent users for the TAXPAYER ACCOUNTS/LEDGER
functional module.
o At least 500 concurrent users for the REVENUE COLLECTION functional
module.
o At least 100 concurrent users for the REVENUE ENFORCEMENT functional
module.
o At least 350 concurrent users for the TAXPAYER AUDIT functional module.
o At least 200 concurrent users for ANTI-FRAUD functional module.
o At least 100 concurrent users for the OBJECTIONS AND APPEALS functional
module.
o At least 30 concurrent users for the REVENUE ACCOUNTING functional
module.
o At least 30 concurrent users for RISK MANAGEMENT functional module.
o At least 100 concurrent users for the INTERNAL CONTROL functional
module.
o At least 100 concurrent users for the INTERNAL AUDIT functional module.
5.6. The System MUST provide sufficient capacity to support concurrent users for
each software component as follows:
o At least 3,600 concurrent run-time users for DOCUMENT MANAGEMENT.
o At least 250 concurrent users for BUSINESS INTELLIGENCE.
232 Section V: Requirements of the Information System

o At least 1,800 concurrent users for ENTERPRISE REPORTING ENGINE.

o At least 1,800 concurrent run-time users for WORKFLOW ENGINE.
o At least 4,500 concurrent run-time users for RULES ENGINE.
o At least 1,800 concurrent run-time users for FORMS MANAGEMENT and to
retrieve forms and associated metadata within 30 seconds.
o At least 1,800 concurrent users for ON-LINE HELP (i.e., on-line
documentation, chat, wiki, etc.,).
o At least 100 concurrent users for DISTANCE LEARNING.
o At least 9,000 concurrent users for the INTRANET PORTAL.
o At least 25,000 concurrent users for the INTERNET PORTAL.
o At least 500 concurrent users for the ON-LINE AUCTION.
5.7. The System MUST provide sufficient capacity to support concurrent users for
each software elements as follows:
o At least 250 concurrent users for RELATIONAL DATABASE MANAGEMENT
SYSTEM, including OLTP. At least 50 concurrent users for DATA
WAREHOUSE. At least 100 concurrent users for ELECTRONIC ARCHIVE.
o At least 25,000 concurrent users for APPLICATION SERVER.
o At least a sufficient number of virtual server instances to run on virtual
machines each of the instances of the software elements (for CLUSTERING
AND VIRTUALIZATION),

o At least 500 concurrent users for MANAGEMENT INFORMATION SYSTEM

(MIS).
o At least 150 concurrent users for CUSTOMER RELATIONSHIP MANAGEMENT
AND INTERACTIVE VOICE RECOGNITION (CRM-IVR).

SERVICE SPECIFICATIONS
6. Services

6.1. Project Planning. In accordance with GCC/SCC 19 and by the delivery deadline
stated in the Implementation Schedule, (in close dialog with the Purchaser) the
Supplier MUST prepare, present, revise and finalize the Agreed Project Plan
(based on the Supplier’s Preliminary Project Plan submitted as part of its bid).
The Agreed Project Plan MUST present at least the following time and resource
bound sub-plans (as well as others sub-plans as necessary and appropriate):
o Project Organization and Management Sub-Plan
o Testing and Quality Assurance Sub-Plan
o Analysis and Detailed Design Sub-Plan
Section V. Requirements of the Information System 233

o Installation, Configuration, Customization and Integration Sub-Plan

o Data Migration Sub-Plan
o Production Transition and Roll-out Sub-Plan
o Human Capacity Building Sub-Plan
o Warranty Defect Repair and Technical Support Service Sub-Plan

6.2. Project Organization and Management. In accordance with the Project

Organization and Management Sub-Plan of the Agreed Project Plan – with the
close involvement of the Purchaser – the Supplier MUST establish a project
delivery organization with sufficient resource to accomplish the technical,
administrative and manager tasks required to perform the Contract. MUST
include at a minimum key experts as specified below (see Paragraph 7). MUST
establish and perform project management functions in accordance with a formal
project management method (e.g., PMI-PMBOK, PRINCE-2, TEMPO, or
equivalent). MUST prepare and maintain a high-level phased project plan to
deliver and implement the System. MUST prepare and maintain task time and
resource schedules. MUST prepare and maintain progress reporting and problem
escalation mechanisms. MUST prepare and maintain a Change Order
Management system supported by a table of all-inclusive daily fee rates for the
main categories of expert input (as appropriate for the technical characteristics of
the System and the Supplier’s methodologies) – to be agreed with the Purchaser
as part of the Project Organization and Management Sub-Plan of the Agreed
Project Plan.

6.3. Testing and Quality Assurance. In accordance with the Testing and Quality
Assurance Sub-Plan of the Agreed Project Plan – with the close involvement of
the Purchaser – the Supplier MUST establish and perform the Verification,
Validation and Quality Assurance Processes for each of the major work streams
required to realize the System: Project Organization and Management; Analysis
and Detailed Design; Installation, Configuration and Customization; Production
Transition and Roll-Out; Data Migration; Human Capacity Building; as well as
Warranty and Technical Support. As appropriate, the Verification, Validation
and Quality Assurance Processes MUST conform to: ISO/IEC/IEEE 29119
Software Testing Standard (parts 1-5); ISO/IEC 15504 Information Technology-
Process Assessment; ISO/IEC 12207:2008 Systems and Software Engineering –
Software Lifecycle Processes; ISO/IEC 15288 Systems Engineering.

Among many other things, as part of the detailed Testing Design, the Supplier
MUST document in detail the test data that will be required at each critical stage
of the Verification and Validation Process. These data – appropriately
anonymized – will be sourced from the Purchaser’s systems.

In addition to the Installation and Operation Acceptance Test specified below in

Paragraph 8, the Supplier must demonstrate functional and performance the
System / Subsystems as a control to the transition from the Pre-Production
versions to the Production Version (in accordance with the Implementation
Schedule). In particular, the performance tests MUST demonstrate the System
performance requirements specified in Paragraph 5 above on the Purchaser’s
234 Section V: Requirements of the Information System

production platform (i.e., the software components, elements, etc. supplied under
the Contract plus the hardware elements as specified by the Supplier in
accordance with Paragraph 6.5below). The Supplier MUST provide any
additional software, equipment, and tools, (i.e., “Supplier’s Equipment” as
defined in the GCC/SCC) as well as staff inputs, required to simulate the loads
and record the results. The performance tests MUST be performed on the
following set-ups:

o Simultaneous 12,000 internal users accessing the System data with read-
only capabilities and a setup of simultaneous 3,000 internal users
accessing the system data with write and edit capabilities (the “Peak
System Load for Internal Access” set-up).

o Simultaneous 100,000 external users accessing the System data with read-
only capabilities and a setup of simultaneous 10,000 external users
accessing the system data with write and edit capabilities (the “Peak
System Load for External Access” set-up).

The System tests MUST demonstrate that under Peak System Load for
Internal Access and External Access set-ups:

o All queries must generate and retrieve a document in no more than 5

seconds (on average for at least 100 test runs).

o All queries must deliver 100% application functionality.

o All user interfaces (for internal and external access) must deliver a 99.9%
uptime (i.e., no more than 9 hours of unplanned downtime annually).

6.4. Analysis and Detailed Design. In accordance with the Analysis and Detailed
Design Sub-Plan of the Agreed Project Plan, the Supplier MUST apply a formal
system development methodology to the analysis, design, and specification
processes. The Supplier MUST undertake an analysis of the Purchaser’s business
processes, organization, institutional context/environment, existing business
systems (and plans), and ICT infrastructure (and plans). The Analysis activities
MUST take as the point of departure the Detailed Functional Design Goals
presented in the Informational Annex 5.The Purchaser will provide to the
Supplier the underlying detailed process design goal documentation at the earliest
convenient point following Contract Effectiveness.

On the basis of this analysis, the Supplier MUST formally describe, document,
and obtain the Purchaser’s formal agreement on the planned functional, general
and non-functional characteristics of the System. This specification MUST be of
sufficient depth and detail that, on the basis of the approved design
documentation, the Supplier can proceed to Install, Configure, Customize and
Integrate the System according to the agreed specifications.

The business processes analysis and system requirements documentation MUST

be presented in the Purchaser’s corporate standard formats BPNM 2.0. The
detailed system design and configuration documentation MUST follow the
Supplier’s adopted formal methodology.
Section V. Requirements of the Information System 235

The Supplier MUST also provide recommendations on organizational

arrangements to ensure an effective match between the System and ANAF.

6.5. ICT Platform Specification. On the basis of the detailed System design and the
work-load/sizing analysis, the Supplier MUST prepare a open-system, vendor
neutral ICT platform specification that will achieve the System performance
norms specified above in Paragraph 5.Furthermore the specification MUST allow
the System with 2,500 concurrent users to achieve no more than 3 (three) second
response time for 95% of all application-related transactions other than MIS
queries, MIS report generations and all login operations. The specification MUST
ensure ICT platform reliability of 99.9%. The specification MUST ensure ICT
platform recovery time objective (RTO) of 15 (fifteen) minutes for disaster-
recovery.
6.6. The Supplier MUST provide the specifications in sufficient depth and detail as to
form the Technical Requirements Section of a international competitive bidding
process under World Bank procurement guidelines.

6.7. Data Preparation for Migration. In accordance with the Data Migration Sub-Plan
of the Agreed Project Plan, the Purchaser will provide access for the Supplier to
the production data. With the close support of the Purchaser, the Supplier MUST
centralize, clean, normalize and convert (to data migration formats) the
production data. The Purchaser will be responsible for the quality of the input
data). The Supplier will be responsible for the quality of the data prepared for
migration. The Supplier and the Purchaser will be jointly responsible to
identifying residual quality/alignment problems in the data prepared for
migration. The Supplier will be responsible to correct the quality/alignment
problems in the prepared data. Informational Annex 6 describes the various
datasets that will need preparation/migration.

6.8. Test Data Migration. In accordance with the Testing and Quality Assurance Sub-
Plan of the Agreed Project Plan, the Purchaser will make available –
appropriately anonymized – test data extracted from its various systems. The
Supplier MUST work with the Purchaser to ensure the test data are properly
structured/formatted to be migrated into the data model of the System. (As soon
as possible in the execution of the Contract, the Supplier MUST share the data
model of the System with the Purchaser, to accelerate the data cleaning and
preparation activities by the Supplier.) The migration will be the responsibility of
the Supplier. The Supplier will be responsible for the quality of the test data (i.e.,
cleaned and centralized in preparation) using inputs from the Purchaser’s
systems. The Supplier and the Purchaser will be jointly responsible to identifying
residual quality/alignment problems in the test data prepared. The Purchaser will
be responsible to correct the quality/alignment problems in the test data extracted.

6.9. Pre-Production Implementation. In accordance with the Installation,

Configuration, Customization and Integration Sub-Plan – and as reflected in the
Implementation Schedule – the Supplier MUST Install, Configure, Customize
and Integrate the Pre-Production System in a phased/sequenced manner. For
example: Configuration V.1 = Full functionality “out-of-the-box”
configuration; Configuration V.2 = Customized and Localized version and
interfaces. As reflected in the Implementation Schedule, the Configuration V.1
236 Section V: Requirements of the Information System

would be loaded with test data set 1 (anonymized test data) and then tested.
Configuration V.2 should be first loaded with test data set 1, retested to confirm
the new functionality, then loaded with tests data set 2 (pre-production real data)
and then tested to reconfirm functionality and capacity. Systems Integration
should also be staged, with the Pre-Production Versions using mock-up interfaces
for the internal and external systems The Purchaser will provide the development
and test hardware platform (and relevant system software) to run and test the Pre-
Production versions of the System. The technical description of the Test and
Development hardware platform is presented in Informational Annex 3.

6.10. System Integration. In accordance with the Installation, Configuration,

Customization and Integration Sub-Plan, the Supplier should be responsible for
the technical integration of the System with of the Purchaser’s internal business
systems as well as external systems that the System will receive and/or transmit
information to. The Suppler MUST analysis the technical and logical features of
the systems to be integrated in sufficient depth and detail that the Purchaser can
ready the internal systems to realize the technical interface as well as align the
semantics, syntax and coverage of the logical interface. Similarly, the Supplier’s
analysis MUST be of sufficient depth and detail to allow the Purchaser to
coordinate/negotiate the technical and logical alignment of external business
systems. The Supplier and the Purchaser should be jointly responsible for
achieving the alignment, as well as monitoring the continued alignment of the
various systems through the Operational Acceptance Processes. The inventory of
internal and external systems that MUST be integrated is presented in
Informational Annex 4 - Table "Existing Systems to be Interoperable with RMS".
The Purchaser will provide further detailed descriptions in the technical
document of ANAF’s Enterprise Architecture (in the format of TOGAF 9®).

6.11. Production Transition and Roll-Out. In accordance with the Production

Transition and Roll-out Sub-Plan of the Agreed Project Plan, the Supplier (with
the active assistance of the Purchaser) MUST:

 Install and configure the System on the production ICT platform (including,
but not restricted to, implementing the systems and security administration
features).
 Migrate the data from the cleaned data stores (and, as appropriate, from the
Purchaser’s production systems) to the production systems installed on the
production ICT platform.
 Manage and closely monitor the system roll-out in the agreed functional,
organizational/geographical sequence – with the agreed stock-taking, review
and revision mechanisms.

 Implement follow-up/refresher training for the system and business

administration personnel, as well as the line-of-business user trainers.

6.12. Production Data Migration. In accordance with the Production Transition

and Roll-out Sub-Plan of the Agreed Project Plan, the Purchaser will be
responsible to ensure the full inventory of the data required to put the System into
Production Operation is properly cleaned and structured to allow a timely
Section V. Requirements of the Information System 237

migration and an orderly parallel operation (during Operational Acceptance

Testing). Once the customizations are implemented in Configuration V.2, the
Supplier MUST provide the revised full data model of the RMS to the Purchaser.
The migration of the production data will be the responsibility of the Supplier.
The Supplier and the Purchaser will be jointly responsible to identifying residual
quality/alignment problems in the production data. The Purchaser will be
responsible to correct the quality/alignment problems (including any ad hoc
business rule changes required). The Supplier will be responsible for quality of
the production data (i.e., cleaned and centralized). Pending residual migration
issues related to the quality /alignement data (up to 0.1 % (onetenthofapercent) of
the total data to be migrated) would not affect the completion of the acceptance
procedures.

6.13. Continuous Production Data Quality Control and Cleaning. Testing and
Quality Assurance Sub-Plan of the Agreed Project Plan, the Supplier MUST
prepare a facility to monitor the quality of the production data and to perform
corrections/data cleaning in joint cooperation with the Purchaser. The facility to
monitor the quality of the production data MUST be handed over to the Purchaser
at the end of the Technical Support phase.

6.14. Human Capacity Building. In accordance with the Human Capacity

Building Sub-Plan of the Agreed Project Plan, the Supplier MUST develop and
formally document the scheme of roles and jobs required to manage, operate and
sustain the System (including required roles of the Purchaser’s personnel for
design, development, review, verification and validation processes). In
documenting the scheme of roles and jobs, the Supplier MUST develop formal
job descriptions in the Purchaser’s institutional standard format. For each of the
operational jobs, the Supplier must develop and document a workload model (to
inform the Purchaser’s staffing plans, as well as inform the transition planning
into full system operation).

6.15. Training Development. On the basis of the scheme of roles and jobs, and
in accordance with the Human Capacity Building Sub-Plan of the Agreed Project
Plan, the Supplier MUST prepare curriculum, materials, course-plans and
certification processes to cover each of the roles and jobs in the scheme. These
MUST be delivered in hard copy and digital format in the Romanian Language.
These MUST be delivered with a limited not-for-resale copyright agreement, that
will allow the Purchaser to further to replicate, change, adapt and use the training
materials, for future training programs, for existing and future users of the RMS
Information System. All the copyrighted materials, inserts, citations and other
references to copyrighted materials part of the training materials to be delivered
by the Supplier, MUST be marked appropriately, and described as such. The
roles and jobs in the scheme include, but are not restricted to:

 Business line managers

 Business functions administrative
 Line-of-business users
 System administration
238 Section V: Requirements of the Information System

 Technical support
 Trainers
The subject areas also MUST cover:
 The Supplier’s formal system development methodology and
documentation (including the Verification, Validation and Quality
Assurance processes)
 The technical features and configuration of the major components of the
System
6.16. Training. On the basis of the roles/jobs scheme and in accordance with the
Human Capacity Building Sub-Plan of the Agreed Project Plan, the Supplier
MUST implement the developed training programs. The Supplier must perform
the training in classroom/laboratory settings established on premises in Bucharest
provided/contracted by the Purchaser.

The training on the Supplier’s formal systems development methodology and on

the technical features of the major components of the System MUST be provided
as soon as practical, to prepare the Purchaser’s key personnel to be effective
counterparts to the Supplier in the development and testing processes. The
participants in these courses should include approximately:
 12 functional area managers (representing the business line
departments at headquarters)

 12 regional office managers (i.e., representing a selection of the

regional offices)

 4 RAMP project management personnel

 12 senior staff and mangers of the General Directorate of IT (DGIT)

The training on business function administration MUST be synchronized with the

timing of the implementation and testing of the sequence of pre-production
versions of the System – i.e., sufficiently in advanced to ensure the Purchaser’s
personnel are ready to participate, but not so advanced that the knowledge
imparted depreciates. The participants in these courses should include
approximately:
 32 functional area managers and senior specialists

The training on system administration MUST be synchronized with the timing of

the implementation and testing of the sequence of pre-production versions of the
System – i.e., sufficiently in advanced to ensure the Purchaser’s personnel are
ready to participate, but not so advanced that the knowledge imparted depreciates.
The course/participants should include approximately:
 5 database designers

 5 database administrators

 5 system engineers/system administrators

Section V. Requirements of the Information System 239

 30 application developers/designers

 64 first-line technical support staff

 80 technical trainers (for training end-users)

The training for line-of-business users MUST be synchronized with the timing of
the implementation and testing of the sequence of pre-production versions of the
System, as well as during the production roll-out phase. The training must
implement a train-the-trainers model. The courses need to be segmented by the
main business function areas. The participants in these courses should include
approximately:
 160 training specialists

6.17. Technical Support (Warranty Period). In accordance with the Warranty

Defect Repair and Technical Support Service Sub-Plan of the Agreed Project
Plan, during the Warranty Period the Supplier MUST:

 Maintain 24x7x365 a single integrated point of contact for trouble reporting,

technical queries and assistance requests (with voice, e-mail, chat, SMS and
web portal channels). Provide monthly logs of in-coming and out-going
communications with five working days of the close of the respective
month.
 Maintain 12x5x52 (Romanian time) Help Desk.
 Provide continuous access to software versions, releases, and updates, as
well as commentaries and bodies of knowledge for the System and all of its
components (inclusive of any third-party components of the System).
Ensure all relevant software licenses are paid-up, up-to-date and
continuously valid for the configuration of the System.
 Provide at least 8x5x52 on-site system monitoring, trouble-shooting and
defect repair technical support by at least one (1) qualified System
Specialist, working according to the business hours of ANAF.
 Provide up to two hundred twenty (220) person-days of technical assistance
(on site and remote) by Senior System Specialists/Analysts to ensure the
System properly functions and remains consistent with the Romanian
Legislation and Regulations and up-to-date with then current version of the
System (software). Following a formal request from the Purchaser, the
Supplier must respond to the request within one (1) business day and
mobilize the appropriate team within five (5) business days.
240 Section V: Requirements of the Information System

THE SUPPLIER’S TEAM

7. Supplier’s Team

7.1. Supplier’s Team (Supply and Install Period). The Supplier MUST establish and
maintain a team during the Supply and Install Period with the following
minimum composition and minimum experience. The team MUST maintain an
presence on-site as required to perform the above services in a timely manner
consistent with the Implementation Schedule.

 Team Leader with documented experience in leading large teams and leading the
interactions with senior client management in at least two successful
implementations of integrated revenue administration systems using the System’s
core RMS product. General qualifications must include an university degree in the
field of Business Administration / Business Management / Economics / ICT /
Engineering and fluency in English language (spoken and written).
 Senior Functional Specialists with documented experience in the analysis and
successful implementation in at least two revenue administration projects.
Expertise may be combined in any combinations of Senior Functional Specialists,
provided all functional areas list below are covered (with the minimum number of
successful implementations).
o Taxpayer Registration
o Returns Processing
o Payments Processing
o Taxpayer Accounts / Ledger
o Refunds processing
o Revenue collection
o Reconciliation
o Revenue Accounting
o Revenue Enforcement
o Taxpayer Audit
o Risk Management and monitoring
General qualifications must include a university degree in the field of Business
Administration / Business Management / Economics / ICT / Engineering and
fluency in English language (spoken and written).
 Business Process Analysts (at least 3 specialists) with documented three years
successful experience in the formal process analysis/documentation employed by
the Supplier. General qualifications must include a university degree in the field
of Economics / Business Administration / Business Management / ICT /
Engineering and fluency in English language (spoken and written).
Section V. Requirements of the Information System 241

 Senior ICT Implementation Specialist with certification(s) in the formal project

management processes employed by the Supplier and documented experience in
at least one successful implementation of an integrated revenue administration
system using the System’s core RMS product. General qualifications must include
a university degree in the field of Economics / Business Administration / Business
Management / ICT / Engineering and fluency in English language (spoken and
written).
 Senior Validation and Verification (QA) Specialist with certification(s) in the
formal validation and verification (QA) processes employed by the Supplier and
documented experience in at least one successful implementation of an integrated
revenue administration system using the System’s core RMS product. General
qualifications must include a university degree in the field of Economics /
Business Administration / Business Management / ICT / Engineering and fluency
in English language (spoken and written).
 Senior Software Developers with documented successful experience in the
deployment and customization of at least one successful implementations of an
integrated revenue administration system using the System’s core RMS product
(in sufficient number to demonstrate successful experience in interface
development for all the functional areas noted above). General qualifications must
include a university degree in the field of Economics / ICT / Engineering and
fluency in English language (spoken and written).
 Senior ICT Platform Specialists with documented successful experience in the
installation and integration of the software element and technical management
tools provided under the Contract (in sufficient number to demonstrate successful
experience in interface development for all software element and technical
management tools provided under the Contract). General qualifications must
include a university degree in the field of ICT / Engineering and fluency in
English language (spoken and written).
 Senior Training Specialists with documented experience in the development and
implementation of technical and user training programs in at least one successful
implementation of an integrated revenue administration systems using the
System’s core RMS product. General qualifications must include a university
degree in the field of Economics / Business Administration / ICT / Engineering
and fluency in English language (spoken and written).
7.2. Supplier’s Team (Warranty Period). The Supplier MUST establish and maintain
a stable team with the same minimum skills and minimum experience as during
the Supply and Installation Period – except that the Team Leader, instead, MUST
have documented experience in managing technical support teams (including
client relations) in at least one successful implementation of an integrated
revenue administration systems using the System’s core RMS product. General
qualifications must include an university degree in the field of Business
Administration / Business Management / Economics / ICT / Engineering and
fluency in English language (spoken and written).
242 Section V: Requirements of the Information System

TESTING AND QUALITY ASSURANCE REQUIREMENTS

8. Inspections, Installation and Operational Acceptance Testing and Control of
Technical Support Services

8.1. Delivery. The one-time and all-encompassing Delivery milestone should be

achieved when:

 The Purchaser formally confirms and documents the completeness (and

validity) of the software licenses for all components of the System
(inclusive of certificates of origin, manufactures’ certificates of conformity,
manufactures’ certificates of quality, and license certificates).
 The Purchaser formally accepts the Supplier’s submission of final
Verification and Validation reports for all the planning, analysis, design and
training documentation(and verify that the Supplier grants to the Purchaser
not-for-resale unrestricted rights to store, duplicate and communicate the
various documents/materials created and supplied under the Contract).

8.2. Installation. The one-time and all-encompassing Installation milestone should be

achieved when:

 The Purchaser formally accepts the Supplier’s submission of final

Verification and Validation reports for the last pre-production version of the
System and the provision of the corresponding agreed training programs.

8.3. Operational Acceptance. The one-time and all-encompassing Operational

Acceptance milestone should be achieved when:

 The Purchaser formally accepts the Supplier’s submission of final

Verification and Validation reports for the last iteration of the production
version of the System required to complete the phased national roll-out
(including, but not restricted, to the overall system performance and
capacity requirements specified above).

 The Purchaser formally confirms that all System and implementation

related documentation is complete, up-to-date and subject to not-for-resale
unrestricted rights to store, duplicate and communicate).

 The Purchaser formally confirms the Technical Support arrangements are

established and satisfactorily pass initial testing.

8.4. Technical Support. Technical Support Services (during the Warranty Period)
should be controlled on a monthly and twice-yearly basis. In accordance with the
with the Warranty Defect Repair and Technical Support Service Sub-Plan of the
Agreed Project Plan:

 On a monthly basis, the Purchaser MUST formally accept and document the
provision of the Supplier’s monthly reports, including, but not restricted to:
the contact center’s monthly logs of in-coming and out-going
communications; a comprehensive summary of the Supplier’s support
Section V. Requirements of the Information System 243

activities (requested, commenced, completed and on-going); issues

requiring the Purchaser’s management attention and/or action; etc.

 On at least a twice yearly basis, the Purchaser MUST review the Supplier’s
monthly reports for the preceding six months, meet with the Supplier’s
Team Leader to discuss the performance of the past six months and
expectations for the subsequent six months, and review the Supplier’s
minutes of the review meeting. The Purchaser’s formal acceptance of the
meeting minutes should constitute satisfactory performance of the
Supplier’s Technical Support Services for the period (and trigger the
corresponding payment under the Contract).The Purchaser reserves the
right to shorten the six-month review period to, for example, address any
quality or performance concerns the Purchaser may have. With appropriate
advance notice, the Purchaser shall inform the Supplier in writing of the
change in this requirement and the ramifications for the payment schedule.

 For the final six month period under the Contract, in addition to the above
six-month requirements, the Supplier MUST demonstrate to the Purchaser’s
satisfaction that the system documentation (hard copy and digital) is
complete and up-to-date (i.e., that it reflects all the changes implemented
during the Warranty Period). Moreover, the Supplier MUST deliver to the
Purchaser the up-to-date, fully documented and commented source code or
all Custom Software developed under the Contract (and formally designated
as such). The Purchaser should formally document to the Supplier that the
Purchaser will NOT to transfer the code to any other external party and will
use it ONLY for the purpose of updating/further developing NAFA's IT
system(s).
 Implementation Schedule

Table of Contents: Implementation Schedule

A. Implementation Schedule.....................................................................................244
B. Site Table...............................................................................................................247
C. Table of Holidays and Other Non-Working Days.............................................277
Y
Section V. Requirements of the Information System

A. IMPLEMENTATION SCHEDULE

Note: Indicative Schedule (to be rendered consistent with the Supplier’s technologies and methodologies)

Year 1 Year 2 Year Warranty Period

3
Q Q Q Q Q Q Q Q Q Q W W W W W
1 2 3 4 1 2 3 4 1 2 1 2 3 4 5

Project Plan
Final Delivery Milestone (60 days from Effectiveness) 

Analysis & Design

BPs
System
ICT Platform Requirements
Test Data and Test Script Requirements
Roles/Jobs Scheme & Training Programs
review, revision, approval
deliver software components, elements, and technical management tools

Delivery Milestone 

Configuration V.1 (Full functionality “out-of-the-box” configuration)

 Section V. Requirements of the Information System

Year 1 Year 2 Year Warranty Period

3
Q Q Q Q Q Q Q Q Q Q W W W W W
1 2 3 4 1 2 3 4 1 2 1 2 3 4 5

train
load and configure software products (on test and training platform)
load test data set 1
test
plan/specify V.2

Configuration V.2 (Customized and Localized version and interfaces)

train
configure
reload test data set 1
retest
reload test data set 2
retest
plan/specify V.3
Installation Milestone 

Configuration V.3 (1st Production Version running on the production platform, with a
full production data, set and deployed as parallel operations in select test offices)
train
configure
populate production data
Section V. Requirements of the Information System

Year 1 Year 2 Year Warranty Period

3
Q Q Q Q Q Q Q Q Q Q W W W W W
1 2 3 4 1 2 3 4 1 2 1 2 3 4 5

interface/integrate
test
plan/specify V.4 and roll-out

Configuration V.4 (2nd Production, 3rd Production, … Full National Roll-out)

train
configure
integrate and populate
test
Operational Acceptance Milestone 

Technical Support
 Section V. Requirements of the Information System

B. SITE TABLE

Site Code Site Commune/City / County / Region Primary Street Address

09 Head Office of NAFA National Bucureşti, Str. Apolodor, Nr. 17, Sector
5, 021.387.1000
Anti-Tax Fraud General N/a Piaţa Presei Libere, nr. 1, Corp C3, Et. 3-
Directorate 4, Sector 1, Bucureşti
021 327 06 29
General Directorate for Integrity Splaiul Independentei nr.202 A , etaj 6,
Sector 6
Bucureşti,
021.211.55.60
Fiscal Verification Directorate / Strada Ion Câmpineanu, nr. 16, Sector 1
General Directorate for Appeals Bucureşti
Settlement / General Directorate 021.319.14.76
of Services for Taxpayers

General Directorate for Large Strada Mihail Sebastian nr. 88, Sector 5
Taxpayers Bucureşti,
021.408.94.03
General Directorate for B-dul. LIBERTĂŢII nr. 14 A etaj 4
Procedures on Revenue Bucureşti,
Administration/ General 021.312.24.29
Directorate for Strategy and
International Relations / General
Directorate for Regulation of
Budgetary Claims Collection
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

General Directorate for Strada Poenaru Bordea nr. 3 – 5 / Piata

Information Technology Alba Iulia, nr. 6,
Sector 4, Bucureşti
021.319.98.89
Directorate for Information Strada Matei Millo nr. 13, Sector 1,
Technology, Bucureşti,
0213155858
Communication and Customs
Statistics

01 Regional General Directorate of Public REGION Str. Aurel Vlaicu nr. 22,
Finance PLOIEŞTI C.P. 100023
Jud. Prahova
0244/407710
01.01 County Public Finance Argeş County Piteşti, Judeţul Argeş
Administration ARGEŞ B-dul Republicii nr. 118
C.P.110050
Tel. 0248/211511
01.01.01 Municipal Fiscal Service City Câmpulung, Judeţul Argeş
Câmpulung Str. Negru Vodă nr.117 şi Str.Negru
Vodă nr.84,
C.P. 115100
Tel. 0248/510830
01.01.02 Municipal Fiscal Service Curtea City Curtea de Argeş, Judeţul Argeş
de Argeş Str. Nevers nr.1
C.P. 115300
Tel. 0248/722159
01.01.03 Town Fiscal Service Costeşti City Costeşti, Judeţul Argeş
Str.Victoriei, nr.47
C.P.115200
Tel. 0248/672768
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

01.01.04 Town Fiscal Service Topoloveni City Topoloveni, Judeţul Argeş

Calea Bucureşti nr. 107A
C.P. 115500
Tel. 0248/666900
01.01.05 Town Fiscal Service Mioveni City Mioveni, Judeţul Argeş
B-dul Dacia, bloc V2B, Sc.D, mezanin,
C.P. 115400
01.02 County Public Finance Călăraşi County CĂLĂRAŞI, Judeţul Călăraşi
Administration CĂLĂRAŞI Str. Eroilor, nr.6-8,
C.P.910005,
Tel. 0242/315266,
01.02.01 Municipal Fiscal Service Olteniţa City Olteniţa, Judeţul Călăraşi
Str. Republicii nr.1
C.P.915400
Tel. 0242/513166
01.02.02 Town Fiscal Service City Oraş Lehliu-Gară, Judeţul Călăraşi
Str.Crinului nr.2,
Lehliu C.P. 915300
Tel. 0242/640846
01.02.03 Town Fiscal Service City Budeşti, Judeţul Călăraşi
Str.Republicii nr.49,
Budeşti C.P. 915100
Tel. 0242/528304
01.03 County Public Finance Dâmboviţa County Târgovişte, Judeţul Dâmboviţa
Administration DÂMBOVIŢA Calea Domnească nr.166
C.P.130003,
Tel. 0245/616779
01.03.01 Municipal Fiscal Service Moreni City Moreni, Judeţul Dâmboviţa
Cpt. Pantea Ion nr.39, bl.B1
C.P.135300
Tel. 0245/666100
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

01.03.02 Town Fiscal Service City Pucioasa, Judeţul Dâmboviţa

Str.Republicii nr.1
Pucioasa C.P.135400
Tel. 0245/760698
01.03.03 Town Fiscal Service City Găeşti, Judeţul Dâmboviţa
Str. Cuza Vodă nr 4, bl. 30, Sc. A,
Găeşti C.P.135300
Tel. 0245/713445
01.03.04 Town Fiscal Service City Titu, Judeţul Dâmboviţa
 Str.Gării nr.79
Titu C.P.135500
Tel. 0245/651112
01.04 County Public Finance Giurgiu County GIURGIU, Judeţul Giurgiu
Administration GIURGIU Sos.Bucureşti nr.12
C.P. 080045
Tel. 0246/216.705,
01.04.01 Town Fiscal Service City Bonlintin Vale, Judeţul Giurgiu
Bd. Republicii Bl.B5,
Bonlintin Vale C.P. 85100
Tel. 0246/270520
01.04.02 Town Fiscal Service City Mihăileşti, Judeţul Giurgiu
Str. Avicola,
Mihăileşti C.P. 085200
Tel. 0246/278023
01.05 County Public Finance Ialomiţa County Slobozia, Judeţul Ialomiţa
Administration IALOMIŢA Str. Matei Basarab nr. 14,
C.P. 920031
Tel. 0243/237140
01.05.01 Municipal Fiscal Service Feteşti City Feteşti, Judeţul Ialomiţa
str. Ceahlău nr. 44
Tel. 0243/364750, 0243/361577
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

01.05.02 Municipal Fiscal Service Urziceni City Urziceni, Judeţul Ialomiţa

str. Revoluţiei nr. 11A
Tel. 0243/254329

01.06 County Public Finance Prahova County Ploieşti, Judeţul Prahova

Administration PRAHOVA Str. Aurel Vlaicu nr. 22, C.P. 100023
Tel. 0244/407710
01.06.01 Municipal Fiscal Service City Câmpina, Judeţul Prahova
Câmpina Str. Mioriţei nr.16,
C.P. 105600
Tel. 0244/376011
01.06.02 Town Fiscal Service City Băicoi, Judeţul Prahova
Str. Republicii nr.75B
Băicoi C.P. 105200
Tel. 0244/268674
01.06.03 Town Fiscal Service City Buşteni, Judeţul Prahova
Str. Nestor Ureche, nr. 3
Buşteni C.P. 105500
Tel. 0244/320155

01.06.04 Town Fiscal Service City Ploieşti, Judeţul Prahova

Str. Democraţiei, Nr. 60-62, C.P. 100560
Boldeşti-Scăeni Tel. 0244/512879
01.06.05 Town Fiscal Service City Mizil, Judeţul Prahova
Str. Blajului nr. 8,
Mizil C.P. 105800
Tel. 0244/251671
01.06.06 Town Fiscal Service City Slănic, Judeţul Prahova
Str. 23 August nr. 13, C.P. 106200
Slănic Tel. 0244/240976
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

01.06.07 Town Fiscal Service City Vălenii de Munte, Judeţul Prahova

Str. Popa Şapcă nr. 7,
Vălenii de Munte C.P. 106400
Tel. 0244/283006
01.07 County Public Finance Teleorman County Alexandria, Judeţul Teleorman
Administration TELEORMAN Str. Dunării, nr. 188,
C.P. 140.046
Tel. 0247/421.168, 0247
01.07.01 Municipal Fiscal Service Turnu City Turnu Măgurele, Judeţul Teleorman
Măgurele Calea Dunării, nr. 1,
C.P. 145.200
Tel. 0247 / 416.937
01.07.02 Municipal Fiscal Service Roşiorii City Roşiorii de Vede, Judeţul Teleorman
de Vede  Str. Sf. Teodor nr. 1,
C.P. 145100
Tel. 0247/466.521
01.07.03 Town Fiscal Service City Videle, Judeţul Teleorman
Str. Giurgiului nr. 13,
Videle C.P. 145.300
Tel. 0247 /453.103
01.07.04 Town Fiscal Service City Zimnicea, Judeţul Teleorman
Sos. Giurgiului nr. 1,
Zimnicea C.P. 145.400
Tel. 0247 /366.441
02 Regional General Directorate of Public REGION Timişoara, jud. Timiş,
Finance TIMIŞOARA Str. Gheorghe Lazăr nr.9B,
C.P. 300081,
0256.499.334
02.01 County Public Finance Arad County Arad, Judeţul Arad
Administration ARAD B-dul Revoluţiei, nr. 77,
C.P. 310130
Tel. 0257/202700
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

02.01.01 Town Fiscal Service City Chişineu Criş, Judeţul Arad

Str. Gării, nr. 1/A,
Chişineu Criş C.P. 315100,
Tel. 0257/350659
02.01.02 Town Fiscal Service City Lipova, Judeţul Arad
Str. Nicolae Bălcescu nr. 5
Lipova C.P. 315400
0257/561453
02.01.03 Town Fiscal Service City Ineu, Judeţul Arad
Str. Republicii, nr. 16
Ineu C.P. 315300
Tel. 0257/511553
02.01.04 Town Fiscal Service City Sebiş, Judeţul Arad
Str. Romana, nr.4
Sebiş C.P. 315700
Tel. 0257/311016
02.01.05 Village Fiscal Service Village Săvârşin, Judeţul Arad
Str. Vlad Ţepeş nr. 400A
Săvârşin C.P. 317270
Tel. 0257/557591
02.02 County Public Finance Caraş-Severin County Reşiţa, Judeţul Caraş-Severin
Administration CARAŞ-SEVERIN Str. Domanului nr. 2 C.P. 320071
Tel. 0255/210.661
02.02.01 Municipal Fiscal Service City Caransebeş, Judeţul Caraş-Severin
Caransebeş Str. Gen. M. Trapşa, nr. 1
C.P. 325400
Tel. 0255/511154
02.02.02 Town Fiscal Service City Băile Herculane, Judeţul Caraş-Severin
Str. Mihai Eminescu nr. 10
Băile Herculane C.P. 325200
Tel. 0255/560501
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

02.02.03 Town Fiscal Service City Moldova Nouă, Judeţul Caraş-Severin

Str. Dunării nr. 224
Moldova Nouă C.P. 325500
Tel. 0255/540643
02.02.04 Town Fiscal Service City Oraviţa, Judeţul Caraş-Severin
Str. Emil Gojdu nr. 43-45
Oraviţa C.P. 325600
Tel. 0255/571580
02.02.05 Town Fiscal Service City Oţelu Roşu, Judeţul Caraş-Severin
Str. Haţegului nr. 110
Oţelu Roşu C.P. 325300
Tel. 0255/530964
02.02.06 Village Fiscal Service Village Bozovici, Judeţul Caraş-Severin
Str. M. Eminescu, nr. 250/B
Bozovici C.P. 327040
Tel. 0255/242381
02.03 County Public Finance Hunedoara County Deva, Judeţul Hunedoara
Administration HUNEDOARA Str.Avram Iancu Bl.H3 Parter
C.P. 330025
Tel. 0254/215944
02.03.01 Municipal Fiscal Service Brad City Brad, Judeţul Hunedoara
Str. Republicii, nr. 8
C.P. 335200
Tel. 0254/612607
02.03.02 Municipal Fiscal Service City Hunedoara, Judeţul Hunedoara
Hunedoara Str. George Enescu, nr. 10
C.P. 331056
Tel. 0254/712956
02.03.03 Municipal Fiscal Service Orăştie City Orăştie, Judeţul Hunedoara
Str. Armatei, nr. 21,
C.P. 335700,
Tel. 0254/247638
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

02.03.04 Municipal Fiscal Service City Petroşani, Judeţul Hunedoara

Petroşani Str. 1 Decembrie 1918, nr.90
C.P. 332005,
Tel. 0254/542318
02.03.05 Town Fiscal Service City Haţeg, Judeţul Hunedoara
Str. Tudor Vladimirescu, nr. 11
Haţeg C.P. 335500,
Tel. 0254/770103
02.04 County Public Finance Timiş County Timişoara, Judeţul Timiş
Administration TIMIŞ Str. Gheorghe Lazăr nr.9B,
C.P. 300081
Tel. 0256.290.500
02.04.01 Municipal Fiscal Service Lugoj City Lugoj, Judeţul Timiş
Str. Alexandru Astalaş nr.1-3
C.P. 305500
Tel. 0256.351.673
02.04.02 Town Fiscal Service City Buziaş, Judeţul Timiş
Str. Principală nr.17
Buziaş C.P. 305100
Tel. 0256.321.773
02.04.03 Town Fiscal Service City Deta, Judeţul Timiş
Str. Înfrăţirii nr.11
Deta C.P. 305200
Tel. 0256.390.404
02.04.04 Town Fiscal Service City Făget, Judeţul Timiş
Calea Lugojului nr.25
Făget C.P. 305300
Tel. 0256.320.420
02.04.05 Town Fiscal Service City Jimbolia, Judeţul Timiş
Str. Republicii nr.31
Jimbolia C.P. 305400
Tel. 0256.360.670
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

02.04.06 Town Fiscal Service City Sânnicolau Mare, Judeţul Timiş

Str. Profesor Ion Stamate nr.1
Sânnicolau Mare C.P. 305600
Tel. 0256.370.202
03 Regional General Directorate of Public REGION Cluj-Napoca, Piata Avram Iancu nr. 19,
Finance CLUJ-NAPOCA C.P. 400117, Jud. Cluj 0264/592.602

03.01 County Public Finance Bihor County Oradea, Judeţul Bihor

Administration BIHOR Str.Dimitrie Cantemir nr.2B,
C.P. 410519
Tel. 0259/433050
03.01.01 Town Fiscal Service City Aleşd, Judeţul Bihor
Str.Avram Iancu nr.1,
Aleşd C.P. 415100
Tel. 0259/342237
03.01.02 Town Fiscal Service City Beiuş, Judeţul Bihor
Str.Horia nr.20,
Beiuş C.P. 415200
Tel. 0259/322321

03.01.03 Town Fiscal Service City Marghita, Judeţul Bihor

Str.Republicii nr.70-74
Marghita C.P. 415300
Tel. 0259/362642
03.01.04 Town Fiscal Service City Salonta, Judeţul Bihor
str. Republicii nr. 36
Salonta C.P. 414500  
Tel. 0259/372537
03.02 County Public Finance Bistriţa-Năsăud County Bistriţa, Judeţul Bistriţa-Năsăud
Administration BISTRIŢA-NĂSĂUD Str. Decembrie, nr. 6-8
C.P. 420080
Tel. 0263/210661
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

03.02.01 Town Fiscal Service City Beclean, Judeţul Bistriţa-Năsăud

Str.Trandafirilor nr.2A,
Beclean C.P. 425100
Tel. 0263/340820
03.02.02 Town Fiscal Service City Năsăud, Judeţul Bistriţa-Năsăud
Piaţa Unirii, nr.3A,
Năsăud C.P. 425200
Tel. 0263/360787
03.02.03 Town Fiscal Service City Sângeorz Băi, Judeţul Bistriţa-Năsăud
Str.Izvoarelor nr.2,
Sângeorz Băi C.P. 425300
Tel. 0263/371591
03.03 County Public Finance Cluj County Cluj-Napoca, Judeţul Cluj
Administration CLUJ Piaţa Avram Iancu nr. 19,
C.P. 400117
0264/592.602
03.03.01 Municipal Fiscal Service Turda City Turda, Judeţul Cluj
Piaţa Romană nr. 15/b,
C.P. 401188
Tel. 0264/314941
03.03.02 Municipal Fiscal Service City Dej, Judeţul Cluj
Str. Mihai Eminescu nr 2,
Dej C.P. 405200
Tel.0264/216230
03.03.03 Municipal Fiscal Service Gherla City Gherla, Judeţul Cluj
Str. Armenească nr. 63,
C.P. 40530
Tel. 0264/243037
03.03.04 Town Fiscal Service City Huedin, Judeţul Cluj
Str. Horea nr. 23,
Huedin C.P. 405400
Tel.0264/351944
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

03.04 County Public Finance Maramureş County Baia Mare, Judeţul Maramureş
Administration MARAMUREŞ Str. Serelor, nr. 2/A
C.P. 430333
Tel. 0262/205150
03.04.01 Municipal Fiscal Service City Sighetu Marmaţiei, Judeţul Maramureş
str. Serelor nr. 2/A
Sighetu Marmaţiei C.P. 430333
Tel. 0262/205012
03.04.02 Town Fiscal Service City Târgu Lăpuş, Judeţul Maramureş
str. Doinei nr. 5,
Târgu Lăpuş C.P. 435600
Tel. 0262/384409
03.04.03 Town Fiscal Service City Vişeu de Sus, Judeţul Maramureş
str. 22 Decembrie nr. 15,  
Vişeu de Sus C.P. 435700   
Tel. 0262/352731
03.05 County Public Finance Satu Mare County SATU MARE, Judeţul Satu Mare
Administration SATU MARE Piaţa Romană, nr. 3-5,
CP 440012
Tel. 0261/807039
03.05.01 Municipal Fiscal Service City Carei, Judeţul Satu Mare
Cartierul Republicii, nr. 20,
Carei C.P. 445100
Tel. 0261/864042
03.05.02 Town Fiscal Service City Negreşti Oaş, Judeţul Satu Mare
Str. Victoriei, nr. 109,
Negreşti Oaş C.P. 445200
Tel. 0261/854691
03.05.03 Town Fiscal Service City Tăşnad, Judeţul Satu Mare
Str. Lăcrămioarei nr. 57,
Tăşnad C.P. 445300
Tel. 0261/825672
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

03.06 County Public Finance Sălaj County Zalău, Judeţul Sălaj

Administration SĂLAJ Piaţa Iuliu Maniu, nr. 15,
C.P. 450016
Tel. 0260/662309
03.06.01 Town Fiscal Service City Şimleu Silvaniei, Judeţul Sălaj
str.1 Decembrie 1918 nr.23
Şimleu Silvaniei C.P. 455300
Tel. 0260/679306
03.06.02 Town Fiscal Service City Jibou, Judeţul Sălaj
Str. 1 Decembrie 1918, Nr. 4
Jibou C.P. 455200
Tel. 0260/641496
03.06.03 Town Fiscal Service City Cehu Silvaniei, Judeţul Sălaj
P-ţa Trandafirilor, Nr. 18  
Cehu Silvaniei C.P. 455100
Tel. 0260/650888
04 Regional General Directorate of Public REGION Iaşi
Finance IAŞI Str. Anastasie Panu nr. 26,  
700020
Jud. Iaşi
0232/213332
04.01 County Public Finance Bacău County BACĂU, Judeţul Bacău
Administration BACĂU str. Dumbrava Roşie nr. 1-3
C.P. 600045
0234/510015
04.01.01 Municipal Fiscal Service City Oneşti, Judeţul Bacău
str.Poştei, nr.5
Oneşti C.P. 601010
Tel.0234/320671
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

04.01.02 Town Fiscal Service City Buhuşi, Judeţul Bacău

str.Republicii, nr.2 bis
Buhuşi C.P. 605100
Tel. 0234/261461
04.01.03 Town Fiscal Service City Moineşti, Judeţul Bacău
str.Zorilor, nr.1, bl.B1
Moineşti C.P. 605400
Tel. 0234/364774
04.01.04 Village Fiscal Office Village Podu Turcului, Judeţul Bacău
Str.Tudor Vladimirescu, nr.14
Podu Turcului C.P. 607450
Tel. 0234/289217
04.02 County Public Finance Botoşani County BOTOŞANI, Judeţul Botoşani
Administration BOTOŞANI Piaţa Revolutiei nr.5
C.P. 710236
Tel. 0231/ 607120
04.02.01 Municipal Fiscal Service City Dorohoi, Judeţul Botoşani
Ghica nr.28,
Dorohoi C.P. 715200
Tel. 0231/607050
04.02.02 Town Fiscal Service City Dărăbani, Judeţul Botoşani
Str. Pieţei nr.26
Dărăbani C.P. 715100
Tel. 0231/631248
04.02.03 Town Fiscal Service City Săveni, Judeţul Botoşani
Str.Decembrie nr.39
Săveni C.P. 715300
Tel. 0231/541999
04.03 County Public Finance Iaşi County IAŞI, Judeţul Iaşi
Administration IAŞI Str. Anastasie Panu nr.26
C.P. 700020
Tel. 0232/210005
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

04.03.01 Municipal Fiscal Service City Paşcani, Judeţul Iaşi

Str.Grădiniţei nr.2A, bl.G1-A,
Paşcani C.P. 705200
Tel. 0232/760489
04.03.02 Town Fiscal Service City Hârlău, Judeţul Iaşi
Str.Stefan cel Mare bl.2B,
Hârlău C.P. 70510
Tel. 0232/720728
04.03.03 Town Fiscal Service City Târgu Frumos, Judeţul Iaşi
Str. Cuza Vodă nr. 40-41,
Târgu Frumos C.P. 705300
Tel. 0232/712220
04.03.04 Village Fiscal Office Village Com. Răducăneni, Judeţul Iaşi
C.P. 707400
Răducăneni Tel. 0232/292327
04.04 County Public Finance Neamţ County Piatra Neamţ, Judeţul Neamţ
Administration NEAMŢ Bd. Traian nr. 19 bis,
C.P. 610137
Tel. 0233 /207630
04.04.01 Municipal Fiscal Service City Roman, Judeţul Neamţ
Piaţa Roman Vodă nr.1
Roman C.P. 611022
Tel. 0233/740129
04.04.02 Town Fiscal Service City Târgu Neamţ, Judeţul Neamţ
Str. Stefan cel Mare nr. 48,
Târgu Neamţ C.P. 615200
Tel. 0233/79.00.40
04.04.03 Town Fiscal Service City Bicaz, Judeţul Neamţ
Str.Barajului nr.7,
Bicaz C.P. 615100
Tel. 0233/25.31.96
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

04.05 County Public Finance Suceava County SUCEAVA, Judeţul Suceava

Administration SUCEAVA Str. Vasile Bumbac nr.1
C.P.720003
Tel. 0230/521358
04.05.01 Municipal Fiscal Service City Câmpulung Moldovenesc, Judeţul
Suceava
Câmpulung Moldovenesc Str. 22 Decembrie, nr.2A
C.P. 725100
Tel. 0230/312310
04.05.02 Municipal Fiscal Service City Fălticeni, Judeţul Suceava
Str. Republicii nr.27, C.P. 725200
Fălticeni Tel. 0230/541054
04.05.03 Municipal Fiscal Service City Rădăuţi, Judeţul Suceava
Str. 1 Mai, nr.3,
Rădăuţi C.P. 724500
Tel. 0230/561067
04.05.04 Municipal Fiscal Service City Vatra Dornei, Judeţul Suceava
Str. Mihai Eminescu
Vatra Dornei  nr.47
C.P. 725700
Tel. 0230/374045
04.05.05 Town Fiscal Service City Gura Humorului, Judeţul Suceava
Str. Mânăstirea Humorului nr.6
Gura Humorului C.P. 725300
Tel. 0230/231391
04.05.06 Town Fiscal Service City Siret, Judeţul Suceava
Str. Sucevei nr. 1
Siret C.P. 725500
Tel. 0230/280635
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

04.06 County Public Finance Vaslui County VASLUI, Judeţul Vaslui

Administration VASLUI Str. Stefan cel Mare, nr. 56
C.P. 730171
Tel. 0235/314.143
04.06.01 Municipal Fiscal Service City Bârlad, Judeţul Vaslui
Str. 1 Decembrie nr. 23
Bârlad C.P.  731182
Tel. 0235/419570
04.06.02 Municipal Fiscal Service City Huşi, Judeţul Vaslui
Str. G-ral Teleman, nr. 18 
Huşi C.P.  735100
Tel. 0235/480707
04.06.03 Town Fiscal Service City Negreşti, Judeţul Vaslui
Str. Decebal, nr. 7
Negreşti C.P.  735200 
Tel. 0235/457856
05 Regional General Directorate of Public REGION Braşov, Judeţul Braşov
Finance BRAŞOV Bd. Mihail Kogălniceanu nr. 7, C.P.
500090
Jud. Braşov
0268/308421
05.01 County Public Finance Alba County Alba Iulia, Judeţul Alba
Administration ALBA Str. Primăverii nr. 10 C.P. 510110
Tel. 0258/813002
05.01.01 Municipal Fiscal Service City Aiud, Judeţul Alba
Str. Simion Bărnuţiu nr.8 C.P. 51520
Aiud Tel. 0258/861324
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.01.02 Municipal Fiscal Service City Blaj, Judeţul Alba

Str. Mitropolit Ioan Vancea nr.2
Blaj C.P. 51540
Tel . 0258/711539

05.01.03 Municipal Fiscal Service City Sebeş, Judeţul Alba

Str. Valea Frumoasei nr. 26
Sebeş C.P. 51580
Tel. 0258/734405

05.01.04 Town Fiscal Service City Câmpeni, Judeţul Alba

Piaţa Avram Iancu nr.1
Câmpeni C.P. 515500
Tel. 0258/771553

05.01.05 Town Fiscal Service City Cugir, Judeţul Alba

Str. 21 Decembrie 1989 nr. 56
Cugir C.P. 515600
Tel. 0258/754947

05.01.06 Town Fiscal Service City Zlatna, Judeţul Alba

Str. Valea Morilor nr. 1,
Zlatna C.P. 516100
Tel. 0258/856223

05.02 County Public Finance Braşov County BRAŞOV, Judeţul Braşov

Administration BRAŞOV Bd. Mihail Kogălniceanu nr. 7
C.P. 500090
0268/308421
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.02.01 Municipal Fiscal Service City Făgăraş, Judeţul Braşov

Str. Republicii nr.2
Făgăraş C.P. 505200
Tel. 0268/211226

05.02.02 Town Fiscal Service City Săcele, Judeţul Braşov

Str. Mihai Eminescu, nr.2
Săcele C.P. 505600
Tel. 0268/276143

05.02.03 Town Fiscal Service City Codlea, Judeţul Braşov

Str. Lungă nr. 108
Codlea C.P. 505100
Tel. 0268/252943

05.02.04 Town Fiscal Service City Rupea, Judeţul Braşov

Str. Republicii, nr.193,
Rupea C.P. 505500
Tel. 0268/260959

05.02.05 Town Fiscal Service City Victoria, Judeţul Braşov

Str. Decembrie, nr.3,
Victoria C.P. 505700
Tel. 0268/241595

05.02.06 Town Fiscal Service City Zărneşti, Judeţul Braşov

Str. Mitropolit Meţianu, nr. 126,
Zărneşti C.P. 505800
Tel. 0268/223058
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.02.07 Town Fiscal Service City Râşnov, Judeţul Braşov

Piaţa Unirii nr. 20,
Râşnov C.P. 505400
Tel. 0268/230186

05.03 County Public Finance Covasna County COVASNA, Judeţul Covasna

Administration COVASNA Sfântu Gheorghe,
Str. Bem Jozef nr.9
C.P. 520023
Tel. 0267.351.86
05.03.01 Municipal Fiscal Service City Târgu Secuiesc, Judeţul Covasna
Str. Kossuth Lajos nr.10
Târgu Secuiesc C.P. 525400
Tel. 02636373

05.03.02 Town Fiscal Service City Baraolt, Judeţul Covasna

Str. Libertăţii nr. 19
Baraolt C.P. 525100
Tel. 02637766

05.04 County Public Finance Harghita County Miercurea Ciuc, Judeţul Harghita
Administration HARGHITA Str.Rev.din Decembrie nr.20,
C.P. 530223
Tel. 0266/207800
05.04.01 Municipal Fiscal Service City Odorheiu Secuiesc, Judeţul Harghita
Str. Morii nr.5,
Odorheiu Secuiesc C.P. 535600
Tel. 0266 217558
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.04.02 Municipal Fiscal Service City Topliţa, Judeţul Harghita

str.Nicolae Bălcescu nr.59 C.P. 535700
Topliţa Tel. 0266 343001

05.04.03 Town Fiscal Service City Gheorgheni, Judeţul Harghita

Str.Carpaţi nr.3,
Gheorgheni C.P. 535500
Tel. 0266 364849

05.05 County Public Finance Mureş County Târgu Mureş, Judeţul Mureş
Administration MUREŞ Str. Gheorghe Doja nr. 1-3,
C.P. 540015
Tel. 0265/250982
05.05.01 Municipal Fiscal Service City Sighişoara, Judeţul Mureş
Str. 1 Decembrie 1918 nr.37-39,
Sighişoara CP 545400
Tel. 0265/777634

05.05.02 Municipal Fiscal Service City Reghin, Judeţul Mureş

str. Petru Maior nr.33,
Reghin CP 545300
Tel. 0265/512591

05.05.03 Municipal Fiscal Service City Târnăveni, Judeţul Mureş

Str. Republicii nr.30,
Târnăveni C.P. 54560
Tel. 0265/443312
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.05.04 Town Fiscal Service City Luduş, Judeţul Mureş

Str. Republicii nr. 25,
Luduş C.P. 545200
Tel. 0265/413224

05.05.05 Town Fiscal Service City Sovata, Judeţul Mureş

Str. Principală nr.159
Sovata C.P. 545500
Tel. 0265-570310

05.06 County Public Finance Sibiu County SIBIU, Judeţul Sibiu

Administration SIBIU Calea Dumbrăvii,  nr. 17
CP 550324
tel 0269.218 331
05.06.01 Municipal Fiscal Service City Mediaş, Judeţul Sibiu
Str. I. C. Brătianu nr. 3
Mediaş CP 551003
Tel 0269.841 990
05.06.02 Town Fiscal Service City Agnita, Judeţul Sibiu
Str.1 Decembrie, nr. 2
Agnita CP 555100
Tel/fax 0269.510 630

05.06.03 Town Fiscal Service City Sălişte, Judeţul Sibiu

Str.Bucureşti nr. 4,
Sălişte C.P. 557225
Tel/fax 0269/553737
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

05.06.04 Town Fiscal Service City Avrig, Judeţul Sibiu

Str. Gh. Lazăr nr.41,
Avrig C.P. 555200
Tel/fax 0269/524430

06 Regional General Directorate of Public REGION Craiova,

Finance CRAIOVA Str. Mitropolit Firmilian nr.2,
C.P.200761
Jud. Dolj
0251/402312
06.01 County Public Finance Dolj County Craiova, Judeţul Dolj
Administration DOLJ Str. Mitropolit Firmilian nr.2
CP 200761
Tel. 0251/402212
06.01.01 Town Fiscal Service City Calafat, Judeţul Dolj
Str. Gheorghe Doja nr.3   
Calafat CP 205200
Tel. 0251/333231

06.01.02 Town Fiscal Service City Filiaşi, Judeţul Dolj

Bd. Racoţeanu nr.160
Filiaşi C.P. 205300
Tel. 0251/441835

06.01.03 Town Fiscal Service City Segarcea, Judeţul Dolj

Str. Unirii nr.56  
Segarcea CP 205400
Tel. 0251/210644
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

06.01.04 Town Fiscal Service City Bechet, Judeţul Dolj

Str. Nicolae Titulescu nr.27  
Bechet CP 207060
Tel. 0251/336795

06.01.05 Town Fiscal Service City Băileşti, Judeţul Dolj

Str. Victoriei nr.42
Băileşti CP 205100
Tel. 0251/312169

06.02 County Public Finance Gorj County Târgu Jiu, Judeţul Gorj
Administration GORJ Str. Siretului nr. 6,
C.P. 210190
Tel. 0253/212972
06.02.01 Town Fiscal Service City Motru, Judeţul Gorj
Str. Tineretului nr. 8
Motru C.P. 21520
Tel. 0253/360623

06.02.02 Town Fiscal Service City Novaci, Judeţul Gorj

Str. Parângului nr.32
Novaci C.P. 215
Tel. 0253/46625

06.02.03 Town Fiscal Service City Târgu Cărbuneşti, Judeţul Gorj

Str. Trandafirilor nr. 71,
Târgu Cărbuneşti C.P. 215500
Tel. 0253/3788131
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

06.02.04 Town Fiscal Service City Rovinari, Judeţul Gorj

Str. Florilor, nr.1,
Rovinari C.P. 215400
Tel. 0253/371169

06.03 County Public Finance Mehedinţi County Drobeta-Turnu Severin, Judeţul

Administration MEHEDINŢI Mehedinţi
Piaţa Radu Negru nr.1,
C.P. 220234
Tel. 0252/315774
06.03.01 Town Fiscal Service City Strehaia, Judeţul Mehedinţi
Str. Eroilor nr.5,
Strehaia C.P. 225300
Tel. 0252/370846

06.03.02 Town Fiscal Service City Orşova, Judeţul Mehedinţi

Str. 1 Decembrie 1918 nr.16B,
Orşova C.P. 225200
Tel. 0252/362826

06.03.03 Town Fiscal Service City Vânju Mare, Judeţul Mehedinţi

Str. Rahovei nr.3
Vânju Mare C.P.225400
Tel. 0252/350696

06.03.04 Town Fiscal Service City Baia de Aramă, Judeţul Mehedinţi

Str. Republicii nr.35
Baia de Aramă C.P. 225100
Tel. 0252/381236
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

06.04 County Public Finance Olt County Slatina, Judeţul Olt

Administration OLT Str. Arcului nr.2A
C.P. 230039
Tel. 0249/412155
06.04.01 Municipal Fiscal Service City Caracal, Judeţul Olt
Str. Toma Ruşcă nr. 5-7,
Caracal C.P. 235200
Tel. 0249/511155

06.04.02 Town Fiscal Service City Balş, Judeţul Olt

Str. Nicolae Bălcescu, nr. 13
Balş C.P. 235100
Tel. 0249/451717

06.04.03 Town Fiscal Service City Corabia, Judeţul Olt

Str. C.A Rosetti, nr.64,
Corabia C.P. 235300
Tel. 0249/561376

06.05 County Public Finance Vâlcea County Râmnicu Vâlcea, Judeţul Vâlcea
Administration VÂLCEA Str. G-ral Magheru nr. 17,
C.P. 240195
Tel. 0250/737777
06.05.01 Municipal Fiscal Service City Drăgăşani, Judeţul Vâlcea
Str.Regele Carol nr. 55, bl. A. parter
Drăgăşani C.P. 245700
Tel. 0250/811094
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

06.05.02 Town Fiscal Service City Bălceşti, Judeţul Vâlcea

Str. Petrache Poenaru nr. 8, parter,
Bălceşti C.P. 245400
Tel. 0250/840376

06.05.03 Town Fiscal Service City Gura Lotrului, Judeţul Vâlcea

Brezoi, Str. Lotrului nr. 2
Gura Lotrului C.P. 245500
Tel. 0350/806539

06.05.04 Town Fiscal Service City Horezu, Judeţul Vâlcea

Str. George Coşbuc nr.4
Horezu C.P. 245800
Tel. 0250/860997

06.05.05 Town Fiscal Service City Băbeni, Judeţul Vâlcea

Str. Dragoş Vrânceanu, bl. A5, parter
Băbeni C.P. 245100
Tel. 0250/765570

07 Regional General Directorate of Public REGION Galaţi, Str. Portului nr. 163, C.P. 800211
Finance GALAŢI Jud. Galaţi, 0236/460486

07.01 County Public Finance Brăila County BRĂILA, Judeţul Brăila

Administration BRĂILA Str. Delfinului nr. 1
C.P. 810210
Tel. 0239/619900
07.01.01 Town Fiscal Service City Însurăţei, Judeţul Brăila
Str.Brăilei nr.15,
Însurăţei C.P. 815300
Tel. 0239/660400
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

07.01.02 Town Fiscal Service City Făurei, Judeţul Brăila

Str.Depozitelor Bloc A4,
Făurei C.P. 815100
Tel. 0239/661669

07.01.03 Town Fiscal Service City Ianca, Judeţul Brăila

Str.Eroilor, Bloc F5
Ianca C.P. 815200
Tel. 0239/668930

07.02 County Public Finance Buzău County BUZĂU, Judeţul Buzău

Administration BUZĂU Str. Unirii nr. 209
C.P. 120191
0238/720570
07.02.01 Municipal Fiscal Service City Râmnicu Sărat, Judeţul Buzău
Str. Victoriei nr. 10
Râmnicu Sărat C.P. 12530
Tel. 0238/565461

07.02.02 Town Fiscal Service City Pogoanele, Judeţul Buzău

Str.Unirii, bl.3
Pogoanele C.P. 125200
Tel. 0238/552367

07.02.03 Town Fiscal Service City Pătârlagele, Judeţul Buzău

Str. N.Bălcescu bl. D parter,
Pătârlagele C.P. 127430
Tel. 0238/550947

07.03 County Public Finance Constanţa County CONSTANŢA, Judeţul Constanţa

Administration CONSTANŢA Str. I.G. Duca nr. 18
Tel. 0241/48.80.10, 0241/48.80.47
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

07.03.01 Municipal Fiscal Service City Mangalia, Judeţul Constanţa

Str. Mihai Viteazu nr.13,
Mangalia C.P. 905500
Tel. 0241/75.37.95

07.03.02 Municipal Fiscal Service City Medgidia, Judeţul Constanţa

Str. Decebal nr.37,
Medgidia C.P. 905600
Tel. 0241/81.03. 85

07.03.03 Town Fiscal Service City Eforie, Judeţul Constanţa

Str. Traian nr.7-9,
Eforie C.P. 905350
Tel. 0241/74.13.56

07.03.04 Town Fiscal Service City Hârşova, Judeţul Constanţa

Str. Vadului nr. 27, bl. V8M,
Hârşova C.P. 905400
Tel. 0241/87.03. 02

07.03.05 Town Fiscal Service City Năvodari, Judeţul Constanţa

Str. Sănătăţii nr.2,
Năvodari C.P. 905700
Tel. 0241/76.09. 09

07.03.06 Town Fiscal Service City Băneasa, Judeţul Constanţa

Str. Trandafirilor nr.100,
Băneasa C.P. 907035
Tel. 0241/85.03.15
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

07.04 County Public Finance Galaţi County GALAŢI, Judeţul Galaţi

Administration GALAŢI Str. Brăilei Nr.33
CP  800076
Tel. 0236/490008
07.04.01 Municipal Fiscal Service City Tecuci, Judeţul Galaţi
Str. Decembrie 1918 nr. 43
Tecuci C.P. 805300
Tel. 0236/820474

07.04.02 Town Fiscal Service City Târgu Bujor, Judeţul Galaţi

Str. General Eremia Grigorescu nr.28
Târgu Bujor C.P. 805
Tel. 0236/340962

07.05 County Public Finance Tulcea County TULCEA, Judeţul Tulcea

Administration TULCEA Str.Babadag, Nr.163 bis,
C.P.820112
Tel. 0240/502.601
07.05.01 Town Fiscal Service City Sulina, Judeţul Tulcea
Str. A II-a nr. 39,
Sulina CP 825400
Tel. 0240/543142

07.05.02 Town Fiscal Service City Babadag, Judeţul Tulcea

Str. Pavel Gheorghe nr.10,
Babadag C.P. 825100
Tel. 0240/562559

07.05.03 Town Fiscal Service City Măcin, Judeţul Tulcea

Str.Florilor nr.1,C.P. 825300
Măcin Tel. 0240/571417
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

07.05.04 Village Fiscal Office Village Baia, Judeţul Tulcea

Str.Republicii Nr.57
Baia C.P. 827005
Tel. 0240/564343

07.06 County Public Finance Vrancea County Focşani, Judeţul Vrancea

Administration VRANCEA Bd. Independentei nr. 24,
C.P.620112
Tel. 0237/236600
07.06.01 Municipal Fiscal Service City Adjud, Judeţul Vrancea
Str. Siret, bl.32, parter
Adjud C.P.625100
Tel. 0237/642480

07.06.02 Town Fiscal Service City Panciu, Judeţul Vrancea

Bd. Independenţei nr. 6
Panciu C.P.625400
Tel. 0237/275633

08 Regional General Directorate of REGION Bucureşti, Str. Dimitrie Gerota nr. 13,
Public Finance BUCUREŞTI sector 2, C.P. 020027
021-305.70.80
08.01 District 1 Public Finance District 1 Str.Londra nr.10, sect.1,
Administration C.P. 011761
Tel. 021-231.93.95
Bucureşti
Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

08.02 District 2 Public Finance District 2 Str.Avrig nr.63, sector 2

Administration Tel. 021-256.99.35 /
Str. C.A. Rosetti nr.39, sector 2,
C.P. 020012
Tel. 021-313.40.08
Bucureşti

08.03 District 3 Public Finance District 3 Str.Lucreţiu Pătrăşcanu nr.10, sect.3,

Administration C.P. 030504
Tel. 021-340.22.65 /
Calea Moşilor 156 sector 2  
CP 020883
Tel. 021-314.62.22
Bucureşti

08.04 District 4 Public Finance District 4 Bd. C.Brâncoveanu nr. 2, bl. 12, sect.4,
Administration C.P. 041447,
Tel. 021-332.63.53 /
Str.Cuţitul de Argint nr.7, sector 4,
Tel. 021-310.24.06
Bucureşti

08.05 District 5 Public Finance District 5 Calea 13 Septembrie nr. 226, bloc. V 54,
Administration sector 5,
C.P. 050735,
Tel. 021-410.06.12
Bucureşti

08.06 District 6 Public Finance District 6 Str. Popa Tatu nr.7, sect.1,
Administration C.P. 010801
Tel. 021/315.32.70
Bucureşti
 Section V. Requirements of the Information System

Site Code Site Commune/City / County / Region Primary Street Address

08.07 Fiscal Administration for Middle N/a Str.Prof.Dr.Dimitrie Gerota nr.13, sector
Size Taxpayers 2,
C.P. 020027
Tel. 021-305.70.80
Bucureşti

08.08 County Public Finance Ilfov County Bucureşti,

Administration ILFOV str Lucreţiu Pătrăşcanu nr. 10 Sector 3,
C.P.030507
Tel. 021/340.16.00
08.08.01 Town Fiscal Service City Buftea, Judeţul Ilfov
Bd Mihai Eminescu, nr. 1
Buftea C.P.70000
Tel. 021/3515611
08.08.02 Town Fiscal Service City Bragadiru, Judeţul Ilfov
Şos. Alexandriei, nr 271
Bragadiru C.P.77025
Tel. 021/4481371
Section V. Requirements of the Information System

C. TABLE OF HOLIDAYS AND OTHER NON-WORKING DAYS

Month 2015 2016 2017 2018 2019

1 01.01.2015 01.01.2016 01.01.2017 01.01.2018 01.01.2019
02.01.2015 02.01.2016 02.01.2017 02.01.2018 02.01.2019
24.01.2015 24.01.2016 24.01.2017 24.01.2018 24.01.2019
2
3
4 12.04.2015 16.04.2017 08.04.2018 28.04.2019
13.04.2015 17.04.2017 09.04.2018 29.04.2019
5 01.05.2015 01.05.2016 01.05.2017 01.05.2018 01.05.2019
31.05.2015 02.05.2016 27.05.2018
28.05.2018
6 01.06.2015 19.06.2016 04.06.2017 16.06.2019
20.06.2016 05.06.2017 17.06.2019
7
8 15.08.2015 15.08.2016 15.08.2017 15.08.2018 15.08.2019
9
10
11 30.11.2015 30.11.2016 30.11.2017 30.11.2018 30.11.2019
12 01.12.2015 01.12.2016 01.12.2017 01.12.2018 01.12.2019
25.12.2015 25.12.2016 25.12.2017 25.12.2018 25.12.2019
26.12.2015 26.12.2016 26.12.2017 26.12.2018 26.12.2019
282 Section V. Requirements of the Information System

Informational Materials

Table of Contents: Informational Materials

YAnnex 1: The Purchaser’s Organization...........................................................................2
Annex 2: Romanian Tax System (2015)............................................................................293
Annex 3: ANAF’s Test and Development Platform.........................................................338
Annex 4: Legacy Systems for Integration.........................................................................341
Annex 5: Detailed Functional Design Goals.....................................................................406
Annex 6: Databases for Migration....................................................................................558
Annex 7: Selected Acronyms..............................................................................................571
Section V. Requirements of the Information System 283

ANNEX 1: THE PURCHASER’S ORGANIZATION

ANAF is organized and operates as a specialized body of the central public administration, being a public institution and a legal person,
subordinated to the Ministry of Public Finance and is being financed from the state budget, in accordance with the relevant legislation.

The Agency provides the collection and the management of taxes, social contributions, as well as of other budget revenues provided by the
legislation in force (be it primary, secondary or tertiary legislation), the implementation of budget revenues collection as well as of
revenues from customs taxes, having also such responsibilities for the customs activities; the Agency is also in charge with operational and
unexpected on site controls and inspections, to detect, prevent and combat all acts and deeds that have as effect tax evasion, tax fraud or
customs fraud, as well as all other lawful actions under ANAF competencies,

The organizational structure of ANAF related to tax and customs administration is based on a combination between the functions model
and the model based on types of taxpayers. In addition, the Customs General Directorate is integrated in the tax administration structure,
as a specialized structure. ANAF has an unique feature referring to the fact that it shares the responsibility for the Treasury with the
Ministry of Public Finance, the only interaction with the tax administration and the revenues collection processes being the timely
reporting of the payments received by the Treasury, in order for such payments to be correlated with the tax returns and with other
payments.

At present, ANAF consists of its own apparatus and its subordinated structures. ANAF includes a General Directorate (Unit) for Large
Taxpayers (LTU) which is a structure without legal personality for now (but for the future is foreseen the set up of a structure with legal
personality, similar to the regional general directorates for public finance) as well as 8 regional general directorates for public finance,
having each its own legal personality, as a result of the fusion by absorption of the district general directorates for public finance from the
respective area of competency.

Within the 8 regional general directorates for public finance, we can find the following structures without legal personality
 regional customs directorates
 district administrations for public finance;
 municipal and town tax services/units, as well as tax offices at communes' level
 domestic and border customs offices
284 Section V. Requirements of the Information System

Presently, the ANAF structure consists of:

1. Central body (own apparatus)
2. Territorial structures
- 8 regional general directorates for public finance, which include the Regional Customs directorates
- 41 district administrations for public finance
- 6 Administrations of the sectors 1 - 6 of public finance within the regional general directorate of public finance Bucharest, one tax
administration for middle sized taxpayers and a tax administration for non-resident taxpayers
- 162 tax units, at the level of municipalities, towns as well as tax offices in communes
- 37 interior/domestic customs offices and 52 border tax offices, operating at territorial level, being guided and coordinated in their
operations and from the methodological point of view directly by the General Directorate for Customs.

The organizational structure of the national Agency for Fiscal Administration is presented in short in the following organizational charts.
Section V. Requirements of the Information System 285
286 Section V. Requirements of the Information System

NAFA Headquarters organizational chart:

Section V. Requirements of the Information System 287

Regional level
The 8 regional structures of ANAF are the following: Bucharest, Ploiesti, Braşov, Timişoara, Cluj-Napoca, Iaşi, Craiova and Galaţi

The role of the regional directorates is planning, coordinating and controlling their subordinated units (district tax administrations,
municipal and town tax units, commune tax offices) within their territorial coverage. In addition, the regional directorates have also a
support function (human resources, specialized training, internal finance unit, internal accounting unit, internal administration and public
procurement unit, IT).

Within the regional general directorates of public finance operate the regional customs directorates, managed by an executive director,
being methodologically coordinated by the Customs General directorate. Subordinated to the regional general directorates of public
finance may operate district administrations for public finance as well as municipal tax units, town tax units or commune tax offices.

Within the Regional General Directorate for public Finance Bucharest operate, as well, the following subordinated structures, having no
legal personality:

 The Tax Administration for Middle Size Taxpayers

 The Tax Administration for non-resident taxpayers
 The District administration of public finance Ilfov
 The Administration of sectors 1 - 6 for public finance

The organizational structure generally applicable for the Regional general directorates for public finance within NAFA is presented below:
288 Section V. Requirements of the Information System
Section V. Requirements of the Information System 289

The Regional General Directorate for Public Finance of Bucharest structure is presented below:
290 Section V. Requirements of the Information System

County/district level

There are 41 county administrations of public finance and 6 district administrations for public finance in Bucharest, coordinated by the
regional general directorates for public finance

The county administrations of public finance have different organizational structures according to their location, respectively:

 County administrations of public finance having their headquarters located in the same localities as the regional general
directorates of public finance
 County administrations of public finance other than those having their headquarters located in the same localities as the regional
general directorates for public finance

Below are illustrated the organizational structures of the district administrations of public finance:
Section V. Requirements of the Information System 291
292 Section V. Requirements of the Information System
Section V. Requirements of the Information System 293

Municipalities, towns and communes

Within the district administration for public finance at the level of municipalities (other than the capital town of the district) and towns may
operate as subordinated structures, without legal personality, municipal and town tax units, as well as commune tax offices, headed by a
head of unit and respectively head of office.

Like the district tax administrations, the municipal/town tax units and the commune offices report to the regional directorate to which they
are belonging and their role is to implement the plans received from the regional directorate.

The heads of municipal/town units and the heads of the commune offices are appointed by the general director of the regional directorate,
according to the law.
294 Section V. Requirements of the Information System
Section V. Requirements of the Information System 295
296 Section V. Requirements of the Information System
Section V. Requirements of the Information System 297

ANNEX 2: ROMANIAN TAX SYSTEM(2015)

A. Corporate Income Tax – In Romania - At a glance

Corporate Income Tax Rate (%) 16 (a)
Capital Gains Tax Rate (%) 16 (a)
Branch Tax Rate (%) 16 (a)
Withholding Tax (%) (b)
Dividends 16 (c)
Interest 16 (d)(e)(f)
Royalties 16 (d)(f)
Commissions 16 (d)
Certain types of services rendered abroad 16 (h)
Services Rendered in Romania 16 (d)
Gambling 25
Branch Remittance Tax 0
Net Operating Losses (Years)
Carryback 0
Carryforward 7 (g)
(a) See Section B.
(b) These withholding tax rates are standard and final. They can be reduced under double tax treaties or European Union (EU) directives.
(c) This tax may be reduced to nil for dividends paid to a legal entity residing in another EU member state or to a permanent establishment of an
entity residing in an EU member state, if certain conditions relating to the dividend recipient and dividend payer are satisfied. These conditions
are described in Dividends in Section B. Dividends paid by Romanian legal entities to pension funds resident in an EU member state, as defined
by the law of such state, are exempt from withholding tax in Romania.
(d) This withholding tax applies only if the income is not attributable to a permanent establishment in Romania.
(e) The following types of interest derived by nonresidents are not subject to withholding tax:
• Interest from public debt instruments in national and foreign currency
• Interest related to instruments issued by the National Bank of Romania to carry out monetary policy
• Interest paid by Romanian legal entities to pension funds resident in an EU member state, as defined by the law of such state
(f) The withholding tax rate is 0% for interest and royalties if certain conditions are satisfied, including the following principal conditions:
• The beneficial owner of the interest or royalties is a legal person resident in an EU member state or a permanent establishment of an entity
resident in such a state.
• The beneficial owner of the interest or royalties holds at least 25% of the value or number of participation titles in the Romanian entity for an
uninterrupted period of at least two years that ends on the date of payment of the interest or royalties.
(g) Annual tax losses incurred in 2009 and subsequent years may be carried forward for seven years (five years for losses incurred before 2009) and
are not adjusted for inflation.

(h) Withholding tax applies for the following types of services rendered abroad: management, consultancy, marketing, technical assistance,
research and design, advertising and publicity expenses, without taking into account how these services are rendered, as well as for the services
provided by lawyers, engineers, architects, public notaries, auditors and accountants provided that the income is not attributable to a
permanent establishment in Romania. International transport and supplies of services ancillary to such transport are not subject to withholding
tax.

B. Taxes on corporate income and gains

Micro-enterprises. Starting with February 2013, Romanian legal persons fulfilling certain
conditions have the obligation to pay micro-enterprise tax computed as 3% of the taxable
revenues with exemptions of certain revenues.
This regime applies to companies that have obtained income of less than EUR 65,000 in the
previous year and obtain income from activities other than banking, insurance and
reinsurance, capital market (except for intermediaries) and gambling. It also applies if the
revenues from consultancy and management are less than 20% of the total revenues.
If during a fiscal year, the taxpayer assessed as micro-enterprise obtains for example income
exceeding EUR 65,000 it will pay corporate income tax considering revenues and expenses
recorded from the beginning of the fiscal year.
298 Section V. Requirements of the Information System

Please note that the fiscal loss incurred by the taxpayer in the period when the micro-
enterprise income tax is applied is not taken into account (there is no computation of the
taxpayer's fiscal result).
The fiscal losses incurred by legal persons before applying the micro-enterprise taxation
regime can be carried forward until the legal entity fulfills the conditions to become again a
corporate income tax payer, but only within the seven years (five years for losses incurred
before 2009) period stated by the law.
Corporate income tax. Resident entities are subject to tax on their worldwide income. An entity
is resident in Romania if it satisfies any of the following conditions:
• It is incorporated in Romania.
• Its place of effective management and control is located in Romania.
• It is a legal entity that has its headquarters in Romania and that is incorporated in
accordance with the European legislation.
Associations or consortia, which are not considered separate legal persons in Romania, are
tax transparent. For such associations between Romanian legal entities and individuals or
foreign entities, the tax is calculated and paid by the Romanian legal entities on behalf of the
partners.
Nonresident companies that do not have an effective place of management in Romania are
subject to tax on their Romanian-source income only, including capital gains derived from
specified transactions (see Capital gains).
Rates of corporate income tax. The standard rate of income tax for Romanian companies is 16%,
regardless of whether the companies have foreign participation. Income derived by
companies from night bars, nightclubs, discos and casinos directly or in association is also
normally taxable at a rate of 16%, but the amount of the tax payable may not be less than 5%
of the gross income derived from such activities.
Nonresident companies that do not have their place of effective management in Romania are
taxed in Romania at the standard rate of 16% on earnings derived from their operations in
Romania through branches, permanent establishments or certain consortia. A permanent
establishment of a foreign company in Romania may be constituted in certain forms,
including the following:
• An office
• A branch
• An agency
• A factory
• A mine
• A place of extraction for gas or oil
• A building site that exists for a period exceeding six months
• The place in which an activity continues to be carried out with the assets and
liabilities of a Romanian legal person subject to a cross-border reorganization
Section V. Requirements of the Information System 299

Foreign companies are also normally taxable in Romania at the standard corporate income
tax rate on profits derived in Romania from real estate located in Romania and the
exploitation of natural resources, as well as on certain capital gains (see Capital gains).
Representative offices are subject to an annual tax equal to the equivalent in Romanian lei of
€4,000, payable in two installments.
Tax incentives. Romania offers certain tax incentives, which are summarized below.
Corporate income tax. The Fiscal Code contains measures allowing companies to claim
accelerated depreciation in certain circumstances.
The Fiscal Code allows “sponsorship” expenses to be claimed as a credit against corporate
income tax due, subject to certain limitations. Under the Sponsorship Law, “sponsorship” is
defined as “the juridical deed by which two persons agree upon the transfer of the
ownership right upon certain material goods or financial means, in order to support the
activity without lucrative scope, carried out by one of them.” The tax credit for sponsorship
expenses is limited to the lower of the following:
• 0.3% of the company’s turnover
• 20% of the corporate income tax due
Starting with 1 January 2014, the sponsorship expenses which were not used for obtaining a
fiscal credit, can be carried forward for 7 consecutive years.
Beginning in 2009, dividends reinvested for the purpose of securing and creating new jobs for
the business development of Romanian legal entities distributing the dividends are exempt
from dividend tax. Dividends invested in the share capital of another Romanian legal entity to
create new jobs or to develop its activities are exempt from dividend tax.
Research and development costs. Starting with February 2013, the additional allowance
taxpayers can benefit from for research and development activities has increased to 50% of
eligible costs.
Industrial parks. Companies administering industrial parks (administrator companies) may
benefit from the following incentives:
• Exemption from taxes due on conversion of agricultural land to be used for
industrial parks
• Buildings, constructions and land located inside industrial parks are exempt from
building tax and land tax
• Other incentives, which may be granted by the local authorities
Petroleum companies. Incentives are available to titleholders of oil and gas concessions.
Titleholders are granted the concessions by the government in exchange for the payment of
a royalty. The following are the incentives:
• For rehabilitation projects, a deductible provision equal to 10% of the annual
exploitation profits derived by titleholders of oil and gas licenses that relate to
offshore areas with water deeper than 100 meters (328 feet)
300 Section V. Requirements of the Information System

• Exemption from payment of tax on oil and natural gas (consumption tax imposed
on the value of oil and gas delivered) for the production extracted and directly
exported by producers
Free-trade zones. The following tax benefits are available to companies performing activities
in free-trade zones:
• Value-added tax (VAT) exemption applies to supplies of non-Community goods to
be placed in a free-trade zone and to supplies of the respective goods performed
in a free-trade zone
• Non-Community goods introduced into free-trade zones for storage purposes are
not subject to customs duties
• State aid is available for investments performed in free-trade zones
Property taxes. Local councils may grant building and land tax exemptions to legal entities,
subject to the state-aid regulations.
Capital gains. Capital gains are included in taxable income and taxed at the normal corporate
income tax rate. Capital gains derived by nonresident companies are also subject to the
standard 16% tax rate if they are derived from the disposal of the following:
• Real Estate property located in Romania
• Participation titles (shares) in a Romanian company, or a company with fixed
assets that primarily consist of, directly or indirectly, immovable property located
in Romania
Certain exemptions apply to income derived by nonresident collective placement bodies
without corporate status (for example, Romanian entities that attract financial resources for
investment, according to specific legislation) from the transfer of value titles (securities
participation titles in open funds, and other financial instruments, such as derivatives) and
participation titles held directly or indirectly in Romanian companies, as well as to income
derived by nonresidents from the transfer on a foreign capital market of participation titles
held in a Romanian company and of value titles.
Starting with 1 January 2014, the income derived from the sale/assignment of shares
held in Romanian legal entities or in legal entities from countries with which Romania
has concluded a double tax treaty is not included in taxable income if the taxpayer
holds for an uninterrupted period of 1 year, at least 10% of the share capital of the
legal entity in which the shares sold/assigned were held.
Administration. In general, the tax year is the calendar year. However, starting with 1 January
2014, certain companies may opt for a fiscal year different from the calendar year.
Under the corporate income tax law, payers of corporate income tax (for example,
companies, branches and permanent establishments) must file tax returns and pay corporate
income tax quarterly (computed based on actual numbers) by the 25th day of the first month
following the first, second and third quarters.
As an exception to the general rule, the payments made by banks are advance payments
based on the corporate income tax for the preceding year, adjusted by the inflation rate. This
rule does not apply to newly established banks and banks that recorded a tax loss in the
preceding year. These banks apply the 16% rate to the accounting profit of the current
Section V. Requirements of the Information System 301

quarter. ,All other companies may opt for reporting and paying the annual corporate income
tax through advance payments made on a quarterly basis. The annual corporate income tax
return must be filed and any balance of annual corporate income tax must be paid by 25
March of the following year. For the taxpayers applying a different non-calendar fiscal year,
the annual corporate income tax return must be filed and any balance of annual corporate
income tax must be paid by the 25 th of the third month following the fiscal year end.
However, certain taxpayers must submit the annual corporate income tax return and pay the
related tax by 25 February of the following year, such as nonprofit organizations or taxpayers
deriving most of their revenues from cereals and technical plants.
Companies ceasing to exist must submit a final tax return and pay the corporate income tax
based on special rules.
The annual financial statements must be submitted within specified time periods after the
year-end. The following are the time periods:
• Companies (in general), national companies and research and development
institutes: 150 days
• Certain specified legal persons, individuals and bodies: 120 days
• Companies not performing any activities after their formation: 60 days
The failure of a company to file tax returns by the deadline may result in a fine ranging
usually from RON 1,000 to RON 5,000. Companies are liable for the payment of the fines for
late filing of returns even if they pay the tax due. For the late payment of tax liabilities, the
following late payment interest and late payment penalties are due (except where otherwise
provided):
• Late payment interest, computed at 0.04% per day of delay
• Late payment penalties, computed at 0.02% per day of delay.
Dividends. Dividends paid by Romanian companies to resident companies are subject to a 16%
withholding tax. The 16% tax is considered a final tax and, accordingly, the dividends are not
included in the taxable income of the recipient. However, as a result of Romania’s accession
to the EU, no tax is imposed on dividends paid by a Romanian resident company to resident
companies that held at least 10% of the shares of the payer for an uninterrupted period of at
least one year that ended on the date of payment of the dividend.
Dividends paid by Romanian companies and legal entities having their social headquarters in
Romania (that is, societas europea registered with the Romanian Trade Registry and set up
according to European law) to resident individuals and nonresident companies and
individuals are generally subject to a 16% withholding tax. However, dividends paid by a
Romanian legal entity to a legal entity resident in another EU member state (see footnote [c]
in Section A) or to a permanent establishment of an entity residing in an EU member state
are not subject to withholding tax if certain conditions relating to the legal entity receiving
the dividends and to the Romanian income payer are satisfied. These conditions are
described below.
The following conditions must be satisfied with respect to the legal entity receiving the
dividends:
302 Section V. Requirements of the Information System

• The legal entity receiving the dividends must be established in one of the legal
forms provided by the law and must be resident in the respective EU member
state and, according to the double tax treaties entered into with third countries,
may not be resident outside the EU from a tax perspective.
• The legal entity receiving the dividends must be liable to pay corporate income
tax or other similar tax under the tax law in its state of residence without the
possibility of exemption or choice of the fiscal treatment.
• The beneficiary of the dividends must own at least 10% of the participation titles
in the Romanian legal entity for an uninterrupted period of at least one year
ending on the date of the payment of the dividends.
The Romanian entity paying the dividends must satisfy the following conditions:
• It must be a joint stock company, limited partnership or limited liability company.
• It must be liable to pay corporate income tax without the possibility of
exemption or choice of the fiscal treatment
Dividends paid by Romanian legal entities to pension funds, as defined by the law of the
respective EU member state, are exempt from withholding tax in Romania.
The deadline for payment of dividend withholding tax is the 25th day of the month following
the month in which the dividends are paid. However, if the dividends are distributed but not
paid to shareholders by the end of the year in which the annual financial statements are
approved, the tax is due on 25 January of the following year.
Foreign tax relief. Foreign taxes may be credited against Romanian taxes based on the
provisions of a double tax treaty between Romania and the foreign state.
Income of permanent establishments. Romanian permanent establishments of foreign legal
entities resident in an European Union Member State or a state of the European Economic
Area, which derive income from another European Union Member State or from a state of
the European Economic Area, benefit under certain conditions of a fiscal credit for the tax
paid in the state from where the income included in the taxable income of the permanent
establishment from Romania was derived.

C. Determination of trading income

General. In general, all income that is booked as revenue is included in taxable income.
However, the following items, among others, are not included in taxable income:
1. Dividends received by a Romanian company from another Romanian company
or from a foreign legal entity subject to corporate income tax or a similar tax
located in a state with which Romania concluded a double tax treaty Dividends
received by a Romanian company from an EU resident subsidiary and dividends
received by Romanian permanent establishments of EU companies are also not
taxable if certain conditions are satisfied.
2. Increases in the value of shares held in other companies, resulting from the
incorporation of reserves, premiums, profits and similar items.
Section V. Requirements of the Information System 303

3. Revenues from the reversal of expenses and provisions that were previously
considered to be nondeductible.
4. Income derived from the liquidation of other Romanian legal entities or of foreign
legal entities located in countries with which Romania has concluded a double tax
treaty.
The provisions no.1 and 4 apply if the taxpayer holds for an uninterrupted period of 1
year at least 10% of the share capital of the legal entity distributing the dividends or of
the legal entity which is subject to liquidation.

In general, only expenses related to the earning of taxable income are deductible for tax
purposes. However, the following items are deductible within specified limits:
• Protocol and entertainment expenses (for example, gifts to clients and business
lunches), up to 2% of the adjusted accounting profit before tax
• Employee-related expenses (social expenses), up to 2% of the total salary cost
• Contributions to the legal reserve fund, generally up to 5% of the accounting
profit before tax, until the reserve fund reaches 20% of share capital
• Expenses with respect to perishable goods (goods on which a company might
incur losses for various reasons, such as from damage suffered during the
transport of the goods), which are deductible within the limits set by a
government decision
• Provisions (see Provisions)
• Interest expenses and foreign-exchange losses related to loans subject to the
debt-to-equity limitation, if the debt-to-equity ratio is not exceeded (see Section
E)
• Depreciation expenses (see Tax depreciation)
• Expenses incurred on behalf of an employee with respect to optional
occupational pension and private health insurance schemes, within certain
thresholds
The following expenses are not deductible for tax purposes:
• Service expenses, including management, assistance and consultancy expenses,
if the taxpayer cannot justify their necessity and no contracts and other
documents justifying the expenses are available.
• Expenses relating to insurance, other than insurance relating to risks of work-
related accidents and insurance relating to assets owned by the company.
• Interest on loans that are not from financial institutions, to the extent that the
interest exceeds the following limits:
— For loans denominated in lei (RON), the level of the reference interest rate
published by the National Bank of Romania (NBR) for the last month of the
quarter.
304 Section V. Requirements of the Information System

— For loans denominated in foreign currencies, an annual interest rate of 6%

(beginning in 2010).
• Penalties and fines paid to Romanian or foreign authorities.
• Losses from the reduction in the value of inventory and uninsured assets, as well
as the related VAT.
• VAT related to certain nondeductible expenses.
• Romanian and foreign corporate income tax (however, a tax credit is allowed for
taxes paid in other countries based on the provisions of a double tax treaty
between Romania and the foreign state).
• Expenses incurred for the benefit of shareholders or associates, other than
payments for goods and services at market value.
• Salary expenses that are not taxed at the level of the individual, unless the law
provides otherwise.
• Expenses related to nontaxable income.
Effective from 1 July 2012, the deductibility of car expenses not falling under the full
deductibility criteria provided under the Romanian tax law is limited to 50% for certain cars
not exclusively used for business purposes.
Sponsorship expenses are also nondeductible, but they may be claimed as a credit against
corporate income tax due, subject to certain limitations (see Section B).
Taxpayers applying the international financial reporting standards. Taxpayers applying international
financial reporting standards (IFRS), such as banks and listed companies, must take specific
tax rules into consideration in determining the corporate income tax.
Inventories. Under Romanian law, inventories of raw materials and merchandise are valued at
purchase cost, while inventories of finished goods and work-in-progress are valued at
production cost. On the write-off of the inventories, the valuation is calculated using the first-
in, first-out (FIFO), weighted-average or last-in, first-out (LIFO) methods.
Provisions. Under Romanian law, the following provisions are deductible for corporate income
tax purposes:
• Bad debt provisions under specified conditions
• Provisions for performance guarantees granted to clients
• Mandatory credit risk provisions, if established by banks, credit institutions or
nonbanking financial institutions (leasing companies)
• Special provisions for titleholders of oil and gas concessions
Tax depreciation. The following are the permissible depreciation methods:
• Buildings: straight-line depreciation
• Equipment: straight-line, reduced-balance or accelerated depreciation
• Other depreciable assets: straight-line or reduced-balance depreciation
The depreciation method must be applied consistently. Land may not be depreciated.
Section V. Requirements of the Information System 305

Under the accelerated depreciation method, the assets are depreciated at a maximum rate
of 50% in the year of purchase, and the balance of the value is deducted using the straight-
line method during the remaining useful life of the asset.
Patents, licenses, know-how, manufacturers’ brands, trademarks and service marks, as well
as other similar industrial and commercial property rights, are depreciated during the
contract period or during the period in which the purchaser intends to use the rights.
Expenses for the production or purchase of software programs are deductible on a straight-
line basis over three years. The reduced-balance and accelerated depreciation methods may
be used for patents.
Goodwill, , as well as intangibles with an undetermined operational life classified as such
under accounting regulations cannot be depreciated for tax purposes.
Starting with 1 February 2013, the deductibility of the fiscal depreciation of certain
vehicles is limited to RON 1,500 /month/ per vehicle.

For tax depreciation purposes, useful lives are prescribed by law. The following are the useful
lives that are generally applicable to major categories of assets.
Asset Years
Buildings and constructions (for example,
roads and fences) 8 to 60
Machinery and equipment 2 to 24
Furniture and fittings 2 to 15
Motor vehicles 3 to 9
Revaluations of the book value of land and fixed assets carried out before 31 December 2003
are taken into account for tax purposes. Revaluations carried out after 1 January 2007, as
well as the part remaining undepreciated as of 31 December 2006 with respect to
revaluations carried out between 1 January 2004 and 31 December 2006, are also taken into
consideration for tax purposes.
Reserves from the revaluation of fixed assets, carried out after 1 January 2004, which are
deducted as tax depreciation or expenses when assets are sold or written off are taxed
simultaneously with the deduction of the tax depreciation or expenses (that is, when the
assets are sold or written off).
Relief for losses. Annual tax losses incurred in 2009 and subsequent years may be carried
forward for seven years (five years for losses incurred before 2009) and are not adjusted for
inflation. Losses of entities ceasing to exist as a result of a spin-off or merger are recovered
by the taxpayers taking over the patrimony of the absorbed or spun-off company,
proportionally to the value of the assets and liabilities transferred to the beneficial legal
entity.
Losses recorded by taxpayers that do not cease to exist as a result of an operation consisting
of the spin-off of a part of their patrimony transferred as a whole are recovered by such
taxpayers and by the taxpayers taking over the patrimony of the transferring company,
proportionally to the assets and liabilities transferred to the beneficial legal persons,
according to the spin-off project, respectively with those maintained by the transferring legal
entity.
306 Section V. Requirements of the Information System

Losses may not be carried back.

Groups of companies. Although the Romanian law provides financial accounting rules for the
consolidation of companies, the tax law treats each group company individually for tax
purposes. Under certain circumstances, a group of taxable persons established in Romania
may be treated as a single taxable person for VAT reporting purposes.
Tax consolidation. Starting with 1 July 2013, tax consolidation was introduced for foreign
legal entities which had several permanent establishments in Romania (i.e. offset the
taxable profits of a permanent establishment against the tax losses of another
permanent establishment).

D. Other significant taxes

The following table summarizes other significant taxes.
Nature of tax Rate (%)
Value-added tax; certain enterprises, products
and services are exempt, including banks,
financial intermediaries and insurance companies
Standard rate 24
Special rates for certain goods and services 5/9
Special consumption (excise) taxes; imposed,
for example, on energy products, beverages,
cigarettes and coffee; taxes are imposed at
specified amounts per unit on certain products
(for example, coffee and alcohol) and at
percentage rates for other products Various
Social security contributions; paid by employers
on the total gross realized salaries
Social Insurance Fund; rate varies according
to work conditions 20.8 to 30.8
Health Fund 5.2
Unemployment Fund 0.5
National Insurance Fund for Labor Accidents
and Professional Diseases 0.15 to 0.85
Fund for Guarantee of Salary
Payment Liabilities; this fund finances the
payment of salary debts resulting from labor
agreements entered into between employees
and employers against which an insolvency
procedure has begun 0.25
Medical leaves 0.85
Local taxes on land, buildings, cars, certain
authorizations and other items Various

E. Miscellaneous matters
Foreign-exchange controls. The Romanian currency is the leu (RON). Regulation 4/2005, as
amended, governs the foreign-exchange regime in Romania.
In Romania, transactions between resident companies or between resident companies and
resident individuals must be made in local currency, with certain exceptions. Transactions
between residents and nonresidents can be made in domestic as well as in foreign currency.
Section V. Requirements of the Information System 307

In the free-trade zones (see Section B), transactions between residents can also be
performed in foreign currency.
Residents and nonresidents may open foreign-currency accounts in Romanian banks or
foreign banks authorized to operate in Romania. Residents are allowed to open accounts in
banks located abroad. Romanian legal entities may hold and use hard currency deposited
with authorized banks.
Romanian legal entities may make payments in foreign currency to nonresidents without
prior approval. Current-account transactions include, among others, imports of goods and
services, payments of dividends and repatriation of profits.
Romanian and foreign entities may freely buy and sell hard currency on the interbank
foreign-exchange market, but specified documentation is usually required.
Transfer pricing. Under the provisions of the Romanian Fiscal Code, for transactions between
related parties, the tax authorities may adjust the amount of income or expenses of either
party to reflect the market value of the goods or services provided in the transaction. Such
reassessment affects only the tax position of the Romanian entity. It does not affect the
entity’s financial statements.
The law indicates that in applying the domestic transfer-pricing measures, the Romanian tax
authorities must also take into account the Organization for Economic Cooperation and
Development (OECD) Transfer-Pricing Guidelines.
On request, Romanian entities performing transactions with nonresident related parties must
make available to the tax authorities a file containing specified transfer-pricing
documentation.
Debt-to-equity rules. Interest expenses are fully deductible if the debt-to-equity ratio is positive
and does not exceed 3:1. Only loans granted for a period of greater than one year are
included in the debt-to-equity computation. If the 3:1 threshold is exceeded, interest
expenses on such loans and net losses from foreign-exchange differences related to such
loans are not deductible, but they may be carried forward to the following tax years until
they are fully deducted.
The carried forward deductibles for interest and net foreign exchange losses are taken over
by the taxpayers that take over assets and liabilities following a reorganization (e.g. merger,
spin-off) proportionally to the value of the assets and liabilities transferred to the beneficiary
legal entity.
Interest expenses and net foreign-exchange losses are not subject to the debt-to-equity rules
if the loans satisfy any of the following conditions:
• They are granted by international development banks or similar organizations,
Romanian or foreign credit institutions, nonbanking financial institutions or legal
persons granting credits according to the law.
• They relate to bonds traded on a regulated market.
• They are guaranteed by the state.

F. Treaty withholding tax rates

308 Section V. Requirements of the Information System

The following table shows the applicable withholding rates under Romania’s bilateral tax
treaties.
Dividends (gg) Interest (hh) Royalties (hh)
% % %
Albania 10/15 (a) 10 15
Algeria 15 15 15
Armenia 5/10 (a) 10 10
Australia 5/15 (b) 10 10
Austria 0/5 (a) 0/3 (n) 3
Azerbaijan 5/10 (a) 8 10
Bangladesh 10/15 (b) 10 10
Belarus 10 10 15
Belgium 5/15 (a) 10 5
Bulgaria 10/15 (a) 15 15
Canada 5/15 (b) 10 5/10 (r)
China 10 10 7
Costa Rica (dd) 5/15 (a) 10 10
Croatia 5 10 10
Cyprus 10 10 0/5 (e)
Czech Republic 10 7 10
Denmark 10/15 (a) 10 10
Ecuador 15 10 10
Egypt 10 15 15
Estonia 10 0/10 10
Ethiopia 10 15 15
Finland 5 0/5 2.5/5 (f)
France 10 10 10
Georgia 8 10 5
Germany 5/15 (b) 0/3 (g) 3
Greece 25/45 (h) 10 5/7 (i)
Hungary 5/15 (j) 15 10
Iceland 5/10 (a) 3 5
India 15/20 (a) 0/15 22.5
Indonesia 12.5/15 (a) 12.5 12.5/15 (k)
Iran 10 8 10
Ireland 3 0/3 (l) 0/3 (i)
Israel 15 0/5/10 (m) 10
Italy 10 10 10
Japan 10 10 10/15 (i)
Jordan 15 12.5 15
Kazakhstan 10 10 10
Korea (North) 10 10 10
Korea (South) 7/10 (a) 0/10 (x) 7/10 (k)
Kuwait 0/1 (ii) 1 20
Latvia 10 10 10
Lebanon 5 5 5
Lithuania 10 10 10
Luxembourg 5/15 (a) 0/10 (c) 10
Macedonia 5 10 10
Malaysia 0/10 (o) 0/15 (p) 0/12 (q)
Malta 5/30 (h) 5 5
Mexico 10 15 15
Moldova 10 10 10/15 (k)
Morocco 10 10 10
Namibia 15 15 15
Netherlands 0/5/15 (s) 0/3 (t) 0/3 (t)
Nigeria 12.5 12.5 12.5
Norway 10 10 10
Section V. Requirements of the Information System 309

Pakistan 10 10 12.5
Philippines 10/15 (a) 10/15 (u) 10/15/25 (v)
Poland 5/15 (a) 10 10
Portugal 10/15 (w) 10 10
Qatar 3 3 5
Russian
Federation 15 15 10
San Marino 0/5/10 (ee) 3 3
Saudi Arabia 0/5 (jj) 0/5 (kk) 10
Singapore 0/5 (ff) 5 5
Slovak Republic 10 10 10/15 (k)
Slovenia 5 5 5
South Africa 15 15 15
Spain 10/15 (a) 10 10
Sri Lanka 12.5 10 10
Sudan 5/10 (a) 0/5 5
Sweden 10 10 10
Switzerland 0/15 (ll) 0/5 (mm) 0/10 (y)
Syria 5/15 (a) 10 12
Tajikistan 5/10 (a) 10 10
Thailand 15/20 (a) 10/20/25 (z) 15
Tunisia 12 10 12
Turkey 15 10 10
Turkmenistan 10 10 15
Ukraine 10/15 (a) 10 10/15 (k)
United Arab
Emirates 0/3 (d) 3 0/3 (aa)
United Kingdom 10/15 (a) 10 10/15 (i)
United States 10 10 10/15 (i)
Uruguay (dd) 5(a)/10 0/10 (nn) 10
Uzbekistan 10 10 10
Vietnam 15 10 15
Yugoslavia (Federal
Republic of) 10 10 10
Yugoslavia
(former) (bb) 5 7.5 10
Zambia 10 10 15
Nontreaty countries 16 0/16 (cc) 16

(a) The lower rate applies if the beneficiary of dividends is a company owning at least 25% of the
capital of the payer.
(b) The lower rate applies if the beneficiary of dividends is a company owning at least 10% of the
capital of the payer.
(c) The rate is 0% if the indebtedness on which the interest is paid is guaranteed, insured, or financed
by the other state or by a financial institution that is a resident of the other state.
(d) The 0% rate applies if the beneficial owner of the dividends is one of the following:
•The government of a contracting state
•The governmental institution or entity of a contracting state
•A company that is resident in a contracting state and that has at least 25% of its capital owned
directly or indirectly by the government or governmental institutions of either contracting state
(e) The 5% rate applies to royalties paid for patents, brands, designs and models and know-how.
(f) The 2.5% rate applies to royalties relating to computer software or industrial equipment.
(g) The 0% applies to interest paid to the German government, Deutsche Bundesbank Kreditanstalt
fur Wiederaufbau or Deutsche Investitions und Entwicklungsgesellschaft (DEG) and to interest
paid on a loan guaranteed by Hermes-Deckung. The 0% rate also applies to interest paid to the
Romanian government if it is derived and beneficially owned by certain types of institutions (for
example, the Romanian government, an administrative-territorial unit, a local authority, or an
310 Section V. Requirements of the Information System

agency, bank unit or institution of the Romanian government) or if the debt claims of Romanian
residents are warranted, insured or financed by a financial institution wholly owned by the
Romanian government. In addition, as long as Germany does not impose taxes on interest,
Romania may not tax interest. The protocol to the treaty provides that the following types of
interest are taxed only in the state where the interest arises and according to the law of that
state, provided that they are deductible in the determination of profits of the interest payer:
•Interest derived from rights or debt claims carrying a right to participate in profits
•Interest linked to the borrower’s profits
•Interest derived from profit-sharing bonds
(h) The lower rate applies to dividends paid by companies resident in Romania.
(i) The lower rate applies to cultural royalties.
(j) The lower rate applies if the beneficiary of dividends is a company owning at least 40% of the
capital of the payer.
(k) The lower rate applies to payments received for the use of, or the right to use, patents,
trademarks, designs or models, plans, secret formulas and processes, or industrial, commercial or
scientific equipment, and for information concerning industrial, commercial or scientific
experience.
(l) The 0% rate applies to the following types of interest:
•Interest paid in connection with sales on credit of industrial, commercial or scientific equipment
•Interest on loans granted by banks or other financial institutions (including insurance companies)
•Interest on loans with a term greater than two years
•Interest on debt-claims guaranteed, insured or directly or indirectly financed by or on behalf of
the government of either contracting state
(m)The 0% rate applies to interest arising in one contracting state with respect to debentures, public
funds or similar instruments of the government that is paid to residents of the other contracting
state and to interest on loans granted or guaranteed by the National Bank of Romania or by the
Bank of Israel. The 5% rate applies to interest paid with respect to sales on credit of merchandise
or industrial, commercial or scientific equipment and to interest on loans granted by banks. The
10% rate applies to other interest.
(n) As long as Austria, under its national law, does not levy withholding tax on interest paid to
Romanian residents, the withholding tax rate is 0%.
(o) The 0% rate applies to dividends paid by a company resident in Malaysia to a Romanian resident;
the 10% rate applies to dividends paid by a company resident in Romania to a Malaysian resident.
(p) The 0% rate applies to interest paid to Romanian residents on long-term loans.
(q) The 0% rate applies to industrial royalties received from Malaysia by Romanian residents.
(r) The 5% rate applies to the following:
•Copyright royalties and similar payments with respect to the production or reproduction of
literary, dramatic, musical or other artistic works (but not including royalties with respect to
motion picture films or works on film or videotape or other means of reproduction for use in
connection with television broadcasting)
•Royalties for the use of, or the right to use, computer software, patents or information
concerning industrial, commercial or scientific experience (but not including royalties paid with
respect to a rental or franchise agreement)
(s) The 0% rate applies if the beneficiary of the dividends is a company owning at least 25% of the
capital of the payer. The 5% rate applies if the beneficiary of the dividends is a company owning at
least 10% of the capital of the payer. The 15% rate applies to other dividends.
(t) Romania will not impose withholding tax on interest and royalties paid to Dutch residents as long
as Dutch domestic law does not impose withholding tax on these types of payments.
(u) The lower rate applies to interest related to sales on credit of equipment, loans granted by a bank
or to public issues of bonds and debentures.
Section V. Requirements of the Information System 311

(v) The 10% rate applies to royalties paid by a company that is registered as a foreign investor and is
engaged in an activity in a priority economic field. The 15% rate applies to royalties related to film
or television production. The 25% rate applies to other royalties.
(w) The 10% rate applies if the beneficiary of dividends is a company owning at least 25% of the
capital of the payer for an uninterrupted period of two years.
(x) The 0% rate applies to interest related to sales on credit of industrial and scientific equipment.
(y) Romania will not impose withholding tax on royalties paid to Swiss residents as long as Swiss
domestic law does not impose withholding tax on royalties.
(z) The 10% rate applies if the beneficiary of the interest is a financial company, including an
insurance company. The 20% rate applies to interest with respect to sales on credit. The 25%
rate applies to other interest payments.
(aa) The 0% rate applies to industrial royalties.
(bb) This treaty is currently applied only to Bosnia-Herzegovina.
(cc) The 0% rate applies to the following types of interest:
•Interest related to public debt instruments or to instruments issued by the National Bank of
Romania with the purposes of reaching monetary policy objectives
•Interest paid to EU pension funds
The 16% rate applies to other interest payments.
(dd) The treaty is not yet effective.
(ee) The 0% rate applies if the beneficiary of the dividends is a company owning at least 50% of the
capital of the payer. The 5% rate applies if the beneficiary of the dividends is a company owning
at least 10% of the capital of the payer. The 10% rate applies to all other dividends.
(ff) The 0% rate applies to dividends paid to the government of the other contracting state.
(gg) In accordance with an EU directive, the following rules apply to dividends paid to companies
residing in the EU:
•The withholding tax rate in Romania is 0% if certain conditions are met, such as the beneficiary
of the dividends owns at least 10% of the capital of the payer for an uninterrupted period of
one year before the payment of the dividends.
•The withholding tax rate in Romania is 16% if the conditions mentioned in the preceding bullet
are not satisfied.
(hh) The withholding tax rate is 0% for interest and royalties if both of the following conditions are
satisfied:
•The beneficial owner of the interest or royalties is a legal person resident in an EU member
state or a permanent establishment of an entity resident in such a state.
•The beneficial owner of the interest or royalties holds at least 25% of the value or number of
participation titles in the Romanian entity for an uninterrupted period of at least two years that
ends on the date of payment of the interest or royalties.
(ii) The 0% rate applies to dividends paid to the government or political subdivisions, local
authorities or administrative territorial units. The 0% rate also applies to majority state-owned
companies (at least 51%) if the minority shareholders are residents of that state.
(jj) The 0% rate applies if the beneficial owner of the dividends is one of the following:
•The government of a contracting state
•A governmental institution or entity of a contracting state
(kk) The 0% rate applies if any of the following circumstances exists:
•The payer of the income from debt-claims is the government of a contracting state or an
administrative-territorial unit or an administrative subdivision or a local authority thereof.
•The income from debt-claims is paid to the government of the other contracting state or
administrative-territorial unit, or an administrative subdivision or local authority thereof, or an
agency or instrumentality (including a financial institution) wholly owned by the other
contracting state or administrative-territorial unit, or an administrative subdivision or local
authority thereof.
312 Section V. Requirements of the Information System

•The income from debt-claims is paid to any other agency or instrumentality (including a
financial institution) with respect to loans made in application of an agreement between the
governments of the contracting states.
•The income from debt-claims is paid on loans granted, insured or guaranteed by a public
institution for purposes of promoting exports.
(ll) A withholding tax exemption for dividends applies if either of the following circumstances exists:
•The dividends are paid to a company (other than a partnership) that holds directly at least 25%
of the capital of the company paying the dividends.
•The beneficial owner of the dividends is the government of the contracting state or a
governmental institution or entity of a contracting state.
(mm) The withholding tax exemption for interest applies if either of the
following circumstances exists:
•The interest is paid to related parties (that is, direct parent or sister companies) that have a
shareholding of 25% or more.
•The loan is secured by a governmental institution.
(nn) The 0% rate applies if the beneficial owner is the Government, an administrative subdivision,
a local authority or an administrative-territorial unit or a Bank owned by the Government, an
administrative subdivision, a local authority or an administrative-territorial unit or if the loan is
guaranteed, assured or financed by a Bank entirely owned by the Government.

A. Income tax – in Romania – at a glance

Who is liable.Individuals domiciled in Romania are considered to be tax residents and are
taxed on their worldwide income (with certain exceptions). During the first year of
meeting certain residency criteria, individuals who are not domiciled in Romania are
subject to tax on their Romanian-source income, regardless of where the income is
received. In the absence of a tax residency certificate issued by another state based on a
double tax treaty, a foreign individual or one who carries out independent activities
through a permanent establishment in Romania becomes subject to tax on worldwide
income starting with 1 January of the year following the year in which the tax-residency
criteria are met.
Individuals in Romania who are also residents in a country that has entered into a
double tax treaty with Romania may benefit from a reduced tax rate or a tax exemption
under the terms of the relevant treaty. If a foreign individual spends less than 183 days
in Romania and if the salary costs for the individual are not recharged to Romania, he or
she may be exempt from Romanian salary tax liabilities, provided that a tax residency
certificate is available and the tax exemption procedure is completed within 15 days of
the beginning of activities. Individuals in Romania who are tax residents in countries that
have not entered into a double tax treaty with Romania are subject to tax in Romania
from their first day of presence in the country.
A Romanian tax resident who is domiciled in Romania and who demonstrates a change
of residency to a country that does not have a double tax treaty with Romania continues
to be subject to tax on worldwide income for the calendar year in which the change of
residency occurs and for the next three calendar years.
Section V. Requirements of the Information System 313

Income subject to tax. A flat tax rate of 16% applies to salary income, income from
freelance activities, rental income, pension income, investments, prizes, investment
income, agricultural, forestry and fisheries income, and other types of income. Special
tax rates apply to income from gambling and transfer of property ownership. The
taxation of various types of income is summarized below.
Employment income. Taxable compensation includes the following:
 Salaries
 Benefits in cash or kind (for example, allowances and perquisites)
 Wage premiums
 Rewards
 Temporary disability payments
 Paid holidays
 Other income received by an individual based on an employment agreement
 Fees and compensation paid to directors and managers of private enterprises and to
members of the board of directors, general shareholders meeting, administration
council and audit committee
The monthly tax on employment income is determined by deducting mandatory social
security charges, personal deductions, trade union contributions and contributions to
the voluntary occupational pension scheme (up to the equivalent in Romanian currency
of €400 per year per participant) from gross income.
Income from independent activities. Income from independent activities includes income
from commercial activities, income from freelance activities and income from
intellectual property rights. The net taxable income from freelance activities is
computed as gross income less specified deductible expenses. Individuals engaged in
freelance activities must make advance tax payments on a quarterly basis by the 25th
day of the last month of each quarter. A 10% advance income tax, which is withheld at
source, applies to the following types of income:
 Income from intellectual property rights
 Income from services contracts entered into based on the Civil Code and income
from agent agreements, with some exceptions
 Income from accounting, technical, judicial and extrajudicial expertise
Income derived by individuals from rental for tourism purposes of rooms located in their
own homes, with a capacity for accommodation of more than five rooms is assessed as
income from independent activities and is subject to tax based on income quotas (fixed
amounts set by the government) or real system (actual income recorded based on the
single-entry system).
Taxable income from intellectual property rights is computed by deducting from gross
income expenses representing 20% of gross income and compulsory social security
charges. A 10% advance income tax must be withheld at source by payers of income
from intellectual property rights by the 25th day of the following month. Taxpayers who
earn income from intellectual property rights can opt for a final withholding tax at a rate
of 16%.
314 Section V. Requirements of the Information System

Rental income. Gross rental income consists of amounts in cash or kind that are
stipulated in rental agreements, as well as certain expenses borne by the tenant that are
the landlord’s liability according to the law. The rental income is taxable in the tax year
to which the rent relates, regardless of when the rent is effectively received.
Rental income also includes income derived by owners from the rental of rooms located
in their own homes, with a capacity for tourist accommodation ranging from one room
to five rooms.
Individuals earning rental income from more than 5 rental contracts at the end of a fiscal
year, starting with the following fiscal year are required to qualify such income as income
from independent activities subject to rules applicable to this category.  

Taxable rental income is determined by subtracting from gross rental income a

deduction equal to 25% of gross income. Tax on rental income is determined by applying
a rate of 16% to the taxable amount. As an exception, taxpayers may opt for the
determination of the net rental income based on single-entry accounting.
As of 1 January 2014, health fund contribution is due and is deductible from the annual
rental income obtained, regardless of the method applied for the computation of net
income.

Investment income. Investment income includes the following:

Dividend income
Interest income
Gains from transfers of securities
Income from futures and forward transactions with foreign currencies and similar
operations
 Income from dissolution of a legal entity
Amounts received from holding participation titles in closed investment funds are
treated similarly to dividends. A 16% final withholding tax is imposed on dividends.
Taxable income from interest is considered to be any income in the form of interest
other than interest from municipal bonds.
A 16% final withholding tax is imposed on interest income. The tax must be remitted by
the 25th day of the following month.
Capital gains derived from sales of shares in publicly traded companies and open
investment funds are subject to a 16% final tax, regardless of the holding period of the
shares.
A 16% advance tax is imposed on gains derived from sale and purchase transactions in
foreign currencies with subsequent term settlement, as well as similar operations. The
advance tax must be paid by the 25th day of the following month. The final tax of 16% is
assessed by the tax authorities based on the annual tax return.
Income whose source is not identified. Any income whose source is not identified is
subject to 16% income tax applied to the tax base adjusted according to the procedures
Section V. Requirements of the Information System 315

and indirect methods for the reconstitution of revenues or expenses. The tax authorities
compute the income tax and late payment penalties.
Deductions. Individuals domiciled in Romania and individuals meeting the residence
criteria for worldwide income taxation are entitled to personal deductions, which vary
according to gross monthly income and number of dependents of the individuals. For
gross monthly income up to RON 1,000, the monthly deductions vary between RON 250
for individuals without dependents and RON 650 for individuals with four or more
dependents. For gross monthly income between RON 1,000 and RON 3,000, the
deductions are set by an order of the Ministry of Economy and Finance. No deduction is
allowed for gross monthly income greater than RON 3,000.
Rates. As discussed in Income subject to tax, most types of income are subject to tax at a
flat rate of 16%.

B. Inheritance and gift taxes

No taxes are levied on inheritances or gifts, except for revenue subsequently derived
from these items.

C. Social security and health care charges

Both employers and employees must contribute to the social security system.
Employees are required to pay the following monthly charges.
Type Amount
Social security contribution10.5% of monthly gross salary
earnings (tax base is capped at
5 times the national average
gross salary earnings)
Health fund contribution 5.5% of gross monthly
salary earnings
Unemployment fund 0.5% of gross monthly
contributions salary earnings
Employers are required to make the following monthly
charges.
Type Amount
Social security 20.8% (for normal work
contribution conditions) of the total gross
salary earnings (tax base is
capped at 5 times the national
average gross earnings multiplied
by the number of employees)
Health fund contribution 5.2% of the total gross
salary earnings
Unemployment fund 0.5% of the total gross
contribution salary earnings
Contribution to insurance 0.15% to 0.85% of the
fund against work total gross salary earnings
316 Section V. Requirements of the Information System

accidents and
professional diseases
Medical leave and health 0.85% of total salary fund
indemnities contribution(tax base is capped at 12 times
the national minimum gross
salary earnings multiplied by
the number of insured persons)
Contribution to the Fund for 0.25% of the total gross
Guarantee of Salary salary earnings
Payment Liabilities
Citizens of European Union countries and Switzerland benefit from the coverage of
medical expenses incurred in Romania and may be exempted from social security
charges if relevant European certificates are obtained. However, if an individual is not
subject to social security charges in his or her home country, he or she falls under the
Romanian social security system and is liable to pay social security charges in accordance
with Romanian regulations (a certain procedure should be followed either by the home
country employer or the employee to register for social security purposes).

D. Tax filing and payment

Foreign nationals assigned to work in Romania and who do not meet the tax exemption
conditions, must register for tax purposes within 15 days after beginning their
assignment. Subsequently, they have to file monthly tax returns, pay income tax and, if
applicable social security charges, by the 25th day of the following month.
If the individual is on a local payroll, the local employer must compute, withhold, declare
and pay the income tax and social security charges (if the case).

E. Double tax relief and tax treaties

Romania has entered into double tax treaties with the following countries.
Albania Indonesia Russian Federation
Algeria Iran
Armenia Ireland San Marino
Saudi Arabia
Serbia and Montenegro (former Yugoslavia)
Australia Israel Singapore
Austria Italy Slovak Republic
Azerbaijan Japan Slovenia
Bangladesh Jordan South Africa
Belarus Kazakhstan Spain
Belgium
Bosnia and Herzegovina Korea (North)Sri Lanka
Bulgaria Korea (South) Sudan
Canada Kuwait Sweden
China Latvia Switzerland
Costa Rica Lebanon Syria
Croatia Lithuania Tajikistan
Cyprus Luxembourg Thailand
Czech Republic Macedonia Tunisia
Malaysia Turkey
Section V. Requirements of the Information System 317

Turkmenistan
Denmark Malta Ukraine
Ecuador Mexico United Arab Emirates
Egypt Moldova
Estonia Morocco United Kingdom
Ethiopia Namibia United States
Finland Netherlands Uzbekistan
France Nigeria Vietnam
Georgia Norway
Germany Pakistan -
Greece Philippines
Hungary Poland
Iceland Portugal
India Qatar Zambia

A. Value Added Tax – in Romania - at a glance

Name of the tax Value-added tax (VAT)
Local name Taxa pe valoarea adaugata
Date introduced 1 July 1993
European Union (EU)
member state Yes (effective from 1 January
2007)
Administered by Ministry of Public Finance
(http://www.mfinante.ro)
VAT rates
Standard 24%
Reduced 5%/9%
Other Exempt without credit and
exempt with credit
VAT number format RO XXXXXX (the prefix is RO,
but the number of digits may
vary)
VAT return periods Monthly or, under certain
conditions, quarterly (if the
Romanian tax authorities grant
a special derogation and if
certain conditions are met, the
return may be submitted on a
half-yearly or yearly basis)
Thresholds
Registration €65,000
Distance sales €35,000
Recovery of VAT by
nonestablished businesses Yes (under certain conditions)
318 Section V. Requirements of the Information System

B. Scope of the value added tax

VAT applies to the following transactions:
 Supplies of goods made in Romania by a taxable person
 Supplies of services in Romania by a taxable person
 The intra-Community acquisition of goods from another EU member state (see the
chapter on the EU)
 Acquisition of general business-to-business (B2B) services taxable in Romania, from
EU and non-EU suppliers
 The importation of goods into Romania

C. Who is liable
A “taxable person” is any person who independently makes taxable supplies of goods or
services in the course of a business, regardless of the purpose or results of that activity. The
VAT registration threshold is turnover of RON 220,000 (€65,000) a year (this threshold
applies only to taxable persons established in Romania). Established taxpayers who estimate
or record a turnover of more than the Romanian currency equivalent of €65,000 must
request registration for VAT by the 10th day of the month following the fiscal period in which
the threshold is exceeded. The VAT registration becomes valid starting the first of the month
following the fiscal period of the request.
In principle, the buyer of goods or services is held jointly and severally liable with the seller
for payment of Romanian VAT.
Deregistration. Taxable persons with annual turnover of less than RON 220,000 may request
deregistration by the 10th day of the month following the fiscal period applied by the taxable
person.
Group registration. VAT grouping is allowed under the Romanian VAT law exclusively for
taxpayers registered with the same tax office.
Under the rules currently in effect, a minimum of two taxable persons may form a fiscal
group for a period of at least two years if all of the members meet the following conditions:

They are established in Romania.

They do not belong to another fiscal group.

They use the same tax period.

Their capital is held directly or indirectly, in a proportion of more than 50% by the
same shareholders.
However, VAT grouping is allowed only for VAT reporting (for consolidation purposes).
Nonestablished businesses. A taxable person that has the seat of its economic activity in
Romania is deemed to be established in Romania for VAT purposes.
A taxable person that has the seat of its economic activity outside Romania is considered to
be established for VAT purposes in Romania if it has a fixed establishment in Romania, which
means that it has sufficient technical and human resources to perform on a regular basis
taxable supplies of goods and/or services.
Section V. Requirements of the Information System 319

A taxable person that has the seat of its economic activity outside Romania and that has a
fixed establishment in Romania is not deemed to be established in Romania for the supplies
of goods and services performed in Romania in which the Romanian fixed establishment is
not involved.
The seat of its economic activity is deemed to be the place where the management decisions
of a taxable person are taken and where the functions of its central administration are
performed. To determine where a taxable person has its economic seat, certain factors
should be taken into account, such as the place where the directors meet and where the
company sets its general policy.
In general, a nonestablished business must register for VAT if it undertakes a range of
activities, such as the following:
 Intra-Community acquisitions of goods in Romania
 Intra-Community supplies of goods in Romania
 Transfers of its own goods to Romania
 Sending goods to Romania from another EU country for processing with the finished
products not returning to the EU country of dispatch
 Distance sales in excess of the annual threshold of €35,000
A taxable person that has the seat of its economic activity outside Romania but has a fixed
establishment in Romania must register for VAT purposes in Romania before receiving a
service for which it is liable to pay the VAT or before supplying a service from this fixed
establishment to a taxable person that is liable to pay VAT in another EU member state.
A taxable person that has the seat of its economic activity in Romania but is not registered
for VAT purposes in Romania must register for VAT purposes if it supplies services with a
place of supply in another EU member state, for which the beneficiary is liable to pay the tax.
A taxable person that has the seat of its economic activity in Romania but is not registered
for VAT purposes in Romania must register for VAT purposes if it acquires services from a
supplier established in another EU member state and if such taxable person, as the
beneficiary of the services, is liable to pay the tax.
VAT registration is not required if an entity that is neither established nor registered for VAT
in Romania makes a local supply of goods or services and the recipient is an established
taxable person, nontaxable legal person (for example, a public authority) or is a
nonestablished taxable person that is registered for VAT in Romania.
If an entity that is established within the EU supplies goods or services, if the place of supply
is in Romania and if the entity is liable to pay VAT with respect to such transaction, the EU
entity may opt to appoint a VAT representative or to register directly for VAT purposes. An
entity that is established outside the EU may register in Romania only through a fiscal
representative.
Taxable persons not established and not registered for VAT purposes in Romania may apply
for VAT registration if they carry out imports of goods into Romania, taxable supplies of
immovable property or rental of immovable property in Romania.
Registration in the Registry of Intra-Community Operators. Effective from 1 August 2010, all taxable
persons and nontaxable legal persons that perform intra-Community operations (intra-
320 Section V. Requirements of the Information System

Community acquisitions and supplies of goods and/or services falling under the general B2B
rule for the supply of services) must register in the Registry of Intra-Community Operators
(RIO) before performing such operations. Failure to comply with this registration
requirement results in an invalid VAT number for intra-Community operations, effective from
1 August 2010, even if the respective person is registered for VAT purposes in Romania.
The Romanian tax authorities may impose a fine of between RON 1,000 and RON 5,000
(approximately €250 to €1,150) if a person performs intra-Community operations before
registering in the RIO.
Reverse charge. The reverse charge applies to the following transactions, among others:
 Intra-Community acquisitions of goods and services.
 Local supplies of goods and services made by nonestablished and unregistered
entities to customers that are registered for VAT in Romania.
 Imports. The reverse charge may be applied to imports exclusively by persons who
have obtained a specific VAT payment postponement certificate.
 Local supplies of certain categories of goods, such as ferrous waste, grain crops,
wood, transfer of green certificates etc. performed between entities registered for
VAT purposes in Romania.
 Supplies of electrical energy performed by a taxable person registered for VAT in
Romania to a Romanian VAT registered taxable person acting as trader.
Tax representatives. A nonestablished, non-EU entity that carries on taxable operations in
Romania and that is required to register for VAT purposes must appoint a tax representative.
A taxable person that is established in the EU may appoint a tax representative, but may also
choose to register for VAT in its own right (direct VAT registration).
Late-registration penalties. Penalties of RON 1,000 to RON 5,000 (approximately €250 to
€1,100) apply to late registration for VAT purposes. Separate penalties ranging from RON
1,000 to RON 5,000 are assessed for delays in submitting VAT returns. In addition, for the late
payment of VAT, late payment interest (0.04% per day of delay) and late payment penalties
(0.02% per day of delay, starting 1 st July 2013) apply.

D. VAT rates
Supplies within the scope of VAT are classified as taxable and exempt. Exempt supplies and
operations are further classified in the following ways:
 Exempt supplies with credit (that is, with the right to deduct input VAT; see Section F)
 Exempt supplies without credit (that is, without the right to deduct input VAT; see
Section F)
 Exempt imports and intra-Community acquisitions (under certain conditions)
 Exempt without credit supplies performed by taxable persons established in Romania
who have annual turnover of less than €65,000 and who have not opted for standard
taxation
In Romania, the standard rate of VAT is 24%. A reduced VAT rate of 9% applies to certain
supplies (see below). Standard VAT rate will be reduced to 20% starting with January 1st,
2016.
Section V. Requirements of the Information System 321

Effective from 15 December 2008, a 5% reduced VAT rate applies to the supply of social
housing (including related land). For this purpose, social housing includes, but is not limited
to, houses that are a maximum of 120 square meters and that do not exceed RON 380,000 in
value (net of VAT). The reduced 5% VAT rate applies only if both of the following conditions
are satisfied:
 The house can be used as such after the sale.
 For individual houses, the surface of the land on which the house is built is less than
250 square meters.
The following tables provide examples of exempt supplies of goods and services and
examples of goods and services taxed at the reduced rate of 9% (these lists are not
exhaustive).
Examples of supplies of goods and services that are exempt without credit
 Specific banking and financial operations
 Insurance and reinsurance
 Medical services
 Education
 Specific hiring, concession, leasing or letting of immovable property (unless option to
tax is exercised)
 Sale of “old” buildings (unless option to tax is exercised)
Examples of supplies of goods and services that are exempt with credit
 Exports of goods
 Transport services and other services directly linked to exports of goods.
 International transport of passengers
 Intra-Community supplies of goods (specific provisions)
Examples of exempt imports and intra-Community acquisitions
 Re-imports of Romanian goods repaired abroad (equivalent to the exported goods)
 Imports of natural gas through specific distribution systems and electricity
Examples of goods and services taxed at 9%
 Books, newspapers, magazines and school manuals (except those intended
exclusively for publicity)
 Prostheses of any type and accessories (except dental prostheses)
 Orthopedic products
 Medicines for human and veterinary use
 Hotel accommodation and similar accommodation, including the rental of land for
camping
 Certain bread and bakery products

E. Time of supply
The time when VAT becomes due is called the “chargeability to tax” or “tax point.” The basic
time of supply for goods is when the goods are delivered. The basic time of supply for
services is when the services are provided. Several exceptions apply to these rules.
322 Section V. Requirements of the Information System

For intra-Community acquisitions or exempt intra-Community supplies of goods, the tax

point arises on the day when the invoice is issued, the day when a self invoice is issued or the
15th day of the month following the month in which the chargeable event took place,
whichever is earlier.
Continuous supplies of services. The time of supply for continuous supplies of services, such as
telephone services, water and electricity, is on the last day of the period specified in the
contract for payment, or on the date of issuance of the invoice (but the settlement period
should not exceed one year).
Prepayments. The tax point for advance payments is when the payment is received. Special
rules may apply in case of a change of tax regime, partial prepayments or partial advance
invoices.
Payments by installment. The tax point for a supply of tangible goods (including immovable)
with installment payments occurs when the goods are handed-over to the beneficiary (unless
an invoice is issued or a payment is received before that date).
Cash accounting. A taxable person registered for VAT purposes in Romania and having the seat
of its economic activity in Romania, whose turnover in the previous calendar year does not
exceed RON 2,250,000 (approx. EUR 500,000) should apply the VAT cash-in system.
The turnover for computing the RON 2,250,000 threshold is made up of the total value of the
supplies of goods or services, VAT exempt with deduction right, as well as of the operations
for which the place of supply is deemed to be located abroad, realized during one calendar
year.
VAT chargeability. The VAT chargeability occurs upon the date of collecting the total or partial
value of the supplies of goods or services in the case of taxable persons applying the VAT
cash-in system.
However, if the taxable person failed to collect the counter value of the invoices issued
within 90 calendar days as of issue date (or the date when such invoice should have been
issued), the VAT chargeability occurs on the 90th calendar date as of issue date of the invoice
(or the date when such invoice should have been issued).
Specific rules have been set in the case of invoices issued by taxable persons prior to
entering/exiting the VAT scheme upon collection, as well as in the case of adjustments of the
taxable amount.
Persons and operations excluded from the application of the VAT cash-in system. The VAT cash-in
system should not be applied by taxable persons who are part of a single tax group, taxable
persons not established in Romania which are registered in Romania for VAT purposes
directly or through a tax representative and taxable persons which have the seat of their
economic activity outside Romania but have a fixed establishment in Romania. However, the
respective persons will apply the VAT cash-in system in respect of VAT deduction for invoices
issued by suppliers - taxable persons applying the respective system.
Furthermore, certain operations, such as e.g. supplies of goods or services which are exempt
from VAT, supplies of goods or services between related parties or supplies of goods or
services paid in cash are excluded from the application of the VAT scheme upon collection.
Deduction right. The deduction right of the input VAT related to acquisitions performed by
Section V. Requirements of the Information System 323

taxable persons from other taxable persons applying the VAT cash-in system is postponed
until the date of the VAT payment towards such suppliers.
Furthermore, the VAT deduction right in the case of acquisitions made by a taxable person
applying the VAT cash-in system will be postponed up to the payment of VAT to its supplier
in relation to the goods or services supplied, with certain exceptions.
Record of transactions. In case of transactions subject to the VAT cash-in system, both the seller
and the buyer have the obligation to include in the VAT journals the invoices issued/received
for which the VAT cash-in system is applicable, even if the VAT chargeability, respectively the
VAT deduction right does not arise in the period in which the invoice was issued. Invoices
bearing unsettled VAT, in full or in part, will be carried forward in the VAT journals for sales,
respectively purchases until the VAT becomes chargeable according to the law.
Registration in the Registry of persons applying the VAT cash-in system. The Register of taxable
persons applying the VAT scheme upon collection has been introduced. Registration and
deregistration is carried out by filing a relevant notice, except for taxable persons registered
for VAT purposes over the current calendar year, who are automatically registered as of VAT
registration date.
Reverse-charge services. Certain services received by a Romanian taxable person from a foreign
supplier are taxed in Romania using the reverse-charge mechanism, which means that the
Romanian customer must account for the VAT due in the VAT return for the month in which
the tax point occurs. In such circumstances, the customer accounts for the VAT as both
output tax and input tax in the VAT return. If the beneficiary has a full right to deduct input
tax, the charge is neutral for tax purposes (see Section F).
If no invoice is received from the foreign supplier, the Romanian beneficiary must issue a
“self-invoice,” which must be in a specified format, by the 15th day of the month following
the month in which the services are supplied. The time limit for issuing an invoice is the 15th
day of the following month.
If the beneficiary of the service is registered for VAT in Romania, the VAT due must be paid
by the 25th day of the month following the month in which the tax point occurs. However, if
the beneficiary is not registered for VAT in Romania under the normal regime, the reverse
charge must be accounted for by using a special VAT return (with no right of deduction;
consequently, the VAT due must be paid).

F. Recovery of VAT by taxable persons

A taxable person may recover input tax, which is due on goods and services supplied to it for
business purposes. A taxable person generally recovers input tax offsetting it against output
VAT, which is VAT charged on supplies made.
In principle, input tax includes VAT charged on goods and services supplied within Romania,
VAT paid on imports of goods, and VAT self-assessed for reverse-charge services received
and for intra-Community acquisitions of goods, as well as for certain taxable transactions
subject to reverse charge simplified measures.
Except for certain specific cases, the amount of VAT reclaimed must be requested through
the VAT return. The excess of input VAT over output VAT is generally refundable.
324 Section V. Requirements of the Information System

Alternatively, it may be offset against future VAT liabilities.

For taxable persons that are registered for VAT purposes in Romania, the minimum amount
of a VAT refund is RON 5,000 (approximately €1,100). Any amount below this threshold may
be recovered by offsetting it against other VAT liabilities.
Entities that are not registered for VAT in Romania may submit a request for a VAT refund
based on the new EU Refund Directive or the EU 13th Directive (provided reciprocity exists in
the case of the EU 13th Directive). A refund may be requested if the amount due is at least
the equivalent in Romanian lei (RON) of €400 for a period shorter than a year but greater
than three months, or at least the equivalent in RON of €50 for a one-year period or the
remainder of a year.
Nondeductible input tax. Input tax may not be recovered on purchases of goods and services
that are not used in the performance of operations subject to VAT (for example, goods
acquired for private use by an entrepreneur). In addition, input tax may not be recovered for
some items of business expenditure.
The following tables provide examples of items of expenditure for which input tax is not
deductible and examples of items for which input tax is deductible if related to a taxable
business use (these lists are not exhaustive).
Examples of items for which input tax is nondeductible
 Personal expenses
 Business gifts (if the individual value of each item (tangible good) is higher than RON
100, or approximately €22, and VAT was deducted on acquisition)
 Alcohol and tobacco
Examples of items for which input tax is deductible(if related to a taxable business use)
 Advertising
 Hotel accommodation
 Conferences
 Purchase of vans and trucks, and leases of cars, vans and trucks
 Business travel expenses
Effective from 1 July 2012, the right to deduct VAT related to purchase, intra-Community
acquisition, import, rental or leasing of motor road vehicles, together with the VAT deduction
right for expenses related to certain types of vehicles owned or used by the taxable person, is
limited to 50% if such vehicles are not used exclusively for business purposes. The rule does
not apply to motorized road vehicles weighting more than 3.5 tons or having more than 9
seats, including the driver’s seat.
However, vehicles used for certain specifically mentioned activities (for example, used for
rendering services against consideration, used as merchandise for commercial purposes and
used by sales and purchase agents) are not subject to such provision. In this context, input
VAT recovery should be supported by back-up documentation and log books.
For the period 1 May 2009 up to 31 December 2011 the VAT related to the acquisition (i.e.
either local purchase, intra-community acquisition or import) of motorized road vehicles, as
well as the one related to the acquisition of fuel destined for the vehicles having the
characteristics mentioned above, owned or used by taxpayers, is non-deductible.
Section V. Requirements of the Information System 325

Starting with 1 January 2012, the deductibility of the input VAT related to the acquisition of
vehicle used exclusively for passenger road transportation (i.e. motorized road vehicles, that
are exclusively used for passenger road transportation, weighing no more than 3.5 tons and
with a maximum 9 seats, including the driver’s seat) and the acquisition of fuel related to
such vehicles is limited to 50%.
Effective 14 March 2013, input VAT mentioned on fiscal receipts will only be deductible if
they contain a reference to the VAT code of the customer and the total value of the
acquisition is lower than €100.
Partial exemption. Input tax directly related to taxable supplies is fully recoverable, while input
tax directly related to exempt supplies is fully no recoverable. Input tax that is attributable to
both taxable and exempt supplies (such as VAT paid on overhead costs) is deductible on a
pro-rata basis. The pro-rata method is generally based on the percentage of income
generated by supplies with a right to input tax deduction, divided by total income. The
calculation of recoverable VAT is based generally on the pro rata percentage for the
preceding year. However, a special pro rata percentage may be used if approved by the tax
authorities. Pro rata percentages may also be established for each sector of the taxable
person’s activity that has a partial right to claim deductions.
Refunds. If input VAT exceeds output VAT, the balance (known as the “negative VAT balance”)
may be treated in either of the following manners:
 Carried forward to the next period.
 Compensated or refunded by the tax authorities, based on an option exercised by the
taxpayer in the taxpayer’s VAT return. This option may be exercised only for negative
VAT balances exceeding RON 5,000.
The VAT refund application may cover eligible input VAT incurred in the period beginning
with the fifth year before the year in which the claim is made (under certain conditions).In
principle, a VAT refund or compensation request must be dealt within 45 days (in practice,
this period may be longer). Depending on certain parameters, the VAT refund can be granted
with or without a prior VAT audit. During the VAT refund process, the tax authorities may
request additional information from the taxpayer. Consequently, the term for making the
repayment may be extended by the number of days between the date of the request for
additional information and the date on which the information is received by the tax
authorities. If the refund or compensation request is not dealt with by the expiration of this
term, in principle, the taxpayer is entitled to receive late payment interest.

G. Recovery of VAT by nonestablished businesses

Romania refunds VAT incurred by businesses that are neither established in Romania nor
required to be registered for VAT there. Nonestablished businesses may claim Romanian
VAT to the same extent as VAT-registered businesses.
For businesses established in the EU, refund is made under the terms of the new EU 9th
Refund Directive. For businesses established outside the EU, refund is made under the terms
of the EU 13th Directive (under the condition of reciprocity).
For the general VAT refund rules applicable to the new EU Refund Directive and EU 13th
Directive refund schemes, see the chapter on the EU.
326 Section V. Requirements of the Information System

Refund application. The deadline for refund claims is 30 September of the year following the
calendar year of the reimbursement period.
Claims under the EU VAT Refund Directive may be submitted in the Member State where the
applicant is established. The application for refund must be accompanied by the appropriate
documentation (see the chapter on the EU).
In principle, the term established by the tax authorities for processing a refund application is
four months from the date of submission of the application and supporting documents.
The minimum claim period is three months, while the maximum period is one year. The
minimum claim for a period of less than a year, but greater than three months, is the
equivalent in RON of €400. For an annual claim or a claim for a period of less than three
months, the minimum amount is the equivalent in RON of €50.
Repayment interest. Effective from 1 July 2010, interest at a rate of 0.05% (0.04% beginning 1
October 2010) per day of delay may be claimed by a taxable person for late refunds. Before 1
July 2010, the percentage was 0.1%.

H. M1SS Scheme
Starting with 1 January 2015, the place of supply for electronic services, broadcasting
and electronic services to non-taxable persons (e.g. individuals, public institutions, non-
government organizations) should be the place where the customer is established or has
a permanent address or usually resides. Therefore, should a taxable person perform
such supplies to non-taxable persons outside the EU Member State where the taxable
person is established, it will be required to register, charge and account for VAT in the
Member State of the customer. This would potentially trigger registration in all EU
Member States where the clients are established, followed by reporting requirements
and payment obligations in each Member State.
In order to simplify the reporting procedure a special scheme, called the Mini One Stop
Shop (MOSS or M1SS) has been set up. The scheme is optional and allows taxable
persons that supply services falling in the telecommunications, broadcasting or
electronic services category to consumers in EU Member States in which they do not
have an establishment, to account for and report the VAT due on those supplies via a
web-portal in just one EU Member State. In Romania the tax report on VAT is called
declaration 399, and the address of the web-portal is http://www.anaf.ro .

I. Invoicing
VAT invoices and reversal invoices. A Romanian taxable person must generally provide a VAT
invoice for all taxable supplies made. Invoices that contain errors may be cancelled and the
taxpayer may issue a “reversal invoice.” The amount credited must be printed on the reversal
invoice and must be preceded by a minus sign. A reversal invoice must contain the same
information as a VAT invoice and a cross-reference must be provided.
Electronic invoicing. Effective 1 January 2013, the VAT law has been amended to permit
electronic invoicing in line with EU Directive 2010/45/EU. For invoices issued by non-EU
suppliers, the authenticity and integrity of the content of the invoice should be ensured
Section V. Requirements of the Information System 327

either through an electronic signature or the electronic data exchange (EDI) procedure.
Proof of exports. Goods exported from Romania are not subject to Romanian VAT. To qualify
as exempt with credit, the supplier must prove that the goods left Romania. Suitable proof
includes the following documentation:
 Customs documentation
 Invoices
 Other relevant documentation depending on the nature of the export
Foreign-currency invoices. If a VAT invoice for a transaction that takes place in Romania is issued
in a foreign currency, the VAT amount must be converted into Romanian lei (RON), using the
rate published by the National Bank of Romania, the bank in charge of the payment transfers,
or the European Central Bank. The conversion must be calculated for the date on which the
tax point for the transaction occurred or would have occurred if the VAT cash-in system had
not been applied. The parties to the transaction must mention the applicable method in the
contract.

J. VAT returns and payment

VAT returns. Taxable persons with an annual turnover below the RON equivalent of €100,000
must submit VAT returns quarterly. However, effective from 1 May 2009, taxpayers who
submit quarterly VAT returns must submit monthly VAT returns, effective from the date on
which they perform a taxable intra-Community acquisition in Romania. All other taxable
persons submit VAT returns monthly.
The due date is the 25th day of the month following the end of the return period. Payment in
full is required by the same date. All VAT liabilities must be paid in Romanian currency.
Beginning with the tax returns due on 25 November 2010, large and medium-sized taxpayers
must file their tax returns (including corporate income tax and VAT returns) electronically.
The relevant tax returns must be signed by the taxpayer using a qualified certificate issued by
a provider of certification services.
Informative statement. All taxable persons that are registered for VAT in Romania must also
submit an informative statement to the Romanian tax authorities. This statement must
include all local supplies and acquisitions performed between taxable persons registered for
VAT purposes in Romania, made in the reporting period.
The due date is the 25th day of the month following the end of the period. In case no local
acquisitions/sales are performed during the period, no Informative statement should be
filled. A failure to submit an Informative statement by the due date is subject to a fine
ranging from RON 12,000 – 14,000 (approximately €2,600 - €3,200).
Penalties. Effective from 1 July 2010, late payment interest, charged at a rate of 0.05%, applies
for each day of delay. Beginning 1 October 2010 the late payment interest rate is 0.04%.
Additional late payment penalties (0.02% per day of delay) apply. Before 1 July 2013, late
payment penalties were in amount of 0%, 5% or 15% depending on the period of delay.
Fraud committed with respect to the calculation of a VAT repayment may be considered a
fiscal evasion.
328 Section V. Requirements of the Information System

K. EU declarations
INTRASTAT. A Romanian taxable person that trades with other EU countries must complete
statistical reports, known as INTRASTAT, if the value of either dispatches or arrivals of goods
exceeds certain thresholds. Separate reports are required for intra-Community acquisitions
(INTRASTAT Arrivals) and for intra-Community supplies (INTRASTAT Dispatches).
The threshold for INTRASTAT Arrivals is RON 500,000.
The threshold for INTRASTAT Dispatches is RON 900,000.
Romanian taxable persons must complete INTRASTAT declarations in Romanian lei, rounded
up to the nearest whole number.
INTRASTAT returns must be submitted monthly. The submission deadline is the 15th day of
the month following the return period.
A penalty may be imposed for late submissions or for missing or inaccurate declarations.
EU Sales and Acquisitions Lists. If a Romanian taxable person makes intra-Community supplies or
intra-Community acquisitions of goods in any return period, it must submit an EU Sales and
Acquisitions List to the Romanian VAT authorities. Effective from 1 January 2010, the listing
of intra-Community supplies or acquisitions is also required for qualifying services that are
rendered to or received from a taxable person established in the EU and that are taxed
where the beneficiary is established. This list is not required for any period during which the
taxable person does not make any intra-Community supplies or acquisitions.
The listing of intra-Community sales or acquisitions of goods and qualifying services must be
submitted on a calendar monthly basis by the 25th day of the month following the relevant
month. A failure to submit an EU Sales and Acquisitions List reporting sales or acquisitions of
goods by the due date is subject to a fine ranging from RON 1,000 to RON 5,000
(approximately €230 to €1,100). The submission of such list with incorrect or incomplete
amounts is subject to a fine ranging from RON 500 to RON 1,500 (approximately €115 to
€350). The fine does not apply if the taxable person corrects voluntarily the EU Sales and
Acquisitions List by the due date for the submission of the next EU Sales and Acquisitions List.
Section V. Requirements of the Information System 329

Tax Nomenclature

Budgetary
COD_IMP Tax Description (in English)
Category
100 Income tax 1
101 Payments from net revenue of National Bank of Romania 1
Advance payments for annual income tax due by commercial
banks, Romanian legal persons and Romanian bank subsidiaries,
102 foreign legal persons 1
Income tax/ advance payments for annual income tax due by
Romanian legal persons, others than those from section 1 and
legal persons with headquarters in Romania, established
103 according to European legislation 1
104 Annual tax income 1
Income tax due by foreign legal persons, other than those from
section 1 or advance payments due to annual tax income, due by
foreign legal persons that carry out activities by means of a
105 permanent office in Romania 1
106 Tax on profit from natural persons in association 1
110 Romanian fund 1
Income tax exempted according to art. 38 paragraph(1) from the
111 Fiscal Code 1
Income tax exempted according to art. 38 paragraph(3) from the
112 Fiscal Code 1
Income tax exempted according to art. 38 paragraph(8), (9) or
113 (11) from the Fiscal Code 1
Additional 20% share of investment value according to art. 38
114 paragraph(13) from the Fiscal Code 1
120 Micro-enterprises' income tax 1
121 Micro-enterprise income tax 1
Tax on income from micro-enterprises created by the association
of a natural person with a legal person, not generating a legal
122 person 1
Tax on income generated in Romania by nonresident - legal
140 persons, collected until 31.01.2014 1
150 Tax on income from dividends for legal persons 1
155 Tax on income of attorneys and public notaries 1
Income tax for Romanian offices of foreign commercial and
160 economic organizations 1
200 Excise 1
Excise duty on alcohol and distilled spirits sales, due until
210 31.12.2006 1
330 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
211 Excise duty on beer 1
212 Excise duty on sparkling wines 1
213 Excise duty on fermented beverages other than wine and beer 1
214 Excise duty on intermediate products 1
215 Excise duty on ethyl alcohol 1
216 Excise duty on still wines 1
217 Excise duty on still fermented beverages other than beer and wine 1
Excise duty on still fermented beverages other than beer and wine
218 sales, due until 31.01.2011 1
220 Excise duty on tobacco sales 1
221 Excise duty on cigarettes 1
222 Excise duty on cigars and cigar sheets 1
223 Excise duty on tobacco 1
224 Excise duty on fine-cut tobacco for cigar rolling 1
225 Excise duty on other smoking tobacco 1
230 Excise duty on energy products sales 1
231 Excise duty on leaded petrol 1
Excise duty on unleaded petrol and denatured bioethanol used as
232 motor fuel 1
233 Excise duty on diesel fuel and biofuel 1
234 Excise duty on heavy fuel oils 1
235 Excise duty on liquefied petroleum gas 1
236 Excise duty on natural gas 1
237 Excise duty on coal and coke 1
238 Excise duty on kerosene 1
239 Excise duty on mineral oils due until 31.12.2006 1
240 Excise duty on coffee 1
241 Excise refund for diesel sales 1
242 Excise duty on roasted coffee including coffee-substitute 1
243 Excise duty on soluble coffee including soluble coffee blends 1
244 Excise duty on green coffee 1
250 Excise duty on other products sales until 30 September 2013 1
Excise duty on beer/ beer base in mixtures of non-alcoholic
beverages and beer with the percentage of Plato degrees from
malt, malted and/or unmalted grains less than 30% of the overall
251 Plato degrees 1
Section V. Requirements of the Information System 331

Budgetary
COD_IMP Tax Description (in English)
Category
Excise duty on fermented beverages other than wine & beer with
the percentage of absolute alcohol (100%) only from fermented
252 fruit, fruit juices and concentrated fruit juice is lower than 50% 1
Excise duty on gold and/or platinum jewelry, except wedding
253 rings 1
254 Excise duty on natural fur clothing 1
Excise duty on yachts and other recreational ships and boats with
255 or without an engine, except those for performance sport 1
Excise duty on vehicles and SUVs with cylindrical capacity
256 greater or equal to 3.000 cm3 1
Excise duty on hunting weapons and personal use weapons others
257 than those for military and sportive use 1
Excise duty on bullet cartridges and other types of ammunition
for hunting and personal use arms, other than those for military
258 and sportive use 1
Excise duty on engines with more than 100 horse power, for
259 yachts and other recreational ships and boats 1
260 Excise duty on vehicle sales from domestic production 1
Excise duty on vehicles that were subject of leasing contracts
261 started before 1st January 2007 1
270 Excise duty on electrical energy 1
275 Excise duty on other excisable products (energy) 1
280 Excise duty on sales of air conditioners 1
283 Excises from issuing of fiscal bands for alcoholic beverages 1
290 Refunded excise duty 1
300 Value-added tax (VAT) 1
301 Monthly - value-added tax (VAT) 1
302 Quarterly - value-added tax (VAT) 1
303 Half-yearly - value-added tax (VAT) 1
304 Annual - value-added tax (VAT) 1
305 Interest and penalties on late payment of VAT 1
307 VAT to be paid as a result of adjustments 1
Amounts deducted from VAT for state pre-university educational
institutions, nurseries, county and local centers of agricultural
344 consulting and support for child protection system 1
390 Reimbursement of the VAT 1
410 Social insurance contribution 2
411 Social insurance contribution by the employer 2
332 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
412 Social insurance contribution deducted from the insured persons 2
Social insurance contribution for people whose duties are paid
413 2
from the Unemployment Insurance Fund
Contribution to supplementary pension retained from people
414 included in the social insurance system 2
415 Farmers' contribution to the pension fund and social insurance 2
Social insurance contribution for work accidents and professional
416 illnesses caused by the employer 2
417 Contribution for Social insurance fund 2
Social insurance contribution for work accidents and professional
418 illnesses for unemployed people 2
Individual social insurance contribution by people who obtain
419 professional income other than salary 2
420 Contribution to unemployment fund 4
421 Contribution to unemployment fund by the employer 4
Contribution to unemployment fund deducted from the insured
422 persons 4
The employer's contribution to the Guarantee Fund for salary
423 payment 4
Individual contribution to unemployment fund by people who
424 obtain professional income other than salary 4
430 Health insurance contribution 3
431 Health insurance contribution by the employer 3
432 Health insurance contribution deducted from the insured persons 3
Health insurance contribution for people whose duties are paid
433 from the Unemployment Insurance Fund 3
Health insurance contribution for people in ongoing military
434 service 3
Health insurance contribution for people who perform custodial
435 sentence or remand 3
Health insurance contribution for sick leaves which is deducted
436 from social insurance contribution by the employer 3

Health insurance contribution for persons in parental leave up to

437 the age of 2 and for a disabled child up to the age of 3 3
Health insurance contribution for people in sick leave, according
to the Law no. 95/2006 regarding healthcare reform, with
subsequent changes and additions and other deductions according
438 to specific social contribution legislation 3
Contribution for vacation and compensation from natural or legal
439 persons 3
Section V. Requirements of the Information System 333

Budgetary
COD_IMP Tax Description (in English)
Category
Contribution for vacation and compensation by unemployed
440 people 3
Health insurance contribution by retirees for income that exceeds
441 the threshold required by law 3
Contribution for vacation and compensation by people which are
442 unable to work due to a work accident or professional illnesses 3
Contribution for vacation and compensation by people which are
unable to work due to a work accident or professional illnesses
accounted for from the insurance fund for work accidents and
443 professional illnesses 3
Health insurance contribution for people from families that are
entitled to welfare, according to Law no. 416/2001 regarding the
444 minimum guaranteed income, with subsequent amendments 3
Individual health insurance contribution for persons, foreign
citizens located in detention centers for deportation, and for
persons, foreigners, victims of human trafficking, which are
undergoing procedures to establish their identity and are
445 accommodated in special centers according to the law 3
Individual health insurance contribution for persons who are
undertaking measures provided in art. 105, 113 and 114 from the
Penal Code and for persons who are in postponement or
446 interruption of imprisonment sentence 3
Individual health insurance contribution for monastic staff of
447 recognized religions 3
Health insurance contribution by the employer for people who are
in medical leave for incapacity of work, due to a work accident or
professional illnesses supported by FAAMBP, according to the
448 Law no. 95/2006, with subsequent amendments 3
Individual health insurance contribution for persons, Romanian
citizens who are victims of human trafficking, for a period of
449 maximum 12 months 3
Quarterly contribution for financing medicine expenses covered
from the National Fund of Health Insurance and from the
450 Ministry of Health's budget 3
Individual social insurance contribution by people with revenue
451 from intellectual property 2
Individual social insurance contribution by people with revenue
from activities performed under contracts / civil agreements
452 concluded according to the Civil Code as well as agent's contract 2
Individual social insurance contribution by people with revenue
453 from technical, judicial and extrajudicial expertise 2
Social insurance contribution by people with revenues from
independent activities, agricultural activities and associations
454 without legal persons 2
334 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
Quarterly contribution for Cost-volume / cost-volume-outcome
455 contracts 3
Contribution for amount of medicines consumed exceeding
456 volumes determined by contracts 3

460 Health insurance contribution by natural persons - regularizations 3

Individual health insurance contribution by people with revenues
461 from intellectual property rights 3
Individual health insurance contribution by people with revenue
from activities performed under contracts / civil agreements
462 concluded according to the Civil Code as well as agent's contract 3
Individual health insurance contribution by people with revenue
463 from technical, judicial and extrajudicial expertise 3
Individual health insurance contribution by people with revenues
from an association with a micro-enterprise, according to the
464 IV^1 Title from the Fiscal Code, which is not a legal person 3
Individual health insurance contribution by people with revenues,
withholding income tax from associations with no legal persons
465 referred in art. 13 letter e) from Tax Code 3
Individual health insurance contribution by people with revenues,
withholding tax on income from agricultural associations referred
466 in art. 71 letter d) from Tax Code 3
467 Individual contribution to social security (OMEF1646/2007) 2
Individual health insurance contribution by people with revenues
468 from independent activities or by people with no revenue 3

Individual health insurance contribution by people with revenues

469 from leases of agricultural goods, withholding income tax 3
Individual health insurance contribution by people with revenues
470 from granting property 3
500 Tax on gambling 1
Tax on gambling in advance or monthly during gambling license
501 availability 1
Periodically regulated tax on gambling according to income
502 within reporting time 1
503 Gambling social stamp tax 1
Periodically regulated annual gambling authorization fee,
504 according to income 1
Duty for organizing and operating gambling activities due until
510 01.01.2014 1
511 Gambling license duty for lottery games 1
512 Gambling license duty for totalizator 1
Section V. Requirements of the Information System 335

Budgetary
COD_IMP Tax Description (in English)
Category
513 Gambling license duty for fixed odds betting 1

514 Gambling license duty for casino activities 1

515 Gambling license duty for slot-machines 1

516 Gambling license duty for bingo halls 1

517 Gambling license duty for TV bingo games 1

518 Authorization duty for operating gambling for lottery games 1
519 Authorization duty for operating gambling for totalizator 1

520 Authorization duty for operating gambling for fixed odds betting 1

521 Authorization duty for operating gambling for casino activities 1

522 Authorization duty for operating gambling for slot-machines 1

523 Authorization duty for operating gambling for bingo halls 1

524 Authorization duty for operating gambling for TV bingo games 1

535 Gambling access fee 1
536 Duty for obtaining license for organizing gambling activities 1
Annual duty for obtaining authorization for operating gambling
537 games 1
600 Income tax 1
601 Income tax from independent services 1
602 Payroll taxes 1
603 Tax on property and granting property 1
604 Tax on dividends for natural persons 1
605 Interest tax 1
Liquidation / dissolution without liquidation of a legal person
606 income tax 1
607 Pensions income tax 1
608 Financial awards income tax 1
609 Transfer of ownership of securities income tax 1
610 Regularizations 1
611 Intellectual property income tax 1
Tax on incomes obtained in Romania by non-residents -
612 individuals, collected up to 31/01/2014 1
613 Tax on income from agricultural activities 1
336 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
Tax on income from the sale of assets in a consignment and from
activities carried out under an agent contract, commission or
614 commercial mandate 1
Tax on income from accounting, technical, judicial and
615 extrajudicial expertise 1
Tax on income from activities performed under contracts / civil
agreements concluded according to the Civil Code and agent
616 contracts 1
Tax on income from sale operations - buying foreign currency
contract based and from other such operations, other than those
with financial instruments traded on authorized markets and
617 supervised by the National Securities Commission 1
Tax on income from commercial activities - tax on income based
on conventions / civil contracts concluded according to the Civil
618 Code 1
619 Leasing agricultural goods income tax 1
620 Transfer of real estates from the personal property income tax 1
621 Gambling income tax 1
Tax on income from dividends obtained in Romania by non-
631 residents 1
Tax on income from interests obtained in Romania by non-
632 residents 1
Tax on income from royalties obtained in Romania by non-
633 residents 1
Tax on income from commissions obtained in Romania by non-
634 residents 1
Tax on income obtained in Romania by non-residents from sports
635 and entertainment activities 1
Tax on income from services provided in Romania and outside
636 Romania by non-residents 1
Tax on income obtained by non-residents individuals from
637 financial award granted at contests held in Romania 1
Tax on income obtained from gambling in Romania by non-
638 residents 1
Tax on income obtained by liquidation of a legal person by non-
639 residents 1
Tax on income representing remunerations received by non-
resident legal persons who act as administrator, founder or
640 member of a board of directors of a Romanian legal person 1
Tax on income from the transfer of fiduciary patrimony from the
641 fiduciary to non-resident beneficiary 1
690 Tax on income from other sources 1
Section V. Requirements of the Information System 337

Budgetary
COD_IMP Tax Description (in English)
Category
699 Payroll Taxes (residual) 1
701 Property tax 1
710 Natural gas and oil intern production tax 1
Tax on additional income obtained as a result of the natural gas
711 prices deregulation 1
Tax on income from exploitation activities of natural resources,
712 others than natural gas 1
713 Tax on natural monopoly of the energy and natural gas sectors 1
720 Tax on nocive activities to human health 1
721 Penalties not paid on time 1
Tax and tariffs on the issuing of licenses and operation
725 authorizations 1
Share of the income realized by the Romanian legal persons
provided at art. 2, letter a) from the OG no. 47/1998 regarding the
730 establishment and use of the Special Fund of civil aviation 1
Share applied to the monthly wages fund, including monthly
735 gainings achieved by individuals (art. 53/OUG no. 102/1999) 1
Social stamp tax on the value of imported new vehicles with
740 engine capacity of more than 2000 cm3 1
750 Tax on prospecting, exploration, resource exploitation 1
Directed income from the flat tax on automotive fuels delivered
internally by producers as well as automotive fuels consumed and
751 imported by them 1
752 Refund for advanced state judicial expenses 1
755 Mining royalties 1
756 Oil royalties 1
Other revenues from concessions and rentals of Public
757 Institutions 1
Royalties from concessions contracts, lease and other efficient
758 exploitation of agricultural land contracts 1
760 Development tax included in the tariff of electricity and heating 1
761 Judicial stamp taxes 1
762 Incomes from judicial stamp 1
765 Income from the application of the extinctive prescription 1
770 Income tax from higher education institutions 1
771 Income from custom benefits tax 1
772 Consular fees 1
773 Income from technical, judicial and extrajudicial expertise 1
338 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
774 Income from provision of services 1
776 Car pollution tax, compensated/ refunded 1
777 Fees and other income from environmental protection 1
Payments from public institutions' liquidities and self-financed
778 activities 1
779 Special taxes for cars and vehicles at first registration in Romania 1
780 Payments from net profit of autonomous administrations 1
781 Dividends paid to the state budget by central public authorities 1
Authorization fees for marketing alcohol, alcoholic beverages,
790 tobacco and coffee 1
791 Environmental stamp 1
810 Payments from legal persons for unqualified disabled people 1
Amounts payable due to special protection and qualification of
811 disabled people 1
814 Income tax deducted shares 1
820 Contribution to public education 1
830 Contribution by tourism undertakings 1
Collections from redemption of loans granted for arrears coverage
840 toward CONEL and ROMGAZ 1
850 Custom duties from legal persons 1
Revenues from fines and other penalties imposed by other
910 specialized institutions 1
Income for state social insurance budget from fines and other
911 penalties imposed under legal provisions 2
Revenues from fines and other penalties imposed by the
912 Directorate General for Tax Fraud 1
915 Collections from retained share, according to the Penal Code 1
916 Refunds from budget financing of previous years 1

920 Penalties for failure to file or late filing of the declaration of taxes 1
921 Penalties due to scheduled payments 1
922 Income from compensations 1
Collections from the sale of seized, abandoned goods and other
923 amounts identified with the appropriate seizure law 1
924 Court fines 1
925 Increases due to revenue not paid on time 1
926 Other fines, penalties and confiscations 1
930 Tax on profits earned from illicit commercial activities or from 1
Section V. Requirements of the Information System 339

Budgetary
COD_IMP Tax Description (in English)
Category
not respecting the laws regarding consumer protection
931 Other direct tax collection 1
940 Quarterly contribution for financing health services expenses 3
Contribution to health services expenses for domestic tobacco
941 production 5
Contribution to health services expenses for imported tobacco
942 products 5
Contribution to health services expenses for intern alcoholic
943 beverages products production 5
Contribution to health services expenses for imported alcoholic
944 beverages 5
Contribution to health services expenses from publicity activities
945 on tobacco and alcoholic beverages products 5
Quarterly contribution to medications covered from the National
Fund of Health Insurance and from the Ministry of Health's
946 budget, outstanding at 1 October 2011 5
947 Available from cars emission tax 5
950 Income from capitalization of public goods 1
951 Amounts of debt collection from undue rights 1
Income from recovery of court fees, imputations and
952 compensations 1
953 Other incomes from capitalization of assets 1
955 Hedge fund 1
956 Revenue from the recovery of the State Aids 1
Income from expenses recovery incurred in the process of
957 foreclosure 1
960 Payments from salary reduction 1
Income from commission charged by territorial labor
961 inspectorates due until 31 December 2010 1
970 Other income 1
Income from guarantees granted and paid to credit institutions
971 within <PRIMA CASA> program 1
972 Receivables recovered by joint liability 1
981 Refund of budgetary financing of previous years - SB 1
982 Refund of budgetary financing of previous years - BCAS 2
983 Refund of budgetary financing of previous years - BSAN 3
984 Refund of budgetary financing of previous years - BSOM 4
985 Receivables compensation SB 1
340 Section V. Requirements of the Information System

Budgetary
COD_IMP Tax Description (in English)
Category
Receivables compensation CAS (contributions to the social health
986 fund) 2
Receivables compensation CASS (contributions to the social
987 welfare found) 3
Receivables compensation SOMAJ (unemployment
988 contributions) 4
991 Single account for non-residents 5
State budget income collected in the single account, ongoing
992 distribution 9
Social insurance income budget collected in the single account,
993 ongoing distribution 9
Available social insurance and special funds budgets, ongoing
994 distribution 9
Available from amounts collected from deduction (bank/third
995 party) of amounts owned to debtors 1
Available from amounts collected representing financial loss
997 caused and recovered in terms of art. 10 from Law no. 241/2005 5

Legend:
COD_IMP Budgetary Category (in English)
1 State Budget
2 State Social Insurance Budget
3 Health Insurance Budget
4 Unemployment Insurance Budget
Budget of Public Institutions and Activities Financed Fully or
5 Partially of Own Revenue
9 Single account
Section V. Requirements of the Information System 341

ANNEX 3: ANAF’S TEST AND DEVELOPMENT PLATFORM

The test and development server base consists of three sites: (1) the Primary Datacenter,
(2) the Secondary Datacenter and (3) the Data-warehouse.
Each site includes:
1 (one) Modular Computer System Core (#CSC) – HP ProLiant BL660C Gen8 –
including:
 8 (eight) Compute modules (#CSC_CM) implementing a symmetrical multi-
processing (SMP) system based on modern multi-core CPUs, each with 16
(sixteen) active CPU cores (single- and multi thread) in 2 (two) installed
multi-core CPU chips; 256GB RAM installed in at least 2 (two) RAM
modules; 4 (four) I/O fabric ports, supporting universal 1Gbps/10Gbps of
IP/Ethernet and 10Gbps FCoE connectivity, per I/O fabric port.

 Each Computer Module (#CSC_CM) achieves at least 750 (seven hundred

fifty) synthetic CINT2006 SPECint_rate CPU, as measured at factory clock
rate for maximum supported CPU configuration of the compute module and at
least 25 (twenty five) per CPU-core (the per CPU-core CINT2006
SPECint_rate test result value computed by respectively dividing the result for
the tested configuration by the total number of CPU-cores) and at least 17
(seventeen) per thread (the per thread CINT2006 SPECint_rate test result
computed by further dividing, respectively, the result per CPU-core to the
number of threads per core in the tested configuration).

1 (one) Data Storage System Core (#DSC)–NetApp Model FAS8040– providing

data storage, structured and unstructured, and with full server-less data lifecycle
management, including the relevant data high-availability and integrity features;
with 50 (fifty) TB of total raw storage capacity including:
 10 (ten) high-performance SSD drives with a capacity of 200 GB / each.

 50 (fifty) performance-optimized 10K rpm SAS drives with a capacity of 600

GB / each.

 15 (fifteen) higher-capacity 7.2K rpm SAS-NL drives with a capacity of 2.0

TB / each.

 dual 6Gbps SAS internal (drive unit to shelf) back-end I/O paths, per storage
capacity expansion module.

 the unit is expandable to at least 50 (fifty) solid state (SSD) and at least 500
(five hundred) physical hard-disk (HDD) storage drive units concurrently
installed and at least 2000TB storage capacity.

4 (four) Service Controller Modules (#DSC_SCM) – NetApp Model ADPT 2 –

operating as an active-active HA configuration with both data access and control
loop multi-pathing, including the relevant data high-availability and integrity
342 Section V. Requirements of the Information System

features, with 8 (eight) 1Gbps Ethernet ports and 8 (eight) 10Gbps FCoE ports,
per service controller module.
2 (two) I/O Interconnect Fabric Modules (#IFM) – Cisco Nexus 5548UP –
provisioned as pairs of active independent components, to provide with service
and data access multi-pathing respectively.
System software:
 Core Hypervisor Subsystem (#HPS) – VMware vSphere Enterprise
Plus/VMWare ESXi– that implement any x86 32-bit or 64-bit VM without
modifications (except needed drivers), fully licensed for the existing
configuration.

 Application Virtualization Subsystem (#AVS) – VMware vRealize

Automation Enterprise and VMWare vRealize Operations Enterprise –
licensed for the full virtualization platform.

 Virtualization capable operating platform subsystem (#OS) – RedHat Linux –

with symmetrical multiprocessing functions, licensed for at least 32 (thirty
two) processors for x86 architecture and at least 256 (two hundred fifty six)
processors for x86-64 architecture, with the maximum active memory
configurations of at least 64GB RAM for processors with x86 architecture and
at least 2TB RAM for processors with x86-64 architecture, with highly
scalable file systems based on journaling, connections to shared files systems,
via NFS and SMB/CIFS, that supports multi-platform DBMS engines,
including: Oracle RDBMS, IBM DB2, MySQL, PostgreSQL, Hadoop-based
BigData, other relevant functionalities.

 Platform Control Subsystem (#PCS) – VMware vCenter, VMware vCloud

Director; VMware vCloud Networking and Security, NetApp Virtual Cloud
Storage Console – licensed for the above configuration.

 Security Management Subsystem (#SMS) – VMware vClod NSX, and Palo

Alto for NSX.

See diagrams on next page.

Section V. Requirements of the Information System 343
344 Section V. Requirements of the Information System

ANNEX 4: LEGACY SYSTEMS FOR INTEGRATION

ANAF anticipates that the following internal and external systems (operational and technical support systems) will remain as to-be legacy
systems once the RMS is implemented.
Section V. Requirements of the Information System 345

Applic a tio ns in the func tio na l a re a o f the RMS (Re ve nue Ma na g e me nt S ys te m), e xpe c te d to be re pla c e d Applic a tio n tha t ne e d inte ro pe ra bility with the RMS
func tina l do ma in Out-o f-s c o pe (no c ha ng e s e xpe c te d)
AN AFI AVIZEG PATRIMVEN
SACF-
VECTOR (Vector
ARHEL DECIMP FmAsistenta Raportare WEBCAUTARE WEBFMSESIZARI WEBSMS MGMTID Banca Mondială PresaMFP AGCABTREZ EMIRAP UCASMFC
fiscal)
Arierate
SACF-Restanțe WEBINACTIV_REA
ARTHEMIS DeclMF IN ACTIVI Verif088 WEBCAZIERFISCAL WEBSTARED112 RSalvarilor BAZATVA RAPINF Ag e nd a ECOFIN EMTITLURI UCVAP
raportare CTIV

WEBINREGADMIN
WEBSTATICHTMLR
AUDIT ACVILA INFOPC SAIVEN WEB_CODFISC WEBCERTSPV TERTEINSTIT SEP CCANAF RAPOARTE AgendaTrez EULICENTE URMFMI
ENDER
(primarii, banci, ...)

BILDEC ACA INFOPLUS SERADA+E18 WEB_BILANT WEBCOMUNICAREARB WEBINREGD112PF WEBWSTAM CCN/CSI Regtaxe ALOP Evenituri WEB_ANTREP
CAMELEON DECLWEB LITIGII SERADN WEB_PUBNOMEN WEBCONCURSURI WEBINREGD112PJ CHAT_CERTIF AGMON EVIDSTOC
CAZIER (ASISCAZ, WEBINREGD112Re
DECSEN MB SIDOC WEBAFISBUNPRIVATE WEBDECL WEBNOTIF Ctranzitoriu TAXEDIV ANAVI EXEFIN WEB_BUGET
INTCAZ, ELCAZ) prezentant
WEBAFISBUNSECHEST
CITARH DEDECER MONS1001 S1001 WEBDECLFIZICE WEBINREGSPV WEBNOUTATI WEBTRAFIC DARSAM Anexa31 WEB_CAP
RATE
DEDOC(
denumnire WEBINREGUTILIZT
CITER NOMEN SIAC WEBAFISSEDIU WEBDECONT WEBNREVIDENTA WEBTVAUE HelpDesk TB ANGAJ WEB_PETITII-MFP
vecheDEC_UNK ERTEINSTIT
(DECUNK))
CITMIN DOBROUE PHOENIX – SI SIAD WEBAGSPV WEBDECUNCAF-agent afisare WEBIST318 WEBPATRIM WEBVIZBIL HLPDSK TREZOR ANGCON GARANTII BANCARE WEBANRP
WEBANUNTACTEFISC
CITNOPROC DOBUERO PLA – SI SIARC WEBDECUNCREC-agent recipisa WEBISTONRC WEBPERISABILE WEBRobotD112 INDFIN VIES ANGLEG GFTC-VIEWER WEBEVIDAVIZE
ALE
WEBRAPOARTEPA
CLIBANCI DWAIF RAMBNETP SOLCON WEBAPROBASPV WEBDECUNCUP-agent upload WEBJOCURI WEBRSSMFP INTERNET VoeS BUGCASH GSRS WEBEVIDPROC
TRIMVEN
WEBLISTAANGAJA WEBSCHIMBAR WEBINREGADMINFORE
C-LYNX DWANAF RCNG-PF TAXA AUTO Mo nito r_ S P WEBDECUPLOAD WEBRAPSPV LOTOBONO BUGDEF IBANCLS WEBPUBL
TI B XE
CODTVA DWCNPAS RCNG-PJ TAXA_AUTO WEBDOCSECURITATE WEBLOTONRC WEBREINNOIRE LOTUS DOMINO WEBAUDIT BUGETNG V2 IMPATRIM WEBPUBMFP
REGSEDIU TAXA_AUTO
COMERT DW-D394 S AN CT _ IN T WEBEDITPSPV WEBMDX WEBRESTANTE M1SS WEBBILANT-AG BUGETNG_V3 MODIFNERAMB (MODIF) WEBRAP
(REGADRESE) Restituire
RESTANTE
CONDOR DWDECONT (RESTANTE TRIDENT Ce rtific a te _ re zid e nta WEBENERGIE WEB-MINIMIS WEBRESURSE MOFICIAL WEBBSC BUGETNG_V1 MONPERS WEBSITEMFP
FISCALE)
SACF-Form 01-
04
CONTABCR DWGFTC VATRefund WEBEXTRASE WEBMON WEBRGPITVA Nomen_FOREXEBUG WEBBUGETUPDATE BUGLOC OMF WEBSITEUPDATE
Monitorizare
contribuabili
CONTRACT_NRZ(CONT DWIND SACF-Rapoarte WEBRGPITVAINCA
WEBFMASIST ONIX WEBCASEMARCAT BUG-NERAMBR OPFV WEBSWISS
R_NEREZ, Contractnrz) (PRELIND) colectare SARE
WEBTaxe BUGPRO OPTT WEBSWISSUPDATE
WEBTHEMES CAP PATRIM WEB-UCASMFC
WEBTREZOR Carmonizare PEAG WEBZIARISTI
Total number of applications: 140 Total number of applications: 37 CASHBNR PRESTAJ
D ro p (o b s o lite a p p lic a tio ns , e ithe r s us p e nd e d , e ithe r ina c tiv e ) Re ta ine d a pplic a tio ns (no c hna g e s a re e xpe c te d) CENTRALIZTT PREV - SI Documente DGE
INACTIV WEBVOES APLICATII DECLSEN MODAF ProceduriMFP DocDGTDP
CONTABPRE_ACP
MUTDOSAR AP LICROL DECLPORTAL MOFICIAL_0 REGDAT DOCOPCP
(Contabpre)
CENTRBIL &
CONTABPRE_OPCP
SALARII FOX INTBIL & ARH_BD ORDINE-MFP-ANAF SCCFI DocUEMFP
(Contabpre)
INTBILCAZ
STIM BIBLIOTECA COOP PRIME CREDPRIV SITFIN_NG DOTARE
E-MAIL
BILANT/ASISBIL ProceduriANAF CREDLOC STAFCT
TREZORERIE
UTILITAR BOMGAR RActivitate DCREDITE STAMOD EMICERT
CIRCANAF SPIN De ciziile CFC STAMURI MASREP
CJCE TELEFONIE MOBILA DEPBAN STAR MONINV
CONTAB WEBANUNTACHIZITIE DEPTERM STAREC TEMADOC
CPF WEBGENRI DESCRED Statef_L330 TEMADOC_2
DECLAVERE WEB-Moodle DMFAS STATEF186 TRAFIC_CONTROL
STRUCONTAB_ACP STRUCONTAB_ACIS_AM
DOCBCL TRANSFER TREZCEN
N o te : Ga nd to ta l numb e r o f a p p lic a tio ns : 323 (Contabstru) (Contabstru)
STRUCONTAB_ACIS_BEN
DocDecl FOREXEBUG SWIFT TRZCENTT
Ap p lica tio n na me This a p p lica tio n is ina ctive o r s us p e nd e d Ap p lica tio ns in the functio na l a re a o f the RMS 140 (StructBen, ContabBen)
Ap p lica tio n na me This a p p lica tio n is und e r imp le me nta tio n (a s o n J uly 2015) Dro p e d a p p lica tio ns 9 DOCGF FOREXEBUG_LOTUS
Ap p lica tio n tha t ne e d inte ro p e ra b ility with the R MS 37 DocLib EvRiscAplicatii
Ap p lica tio ns to b e re ta ine d 37 E-Learning FF_2009
EMCS_RO (are beneficiari
INFDGTI
Ap p lica tio ns o ut o f s co p e fo r the RMS 100 ANAF si MFP)
EMCS_RO (are beneficiari MAEC (nagios,
ANAF si MFP) NetDisco, etc.)
MANUALE
Total number of applications: 9 Total number of applications: 37 Total number of applications: 100
346 Section V. Requirements of the Information System

External Systems and Interfaces that need interoperability with the new Revenue Management System
Appli
catio Amount
Amount
n of data Asessment
Go of data Datab
App. Owne Implement App Build on/in exchang Database regading the
Description - EN Live Web Enabled Operating System exchang D.B. Datasource ase No. of Users
CODE - r ation type State Technology ed - Name integration wi
at: ed - Size
Adopted (instit transmit the RMS
received
ution ed
)
NAME DESCRIPTION                              
                                 
AVIZEG Electronic archive of real estate guarantees. ANAF Centralized 2009 Active Portalized AIX 5.2, Windows Client -server     Oracle11g Oracle RAC ORACENTR. mfol.dgti.ro 30,11 2130 Interoperabilit
XP(terminale), 11.2.0.3 GB check real esta
The management of real estate collateral approvals WINDOWS 8 -ORACENTR guarantees in t
consists in issuance and consultation of statistical register, web
reports for different opinions and in the management service availab
of specific lists management

BANCA- BANCA MONDIALA (world bank) database is a MFP Centralized 2008 Active Not portalized MS Windows Server Client -server     Lotus Domino   Lotus Domino Application 61 30 Interoperabilit
MONDIA document management system resulting from the 2003 MB move docume
LA World Bank project, BM-P0623 "Technical assistance from one
for enhancing IT systems for Treasury, public workflow to
accounting and budget management another, in th
Document
Managemen
System
BAZATVA The application addresses to the Coordination Unit of MFP Distributed   Active Not portalized         Visual Fox Pro and   Application deployed     Interoperabilit
budgetary relations directorate with the European Lotus Domino WebSphere Portal, WebSphere check registe
Union and IT Directorate. Application Server information
regarding
The application allows getting some cases necessary companies fo
for the calculation of the VAT base, the structure of VAT purpose
economic agents on CAEN branches - with the
turnover of between 10,000 and 35,000 euros for
individuals.

CCANAF ANAF Call Center ANAF     Active   Windows Server 2008 client - server         Application deployed   Internal users: 12 Interoperabilit
Enterprise Edition SP2 , WebSphere Portal, WebSphere main agents (10 call center logi
The application provides grant assistance to taxpayers Linux Apache Application Server active and 2 in and access to t
by telephone (call center). reserve) and 11 System On Lin
agents Level 2 in Help
the contract
center; External
Users: any tax
payer
CCN-CSI Common network of communication ANAF     Active   AIX 5.3 Web-based         Application deployed   3 000 Interoperabilit
WebSphere Portal, WebSphere messages
The application provides message exchange between Application Server exchange wit
national administrations of the member states. the other
member state
via the CCN-C
Network of DG
CHAT_CE Certification Authority – ANAF v2 ANAF Centralized   Active Not portalized MS Windows Server Client-server si Web-     Lotus Domino   Application Domino 150 30 Interoperabilit
RTIF 2003 based CHAT/mfinante.ro MB the NAFA
The application is used for the issuance, revoking and Internal
management of unqualified certificates for their NAFA certification
and MFP staff, central and from the region, in order to authority; to b
have secure access in the intranet and internet portal. integrated in t
Identity and
Access
Managemen
tools
CTRANZIT Payment of taxes paid through banks (for individuals) MFP Centralized 2011 Active Not portalized AIX RISC Web-based 20MB 30MB Oracle 10g 10.2.0.5.0 TRZP   8GB 20 Interoperabilit
ORIU file exchange
Section V. Requirements of the Information System 347

Appli
catio Amount
Amount
n of data Asessment
Go of data Datab
App. Owne Implement App Build on/in exchang Database regading the
Description - EN Live Web Enabled Operating System exchang D.B. Datasource ase No. of Users
CODE - r ation type State Technology ed - Name integration with
at: ed - Size
Adopted (instit transmit the RMS
received
ution ed
)
NAME DESCRIPTION                              
                                 
DARSAM IT Application processes forms regarding the financial MFP Centralized   Active Not portalized AIX       Oracle         Interoperability -
statements of public institutions of central and local data exchange
administration. based on Adobe
intelligent forms
HELPDES The application is a dispatcher for technical assistance ANAF     Active   Windows 2003 Server Client-server             Internal users: the Interoperability -
K in ICT for all MFP and NAFA employees. Std Ed şi Linux Apache 3 helpdesk agents; access the
external users: System's On Line
any employee in Help
any location of the
MPF and NAFA
HLPDSK The application collects on 2 channels of ANAF Centralized 2006 Active Not portalized MS Windows Server Client-server     Lotus Domino HelpDesk Lotus Domino Application 36 50 Interoperability -
communication, e-mail and phone, user complaints on 2003 MB access the
the operation / non-operation informatic system, in System's On Line
terms of office equipment, network, communications Help
and applications service.

INDFIN Application of reporting financial indicators in the ANAF Centralized   Active Portalized AIX technology WEB     Oracle11g dwrac. Oracle RAC 11.2.0.3 - DWRAC 2,7 4000 Interoperability -
national economy. The application allows access to fiscnet.ro Gb statististical data,
various financial indicators extracted from the balance (occu file exchange,
sheets submitted by economic agents. The access can pied data extraction,
be made at the level of an economic agent or at the space MIS
aggregate level on CAEN codes. expan
ds
The economic agents enrolled in this application are each
companies that have filed / lodged balance sheet date year)
since 2008.
LOTOBO Receipts Lottery ANAF Centralized 2015 Active Portalized   web-based     Oracle 11g LOTOBONO Oracle RAC 11g (11.2.0.4) 400 700 Interoperability -
NO Mb/a file exchange
n

M1SS M1SS system is intended to support companies ANAF Centralized 2015 Active Portalized Red Hat Enterprise Web-based, three tier     Oracle 11 g Release 2 M1SS Oracle 11g - MISS 5 GB 45 users Interoperability
providing electronic services, telecommunications, Linux Server release 6.4 (m1ssproddb.c
broadcasting and television. It allows companies to pd.fiscnet.ro)
register, submit statements and pay VAT due to
Member State of Consumption via the web portal
provided by the Member State of identification
(usually the Member State in which the company has
established economic activity).

Using M1SS is optional and addresses both activity-

based companies in the EU (EU scheme) and those
established outside the EU (non-EU scheme).

VoES Scheme (VAT on E-services) which is already

operational, available to providers of electronic
services outside the EU, is replaced with M1SS.
348 Section V. Requirements of the Information System

Appli
catio Amount
Amount
n of data Asessment
Go of data Datab
App. Owne Implement App Build on/in exchang Database regading the
Description - EN Live Web Enabled Operating System exchang D.B. Datasource ase No. of Users
CODE - r ation type State Technology ed - Name integration wi
at: ed - Size
Adopted (instit transmit the RMS
received
ution ed
)
NAME DESCRIPTION                              
                                 
MOFICIAL The application allows the viewing of information in MFP Centralized   Active Portalized MS Windows Server Client-server si Web-     Lotus Domino Official Gazette Lotus Domino Application 26 10 editors and Interoperabili
the Official Gazette - normative documents published 2003 based MB unlimited number
in the Official Gazette Part IV. of readers
NOMEN_ It represents an extension of the general ANAF Centralized   Active Portalized AIX Technology web     Oracle 11g ORACENTR.mfo Oracle RAC 11.2.0.4 - 1Gb 20 Interoperabilit
FOREXEB nomenclature (NOMEN) - Managing nomenclatures l.dgti.ro ORACENTR along webservice
UG for BUDGET ACTIVITY / TREASURY FOREXEBUG with integration, t
NOM access all the
EN nomenclateurs
ANAF

ONIX The application is a informatics system for managing ANAF Centralized 2006 Active Portalized AIX Web-based     Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 5039 367 Interoperabilit
the personnel and Human Resources mfol.dgti.ro -ORACENTR MB file exchange a
web service

PresaMF REVISTA PRESEI MFP DataBase stores news articles MFP Centralized 2008 Active Portalized MS Windows Server Client-server     Lotus Domino Revista presei Lotus Domino application 7.5 - 10 for editing Interoperabilit
P related to the activity of Ministry of Finance. 2003 MFP MB - all MPF and read only via w
NAFA staff for service
consultation
RAPINF Manages information reports about the achievement ANAF Centralized 2013 Active Not portalized MS Windows Server Client-server     Lotus Domino Rapoarte de Lotus Domino application 625 80 Interoperabili
of indicators related to work performed by DGRFPs. 2003 Informare MB
RAPOART Budget execution related ANAF reports MFP Centralized 2012 Active Portalized AIX RISC Web-based 50MB 100MB Oracle 10g 10.2.0.5.0 TRZP Application deployed 8BG 60 Interoperabili
E WebSphere Portal, WebSphere
Application Server
Regtaxe Register of fiscal and non fiscal duties MFP No 2008 Active Not portalized AIX client server - loading N/A N/A Oracle 11g dwrac dwrac 900M 1 user for data Interoperabili
data part; load, max 100
web - searching data concurrent users
part
TAXEDIV Management of taxes collected in cash collection MFP Distributed 2002 Active   Windows 2000, client-server 30MB N/A Oracle 8i, Oracle 8.05 TAXEDIV Application deployed   min 5 users / each Interoperabili
points located in treasury operative units within DGFP Windows technology WebSphere Portal, WebSphere cash-in point
XP(Workstations) Application Server
TREZOR Buyouts OPT, payment shall barcode sheets, collected MFP Centralized 2004 Active Not portalized Windows 2000, client-server 30- 30-50MB Oracle 8i TREZOR Application deployed 20- around 5000 users Interoperabili
daily errands, taking control, confirmation documents, Windows XP technology 50MB WebSphere Portal, WebSphere 30GB
taking monthly fees, updating and various operations, Application Server
analytical accounts nomenclature, calculation and
distribution IVG share, calculation and takeover
interest
VIES VIES – VAT Information Exchange System ANAF Centralized   Active Portalized Linux RedHat 3 AS Web-based, three tier     Oracle CLO Application deployed 100 800 users Interoperabili
(VIES_DB) WebSphere Portal, WebSphere GB
Application Server
VoeS VoeS – VAT on e-Services ANAF Centralized   Active Portalized MS Windows Server Web-based     Oracle   Application deployed   16 Interoperabili
Section V. Requirements of the Information System 349

Appli
catio Amount
Amount
n of data Asessment
Go of data Datab
App. Owne Implement App Build on/in exchang Database regading the
Description - EN Live Web Enabled Operating System exchang D.B. Datasource ase No. of Users
CODE - r ation type State Technology ed - Name integration with
at: ed - Size
Adopted (instit transmit the RMS
received
ution ed
)
NAME DESCRIPTION                              
                                 
(Will 2000 WebSphere Portal, WebSphere
be Application Server
replac
ed
entire
ly by
M1SS
)
WEBAUDI Auditors Register based on HG 1259/2012 MFP     Active www.mfinant           AUDIT Web application on JBOSS     Interoperability
T e.ro
WEBBILA Balances - Update Agent MFP Centralized   Active Portalized                   Interoperability
NT-AG
WEBBSC Balanced Scorecards - Dashboard MFP     Active Intranet           TABBSC Web application located on   150- Interoperability
JBoss server
Contact: Dorina Andrei
WEBBUG Displaying information on Budget Website MFP     Active www.mfinant           BUGET Web application on IBM WAS     Interoperability
ETUPDAT e.ro
E
WEBCASE Cash Register authorizations Register MFP     Active Portalized           casedemarcat Web application on JBOSS     Interoperability
MARCAT
WEBTaxe Fiscal and non fiscal duties register MFP     Active www.mfinant           TAXE Web application on IBM WAS     Interoperability
e.ro
WEBTHE Applications for themes customization related to the ANAF   2015 Active Portalized             Does not use any data source     Interoperability
MES Internet portal, Intranet and Extranet (skins, banners,
horizontal menu, vertical menu)
WEBTREZ Reports for Treasury excerpts MFP Centralized   Active Portalized AIX       Oracle 11g   Oracle RAC 11.2.0.3 - DWRAC     Interoperability
OR
PATRIMV It contains documents related to PATRIM application ANAF                           Interoperability
EN deployment. The application can be used by members
of a group, depending on the interests and rights of
access granted. Beneficiaries Control Department,
Legal Department, any individual or company
TB The app shows in real time the evolution of revenues MFP                           Interoperability
to the state budget by the Treasury.
WEBINRE The enrollment of system administrators for MFP       Portalized                   Interoperability
GADMIN FOREXEBUG
FOREXE
350 Section V. Requirements of the Information System

Internal Systems and interfaces

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
   
DECLWEB Tax returns submitted electronically - Taxpayers ANAF Distributed N/A Active Portalized N/A
Assistance Programs for completion, validation and
signing electronic returns; Errors Validation of PDFs. Tax
returns submitted electronically - which are PDFs

WEB_ANTREP Warehouse keeping publishing MFP Centralized Active Portalized

WEB_BILANT Optimized display of balance data MFP Active

WEB_BUGET Budget Website MFP Active Portalized

WEB_CAP Public Procurement Control MFP Centralized Active Portalized

WEB_CODFISC Displaying fiscal data on the MFP site MFP Centralized Active Portalized

WEB_PETITII-MFP Submitting petitions on MFP Website MFP Active Portalized

WEB_PUBNOMEN Publishing of nomenclatures MFP Active Portalized

WEBAFISBUNPRIVATE Selling property owned by the state ANAF 2015 Active Portalized

WEBAFISBUNSECHES Selling of seized goods ANAF 2015 Active Portalized

TRATE
WEBAFISSEDIU Application for displaying tax office units ANAF 2015 Active Portalized

WEBAGSPV Agent for individuals Users activation in SPV ANAF 2015 Active Portalized

WEBANRP Application for securities compensation payment ANRP MFP Active Portalized
Section V. Requirements of the Information System 351

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
WEBANUNTACHIZITIE Announcements for Procurement of goods and services ANAF 2015 Active Portalized

WEBANUNTACTEFISC Notifications for fiscal administrative acts ANAF 2015 Active Portalized
ALE
WEBAPROBASPV SPV Users Approval ANAF 2015 Active Portalized

WEBAUDIT Auditors Register based on HG 1259/2012 MFP Active www.mfinante.ro

WEBBILANT-AG Balances - Update Agent MFP Centralized Active Portalized

WEBBSC Balanced Scorecards - Dashboard MFP Active Intranet

WEBBUGETUPDATE Displaying information on Budget Website MFP Active www.mfinante.ro

WEBCASEMARCAT Cash Register authorizations Register MFP Active Portalized

WEBCAUTARE Search Engine Application ANAF 2015 Active Portalized

WEBCAZIERFISCAL Fiscal Record Transmission ANAF 2015 Active Portalized

WEBCERTSPV Subscribe and Edit User Profile and digital certificate ANAF 2015 Active Portalized
owner to Virtual Private space
WEBCOMUNICAREAR ARB Communications ANAF 2015 Active Portalized
B
WEBCONCURSURI Competitions / Raffers ANAF 2015 Active Portalized

WEBDECL Filling in legal statements ANAF Active Portalized

WEBDECONT Rezolving expense account ANAF Active Portalized

WEBDECUNCAF-agent Display NAFA statements application MFP Active Portalized

afisare
WEBDECUNCREC-agent Generation of check NAFA statements application MFP Active Portalized
recipisa
WEBDECUNCUP-agent Submission of NAFA statements application MFP Active Portalized
upload
352 Section V. Requirements of the Information System

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
WEBDECUPLOAD Transmission of on-line electronic returns ANAF 2015 Active Portalized

WEBDOCSECURITATE Security Documents ANAF 2015 Active Portalized

WEBEDITPSPV SPV Users Profile Edit ANAF 2015 Active Portalized

WEBENERGIE List of taxpayers who filed D089 on their own. ANAF Active Portalized

WEBEVIDAVIZE Evidence of legal opinions MFP Active Portalized

WEBEVIDPROC Register of MFP Processes MFP Active Portalized

WEBEXTRASE Web Service for transmission of Treasuries excerpts ANAF 2015 Active Portalized

WEBFMASIST E-Mail Assistance ANAF 2015 Active Portalized

WEBFMSESIZARI Form for complaints ANAF 2015 Active Portalized

WEBGENRI Inventory numbers generator MFP Active Portalized

WEBINACTIV_REACTI Taxpayers registry active / inactive ANAF Centralized Active Portalized

V
WEBINREGADMINFOR FOREXEBUG system administrator enrolments MFP 2015 Active Portalized
EXE
WEBINREGADMINTER PATRIMVEN system administrator enrolments ANAF 2015 Active Portalized
TEINSTIT (primarii,
banci, ...)
WEBINREGD112PF Users Registration for returns submitting - individuals ANAF 2015 Active Portalized

WEBINREGD112PJ Users Registration for returns submitting - companies ANAF 2015 Active Portalized

WEBINREGD112Repreze Tax representative registration ANAF 2015 Active Portalized

ntant
WEBINREGSPV Registration for individuals users in SPV: Register users, ANAF 2015 Active Portalized
users Lost SPV password , SPV credentials Recovery,
Change SPV users email
WEBINREGUTILIZTER Users Registration for PATRIMVEN and ARB systems ANAF 2015 Active Portalized
TEINSTIT
Section V. Requirements of the Information System 353

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
WEBIST318 History for 318, 319 returns ANAF 2015 Active Portalized

WEBISTONRC History for ONRC associates / shareholders ANAF 2015 Active Portalized

WEBLISTAANGAJATI Employee list ANAF 2015 Active Portalized

WEBLOTONRC ONRC batch transmission ANAF 2015 Active Portalized

WEBMDX Massive data exchange with Public Institutions ANAF 2015 Active Portalized

WEBMON Site monitorization MFP Active www.mfinante.ro

WEB-Moodle Development and sustain courses on e-learning Moodle MFP Active Yes
platform
WEBNOTIF Notifications ANAF Centralized Active Portalized

WEBNOUTATI Display of news on ANAF internet portal ANAF 2015 Active Portalized

WEBNREVIDENTA Generation of payment evidence number under ANAF ANAF 2015 Active Portalized
Order 1870/2012
WEBPATRIM Public institutions assets publishing on MFP website MFP Active Portalized

WEBPERISABILE Capitalization of perishable goods ANAF 2015 Active Portalized

WEBPUBL Publish portal documents MFP Active Portalized

WEBPUBMFP MFP Website publishing MFP Active Yes

WEBRAP Activity report application MFP Active www.mfinante.ro

WEBRAPOARTEPATRI Displaying reports for PATRIMVEN system, views for ANAF 2015 Active Yes
MVEN building sites, Contributions, lands, vehicles, Banks
WEBRAPSPV Reports for Virtual Private space approvals ANAF 2015 Active Portalized

WEBREINNOIRE Qualified certificates renewal ANAF 2015 Active Portalized

354 Section V. Requirements of the Information System

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
WEBRESTANTE Past due obligations to the budgets ANAF Active Portalized

WEBRESURSE Resource loading application for ANAF internet portal ANAF 2015 Active Portalized

WEBRGPITVA Register for taxable persons registered for VAT purposes ANAF 2015 Active Portalized

WEBRGPITVAINCASA Register of taxable persons applying VAT on collection ANAF 2015 Active Portalized
RE system
WEBRobotD112 Monitoring submission of online statements MFP Active www.mfinante.ro

WEBRSSMFP RSS Feed application for MFP website ANAF 2015 Active Portalized

WEBSCHIMBARB ANAF-ARB Information Exchange Application ANAF 2015 Active Portalized

WEBSITEMFP MFP Website MFP Active www.mfinante.ro

WEBSITEUPDATE Website information publishing application MFP Active www.mfinante.ro

WEBSMS Data access via SMS at 1300 number ANAF 2015 Active Portalized

WEBSTARED112 Returns state viewing ANAF 2015 Active Portalized

WEBSTATICHTMLREN Display information on ANAF internet portal ANAF 2015 Active Portalized
DER
WEBSWISS Site Swiss-Contribution MFP Active www.mfinante.ro

WEBSWISSUPDATE Publish information on the Swiss-Contribution website MFP Active www.mfinante.ro

WEBTaxe Fiscal and non fiscal duties register MFP Active www.mfinante.ro

WEBTHEMES Applications for themes customization related to the ANAF 2015 Active Portalized
Internet portal, Intranet and Extranet (skins, banners,
horizontal menu, vertical menu)
WEBTRAFIC Application for tax codes querying MFP Active Intranet/internet

WEBTREZOR Reports for Treasury excerpts MFP Centralized Active Portalized

Section V. Requirements of the Information System 355

App. CODE - Adopted Description - EN Functional Domain Implementation Go Live App Web Enabled Version
(institution) type at: State control
NAME DESCRIPTION - - - -
WEBTVAUE Submitting declarations for VAT repayment from EU ANAF Centralized Active Portalized

WEB-UCASMFC Central Harmonization Unit application of Financial MFP Active Intranet

Management and Control System
WEBVIZBIL Show balances attachments ANAF 2015 Active Portalized

WEBVOES Web application to access VOES application using MFP MFP Portalized
site.
WEBWSTAM web service for registering users in TAM ANAF 2015 Active Portalized

WEBZIARISTI Journalists accredited by the MFP MFP Active Portalized

WEBDECLFIZICE Individuals submitting returns ANAF Portalized

WEBINREGADMINFOR The enrollment of system administrators for MFP Portalized
EXE FOREXEBUG
WEBINREGADMINTER Registration for system administrators for ARB and ANAF Portalized
TEINSTIT (city halls, PATRIMVEN
banks, ...)
WEBINREGUTILIZTER Registers users for the systems PATRIMVEN and ARB ANAF Portalized
TEINSTIT
WEBJOCURI Application publishing gambling information MFP Portalized
WEB-MINIMIS Deposit MINIMIS funding requests MFP Portalized
356 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
       
ACA The application will have the capability to keep the evidence of roles of       RMS
information applications. In the same time ACA is a recording system of
possible roles to access the computer applications made in DGTI by the MFP
internal operators as well as by external ones. Will replace APLICROL
application.
AGCABTREZ The CABINET AGENDA TREZORERIE database is a management system Lotus Agenda Cabinet Lotus Domino. Out of scope
for meetings and meeting minutes from Secretary of State Cabinet 4 Domino Trezorerie BUC31A/SERVER/MFINANTE
AGENDAECOFI DGP Ecofin and Communitary Assistance activities calendar Lotus Agenda ECOFIN Lotus Domino Application Out of scope
N Domino
AGENDATREZ Treasury meetings and meeting minutes management system Lotus Agenda Trezorerie Lotus Domino Application Out of scope
Domino
AGMON Retrieval, verification, information of the monitored economic entities       Out of scope
centralization System according to GEO 79/2001 Making the interface
between Oracle and Excel by exporting and importing data in Oracle
predefined layouts Monetary Fund.
ALOP Commitment accounting based on OMFP 1792 / 2002 Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Out of scope
mfol.dgti.ro -ORACENTR
ANAFI Scope of the application is to assist the taxpayer on fiscal issues. ANAFI is a Lotus ANAFI Lotus Domino Application RMS
knowledge base to assist taxpayers with questions and answers on tax issues. Domino
View information from the base can be made through the browser. The base is
located on a central server and it is possible to access for users who have a
Lotus-desktop client installed on their computer, connection to MFP network
and access rights granted by the manager (administrator) basis.
ANAVI Managing normative acts issued in MFP and those developed by other Lotus Acte elaborate / Lotus Domino Application Out of scope
institutions (other issuers) and entered into the MFP to be approved for Domino avizate de MFP
publication in the Official Gazette
ANEXA31 IT Application managing the situation of holding direct / indirect shares / Microsoft ANEXA31MIN Visual Fox Pro Out of scope
shares, by the administrative authorities (city halls) at economic operators. Visual Fox
Pro 6.0,
transmitted
via
LotusNotes
(Lotus
Domino)
ANGAJ engagement, settlement, authorization and payment of public institutions       Out of scope
expenses, and organizing, recording and reporting of budgetary and legal
commitments (O 1792/2002)
ANGCON Evidence of commitments, contracts and payments, check payments matching       Out of scope
in contracts and contracts in allocations, based on funding sources
ANGLEG Evidence of legal commitments under OMPF 1792/2002 Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Out of scope
mfol.dgti.ro -ORACENTR
APLICATII- This service allows the user to have a record of IT applications built and used Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Retain
ANAF in the DGTI MFP and ANAF system mfol.dgti.ro -ORACENTR
Section V. Requirements of the Information System 357

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
APLICROL Information system for keeping the evidence of roles of information Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Retain
applications mfol.dgti.ro -ORACENTR

APLICROL is a recording system of possible roles to access the computer

applications made in DGTI by the MFP internal operators as well as by
external ones.
ARH_BD The application allowed the retrieval of performance indicators from 2008       Retain
through to commissioning production warehouse platform. Stored documents
should be filed. The application is no longer used today. Documents should be
filed, then the application can be deleted.
ARHEL Electronic archive DB2 Arhiva electronica DB2 - driver type: 4, database RMS
name: ICMNLSDB, server
ARHEL is a functional pilot of centralized electronic archive MEF-NAFA, name: 10.254.250.66 port: 50000
respecting legislation on archiving electronic documents (Law 135/2007 and
other related acts). Based on this analysis, the current data model is built
mainly for archiving electronic returns filed by taxpayers.
ARTHEMIS Risk analysis information system Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS

ARTHEMIS is a risk management system to achieve an equal treatment / fair

for the taxpayers, to focus audit on economic agents with "real" non-
compliance, to allocate the resources according to risk levels; It is used by the
units / departments responsible for tax audit and controls to individuals or
legal entities.
AUDIT Specific documents of audit activity Lotus Audit Lotus Domino Application RMS
Domino
The application stores and manages specific audit documents. The users are
authorized persons from DG Internal Audit and DGFP within the counties.
AVIZEG Electronic archive of real estate guarantees. Oracle11g Oracle RAC ORACENTR. mfol.dgti.ro Interoperability
11.2.0.3
The management of real estate collateral approvals consists in issuance and -ORACENTR
consultation of statistical reports for different opinions and in the management
of specific lists management
BANCA- BANCA MONDIALA (world bank) database is a document management Lotus   Lotus Domino Application Interoperability
MONDIALA system resulting from the World Bank project, BM-P0623 "Technical Domino
assistance for enhancing IT systems for Treasury, public accounting and
budget management
BAZATVA The application addresses to the Coordination Unit of budgetary relations Visual Fox   Application deployed Interoperability
directorate with the European Union and IT Directorate. Pro and WebSphere Portal, WebSphere
Lotus Application Server
The application allows getting some cases necessary for the calculation of the Domino
VAT base, the structure of economic agents on CAEN branches - with the
turnover of between 10,000 and 35,000 euros for individuals.

BIBLIOTECA- International Cooperation Department has requested an application / database Lotus   Lotus Domino Application Retain
358 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
COOP to enable storing, updating, viewing, management of relevant documents, of Domino
various types.
BILANT/ASISBI Application for processing of financial statements Xbase   PDF intelligent + CLIPPER Retain
L
The application is developed in CLIPPER and it is used by DGTI NAFA,
AFPs, county DGFPs, ONRC and taxpayers. ASISBIL - Assistance
application for retrieving electronic economic balances -starting with
31.12.2003, the economic agents have to submit financial statements on
magnetic media support or on the Internet.
BILDEC BILDEC application displays inconsistencies between data from the annual Oracle 11g   Oracle RAC 11.2.0.3 - DWRAC RMS
financial statements compared to those recorded in the returns.
BOMGAR Technical assistance to workstation users of the MFP / ANAF       Retain
BUGCASH BUGCASH application (Law on State Budget - cash) provides draft budget of       Out of scope
the state budget, state social insurance budget and the national budget for
health insurance. It addresses the principal loan, DGIT DG budgetary
planning, budgetary policy DG. Software application for drafting budget laws
(law on state budget, state social insurance budget law, the budget of
unemployment, sole national health budget).
BUGDEF BUGDEF application (breakdown by quarters of the approved budgetary       Out of scope
provisions) ensures the development of the Quarterly breakdown of the draft
budget of the state budget, state social insurance budget and the national
budget for health insurance.
It addresses the principal loan, DGIT DG Budget programming, D. G.
Budgetary policies. Software application for drafting budget laws (law on state
budget, state social insurance budget law, the budget of unemployment, sole
national health budget).
The application has been developed in Visual Fox, and the detailed process
data from the principal loan from central government. Application information
is used for budgeting and the state treasury. BUDGET local network computer
application uses the MFP. During the budgeting, several variants of the budget
can be developed. To get the Annexes of budget laws the following steps must
be made: - data acquisition, verification based on correlations and in
proprietary catalogs, data centralization, editing and publishing preparing final
reports. Computer application uses lists of general interest that relate to
financial indicators (budget classification) and the main credit. From the
database input for Budget Evidence application is drawn.
BUGETNG_V2 It addresses the principal loan, DGIT DG Budget programming, D. G. Oracle 10g     Out of scope
Budgetary policies. Software application for drafting budget laws (law on state
budget, state social insurance budget law, the budget of unemployment, sole
national health budget).
BUGETNG_V3 The application has been developed in Visual Fox, and the detailed process Oracle 10g     Out of scope
data from the principal loan from central government. Application information
is used for budgeting and the state treasury. BUDGET local network computer
application uses the MFP. During the budgeting, several variants of the budget
can be developed. To get the Annexes of budget laws the following steps must
Section V. Requirements of the Information System 359

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
be made: - data acquisition, verification based on correlations and in
proprietary catalogs, data centralization, editing and publishing preparing final
reports. Computer application uses lists of general interest that relate to
financial indicators (budget classification) and the main credit. From the
database input for Budget Evidence application is drawn.
BUGETNG_V1 Drafting budget laws in Oracle technology. The information system contains Oracle 10g     Out of scope
the following software applications, managed through a common application
menu: cash budget; programs budget; states of functions
BUGLOC The application for initial draft local budgets broken down by quarters Visual Fox     Out of scope
Pro, Lotus
Domino
BUG- The application allows uploading data, updating and annexes listing       Out of scope
NERAMBR 4,5,20,21,22,23,24, and 25 for the 2010 budget revision Annexes 4 and 5 meet
foreign funded programs repayable according to EO No.64 / 2007. Annexes
20 and 21 correspond to projects financed from external grants accession,
donors and other tools / post-accession funds. Annexes 22,23 and 24
correspond to projects funded under the Cohesion Policy of the EU Common
Agricultural Policy and Fisheries, facilities and post-accession instruments.
Appendix 25 corresponds programs under the EU Cohesion Policy, the
Common Agricultural Policy related programs and Fisheries, other programs
financed by external funds post-accession and post-accession instruments and
other facilities.
BUGPRO BUGPRO application addresses D. G. Budget planning, DGIT. The       Out of scope
application allows drawing program budgets of the principal loaners in the
allocation of scarce resources in the state budget financing and the use of
public funds in maximum efficiency. The main functions of the application
are: taking proposals of the principal loan, database maintenance budget,
centralization of budget proposals and obtaining synthetic and analytical
output situations, permanent and on-demand. Data handling is done with
certain checks in their catalogs. Error handling is achieved through the
takeover of tree type relationships between financial indicators.
Nomenclatures working with applied are:
 Specific -nomenclatures: -nomenclature programs and objectives;
            -nomenclature formulation columns.
            -nomenclature general interest concerns: Annual financial (budgetary
classification) and the principal loan
 Computer application technology is designed Oracle8 and is available in a
local area network in MFP.
CAMELEON Information System for activity Control of the Financial Guard, taken after the       RMS
reorganization DGAF NAFA; is replaced by ACVILA.
The application is an integrated information system, for complex activity
management of the Financial Guard that covers most of the activities of this
institution. It is a flexible and secure information system using various sources
of ANAF (general nomenclatures, Onyx, identity management, register of
legal entities and individuals) and the existing database of the Financial
360 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
Guard. Programming was executed in web-based technology which implies
that future operations can be executed in real time. The reports reflect the
situation to date across the country. It has a high degree of standardization,
given the user guide and use the same classification system nationwide,
leading to reports issued by the system that accurately reflect the real situation.
It contains annual management module of objectives of the institution and can
be used in planning daily activities at the commissioner and divisional level.
CAP             -nomenclatureformulation columns. Oracle 11g   Oracle RAC 11.2.0.3 Retain
-ORACENTR
Carmonizare Harmonization Database managing specific documents for Cabinet of       Out of scope
PreAdherance Funding; Legal Harmonization and European Integration. It can
be used by members of a group, depending on the interests and rights of
access granted.
CASHBNR  Computer application technology is designed Oracle8 and is available in a Oracle     Out of scope
local area network MFP. Version
8.1.7.0.0
CAZIER Tax record Oracle 11g   Oracle RAC 11.2.0.3 RMS
FISCAL -ORACENTR
CAZIER is a computerized system for the management of taxpayers tax
record. It provides assistance for attesting bodies to edit the registration
forms / update actions in the fiscal record. It manages the registration forms
and updating of the facts which fall in the tax record received from bodies
such as.

It manages requests for release fiscal record and fiscal record certificates for
the taxpayers subordinated in terms of tax residence to a tax unit with
competence in managing fiscal record. It makes the exchange of information
in tax record, according to the Protocol on the procedure for the electronic
transmission of information from the tax record of taxpayers, concluded
between MFP and the Ministry of Justice (NTC).
CCANAF ANAF Call Center     Application deployed Interoperability
WebSphere Portal, WebSphere
The application provides grant assistance to taxpayers by telephone (call Application Server
center).
CCN-CSI Common network of communication     Application deployed Interoperability
WebSphere Portal, WebSphere
The application provides message exchange between national administrations Application Server
of the member states.
CENTRALIZTT Centralization of specific accounting operations of the territorial units of the Visual     Out of scope
state treasury - BTS and BS - MFP AG to DGRFP and the quarterly financial FoxPro 6.0
statements editing
CENTRBIL- CENTRBIL centralize data from all financial administrations of the counties Oracle 11g   Out of scope
INTBIL- and of DGFP Bucharest and performs the following: /
INTBILCAZ Interoperability
Section V. Requirements of the Information System 361

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
- Importation into DW (data warehouse) for analysis.

- Publishing on MFP-NAFA site certain indicators of financial statements for

each type of economic agent

- Export data to various formats for external users such as: Statistics, Forecast,
NBR, AVAS

NTBIL did the ad hoc query of the database using ORACLE balances SQL /
PLSQL, DISCOVERER, REPORT DEVELOPER.
CHAT_CERTIF Certification Authority – ANAF v2 Lotus   Application Domino INTEROPERAB
Domino CHAT/mfinante.ro ILITY
The application is used for the issuance, revoking and management of
unqualified certificates for their NAFA and MFP staff, central and from the
region, to have secure access in the intranet and internet portal.
CIRCANAF The purpose of the application is collecting and distributing circulars issued by       Interoperability
ANAF their territory. The application was implemented but not used.
CITARH Documents and summonses Archive on pending files, for the lawsuits in Lotus   Lotus Domino Application RMS
which the MFP represents a party; older than 2003. It is used very rarely. Domino BUCMINX01/MFINANTE
CITER Managing subpoenas and lawsuits pending in the courts of the territory, where Lotus   Lotus Domino Application RMS
MFP is a party in the lawsuit; SIDOC interface, the application that provides Domino
the unique registration number of documents in the system. Is updated daily
CITMIN Managing subpoenas and lawsuits pending in the courts of the territory, where Lotus   Lotus Domino Application RMS
MFP is a party in the lawsuit; SIDOC interface, the application that provides Domino
the unique registration number of documents in the system. Is updated daily
CITNOPROC Archive for subpoenas registered at the General Registry that were not taken       RMS
by the Legal Department of MFP. The documents are presented together after
filing year after the Issuer. Searching can be done after the number given by
the Registry.
CJCE The application provides documents (court orders, decisions) issued by the Lotus   Lotus Domino Application Retain
Court of Justice of the European Commission in the area of taxation, Domino
translated into Romanian.
CLIBANCI The application collects and maintains data on bank customers and provide Oracle11g Oracle RAC ORACENTR. mfol.dgti.ro RMS
data to other systems and other public institutions. The application must be 11.2.0.3
rewritten. -ORACENTR (also
works as distributed
to the relevant tax
administration -
Oracle 8.0.5)
C-LYNX The application allows generating links charts between taxpayers based on Oracle 11g DWRAC – Oracle trafic_control RMS
D394 / D390 and on other sources of information (ex .: Imports, ONRC) by RAC 11g (11.2.0.3)
setting the selection conditions (the transaction percentage to the tax base,
VAT, transaction type, etc. )
CODTVA The application allows submission through the MFP-NAFA web portal of the Lotus Solicitare Cod TVA Lotus Domino application RMS
362 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
requests for checking the validity of registration codes for VAT and for the Domino
identification data of persons registered for VAT in other EU member states.
These requests are distributed to the county said by the deponent as fiscal
domicile. For each application is assigned a registration number 1234567 JJ-
form-YYYY (ie AB-0000082-2007) where:

JJ - auto code of the county where he was assigned

- 1234567 - 7 digit number that is assigned sequentially and it resets at the

beginning of each year

- YYYY - year in which the request is made.

At the base form is the submitted file sent by the applicant of the information.
COMERT The application allows viewing associates and managers of companies (from Oracle 11g Schema COMERT Application deployed RMS
ONRC). - Oracle RAC 11g WebSphere Portal, WebSphere
(11.2.0.4) Application Server
CONDOR Application for management of programming activities for verification of Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 – RMS
personal tax situation mfol.dgti.ro ORACENTR
CONTAB Subsystem general ledger of the inventory objects Oracle ORACENTR Oracle RAC 11.2.0.3 – Retain
ORACENTR
CONTABCR The application performs accounting budgetary debts: nomenclatures Oracle baze de date locale , Application deployed RMS
administration, accounting notes, scales, reports schema WebSphere Portal, WebSphere
CONTABCR Application Server
CONTABPRE- Preadherence funds accounting Oracle 8i SP 01 SP 01 Out of scope
ACP
CONTABPRE_ Accounting for pre-accession funds: ISPA, PHARE, SCHENGEN, EEA,       Out of scope
OPCP OECD
CONTRACT- CONTRACT_NRZ application allows user management and the requests Oracle 11g Schema CONTNER Application deployed RMS
NRZ processing for contracts with non-residents. - Oracle RAC 11g WebSphere Portal, WebSphere
(11.2.0.4) Application Server
CONTR_NEREZ application allows views of lists / requests of contracts or
statistical reports.
CPF The application presents the Chapters and Articles of procedure code, Lotus Codul de procedurã Lotus Domino Application Retain
enriching content by associating methodological norms, application solutions, Domino fiscalã
forms, instructions, explanations and comments.
CREDLOC Evidence of operative reports on making payments on loans / guarantees Visual CREDLOC   Out of scope
contracted by the local public administration authorities, with or without state FoxPro 6.0
guarantees or guaranteed by the administration authorities.
CREDPRIV Management of loans to administrative units of proceeds from privatization Oracle 8i CREDPRIV   Out of scope
CTRANZITORI Payment of taxes paid through banks (for individuals) Oracle 10g TRZP   Interoperability
U 10.2.0.5.0
DARSAM IT Application processes forms regarding the financial statements of public Oracle     Interoperability
institutions of central and local administration.
Section V. Requirements of the Information System 363

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
DCREDITE Management of openings loans from the state treasury Visual DCREDITE   Out of scope
FoxPro 6.0
DECIMP Tax returns and information management for businesses and other entities. Oracle 8i baze de date locale , Application deployed RMS
schema DECIMP- WebSphere Portal, WebSphere
The application allows the management of tax returns and information of legal Oracle 8 Application Server
entities and other entities.
DECIZIILECFC CFC Decisions Lotus Deciziile CFC It is not a web application / Out of scope
Domino portlet / web service installed on
The application is a management system of the Central Fiscal Commission WebSphere Portal and
MFP decisions. The access to the application just for viewing is public and WebSphere Application Servers.
can be accessed via browser for MFP and NAFA staff. The base is located on It is a Domino Application.
a central server, it is possible to access to users who have a Lotus-desktop BUC32A/SERVER/MFINANTE
client installed on their computer, connected to the network MFP and access
rights granted by the base manager (administrator) .
DECLAVERE DECLAVERE is a management system of returns of assets and interests, Lotus Declaratii de avere Lotus Domino Application Retain
integrated with the MFP and ANAF employee management system. Supports Domino
Attachment of the scanned files
DECLlMF Fiscal declarations DB2 N/A Application deployed RMS
WebSphere Portal, WebSphere
Application for assisted processing, validation, printing and obtaining Application Server
electronic format or the applying of two-dimensional barcode for tax returns.
DECLPORTAL Archive of tax returns filed through the portal. Lotus Declaratii protal Lotus Domino Application RMS
Domino
The application stores the tax returns filed through the portal and provides the
flow distribution of the statements to back-office.
DECLSEN National Electronic System, communication between the NAFA portal and the Lotus Declaratii SEN Lotus Domino Application RMS
territorial back office. Domino

The application allows transmission of the statements from SEN and portal to
back office and taking the backoffice answer to the portal. It allows to resolve
errors occurred.
DECLWEB Tax returns submitted electronically - Taxpayers Assistance Programs for DB2 N/A DB2 RMS
completion, validation and signing electronic returns; Errors Validation of
PDFs. Tax returns submitted electronically - which are PDFs
DECSEN MFP Decisions, CSJ rulings. It is a Case Management / Document Lotus Declaratii SEN Lotus Domino Application RMS
Management application. Domino
DEDECER Application for assisted processing, validation, printing and obtaining the DB2 N/A Application deployed RMS
electronic format for "308/313 -Refund Request for taxable persons which are WebSphere Portal, WebSphere
not registered for VAT purposes in Romania, established in another member Application Server
state of the EU / outside the Community".
DEDOC 112- Statement regarding the payment obligations of social contributions, Oracle 10g Schemele Oracle RAC 10g (10.2.0.4) RMS
income tax and nominal record of insured persons. DEC_ROOT,
DEC_UNK,
DEC_IMP,
364 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
DEC_FORM
DEPBAN Deposits from banks Oracle 11g DEPBAN Application deployed Out of scope
WebSphere Portal, WebSphere
Application Server
DEPTERM Evidence of out-of-financial-balance term deposits, made by public Oracle 8i, DEPTERM Application deployed Out of scope
institutions and the economic entities Oracle 8.05 WebSphere Portal, WebSphere
Application Server
DESCRED IT application processes evidence of budget appropriations openings Visual   Application deployed Out of scope
FoxPro WebSphere Portal, WebSphere
Application Server
DMFAS Debt Monitoring System is a client-server application with the following Oracle 10i DMS1 DMS1 Out of scope
functions: - track domestic and foreign borrowings - tracking of ongoing loans
- public debt simulations on various periods
DOBROUE The application takes D400 reports of banks, group and extract data and Oracle 10i ORAVISE_P ORAVISE_P RMS
generate containers about beneficiaries of the interest income, for EU member
states and associated states according with dir. 48 / EC / 2003.
DOBUERO The application takes reports according to dir. 48 / EC / 2003 of the member Oracle 10i ORAVISE_T ORAVISE_T Retain
states and associated and load them into a database about the beneficiaries of
interest income from EU member states and associated states for tax purposes
in Romania.
DOCBCL The application allows manipulation of the Central Liaison Office documents. Lotus Documente BCL Lotus Domino Application Retain
In the database, the documents are grouped according to their flow such as: Domino
receiving requests from EU member states, hereinafter EU-RO documents and
sending requests from Romania to the EU Member States hereinafter RO-EU
documents.
DOCDECL The application stores the normative acts relating to the completion and Lotus DocDecl DB2 - driver type: 4, database Retain
submission of tax statements for consultation / examination / fast retrieval of Domino name: licita, server name: idb1
information. port: 60300 FISCA03/FISCNET
DOCDGE Manage General Economic Directorate activity-specific documents. Lotus Doc DGE Lotus Domino Application Out of scope
Domino
DOCDGTDP Documents belonging to DGTDP (General Directorate of Treasury and Public Lotus DocDGTDP Lotus Domino Application Out of scope
Debt) Domino
DOCGF Manages inventory of IT Financial Guard headquarters. The application can       Retain
be used by members of a group, depending on the interests and rights of
access granted.
DOCLIB Documentation (DGTI Library, Manuals) Lotus Biblioteca DGTI Lotus Domino Application Retain
Domino
DOCOPCP The application aims to manage work officially by storing relevant work       Out of scope
documents. These are grouped by services, by projects, in different categories
and subcategories, document type, the date of registration. Important is the
fact that attachments can be stored.
DOCUEMFP Documents received from the Council of the European Union are stored in the Lotus DOCUEMFP Lotus Domino Application Out of scope
database as attachments, information to be disseminated within the institution Domino
based on a classification of topics and a classification of special working
Section V. Requirements of the Information System 365

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
groups
DOTARE DOTARE is a system of computer records of equipment located in the MFP       Out of scope
and ANAF units at central and local level.
It is a stand-alone system platform Visual Fox 5.0 is a reporting tool to MFP
and ANAF occasional stage computing facilities with:
• County Department of Public Finance - occasional use in production since
2004, at the request of management DGIT
DWAIF DWAIF is an area of centralized reports according to the activity of fiscal Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS
inspection on legal entities (from PHOENIX database). The access of this
area of reporting is made through the NAFA dashboard.
DWANAF The application is an informatic system for collection / processing / analysis / Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS
centralized reporting of information from NAFA DW.
DW-D394 DW-D394 is a system that implements and manages the procedure for Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS
determining and identifying the degree of fiscal risk of taxpayers which have
to submit the informative statement D394.
DWDECONT The application contains the central database for VAT returns with negative Oracle 11g DWRAC – Oracle isa_dw RMS
amounts, with reimbursement option. RAC 11g (11.2.0.3)
DWGFTC The application is an informatic system for viewing statistical reports / Oracle 11g DWRAC – Oracle trafic_control RMS
operative according to the transportations made by the economic agents in the RAC 11g (11.2.0.3)
intra-Community acquisitions field (based on information taken from the
application TRAFIC_CONTROL).
DWIND- The application is an informatic system for analyzing the performance Oracle 11g DWRAC – Oracle mis RMS
PRELIND indicators of NAFA, GF, ANV: centralization, processing, analyzing RAC 11g (11.2.0.3)
situations.
E-LEARNING The application provides support on distance education of the officials around DB2   Application deployed Retain
the MFP and NAFA network. WebSphere Portal, WebSphere
Application Server
EMAILTREZ EMAIL TREZORERIE It is a management system works within the General Lotus E-MAIL Lotus Domino Application Out of scope
Treasury and Accounting Domino TREZORERIE
EMCS_RO The application is a control system of Excise Goods in National Domain Oracle ORACLE RAC 10g   Interoperability
(NSEA) and in Common Domain (in accordance with the requirements (10.2.0.3),
DGTAXUD EMCS2). ORACLE RAC 10g
(10.2.0.3),
ORACLE RAC 10g
(10.2.0.3),
ORACLE RAC 10g
(10.2.0.30),
ORACLE RAC 10g
(10.2.0.3),
ORACLE RAC 10g
(10.2.0.3.)
EMICERT The application provides the operative management for issues of treasury Oracle 8i, EMICERT Application deployed Out of scope
deposit bills in the operational treasury units of the General Directorate of Oracle 8.05 WebSphere Portal, WebSphere
Public Finance. Application Server
366 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
EMIRAP Automatic Processing of treasuries operative reports on the progress of issues Oracle 8i, EMIRAP Application deployed Out of scope
of certificates in county treasuries and out of county treasuries from the MFP- Oracle 8.05 WebSphere Portal, WebSphere
DGTDP Application Server
EMTITLURI Evidence of Government Securities issuance VisualFox baza de date Visual Application deployed Out of scope
6.0 Fox 6.0 WebSphere Portal, WebSphere
Application Server
EULICENTE Evidence and tracking licenses and authorizations to practice gambling       Out of scope
EVENITURI E-Revenues Oracle 10g TRZP Application deployed Out of scope
10.2.0.5.0 WebSphere Portal, WebSphere
Application Server
EVIDSTOC Evidence of stocks and valorisation of seizures VisualFox Valorif; baza de Application deployed Out of scope
6.0 date Visual Fox6.0 WebSphere Portal, WebSphere
Application Server
EVID-RISK- EVALUARE RISC APLICAŢII is a applications management system of Lotus Evaluare Risc Lotus Domino Application Retain
APP DGTI - ANAF and MFP Domino Aplicatii
EXEFIN Centralization and financial execution of the data reported by state treasuries VisualFox   Application deployed Out of scope
in Form 05D double key 6.0 WebSphere Portal, WebSphere
Application Server
FF_2010 Application for assisted processing, validation, printing and getting electronic DB2 N/A Application deployed Retain
format on 31 December 2009 for tax records WebSphere Portal, WebSphere
Application Server
FMASISTENTA The application is a management system of requests received through the Lotus FormularAsistenta It is a Domino Application RMS
assistance form from the website www.anaf.ro. Domino BUC32A/SERVER/MFINANTE
FOREXEBUG performance IT service for reporting financial statements of public institutions       Out of scope
FOREXEBUG_L It contains documentation for the FOREXEBUG project Lotus FOREXEBUG Lotus Domino Application Out of scope
OTUS Domino
GARANTII- Evidence of bank guarantees submitted by various suppliers after winning     Application deployed Out of scope
BANCARE tenders for execution of the various objectives in the ISPA, PHARE, WebSphere Portal, WebSphere
SCHENGEN, EEA, OECD Application Server
GFTC-VIEWER The application is a system that allows viewing scanned documents / Oracle 11g DWRAC – Oracle trafic_control Out of scope
attachments in the point of frontier for carriage made by the economic agents RAC 11g (11.2.0.3)
in intra-Community acquisitions field.

Allows filtering by various criteria: CUI beneficiary, name beneficiary,

number car, PTF input, merchandise category, etc.

GSRS Registration and Settlement System of Government Securities Operations Oracle   Application deployed Out of scope
WebSphere Portal, WebSphere
Application Server
HELPDESK The application is a dispatcher for technical assistance in ICT for all MFP and       Interoperability
NAFA employees.
HLPDSK The application collects on 2 channels of communication, e-mail and phone, Lotus HelpDesk Lotus Domino Application Interoperability
user complaints on the operation / non-operation informatic system, in terms Domino
of office equipment, network, communications and applications service.
Section V. Requirements of the Information System 367

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
IBANCLS Treasury related IBAN Accounts Management Oracle SP01 Application deployed Out of scope
Version WebSphere Portal, WebSphere
8.1.7.4.0 Application Server
IMPATRIM WEB enabled of state public Heritage. Keep track of the state of public Oracle   Application deployed Out of scope
property in accordance with law 213/1998 and subsequent amendments. WebSphere Portal, WebSphere
Application Server
INACTIV The INACTIV information system manages taxpayers and / or inactive /       DROP
reactivated by the tax inspection activity - legal entities. Taxpayers - legal
entities - inactive / reactivated by the tax inspection activity through
publication in OPANAF and / or MO, displaying the ANAF. It is implemented
in production in July 2005. It was redesigned year in technology in the project
WEB Phare2005
INACTIVI Application allows the management of active and reactive tax codes. Oracle 8i VECTOR_CENTR Oracle 10.2.0.1 - ORCB (CM) RMS
AL
INDFIN Application of reporting financial indicators in the national economy. The Oracle11g dwrac. fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC Interoperability
application allows access to various financial indicators extracted from the
balance sheets submitted by economic agents. The access can be made at the
level of an economic agent or at the aggregate level on CAEN codes.

The economic agents enrolled in this application are companies that have filed
/ lodged balance sheet date since 2008.
INFDGTI DGTI Information Lotus Informaţii DGTI Lotus Domino Application RETAIN
Domino
INFOPC INFOPC is a query system for information about taxpayers and tax audit Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS
preparation. It is used for services / departments within the business tax
inspection and / or with control attributes on individuals or legal entities.
INFOPLUS The application provides interoperability between ANV and NAFA using data Oracle 11g dwrac.fiscnet.ro Oracle RAC 11.2.0.3 - DWRAC RMS
for fiscal control.
INTERNET It gives users access to the Internet. Microsoft     Interoperability
SQL Server
2005
LITIGII Manage documents on the MFP party disputes. Lotus LITIGII Lotus Domino Application Interoperability
Domino
LOTOBONO Receipts Lottery Oracle 11g LOTOBONO Oracle RAC 11g (11.2.0.4) Interoperability
LOTUS- Lotus Domino Administration Lotus   Application deployed Interoperability
DOMINO Domino WebSphere Portal, WebSphere
Application Server
M1SS M1SS system is intended to support companies providing electronic services, Oracle 11 g M1SS Oracle 11g - MISS Interoperability
telecommunications, broadcasting and television. It allows companies to Release 2 (m1ssproddb.cpd.fi
register, submit statements and pay VAT due to Member State of scnet.ro)
Consumption via the web portal provided by the Member State of
identification (usually the Member State in which the company has established
economic activity).
368 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
Using M1SS is optional and addresses both activity-based companies in the
EU (EU scheme) and those established outside the EU (non-EU scheme).

VoES Scheme (VAT on E-services) which is already operational, available to

providers of electronic services outside the EU, is replaced with M1SS.
MAEC Applications of monitoring and management of network communications     Application deployed Retain
equipment from NAFA. These applications are: WebSphere Portal, WebSphere
Application Server
- NAGIOS

- Net Disco

- Zabbix

- Cisco Network Registrar

- Cisco Transport Controller

- Certes TrustNet Manager

- phpIPAM IP address management

- NetLog LogAnalyzer

- Rancid

- Cisco Prime Network Analysis Module

- Anue

- Cisco Secure Access Control Server

MANUALE Lotus Notes User Manuals Lotus Manuale Utilizare Lotus Domino Application RETAIN
Domino Lotus Notes
MASREP Main functionalities of the application are:       Out of scope

• Issue of registered securities - Central Bureau of the Ministry of Finance;

• The distribution of registered securities - the territorial offices of the County
Treasurer;
• Assignment of registered securities - the territorial offices of the County
Treasurer;
• Use of registered securities - the territorial offices of the County Treasurer.
    Currently the app only has the functionality distribution of registered
securities issued before the establishment of the company "Fondul
Proprietatea" SA National Agency for Property Restitution.
MB Management of Bulletins received from the National Trade Register Office Oracle   Application deployed RMS
Section V. Requirements of the Information System 369

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
WebSphere Portal, WebSphere
Application Server
MGMTID Identity management is a centralized and secure system that aims to identify, DB2   Application deployed RMS
authenticate and authorize user access to centralized applications (portalized) - WebSphere Portal, WebSphere
intranet, extranet, internet - of ANAF and MFP Application Server
MODAF Modernizare AF (RAMFP). Il will be replaced soon by other application Lotus Modernizare AF Lotus Domino Application Retain
Domino (RAMFP)
MODIFNERAM "MODIF application is part of the BUGET computer system and addresses       Out of scope
B (MODIF) Ministry of Finance, DGIT DG budgetary planning, budgetary policy DG. The
application allows the initial budgetary provisions approved accounting
changes as a result of normative acts. The application is designed in Visual
Fox. For working BUDGET local network uses data from the MFP. primary
document is a standard form of "" M "" OPC completed and approved by the
General Directorates of budget programming, sectoral of MFP. Processing of
"" M "" is in the Directorate General of accounting methodology and public
institutions. From the database provides data entry openings for evidence of
budgetary appropriations (DESCRED) for the drafting of the budget
(BUGCASH) and supervising the budget (DARSAM). "
MOFICIAL_0 The application is the first version of the Official Gazette, which is in use at       Retain
this time
MOFICIAL The application allows the viewing of information in the Official Gazette - Lotus Monitorul Oficial Lotus Domino Application Interoperability
normative documents published in the Official Gazette Part IV. Domino
MONINV MONINV is a tracking system of payments each month on investments, made       Out of scope
by DGIT: • Contains information about authorizing payments every month
since the beginning of the year monitored and the amount that remains to be
funded to the completion of the investment • The application is in operation
since 01.01.2009 • The main role of this application is that there must be a
similar form under which the authorizer to report, and the MFP to centralize
the results
MONPERS MONPERS application addresses the principal credit instructors, DGTI, Oracle   Application deployed Out of scope
ACIS, DG Budget programming, D. G. Budgetary Policy, Directorate of WebSphere Portal, WebSphere
Treasury and Public Debt. The application allows uploading data, updating Application Server
and annexes listing
MONS1001 The application stores information relating to declaration S1001. The Lotus Monitorizare S1001 Lotus Domino Application RMS
application can be used by members of a group, depending on the interests and Domino
rights of access granted.
MUTDOSAR The application Mutdosar aims tracking and prevention of AFP delays in both       DROP
fiscal files received as well as those transferred. Data monitoring and issuance
of reports has been made so far, in March-April and October-November 2010.
This app has been delivered in the territory for distribution in each county
DGFP AFP, PDF takeover application data transfers between AFPs tax files.
Application PDF (Adobe) with complete data is transmitted to AFP DGIT by
e-mail, where are centralized, data is processed Oracle Application Server and
issue the required reports.
370 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
NOMEN General lists / catalogs / nomenclatures Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 RMS
mfol.dgti.ro -ORACENTR
NOMEN_FORE It represents an extension of the general nomenclature (NOMEN) - Managing Oracle 11g ORACENTR.mfol. Oracle RAC 11.2.0.4 - Interoperability
XEBUG nomenclatures for BUDGET ACTIVITY / TREASURY FOREXEBUG dgti.ro ORACENTR
OMF Orders Archive of Finance Minister issued after 28.12.2000, but only until the       Out of scope
end of 2005, when it went into production a new application. The documents
are grouped by the date of exit from the MFP to publication.
ONIX The application is a informatic system for managing the personnel and Human Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Interoperability
Resources mfol.dgti.ro -ORACENTR
OPFV Application for assisted processing, validation and printing of payment DB2 N/A Application deployed Out of scope
orders / payment should sheet WebSphere Portal, WebSphere
Application Server
OPTT Application for assisted processing, validation and listing individual payment DB2 N/A Application deployed Out of scope
orders WebSphere Portal, WebSphere
Application Server
ORDINE-MFP- MFP-ANAF Orders Lotus ORDINE-MFP- Lotus Domino Application Retain
ANAF Domino ANAF
PATRIM System for monitoring the assets. Oracle   Application deployed Out of scope
WebSphere Portal, WebSphere
Application Server
PHOENIX – SI PHOENIX IT system addresses Services / departments of NAFA, AJFPs, AFP Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 RMS
sectors of Bucharest, Bucharest AFP medium taxpayers who carries the legal mfol.dgti.ro -ORACENTR
entities tax audit. The main function of this system is loading, query,
centralization and listing information on the results of control documents for
legal persons, the issuance of the decision to impose according with the
additional tax obligations established by the tax inspection and issuance of the
decision according with the unmodified tax base, according to order no . 109
of 27.07.2004 and 972 / 13.06.2006 (as amended and supplemented). Provides
automatic calculation scripts performance indicators of tax audit activity.

Provides data queried by other applications (decisions regarding unchanging

the taxation base for SERADN system, informatic system DECIMP - web
version - tax audit opinions issued for the shares open through the issuance of
service order).
PLA – SI PLA computer system addresses to Services / departments of NAFA, DGFPs Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 – RMS
that carries the corporate tax audit and corporate tax audit activity from the mfol.dgti.ro ORACENTR
county / regional Directions for Excise and Customs.

The main functions of this system is loading, query, centralization and listing
information on the planning and implementation of actions in fiscal inspection
according to OPANAF 2225/2007.

It was redesigned in web technology and integrated with the informatic system
Phoenix.
Section V. Requirements of the Information System 371

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
PresaMFP REVISTA PRESEI MFP DataBase stores news articles related to the activity Lotus Revista presei MFP Lotus Domino application Retain
of Ministry of Finance. Domino
PRESTAJ IT Application monitors payment of social benefits, in accordance with Joint Microsoft la nivel central Visual Fox Pro, and TRANSFER Out of scope
Order of MFP and MMFPS, nr.1849 / 12.06.2008 Visual Fox PRESTMIN
Pro 6.0, Data
Transmission
from one
level to
another is
done
electronically
through
LotusNotes
(Lotus
Domino)
after their
validation at
the Treasury
counter
PREV - SI Prevention Control - tracking the activity of delegated controllers (Application Oracle   Application deployed Out of scope
for Preventive Control Assistance) WebSphere Portal, WebSphere
Application Server
ProceduriANAF PROCEDURi ANAF is a system where ANAF specific procedures are Lotus Proceduri ANAF Lotus Domino Application Retain
managed Domino
ProceduriMFP PROCEDURi MFP is a system where MFP specific procedures are managed Lotus Proceduri MFP Lotus Domino Application Out of scope
Domino
RActivitate The application is a management system of monthly reports of all Directors of Lotus Rapoarte de Lotus Domino application RETAIN
NAFA, ANV and GF, as well as ratings given by approved directions of these Domino activitate
units.
RAMBNETP The objective of the application is the implementation of the procedure for Oracle 8i baze de date locale , Application deployed RMS
settlement of refund claims filed by taxable persons not registered for VAT schema WebSphere Portal, WebSphere
purposes in Romania, established outside the Community. RAMBNETP Application Server
RAPINF Manages information reports about the achievement of indicators related to Lotus Rapoarte de Lotus Domino application Interoperability
work performed by DGRFPs. Domino Informare
RAPOARTE Budget execution related ANAF reports Oracle 10g TRZP Application deployed N/A
10.2.0.5.0 WebSphere Portal, WebSphere
Application Server
RCNG-PF The Register of individual taxpayers Oracle 11g Schemele IVG_RC, rcng@oracentr-oltp RMS
CONTRIBPF,
RCNG - Oracle
RAC 11g
(11.2.0.4)
RCNG-PJ The Register of legal entities Oracle 11g Schemele rcng@oracentr-oltp RMS
CODFISC,
372 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
CODFISC_PROD,
LOTURI - Oracle
RAC 11g
(11.2.0.4)
REGDAT IT application that manages public debt register in electronic format Oracle REGDAT, baza de Application deployed Out of scope
date Visual Fox 6.0 WebSphere Portal, WebSphere
Application Server
REGSEDIU The application represents the register of requests of certificate headquarters Oracle 8i baze de date locale , Application deployed RMS
(REGADRESE) of a new founded firm. schema WebSphere Portal, WebSphere
REGSEDIU Application Server
Regtaxe Register of fiscal and non fiscal duties Oracle 11g dwrac dwrac Interoperability
RESTANTE Management of debtors to the state consolidated budget. Oracle 8i RESTANTE @ Application deployed RMS
(RESTANTE Oracle 10.2.0.1 - WebSphere Portal, WebSphere
FISCALE) ORCB (CM) Application Server
S1001 S1001 - Report on economic and financial indicators under OMFP no. 41 / Benefits   Application deployed RMS
14.1.2014. from DeDoc WebSphere Portal, WebSphere
System Application Server
S1001 form can be downloaded from the website at Infrastructu
https://static.anaf.ro/static/10/Anaf/Declaratii_R/1001.HTML then transmitted re
and processed through the DeDoc transmission system of statements.
SACF The information system of administration of tax receivables. Outstanding       RMS
reporting.
SACF-Form 01- The information system of administration of tax receivables: taxpayers lists, Oracle 8i Local data bases, Application deployed RMS
04 Monitorizare inspectors administration, printing forms. SACF db schema WebSphere Portal, WebSphere
contribuabili Application Server
SACF-Rapoarte The information system of administration of tax receivables. Collection Oracle 8i baze de date locale , Application deployed RMS
colectare reports schema SACF- WebSphere Portal, WebSphere
Oracle 8 Application Server
SACF-Raportare The information system of administration of tax receivables. Arrears reports Oracle 8i Local data bases, Application deployed RMS
Arierate SACF db schema WebSphere Portal, WebSphere
Application Server
SACF-Restanțe The information system of administration of tax receivables. Debts reports Oracle 8i Local data bases, Application deployed RMS
raportare SACF db schema WebSphere Portal, WebSphere
Application Server
SAIVEN Management System Income Tax for individuals Oracle 11g Oracle RAC 11g [email protected] is not a RMS
(11.2.0.4), Schema web application / portlet / web
MILIESCU, service installed on WebSphere
ADMCENTRAL Portal and WebSphere
Application Servers
SCCFI SCCFI Projects Lotus Proiecte SCCFI It is not a web application / Out of scope
Domino portlet / web service installed on
WebSphere Portal and
WebSphere Application Servers.
It is a Domino Application.
Section V. Requirements of the Information System 373

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
It is a Domino
Application.BUC32A/SERVER/
MFINANTE
SERADA The application is a Managing Risk Assessment system at Request Oracle 8i baze de date locale , Application deployed RMS
Administration for refund of excise duty. For each request for refund of excise schema WebSphere Portal, WebSphere
duty should be established a degree of risk: low, medium, high, according to RAMBURS- Oracle Application Server
the law (420/2007 OMPF. All information necessary to illustrate the solution
of a request to refund the excise can be found in BD SERADA.
SERADN Risk Assessment System Administration Negative Returns with Oracle 8i baze de date locale , Application deployed RMS
reimbursement option. schema WebSphere Portal, WebSphere
RAMBURS - Application Server
For each negative retarn of VAT with negative amounts, with reimbursement Oracle
option (DNOR) is established a degree of risk: low, medium, high, according
to the law (OMPF 263/2010); on standard negative individual (SIN), semester
calculated until 2010 and quarterly since 2010, in the case of small taxpayers.

For taxpayers large, medium and exporters with special scheme approved,the
DNOR analysis is based on the papers.

All information needed to illustrate solving a DNOR can be found in BD

SERADN: compensation / refund notes, tax decisions, delaying the settlement
terms, etc.
SIAC IT system managing administration of tax receivables Oracle 8i Local data bases, Application deployed RMS
SACF db schema WebSphere Portal, WebSphere
Application Server
SIAD Informatic system of management administrative documents: docket post, car Oracle SIAD@SAPP4 Application deployed RMS
documents, etc. WebSphere Portal, WebSphere
Application Server
SIARC Manage requests for assistance in recovery received or transmitted from / to Oracle 11g schema RECUP Oracle RAC 11.2.0.4 - RMS
the competent authorities of other EU Member States ORACENTR
SIDOC Documents Registration and Tracking System at the General Registry and Lotus SIDOC Este o aplicatie Domino. RMS
secretariats level - MFP and ANAF central level. The system is based on the Domino BUC33A/SERVER/MFINANTE
current organizational structure and registration numbers, internal numbers in
the ranges allocated
SITFIN_NG SITFIN_NG application - Develop financial statements for each program Oracle   Application deployed Out of scope
component budget. The IT system has been designed to process payments WebSphere Portal, WebSphere
made Application Server
SOLCON The application provides a way to record information on complaints filed and Lotus Soluționare Lotus Domino application RMS
decisions related solving the complaints Domino Contestații

Appeals may be filed by large taxpayers, may be directed against the acts
issued by the tax authorities of NAFA body, may challenge the customs debt
and excise, VAT and income tax on non-resident, income tax, social
contributions, grants and subsidies, tax facilities, etc.
374 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A

The information stored can be viewed grouped in several ways: grouped by

subject or grouped according to the type of act. It is possible to group
information by county where the complaint was filed, or depending on body
found.
SPIN Evidence and calculation of salary rights granted in the MFP and ANAF Oracle 11g ORACENTR. Oracle RAC 11.2.0.3 Retain
mfol.dgti.ro -ORACENTR
STAR Public Debt Management Oracle 11g STARLIVE, Application deployed Out of scope
STARTEST; baza WebSphere Portal, WebSphere
de date Oracle 11g Application Server
STATEF186 Follow STATEF186-execution of the state of functions of public institutions Oracle   Application deployed Out of scope
WebSphere Portal, WebSphere
Application Server
STRUCONTAB Accounting of post-accession funds (accounting for the Structural Funds Oracle 8i SP 01 SP 01 Out of scope
_ACP Managing Authority and for Certification and Payment Authority)
(Contabstru)
SWIFT Interbank settlement system through SWIFT and TRANSFOND Oracle buc-oracle Application deployed Interoperability
WebSphere Portal, WebSphere
Application Server
TAXA_AUTO IT System for applications, calculate and refund of automotive special tax , Oracle 11g TAXA_AUTO Oracle RAC 11g (11.2.0.4) RMS
pollution tax , pollutant emissions tax, environmental stamp.
TAXA_AUTO Refund of Automotive Tax - Environmental Stamp Oracle 11g TAXA_AUTO Oracle RAC 11g (11.2.0.4) RMS
Restituire
TAXA_AUTO-         RMS
POLUTION
TAXEDIV Management of taxes collected in cash collection points located in treasury Oracle 8i, TAXEDIV Application deployed Interoperability
operative units within DGFP Oracle 8.05 WebSphere Portal, WebSphere
Application Server
TELEFONIE Subsystem for calculating deductions for personal telephone subscriptions Fox N/A aplicatie FOX Retain
MOBILA
TEMADOC Information about ongoing projects Lotus TEMADOC Lotus Domino application Out of scope
Domino
TEMADOC_2 Information of procedures, methodologies type Lotus TEMADOC_2 Lotus Domino application Out of scope
Domino
TRAFIC_CONT Informatic system for gathering information on carriage made by economic Oracle 11g MS-SQL Server, trafic_control Out of scope
ROL agents in the intra-community acquisitions field. DWRAC – Oracle
RAC 11g (11.2.0.3)
TRANSFER Transfer of information between levels of MFP structures Oracle SAPP 4(DIN SAPP 4(DIN CENTRAL IN DROP
8i(CENTRA CENTRAL IN TERITORIU), SO 01(updates
L) SI 8.0.5 TERITORIU), SO from Nomenclatoare and
TERITORIU 01(updates from Codfisc)
Nomenclatoare and
Codfisc)
TREZCEN accounting management operations in Central Treasury Visual TREZCEN Application deployed Out of scope
Section V. Requirements of the Information System 375

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
FoxPro 6.0 WebSphere Portal, WebSphere
Application Server
TREZOR Buyouts OPT, payment should barcode sheets, collected daily errands, taking Oracle 8i TREZOR Application deployed Interoperability
control, confirmation documents, taking monthly fees, updating and various WebSphere Portal, WebSphere
operations, analytical accounts nomenclature, calculation and distribution IVG Application Server
share, calculation and takeover interest
TRIDENT "Application for management of assessment documents of D088 statement Oracle 11g ORACENTR_P – trident RMS
(Statement on own responsibility to assess the intention and ability to conduct Oracle RAC
economic operations involving the actions in the VAT field. " 11.2.0.4
TRZCENTT Evidence of specific accounting operations in territorial units of the state Visual TRZCENTT   Out of scope
treasury - BTS and BS-MFP AG FoxPro 6.0
UCASMFC Introducing, listing processing of preventive financial control data and     Oracle RAC 11.2.0.4 - Out of scope
financial management; - The creation, monitoring and archiving internal ORACENTR
documents CHUFMCS, developed under control activity; - Storage and
processing
UCVAP Information system for management of MFP activity - Unit for Coordination Oracle 11g ORACENTR.mfol. Oracle RAC 11.2.0.3 Out of scope
and Verification of Public Procurement dgti.ro -ORACENTR
UTILITAR Transfer Mail attachments to the counties. The main users: DGIT staff and Lotus Transfer Mail catre Lotus Domino application DROP
local administrators of the Oracle application. The database is the mail-in type. Domino Judete
VATRefund EU VAT refund. Oracle 10g (SID=VATREFUN (HOST=10.254.20.76) RMS
D) (PORT=1521)
VECTOR The application represents the tax vector of corporate taxpayers and other Oracle 8i baze de date locale , Application deployed RMS
(Vector fiscal) entities. schema VECTOR WebSphere Portal, WebSphere
Application Server
Verif088 Information check-ups from 088 Return Oracle 11g schemele Oracle RAC 11g (11.2.0.3), RMS
CODFISC, Oracle RAC 11g (11.2.0.4)
VECTOR_CENTR
AL, DEC_VIEW,
ETC
VIES VIES – VAT Information Exchange System Oracle CLO Application deployed Interoperability
(VIES_DB) WebSphere Portal, WebSphere
Application Server
VoeS VoeS – VAT on e-Services Oracle   Application deployed Interoperability
WebSphere Portal, WebSphere
Application Server
WEB_ANTREP Warehouse keeping publishing   AVERI Web Application on IBM WAS Out of scope
WEB_BILANT Optimized display of balance data   CODFISC Web application on IBM WAS Interoperability
WEB_BUGET Budget Website   BUGET Web application on IBM WAS Out of scope
WEB_CAP Public Procurement Control     Web application on IBM WAS Out of scope
WEB_CODFISC Displaying fiscal data on the MFP site   CODFISC Web application on IBM WAS RMS
WEB_PETITII- Submitting petitions on MFP Website   SITEMF Web application on IBM WAS Out of scope
MFP
WEB_PUBNOM Publishing of nomenclatures   PUBLINOMEN Web application on IBM WAS RMS
EN
376 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
WEBAFISBUNP Selling property owned by the state     DB2 - driver type: 4, database RMS
RIVATE name: licita, server name: idb1
port: 60300
WEBAFISBUNS Selling of seized goods     DB2 - driver type: 4, database RMS
ECHESTRATE name: licita, server name: idb1
port: 60300
WEBAFISSEDI Application for displaying tax office units     Oracle 10.2.0.1 - ORCB (CM) RMS
U
WEBAGSPV Agent for individuals Users activation in SPV     Oracle 10.2.0.1 - ORCB (CM) RMS
WEBANRP Application for securities compensation payment ANRP   DESPAGUB Web application on IBM WAS Out of scope
WEBANUNTAC Announcements for Procurement of goods and services     DB2 - driver type: 4, database Retain
HIZITIE name: licita, server name: idb1
port: 60300
WEBANUNTAC Notifications for fiscal administrative acts     DB2 - driver type: 4, database RMS
TEFISCALE name: licita, server name: idb1
port: 60300
WEBAPROBAS SPV Users Approval       RMS
PV
WEBAUDIT Auditors Register based on HG 1259/2012   AUDIT Web application on JBOSS Out of scope
WEBBILANT- Balances - Update Agent       Interoperability
AG
WEBBSC Balanced Scorecards – Dashboard   TABBSC Aplicație web aflata pe server Interoperability
JBOSS persoana de contact
Dorina Andrei
WEBBUGETUP Displaying information on Budget Website   BUGET Web application on IBM WAS Interoperability
DATE
WEBCASEMAR Cash Register authorizations Register   casedemarcat Web application on JBOSS Interoperability
CAT
WEBCAUTARE Search Engine Application     DB2 - driver type: 4, database Interoperability
name: licita, server name: idb1
port: 60300
WEBCAZIERFI Fiscal Record Transmission     Oracle RAC 11.2.0.4 - Interoperability
SCAL ORACENTR
WEBCERTSPV Subscribe and Edit User Profile and digital certificate owner to Virtual Private     Oracle 10.2.0.1 - ORCB (CM) Interoperability
space
WEBCOMUNIC ARB Communications       Interoperability
AREARB
WEBCONCURS Competions / Raffers     DB2 - driver type: 4, database RMS
URI name: licita, server name: idb1
port: 60300
WEBDECL Filling in legal statements DB2   No longer available, it was RMS
replaced
WEBDECONT Rezolving expense account Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
WEBDECUNCA Display NAFA statements application     Web application on IBM WAS RMS
Section V. Requirements of the Information System 377

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
F-agent afisare
WEBDECUNCR Generation of check NAFA statements application   Dec_Declaratii Web application on IBM WAS RMS
EC-agent recipisa
WEBDECUNCU Submission of NAFA statements application   Dec_Declaratii Web application on IBM WAS RMS
P-agent upload
WEBDECUPLO Transmission of on-line electronic returns Oracle 10g   Oracle RAC 10.2.0.4 - MQDEC RMS
AD (DEDOC)
WEBDOCSECU Security Documents       RMS
RITATE
WEBEDITPSPV SPV Users Profile Edit     Oracle 10.2.0.1 - ORCB (CM) RMS
WEBENERGIE List of taxpayers who filed D089 on their own. Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
WEBEVIDAVIZ Evidence of legal opinions   aviz Web application on JBOSS RMS
E
WEBEVIDPRO Register of MFP Processes   procese Web applications on server RMS
C JBOSS
WEBEXTRASE Web Service for transmission of excerpts by Treasuries     Oracle RAC 11.2.0.3 - DWRAC RMS
WEBFMASIST e-mail Assistance     Oracle 10.2.0.1 - ORCB (CM) RMS
WEBFMSESIZA Form for complaints     Oracle 10.2.0.1 - ORCB (CM) RMS
RI
WEBGENRI Inventory numbers generator     Web applications on JBOSS RETAIN
server
WEBINACTIV_ Taxpayers registry active / inactive Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
REACTIV
WEBINREGAD FOREXEBUG system administrator enrolments     Oracle RAC 11.2.0.3 - DWRAC RMS
MINFOREXE
WEBINREGAD PATRIMVEN system administrator enrolments     RMS
MINTERTEINS
TIT (primarii,
banci, ...)
WEBINREGD11 Users Registration for returns submitting - individuals Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
2PF
WEBINREGD11 Users Registration for returns submitting - companies Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
2PJ
WEBINREGD11 Tax representative registration Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
2Reprezentant
WEBINREGSPV Registration for individuals users in SPV: Register users, users Lost SPV Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
password , SPV credentials Recovery, Change SPV users email
WEBINREGUTI Users Registration for PATRIMVEN and ARB systems       RMS
LIZTERTEINST
IT
WEBIST318 History for 318, 319 returns Oracle 10g   Oracle RAC 10.2.0.3 - RMS
ORAHUB
WEBISTONRC History for ONRC associates / shareholders     Client webservice, uses RMS
webservice ONRC, Oracle data
378 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
base
WEBLISTAAN Employee list       RMS
GAJATI
WEBLOTONRC ONRC batch transmission Oracle 11g   Oracle RAC 11.2.0.4 - RMS
ORACENTR
WEBMDX Massive data exchange with Public Institutions     cm extranet RMS
WEBMON Site monitorization   monitor Web application on JBOSS RMS
WEB-Moodle Development and sustain courses on e-learning Moodle platform   Moodle Linux, proprietary technology Retain
Moodle
WEBNOTIF Notifications Oracle 11g   Oracle RAC 11.2.0.3 - DWRAC RMS
WEBNOUTATI Display of news on ANAF internet portal       RMS
WEBNREVIDE Generation of payment evidence number under ANAF Order 1870/2012       RMS
NTA
WEBPATRIM Public institutions assets publishing on MFP website   PATRIM Web application on IBM WAS RMS
WEBPERISABI Capitalization of perishable goods     Oracle 10.2.0.1 - ORCB (CM) RMS
LE
WEBPUBL Publish portal documents DB2   DB2 - driver type: 4, database RMS
name: licita, server name: idb1
port: 60300
WEBPUBMFP MFP Website publishing     Web application on IBM WAS Out of scope
WEBRAP Activity report application     Web application on IBM WAS Out of scope
WEBRAPOART Displaying reports for PATRIMVEN system, views for building sites,     Oracle RAC 11.2.0.3 - DWRAC Interoperability
EPATRIMVEN Contributions, lands, vehicles, Banks
WEBRAPSPV Reports for Virtual Private space approvals     Oracle 10.2.0.1 - ORCB (CM) RMS
WEBREINNOIR Qualified certificates renewal     Oracle 10.2.0.1 - ORCB (CM) RMS
E
WEBRESTANT Past due obligations to the budgets Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
E
WEBRESURSE Resource loading application for ANAF internet portal     DB2 - driver type: 4, database RMS
name: licita, server name: idb1
port: 60300
WEBRGPITVA Register for taxable persons registered for VAT purposes     Oracle 10.2.0.1 - ORCB (CM) RMS
WEBRGPITVAI Register of taxable persons applying VAT on collection system     Oracle 10.2.0.1 - ORCB (CM) RMS
NCASARE
WEBRobotD112 Monitoring submission of online statements   Dec_Declaratii Web application on IBM WAS RMS
WEBRSSMFP RSS Feed application for MFP website   SITEMF Web application on IBM WAS RMS
WEBSCHIMBA ANAF-ARB Information Exchange Application       RMS
RB
WEBSITEMFP MFP Website   SITEMF Aplication deployed on WAS Out of scope
server
WEBSITEUPDA Website information publishing application   SITEMF Web application on IBM WAS Out of scope
TE
WEBSMS Data access via SMS at 1300 number Oracle 10g   Oracle 10.2.0.1 - ORCB (CM) RMS
Section V. Requirements of the Information System 379

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
WEBSTARED11 Returns state viewing Oracle 10g   Oracle RAC 10.2.0.4 - MQDEC RMS
2 (DEDOC)
WEBSTATICHT Display information on ANAF internet portal       RMS
MLRENDER
WEBSWISS Site Swiss-Contribution   SWISS Web application on IBM WAS Out of scope
WEBSWISSUP Publish information on the Swiss-Contribution website   SWISS Web application on IBM WAS Out of scope
DATE
WEBTaxe Fiscal and non fiscal duties register   TAXE Web application on IBM WAS Interoperability
WEBTHEMES Applications for themes customization related to the Internet portal, Intranet     Nu foloseste sursa de date DROP
and Extranet (skins, banners, horizontal menu, vertical menu)
WEBTRAFIC Application for tax codes querying   CODFISC Web application on IBM WAS RMS
WEBTREZOR Reports for Treasury excerpts Oracle 11g   Oracle RAC 11.2.0.3 - DWRAC Interoperability
WEBTVAUE Submitting declarations for VAT repayment from EU Oracle 10g   Oracle RAC 10.2.0.3 - RMS
ORAHUB
WEB- Central Harmonization Unit application of Financial Management and Control   UCASMFC   Out of scope
UCASMFC System
WEBVIZBIL Show balances attachments Oracle 10g   Oracle RAC 10.2.0.4 - MQDEC RMS
(DEDOC)
WEBVOES Web application to access VOES application using MFP site.       Interoperability
WEBWSTAM web service for registering users in TAM       RMS
WEBZIARISTI Journalists accredited by the MFP   SITEMF Web application on IBM WAS Out of scope
DWCNPAS Loading data provided on CD by CNPAS into the central database in Oracle       RMS
10g. Information processing CNPAS in conjunction with the ANAF (based on
nominal returns related Annexes A1.2 highlighted in art. 6 of the L19 / 2000)
to obtain lists / special records provided in order ANAF President 94/2009.
Making reports on the lists / Special records set in order and submission to the
Department of Tax Information.
PATRIMVEN It contains documents related to PATRIM application deployment. The       Interoperability
application can be used by members of a group, depending on the interests and
rights of access granted. Beneficiaries Control Department, Legal Department,
any individual or company
PEAG The application receives payment orders (from agencies pay) in electronic       Out of scope
format and records them in Treasury accounts. Sending payment orders
electronically streamlines work with the agencies they pay a huge number of
orders in certain periods.
PresaANAF NAFA Press Disclosures       Retain
DEZVALUIRI DataBase ANAF stores PRESS news articles related to the
work of Ministry of Finance and ANAF. It can be used by members of a
group, depending on the interests and rights of access granted. Access is
public MFP and ANAF staff and view information from the base can be done
through the browser. The base is located on a central server, access to it is
possible for users who have a Lotus-desktop client installed on their computer,
connection to network MFP and access rights granted by the manager
(administrator) basis. Access level can be: Author, Reader, Manager. "
380 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
PRIME "Based on data classification and current month presence, it calculates       Retain
employee bonuses of ANAF (advance, CO, CM, bonuses, incentives,
liquidation, other payments). Made in DOS FoxPro language. It is in operation
and approximately 35 external customers (ie the Prime Minister, the
Ombudsman, the European Institute of Romania, etc) Structures uses SI:
Budget and Accounting Departments of Homeland Financial Services
Accounting The redesigned PHARE2005 - SPIN "
SALARII FOX "Based on data classification and current month presence, calculates the wage       DROP
(advance, CO, CM, bonuses, incentives, liquidation, other payments). Made in
DOS FoxPro language. It is in operation and approximately 35 external
customers (ie the Prime Minister, the Ombudsman, the European Institute of
Romania, etc) Structures uses SI: Budget and Accounting Departments of
Homeland Financial Services Accounting The redesigned PHARE2005 -
SPIN "
SEP Protection of computing equipment (servers and workstations) against       RMS
computer viruses and malicious software
STAFCT "STAFCT application is a component of the information system       Out of scope
BUGETNG_V1. During a budget year STAFCT component interact with
STAREC budget component of the application BUGETNG_V1 and
STAMOD component of the application BUGETNG_V3. The system
addresses the principal loan, DGIT DG Budget planning, budget policy DG of
MFP. The application runs on central servers MFP, providing virtual private
data network MFP possibility of direct accessing of information by extranet
and intranet users. Each OPC from central government has access to the
computer system, and based on assigned roles can perform data acquisition
operations, data verification, editing work situations, to develop initial annual
budget law. They established roles and internal users of the MFP. "
STAMOD "The application STAMOD is part of the computer system BUGETNG_V3.       Out of scope
During a budget year STAMOD component interact with STAFCT budget
components of the application STAREC BUGETNG_V1 using specific tables
common with BUGETNG_V1 application. STAMOD application addresses
the principal loan, DGIT and D. G. Programming MFP budget. The
application allows updating budgetary provisions approved for the current
year, with changes occurring in the basis of ordinances, government decisions
or laws other than the laws amending, aiming number of jobs or the related
salary fund. By using this application the database which is needed to rectify
the approved budget is updated, and constitutes the basis for next year's
budget. "
STAMURI STAMURI computer application addresses the principal loan, DGIT and D. G.       Out of scope
Programming MFP budget. It allows updating the approved budgetary
provisions of Annex 03 (with forms 06.17, 04) and 04 (with forms 03 04).
These changes made in the basis of Ordinances or GD, target number of jobs
or the related salary fund. By using this application the database which is
needed to rectify the approved budget is updated, and constitutes the basis for
next year's budget.
Section V. Requirements of the Information System 381

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
Users, Beneficiaries:
The application has direct users of the services employees / departments
within the scope (Budget and human resources service).
Input / output volume:
Primary data entry are:
- Documents "M" elaborated on the basis of normative acts of the principal
loan completed, the number of positions and corresponding salary fund.
The output data are:
- Annexes specific number of positions and corresponding salary fund.
- Situations for centralizing budgetary annexes 03 (with forms 06.17, 04) and
04 (with forms 03 04) the number of positions and corresponding salary fund.
Data volume: Depending on the period.
STAREC "STAREC application is a component of the information system       Out of scope
BUGETNG_V1. During a budget year STAREC component interacts with
STAFCT budget component of the application BUGETNG_V1 and STAMOD
component of the application BUGETNG_V3. The system addresses the
principal loan, DGIT DG Budget planning, budget policy DG of MFP. The
application runs on central servers MFP, providing virtual private data
network MFP possibility of direct accessing of information by extranet and
intranet users. Each OPC from central government has access to the computer
system, and based on assigned roles can perform data acquisition operations,
data verification, editing work situations, to elaborate the law amending the
initial budget. They established roles and internal users of the MFP. "
Statef_L330 "Analysis of economy salary fund after applying uniform pay law in the       Out of scope
budget no. 330/2009. Collection of data on the salaries of staff employed in
public institutions, at the CNP, on 31 December 2009 and 30 April 2010.
Information for CNP refers to income structure, base salary and bonuses,
grouped by acts that led to the granting of their previous salary under the laws
L330 / 2009, according to the decisions of local councils or court orders. "
STIM "Based on data classification and this month, calculates employee incentives       DROP
of ANAF (advance, CO, CM, bonuses, incentives, liquidation, other
payments). Made in DOS FoxPro language. It is in operation and
approximately 35 external customers (ie the Prime Minister, the Ombudsman,
the European Institute of Romania, etc) Structures uses SI: Budget and
Accounting Departments of Homeland Financial Services Accounting.
Redesigned in PHARE2005 - SPIN "
STRUCONTAB Accounting for post-accession structural funds as a monitoring agency       Out of scope
_ACIS_AM Structures uses SI:
(Contabstru) Budget and Accounting Departments of Homeland financial services
accounting ACP CFCU, MEI, MIRA, Min.Muncii, ACIS, Min. transport
STRUCONTAB Accounting for post-accession structural funds as beneficiary       Out of scope
_ACIS_BEN
(StructBen,
ContabBen)
TB The app shows in real time the evolution of revenues to the state budget by the       Interoperability
382 Section V. Requirements of the Information System

App. CODE - Description – EN D.B. Database Name Datasource RMS

Adopted Assessment
NAME DESCRIPTION       N/A
Treasury.
URMFMI Data management on salary related expenses for state companies monitored       Out of scope
by the IMF: collecting and transmitting data by companies, data centralization
by the General Directorate of Legislation and State Assets Regulatory,
drafting reports of DGIT on request
WEBDECLFIZI Individuals submitting returns       RMS
CE
WEBINREGAD The enrollment of system administrators for FOREXEBUG       Interoperability
MINFOREXE
WEBINREGAD Registration for system administrators for ARB and PATRIMVEN       Interoperability
MINTERTEINS
TIT (city halls,
banks, ...)
WEBINREGUTI Registers users for the systems PATRIMVEN and ARB       Interoperability
LIZTERTEINST
IT
WEBJOCURI Application publishing gambling information       RMS
WEB-MINIMIS Deposit MINIMIS funding requests       RMS
MonitorSP Monitors collection Oracle 10g centralized Web application on IBM WAS RMS
Certificate_rezid Informations about the non-resident fiscal entities Oracle 10g centralized Web application on IBM WAS RMS
enta
Sanct_int Intenational sactions Oracle 10g centralized Web application on IBM WAS Retained
Legend:
RMS Expected to be replaced by the Revenue Management System (RMS)
Out of scope This application is out of scope for the implementation of the RMS
Interoperability Interoperability is needed with this applications, for various reasons (e.g.
interface with the Tax payer Register, or the different nomenclatures, etc.)
RETAIN This application will be retained as it is, not in scope for the implementation of
the RMS, no expected interoperability or interfacing
Section V. Requirements of the Information System 383

External systems and interfaces

No. Name of the data exchange partner (institution) Short name of Data Exchange Format
institution

1 National Agency for Payments and Social Inspection ANPIS Oracle .DMP files
2 Romanian Naval Authority ANR Oracle .DMP files
3 Administration of the State Domains ADS MS Excel files (.XLS)
4 Environment Fund Administration AFM .PDF files, in .ZIP archives
5 Funding Agency for Rural Investment AFIR <N/A> currently under implementation
6 Romanian Agency for Digital Agenda AADR <N/A> currently under implementation
7 Agency for Payments and Intervention in Agriculture APIA Variable length ASCII files with separators and
limiters (.CSV) + Extended markup language files
(.xml)
8 National Agency for Cadastre and Land Registration ANCPI Variable length ASCII files with separators and
limiters (.CSV) + Extended markup language files
(.xml)
9 National Integrity Agency ANI Variable length ASCII files with separators and
limiters (.CSV) + Extended markup language files
(.xml)
10 National Agency for Employment ANOFM Archived Oracle .DMP files
11 Romanian Banks Association ARB .PDF files with attached .xml files
12 Romanian Civil Aeronautical Authority AACR Variable length ASCII files with separators and
limiters (.CSV) + Extended markup language files
(.xml)
13 Financial Supervisory Authority ASF 1st year (2015): MS Excel .XLS files / After 1st
year: Extended markup language files .xml
384 Section V. Requirements of the Information System

14 The National Sanitary Veterinary and Food Safety ANSVSA Variable length ASCII files with separators and
Authority limiters (.CSV) + Extended markup language files
(.xml)
15 The Authority for State Assets Recovery AVAS Variable length ASCII files with separators and
limiters (.CSV) + Extended markup language files
(.xml)
16 The National Bank of Romania BNR Variable length ASCII files with separators and
limiters (.TXT)
17 Chamber of Commerce and Industry of Romania CCIR MS Excel files (.XLS) + .PDF files
18 Sectorial Pension Fund of Ministry of Defense CPSM Variable length ASCII files with separators and
limiters (.TXT)
19 National Health Insurance House CNAS Oracle .DMP files
20 National House of Public Pensions CNPP Variable length ASCII files with separators and
limiters (.TXT)
21 Health Insurance House of Defense, Public Order, OPSNAJ Variable length ASCII files with separators and
National Security and Judicial Authority limiters (.CSV)
22 National Company of Motorways and National Roads CNADR MS Excel files (.XLS) + .PDF files
in Romania
23 County Councils CJ Webservice
24 COMPETITION COUNCIL CC Webservice
25 National Broadcasting Council CAN Webservice
26 General Directorate for Intelligence and Internal DGIPI Variable length ASCII files with separators and
Protection limiters (.CSV)
27 General Directorate of Fisheries AMPOP Variable length ASCII files with separators and
limiters (.CSV)
28 National Institute of Research - Development in ICI E-Mail messages
Informatics
Section V. Requirements of the Information System 385

29 National Institute of Statistics INS Variable length ASCII files with separators and
limiters (.TXT)
30 State Inspectorate for Control in Road Transport ISCTR MS Excel files (.XLS) + .PDF files
31 MINISTRY OF INTERIOR MAI Oracle .DMP files
32 MAI - Directorate for Persons Record and Databases DEPABD ASCII .TXT Files
Management
33 MAI - License and Vehicle Registration Department DRPIV Online Extranet Portal Access
34 MAI - Romanian Immigration Office ORI MS Excel .XLSX Files
35 M.M.F.P.S. - Work Inspection IM Not decided yet
36 Ministry for Information Society - Agricultural MSI Shareplex Database replication
Register
37 Ministry of Agriculture and Rural Development MADR Log files, ASCII variable length .TXT Files, other
formats as per the case
38 MAI - General Anticorruption Division MAI – DGA Log files, ASCII variable length .TXT Files, other
formats as per the case
39 Ministry Of Justice MJ Log files, ASCII variable length .TXT Files, other
formats as per the case
40 Ministry of Justice - National Trade Register Office ONRC ASCII .TXT Files- the data flow (.TXT) regarding
the register data about the new companies /
individuals (PFA) / etc.
Web Service for the Insolvency Procedures
Bulletin

41 Ministry of Labor, Family and Social Protection MMFPS Log files, ASCII variable length .TXT Files, other
formats as per the case
42 Ministry for Information Society MSI Shareplex Database replication
386 Section V. Requirements of the Information System

43 Ministry of Public Prosecutor's Office - High Court of MPPICCJ Log files, ASCII variable length .TXT Files, other
Cassation and Justice formats as per the case
44 Ministry of Transport - Romanian Road Authority ARR Variable length ASCII files with separators and
limiters (.TXT)
45 Ministry of Transport and Infrastructure MTI Log files, ASCII variable length .TXT Files, other
formats as per the case
46 NATIONAL OFFICE for Gambling ONJN Log files, ASCII variable length .TXT Files, other
formats as per the case
47 National Office for Preventing and Combating Money ONPCSB Data Export: Oracle .DMP files, Shareplex
Laundering database replication, Webservice
48 Romanian Copyright Office ORDA Log files, ASCII variable length .TXT Files, other
formats as per the case
49 Romanian Patriarchate PR Log files, ASCII variable length .TXT Files, other
formats as per the case
50 Special Telecommunications Service STS Data Export: Oracle .DMP files, Shareplex
database replication, Webservice
51 Government Secretary General SGG <N/A> currently under implementation
52 National Union of Bailiffs UNEJ Variable length ASCII files with separators and
limiters (.CSV)
53 Romanian Automotive Registry RAR Webservice
54 Romanian National Lottery Company CNLR <N/A> currently under implementation
55 Other tax administrations from countries which are part AEOI (Standard for Automatic Exchange of
Other Competent
of the cooperation memorandum between tax Financial Account Information in Tax Matters),
Authorities for
authorities to automatic exchange of financial account which include automatic interfaces for data
Tax
information (Council Directive 2011/16/EU, Council exchange (3)
Administration
Directive 2014/107/EU and others related legislation)
Section V. Requirements of the Information System 387

Note:
1 All the data exchange protocols are bi-directional, with data and transmission control flows, automatic and manual transmission
and recovery mode.
2 Information is dated: July 2015
3 More details about the data exchange protocols are available here: http://www.oecd.org/ctp/exchange-of-tax-
information/automatic-exchange-financial-account-information-common-reporting-standard.PDF (data source: OECD). The
automatic data exchange (AEOI) will be done via the Romanian AEOI system (currently under implementation)
388 Section V. Requirements of the Information System

Standard Forms
The following catalog the standard forms used by ANAF, the technology, and the references to instructions (as posted on-line at
www.anaf.ro)

Support program / Work instructions / Documentation

Name of the form / Programe asistenţă /
Denumire formular
PDF JAVA Instrucţiuni/ Documentaţie
soft J* Validation annex
100 – Tax Return regarding the fiscal obligations to the state budget, according to OPANAF 123/ XSD Schema
29.01.014, in force starting with 01/2014 – updated on 19.01.2015 D100 Declaration submission guide
soft A
100 - Declaraţie privind obligaţiile de plată la bugetul de stat, conform OPANAF 123/ 29.01.2014 Anexa validări
valabil începând cu 01/2014 - actualizat în data de 19.01.2015 Schema XSD
Ghid de depunere a declaraţiei D100
Validation annex
100 – Tax Return regarding the fiscal obligations to the state budget, according to OPANAD 3136/ XSD Schema
26.09.2013 – updated on 20.01.2014 D100 Declaration submission guide
soft A
100 - Declaraţie privind obligaţiile de plată la bugetul de stat, conform OPANAF 3136/ 26.09.2013 Anexa validări
- actualizat în 20.01.2014 Schema XSD
Ghid de depunere a declaraţiei D100
100 – Tax Return regarding the fiscal obligations to the state budget, according to OPANAF 1135/ soft A Validation annex
30.07.2012 for year 2012 – updated on 28.12.2012 XSD Schema
D100 Declaration submission guide
100 - Declaraţie privind obligaţiile de plată la bugetul de stat, conform OPANAF 1135/ 30.07.2012
pentru an 2012 - actualizat în 28.12.2012 Anexa validări
Schema XSD
Ghid de depunere a declaraţiei D100
Section V. Requirements of the Information System 389

Support program / Work instructions / Documentation

Name of the form / Programe asistenţă /
Denumire formular
PDF JAVA Instrucţiuni/ Documentaţie

100 – Tax Return regarding the fiscal obligations to the state budget, according to OP ANAF Validation annex
1932/2011, used starting with declaring tax liabilities for the month of November 2011 – updated XSD Schema
on 12.01.2012 D100 Declaration submission guide
soft A
100 - Declaraţie privind obligaţiile de plată la bugetul de stat, conform OP ANAF 1932/2011, Anexa validări
utilizată începând cu declararea obligaţiilor fiscale aferente lunii noiembrie 2011 -  actualizat în Schema XSD
12.01.2012 Ghid de depunere a declaraţiei D100

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii

Support program / Work instructions /

Programe asistenţă Documentation
Name of the form /
/
Denumire formular
PDF JAVA Instrucţiuni/
Documentaţie

101 – Statement of income tax, according to OPANAF no. 4024/ 23.12.2014 (M.OF. no.2/05.01.2015) – in force Validation annex
starting with year 2014 – updated on 26.02.2015 XSD Schema
soft A soft J*
101 - Declaraţie privind impozitul pe profit, conform OPANAF nr. 4024/ 23.12.2014 (M.OF. nr.2/ 05.01.2015) - Anexa validări
valabil incepand cu anul 2014 - actualizat 26.02.2015 Schema XSD
390 Section V. Requirements of the Information System

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA
Instrucţiuni/

101 – Statement of income tax, according to OPANAF no. 1950/2012 – updated on 24.01.2014 (update for legal
entities which on 31.12 fulfills the condition of tax payers of microenterprise incomes cf. art. 112^2 alin.(3) from
L. 571/2003)

For the previous reporting periods of 2014, statement 101 can be downloaded from ANAF portal section of Validation annex
useful programs. XSD Schema
soft A soft J*
101 - Declaraţie privind impozitul pe profit, conform OPANAF nr. 1950/2012 - actualizat în data de 24.01.2014 Anexa validări
(actualizare pentru persoanele juridice care la 31.12 îndeplinesc condiţiile de plătitor de impozit pe veniturile Schema XSD
microintrep. cf. art. 112^2 alin.(3) din L. 571/2003)

Pentru perioadele de raportare anterioare anului 2012, declaraţia 101 se poate descărca de pe portalul ANAF
secţiunea programe utile şi se pot depune numai la ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 391

Support program / Work instructions /

Programe asistenţă Documentation
Name of the form /
/
Denumire formular
PDF JAVA Instrucţiuni/
Documentaţie

104 – Statement on the distribution between associates of incomes and expenses, according to OPANAF no. Validation annex
1950 from 13.12.2012 – updated on 27.01.2014 XSD Schema
soft A soft J*
104 - Declaraţie privind distribuirea între asociaţi a veniturilor şi cheltuielilor, conform OPANAF nr. 1950 din Anexa validări
13.12.2012 - actualizat în data de 27.01.2014 Schema XSD

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
392 Section V. Requirements of the Information System

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie

106 – Informative statement regarding the dividends to shareholders, according to OPANAF 1292/ Validation annex
20.05.2014; in force starting with 03.06.2014 – published on 04.06.2014 XSD Schema
soft A soft J*
106 - Declarație informativa privind dividendele cuvenite acționarilor, conform OPANAF 1292/ Anexa validări
20.05.2014; valabil începând cu 03.06.2014 - publicat in data de 04.06.2014 Schema XSD

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 393

Support program / Work instructions /

Name of the form / Programe Documentation
Denumire formular asistenţă /
PDF JAVA Instrucţiuni/ Documentaţie
soft J*

112 – Tax Return regarding the fiscal obligations of social contributions, income tax and the nominal records of
insured persons – according to Order of the Minister of Public Finance no. 1977/ 09.12.2013, Minister of Labor,
Family, Social Protection and elderly persons, no. 2757/ 23.12.2013 and Minister of Health no. 1580/ 23.12.2013, Validation annex
in force starting with 01/2015 – updated on 03.03.2015 XSD Schema
soft A
112 - Declaraţia privind obligaţiile de plată a contribuţiilor sociale, impozitului pe venit si evidenţa nominală a Schema XSD
persoanelor asigurate - conform Ordinului comun al ministrului finanţelor publice nr.1977/ 09.12.2013, ministrului Anexa validări
muncii, familiei, protecției sociale şi persoanelor vârstnice nr.2757/ 23.12.2013 şi al ministrului sănătăţii nr. 1580/
23.12.2013, valabil începând cu 01/2015 - actualizat în data  03.03.2015

Validation annex
112 – Tax Return regarding the fiscal obligations of social contributions, income tax and the nominal records of XSD Schema
insured persons – according to Order of the Minister of Public Finance no. 1977/ 09.12.2013, Minister of Labor, For more info click AICI
Family, Social Protection and elderly persons, no. 2757/ 23.12.2013 and Minister of Health no. 1580/ 23.12.2013,
in force starting with 01/2014 – updated on 04.12.2014
soft A
Schema XSD
112 - Declaraţia privind obligaţiile de plată a contribuţiilor sociale, impozitului pe venit si evidenţa nominală a Anexa validări
persoanelor asigurate - conform Ordinului comun al ministrului finanţelor publice nr.1977/ 09.12.2013, ministrului
muncii, familiei, protecției sociale si persoanelor vârstnice nr.2757/ 23.12.2013 şi al ministrului sănătăţii nr. 1580/
23.12.2013, valabil începând cu 01/2014 - actualizat in data  04.12.2014 Pentru mai multe informaţii
click AICI

112 – Tax Return regarding the fiscal obligation of social contributions, income tax and the nominal records of soft A Validation annex
insured persons – according to Order of the Minister of Public Finance, Minister of Labor, Family and Social For more info click AICI
Protection and Minister of Health no. 1045 – (available for year 2013) updated on 19.09.2013
Anexa validări Pentru mai
112 - Declaraţia privind obligaţiile de plată a contribuţiilor sociale, impozitului pe venit si evidenţa nominală a multe informaţii click AICI
394 Section V. Requirements of the Information System

persoanelor asigurate - conform Ordinului comun al ministrului finanţelor publice, ministrului muncii, familiei şi
protecţiei sociale şi al ministrului sănătăţii nr. 1045 - (valabilă pentru anul 2013) actualizată în data de 19.09.2013
112 – Tax Return regarding the fiscal obligations of social contributions, income tax and nominal records of
insured persons – according to Order of Minister of Public Finance, Minister of Labor, Family and Social
Protection and Minister of Health no. 1045 – (in force starting with January 2012) updated on 20.09.2012 For more info click AICI
soft A
112 - Declaraţia privind obligaţiile de plată a contribuţiilor sociale, impozitului pe venit si evidenţa nominală a Pentru mai multe informaţii
persoanelor asigurate - conform Ordinului comun al ministrului finanţelor publice, ministrului muncii, familiei şi click AICI
protecţiei sociale şi al ministrului sănătăţii nr. 1045 - (valabilă începând cu ianuarie 2012) actualizată in data de
20.09.2012

112 – Tax Return regarding the fiscal obligations of social contributions, income tax and nominal records of
insured persons – according to Government of Romania no. 1397/2010 – (in force stating with January 2011)
For more info click AICI
updated on 30.11.2011
soft A
Pentru mai multe informaţii
112 - Declaraţia privind obligaţiile de plată a contribuţiilor sociale, impozitului pe venit si evidenţa nominală a
click AICI
persoanelor asigurate - conform Hotărârii Guvernului României nr. 1397/2010 -(valabilă începând cu ianuarie
2011) actualizată în data de 30.11.2011

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 395

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie
Validation annex
120 – Statement regarding the excise, according to OPANAF no. 123/2014 – published on 06.03.2014 XSD Schema
soft A soft J*
120 - Decont privind accizele, conform OPANAF nr. 123/2014 - publicat in data de 06.03.2014 Anexa validări
Schema XSD

120 – Statement regarding the excises, according to OPANAF no. 1950/2012 – updated on 01.04.2013

For the previous reporting periods of 2013, statement 120 can be downloaded from ANAF portal section of useful Validation annex
programs and it can be submitted only at the counter. XSD Schema
soft A soft J*
Anexa validări
120 - Decont privind accizele, conform OPANAF nr. 1950/2012 - actualizat în data de 01.04.2013  Schema XSD

Pentru perioadele de raportare anterioare anului 2013, declaraţia 120 se poate descărca de pe portalul ANAF
secţiunea programe utile şi se pot depune numai la ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
396 Section V. Requirements of the Information System

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie

130 – Tax Return regarding the oil from internal production, according to OPANAF no. 1950/2012 –
updated on 24.01.2014

For the previous reporting periods of 2013, statement 130 can be downloaded from ANAF portal section of Validation annex
useful programs and it can be submitted only at the counter. XSD Schema
soft A soft J*
130 - DECONT PRIVIND IMPOZITUL LA ŢIŢEIUL DIN PRODUCŢIA INTERNĂ, conform OPANAF Anexa validări
nr. 1950/2012 - actualizat în data de 24.01.2014 Schema XSD

Pentru perioadele de raportare anterioare anului 2013, declaraţia 130 se poate descărca de pe portalul ANAF
secţiunea programe utile şi se pot depune numai la ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 397

Support program / Work instructions /

Programe asistenţă Documentation
Name of the form /
/
Denumire formular
PDF JAVA Instrucţiuni/
Documentaţie

205 – Informative statement on withholding tax and realized incomes/loses, on income beneficiaries, according to ANAF Validation annex
Order 3883/2013 (starting with reporting year 2013) – updated on 20.02.2015 XSD Schema
soft A soft J*
205 - Declaraţie  informativă privind impozitul reţinut la sursă şi câştigurile/pierderile realizate, pe beneficiari de venit, Anexa validări
conform Ordinului ANAF 3883/2013 ( începând cu anul de raportare 2013 ) - actualizat în 20.02.2015 Schema XSD

205 – Informative statement on withholding tax and realized incomes/loses, on income beneficiaries, according to ANAF Validation annex
Order 1913/212 – (available for the reporting year 2012) updated on 09.04.2013 XSD Schema
soft A soft J*
205 - Declaraţie  informativă privind impozitul reţinut la sursă şi câştigurile/pierderile realizate, pe beneficiari de venit, Anexa validări
conform Ordinului ANAF 1913/2012 -( valabil pentru an raportare 2012 ) actualizat în 09.04.2013 Schema XSD

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
398 Section V. Requirements of the Information System

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie
Validation annex
XSD Schema
300 – Value Added Tax Return according to OPANAF no. 1790/2012, used starting with declaring tax D300 Declaration submission
liabilities available starting with 01.01.2013 – updated on 24.01.2014 guide
soft A
300 - Decont de taxă pe valoarea adăugată conform OPANAF nr. 1790/2012, utilizat începând cu declararea Anexa validări
obligaţiilor fiscale valabil de la data 01.01.2013 - actualizat în data de 24.01.2014 Schema XSD
Ghid de depunere a declaraţiei
D300
Validation annex
XSD Schema
300 – Value Added Tax Return according to OPANAF no. 3665/22.12.2011, used starting with declaring tax D300 Declaration submission
liabilities available starting with 01.01.2012 – updated on 06.03.2012 guide
soft A soft J*
300 - Decont de taxă pe valoarea adăugată conform OPANAF nr. 3665/22.12.2011, utilizat începând cu Anexa validări
declararea obligaţiilor fiscale valabil de la data 01.01.2012 - actualizat în data de 06.03.2012 Schema XSD
Ghid de depunere a declaraţiei
D300
Validation annex
XSD Schema
300 – Value Added Tax Return according to OPANAF no. 183/31.01.2011, used starting with declaring tax D300 Declaration submission
liabilities related to November 2011 – updated on 15.01.2012 guide
soft A
300 - Decont de taxă pe valoarea adăugată conform OPANAF nr. 183/31.01.2011, utilizat începând cu Anexa validări
declararea obligaţiilor fiscale aferente lunii noiembrie 2011 - actualizat în data de 15.01.2012 Schema XSD
Ghid de depunere a declaraţiei
D300

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 399
400 Section V. Requirements of the Information System

Support program / Work instructions /

Programe asistenţă Documentation
Name of the form /
/
Denumire formular
PDF JAVA Instrucţiuni/
Documentaţie
301 – version 4 – Special Value Added Tax Return, according to OPANAF 75/2010 – for the reporting period starting
with January 2013, updated on 04.03.2015

For the previous reporting periods of year 2013, statement 301 can be downloaded from ANAF portal section of useful Validation annex
programs and it can be submitted only at the counter. XSD Schema
soft A soft J*
301 - versiunea 4 - Decont special de taxa pe valoarea adăugată, conform OPANAF 75/2010 - pentru perioada de Anexa validări
raportare începând cu ianuarie 2013, actualizat în data de 04.03.2015 Schema XSD

Pentru perioadele de raportare anterioare anului 2013, declaraţia 301 se poate descărca de pe portalul ANAF secţiunea
programe utile şi se pot depune numai ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 401

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie
Validation annex
XSD Schema
390 – Review statement regarding intercommunity goods deliveries/acquisitions, according to OP ANAF no. D390 Declaration submission guide
76/21.01.2010, used starting with declaring tax liabilities related to month December of 2011 – updated on Legal Provisions for completing the
24.01.2014 390 form
soft A soft J*
390 - Declaraţie recapitulativă privind livrările/achiziţiile intracomunitare de bunuri, conform OP ANAF Anexa validări
nr.76/21.01.2010, utilizat începând cu declararea obligaţiilor fiscale aferente lunii decembrie 2011 - Schema XSD
actualizat în data de 24.01.2014 Ghid de depunere a declaraţiei D390
Prevederi legale de completare a
formularului 390

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
402 Section V. Requirements of the Information System

Support program / Work instructions /

Programe asistenţă Documentation
Name of the form /
/
Denumire formular
PDF JAVA Instrucţiuni/
Documentaţie
390 – Informative statement regarding goods delivery and provision of services performed according to OPANAF
no. 93/ 21.01.2014 – starting with the reporting year 2014 – updated on 23.02.2015

For the previous reporting periods of year 2014, statement 392 can be downloaded from ANAF portal section of Validation annex
useful programs and it can be submitted only at the counter. XSD Schema
soft A soft J*
392 - Declaraţie informativă privind livrările de bunuri şi prestările de servicii efectuate conform OPANAF nr.93/ Anexa validări
21.01.2014 - începând cu anul de raportare 2014 - actualizat 23.02.2015 Schema XSD

Pentru perioadele de raportare anterioare anului 2014, declaraţia 392 se poate descărca de pe portalul ANAF
secţiunea programe utile şi se pot depune numai ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
Section V. Requirements of the Information System 403

Support program / Work instructions /

Programe Documentation
Name of the form /
asistenţă /
Denumire formular
Instrucţiuni/
PDF JAVA Documentaţie
393 – Informative statement regarding incomes obtained from selling of international passenger road transport, leaving
from Romania according to OPANAF no. 1081/ 07.02.2011 – starting with the reporting year 2014 – updated on
12.02.2015

For the previous reporting periods of year 2014, statement 393 can be downloaded from ANAF portal section of useful Validation annex
programs and it can be submitted only at the counter. XSD Schema
soft A soft J*
393 - Declaraţie informativă privind veniturile obţinute din vânzarea de bilete pentru transportul rutier internaţional de Anexa validări
persoane, cu locul de plecare din România conform OPANAF nr.1081/ 07.02.2011 - începând cu anul de raportare 2014 - Schema XSD
actualizat 12.02.2015

Pentru perioadele de raportare anterioare anului 2014, declaraţia 393 se poate descărca de pe portalul ANAF secţiunea
programe utile şi se pot depune numai ghişeu.

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
404 Section V. Requirements of the Information System

Support program / Work instructions /

Name of the form / Programe asistenţă Documentation
Denumire formular /
PDF JAVA Instrucţiuni/ Documentaţie
Validation annex
XSD Schema
394 – Informative statement regarding delivery/supplies and acquisitions performed on national territory D394 Declaration submission guide
according to OPANAF 3806/2013 – used starting with declaring tax liabilities related to month December Legal provisions for completing the
2013 – updated on 19.03.2015 394 form
soft A soft J*
Anexa validări
394 Declaraţie informativă privind livrările/prestările şi achiziţiile efectuate pe teritoriul naţional conform Schema XSD
OPANAF 3806/2013  - utilizat începând cu declararea obligaţiilor fiscale aferente lunii decembrie 2013 - Ghid de depunere a declaraţiei
actualizat in 19.03.2015 D394
Prevederi legale de completare a
formularului 394
Validation annex
XSD Schema
394 – Informative statement regarding delivery/supplies and acquisitions performed on national territory D394 Declaration submission guide
according to OPANAF 3596/2011 published in OM 927/28.12.2011 – used starting with declaring tax Legal provisions for completing the
liabilities related to month January 2012 – updated on 28.10.2013 394 form
soft A soft J*
Anexa validări
394 Declaraţie informativă privind livrările/prestările şi achiziţiile efectuate pe teritoriul naţional conform Schema XSD
OPANAF 3596/2011 publicat în MO 927/28.12.2011 - utilizat începând cu declararea obligaţiilor fiscale Ghid de depunere a declaraţiei
aferente lunii ianuarie 2012 - actualizat in 28.10.2013 D394
Prevederi legale de completare a
formularului 394
399– Special tax return for VAT, according to the Fiscal Code, art. 152.4 align. (7) and 152.6 align. (6), for
the period of time starting with April 2015 – published on 01.04.2015 soft J*
soft A
actualizat în Anexa validări
actualizat
399 Declaraţie specială de TVA, conform Codului Fiscal, art.152.4 alin. (7) si 152.5 alin.(6), pentru data de Schema XSD
în data de
perioada de raportare începând cu aprilie 2015 - publicat în 01.04.2015 23.04.201
09.04.2015
5
Section V. Requirements of the Information System 405

*software J is only for the tax payers which generate their own .xml file from their IT application software
 *softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
406 Section V. Requirements of the Information System

Support
program / Work instructions /
Name of the form / Programe Documentation
Denumire formular asistenţă /
Instrucţiuni/ Documentaţie
PDF JAVA
soft J* Validation annex
XSD Schema
710 – Honed statement, according to OPANAF 123/ 29.01.2014 in force starting with 01/2014 – updated D710 Declaration submission
on 19.01.2015 guide
soft A
710 - Declaraţie rectificativă, conform OPANAF 123/ 29.01.2014 valabil incepand cu 01/2014 - Anexa validări
actualizat în data de 19.01.2015 Schema XSD
Ghid de depunere a declaraţiei
D710
Validation annex
XSD Schema
D710 Declaration submission
710 – Honed statement, according to OPANAF 3136/ 26.09.2013 for year 2013 – updated on 04.10.2013
guide
soft A
710 - Declaraţie rectificativă, conform OPANAF 3136/ 26.09.2013 pentru an 2013 - actualizat în data de
Anexa validări
04.10.2013
Schema XSD
Ghid de depunere a declaraţiei
D710
Validation annex
XSD Schema
D710 Declaration submission
710 – Honed statement, according to OPANAF 1135/30.07.2012 – updated on 27.12.2012 guide
soft A
710 - Declaraţie rectificativă, conform OPANAF 1135/30.07.2012 - actualizat în data de 27.12.2012 Anexa validări
Schema XSD
Ghid de depunere a declaraţiei
D710
710 – Honed statement, according to OPANAF 1932/2011, used starting with declaration of tax soft A Validation annex
liabilities related to month November 2011 – updated on 30.11.2011 XSD Schema
D710 Declaration submission
710 - Declaraţie rectificativă, conform OPANAF 1932/2011, utilizată începând cu declararea obligaţiilor guide
Section V. Requirements of the Information System 407

Anexa validări
fiscale aferente lunii noiembrie 2011 - actualizat în data de 30.11.2011 Schema XSD
Ghid de depunere a declaraţiei
D710

*software J is only for the tax payers which generate their own .xml file from their IT application software
*softul J se adresează doar contribuabililor care îşi generează fişierul xml din aplicaţiile informatice proprii
408 Section V. Requirements of the Information System

ANAF’s Taxpayer Services Contact Center

Avaya Aura Contact Centre rel. 6.0

ANAF’s Taxpayer Services Contact Center uses SIP (Session Initiation Protocol) along with
standard SOA and Web-services interfaces to support connectivity and establish collaborative
interaction sessions regardless of media type. Open Web services allow ANAF to integrate the
contact center with its databases and business applications to provide Contact Centre Agents with
real time and historical contextual information to improve the effectiveness of interactions with
the taxpayers.

Avaya Communication Server 1000 Switch rel. 7.5

The private branch exchange (PBX) or switch provides a speech path for a voice contact between
the source (usually a trunk) and the destination (a RAN - Recorded Trunk Announcement trunk,
voice port, or agent). Voice paths are connections that carry speech (phone calls). They are
configured as Terminal Numbers (TN) on the switch.

The Contact Center Manager Server communicates with the switch and the voice-processing
system.
The server runs applications and instructs the switch to configure the speech paths necessary to
connect calls to voice ports, agents, or RAN trunks, and to provide tone treatments (such as ring-
back and busy) to voice contacts.

The server communicates with the switch over the Embedded Local Area Network (ELAN)
subnet and the contact center subnet using the Application Module Link (AML) protocol.

Switch features
The Avaya Communication Server 1000 switch offers the following:
• Meridian Link Services (MLS)
• Avaya CallPilot
• Meridian Integrated Recorded Announcement (MIRAN).

Contact Center ANAF Current Setup

Multimedia Capability
Email (for Lotus Domino)  15 licenses available
 Scripts, Skillsets, Agents must be configured
Web Communications  6 licenses available
 Scripts, Skillsets, Agents must be configured
 Agents websites must be integrated with AACC
 Avaya offers an SDK for integration, but the integration
must be performed by the agents
Outbound  6 licenses available
 Campaigns, Agents must be configured
SMS Text  An SMS gateway is required, to convert the SMS texts
into E-mails to be received by AACC and further
distributed to agents
Faxed Document  2 fax licenses available
 By configuring the CallPilot Equipment, component of
the Contact Centre, 20 faxes can be sent to Agents.
Scanned Document  The Document Scans can be treated as E-mail
Section V. Requirements of the Information System 409

attachments
Voice Mail  100 voicemail inboxes are available
 8 simultaneous access channels are available to the Voice
Mail

The following diagram shows the high level architecture of the Contact Center.

Taxpayer
Rec ---
Name: Taxpayer
AACC One
Context Tel# 1234
Agen ID = 3000

Update ...

Oracle
Apex NAFA Taxpayer
API
DataBase
Taxpayer One
Caller ID 1234

Legend
Web Services Agent Assignment
with Screen-Popup
HTTP

Agent
3000
410 Section V. Requirements of the Information System

ANNEX 5: DETAILED FUNCTIONAL DESIGN GOALS

The following presents the detailed functional design goals arising from ANAF’s various business process re-engineering initiatives. Note:
these are NOT requirements of the System. Rather these represent the required point of departure for the Supplier’s Analysis and Detailed
Design Services (as specified in Paragraph 6.4 of the body of Technical Requirements).
Section V. Requirements of the Information System 411

1 – TAXPAYER REGISTRATION (TR)

ID Name Description
The system should provide a flexible graphical user interface that may be operated easily using personal computers with
TR-B-1 Equipment locale setting for Romania, a selection of the most popular web browsers, and printers connected locally or via the
Local Area Network.
Using the address - 3rd The system should be capable of using third party (e.g. Police, phone companies, etc.) data to process and validate
TR-F-2
party data addresses supplied by taxpayers in registration.
Using phone number - 3rd The system should be capable of using third party (e.g. Police, phone companies, etc.) data to process and validate
TR-F-3
party data phone data supplied by taxpayers during the registration process.
TR-F-4 TIN/PIN requirements Please see General Requirements.
Automatic allocation of The system should allocate to all taxpayers which do not start the registration process through the WEBSpace, with a
TR-F-5 username and temporary temporary username and password, which should be communicated together with the TIN (for traders) or through the
password – new taxpayers employer (for employees).
Automatic allocation of
For existing taxpayers, irrespective of their category, the system should allocate a temporary username and password
username and temporary
TR-F-6 for accessing the WEBSpace (practically, the account should be created by the Tax Administration), which should be
password – existing communicated to the taxpayer by Post to the declared address.
taxpayers
The traders should enter the supplied Use rid, provided at the Trade Registry and start the registration process in NAFA
WEBSpace account - First
TR01.1-F-1 systems. Non-traders should start the registration process creating a Use rid. Employees should enter the Use rid
log-in supplied by the employer and start the registration process.
WEBSpace account -
TR01.1-F-2 The taxpayer, previously registered, should be required to create a unique password.
Password creation
WEBSpace account -
TR01.1-F-3 The taxpayer should receive a standard notification that the account in the WEBSpace was created.
Notification
WEBSpace account - Data For traders and employees, part of the data should be automatically imported from Trade Registry database or from the
TR01.2-F-4
pre-filling return submitted by the employer.
WEBSpace account - Data The trader/employee should be asked to validate the pre-populated data in the system and complete the registration
TR01.2-F-5
filling/validation process with additional required data. The other taxpayers will fill in the information from scratch.
There should be only one central source for issuing the Taxpayer/Personal Identification number, which should be
TR01.2-F-6 Issuing the TIN/PIN unique.
Delivering registration
TR01.3-I-7 The Workflow subsystem should deliver the registration data from the website to the back-office for processing.
record to the back office
A service broker should select a single processing scenario in order to process a specific registration form (the scenario
TR01.4-F-8 SOA scenarios is composed of programmable objects required to process the Initial Taxpayer Registration record).
412 Section V. Requirements of the Information System

ID Name Description

Inspecting initial taxpayer All initial registration records should be inspected electronically by a back office programmable object for data integrity
TR01.4-F-9
registration data and errors missed during visual inspection.
Storing the record in the
TR01.4-F-10 All registration records should be stored on the central primary production facility databases.
database
TR01.4-O-11 Accepted omissions Initial registration applications should be allowed to have some omissions.
The Workflow system should be informed and the information should be moved to step TR01.7 in order to be
TR01.4-F-12 Workflow transmitted for registration audit.
Any defects in the registration record that caused the registration to be provisional/temporary should be noted in the
TR01.5-F-13 Recording defects taxpayer’s WEBSpace account.
Temporary or permanent The system should not issue a permanent TIN/PIN if electronic review of the registration data record contains
TR01.5-F-14
TIN/PIN omissions.
The system should parse (break apart) the incoming data stream in order to create an input suitable for storage in a
Parsing incoming initial
TR01.5-F-15 predefined relational database and be ready to create the proper accounts record required for posting to the Taxpayer
registration record Accounts Ledger.
Creating Taxpayer Risk
TR01.5-F-16 There should be an initial registration facility to create the Taxpayer’s Risk History and Profile account.
History and Profile
Create a Taxpayer
TR01.5-F-17 Account in the Taxpayer There should be an initial registration facility to establish the Taxpayers Account (in the Taxpayer Accounts Ledger).
Accounts Ledger
Create a Taxpayer
TR01.5-F-18 There should be an initial registration facility that creates the encrypted taxpayer WEBSpace account.
WEBSpace account
TR01.5-F-19 Document Management The registration file should be stored as a document in the DMS.
TR01.5-F-20 Statistical totalizer There should be an initial registration facility to update the registration totalizer by one.
Outreach Program - The production system should perform an outbound communication check for all forms of communications defined in
TR01.6-F-21
Communication check the registration record as part of the outreach program.
Outreach Program - Any communication method that fails during initial registration is an exception and should be noted as an error attached
TR01.6-F-22
Communication failure to the registration record for further processing.
Notice to Taxpayer A registration should require a notice be sent to the Registration Audit Department by Workflow, being placed in a
TR01.7-F-23
Registration Audit queue in order to be taken into consideration for verification.
Trade Registry - NAFA should issue a unique temporary TIN (marked with the letter “T”), upon notification that a trader has registered
TR01.8-F-24
Registration as a trader.
TR01.8-F-25 Trade Registry - NAFA shouldissue a temporary UserID and password, in order for the taxpayer to complete registration on the
Temporary WEBSpace account.
Section V. Requirements of the Information System 413

ID Name Description

UserID/Password
Trade Registry - Create
TR01.8-F-26 A Trade Registry record should create a WEBSpace account for the taxpayer.
WEBSpace account
WEBSpace account - Data
TR02.2-F-1 The system should allow updates for any registration information, through an "edit" functionality.
update
Delivering update record
TR02.3-F-2 The Workflow subsystem should deliver the registration update data from the website to the back-office for processing.
to the back office
Processing based on form
TR02.4-F-3 The back office should scan the incoming maintenance record for completeness.
type
Registration record Should the maintenance record update a registration that was incomplete and as a consequence of the update, the
TR02.4-F-4
completeness registration record becomes complete, the system should change the temporary or provisional TIN/PIN to permanent.
TR02.4-F-5 Statistical totalizer The statistical totalizers demonstrating a registration change record was processed should be incremented by one.
Registration database
TR02.4-F-6 The Registration RDBMS should be updated with maintenance records submitted by taxpayer.
updated
Taxpayer Risk History
The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
TR02.4-F-7 and Profile database Registration Record up to date).
update
Notice to Taxpayer
TR02.4-F-8 The system should send a notice to the Registration Audit unit indicating there is a change in registration record.
Registration Audit
TR02.4-F-9 Document Management The Registration Change Record should be stored as a document in the Document Management Subsystem.
Outreach Program –
TR02.5-F-10 The system should compose and send a short message notifying the taxpayer that the registration update was completed.
Short message
Posting in the WEBSpace
TR02.5-F-11 The system should post the change record and document to the taxpayer WEBSpace account.
account
Notice to Taxpayer The Workflow system should move the entire information pack related to the registration changed to TR08 Taxpayer
TR02.6-F-12
Registration Audit Registration Audit.
Delivery of a change from The Returns Processing pipeline should identify a change in registration record and while formulating the update to
TR03.1-F-1
Returns Processing Taxpayer Accounts Ledger; it should formulate a registration record and send it for Registration Processing.
Third party data
TR03.1-F-2 The registration data record should be verified by 3rd party data.
validation
Validation of registration
TR03.1-F-3 The system should compare the change with the current registration record.
change
414 Section V. Requirements of the Information System

ID Name Description

TR03.F.01 Exception declaration Changes with errors should be declared an exception and the exception should be attached to the change
record for taxpayer attention.
TR03.F.02 Recording exceptions to If there is an error, the system should not update the Registration database with the new data.
the Registration database
TR03.F.03 Recording changes to the Should there be no errors in the update record; the record should be treated as an update to the Registration
Registration database database.
TR03.F.04 Outreach Program - Should there be an error, the system should compose an error message to be sent to the taxpayer and append
Short Message it to the change record for further processing.
TR03.F.05 Taxpayer Risk History The registration change process should compose and post a record in the risk history and profile database
and Profile database indicating a change in registration record was successful (as a compliance indicator).
update
TR03.F.06 Notice to Taxpayer The registration change should trigger a notice to be sent to Registration Audit characterizing the changes
Registration Audit the taxpayer has made to their registration record.
TR03.F.07 Statistical totalizer The system should update the Registration Change totalizer by one record processed.
TR03.F.08 Document Management The Registration Change Record should be stored as a document in the Document Management Subsystem.
TR03.F.09 Outreach Program – A short message should be composed and transmitted to the taxpayer advising that the change has occurred.
Short message
TR03.F.10 Posting in the WEBSpace The change document should be posted together with any errors to the WEBSpace account.
account
TR04 – Re-Classify Taxpayer
TR04.F.01 Algorithm development NAFA and the developer should develop jointly an algorithm using the Taxpayer Accounts Ledger and
Returns Data to determine the size of a taxpayer.
TR04.F.02 Algorithm – Dashboard The system should permit a setting that selects only x number of taxpayers as “Large” and selects only y
setting number of taxpayers as “Medium”
TR04.F.03 Query the Taxpayer The system at a precise moment in time should interrogate the Taxpayer Accounts Ledger snapshot and
Accounts Ledger select in a descending order and according to the selection criteria provide by the law the largest x
contributors and y smallest contributors and create a list.
TR04.F.04 Execution of the Once the lists are set the reclassify taxpayer sub process should use the algorithm, determine the largest x
algorithm taxpayers for the Large Taxpayer Unit and y for the smaller of list of taxpayers who will become part of
medium Taxpayer Units.
TR04.F.05 Updating the registration The new designation should be uploaded into the registration database.
database
Section V. Requirements of the Information System 415

ID Name Description

TR04.F.06 Updating the Risk History The new designation should be uploaded into the Risk History and Profile Database to assist in
and Profile database classification and returns processing support.
TR04.F.07 Communicating the list to The system should reallocate the right to perform actions into the taxpayer’s fiscal record to the new Tax
the new Tax Administration.
Administration
TR04.F.08 Outreach Program – The system should compose and send a message informing the taxpayer regarding the status change.
Short message
TR04.F.09 WEBSpace posting The system should post the message into the WEBSpace account.
TR04.F.10 Updating the Taxpayer Taxpayer Risk History and Profile database should be updated with this change.
Risk History and Profile
Database
TR04.F.11 Statistical totalizer As a taxpayer is selected for large and medium taxpayer there will be specific data uploaded into the annual
promotion totalizer.
TR05 – Inactivate/Reactivate Taxpayer – based on voluntary decision (i.e. submitting an application)
TR05.F.01 Voluntary inactivation/ The taxpayer should be capable of declaring he is closing/suspending economic operations.
derogatory regime/
radiation declaration
TR05.F.02 Directed (ex-officio) The act of filing a request for inactivation or derogatory regime/radiation should prevent the Filer/Stop Filer
returns prevention subsystem from filing a directed (ex-officio) return.
TR05.F.03 Inactivation or derogatory A data verification operation that inspects the integrity of incoming inactivation or derogatory
regime/ radiation request regime/radiation records should be accomplished.
review
TR05.F.04 Notification to the Trade In case of voluntary inactivation, a notification should be sent to the Trade Registry.
Registry
TR05.F.05 Statistical totalizer The number of inactivations or derogatory regime/radiation should increase in the inactivation totalizer with
one unit.
TR05.F.06 Looking for arrears For radiations, the system should look for arrears through A03.1.
TR05.F.07 Arrears identified – joint If there will be any arrears identified during the previous step, the system should deploy the process for
responsibility engaged identifying the cases in which the joint responsibility has been engaged and should follow the procedures
detailed within the functional requirements for enforced collection, to recover the amounts.
TR05.F.08 Arrears identified – joint If the joint responsibility procedure has not been engaged, then the system should cancel the arrears.
responsibility not engaged
416 Section V. Requirements of the Information System

ID Name Description

TR05.F.09 Certificate/TIN, PIN – The system should cancel the TIN/PIN but these should remain into the database.
cancelled
TR05.F.10 Account erased from the After a certain amount of time established by NAFA (i.e. 5 years), in case there is no sign of activity, the
database system should erase the taxpayer from the database and its account from the WEBSpace.
TR05.F.11 Notice to Taxpayer The system should send a notice to TR08 Registration audit indicating that a specific taxpayer has been
Registration Audit inactivated/radiated or had its derogatory regime application approved.
TR05.F.12 Posting an end of The system should format a message for taxpayer Accounts that marks the account inactive and ensures that
operation record to all tax types for this business has ceased.
Accounts
TR05.F.13 Active to Inactive The taxpayer should be moved from Active Taxpayer Registry to Inactive Taxpayer Registry.
Registry transfer
TR05.F.14 Active to Inactive Risk The Taxpayer’s Risk History and Profile Data should be moved from active Taxpayer Registry to Inactive
History and Profile Taxpayer Risk History and Profile database.
transfer
TR05.F.15 Data transfer to In case of taxpayers which request radiation, the information should be moved to the Document
Document Management Management database and a reference should be maintained in the database containing inactive taxpayers,
database – radiation reference saying that they have been radiated.
reference
TR05.F.16 Outreach Program – A short message should be transmitted to the taxpayer indicating the inactivation transaction was
Short message completed.
TR05.F.17 Document Management The inactivation short message communication should be stored in Document Management.
TR05.F.18 Posting to WEBSpace The approved inactivation application should be posted to the taxpayer’s WEBspace account.
account
TR05.F.19 Taxpayer The taxpayer should be required to acknowledge the inactivation action.
acknowledgement
TR05.F.20 Preliminary checks The system should query the existing databases to identify arrears that have not been paid.

Also, the system should perform queries for identifying taxpayer’s presence as shareholder/associate in
other companies.
TR05.F.21 Taxpayer reactivation - The taxpayer should be able to select an option when reactivating, so that the system generates returns
Automated completion of automatically filled with zero value, if there were no liabilities.
returns
TR05.F.22 Taxpayer reactivation - The system should store past year returns in support of a taxpayer that decides to re-register and needs to
Section V. Requirements of the Information System 417

ID Name Description

Past returns storage complete those returns before the TIN/PIN is allowed to be reused.
TR05.F.23 Taxpayer reactivation - The system should be capable of processing past years stored returns.
Processing past forms
TR05.F.24 Outreach Program – In case the system should identify economic activity, a short message should be sent to the taxpayer
Short message indicating this.
TR05.F.25 Document Management The short message of communicating the economic activity detection should be stored into the Document
Management database.
TR05.F.26 Audit notification In case the system should identify economic activity as regards a certain taxpayer, a notification should be
electronically sent to TR08.
TR06 – Inactivate Taxpayer – at NAFA’s initiative (i.e. not filing any application or tax/informative return)
TR05.F.01 Query for activity The Taxpayer Risk History and Profile database and the absence of returns for a period of 183 days should
be the basis for automated inactivation.
TR05.F.02 Query for activity – If the system detects activity, it will fill, communicate and post a directed (ex-officio) return using relevant
Activity detected information from identified activities, determining the liability.
TR05.F.03 Updating the Risk History The Risk History and Profile database should be updated during the 183 day period to indicate a Directed
and Profile database (ex-officio) Return has been filed due to a non-filer.
TR05.F.04 Declaration of enforced In case the taxpayer does not submit the returns in due time (e.g. VAT returns, CIT returns, etc.), the
inactivation taxpayer should be declared inactive.
TR05.F.05 Notifications to other Based on the directed return mentioned above, the system should create arrears for the taxpayer and should
processes send a notification in this respect to A03. Also, the system should send a notification to TR08, for
verification purposes.
TR05.F.06 Active to Inactive The taxpayer should be moved from Active Taxpayer Registry to Inactive Taxpayer Registry.
Registry transfer
TR05.F.07 Active to Inactive Risk The Taxpayer’s Risk History and Profile Data should be moved from active Taxpayer Registry to Inactive
History and Profile Taxpayer Risk History and Profile database.
transfer
TR05.F.08 Update inactive taxpayer The system should update a totalizer that identifies the number of inactive taxpayers that were inactivated.
totalizer
TR05.F.09 Outreach Program – A short message should be transmitted to the taxpayer indicating that he/she meets the conditions for
Short message 1 inactivation.
TR05.F.10 Outreach Program – Another short message should be transmitted to the taxpayer, if case, indicating that the inactivation
Short message 2 transaction was completed.
418 Section V. Requirements of the Information System

ID Name Description

TR05.F.11 Document Management The inactivation short message communication should be stored in Document Management.
TR05.F.12 Posting to WEBSpace The approved inactivation application should be posted to the taxpayer’s WEBSpace account.
account
TR05.F.13 Inactivation related The requirements related to TR05.6 above should be repeated because the processes are identical.
operations
TR07 – Managing Taxpayer Risk History and Profile
TR07.F.01 Calculating the taxpayer The system should compute a taxpayer rating using the input provided.
rating
TR07.F.02 Color coding Taxpayer’s should be rated using a color coding system for easy identification.
TR07.F.03 Posting to WEBSpace The taxpayer’s risk score should be posted on the taxpayer’s WEBSpace account in a prominent place
account visible when the taxpayer logs onto their WEBSpace account.
TR07.F.04 Risk score publication Taxpayers should be capable of opting to make their risk rating public.
TR07.F.05 Returns Processing The Returns Process step RP03.8 should query the Taxpayer Risk History and Profile database to determine
queries whether the taxpayer is fast tracked for a refund/restitution.
TR07.F.06 Taxpayer risk history NAFA and the developer should develop a formula that takes into account positive and negative entries to
algorithm the Taxpayer Risk History and Profile in determining an overall risk score.
TR07.F.07 Risk scoring mechanism The Taxpayer Risk History and Profile database should contain individualized returns data averages.
TR07.F.08 Returns risk clues Lines that are outside present norms (defined as a certain deviation from the mean), stored in the Taxpayer
Risk History and Profile database, should be highlighted as clues on the return.
TR07.F.09 Dashboard taxpayer risk What constitutes a significant deviation from the mean for highlighting and scoring purposes should be a
history configuration configurable item on the dashboard.
TR08 – Taxpayer Registration Audit (Registration Record Validation)
TR08.F.01 Notice to Taxpayer The Workflow subsystem should deliver referral for registration audit to a queue.
Registration Audit
TR08.F.02 Sorting incoming audit The Workflow subsystem should sort incoming work by the type of inspection that needs to be performed.
work by type
TR08.F.03 Assigning registration Sorted registration audit work should be sorted again by area, as to permit maximum coverage in minimal
notice by area time.
TR08.F.04 Connection to HRMIS The System should interface with the Human Resources application (ONIX, in web technology, see
(Human Resources Informational Annex 4: Legacy Systems for Integration) to import information staff movements and about
Management Information where the staff resides, to optimally schedule staff audits. A single audit can be assigned during the course
System) of a day’s work to maximize the positive effect on this base verification and compliance process.
Section V. Requirements of the Information System 419

ID Name Description

TR08.F.05 Registration audit The system, using NAFA priority policy for registration audit selection, should prioritize and
prioritization geographically group audits for assignment and scheduling.
TR08.F.06 Scheduling the The system should schedule the no-notice audit based on priority in the audit selection subsystem.
registration audit
TR08.F.07 Assigning the auditor The system, using a geographical model, should present a manager with registration audits and the manager
should use the Workflow subsystem to assign audits to staff and others based on availability.
TR08.F.08 Registration audits The Registration Audit Manager should coordinate with other NAFA departments for assigning audits
performed by other based on staff availability.
NAFA staff
TR08.F.09 Taxpayer Risk History Each audit report should generate an entry in the Taxpayers Risk History and Profile database.
and Profile database
TR08.F.10 Taxpayer Registration The Taxpayer Registration audit should be supported by a distributed database report application that
Audit application permits posting the report quickly with little staff effort.
TR08.F.11 Document Management All Registration Audit reports should be stored in the Document Management subsystem.

2 – RETURNS PROCESSING (RP)

ID Name Description

RP.F.01 Dashboard – Returns There should be a section on the Dashboard for scheduling returns jobs for processing.
Processing
RP.F.02 Document Management All submitted returns should be stored not only as data in a returns processing database, but the signed
return should be converted to .PDF and filed in the Document Management subsystem.
RP.F.03 Digital storage All digitally submitted returns should be stored in a Returns Processing relational database.
RP.F.04 SOA Processing (by form Each return form should have a Document Identifier that should define the steps in software required to
type) process the form correctly.
RP.F.05 The Purchaser/ Supplier The purchaser/supplier matrix should carry over invoice amounts that have not cleared in the previous
matrix - Carry-over of quarter.
uncleared amounts
RP.F.06 The Purchaser/ Supplier Carried over items should be marked as to how many times the item has been carried over without being
matrix - Marking reconciled.
420 Section V. Requirements of the Information System

ID Name Description

uncleared amounts
RP01 – Pre-Filing Return Preparation Process
RP01.F.01 Automatically scheduling The pre-filing process should be a scheduled job in the system controlled by the System Dashboard.
the job
RP01.F.02 Return form The pre-filled return should represents the tax return scheduled to be filled by the taxpayer (in accordance
with the Law and required by the Taxpayer’s Registration record).
RP01.F.03 Selection of pre-filled Once the scheduled job commences a form stock template should be selected to be populated by data stored
return by NAFA and to be validated by the taxpayer.
RP01.F.04 Determining taxpayers After Pre-Filing for a specific tax return has started, a list of eligible taxpayers required to process the tax
eligible for pre-filling return being prepared as a pre-filled return should be selected from the Registration Database.
RP01.F.05 Preparation of ID box on The system should prepare a pre-filled return for each eligible taxpayer that meets pre-filler eligibility and
the pre-filled return who is responsible for filing this type of return document.
RP01.F.06 Commencing pre-filled The identification box of the pre-filled return form should be populated with registration data (data that is
return extracted from the Taxpayer Registration database).
RP01.F.07 Query of third party data The system should query third party data that is to be posted to the return, if required by the form being
in pre-filling processed.
RP01.F.08 Aggregation of third The system should aggregate the third party data for use in populating the pre-filled return (putting the data
party data in pre-filling in its final form) and for posting to the return (if the third party data item is required by the form being
processed).
RP01.F.09 Posting third party data Data obtained from third parties should be posted to the pre-filled return (if required) on the lines where the
in pre-filing data is required.
RP01.F.10 Revenue statistics Revenue statistics from the pre-filled return should be posted to the revenue counter statistics database.
RP01.F.11 Outreach Program – The taxpayer who is required to file a specific type of return being addressed and who is eligible to file this
Short message type of return should be notified via preferences outlined in their Registration Record that filing season has
started and information should be posted to the WEBSpace account in due course.
RP01.F.12 Posting in the WEBSpace The pre-filled return should be formatted and posted to the taxpayer’s WEBSpace account.
account
RP01.F.13 Message The message that a return has been pre-filled and sent to a taxpayer should be acknowledged by the
acknowledgement taxpayer.
RP01.F.14 Message storage The message sent to the taxpayer on the pre-filled return should be identified and stored in the Document
Management database.
Section V. Requirements of the Information System 421

ID Name Description

RP01.F.15 Outreach Program – A short message should be sent to the taxpayer indicating the specific return has been posted to the
Short message taxpayer’s WEBSpace account.
RP01.F.16 Document Management The pre-filled form message sent to the taxpayer and acknowledgement should be filed in the Document
Management database.
RP02 – Receiving the tax/informative return
RP02.F.01 Prerequisites to pipeline The Taxpayer Service and Call Centersshould have access to knowledge ware to ensure that consistent
process policy, administration procedures and advice are provided to the taxpayer.
RP02.F.02 Front end delivery of Returns data should be delivered as a digital representation of the returns form selected by the taxpayer to
returns comply with a specific tax requirement.
RP02.F.03 Formatting the return The Returns data should be formatted and the record capable of recreating the document for Document
Management.
RP02.F.04 In-checking the return The Automated Returns subsystem should in-check the return into the system by posting the Taxpayer Risk
History and Profile database (NAFA receives the return from the taxpayer).
RP02.F.05 Outreach Program – A short message should be sent to the taxpayer indicating a return has been submitted.
Short message
RP02.F.06 Marking the return for The form’s incoming digital barcode should be changed to read Form Type + TIN/CFP + Date Filed,
processing determining the proper processing line.
RP02.F.07 Posting in the WEBSpace The return that is being processed together with the new barcode should be stored in the taxpayer’s
account WEBSpace account.
RP03 – Pipeline Processing (validation and processing)
RP03.F.01 Returns processing flow The Workflow subsystem should abdicate flow control during the processing of the return to the SOA
control during process step RP03.1.
RP03.F.02 Incoming document The incoming document header (where the document identifier is located) should be read by the system to
identification identify the type of document being processed.
RP03.F.03 SOA operation The Service Broker of the SOA should dynamically assemble the processing objects necessary for reading
the formatted data being offered by the taxpayer on the tax form data record.
RP03.F.04 Scanning the returns The system should scan the incoming returns document for errors.
document for errors
RP03.F.05 Directed (ex-officio) The Directed (ex-officio) Return should be marked as such.
Return
RP03.F.06 Referring document with The system should refer errors to a Tax Administration Officer for data perfection to be reconciled before
422 Section V. Requirements of the Information System

ID Name Description

errors for correction processing can continue.

RP03.F.07 Document with errors for Each SOA Process Scenario should possess an object that is capable of correcting obvious errors on any
correction capability line.
RP03.F.08 Outreach Program – An automated correction requires the taxpayer to be notified using the Outreach Program.
Short message
RP03.F.09 Document Management The short message and the changed document should be filed in the Document Management subsystem,
next to the previous unchanged document.
RP03.F.10 Purge the return residual Once processing objects have completed processing the form, the system should return control of the
record at end of process pipeline to the SOA Service Broker.
RP03.F.11 Form inspection The system should select, for a new form, every x returns where x is a programmable parameter defined in
the System Dashboard, to inspect the form for systemic errors.
RP03.F.12 Form inspection – The system should convert the record to form representation so to be inspected by the relevant tax officer.
Convert data to form
RP03.F.13 Form inspection – Error The relevant Tax Administration Officer, as a consequence of the inspection, should have a facility to
reporting record inspections that were made and attach a report.
RP03.F.14 Form inspection – The system should count the number of defective forms that submitted erroneous data to NAFA in a defect
Totalizer totalizer.
RP03.F.15 Form inspection – Data If errors are detected and are not quality problems, the Quality Control subsystem should be capable of
perfection forwarding data errors for correction by a Tax Administration Officer.
RP03.F.16 Error identification Errors identified in a return should be forwarded for Data Perfection by the Workflow subsystem.
RP03.F.17 Error processing queuing All errors should be queued by the Workflow subsystem for the next available data perfection staff member
(required to visually observe the record and prescribe remediation).
RP03.F.18 Counting errors processed The Workflow subsystem should be capable of counting the number of errors processed overall during the
day.
RP03.F.19 Measuring work The Workflow subsystem should be capable of measuring individual Tax Administration staff member
performance error processing work performance.
RP03.F.20 Error processing - The software subsystem should have a facility that is able to record the types of errors that are being noticed
statistics by types during data perfection.
RP03.F.21 Error review There should be a side by side display that allows the Tax Administration staff member to review the
original return highlighted with the errors in yellow and the digital form – which should contain:
- A correctable form – populated with the current data that can be overwritten
- Workflow options:
Section V. Requirements of the Information System 423

ID Name Description

o Error was corrected by Tax Administration Staff Member in accordance with guidelines permitted by
NAFA.
o Error Exception declared (the matter should be referred to the taxpayer for correction).
RP03.F.22 Manual error correction The Returns Data Perfection Tax Administration Officer should be capable of making edited changes to the
return within guidelines published in an SOP.
RP03.F.23 Manual error correction - Errors authorized for staff adjustment should be made directly in the returns form record and the record
accepted errors prepared for continued processing.
RP03.F.24 Manual error correction - Errors that are not authorized for correction by NAFA Staff Members should be declared exceptions.
not accepted errors
RP03.F.25 Statistical totalizer The system should record the number of returns of a specific type that it processed into a totalizer.
RP03.F.26 Exception handling – Exceptions should require taxpayer intervention.
Data perfection
RP03.F.27 Exception handling – Post Exceptions should be forwarded to the taxpayer’s WEBSpace account to be corrected and resubmitted by
WEBSpace account the taxpayer.
RP03.F.28 Outreach Program – The taxpayer should receive an outbound small message using their contact preferences, advising the
Short message taxpayer that their last return requires perfection and is in the WEBSpace account.
RP03.F.29 Exception Handling – The taxpayer should be able to make corrections to the form in the WEBSpace account and should resubmit
Taxpayer's actions the form to Workflow queue, marked corrected.

RP03.F.30 Document Management If the return document was not posted in the Document Management subsystem (as a consequence of error
correction or quality assurance) it should be posted to the Document Management database.
RP03.F.31 Statistical totalizer The system should read lines which have an economic value and record statistics for reporting into a
totalizer, one for each line of interest as defined by NAFA during Detailed Requirements Analysis.
RP03.F.32 Posting liability to The pipeline process should provide an interface to a single process that interprets many types of returns
taxpayer account and converts the data to a standard liability posting format.
RP03.F.33 Amended return Amended returns should not be reprocessed through the complete pipeline.
RP03.F.34 Liability return only If this is a liability only return the pipeline will refer the liability to Process RP05 – Converting Returns
Data to Postable Formats to post to the Accounts.

RP03.F.35 Posting amended liability The pipeline process should provide an interface to RP05 Converting Returns Data to Printable format for
to taxpayer account posting an amended amount.
RP03.F.36 Moving the tax liability to The Workflow subsystem after being stored in the returns, will move the tax liability data to be formatted
RP05 and posted to process step RP05, Converting Returns’ Data to postable format.
424 Section V. Requirements of the Information System

ID Name Description

RP03.F.37 Third party data The returns processing pipeline should include a facility to collect third party data and match the data to
matching lines on the return (as a compliance indicator).
RP03.F.38 Submitting the return for The pipeline process should submit the return for statistical scoring based on industry codes averages
scoring maintained by the system for each activity.
RP03.F.39 Scoring the return- The pipeline process should be capable of scoring the tax return as it is processed.
General
RP03.F.40 Scoring the return- Certain indicators in the scoring algorithm should require regionalization.
Regionalization
RP03.F.41 Scoring the return – Scoring should be a combination of statistical scoring against industry averages and the taxpayer’s risk
Averages history and profile data score.
RP03.F.42 Scoring the return- Audit The dashboard should control scoring by providing NAFA with a facility that determines how many
referral standard deviations from mean are permitted before the indicator becomes a clue for tax audit.
RP03.F.43 Updating Risk History At the end of scoring the Taxpayer’s Risk History and Profile database should be updated with the:
and Profile database - Return Barcode, QR or Number Identifier
- Tax Type
- Date
- Compliance Score
- Data related to each line in the Taxpayer Risk History and Profile that are used to compose averages for a
specific taxpayer and specific return
- Return data that will be used to compute specific taxpayers return averages for certain lines in the return.
RP03.F.44 Refund/ restitution NAFA should have a Dashboard facility to determine what scores and Taxpayer Risk History and Profile
criteria ratings are eligible for Fast Track refunds/restitutions.
RP03.F.45 Update the returns The return and scores should be stored in the Returns database.
database - Regulated
return
RP03.F.46 Update the returns The Amended Return data should be stored in the Returns database.
database - Amended
return
RP03.F.47 Update the returns The Returns database should be sorted by TIN/PIN, embedded in the Document Identifier.
database - Sorting
RP03.F.48 Tax Audit folder – The returns process should make tax audit referrals based on returns data, where warranted by thresholds set
Scoring clues by NAFA.
RP03.F.49 Tax Audit folder - Returns pipeline should compose an electronic tax audit folder.
Section V. Requirements of the Information System 425

ID Name Description

Composition
RP03.F.50 Tax Audit Folder - The Tax Audit Folder should include:
Content - The audit referral document
- The current state of the Tax Accounts
- Returns document numbers for the last five years
- The Taxpayer’s Risk History and Profile Rating
- A Case Number
RP03.F.51 Moving folder to Tax The electronic Tax Audit Folder should be sent to the Tax Audit Department that has jurisdiction over the
Audit taxpayer.
RP03.F.52 Tax Audit totalizer Each tax audit referred should be counted.
RP03.F.53 Tax Audit queue The Workflow Management system should take control of the Tax Audit Folder and convey it to the Tax
Audit Selection queue.
RP04 – Data verification/Matching (VAT - purchaser vs. supplier)
RP04.F.01 Purchaser/ Supplier The system should post (for every VAT return filed) summary purchases and supplier VAT invoices to a
matrix - Summary matrix for matching.
RP04.F.02 Purchaser/ Supplier Purchaser and supplier data applied to the matrix should be dynamically matched and marked as cleared.
matrix - Matching
RP04.F.03 Purchaser/ Supplier - At a point in time (a Dashboard configured item), a job to reconcile all purchaser and supplier data should
Reconciliation job commence.

RP04.F.04 Purchaser/ Supplier- The purchaser/supplier invoice matrix should be queried for summaries of purchases and sales reported by
Database query taxpayers in a VAT return for which a corresponding entry that exactly matches or nearly matches cannot
be determined by the system.
RP04.F.05 VAT payers with VAT summary of invoice transactions reported to Tax Administration should be marked provisional (i.e.
temporary TINs marked for additional scrutiny).
RP04.F.06 Purchaser/ Supplier An un-cleared purchaser/seller invoice listing should be created, sorted by TIN/PIN, complete with contact
-Listing data for all items that are considered not cleared.
RP04.F.07 Matched items Each month during off peak hours, a scheduled job to clear items that have not cleared in the previous
quarter should be run, creating a listing of un-cleared items.
RP04.F.08 Mismatched items Mismatched items should be posted to the taxpayer’s WEBSpace account, with a notice requiring the
taxpayer to provide written guidance to the Audit/Examination Unit to assist in clearance.
RP04.F.09 Mismatch -Explaining Should there be a major mismatch that requires explanation a return for the month or set of months where
mismatches occurred, should be explained by the taxpayer and the matter referred to Audit.
426 Section V. Requirements of the Information System

ID Name Description

RP04.F.10 Outreach Program – When all items in the matrix match, a short message and WEBSpace entry should be formatted that states
Short message invoices cleared or un-cleared are on the WEBSpace account and may require taxpayer attention.
RP04.F.11 Outreach Program – The taxpayer should be sent a short message notifying him that a notice for under-reporting has been posted
Short message to their WEBSpace account and requires attention.
RP04.F.12 Taxpayer Risk History The system should send a record to the taxpayer Risk History and Profile account that un-cleared items
and Profile - Record sent were noted and the taxpayer notified.
RP04.F.13 Printing center A printed notice for under reporting due to VAT Invoice Summary mismatches should be formulated.
RP04.F.14 Reconciliation with The taxpayers should reconcile the amounts with unmatched transactions.
information related to
operations between
member states and
between member states
and third states

RP05.F.01 Return delivery method The Returns Pipeline should provide a return record with the liability incorporated in the record to process
RP05 for formatting.
RP05.F.02 Creating standard All returns should be formatted before being posted to the Tax Accounts.
formatted accounts entry
RP05.F.03 Handling incoming Incoming records should be stripped of extraneous data leaving as a minimum:
records - TIN/PIN
- Date Filed
- Document Number (Return form type and TIN/PIN)
- Tax Type
- Amount
Section V. Requirements of the Information System 427

3 – PAYMENT PROCESSING (PP)

ID Name Description
PP01 – Payment by taxpayer
PP01.F.1 Online Payment Receipt System should allow electronic payments through Net banking, debit cards, credit cards for all leading
banks. System also allows payments through mobile phones. Hence the application should be accessible
through a 3G / GPRS enabled browser on a mobile phone
PP01.F.2 Payment Receipt System Should provide unique Payment Receipt Number for each tax payment. This unique Payment
Information Receipt Number will be provided by each taxpayer along with its return and will act as a common identifier
for reconciliation.
PP01.F.3 System should generate Acknowledgment for cash payment
PP01.F.4 System should generate Payment Receipt Number instantly at time of tax payment
PP01.F.5 System should provide e-payment facility with multiple bank internet banking facility
PP01.F.6 Payment for The system should provide provision of tax payment for unregistered taxpayers
Unregistered Taxpayers
PP02 - System Verification against Payments
PP02.F.1 System Verification System should be able to treat every 'payment made' as an open item if it not able to find the reference no.
against Payments against which the payment has been made
PP02.F.2 System Verification System should be able to offset a payment made against a payment due, fully or partially and indicate the
against Payments amount due, only of the reference no. is the same in both the entries
PP02.F.3 System Verification The system should allow the user to link a specific 'payment made' entry to the 'payment due' entry, in case
against Payments system is not able to link the pair properly
PP02.F.4 System Verification System should be able to display by the side of every payment made- whether the payment has been
against Payments reconciled
PP02.F.5 System Verification The system should be able to generate a payment acknowledgement with the necessary payment detail
against Payments
PP02.F.6 Tracking of payment System should maintain an account of payments made by Registered taxpayer and payments due, by date,
payment head and amount
PP02.F.7 Mode of Revenue The system should recognize Payment Types such as: Credit/Debit Card, Electronic Transfers (Direct
Accounting Banking, Wire Transfers), Exchange of value (Document Swap), Book transfer from another government
department for a 3rd party, Treasury
PP02.F.8 Integration with Refund The Tax payment system should be integrated with Refund module for adjustment against tax liability
Module
428 Section V. Requirements of the Information System

ID Name Description
PP02.F.9 Integration with System should maintain a continuous taxpayer WEBSpace account with details of payments made, net
taxpayer WEBSpace outstanding liability, etc. At any time, system shows the net account balance (amount due) of the registered
account taxpayer and taxpayer can choose how much to pay. Accordingly, system allows partial and advance
payment of outstanding liability
PP03 – Payment reconciliation
PP03.F.1 Bank Interface With Tax The system should provide an interface between treasury, bank system and NAFA's Tax system.
System
PP03.F.2 Taxpayer Information The system should provide the database of each taxpayer bank account and the information of all partners.
PP03.F.3 Revenue Accounting The system should recognize and interface with Payment Channels such as: Online, Electronic Transfers,
Payment Agencies, etc.
PP03.F.4 Payment Report The system should be capable of generating reports regarding payment received on the basis of taxpayer
type/ group
PP03.F.5 Real time update The system should allow for real time update of transactions conducted through the e-payment portal (i.e.:
via pseudo update) of all transactions with end-of-day update
PP03.F.6 Reconciliation System should allow for online receipt of reconciliation information from various sources such as banks/
treasury/payment aggregators etc. real time or at pre-defined frequency as the case may be and show status
of reconciliation.
PP03.F.7 Reconciliation System should provide alerts to assessing authority in case of a reconciliation failure
PP03.F.8 Reconciliation System should allow for SMS and email notification to be sent along with postal notice to the taxpayer
notifying him of his payment reconciliation status (successful / unsuccessful)
PP03.F.9 Reconciliation System should immediately invoke the Arrears Management module along with updating the risk profile of
taxpayer in the event of a mismatch between Tax payment declared by the taxpayer and the Tax payment
information obtained from the banks/ payment gateways
Section V. Requirements of the Information System 429

4 – TAXPAYER ACCOUNTS / LEDGER (AL)

ID Name Description

AL.F.01 Single Taxpayer Accounts There should be one Taxpayer Accounts Ledger.
Ledger
AL.F.02 Single third party There should be one database for third party data.
database
AL.F.03 Taxpayer Accounts The Taxpayer Accounts Ledger can be called by an application and should be dynamically constructed by
Ledger – Access TIN/PIN account and then by subaccount.
AL.F.04 Taxpayer Accounts There should be an account for each registered taxpayer.
Ledger – Construction by
taxpayer
AL.F.05 Taxpayer Accounts There should be a sub account for each tax type and a subaccount for credits (not claimed for
Ledger – Construction by refund/restitution).
tax type
AL.F.06 Penalties and interest Penalties and interest should be dynamically calculated, based on due date of arrears and on the due amount
calculations (“principal”), as well as the applicable percentage.
AL.F.07 Payments effective date All payments, no matter when they were discovered, should be credited to the Taxpayer Accounts Ledger
on the day payment was made to the bank/Treasury.
AL01 – Post Liabilities to the Accounts
AL01.F.01 Liabilities stored during All liabilities received during the sorting period should be stored in a temporary buffer until the sorting and
sorting – Buffering accounts calculation operation stops.
AL01.F.02 Liabilities stored during At the end of the sorting process the buffer should be emptied and records received during sorting should be
sorting – Empty buffer appended to the bottom of the Taxpayer Accounts Ledger until the next day’s sorting operation commences.
AL01.F.03 Incoming data records – All incoming data records should comply with a standard data format for posting to the Taxpayer Accounts
Format Ledger.
AL01.F.04 Incoming accounts Ledger data records should contain as a minimum a TIN/PIN, transaction date, a single tax type, a
liability records – transaction code (defining what effect on the accounts this transaction will have), a document identifier/link
Minimal content (that allows access to the Document Management database to allow any authorized user to know how the
liability was created), the liability amount.
AL01.F.05 Delivery of the returns At the conclusion of RP05 Converting Returns' Data to Postable Format, the Workflow Management
liability system should deliver the formatted liability to the accounts for posting.
AL01.F.06 Taxpayer Accounts The Audit Department filed resolution or result of an Audit should be filed using the standard record
Ledger – Interface with format.
430 Section V. Requirements of the Information System

ID Name Description

tax audit
AL01.F.07 Taxpayer Accounts The Enforced Collections Department should file accounts adjustments in accordance with the standard
Ledger – Interface with record format.
enforced collections
AL01.F.08 Taxpayer Accounts The Appeals function, in support of an approved Appeals resolution, should conform to the standard
Ledger – Interface with method of posting.
appeals
AL01.F.09 Taxpayer Accounts The Tax Court should file modification of account liabilities in accordance with the standard Taxpayer
Ledger – Interface with Accounts Ledger posting format.
Tax Court
AL01.F.10 Accounts totalizer The system should count all Accounts transactions in real time, categorizing liabilities posted by enterprises
and by wage earners.
AL01.F.11 On-time payment schemes As a part of the Enforced Collection methodology, advanced payment amounts should be forwarded in a
number of records that are in accordance with the record format.
AL01.F.12 Future liabilities The system should process informative advanced liabilities as a result of the taxpayer declaring their
revenue for the current tax year.
AL01.F.13 Arrears/ Accounts The Taxpayer Accounts Department should post future liabilities in the same manner as Enforced
Management - Payment Collections.
schemes
AL01.F.14 Writing off amounts from Based on the criteria contained within the legal provisions in force, certain amounts should be written off by
the taxpayers’ fiscal the system from the taxpayer evidence, automatically, as a result of an analysis required case by case (see
record examples in the next column).
AL01.F.15 Posting personal income For each employee one tax transaction (crediting the withheld amount) should be submitted to the Ledger
tax records for posting.
AL01.F.16 Appending the Taxpayer To maintain efficiency, the taxpayer liability data should be appended to the end of the Ledger during daily
Accounts Ledger operations.
AL01.F.17 Updating Taxpayer Risk All incoming liabilities should be posted to the Taxpayer Risk History and Profile.
History and Profile
AL01.F.18 Computing impact on tax During the sorting process, the impact of a liability on a tax should be calculated.
accounts
AL01.F.19 Start of sorting at the end At the end of the day the Tax Accounts posting operation will stop, a utility will execute and the sorting
of the day process should start.
AL01.F.20 Taxpayer Accounts The single Taxpayer Accounts Ledger should be sorted daily by automated daily utility scheduled for after
Section V. Requirements of the Information System 431

ID Name Description

Ledger – Sorting normal peak operating hours.

AL01.F.21 Taxpayer Accounts All records related to a single TIN/PIN should be stored in one place and sorted by TIN/PIN, date of
Ledger – Storage transaction and tax type.
AL02 – Filer / Stop Filer
AL02.F.01 Detection of stop filers At a date that is determined after it is certain that all tax reports have been filed or after the end of a filing
season for a specific return type, an automated off peak hours query should determine what taxpayers have
stopped filing.
AL02.F.02 Verification of stop filers For every taxpayer that filed the last period but has stopped filing this period, query the Registration
Database to verify that a return was due.
AL02.F.03 Query of the purchaser/ Determine if there is an economic activity.
supplier invoice matrix
AL02.F.04 Composing a Directed The system should pull information from the Returns Database, Taxpayer Risk History and Profile
(ex-officio) Return database, the purchaser/supplier invoice data matrix (from the past 12 months) and compose the Directed
(ex-officio) Return.
AL02.F.05 Posting the Directed (ex- The Directed (ex-officio) Return should be submitted to the RP03.1.
officio) Return
AL02.F.06 Compose a Directed (ex- The system should populate a Directed (ex-officio) Return for printing.
officio) Return for
printing
AL02.F.07 Posting to the WEBSpace The Directed (ex-officio) Return should be posted on the taxpayer’s WEBSpace account, together with
account instructions on how to reverse the process.
AL02.F.08 Outreach Program – A short message should been sent to the taxpayer indicating that a Directed (ex-officio) Return has been
Short message filed on their behalf.
AL02.F.09 Document Management The short message should be filed in the Document Management database.
AL02.F.10 Updating Risk History The Taxpayer Risk History and Profile database should indicate a Directed (ex-officio) Return was posted
and Profile database to the taxpayer’s WEBSpace account.
AL03 – Arrears Management
AL03.F.01 Snapshot query for At the end of the month, the snapshot (taxpayer status as regards the existing arrears at a specific moment in
arrears time) Taxpayer Accounts Ledger should be created for determining the arrears inventory.
AL03.F.02 Calculating interest and If there are arrears on any type of tax, the system should calculate dynamically, interests and penalties
penalties according to the law.
AL03.F.03 Outreach Program – Taxpayers with liabilities and no offsetting payment by the due date should receive a system created notice
432 Section V. Requirements of the Information System

ID Name Description

Short message of arrears.

AL03.F.04 Posting arrears interest The WEBSpace account should reflect the amount of interest and penalties accumulated thus far and project
and penalties interest increases for 12 months on the debt.
AL03.F.05 Outreach Program – The taxpayer should receive a short message in accordance with Registration preferences, as to the Arrears
Short message notice posting.
AL03.F.06 Updating Risk History Each notice should require a Taxpayer Risk History and Profile data entry.
and Profile database
AL03.F.07 Posting to the WEBSpace The WEBSpace Account should be posted with the Arrears Notice.
account
AL03.F.08 Enforced Collection folder An Enforced Collection Folder should be prepared and sent to the Enforced Collection Division for action.
AL03.F.09 Identifying the suspended Based on the request submitted by the taxpayer through the WEBspace, the system should interrogate the
administrative document Taxpayer Account and should identify the suspended administrative document and the related amounts,
highlighting it adequately.
AL03.F.10 Actions resulted from the The system should operate in the Taxpayer Account the necessary changes, to enforce legal provisions in
suspension of a fiscal relation to the fiscal regime of amounts contained in the respective document.
administrative document
AL03.F.11 Outreach Program – A short message should be sent to the taxpayer indicating the fact that the fiscal administrative document
Short message was suspended.
AL04 – Recalculating Liabilities based on Amended Return
AL04.F.01 Amended return delivery The Workflow subsystem should deliver an amended liability/credit record for posting to the Accounts.
AL04.F.02 Additional liability If the amount is a liability the system should compute the interest and penalties for the additional amount
calculations that was not paid during the filing of the original return.
AL04.F.03 Liability calculations – The liability calculations for past due amounts should be a configurable item on the system dashboard.
Dashboard
AL04.F.04 Convert the liability The liability records should be formatted for posting to the Tax Accounts in accordance with the scheme
record specified in Returns Processing (RP05).
AL04.F.05 Updating Taxpayer Risk Amended return liabilities should be posted to the Taxpayer Risk History and Profile database.
History and Profile
AL04.F.06 Refund/ restitution If there is a refund due the system should review the Taxpayer Risk History and Profile database to
management determine the overall risk score and if the risk score is satisfactory, the refund/restitution request should be
forwarded by Workflow to process step A05.1 for further processing.
AL04.F.07 Refund/ restitution If the taxpayer score is outside the satisfactory range for providing a refund/restitution, the Amended Return
Section V. Requirements of the Information System 433

ID Name Description

criteria process should generate an Audit Folder and transmit via Workflow the Audit folder to the Audit
Department for verification.
AL04.F.08 Audit folder composition The Audit folder should consist of as a minimum:
- The Amended Return document

- Taxpayer Risk History and Profile score

- Other documents and notifications that were generated by the Amended Return process
- The current Taxpayer Accounts Ledger.
AL04.F.09 Posting to WEBSpace The taxpayer’s Amended return liability, together with penalties and interest calculated by the system
account dynamically should be posted to the WEBSpace account.
AL04.F.10 Short message The system should compose a short message indicating there are arrears.
composition
AL04.F.11 Outreach Program – The short message should be transmitted to the taxpayer based on the Registration communications
Short message preferences selected by the taxpayer and saved in the Document Management database.
AL05 – Issuing Fiscal Certificates/Fiscal Records
AL05.F.01 Tax Administration The Tax Administration Officer, taxpayer agent or consultant, taxpayer (using Web Services) should
creates the fiscal receive a taxpayer’s request for a fiscal certificate/income certificate/fiscal record in the form of a query to
certificate/ income the Tax Accounts database (which will search for Arrears in all taxpayer subaccounts). The account should
certificate / certificate for have the appropriate security degree to manage such documents.
budgetary obligations/
fiscal record – Application
AL05.F.02 Fiscal certificate/income The taxpayer should have the possibility to electronically attach the proof of paying for the service of
certificate / certificate for issuing the document, as per the law.
budgetary obligations/
fiscal record – Proof of
payment
AL05.F.03 Fiscal certificate/income The system should identify the payments related to paying specific fees and should post these into the
certificate / certificate for taxpayer’s WEBSpace account.
budgetary obligations/
fiscal record – Payment
allocation
AL05.F.04 Fiscal certificate/ income The system should grant the option of online payment by card, this being connected to authorised electronic
certificate / certificate for means of payment.
budgetary obligations/
434 Section V. Requirements of the Information System

ID Name Description

fiscal record – Online

payment
AL05.F.05 fiscal certificate/ incomeSpecific institutions which require the taxpayer the fiscal certificate/ income certificate / certificate for
certificate / certificate for
budgetary obligations/ fiscal record may benefit from the creation of an interface with the Tax
budgetary obligations/ Administration, which should facilitate the process of accessing data from these documents and which
fiscal record – Interface should eliminate an additional burden for the taxpayer/public body involved in the privatization. The
with other institutions WEBSpace account/interface with other institutions should have the adequate degree of security to handle
the managing process of such documents.
AL05.F.06 System search – Upon a certificate/record request the system should search the Tax Accounts and compose a record that lists
Liabilities out liabilities or no liabilities.
AL05.F.07 System search – Taxpayer The Taxpayer Risk History and Profile database should be searched for any pending adverse actions such as
Risk History and Profile an audit pending on existing transactions or an unfiled return.
AL05.F.08 Fiscal certificate/ income If there are no adverse or pending activities that would preclude the issue of the fiscal certificate/ income
certificate /certificate for certificate / certificate for budgetary obligations, the system should return a positive response to the
budgetary obligations taxpayer’s/public institution involved in the privatization process’ request and process the certificate,
eligibility otherwise the certificate will indicate there are defects in the Taxpayer’s Account or Risk history.
AL05.F.09 Posting to the WEBSpace The fiscal certificate/ income certificate / fiscal record be composed by the system and be posted to the
account taxpayers WEBSpace account.
AL05.F.10 Printable version of the The fiscal certificate/ income certificate / certificate for budgetary obligations/ fiscal record should be
certificate/record transmitted immediately to the requester and a printable version should be made available on the requester’s
browser. The account should have the adequate risk level to handle such document.
AL05.F.11 WEBSpace account The WEBSpace account should be updated with a copy of the fiscal certificate/ income certificate / fiscal
updated record. The account should The account should have the adequate risk level to handle such document.
AL05.F.12 Outreach Program – A small message should be sent to the taxpayer indicating the fiscal certificate/ income certificate / fiscal
Short message record is on the WEBSpace account and can be printed.
AL05.F.13 Emailing In case the fiscal certificate/income certificates / fiscal record was requested by other institution, this is sent
as .PDF at the taxpayers postal address, The account should have the adequate risk level to handle such
document.
AL05.F.14 Document Management The fiscal certificate/ income certificate / certificate for budgetary obligations/ fiscal record should be
stored as a document in the Document Management database.
A06 – Managing arrears from other institutions
AL06.F.01 Other institutions upload Other institutions and local Tax Administrations should upload debts frequently during the day and NAFA
should store inputs in a buffer file.
Section V. Requirements of the Information System 435

ID Name Description

AL06.F.02 Other institutions debt At a specified time an automated job should start and arrears supplied by other institutions and local Tax
integration with the Administrations will be extracted from the buffer file and posted to the end of the Taxpayer Accounts
Taxpayer Accounts Ledger, followed by the enforced collection procedure for recovering the arrears.
Ledger
AL06.F.03 Redirecting payments The system should centralize, at predetermined intervals (for example once a week) the payments received
as regards the enforcement titles received from other institutions, following the application of enforced
collection measures, showing the Treasury the amounts which should be directed to these institutions.
AL06.F.04 Visualization/ download Other institutions should visualize/download in the agreed format, the situations regarding the arrears’
data regarding the status, by taxpayer and on an aggregated basis.
arrears’ status
436 Section V. Requirements of the Information System

5 – REFUNDS PROCESSING(RF)
ID Name Description

RF01 - Pre-refund processing and refund claim

RF01.F.1 Refund/ restitution The Workflow subsystem should deliver the reviewed demand for refund for posting to the account.
demand delivery
RF01.F.2 Review refund status The system should allow taxpayers to view refund status online through a browser and provide a mobile
friendly facility.
RF01.F.3 Online submission of The system should facilitate the submission of a refund claim via internet web portal in the following
refund claim situations:
- Where tax payable is negative from the results of an audit.
- For persons not required to file a return
- Other cases by the Law
RF01.F.4 Mandatory The system should facilitate the capture and storage of supporting documentation for a refund claim. The
supporting taxpayer should not be able to submit the form without uploading the necessary supporting documents.
documents
RF01.F.5 Type of refund The system should allow the user to enter the type of refund. The type of refund may be Provisional Refund,
Annual Assessment Refund or Refund through Court Order.
RF01.F.6 Access Rights The system should ensure that the submitted refund claim form is available to the department in read-only
form. Any required changes will have to be requested by the department and made at the taxpayers end
RF02 - Processing of Refunds
RF02.F.1 Searching for arrears The system should look for arrears in any tax type before making a refund/restitution, listing the arrears in the
order they should satisfied.
RF02.F.2 No Arrears/ Arrears If there an arrear is found the refund/restitution should be applied to the arrears amount in priority order (if
there is more than one arrear).
RF02.F.3 Posting to the account If there was an arrear and the refund/restitution was used to satisfy the arrear, the amounts required in
accordance with the payment order required by law, should be posted to the Accounts.
RF02.F.4 Refund/ restitution to If any amount of the refund/restitution was posted to the Accounts due to an arrears, any excess, should there
Treasury be excess, should be forwarded to the Treasury to be refunded.
RF02.F.5 Refund/ restitution If there is no arrear on file in Accounts, the entire amount should be refunded.
processing
RF02.F.6 Formulating the If there is no refund/restitution pending, the amount should be formatted into a record for processing by the
payment order Treasury.
RF02.F.7 Refund risk analysis The system should risk analyze all refund claims based on a configurable rules engine and using data within
Section V. Requirements of the Information System 437

ID Name Description

the RMS system and external data sources. Risk assessment will categorize claims as Reject, Review or
Accept.
RF02.F.8 Eject refund claim The system should be able to Reject a Claim under the following circumstances:
- When there is a duplicated claim
- Supporting documents are inadequate which may come out of review by the refund officer
- Prevent issuing a refund to a particular taxpayer who has a history of submitting fraudulent claims
RF02.F.9 Review refund claim The system should be able to Review a Claim Under the following circumstances:
- Where the risk is high for payment
- Where verification is required of supporting documents to validate amount claimed
- Where the taxpayer has consistently made a claim for refund for an extended period without audit
- Where the taxpayer has an objection pending - this may lead to an offset
RF02.F.10 Accept refund claim The system should be able to Accept a Claim under the following circumstances:
- Where the taxpayer is compliant
- Risk for payment is low
- Where the taxpayer has no debt/arrear and pending appeal and writ
RF02.F.11 Steps in refund The system should provide the facility create standard steps for the refunds process, for example:
processing - Assign for processing
- Approve refund
- Assign refund for payment via the Treasury units
RF02.F.12 Alerts The system should provide the capability to make an alert when approaching the end of statutory time period
for processing refunds.
RF02.F.13 Refund confirmation The system should allow for recording of the confirmation reference number and other details upon completion
reference number of the refund.
RF02.F.14 Provisional refund The system should have provisional refund module
RF02.F.15 Approval hierarchy The system should ask for approval from the higher authorities with respect to refund amount
RF02.F.16 Refund order from In case of a Court ordered refund, the system should have a provision for attaching the court order as a
court mandatory supporting document
RF02.F.17 Withhold/ cancel the The system should allow the assessing authority to withhold/ cancel the refund. Along with facility to enter a
refund reason for the same
RF02.F.18 Refund for audit The system should not process any refund claim if it has been flagged for audit by the Assessing Authority.
RF02.F.19 Refund for audit The system should process a return with a refund claim which has been flagged for audit by the assessing
authority only after the audit is completed and an instruction is issued to process the refund claim
RF02.F.20 Interest on refund The system should automatically calculate interest on refund and adjust the refund amount, in case the
438 Section V. Requirements of the Information System

ID Name Description

payment of refund is delayed by the department.

RF02.F.21 Taxpayer history The system should allow NAFA to check online the tax payment history and details of returns filed to calculate
the eligible refund amount and verify the amount of claimed amount
RF03 - Post refund processing
RF03.F.1 Posting to the If there was an arrear and the refund/restitution was used to satisfy the arrears, the detailed accounting
WEBSpace account (explaining the use of the refund/restitution to clear the arrear) should be posted on the taxpayers WEBSpace
page.
RF03.F.2 Review of refund The system should allow for the creation of an audit case where a claim has been categorized as ‘Review’.
RF03.F.3 Risk analysis Where the calculated risk is above a threshold amount, the system should create a case for each refund claim
and allocate this case to an officer for verification and authorization.
RF03.F.4 Posting to taxpayer The system should upon receipt of this intimation post the refund credit in the taxpayer's ledger and also send a
WEBSpace account communication to the taxpayer of the refund credit.
RF03.F.5 Letter for claim
The system should generate a letter for claims rejected stating the reason(s) for the rejection.
rejection
RF03.F.6 Monitoring & The system should be capable of alerting officers of claims approved for payment but not paid within a set
evaluation period.
RF03.F.7 Authorization for The system should be able to identify and report all authorized refunds and those not authorized including the
refund reason for non-approval.
RF03.F.8 Approved refund The system should provide the capability to generate a list of approved refund claims and to include any
claims interest due at the time of the report.
RF03.F.9 Withholding of The system should have feature of withholding refund after approval from higher authorities even after
refund assessment and calculation of refund
RF03.F.10 Refund status A refund application can have any one of the following status:
 Draft
 In Process
 Accepted
 Rejected
 Clarification Required
 With held
RF03.F.11 Change of refund The system should ask for a mandatory reason/ comment when status is changed to 'Rejected' or 'Clarification
status Required'
RF03.F.12 User communication The system should send an auto-mailer and SMS to the taxpayer, along with any accompanying comments,
Section V. Requirements of the Information System 439

ID Name Description

every time there is a status change

RF03.F.13 Interest on refund The system should automatically calculate interest on refund and adjust the refund amount, in case the
payment of refund is delayed by the department.
RF03.F.14 Tracking of refund
The system should be capable of tracking the reason for delay in payment of refund
payment
RF03.F.15 Refund audit The system should allow the assessing authority to flag the taxpayer refund claim for audit, if one feels the
refund claim requires further scrutiny
RF03.F.16 MIS Reports All reports should have the capability to be filtered or grouped by tax type, for specified period, location,
taxpayer, date between, etc.
RF03.F.17 The system should provide the ability to issue refund via Bank Transfer and Electronic Funds Transfer
RF03.F.18 The system should provide the ability to cancel a refund, stop payment of refund and re-issue refunds.
RF03.F.19 The system should provide the capability to generate reports for refunds received for payment details
RF03.F.20 The system should provide the capability to generate reports for refunds received but not paid
RF03.F.21 The system should provide the capability to generate reports for refunds paid
RF03.F.22 The system should provide the capability to generate reports for refund payments cancelled
RF03.F.23 The system should provide the capability to generate reports for refund Interest paid
RF03.F.24 The system should provide the capability to generate reports for refund Interest to be Paid
440 Section V. Requirements of the Information System

6 – RECONCILIATION (RR)
ID Name Description
RR01 – Third Party Data Repository / Matching
RR01.1.F.1 Dashboard configuration On a specific date, when it is clear that 3rd party data for a previous period has been posted to the 3rd party
– Start automated job data repository, the system should compare all previously filed returns with lines that are validated by third
party sources for compliance.
RR01.1.F.2 Comparing the return to For individual lines on the return that have corresponding 3rd party data, the tax system should compare the
3rd party data return to the aggregated amount of concern in 3rd party data and determine if the amounts match.
RR01.2.F.3 Amounts that do not Amounts in the return and third party data sources that don’t match should be identified and a notice
match demanding payment composed.
RR01.2.F.4 Recalculating the return If the amounts don't match between 3rd party and the amount reported on the return, a recalculation of the
liability/ credit liability or credit should be created and posted in a notice.
RR01.2.F.5 Case management The system should request a case number from the Case Management Number database for printing on the
number notice.
RR01.2.F.6 Notification The following information should be included on the Under Reporting notice:
- A document number
- An Tax Administration Case number
- A telephone contact for information on the notice and how to comply
- Two choices:
o The taxpayer agree;
o The taxpayer does not agree – which will require the taxpayer to provide proof to the Tax
Administration’s data is not accurate;
- Instructions for compliance
- A barcode.
RR01.2.F.7 Document Management The notice should be stored in the Document Management subsystem.
RR01.2.F.8 Updating Taxpayer Risk Each third party mismatch notice should be entered into the Risk History and Profile database.
History and Profile
RR01.2.F.9 Taxpayer Accounts The Taxpayer Accounts Ledger should be posted with the calculated liability/credit.
Ledger
RR01.3.F.10 Posting to the WEBSpace The notice should be posted on the WEBSpace account.
account
RR01.3.F.11 Outreach Program – The system should generate a short notice advising the taxpayer about an arrear due to matching.
Short message
RR01.3.F.12 Printing center The notice should be sent to the Printing Centre for mailing to the taxpayer.
Section V. Requirements of the Information System 441

ID Name Description
RR02 – Posting Payments
RR02.1.F.1b Revenue payments Payment data should be received in a data stream from the Treasury tax accounts.
received - Data stream
RR02.1.F.1 Revenue payments The Revenue data record should contain as a minimum a TIN/PIN, a date paid into the system (not to be
received - Data content confused with a banking transaction cleared date), taxpayer name, originating account number, routing
number, bank identification and amount.
RR02.1-O-2 Document Management The incoming payment record should be converted to a document form data and provided with a document
number.
RR02.2.F.3 Payment record - Any payment record that does not contain the minimum information necessary to process the payment
Deficiencies should be isolated by the system and sent to A08 – Reconciling Unpostable Payments.
RR02.2.F.4 Matching payment with The system should search the Taxpayer Accounts Ledger that corresponds to an exact match for the
liability payment and post the liability.
RR02.2.F.5 Payments that do not The system should post payments that do not match in accordance with NAFA policy for matching
match payments to liabilities and create one or more payment records.
RR02.2.F.6 Posting payments Payments should be posted to the Taxpayer Accounts Ledger in accordance with the same format
prescribed for posting liabilities, specifically:
- TIN/PIN
- Date paid
- Document dumber (Payment record from MOF which should become a document)
- Tax type (the payment was applied to)
- Amount
- Account number (where the payment originated).
RR02.2.F.7 Updating Taxpayer Risk The payment transaction should be posted to the Taxpayer Risk History and Profile Account and used in the
History and Profile scoring of the taxpayer for compliance.

RR02.2.F.8 Handling excess amounts Excess amounts paid should be credited against any existing arrears.
paid - Arrears
RR02.3.F.9 Handling excess amounts If the taxpayer has overpaid, the system should calculate a credit and post the amount to a Credit Ledger
paid - Credit accordingly.
RR02.3.F.10 Posting to the WEBSpace The payment record should be posted to the WEBSpace account advising the taxpayer how the payment
account was distributed.
RR02.4.F.11 Outreach Program – The taxpayer should receive a composed small message using the Taxpayer’s Registration preferences
442 Section V. Requirements of the Information System

ID Name Description
Short message indicating the payments have been distributed.
RR02.4.F.12 Document Management Post small message to the Document Management database as to record taxpayer payment contact.
RR03 – Reconciling Unpostable Payments
RR03.1-O-1 Off peak hour processing Unpostable payments should be placed in a queue for off peak hour database query.
requirement
RR03.1.F.2 Bank account match If a bank account match occurs the system should look for a liability that matches the amount paid.
RR03.2.F.3 Posting to the Taxpayer The system should post to the Taxpayer Accounts Ledger based on a payment match and apply excess from
Accounts Ledger an account that matched to any unpaid arrears in accordance with NAFA payment policy.
RR03.2.F.4 Posting to the WEBSpace The payment distribution against subaccounts should be recorded in the WEBSpace account.
account
RR03.2.F.5 Outreach Program – The taxpayer should be notified that an unpostable payment was credited to their account and that
Short message verification is required.
RR03.2.F.6 Document Management The small message and the payment document should be recorded in the Document Management
subsystem.
RR03.2.F.7 Updating Taxpayer Risk The Taxpayer Risk History and Profile database should be updated to reflect the payment.
History and Profile
RR03.4.F.8 Additional unpostable If the system can’t reconcile payments automatically, the Workflow subsystem should pull an unpostable
staff actions payment from the queue for a Payment Specialist to research.
RR03.4-O-9 Tax accounts staff actions Tax Accounts Staff actions should include calling the bank to receive identity information.
– Call the bank
RR03.4-O-10 Posting the payment If the Tax Accounts officer is able to identify the account of origin, obtain the TIN/PIN and match a
liability to the payment, the officer should change the payment record and post the Accounts.
RR03.4-O-11 Arrears/ Collection Enforced Collection staff presenting a valid bank payment document for a payment that was not able to be
payment inquiry posted previously, should match the payment with the bank/Treasury which performed the transaction.

RR03.5-O-12 Taxpayer missing Tax Accounts staff, when a taxpayer presents a bank transfer record proving that the missing payment was
payment inquiry theirs, should match the payment with the bank/Treasury which performed the transaction.
RR04 – Reconciliation with third party data
RR04.F.1 Extraction and System should be able to extract and transform information from multiple external sources without any
Transformation intermediate files
RR04.F.2 Open Formats System should have capability to accept files in the form of CSV, spreadsheets, word, etc.
RR04.F.3 Risk Analysis The system should allow for the analysis of risks using data supplied by a third party
RR04.F.4 Integration System should have capability to integrate internal and external data via data quality processes
Section V. Requirements of the Information System 443

ID Name Description
RR04.F.5 Data Refresh Periodicity System should be able to periodically refresh the data received from external agencies
RR04.F.6 Data Refresh Periodicity System should have provision to accept external data at intervals as defined and required by NAFA
RR04.F.7 Data Availability Data should be available at NAFA servers in the same format as provided by the external agencies
RR04.F.8 Back-up The system should be able to take back-up of the external data files
RR04.F.9 Security The inbound and outbound data stream on third party data from external data sources should be secured
RR04.F.10 Matching Feature The system should validate the data of taxpayer with a common field across the third party data available
RR04.F.11 Update The system should be able to update the organized database(s) on third party data with new data being
received from external entities on an ongoing basis
RR04.F.12 Update When a record is received from a third party source, it should compare it with the existing full database to
see if records already present and update the resolution of existing records
RR04.F.13 Assessment of Income and The system should allow user to refer and use third party data for the purpose of assessment of income and
Business Output business outputs using third party sources
RR04.F.14 identifying Market The system should allow user to refer and use third party data for the purpose of identifying sector trends,
Outlook, Sector Analysis, market outlook, etc.
etc.
RR04.F.15 Increasing Tax Base The system should allow user to refer and use third party data for the purpose of increasing tax base by
identifying entities not registered and those that are available in third party data
RR04.F.16 Data Management The system should store, organize and maintain third party data in the manner that should enable effective
usage across tax administration processes in the system
RR04.F.17 Matching of Records The system should link corresponding records in third party database(s) records on matching
444 Section V. Requirements of the Information System

7 – REVENUE COLLECTION (RC)

ID Name Description
RC01 - Automated Collections Notice
RC01.F.01 Generation of debt list The system should be capable of scanning through the taxpayer database based on a pre-programmed
schedule and generate a list of taxpayers with tax debts. The system should clearly identify tax debts
which are collectible and which have been objected to or appealed against by the taxpayer.
RC01.F.02 Due Payments Information The system should be capable of generating report for due dates of payments by taxpayer from
quarterly to monthly in case of voluntary tax payments as per pre-defined amount.
RC01.F.03 Tax Liabilities Report The system should provide a facility to summarize all tax liabilities of each taxpayer according to the
geographical area (includes: the detail of type and amount of tax).
RC01.F.04 Taxpayer History The system should maintain the taxpayer history and past payment transactions.
RC01.F.05 Auto Initiate for Tax The system should allow configuration of the rules for automatic initiation of taxpayer communications
Collection Purposes for tax collection purposes
RC02 - Collection Process Preparatory Activities
RC02.F.01 Interest Calculation in The system should, on a predetermined schedule, calculate interest on amounts subject to interest and
taxpayer’s Account post this interest to the taxpayers’ current account for the affected tax type and by tax period.
RC02.F.02 Case assignment The system should allow assignment of a collection case to a Concerned Officer
RC02.F.03 Priority level for each debt The system should allow setting of a priority level against each debt identified for collection action.
RC02.F.04 Collection checklist The system should provide facility to create one or more Collections checklists which can be updated
by officials during Collection proceedings.
RC02.F.05 Formation of collection The system should allow formation of Collection teams by addition/deletion of team members and also
team allow assignment of roles to team members such as Team Leader.
RC02.F.06 Master update The system should allow maintenance (add/update/delete/archive) of a master list of Regional Offices
of NAFA.
RC02.F.07 Case assignment When no response is received from a taxpayer on his liability before the due date for collections, the
system should initiate assignment of the collections activity to a Concerned Officer.
RC02.F.08 Case assignment The system should allow preparation of a collection "Case Folder" when it has been referred for forced
collection.
RC02.F.09 Case assignment The system should allow addition of the following details to the case prepared from historical data
available in the system:
a. Taxpayer's activity in the last 3 years
b. VAT related activity in the last 12 months
Section V. Requirements of the Information System 445

ID Name Description
RC02.F.10 Case assignment The system should allow addition of details of the tax regulation under which the collection case is
being managed.
RC02.F.11 Case assignment The system should allow a Collection case to be assigned to a team.
RC02.F.12 Case assignment The system should allow re-assignment of a Collection case to another team, if the need arises.
RC03 – Collection Process
RC03.F.01 System Appropriateness The system should provide the ability to post the tax payment into the correct account
for Payment
RC03.F.02 Updating Ledger The system should only allow posting to ledger process when the approval from authorized officer are
Information obtained.
RC03.F.03 Response Collection The system should provide the facility to capture all responses provided by taxpayers in response to
arrears related notices.
RC03.F.04 Response Receipt The system should allow linkage of taxpayer response to the respective collection notices
RC03.F.05 Enforced Collection In case arrears are not settled within ‘x’ days of the final notice, the system should queue the taxpayer
for "enforced collection" of the concerned officer.
RC03.F.06 Integration with The revenue collection module should have an interface with the Taxpayer De-registration module to
Registration allow initiation of de-registration of taxpayers who have deregistered from the National Register of
Commerce.
RC03.F.07 Settlement of Payments The system should update taxpayer WEBSpace account and arrear settlement status in case a taxpayer
makes a payment against an arrears notice sent
RC03.F.08 Instant Payment of Dues When the taxpayer makes an on-the-spot payment to settle dues, the system should provide the facility
to generate and print a receipt for the taxpayer.
RC03.F.09 Update of taxpayer The system should update taxpayer WEBSpace account and arrear settlement status in case a taxpayer
WEBSpace account makes a payment against an arrears notice sent
RC04 – Alerts
RC04.F.01 Report Types The system should have the ability to capture, daily & taxpayer wise, the relevant details of all
payments made via various channels including online payments
RC04.F.02 System Alerts The system should have a provision for online receipt of reconciliation information from various
sources such as banks/treasury/payment mechanism etc. on a daily basis
RC04.F.03 System Alerts The system should have the ability to reconcile the department data with the reconciliation data
received from treasury/payment regulator etc. on a daily basis
RC04.F.04 System Alerts The system should provide alert in case of reconciliation failure
RC04.F.05 Taxpayer Alerts The system should send an SMS/e-mail notification to the taxpayer notifying him of his payment
reconciliation status (Successful/Unsuccessful)
446 Section V. Requirements of the Information System

ID Name Description
RC04.F.06 Taxpayer Alerts 7The system should have the ability to generate alerts when payment becomes over due
RC04.F.07 Taxpayer Alerts The system should have a provision for sending SMS and e-mail notification to the taxpayer for
reminding him of his payment due before and after the due date
RC04.F.08 Decision support system The system should provide decision support tools to allow prioritization of collection activities on the
basis of:
a. Amount of arrears
b. Ability of taxpayer to pay the tax debt as gathered from various sources
c. Availability of NAFA resources with the skills to handle the arrears issue
RC04.F.09 MIS reports The system should provide MIS reports regarding Ageing of collection cases: This report should
provide date of identification of the arrear, number of elapsed days since identification of the arrear,
amount of arrear as on date of identification, amount of arrear as on date of the report (in case any
penalties and/or interest has been levied)
RC04.F.10 MIS reports The system should provide MIS Reports on trends in arrears and collection cases: This report should
provide details of amounts of arrears at the beginning of the month, new arrears identified during the
month, amount of arrears paid during the month and balance arrears at the end of the month.
RC04.F.11 MIS reports The system should provide MIS reports regarding arrears on the following parameters:
a. Amount of arrears by administration
b. Amount of arrears by tax type
RC04.F.12 MIS reports The system should provide MIS reports regarding Collection of arrears based on enforcement steps.
Section V. Requirements of the Information System 447

8 – REVENUE ENFORCEMENT (RE)

ID Name Description

RE01.F.1 Automated Enforced The Revenue Enforcement workflow should have the capability of performing and controlling automated and
Collection manual process steps.
RE01.F.2 Unique ID number The system should allow the attribution of a unique ID number for each enforced collection file.
RE01.F.3 The Enforced Collection The system should allow maintaining a Collections Case Folder for each enforced collection case, that
cases consists of:
a) Returns/other contributing documents;
b) Notices (advising the Taxpayer there is an arrears);
c) Registration Risk History and Profile Data;
d) The Accounts;
e) Registration Data;
f) Taxpayers Bank Accounts;
g) Taxpayer Assets;
h) The time the Case is opened, and
i) Jurisdiction.
RE01.F.4 Workflow Integration The system should allow for the existence of a Workflow subsystem connection between Accounts and
Enforced Collection to transport the Collections Folder from Accounts Arrears Management to the correct
Enforced Collections jurisdiction.
RE01.F.5 Workflow – Process The Workflow subsystem should allow for maintaining the Administration process performance data.
Administration Control Process performance data allows Tax Administration to remediate bottlenecks in a process. Increasing
staffing in a process step might decrease service times and increase overall process performance.
RE01.F.6 Workflow – Individual The Workflow subsystem should allow for maintaining the individual process performance information.
Process Performance Individual process performance data allows Tax Administration to evaluate personnel performance for
training purposes and to increase efficiency. This is particularly important to Collections Staff in monitoring
case team performance.
RE01.F.7 Workflow – Case The Workflow subsystem should allow for monitoring the performance of each Enforced Collection Case
Monitoring overall.
RE01.F.8 Workflow – Enforced The Workflow subsystem should allow for monitoring each step in the Enforcement method, tracking the
Collection Case Control work time for each stage in the Enforced Collections process.
RE01.F.9 Arrears Inventory The system should allow for maintaining an Arrears Inventory.
Arrears Inventory consists of the number of collection cases (case folders allocated to the Enforced
448 Section V. Requirements of the Information System

ID Name Description
Collection Unit) and in the nationwide, allocated to County’s and allocated to a Local Unit for Collection.
RE01.F.10 Enforced Collections The system should allow for composing Enforced Collections report that defines the number of collections
Reports and amount secured by:
• Each Local Office
• Each County
• Each Enforced Collection Region, and
• Nationally.
RE01.F.11 Automated Real Time The system should allow for creating real time collections amounts actually secured in accordance with
Collections arrears amounts collected and posted to the accounts.
RE01.F.12 Enforced Collections Plan The Enforced Collections Central Unit should create a system supported collections target based on
available manpower for Enforced Collection. The Enforced Collection projection or target is based on
previous year’s collection activities and the number of teams that were producing results by jurisdiction.
The objective should be introduced into the system by NAFA and the plans should be monitored each
month against actual performance against the commitment.
RE01.F.13 Enforced Collection case The Chief of Service should select the largest arrears first for review, and assignment, continuing until the
segmentation number of accounts selected for Enforced Collections is equal to the number and size of cases that were
committed to in the Enforced Collection Plan.
RE01.F.14 The Enforced Collection Every Enforced Collection should result in a Resolution that defines how the debt is satisfied.
Resolution Finalising an Enforced Collection activity should result in a resolution which should update the information
existing within the Taxpayer Risk History and Profile database. The resolution defines how the debt will be
settled. There are a number of possible alternatives that might satisfy the debt, specifically:
• Payment in installments
• Bank payment;
• Garnishment;
• Seizure;
• Another party held liable;
• Insolvability;
• Business Bankruptcy, resulting in payment of the debt;
• Statue of limitations.
EC02 - Resource planning (annual, monthly)
RE02.F.01 Staff availability module The Case Management System (“CMS”) should have a staff availability module that contains information
about:
- the employee
- specialisation
- grade / seniority level
Section V. Requirements of the Information System 449

ID Name Description
- calendar and status / period (available, not available - fully booked, on vacation, partially available - %
availability)
RE02.F.02 Calendar There should be a calendar of non-working days and vacation periods.

RE02.F.03 Execution staff utilisation The CMS should target 90% staff utilisation on enforced collection activities and should also be able to
compare the availability of existing resources with the estimated work volume.
RE02.F.04 Workload analysis The CMS should be able to compare resource availability (based on user-defined number of employees)
with the estimated workload.
RE02.F.05 Workload assumptions It should be allowed to introduce variables, such as estimation of workload for a type of case (%).

RE02.F.06 Computation The CMS should be able to compute information on yearly, quarterly and monthly basis.

RE02.F.07 Status review and The system should be able to compare the status of activities with planned ones and recalculate the plan for
rescheduling a specific period, by comparing (i.e. delayed activities should be moved together with necessary resources).
RE02.F.08 New parameters Management should be able to perform changes during the period by introduction of new parameters related
to cases and / or staff.
RE02.F.09 Generating the planning The planning reviewed under RE02.F.7 should be electronically generated and the relevant persons should
be notified for approval.
RE02.F.10 Case database The CMS should have a case database embedded that would record and manage all action related to a
taxpayer having arrears, information which should be transmitted from the Taxpayers Accounts Ledger.
The database should classify cases based on the type of action required, so that they are assigned to relevant
officers according to defined parameters.
RE02.F.11 Case creation The CMS should create a new case and should be able to generate a unique case identifier for the created
case, which should contain elements of taxpayer identification, so that all cases related to a taxpayer can be
tracked.
RE02.F.12 Case information The CMS should be able to register metadata to a freshly created case (inter alia): start date/time, ID No,
trigger of the case, taxpayer enforced collection case history, location, workflow of the activity (i.e. seizure
status, sales process status etc.) etc.
RE02.F.13 Case information – The CMS should be able to add any documents to a freshly created case.
attachments
RE02.F.14 Case assignment The CMS should be able to assign a case to a case worker (collection staff) using information from the staff
availability module. Also, the CMS should notify the tax officer and its superior about the case assignment.
450 Section V. Requirements of the Information System

ID Name Description
RE02.F.15 Case assignment – The status of the employee to which a case was assigned should change “available” to “assigned” for the
availability status duration needed for solving the case.
RE02.F.16 Case assignment – manual Manual changes in the status should be possible based on access rights.
changes
RE02.F.17 Case assignment – The CMS should support workload assignment based on past experience, skills, qualifications of staff
previous experience members.
RE03 - Payment facilities
RE03.F.1 Payment facilities The RMS system should allow NAFA to define the legal conditions in which payment facilities can be
conditions granted (e.g. for payment rescheduling, the taxpayer should have to fulfill the relevant conditions as well as
to have all the returns submitted, should find himself/herself in difficulty due to lack of cash, have a
guarantee constituted); these conditions should be available for reading to the taxpayer on the WEBspace.
RE03.F.2 Payment facilities Parameters should be defined and the system should allow for changes to these parameters by NAFA, as per
conditions – changing the the debt collection strategy,
parameters
Note: The parameters represent those elements which are configurable by NAFA’s staff (e.g. deadlines for
submitting a guarantee, value, etc.).
RE03.F.3 Taxpayer account There should be an option available into the taxpayer account to request payment facilities.

RE03.F.4 Request for payment There should be an electronic form that needs to be filled in by the taxpayer / tax administration officer,
facility – form containing all information related to the requests (which debt, how many installments etc. and the
justification that the conditions are met, request motivation).
RE03.F.5 Request for payment The interface should allow attaching documents in various formats (i.e. PDF, .PNG etc.).
facility – attachments
RE03.F.6 Request for payment The form will be available on the website for download, to be filled in manually.
facility – downloadable
form
RE03.F.7 Online submission – The system should allow online submission only if there is a certified electronic signature attached.
digital signature
RE03.F.8 Personal submission The form downloaded and manually completed by the taxpayer (or consultant representing the taxpayer in
its relations with NAFA) should be personally submitted by the taxpayer at NAFA’s facility and afterwards
the form should be introduced into the system by the relevant tax officer. NAFA’s officer should scan and
attach any necessary documents as attachments.
RE03.F.9 Inquiry of Taxpayer risk In case of online submission but also in cases of personal submission, the system should inquire the
Section V. Requirements of the Information System 451

ID Name Description
history and profile Taxpayer risk history and profile database and decide whether original documents and / or guarantee should
database be requested, based on pre-defined criteria. The same Taxpayer risk history and profile inquiry should be
performed for requests filled in by the tax administration officer for deciding on the need for guarantee.
RE03.F.10 Request registration After the inquiry, the system should return a message to the taxpayer either confirming that the request has
confirmation – online been registered and will be reviewed by NAFA, either that the taxpayer needs to submit the original
submission documents and/or guarantee by a deadline, in case not the request being rejected.
RE03.F.11 Request registration In case the request cannot be resolved on the spot, the system should generate a document confirming the
confirmation – in person registration of the request, any additional requirements (i.e. need for guarantee and conditions for
submission constituting it) and estimated deadline for resolution.
RE03.F.12 Eligibility checks The system should perform all the checks/queries needed for determining the taxpayer’s eligibility for
granting payment facilities in accordance with the conditions defined by NAFA at RE03.F.1, including:
- comparing the amounts from the requests with the ones from the Taxpayer Accounts Registry
- querying the Taxpayers Risk History and Profile database
- providing the guarantee and its amount, if the case.
RE03.F.13 Guarantee amount The RMS system should allow NAFA to define criteria for determining the amount of the necessary
guarantees (e.g. the nature of the taxpayer, the age and value of the arrears, its risk history and profile etc.)
and the amount of the guarantee should be automatically provided after the submission of the request. The
criteria previously defined should be modified as NAFA considers necessary.
RE03.F.14 Withdrawal of request for The taxpayer should have the option of withdrawing the initially submitted request. In this case the taxpayer
payment facilities should submit another request to NAFA, either electronically or personally. The system should update the
taxpayer’s status to reflect the withdrawal of request for payment facilities.
RE03.F.15 Automatic If there is enough information in the system (e.g. checking the existence and correctness of the guarantee’s
approval/refusal – value, if the case), based in pre-defined criteria, the system should decide approval/rejection of the request
insufficient information for granting a payment facility.
RE03.F.16 Automatic In case the taxpayer fulfils/does not fulfill all the necessary conditions, the system should approve/reject the
approval/refusal – request for payment facility.
conditions fulfilled/not
fulfilled
RE03.F.17 Further checks In case there is not enough information for the automatic approval to be applied or there are unclear
notification elements in the request, the system should send a notification to a collection officer, who will analyse the
request and either make a decision based on existing information, either ask the taxpayer for additional
information/documents.
RE03.F.18 Recalculation of interest Upon the approval of the request, the system should recalculate debts, interests and penalties, according to
and penalties payments effected by the taxpayer
452 Section V. Requirements of the Information System

RE03.F.19 Posting the Taxpayer Approval/refusal are posted in the Taxpayer Accounts Registry and WEBSpace account.
ID Name Description
Accounts Registry and
WEBSpace account
RE03.F.20 Outreach Program – The system should compose a short message indicating that there is a resolution posted and send it to the
Short message taxpayer by means preferred by him/her.
RE03.F.21 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
RE03.F.22 Document management The request, resolution, message to the taxpayer should be stored as documents in the Document
Management database.
RE03.F.23 Matching the payments The system should scan periodically the account to identify outstanding liabilities. In addition, the system
with the installments should periodically monitor the fulfillment of the conditions for granting the payment facility but also the
schedule and monitoring taxpayer’s conformation with the approved instalments’ schedule containing the deadlines for payments of
the conditions for each instalment.
applying the payment
facility
RE03.F.24 Cancelling the payment In case the system detects the nonfulfillment of the conditions for maintaining the payment facility, it
facility – notification for should automatically generate a notification to the taxpayer which should be sent using the agreed means
not fulfilling the (e.g. WEBSpace account, email, SMS, fax, etc.). More specifically, in case the taxpayer delays the payment
conditions of an instalment, the event is signalled by the system and the taxpayer is announced about this and advised
to solve the problem and/or to provide explanations to justify the nonfulfillment of conditions within the
deadline established by NAFA.
RE03.F.25 Cancelling the payment In case the taxpayer does not solve the problem or does not provide explanations regarding the cause of not
facility – no answer fulfilling the conditions in the pre-established deadline, the system automatically cancels the payment
facility and the enforced collection procedure should continue for the remaining debt.
RE03.F.25 Cancelling the payment In case the taxpayer solves the problem the system should commence monitoring the fulfilment of the
facility – answer conditions for maintaining the payment facility. In case the taxpayer’s answer contains
explanations/documentation for justifying the nonfulfillment of the conditions for maintaining the payment
facility, the system should notify the responsible tax officer which should then analyse the said
documentation.
RE03.F.26 Posting the Taxpayer Losing the validity of the payment facility/continuing monitoring the conditions for maintaining the
Accounts Registry and the payment facility are posted in the Taxpayer Accounts Registry and in the WEBSpace account.
WEBSpace account
RE03.F.27 Outreach Program – The system should compose a short message indicating that there is a resolution posted and send it to the
Short message taxpayer by means preferred by him/her.
Section V. Requirements of the Information System 453

RE03.F.28
ID Taxpayer
Name risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
Description
profile database update Registration Record up to date).
RE03.F.29 Document management The request, resolution, message to the taxpayer should be stored as documents in the Document
Management database.
RE03.F.30 Changing the payment in The taxpayer should ask for the inclusion into the facility of other taxes or for the change of initial period of
instalments payment/amount of instalments. In this case, RE03.F.15 – RE03.F.32 functional requirements should be
repeated.
RE03.F.31 Recovering a lost payment In case the payment in instalments has been lost, the taxpayer should submit a request for maintaining its
in instalments validity, before the guarantee’s execution. RE03.F.15 – RE03.F.32 functional requirements should be
repeated.
RE04 - Guarantees
RE04.F.1 Cases when guarantee is Legal conditions in which guarantees can be requested/released/executed and the amounts should be
required, can be released defined by NAFA into the RMS system; these should be available for reading to the taxpayer on the
or executed WEBspace. Parameters should be defined by NAFA and the system should allow changes of the parameters
by NAFA according to debt collections strategy.
RE04.F.2 System request for The system should be able to identify the taxpayer requests which meet the conditions for guarantee and
guarantee display a message after the submission of the request online.
RE04.F.3 Communicating the If the request for guarantee is performed on-line, the system should send into the WEBSpace account a
message to the taxpayer message containing the request (amount, deadline, etc.) together with a link to the detailed procedure.

If the request for a guarantee is performed in person, the system should send a similar message to the tax
officer responsible with sending the relevant information to the taxpayer.
RE04.F.4 Guarantee in kind - The system should identify the box checked which means that the taxpayer has expressed the option for
Option constituting a guarantee in the form of movable or immovable goods.
RE04.F.5 Guarantee in kind – The system should detect whether or not documents were attached (valuation report) which should attest the
Attached documents market value of the good. In case such documents were not attached, the system should generate an alert to
the taxpayer in order for him to comply. If the taxpayer has attached such document, the system should
forward them to the tax officer responsible with their analysis.
RE04.F.6 Guarantee in kind – Value The system correlates the amount owed with the estimated valued of the goods constituted as guarantee.
correlation Next the system should replicate the functional requirements RE08.F.6 – RE08.F.16.
RE04.F.7 Proof of guarantee The system should identify guarantees within payment information provided by the Treasury, connect it to a
submission - Cash taxpayer and compare this information with the required amount.
RE04.F.8 Proof of guarantee The tax officer should manually introduce into the system, the amount from the documentation received
454 Section V. Requirements of the Information System

ID Name
submission – Other types Description
from the taxpayer. The system should compare the amount input by the tax administration officer with the
required amount.
RE04.F.9 Surety contract NAFA defines parameters to be inserted into the system.
(“fidejusiune”) – Defining
parameters
RE04.F.10 Surety contract The surety contract is automatically approved by the system provided that the taxpayer (who electronically
(“fidejusiune”) – Fitting submitted the contract) falls within the limits of the parameters previously established.
into the parameters
RE04.F.11 Surety contract In case the taxpayer does not fall within the limits of the parameters, the system generates a short message
(“fidejusiune”) – Not for notifying the taxpayer as regards the need to submit the original contract and the related deadline for this
fitting into the parameters action.
– generate notification
message
RE04.F.12 Surety contract The previously generated message is automatically sent by the system to the taxpayer, through the
(“fidejusiune”) – Not previously agreed means of communication (SMS, fax, e-mail).
fitting into the parameters
– taxpayer notification
RE04.F.13 Approval of requests The system should conform that the guarantee has been submitted and should send an alert to the other
processes which imply submitting a guarantee as well as the approval preconditions (e.g. lifting the
precautionary measures, suspending the enforced collection, payment facilities).

As regards the approval of the requests, posting the Taxpayer Account Registry, taxpayer communication
and databases update, please refer to the functional requirements related to steps RE03, RE05 and RE11.
RE04.F.14 Releasing the guarantee – The system should inquire periodically the cases with deposited guarantees checking whether the reasons
automated release for the guarantee still exist and all other conditions for automated release are met.
condition
RE04.F.15 Releasing the guarantee – If the case may be, the Tax Administration should define the criteria for the automated release of the
automated release guarantee.
RE04.F.16 Releasing the guarantee – The system should provide the taxpayer with the possibility to opt a box to be checked and which allows for
taxpayer option the financial guarantee to be used for paying other tax obligations.
RE04.F.17 Posting the Taxpayer Option to release or release of the guarantee should be posted in the Taxpayer Accounts Registry and in the
Account Registry and WEBSpace account.
WEBSpace account
Section V. Requirements of the Information System 455

RE04.F.18
ID Outreach
Name Program – The system should compose a short message indicating that there is a resolution posted and send it to the
Description
Short message taxpayer by means preferred by him/her.
RE04.F.19 Printing centre – The release of guarantee should be transposed into a document to be handed to the taxpayer, based on a
preparing the document predefined template.
RE04.F.20 Printing centre – option The system should allow opting for document retrieval at the tax office or mailing with receipt confirmation
or receiving it from the WEBSpace account.
RE04.F.21 Printing centre – mailing If there is no option or the document is not retrieved from the tax office in a defined number of days, it
should be sent to the massive printing centre for mailing, with receipt confirmation.
RE04.F.22 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).

RE04.F.23
Document management The request, resolution, message to the taxpayer should be stored as documents in the Document
Management database.
RE04.F.24 Executing the guarantee If the periodical inquiry should indicate the unfulfillement of for which the guarantee was deposited the
system should immediately notify the Treasury/bank to execute the financial guarantees or should mark the
case as ready for enforced collection of the other goods related to guarantees in kind.

RE04.F.25 Competency delegation For goods which are under the jurisdiction of other Tax Administration, the system should automatically
send a delegation of competency for attributing the case to the Tax Administration under whose jurisdiction
the good resides. The delegation of competency should be followed by all justifying documents necessary
for executing the guarantee.
RE04.F.26 Posting the Taxpayer Start of the execution of the guarantee should be posted in the Taxpayer Accounts Registry and in the
Account Registry and WEBSpace account.
WEBSpace account
RE04.F.27 Outreach Program – The system should compose a short message indicating that there is a resolution posted and send it to the
Short message taxpayer by means preferred by him/her.
RE04.F.28 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
RE04.F.29 Document management The execution, start of sale, message to the taxpayer should be stored as documents in the Document
Management database.
456 Section V. Requirements of the Information System

ID Name Description
RE05 - Precautionary measures
RE05.F.1 Precautionary measure The Enforced Collection should receive notifications from control bodies within NAFA such as Tax Audit,
notification Antifraud and Customs or other institutions of precautionary measures to be performed.
Notifications should either be transmitted from other modules of the RMS system or on paper in case they
are issued by other institutions or generated by enforced collection.
RE05.F.2 Precautionary measure The system should upload the decision for justifying the application of the precautionary measure, either
decision upload automatically from the notification message or by an enforced collection officer.
RE05.F.3 Posting to the Taxpayer The precautionary measure should be posted in the Taxpayer Accounts Registry and in the WEBSpace
Accounts Registry and account, at the same time with the measure accomplishment.
WEBSpace account
RE05.F.4 Outreach Program – The system should compose a short message indicating that there is a precautionary measure posted and
Short message send it to the taxpayer by means preferred by him/her. The message will include information about the
possibility to constitute a guarantee.
RE05.F.5 Printing centre – Sending If the taxpayer has opted for receiving the decision by Post or if it has not expressed its option in this
the decision by post regards, the decision should be transmitted together with the implementation method to the Massive
Printing Unit to be sent by Post, with receipt confirmation.
RE05.F.6 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).

RE05.F.7
Document management The decision and message to the taxpayer should be stored as documents in the Document Management
database.
RE05.F.8 Option regarding The system should allow for the expression of the guarantee, through the WEBSpace account.
submitting the guarantee
RE05.F.9 Notification regarding the In cases when, when applying the precautionary measure it is found that the goods and income of the debtor
insufficiency of taxpayer’s are not sufficient or are totally missing, the system should generate a recording of proceedings which should
patrimony contain the existing facts, which should be sent to the body which disposed the measure.
RE05.F.10 Notification for lifting the The Enforced Collection should electronically receive notifications from NAFA’ control bodies such as Tax
precautionary measure Audit, Customs, Antifraud or other institutions of precautionary measures to be lifted.
RE05.F.11 Lifting of The system should inquire the Taxpayer account for active arrears under enforced collection and, in case
garnishment/seizure there are none, the garnishment/seizure should be lifted. If there are any arrears, the normal course of the
enforced collection should be followed.
RE05.F.12 Posting the Taxpayer The termination of the precautionary measure should be posted in the Taxpayer Accounts Registry and in
Accounts Registry and the WEBSpace account.
Section V. Requirements of the Information System 457

ID Name Description
WEBSpace account
RE05.F.13 Outreach Program – The system should compose a short message indicating that the precautionary measure is lifted and send it
Short message to the taxpayer by means preferred by him/her.
RE05.F.14 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
RE05.F.15 Document management The decision and message to the taxpayer should be stored as documents in the Document Management
database.
RE05.F.16 Transformation of The system automatically inquires for writs of execution through which tax obligations were established,
precautionary measures tax obligations which made subject of outstanding liabilities and in case the conditions are met, the writs of
into writs of execution execution is issued and communicated to the taxpayer (see process RE06).
RE06 - Summons and writs of execution
RE06.F.1 Posting debts of other The system should record debts from other institutions, sent to be recovered by NAFA. The institutions can
institutions – Sent either input the data in a web based interface or can send it (through e-mail, fax) to the Tax Administration
information electronically or on paper in a standardized format.
RE06.F.2 Posting debts of other In case of information related to debts transmitted by other institutions electronically (e-mail and/or fax) or
institutions – on paper, the said information should be introduced manually into the system by NAFA’s staff.
Electronically available
information
RE06.F.3 Identification of overdue The system should identify periodically (e.g. daily) the overdue taxes for each type of tax, both for debts of
taxes/debts the Tax Administrations and for debts received from other institutions.
RE06.F.4 Preparation of summons The system should generate a list containing the amounts owed by the taxpayers. The list should contain the
and writs of execution – owed amounts as well as the amounts owed by the taxpayers to other institutions.
Generated list
RE06.F.5 Preparation of summons The amounts contained within the list mentioned in the previous requirement should be centralized by the
and writs of execution – system based on TIN/PIN.
Centralize amounts
RE06.F.6 Preparation of summons The system should issue the summons and writs of execution divided by those for NAFA and those of other
and writs of execution – institutions. These documents should contain information as regards the next stages within the enforcement
Issuance collection process.
RE06.F.7 Posting the Taxpayer The documents are posted in the Taxpayer Accounts Registry and in the WEBSpace account.
Accounts Registry and the
WEBSpace account
458 Section V. Requirements of the Information System

RE06.F.8
ID Outreach
Name Program – The system should compose a short message indicating that a summon is posted and send it to the taxpayer
Description
Short message by means preferred by him/her.
RE06.F.9 Massive printing unit – The summons/writ of execution should be transposed into documents which should be sent to the taxpayer,
Preparing the document based on predefined templates.
RE06.F.10 Massive printing unit – The system should allow the taxpayer to opt for taking the document from NAFA, receiving it by Post with
Option receipt conformation or receiving it through the WEBSpace account.
RE06.F.11 Massive printing unit – If the option mentioned above has not been expressed or if the document has not been taken from NAFA in
Sending by Post a given deadline, it should be sent to the Massive printing unit for sending by Post, with receipt
confirmation.
RE06.F.12 Recording of The system should record the date when the summons and writ of execution were communicated to the
communication date taxpayer, based on the standardized electronic file received from the 3rd party performing the
communication (e.g. postal services or electronic confirmation from the system).
RE06.F.13 Publishing on NAFA’s If the summon and writ of execution could not be communicated to the taxpayer in a predefined number of
website of summons and days (e.g. 10 days) from the date they were issued, the details should be published on the Tax
writs of execution Administration website.
RE06.F.14 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).

RE06.F.15 Document management The documents and message to the taxpayer should be stored in the Document Management database.

RE06.F.16 Notification to the Update of the electronic archive containing real movable guarantees – The system should periodically issue
Ministry of Economy and (e.g. monthly) a report containing the receivables from the writs of executions (the receivables administered
Finances by the Ministry of Economy and Finances) for updating the electronic archive containing real movable
guarantees.
RE07 – Garnishments
RE07.F.1 Identification of taxpayers The system should identify periodically (e.g. twice a month) taxpayers for which the garnishments should
under garnishment be executed, i.e. taxpayers for which summons were communicated and who confirmed their receipt, as
procedure well as the amounts for which the garnishments should be applied.
RE07.F.2 Identification of bank/ The system should periodically (e.g. twice a month) update taxpayer bank/ treasury accounts data with
treasury accounts information received from the banks/ treasury on new/ closed accounts.

Note: The databases should be integrated into RMS and they should be periodically updated as per the
information received from the third party institutions (for example banks and Treasury).
Section V. Requirements of the Information System 459

RE07.F.4 Requests for electronic

ID Name Description
garnishment The system should centralize garnishments per bank/ treasury and send periodically (e.g. twice a month) to
the headquarters of each bank/ central treasury, in electronic format, the garnishment orders.
RE07.F.5 Confirmation of executing The system should record garnishment confirmations of executions (full or partial garnishment) from
the garnishments banks/Treasury for each taxpayer. The confirmations should be received in a standardized format within a
number of days from the date the garnishment order was sent (e.g. in 2 days).
RE07.F.6 Partial garnishment If the garnishment has not been performed or has been partially performed, the process should be repeated
as regards the amount left unrecovered, for all the bank accounts, as per the prioritization (please refer to
the requirements RE07.F.2, RE07.F.3, RE07.F.4 and RE07.F.5)
RE07.F.7 Posting the Taxpayer The garnishment should be posted in the Taxpayer Accounts Registry and in the WEBSpace account.
Accounts Registry and
WEBSpace account
RE07.F.8 Outreach Program – The system should compose a short message indicating that there is a garnishment posted and send it to the
Short message taxpayer by means preferred by him/her.
RE07.F.9 3rd party garnishments The system should compile a list with 3rd parties (employers or clients of the debtor under D394-
Declaraţie informativă privind livrările/prestarile şi achiziţiile efectuate pe teritoriul national) for which the
garnishment process can start. Also, for identifying the economic relations of the main debtor, return D112
should be used or any other return which can provide information in this regard, as well as data from the
trial balance, more specifically account 411.
RE07.F.10 Prioritization of 3rd party The prioritization of third parties as regards the garnishments is determined depending on the amount to be
garnishments recovered compared with the owed amount, so as for the garnishments to be applied to a minimum number
of third parties, but in order for the receivable to be recovered.
RE07.F.11 Issuing third party The system should issue the decision for garnishment in the previously established order.
garnishments
RE07.F.12 Lifting the garnishments Once the system detects the full recovery of the debt as well as the source for covering the debts, it should
issue an order for lifting all the garnishments as well as those on other third parties.
RE07.F.13 Notification regarding The confirmation of the garnishment from a 3rd party should be posted within the WEBSpace account and/
lifting the garnishment or communicated on paper to the taxpayer and to the 3rd party.
RE07.F.14 Posting the Taxpayer The confirmation of garnishment on a third party is posted in the Taxpayer Accounts Registry and in the
Accounts Registry and WEBSpace account, both for the main debtor and for the third party.
WEBSpace account
RE07.F.15 Outreach Program – The system should compose a short message indicating that a garnishment on a third party is posted and
Short message send it to the taxpayer by means preferred by him/her (both main debtor and third party).
460 Section V. Requirements of the Information System

RE07.F.16 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
ID Name Description
profile database update Registration Record up to date).

RE07.F.17 Document management The above should be stored as documents in the Document Management database.

RE08 - Seizure of goods

RE08.F.1 Identification of taxpayers The system should identify periodically (e.g. twice a month) taxpayers for which the garnishments could
under seizure procedure not be executed, i.e. no amounts available in bank accounts or with 3rd parties. For these taxpayers, the
seizure procedure should be initiated. More specifically, the system should query the Taxpayer Accounts
Registry and should extract the amounts which have not been recovered through garnishments. These
amounts should turn into seizures.

The procedure for seizure of goods can be performed in parallel with the garnishments, depending on the
risk history and profile of the taxpayer.
RE08.F.2 Case creation The system should create a case for each situation in which after the expiry of the deadline from
communicating the summon, the taxpayer has not paid or in case the seizure process is performed in
parallel with the instituting the garnishment.
RE08.F.3 Case assignment The system should allocate the case to an appropriate and available enforced collection officer, as per the
criteria defined in the resource planning process.
RE08.F.4 Integration with external The system should be able to extract information on goods owned by the taxpayer from external data bases,
data bases and other such as:
information • Vehicle Registry (Bază de date Inmatriculari)
• Land Registry (Oficiul de Cadastru si Publicitate Imobiliară)
• Movable Guarantees Electronic Archive (Arhiva Electronică de Garanții Reale Mobiliare)
• Financial Investment Entities (Societăţi de Investiţii Financiare)
• Central Repositoy (Depozitarul Central)
• Vessels Register (Înmatriculări Nave)
• Aircrafts Register (Registrul Aeronautic)
• Deposit boxes (Cutii de valori)
• Trade Registry (Registrul Comerţului)
• Local taxes (Taxe locale)
The list above is not exhaustive in the sense in which it can comprise other data bases of other public or
private institutions which hold information as regards other goods in the debtor’s patrimony.

In the same time, the system should extract relevant information regarding the debtor’s patrimony also from
Section V. Requirements of the Information System 461

ID Name Description
its financial statements or from the balance sheet (data from relevant accounts).
RE08.F.5 Market value For the purpose of the current process, the system should take into consideration the estimated market value
of the goods.
RE08.F.6 Selection of taxpayer's The system should match the value of the debt with the estimated value of the goods and prioritize goods
goods to be seized based on criteria predefined by NAFA, to provide a selection of goods to be seized. The order should be
determined by the degree of covering the debt so as for a minimum number of goods to be seized.
RE08.F.7 Allocation of goods to be The goods should be allocated by the system to the relevant Tax Administration for confirmation and for
seized realizing the physical inspection.
RE08.F.8 Debt lower than the value In case the debtor has a debt which is below the value of each good in its property, the system should select
of each good the good with having the market value as close as the debt’s value as possible.
RE08.F.9 Physical inspection of The system should record the location of the goods and whether they should remain with the debtor or a
goods to be seized custodian.
RE08.F.10 Seizure recording of The system should issue the Seizure Note, which should be signed by both the Tax Administration
proceedings representative, the debtor and the custodian, if applicable. The signed Seizure Note should be available in
the system.
RE08.F.11 Posting the Taxpayer The seizure note is posted in the Taxpayer Accounts Registry.
Accounts Registry
RE08.F.12 Taxpayer risk history and
profile database update The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
Registration Record up to date).

RE08.F.13 Document management The seizure note and message to the taxpayer should be stored in the Document Management database.

RE08.F.14 Seized goods inventory There should be a database in the system with the inventory of all seized goods (movable and immovable
goods), with the exception of perishable goods (please refer to RE10) by type (e.g. property, car, electronic
equipment etc.) containing:
- all necessary identification data pre-defined for each type of goods (i.e. for cars: registration no);
- a status (awaiting auction, auction in progress, awaiting second auction, sold, payment received, property
transferred, good delivered to the buyer, not sold, returned to the debtor etc.);
- its location (with all details to easily locate the item if it is stored in NAFA's warehouse).
RE08.F.15 Seized goods inventory – Each item in the inventory should contain a unique property number that is associated with a specific
Unique property ID resolution. The property ID allows the proper amount paid for items disposed of through the online auction
to be credited to the Taxpayers Tax Debt.
462 Section V. Requirements of the Information System

RE08.F.16 Seized goods inventory – The system should allow introduction of groups /packs of goods. They can be created for identical goods
ID Name Description
Groups/packs of goods that should be sold together because the value / unit is higher than the enforced collection cost (i.e. fast
moving consumer goods). The quantity should be specified (no of units, weight etc.).
RE08.F.17 Seized goods inventory – The system should allow upload of attachments, such as pictures of the goods or scanned documents if
other attachments necessary, in a compressed form.
RE08.F.18 Seized goods inventory – The records related to the items which may not be subject to auction (i.e. property transferred or returned to
active/inactive the debtor) should be archived after a defined period (i.e. for the statute of limitation period / annually etc.).
RE08.F.19 Registration of the The system should issue a notification to the institution that is in charge with registering the mortgage.
mortgage Note: In case an interface should be developed for these institutions, the notification will be automatically
sent. If not, the notification should be taken over by a tax officer and sent as per the existing cooperation
protocol.
RE08.F.20 Confirmation of mortgage The system should allow recording the mortgage confirmation received from the institution that is in charge
registration with registration (either manually or through the interface), together with information on mortgages
registered by other creditors for the same good.
RE08.F.21 Notification of intention to The system should issue notifications for all creditors informing them of the intentions to sell the good, the
sell auctioning procedure and estimated auctioning date.
RE08.F.22 Application for release of Once the guarantee is approved, the system should automatically lift the seizure (please refer to RE04).
seized good – Constituting
the guarantee
RE08.F.23 Application for release of The system should analyse the information it holds and in case the taxpayer has performed the full payment
seized good – Debt of its debt (principal and accessories), the system should release the goods from seizure.
payment
RE08.F.24 Replacing the seized Once the measure for replacing the seized goods has been approved, the system should automatically move
goods the seizure from one good to another.
RE08.F.25 Posting the Taxpayer The release from seizure and debt payment (principal and accessories) are posted into the Taxpayer
Accounts Registry and the Accounts Registry and into the WEBSpace account.
WEBSpace account
RE08.F.26 Outreach Program – The systems should compose a short message indicating the fact that the debt payment (principal and
Short message accessories) together with the release from seizure have been posted and the message should be sent to the
taxpayer via the preferred means.
RE08.F.27 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
Section V. Requirements of the Information System 463

RE08.F.28
ID Document
Name management The information mentioned above should be stored in the Document Management database.
Description

RE09 - Transfer of property

RE09.F.1 Submitting the request for The taxpayer should submit a request for the transfer of its property either on paper, electronically or
transfer through its WEBSpace account.
RE09.F.2 Evaluation of submitted The process of evaluating the request is identical with the one in RE10 so please refer to the functional
request requirements for this process.
RE09.F.3 Submitting the justifying Similar with the process of submitting the request whose requirements were detailed above, also in the case
documentation of justifying documentation the taxpayer may submit it electronically.
RE09.F.4 Approval/ Rejection of The Tax Administration responsible Manager should record in the system the approval or rejection of the
transfer transfer.
RE09.F.5 Debt settling The system should settle the debt against the property value.
RE09.F.6 Posting to the Taxpayer The debt settling should be posted in the Taxpayer Accounts Registry and WEBSpace account.
Accounts Registry and
WEBSpace account
RE09.F.7 Outreach Program – The system should compose a short message indicating the event and send it to the taxpayer by means
Short message preferred by him/her.
RE09.F.8
Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
RE09.F.9 Document management The above should be stored as documents in the Document Management database.

RE10 - Auctions (sale of seized goods)

RE10.F.1 Evaluation database – There should be another database with standard values by types of goods which should be updated
Automated update periodically (at least annually) based on inflation rate, exchange rate fluctuation, reference prices defined by
the National Property Register or other authorised bodies or other standard indicators, should be possible.
RE10.F.2 Evaluation database – Manual update of the database by an assigned unit / enforced collection officer should be possible for
Manual update certain types of goods. The valuation in discussions should be requested by the officer to an authorised
valuator (please see RE10 – 12 below).
RE10.F.3 Evaluation database – Manual updates should generate requests for approval from superiors.
Approval of the manual
update
464 Section V. Requirements of the Information System

RE10.F.4 Evaluation database – This database should initially contain most frequent types of seized goods and should be upgraded with
ID Name Description
Maintenance additional items, as new types of goods are seized. Introduction of additional items should generate
approval request to a supervisor.
RE10.F.5 Automated evaluation The system should automatically assign a value based on the evaluation database, once the information
related to the type of good and other characteristics relevant for the value is input in the system.
RE10.F.6 Evaluation by an enforced The system should allow manual input of the value when the search in the database does not generate any
collection officer result. Manual overwrite should be allowed, but based on restricted access rights.
RE10.F.7 Evaluation by an external The system should automatically send a notification to an authorised evaluator when the type of good
evaluator – notification requests such and evaluation (i.e. property).
RE10.F.8 Evaluation by an external Authorised evaluators should have a web interface access to see the information related to the property in
evaluator – input of value the inventory, including contact information of the taxpayer, and to input the value. The same web interface
as for auctions should be used (see below requirements related to user name / passwords etc.)
RE10.F.9 Evaluation by an external The system should allow attachment of the evaluation report in PDF format.
evaluator – attachment
RE10.F.10 Posting to the Taxpayer The evaluation decision should be posted in the Taxpayer Accounts Registry and WEBspace account.
Account Registry and
WEBSpace account
RE10.F.11 Outreach Program – The system should compose a short message indicating the event and send it to the taxpayer by means
Short message preferred by him/her.
RE10.F.12 Pre-auction sales Before posting to the auction platform, if the good is sold through other methods allowed by law, the buyer
should create an account on the auction platform. The enforced collection officer should assign the good to
the registered buyer, inputting the "sold" status, awaiting payment. The rest of the steps are identical with
the auction sales.
RE10.F.13 Publishing goods for The system should scan the inventory daily and should publish for auction all goods older than a pre-
auction defined number of days, which are not yet sold or returned to the debtor. The posted announcement should
contain all information related to the good, which is relevant for the sales process and / or is required by
law.
RE10.F.14 Publishing goods for The auction duration, start date and time should be automatically posted (a defined number of days from the
auction – auction posting moment), as well as the registration deadline and conditions (there should be a link to the relevant
information chapter in the auction rules, which should be available online on the same platform).
RE10.F.15 Publishing goods for One auction should be organised for one item (good / group of goods) having a unique ID. All operations
auction – auction file related to the respective auction should be stored in the auction file, identified by the ID of the good and the
number of the auction (first, second, third).
Section V. Requirements of the Information System 465

RE10.F.16 Registration for auction To participate in the auction, each potential bidder should create an account on the website, defining a
ID Name Description
username and password and should input all necessary identification, contact and bank account information.
Requirements in terms of security should be identical with those for creating the taxpayer's webspace.
RE10.F.17 Registration for auction – The system should display the terms and conditions of the process and should request the bidder's
terms and conditions acknowledgement and agreement before proceeding to the next step.
RE10.F.18 Registration for auction – Each user should receive a unique ID, connected to the TIN/PIN, which should be used and disclosed in the
unique ID auction process. The same ID should be used in future auctions.
RE10.F.19 Registration for auction – The website should be connected to a certified online payment facility.
online payment
RE10.F.20 Registration for auction – Payment should be done in one transaction / auction.
one payment
RE10.F.21 Registration for auction – The system should not authorise the finalization of the payment process if the deadline for registration has
rejected payment passed (i.e. 24 hours before the start of the auction) or if the same user has made another payment for the
same auction.
RE10.F.22 Registration for auction – Once the payment is confirmed, the system should post the ID of the registered bidder in the auction file
registration posting and in the bidder's account.
RE10.F.23 Registration for auction – The system should send a notification to the bidder confirming the registration.
confirmation of
registration
RE10.F.24 Bidder's risk history Each bidder’s activities should be recorded in a risk history and activity database
RE10.F.25 Auction login The bidders should be logged with the user name and password and should access the specific auction page
to participate.
RE10.F.26 Parallel auctions The system should allow participation of the same user to multiple auctions in parallel.
RE10.F.27 Auction rules Specific rules for the auction should be visible on the auction page (i.e. bidding steps)
RE10.F.28 Auction opening At the announced date and time the system should launch the auction with the starting price posted in the
announcement, only if there is at least one participant.
RE10.F.29 Bidding – offer posting All active bidders should post their offer which cannot be lower than the starting price.
RE10.F.30 Bidding – list of offers The list of offers should be updated in real time and posted in descendant order.
update
RE10.F.31 Bidding – steps If there are bidding steps defined, the system should not allow postings lower than the thresholds defined by
ANAF (i.e. percentage or amount)
466 Section V. Requirements of the Information System

RE10.F.32
ID Auction
Name – physical The enforcement offices should be able to introduce the offers of more participants that are no logged in
Description
presence directly, using a special interface.
RE10.F.33 Auction closing The auction should be closed if within three minutes from the last call no other higher offer is posted. The
closing should be clearly posted.
RE10.F.34 Auction winner When the auction is closed, the system should post the winning offer, the ID of the winner and the full
hierarchy of offers.
RE10.F.35 Unsuccessful auction If there are no attendants / no offers, the auction should be declared unsuccessful.
RE10.F.36 Unsuccessful auction – The enforced collection officer should be notified so that next auction should be authorised. The proposed
notifying the enforced time, date and starting price are included in the notification. No more than two additional auctions can be
collection officer organised.
RE10.F.37 Next auction The system should send an authorisation request. The manager either authorises the next auction as
authorisation proposed by the system or suggests new time and price, but no later and no less than the price provided by
the system. In the second case, the authorisation needs to be reviewed by a supervisor.
RE10.F.38 Online payment The website should be connected to a certified online payment facility. The amount should be determined
by the system deducting the registration fee (s).
RE10.F.39 Rejected payment The system should not authorise the finalization of the payment process if the deadline has passed (i.e. 48
hours before the start of the auction) or if the amount is not the correct one.
RE10.F.40 Bank transfer In case the buyer wishes to pay by bank transfer (in defined cases for large amounts), the system should
issue a pro-forma invoice containing all necessary information for the payment order, based on the buyer's
request. There should be a separate Treasury account for such payments to avoid confusions with other
types of payments.
RE10.F.41 Bank transfer – payment The system should allow posting of the payment proof within 48 hours from the moment of payment.
proof
RE10.F.42 Prolonged payment term The system should allow extension of the deadline if authorised by an enforced collection manager.
RE10.F.43 Payment in instalments The system should allow payment in instalments provided that this is authorised by an enforced collection
manager, and if certain conditions are met, in which case the system should compute and post the value and
deadline of each instalment.
RE10.F.44 Payment confirmation When the payment is confirmed, the system should send a notification to the buyer.
RE10.F.45 Payment confirmation – The system should compile once a day reports for each enforced collection officer with their assigned cases
manual check where manual checks (i.e. payment proofs) are required and so that the officer should confirm the payment.
RE10.F.46 No payment – lost auction The system should detect the online payments and if no payment is recorded and there is no attached
payment proof, it should notify the bidder that the winner status was lost.
Section V. Requirements of the Information System 467

RE10.F.47
ID No payment – new winner
Name In case there are other offers, the system should notify the next bidder that he / she is the winner (if such
Description
intention was expressed) and that he/ she can pay within a defined period of time.
RE10.F.48 Ownership change The system should issue the ownership change decision and send it to the assigned collection officer, which
decision is responsible for delivering it to the buyer.
RE10.F.49 Ownership change The system should notify the buyer by agreed means that a document was issued and the good is ready for
decision – buyer delivery. The information about location and terms and conditions of delivery should be included.
notification
RE10.F.50 Posting to the Taxpayer Once the ownership change decision should be issued, it should be posted to the Taxpayer Accounts
Accounts Registry and Registry and on the WEBSpace account.
WEBSpace account
RE10.F.51 Outreach Program – The system should compose a short message indicating the ownership change and send it to the taxpayer by
Short message means preferred by him/her.
RE10.F.52 Recalculating liabilities The system should recalculate the liability based on the payment value.
RE10.F.53 Update of the History and The system should update the History and risk profile database.
risk profile database
RE10.F.54 Document management Information mentioned above should be stored in the Document management database.

RE10.F.55 Printing centre – mailing Relevant documents should be generated by the system to be printed and sent by post mail to the buyer.

RE10.F.56 Options for the The system should notify the bidder who lost the auction to opt for reimbursement methods (using the fee
reimbursement of the as credit for other auctions or reimbursement via the same bank account).
participation fee
RE10.F.57 Participation fee The system should automatically proceed according to the participant's option.
reimbursement
RE10.F.58 Failed auction After 3 unsuccessful auctions, the system should declare the auction as being unsuccessful and should
notify the relevant enforced collection officer.
RE10.F.59 Taxpayer communication The system should notify the taxpayer by agreed means that the good should be returned but unavailable
– short message until the statute of limitation ends.
RE10.F.60 Transfer of property to If the good is not sold during the statute of limitation period, the system should notify the enforced
the state collection officer to start the procedure for transfer of the property to the state.
RE10.F.61 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database.
profile database update
468 Section V. Requirements of the Information System

RE10.F.62
ID Document
Name management The information mentioned above should be stored in the Document Management database.
Description

RE11 - Release and allocation of the amounts collected by enforcement

RE11.F.1 Defining conditions for The system should contain o series of predefined conditions necessary to be fulfilled in order for the release
releasing the amount of amount to take place (e.g. the deadline which should elapse from the moment the relevant amount has
been collected).
RE11.F.2 Defining the order of The system should contain a predefined order according to which the amounts should be distributed.
distribution
RE11.F.3 Checking the deadline The system should check the elapse of the predefined deadline (e.g. 15 days) from the date the amount
which should be released/distributed has been collected.
RE11.F.4 Debt lower than the If the debt is lower than the amount recovered through enforced collection, the system should notify the
amount collected through taxpayer using the means of communication previously agreed (e-mail, fax, WEBSpace account).
enforced collection –
Taxpayer notification
RE11.F.5 Checking the existence of The system should check the existence of other debts.
other debts
RE11.F.6 Existence of other debts The system should allocate the amounts for closing those other debts, in the order of priorities defined
within RE11 process.
RE11.F.7 Notifying the creditors - The system should generate o notice to the creditors as regards their participation in the process of
Format distribution of the amount in question.
RE11.F.8 Notifying the creditors – The system should compose a short message as regards the existence of the notice and the message should
Short message be sent to the taxpayer through the preferred means of communication.
RE11.F.9 Posting the Taxpayer The notice should be posted into the Taxpayer Accounts Registry.
Accounts Registry
RE11.F.10 Posting the Document The notice should be posted into the Document Management database.
Management database
RE11.F.11 Printing unit – Document The notice should be transposed into a document.

RE11.F.12 Printing unit – Send by In case the notice cannot be communicated to the taxpayer through other means, the system should send the
post document to the Massive Printing Unit to be transmitted by post, with receipt confirmation.
RE11.F.13 Deadline for receivable The system should contain a predefined term (as per the legislation in force) up to which receivables titles
titles can be received.
Section V. Requirements of the Information System 469

ID
RE11.F.14 Name
Distribution of amounts Description
The system should distribute the manually checked/approved amounts depending on the pre-established
priorities and based on the receivable titles received/existing into the database,
RE11.F.15 Proportional distribution If the receivables have the same order of preference, the system distributes the amount proportional with
each receivable.
RE11.F.16 Amounts left The amount remained are distributed depending on the age of the tax obligations and as per the legislation
undistributed in force.
RE11.F.17 Recording of proceedings The system should issue the recording of proceedings regarding the release/distribution of amounts.
- Issuance
RE11.F.18 Recording of proceedings The recording of proceedings should automatically be posted on NAFA’s website.
- Publication
RE11.F.19 Restitution of amounts – The system should notify the taxpayer as regards the existence of a positive balance after closing the debts.
Taxpayer notification
RE11.F.20 Restitution of amounts – The system issues a notification to the Treasury as regards restitution of the positive balance.
Treasury notification
RE12 - Suspension of enforcement procedure
RE12.F.1 Automated suspension of In case there are payment facilities approved, in case the taxpayer is subject to insolvency or bankruptcy or
enforcement procedure in case the taxpayer pays the debt (principal and additional amounts) the system should automatically
suspend the enforcement procedure.
RE12.F.2 Manual suspension of The system should allow manual introduction of reasons for suspension (e.g. Court decision), including
enforcement procedure attachment of documents. The system should operate the suspension immediately after the introduction of
such reasons by the enforced collection officer.
RE12.F.3 Application for The system should provide the taxpayer with a predefined template to be electronically filled and submitted
suspension through the WEBSpace account.
RE12.F.4 Application for The interface should allow for electronic documents to be attached in different formats (e.g. .PDF, .png,
suspension – attachments etc.) so as for the justifying documents (e.g. guarantees, other evidences etc.) to be provided.
RE12.F.5 Application for The system should instantly check the introduced data for errors.
suspension – formal check
RE12.F.6 Application for In case of errors, the system should instantly send error alerts to the taxpayer for corrections.
suspension – errors alert
RE12.F.7 Application for The system should be able to compare data in the application and taxpayer risk history and profile with
suspension – initial criteria for granting the suspension.
analysis by the system
470 Section V. Requirements of the Information System

RE12.F.8
ID Application
Name – content The system should push the analysis to an enforced collection manager together with initial findings and
Description
analysis recommendations.
RE12.F.9 Issuing the decision The approval / rejection decision should be taken by the responsible manager.

RE12.F.10 Posting to the Taxpayer The notification should be posted within the Taxpayer Accounts Registry and WEBSpace account.
Accounts Registry and
WEBSpace account
RE12.F.11 Outreach Program – The system should compose a short message alerting that there are new notifications and should send it to
Short message the taxpayer via the preferred means.
RE12.F.12 Printing centre – sending The decision should be transposed into a document.
by post mail
RE12.F.13 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt signature or receiving it by the WEBSpace account.
RE12.F.14 Update of the Taxpayer The system should update the Taxpayer history and risk profile database.
history and risk profile
database.
RE12.F.15 Document management The decision should be stored into the Document Management database.

RE13 - Failure to pay

RE13.F.1 System information – The system should analyse the information available in the system and third party sources to determine any
electronic analysis potential sources of income to be used for extinguishing the debt.
RE13.F.2 System information – The system pushes the results to the interface used to communicate with the Tax Administration officer.
analysis results
RE13.F.3 Report – template The system should generate a report template to be used by the Tax Administration officer.

RE13.F.4 Report – workflow Submission for review, approval, rejection should be done through the system.
RE13.F.5 Report – comments The system should allow addition of comments / suggestion by the manager.

RE13.F.6 Report – changes The system should record all changes in the document.
Section V. Requirements of the Information System 471

RE13.F.7
ID Issuing
Name the decision The decision should be issued automatically upon approval, based on a predefined template.
Description

RE13.F.8 Inactivation The decision should trigger automated inactivation of the debt, which is moved in a separate database and
the case should stop being pursued for enforced collection.
RE13.F.9 Posting to the Taxpayer The inactivation / write-off should be posted in the Taxpayer Accounts Registry and WEBspace account.
Accounts Registry and
WEBSpace account
RE13.F.10 Outreach Program – The system should compose a short message indicating the event and send it to the taxpayer by means
Short message preferred by him/her.
RE13.F.11 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database (that the taxpayer is keeping their
profile database update Registration Record up to date).
RE13.F.12 Document management The above information should be stored in the Document Management database.

RE13.F.13 Periodic inquiry The system periodically reviews (at least once per year) the activity of the taxpayer to search for evidence
of regained solvency.
RE13.F.14 Solvency regained The system should automatically reactivate and trigger the start of the enforced collection procedure for
taxpayers that appear to have regained solvency, suspending the statute of limitation.
RE13.F.15 Posting to the Taxpayer The reactivation of the debt should be posted to the Taxpayer Accounts Registry and WEBSpace account
Accounts Registry and
WEBSpace account
RE13.F.16 Outreach Program – The system should compose a short message indicating the event and send it to the taxpayer by means
Short message preferred by him/her.
RE13.F.17 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database.
profile database update
RE13.F.18 Document management The above information should be stored in the Document Management database.

RE14 - Insolvency
RE14.F.1 Notification for opening of The system receives the notification and send it further to the Enforcement unit.
the insolvency procedure
RE14.F.2 Suspension of the After receiving the above notification/ manual introduction of the data, the system suspends the
enforcement- insolvency enforcement actions.
RE14.F.3 Joint liability The system should generate a message to the officer responsible in this concern, about the fulfilment of the
472 Section V. Requirements of the Information System

ID Name Description
conditions for triggering the joint liability procedure.
RE14.F.4 Joint liability – stop of the In case of not fulfilling the conditions discussed, the process of enforcement is stopped.
enforcement
RE14.F.5 Third party databases – The system should perform inquiries on a regular basis of the third party databases for information related
periodic inquiry to the wealth and the debtor’s capacity to pay. The system should interrogate the databases for information
related to the debtor’s affiliates, his creditors etc.
RE14.F.6 Regaining the solvency In case of identification of capital input in favour of the taxpayer, the system should declare the solvency of
the debtor.
RE14.F.7 Regaining the solvency – The system should generate a letter for summon to interviews for the taxpayer’s debtors.
Summon letter
RE14.F.8 Posting to the Taxpayer The letter for summons should be posted to Taxpayer Accounts Registry and WEBSpace account.
Accounts Registry and
WEBSpace account
RE14.F.9 Outreach Program – The system should compose a short message indicating the event and send it to the taxpayer by means
Short message preferred by him/her.
RE14.F.10 Printing centre – sending The letter for summon should be transposed into a document.
by post mail
RE14.F.11 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt signature or receiving it by the WEBSpace account.
RE14.F.12 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE14.F.13 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database.
profile database update
RE14.F.14 Document management The letter of summon should be stored in the Document Management database.

RE14.F.15 Closing the insolvency Provided that the conditions are fulfilled (the refuse of paying the debts by the creditors, inexistent goods or
procedure insufficient ones), the insolvency procedures is closed.
RE14.F.16 The deregistration of the The system should deregister the taxpayer.
taxpayer
RE15 - Joint/Subsidiary liability
Section V. Requirements of the Information System 473

RE15.F.1
ID Defining
Name the taxpayers to The system should identify the taxpayers to be jointly held responsible based on criteria pre-defined by
Description
be jointly held responsible ANAF.
RE15.F.2 Data analysis - automated The system should have the capabilities of analysing the electronic information and generating patterns and
trends so as to determine the taxpayers (defined in the previous step) to be held liable together with the
principal debtor.
RE15.F.3 Data analysis - manual The system should push the results from the previous step, together with all the other
information/documents which hadn't been electronically analyzed, to the relevant personnel for further
analysis.
RE15.F.4 Determining the amount The same analysis should be applied to establish the amount of the debt that falls under the procedure.

RE15.F.5 Notification for hearing The system should generate notification for hearing, with the information of the taxpayer to share the
responsibility with the principal debtor.
RE15.F.6 Posting to the Taxpayer The hearing notification should be posted within the Taxpayer Accounts Registry and the WEBSpace
Accounts Registry and account.
WEBSpace account
RE15.F.7 Outreach Program – The system should compose a short message alerting that there are new notifications and should send it to
Short message the taxpayer.
RE15.F.8 Printing centre – Hearing notification should be transposed into a document to be mailed to the taxpayer, based on a
Preparing the document predefined template.
RE15.F.9 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt signature or receiving it by the WEBSpace account.
RE15.F.10 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE15.F.11 Taxpayer risk history and The system should update the Taxpayer Risk History and Profile database with the notification for hearing.
profile database update
RE15.F.12 Document management The notification for the hearing should be stored in the Document management database.
RE15.F.13 Taxpayer's confirmation Taxpayer should confirm the receipt of the hearing notification through a response from his WEBSpace
account, an e-mail, SMS, etc.
RE15.F.14 Request for delay The taxpayer should have the possibility of requesting a delay in the hearing process. The option should be
requested through a response from his WEBSpace account, an e-mail, SMS, etc. The taxpayer should
specify the justification and proposed date for the hearing.
474 Section V. Requirements of the Information System

RE15.F.15
ID Request
Name for delay – The Tax Administration officer should receive the taxpayer's request and should analyse the taxpayer's
Description
approval or rejection justification and possibility of delaying the hearing. An approval/rejection decision should be issued.
RE15.F.16 Hearing resolution The resolution should be input in the system.

RE15.F.17 Hearing resolution – In case the answer is negative than all the measures for applying the procedure should be stopped by the
rejection system.
RE15.F.18 Hearing resolution – In case the answer is positive, the Tax Administration officer should run a system query to determine
approval whether the payment obligations of the main debtor were extinguished.
RE15.F.19 Hearing resolution – debts In case the debts of the principal debtor were extinguished, the measures for commencing the procedure
extinguished should be stopped.
RE15.F.20 Hearing resolution – debts In case the debts of the principal debtor were not extinguished, then the system should commence the
not extinguished procedure.
RE15.F.21 Hearing resolution – The system should allow the recording of claims for which there are two jointly liable taxpayers, without
multiplication of the claim multiplying the tax debt (the same debt to appear as a value into both taxpayer accounts).
RE15.F.22 Posting to the Taxpayer The decision upon the hearing should be posted within the Taxpayer Accounts Registry and the WEBSpace
Accounts Registry and account.
WEBSpace account
RE15.F.23 Outreach Program – The system should compose a short message alerting that there are new notifications and should send it to
Short message the taxpayer by preferred means.
RE15.F.24 Printing centre – The decision upon the hearing should be transposed into a document to be mailed to the taxpayer, based on
Preparing the document a predefined template.
RE15.F.25 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt signature or receiving it by the WEBSpace account.
RE15.F.26 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE15.F.27 Taxpayer risk history and The system should update the Taxpayer risk history and profile database.
profile database update
RE15.F.28 Document Management The decision should be stored in the Document Management database.

RE16 - Referral of the competent bodies

Section V. Requirements of the Information System 475

RE16.F.1 Definition of the deadline The system should allow the definition, within the dashboard, of parameters according to the legislation in
ID Name Description
for the limitation of the force.
debts
RE16.F.2 Identification of the The system should interrogate the databases that contain relevant information for the identification of the
debtors – System inquiry debtors and should generate a list of taxpayers that owe taxes and contributions subject to withholding older
than the deadline for the limitation the age of the debts.
RE16.F.3 Identification of The system should interrogate the modules/ databases that contain relevant information for the
compensatory amounts identification of amounts to be recovered by the taxpayer or of reimbursable VAT.
RE16.F.4 Notification – inexistent The system should generate a notification to the taxpayer by which he/ she will be notified regarding the
compensatory amounts need to perform payments in a pre-established deadline.
RE16.F.5 Compensation – existent The system identifies the compensatory amounts/ amounts to be refunded to the taxpayer and will proceed
compensatory amounts with the compensation against the taxpayer’s debts, until the settlement of the latter. In case the debts are
not settled entirely, the requirement RE16.F.4 should repeat.
RE16.F.6 Posting to the Taxpayer The decision upon the hearing should be posted within the Taxpayer Accounts Registry and the WEBSpace
Accounts Registry and account.
WEBSpace account
RE16.F.7 Outreach Program – The system should compose a short message alerting that there are new notifications and should send it to
Short message the taxpayer by preferred means.
RE16.F.8 Printing centre – The notification should be transposed into a document to be mailed to the taxpayer, based on a predefined
Preparing the document template.
RE16.F.9 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt confirmation or receiving it by the WEBSpace account.
RE16.F.10 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE16.F.11 Taxpayer risk history and The system should update the Taxpayer risk history and profile database.
profile database update
RE16.F.12 Document management The notification should be stored in the Document Management database.

RE16.F.13 Verification of the The system should electronically check whether the payment have been performed within the pre-
payments established deadline (e.g. 15 days).
RE16.F.14 Verification of the The system should generate a report comprising of the non-compliance with the pre-established deadline.
payments – Non-
476 Section V. Requirements of the Information System

compliance with the

ID Name Description
deadline – Report
generation
RE16.F.15 Verification of the The report should be electronically sent to the officers responsible with its review/ approval.
payments – Non-
compliance with the
deadline – report sent for
approval
RE16.F.16 Verification of the The taxpayers that fulfilled their obligations in due time should be automatically be excluded from the list
payments – fulfilling the of debtors.
deadline
RE16.F.17 Referral to the After the approval of the report from RE16.F.18, the system should generate a letter for referral to the
prosecution – Referral prosecution bodies.
sent
RE16.F.18 Referral to the The referral together with the Report from RE16.F.18 and with the list of taxpayers that have tax liabilities
prosecution – Document should be sent electronically (by e-mail and fax).
package sent
RE17 - Application of fines by the enforcement units
RE17.F.1 Definition of cases The system should allow the definition, within the dashboard, of the cases that are offenses, according to in
force legislation.
RE17.F.2 Inquiry The system should interrogate the databases/ modules that include relevant information for the
identification of those cases when the liabilities have not been fulfilled and for which fines apply.
RE17.F.3 Minute - Issuance The system should issue an offense minute that should comprise of the deeds for which the taxpayers was
penalised, and also the related fine.
RE17.F.4 Posting to the Taxpayer The offense minute should be posted within the Taxpayer Accounts Registry and the WEBSpace account.
Accounts Registry and
WEBSpace account
RE17.F.5 Outreach Program – The system should compose a short message alerting that there are new notifications and should send it to
Short message the taxpayer by preferred means.
RE17.F.6 Printing centre – The notification should be transposed into a document to be mailed to the taxpayer, based on a predefined
Preparing the document template.
RE17.F.7 Printing centre – option The system should allow the taxpayer to opt for taking the document from the tax administration, sending
the document by post mail with a receipt confirmation or receiving it by the WEBSpace account.
Section V. Requirements of the Information System 477

RE17.F.8 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
ID Name Description
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE17.F.9 Taxpayer risk history and The system should update the Taxpayer risk history and profile database.
profile database update
RE17.F.10 Document management The offense minute should be stored in the Document Management database.

RE18 - Write-off from tax records

RE18.F.1 Cases when the enforced The cases of ceasing the enforced collection are defined within the Dashboard by the relevant staff.
collection is ceased
RE18.F.2 Ceasing the enforced The system identifies the fulfilment of predefined conditions (e.g. small amounts, unsuccessful enforced
collection – write-off of collection measures) and ceases the enforced collection procedure.
debt
RE18.F.3 Ceasing the enforced The system generates a notice and the requirements from RE18.F.12 – RE18.F.21 are repeated.
collection –
Communication and
database update
RE18.F.4 Ceasing the enforced The system cancels/erases any administrative act issued previously and which stipulates payment
collection – obligations (principal and accessories), based on the irrevocable title regarding the total/partial cancel/erase
cancelled/erased of the writ of execution introduced into the system by the tax officer.
administrative act
RE18.F.5 Ceasing the enforced
collection – The system cancels the writ of execution.
cancelled/erased writ of
execution
RE18.F.6 Ceasing the enforced
collection – The system generates a notice and the requirements from RE18.F.12 – RE18.F.21 are repeated.
Communication and
database update
RE18.F.7 Ceasing the enforced
collection – Lifting the The system identifies the closing of debt and the enforced collection stops.
garnishment on third
parties
478 Section V. Requirements of the Information System

RE18.F.8 Ceasing the enforced The system generates a notice for the third party and the requirements from RE18.F.12 – RE18.F.21 are
ID Name
collection – Description
repeated both for the main debtor as well as for the third party.
Communication and
database update
RE18.F.9 Ceasing the enforced The system identifies the closing of debts and the enforced collection stops.
collection – Seizure of
goods
RE18.F.10 Ceasing the enforced
collection – The system generates a notice and the requirements from RE18.F.12 – RE18.F.21 are repeated.
Communication and
database update
RE18.F.11 Ceasing the enforced
collection – Lifting the The system identifies the closing of debts and lifts (updates the taxpayer’s status) automatically the
garnishment off the main garnishment.
debtor
RE18.F.12 Ceasing the enforced The system should automatically generate a message for lifting the garnishment off the taxpayer.
collection – Message
generated
RE18.F.13 Ceasing of enforced The message should be sent electronically to the respective banks.
collection – Sending the
message
RE18.F.14 Ceasing of enforced The message should be transposed into an address and sent to the Massive Printing Unit for being printed.
collection – Address
RE18.F.15 Ceasing the enforced The printed address should be sent to the banks officially by post, with receipt confirmation.
collection – Send by post
RE18.F.16 Posting the Taxpayer Lifting the garnishment should be posted into the Taxpayer Accounts Registry and WEBSpace account.
Accounts Registry and the
WEBSpace account
RE18.F.17 Outreach program – The system should compose a short message as regards the existence of new notifications and this should be
Short message sent to the taxpayer through the preferred means of communication.
RE18.F.18 Massive Printing Unit – The address for lifting the garnishment should be transposed into a document which should be sent to the
Preparing the document taxpayer, based on a predefined template.
Section V. Requirements of the Information System 479

RE18.F.19
ID Massive
Name Printing Unit - The system should allow the taxpayer to opt for taking the document from NAFA’s premises, for receiving
Description
Option it through post with receipt confirmation or for receiving it through the WEBSpace account.
RE18.F.20 Massive Printing Unit – If the above mentioned option has not been expressed or if the document has not been taken from NAFA’s
Send by post premises within a given timeframe, the document should be sent to the Massive Printing Unit to be sent by
post with receipt confirmation.
RE18.F.21 Taxpayer Accounts The system should update the Taxpayer Accounts Registry.
Registry update
RE18.F.22 Document management The address for lifting the garnishment should be stored into the Document Management database.

RE19 - Collection from/to other states

RE19.F.1 Identification of assets The system, based on external data sources, should identify any assets that belong to the taxpayer on which
that belong to the information was requested.
taxpayer
RE19.F.2 Response to request of Any information on the taxpayer should be communicated electronically.
information
RE19.F.3 Identification of taxpayer The relevant tax officer should initiate a system task.
– System task
RE19.F.4 Identification of taxpayer The system should launch the searching process previously initiated to identify the taxpayer within the
– Taxpayer identified Taxpayers Risk History and Profile database.
RE19.F.5 Identification of taxpayer In case the taxpayer has not been identified, the system should automatically create an account for the said
– Taxpayer unidentified taxpayer.
RE19.F.6 Recording the request for The request for notification (UNF) received from other states should be recorded in the system with the
notification identification of the taxpayer TIN and the amount to be recovered.
RE19.F.7 Taxpayer notification The details of the debt should be posted within the WEBSpace account and/or communicated on paper to
the taxpayer.
RE19.F.8 Recording the request for The request for precautionary measures together with the title that allows execution of the precautionary
precautionary measures measure (UIPE) should be recorded in the system.
RE19.F.9 Execution of The system should start the execution of the precautionary measures (garnishments and seizure of assets) as
precautionary measures for any other type of debt.
RE19.F.10 Recording the receivable The receivable together with the title that allows execution (UIPE) should be recorded in the system.
480 Section V. Requirements of the Information System

RE19.F.11
ID Collection
Name procedure The system should start the enforcement procedure as for any other type of debt, starting with the issuing of
Description
the summons.
RE19.F.12 Payment of collected All amounts collected on behalf of other States should be transferred to the institution that initiated the
amounts request for enforced collection.
RE19.F.13 Request for information The system should send a request for information on an individual/ entity to an institution from another
issued State.
RE19.F.14 Information recorded Information received together with the taxpayer’s receivable should be recorded in the system. The system
should allow for the registration of receivables of taxpayers which have their domicile/tax residency in
Romania. Also, the system should allow the registration of receivables for which two taxpayers are jointly
held responsible (e.g. one from Romanian and one from abroad), without multiplying the receivable (the
same receivable should not appear in both taxpayers’ evidences).
RE19.F.15 Request for notification The system should issue a request for notification, together with form UNF that shows the value and type of
issued debt.
RE19.F.16 Notification A record of the communication of the notification by the relevant institution of the State to the taxpayer
communicated should be kept in the system.
RE19.F.17 Request for precautionary The system should issue to other States a request for precautionary measures, based on a Note for
measures precautionary measures execution.
RE19.F.18 Execution of The execution of the precautionary measure should be recorded in the system.
precautionary measures
RE19.F.19 Release of precautionary The release of the precautionary measure should be issued from the system to the institution from the other
measures State that executed the measure.
RE19.F.20 Request for enforced The system should send to any State a request for enforced collection for a debt under a writ of execution
collection already issued, together with the writ of execution and the form UIPE. For more information please refer to
step RE06
RE19.F.21 Payment of debt The payment, when received, should be allocated to the taxpayer account.

RE20 - Enforced collection reporting

RE20.F.1 Automated job start The system should start a data collection job at a specific time defined by a parameter set on the Dashboard
by Tax Administrators.
Section V. Requirements of the Information System 481

RE20.F.2
ID Ad-hoc
Name jobs The system should run any reports predefined by NAFA when the
Description
Tax Administration officer initiates a job.
RE20.F.3 Daily data handling – Reports should become documents in .PDF format.
.PDF
RE20.F.4 Daily data handling – Reports should be sent to recipients by email, with .PDF attachments.
Email
RE20.F.5 Daily data handling – .PDF documents should be encrypted with passwords to open the attachments.
Encryption
RE20.F.6 Document Management All reports emailed to managers should be stored in Document Management database for retrieval by
management when required.
RE20.F.7 System resource sizing Systems statistics should be used to determine the size and number of queues needed to avoid bottlenecks in
the system.
RE21 - Management and sale of seized goods

RE21.F.1 Seizure of goods After drafting the recording of proceedings specified at RE17.F.3, the goods are seized.

RE21.F.2 Registering the goods in The system registers the goods within NAFA’s evidences.
NAFA’s evidences
RE21.F.3 Goods categories - When introducing the goods into NAFA’s evidences, the taxpayer should select from a rolling box the
Selection category of each good.
RE21.F.4 Goods categories - Alerts The categories from the rolling box should be connected to a module for generating alerts to relevant
institutions (if the case). More specifically, for goods with special regime (e.g. weapons, medicine, etc.)
alerts are generated to the relevant institutions (e.g. NBR, Police, etc.). Similarly, in case of perishable
goods alerts are generated to entities specialised in their selling.
RE21.F.5 Goods entered into the The system should check the fulfilment of the deadline (predefined within the Dashboard) up to which
state’s property – complaints may be received.
Checking the term
RE21.F.6 Goods entered into the The system should send an alert to the designated tax officers as regards the goods entered into the state’s
state’s property – Alerts property.
RE21.F.7 Sellable/Unsellable goods The system should send alerts to the Commission’s members who are in charge with analysing the status of
– Commission for analysis the goods.
of goods status
482 Section V. Requirements of the Information System

ID Name Description
RE21.F.8 Unsellable goods – For goods which cannot be sold or processed, the system should send alerts to the designated tax officers
Destroyed goods responsible with the destroying procedure.
RE21.F.9 Sellable goods – Record of For goods which can be sold or processed, the system should issue a record of proceedings which should be
proceedings sent to the Unit responsible with selling the goods.
RE21.F.10 Evaluation of goods – The system should check the fulfilment of the deadline (predefined within the Dashboard) and afterwards
Deadline check should commence the goods valuation procedure.
RE21.F.11 Evaluation of goods - The system should send an alert to the members of the Commission for goods valuation for a meeting.
Alert
RE21.F.12 Publishing goods for The system should scan the inventory daily and should publish for auction all goods older than a pre-
auction defined number of days, which are not yet sold or returned to the debtor. The posted announcement should
contain all information related to the good, which is relevant for the sales process and/or is required by law.
RE21.F.13 Publishing goods for The auction duration, start date and time should be automatically posted (a defined number of days from the
auction – auction posting moment), as well as the registration deadline and conditions (there should be a link to the relevant
information chapter in the auction rules, which should be available online on the same platform).
RE21.F.14 Publishing goods for One auction should be organised for one item (good / group of goods) having a unique ID. All operations
auction – Auction file related to the respective auction should be stored in the auction file, identified by the ID of the good and the
number of the auction (first, second, third).
RE21.F.15 Registration for auction To participate in the auction, each potential bidder should create an account on the website, defining a
username and password and should input all necessary identification, contact and bank account information.
Requirements in terms of security should be identical with those for creating the taxpayer's webspace.
RE21.F.16 Registration for auction – The system should display the terms and conditions of the process and should request the bidder's
terms and conditions acknowledgement and agreement before proceeding to the next step.
RE21.F.17 Registration for auction – Each user should receive a unique ID, connected to the TIN/PIN, which should be used and disclosed in the
Unique ID auction process. The same ID should be used in future auctions.
RE21.F.18 Registration for auction – The website should be connected to a certified online payment facility.
Online payment
RE21.F.19 Registration for auction – Payment should be done in one transaction.
One payment
RE21.F.20 Registration for auction – The system should not authorise the finalization of the payment process if the deadline for registration has
rejected payment passed (i.e. 24 hours before the start of the auction) or if the same user has made another payment for the
same auction.
Section V. Requirements of the Information System 483

RE21.F.21
ID Registration
Name for auction – Once the payment is confirmed, the system should post the ID of the registered bidder in the auction file
Description
registration posting and in the bidder's account.
RE21.F.22 Registration for auction – The system should send a notification to the bidder confirming the registration.
confirmation of
registration
RE21.F.23 Bidder's risk history Each bidder’s activities should be recorded in a risk history and activity database

RE21.F.24 Auction login The bidders should be logged with the user name and password and should access the specific auction page
to participate.
RE21.F.25 Parallel auctions The system should allow participation of the same user to multiple auctions in parallel.

RE21.F.26 Auction rules Specific rules for the auction should be visible on the auction page (i.e. bidding steps).

RE21.F.27 Auction opening At the announced date and time the system should launch the auction with the starting price posted in the
announcement, only if there is at least one participant.
RE21.F.28 Bidding – offer posting All active bidders should post their offer which cannot be lower than the starting price.

RE21.F.29 Bidding – list of offers The list of offers should be updated in real time and posted in descendant order.
update
RE21.F.30 Bidding – steps If there are bidding steps defined, the system should not allow postings lower than the thresholds defined by
ANAF (i.e. percentage or amount).
RE21.F.31 Auction – physical The enforcement offices should be able to introduce the offers of more participants that are no logged in
presence directly, using a special interface.
RE21.F.32 Auction closing The auction should be closed if within three minutes from the last call no other higher offer is posted. The
closing should be clearly posted.
RE21.F.33 Auction winner When the auction is closed, the system should post the winning offer, the ID of the winner and the full
hierarchy of offers.
RE21.F.34 Unsuccessful auction If there are no attendants/no offers, the auction should be declared unsuccessful.

RE21.F.35 Unsuccessful auction – The enforced collection officer should be notified so that next auction should be authorised. The proposed
notifying the enforced time, date and starting price are included in the notification. No more than two additional auctions can be
484 Section V. Requirements of the Information System

ID Name Description
collection officer organised.
RE21.F.36 Next auction The system should send an authorisation request. The manager either authorises the next auction as
authorisation proposed by the system or suggests new time and price, but no later and no less than the price provided by
the system. In the second case, the authorisation needs to be reviewed by a supervisor.
RE21.F.37 Online payment The website should be connected to a certified online payment facility. The amount should be determined
by the system deducting the registration fee(s).
RE21.F.38 Rejected payment The system should not authorise the finalization of the payment process if the deadline has passed (i.e., 48
hours before the start of the auction) or if the amount is not the correct one.
RE21.F.39 Bank transfer In case the buyer wishes to pay by bank transfer (in defined cases for large amounts), the system should
issue a pro-forma invoice containing all necessary information for the payment order, based on the buyer's
request. There should be a separate Treasury account for such payments to avoid confusions with other
types of payments.
RE21.F.40 Bank transfer – payment The system should allow posting of the payment proof within 48 hours from the moment of payment.
proof
RE21.F.41 Prolonged payment term The system should allow extension of the deadline if authorised by an enforced collection Manager.

RE21.F.42 Payment in instalments The system should allow payment in instalments provided that this is authorised by an enforced collection
manager, and if certain conditions are met, in which case the system should compute and post the value and
deadline of each instalment.
RE21.F.43 Payment confirmation When the payment is confirmed, the system should send a notification to the buyer.

RE21.F.44 Payment confirmation – The system should compile once a day reports for each enforced collection officer with their assigned cases
manual check where manual checks (i.e. payment proofs) are required and so that the officer should confirm the payment.
RE21.F.45 No payment – lost auction The system should detect the online payments and if no payment is recorded and there is no attached
payment proof, it should notify the bidder that the winner status was lost.
RE21.F.46 No payment – new winner In case there are other offers, the system should notify the next bidder that he/she is the winner (if such
intention was expressed) and that he/she can pay within a defined period of time.
RE21.F.47 Ownership change The system should issue the ownership change decision and send it to the assigned collection officer, which
decision is responsible for delivering it to the buyer.
RE21.F.48 Ownership change The system should notify the buyer by agreed means that a document was issued and the good is ready for
decision – buyer delivery. The information about location and terms and conditions of delivery should be included.
notification
Section V. Requirements of the Information System 485

RE21.F.49 Posting to the Taxpayer Once the ownership change decision should be issued, it should be posted to the Taxpayer Accounts
ID Name Description
Accounts Registry and Registry and on the WEBSpace account.
WEBSpace account
RE21.F.50 Outreach Program – The system should compose a short message indicating the ownership change and send it to the taxpayer by
Short message means preferred by him/her.
RE21.F.51 Recalculating liabilities The system should recalculate the liability based on the payment value.

RE21.F.52 Update of the History and The system should update the History and risk profile database.
risk profile database
RE21.F.53 Document management Information mentioned above should be stored in the Document management database.

RE21.F.54 Printing centre – Mailing Relevant documents should be generated by the system to be printed and sent by post mail to the buyer.

RE21.F.55 Printing centre - Option The system should allow the taxpayer to opt for taking the document from NAFA’s premises, receiving it
through post with receipt confirmation or receiving it through the WEBSpace account.
RE21.F.56 Printing centre – Send by If the above mentioned option has not been expressed or if the document has not been taken from NAFA’s
post premises within a given timeframe, the document should be sent to the Printing centre to be sent by post
with confirmation receipt.
RE21.F.57 Options for the The system should notify the bidder who lost the auction to opt for reimbursement methods (using the fee
reimbursement of the as credit for other auctions or reimbursement via the same bank account).
participation fee
RE21.F.58 Participation fee The system should automatically proceed according to the participant's option.
reimbursement
RE21.F.59 Failed auction After 3 unsuccessful auctions, the system should declare the auction as being unsuccessful.

RE21.F.60 Transfer of property to If the good is not sold during the statute of limitation period, the system should notify the enforced
the state collection officer to start the procedure for transfer of the property to the state.
RE21.F.61 Free allocation of goods The free allocation of goods, previously agreed with the relevant institutions should be posted within the
Taxpayer Accounts Registry and WEBSpace account.
RE21.F.62 Outreach program – The system should compose a short message as regards the change in property (free allocation of goods) ant
Short message the message should be sent to the taxpayer through the preferred means.
486 Section V. Requirements of the Information System

RE21.F.63
ID Update
Name Taxpayers Risk The system should update the Taxpayers Risk History and Profile database.
Description
History and Profile
RE21.F.64 Document management The information mentioned above should be stored in the Document Management database.

RE22 - Application of international sanctions

RE22.F.1 Notification Obligation Where the case (e.g. for resident persons registered into the system or for the non-residents from states with
which Romania has agreed automatic exchange of information) the systems should receive the notification.
RE22.F.2 Exemptions and A person files electronically (by the system) a request for exemption. The request should be backed-up by
notifications of errors of relevant documents.
identification - Filing
RE22.F.3 Exemptions and The request is sent to the Ministry of External Affairs for providing compliance endorsement with
notifications of errors of international law.
identification –
compliance notice
RE22.F.4 Exemptions and The case should be analyzed and the response should be sent electronically (in cases mentioned in
notifications of errors of RE22.F.1).
identification – Response
RE22.F.5 Posting the Taxpayer For residents, the answer related to the request for exemption and the referral should be posted into the
Accounts Registry and the Taxpayer Accounts Registry and the WEBSpace account
WEBSpace account
RE22.F.6 Outreach program – For residents, the system should compose a short message alerting that there are new notifications and
Short message should send it to the taxpayer by preferred means
RE22.F.7 Printing centre – For residents, the answer related to the request for exemption and the referral should be transposed in
Preparing the document documents that should be sent to the taxpayer, based on a predefined template.
RE22.F.8 Printing centre – option For residents, the system should allow the taxpayer to opt for taking the document from the tax
administration, sending the document by post mail with a receipt confirmation or receiving it by the
WEBSpace account
RE22.F.9 Printing centre – sending If the option above was not expressed or if the document was not picked up from the tax administration
by post mail within a certain deadline, this should be sent to the Massive Printing Centre to be further sent by post mail,
with a receipt confirmation.
RE22.F.10 Taxpayer risk history and For residents, the system should update the Taxpayer risk history and profile database.
profile database update
Section V. Requirements of the Information System 487

RE22.F.11
ID Document
Name management For residents, the answer related to the request for exemption and the referral should be stored in the
Description
Document Management database.
RE22.F.12 Order for freezing of The Legal Directorate should receive electronically the order of the Ministry of Finance by which freezing
funds and economic of funds and economic resources is disposed.
resources - Reception
RE22.F.13 Order for freezing of The order is sent to the DGRCCB which should further send it on to the responsible Territorial Tax office.
funds and economic
resources - Sending
RE22.F.14 Application of the The functional requirements of the process RE07 should repeat.
freezing order -
Garnishment
RE22.F.15 Application of the The functional requirements of the process RE08 should repeat.
freezing order - Seizure
RE22.F.16 Application of the Functional requirements from RE22.F.5 to RE22.F.12 should repeat.
freezing order -
Communication
RE22.F.17 Freezing order - Following the compliance with the release deadline, the system should send the order to be published by the
Publishing Official Gazette.
RE22.F.18 Revoke the freezing The revocation request is submitted electronically or in person (is entered manually into the system), along
measure – submitted with any other required documents.
request
RE22.F.19 Revoke the freezing If the request is approved, the system should automatically cancel the freezing.
measure
RE22.F.20 Revoke the freezing Functional requirements from RE22.F.5 to RE22.F.12 should repeat.
measure –
Communication
RE23 – On-line auctions
RE23.F.1 Publicity MUST provide functions to automate publicity and transactions with goods from enforced collection, seized
goods and other categories of goods (like old ANAF equipment for disposal), over secured Internet.
RE23.F.2 Integration MUST integrate with the Taxpayer Registration, Internet Portal, Intranet Portal and Identity Management
and Access Management components, to provide unique identification, secure and auditable activity logs
for the participants to the on-line auctions of ANAF.
488 Section V. Requirements of the Information System

RE23.F.3
ID Authentication
Name MUST authenticate and log-in the participants to the on-line auctions in e-auction rooms, over the Internet
Description
and the Intranet or from auctions room located on the premises of ANAF, over the Intranet.
RE23.F.4 Role Management MUST provide at least the following roles for the participants: bidders, auction president (only one
participant), lead-secretary (only one participant for the e-auction room), secretaries (at least one for each
auction room), independent witnesses, and auditors.
RE23.F.5 Electronic Signature MUST authenticate the participants at least with user name, password and qualified digital certificate, in
order to sign the auction documents (i.e. auction terms and conditions, consent for the processing of the
personal data, auction forms, and auction session minutes) during the trade session.
RE23.F.6 Electronic Signature for MUST authenticate the public servants appointed by ANAF for the roles of president, lead-secretary,
Elevated Access secretaries, and auditors with digital certificates provided by the ANAF internal certification authority.
RE23.F.7 Audit Trail MUST log with certified time stamp and digital signature all the activities of the participants, in an
auditable activity log and in the auction session minutes document.
RE23.F.8 Logging and Workflow MUST time on all the phases and steps of the auction, locking and unlocking the processes as per the
auction scenario in place.
RE23.F.9 MUST interface with Revenue Enforcement functional module and with the Document Management
System, to import the information regarding the goods on sale from the auction case folder into the
publicity and the transaction.
RE23.F.10 Data Sharing MUST interface with the Revenue Enforcement functional module and with the Document Management
System to export the results and the logs of the auction (i.e. all the auction documents digitally signed,
transactions logs, activity logs, image and sound captures from the physical auction rooms on ANAF
premises, etc.).
RE23.F.11 External Document MUST interface with the WebSpace to post information for the taxpayers enrolled or participating in e-
Uploading auctions and to collect the documents uploaded by the taxpayer to enrol for the e-auctions.
RE23.F.12 Payment Check MUST interface with the Taxpayer Accounting functional module to check the payments made for the
participation security and/or participation fee, for the payments of the adjudicated goods, etc.
RE23.F.13 Workflow Management - MUST implement auction workflows compliant with the regulations in place at least forward e-auction, for
Regulatory non-perishable goods (e.g. fixed assets, equipment, cars, real-estate goods – houses and land, etc.), for
perishable goods (food, beverages, etc.) and low value goods.
RE23.F.14 Auction Types MUST supply support for other types of e-auction like reverse auction, Dutch auction, English auction, etc.

RE23.F.15 Bidding Confirmation MUST implement a secured mechanism to make all transactions non-reputable, with the step-by-step
granularity.
Section V. Requirements of the Information System 489

RE23.F.16 Technical Computing The Supplier MUST provide all the details about the necessary technical computing platform, including
ID Name Description
Platform special security equipment and software, if any – to implement and secure the On-line Auction platform
delivered.
RE23.F.17 Audit Trail (logging) MUST collect audit logs for further compliance audit.

RE23.F.18 User Interface (features) MUST provide functions to manage the events that may happen during the e-auction session (i.e.
presentation of the participants, participant unexpectedly leaves the auction room, technical incidents,
printing documents like auction minutes for the participants, collect the one time credentials of the
participants – user name, password, unique code to participate in the auction, etc.,).
RE23.F.19 Auction Debriefing MUST distribute notifications and documents regarding the results of the auctions, the upcoming auctions,
the goods to be auctioned again at discounted starting price, etc.
RE23.F.20 Public Notifications MUST disseminate information regarding the goods to be auctioned via a public web section, linked in the
ANAF public portal and via a public RSS feed – to largely advertise the goods on sale, the auction sessions
planned, and the terms and conditions for the participants.
RE23.F.21 Public Reminders MUST disseminate reminders to the participants enrolled in the e-auction platform via e-mail and WEB,
regarding the goods on sale and on re-sale, the auction sessions planned, the auctions cancelled, the
custodians contacts for site visits and goods preliminary inspections, etc.
RE23.NF.22 Management Information MUST collect and push statistical information into the MIS, for further analysis.
System
RE23.NF.23 Communications MUST provide secured and encrypted communication sessions over the Internet for all the participants on-
Encryption line (using protocols like https, encryption with X.509 certificates, RSA, TSL 1.3, 3DES, and secured
combinations of ciphers like AES GCM, AES CCM, AES CBC, etc.).
RE23.NF.24 Unsecure MUST reject all the unsecure communications protocols (like SSL 1.0, SSL 2.0 and or SSL 3.0).
Communications
Rejection
RE23.NF.25 Cyber Security MUST provide protection for cyberattacks (like Man-in-the-Middle (MITM), renegotiation, version
rollback, BEAST, CRIME, BREACH, POODLE, timing, RC4, FREAK, Logjam, Heartbleed and BERserk,
etc.,).
RE23.NF.26 Cyber Security MUST utilize ANAF’s Internet security system. (See Informational Annex 4 for details.)

RE23.NF.27 Locale Settings MUST provide a visual user interface in the Romanian and English Languages.
490 Section V. Requirements of the Information System
Section V. Requirements of the Information System 491

9 – TAXPAYER AUDIT (AU)

ID Name Description
AU01 – National Audit Planning
AU01.F.01 Reminder for New The system should be able to create reminder to the authorities to start the annual audit program.
Audit Cycle
AU01.F.02 Rule Setting System should enable setting rules on all the parameters, criteria, profiles and benchmarks as suggested by the
NAFA. At the same time, System should facilitate NAFA objectives and the tax audit integration, as stipulated in
strategy and in compliance with the Fiscal Procedure Code in respect of tax audit
AU01.F.03 Identification of Audit The system should be able to utilize the Risk Scoring Module to generate the selection of audit candidates
Cases according to the criteria, parameters, profiles or benchmarks designed by NAFA i.e. at national, regional and
county level.
AU01.F.04 Historical Data The system should maintain the history and results of previous years’ audit.
AU01.F.05 Historical Data The system will maintain the historical records of all legacy audit cases undertaken before the implementation of
RMS system. The Purchaser will be responsible to correct the data quality problems regarding the historical
records of all the audit cases undertaken before the implementation of the System, like missing information,
multiple records, other as per the case.
AU01.F.06 Audit Time The system should be able to record the audit time budget which can be compared with the actual time charged
Stipulation during the audit execution.
AU01.F.07 Staff availability The system should have a staff availability module that contains information about:
module - the employee
- specialization
- grade / seniority level
- calendar and status / period (available, not available - fully booked, on vacation, partially available - %
availability)
AU01.F.08 Employee Notification The system should notify the employee and his manager on the job allocation.
AU01.F.09 Employee Availability The system should change employee status in the employee availability list from available to be assigned for the
Status estimated duration of the project.
AU01.F.10 Consolidation of local The system should be able to consolidate the approved local audit plan and to generate regional audit plan.
audit plan
AU01.F.11 The system should allow developing monthly, quarterly, biannual and annual programs
AU01.F.12 Modification in The system is able to modify the National Annual Audit Plan and to record each modifications activity in the
National Audit Plan secure log.
AU01.F.13 Modification of audit The system should allow the modification of regional and county programs and the modification of monthly,
492 Section V. Requirements of the Information System

ID Name Description
programs quarterly, biannual and annual programs
AU01.F.14 Section of control The system should allow selection (automatic / manual) of the type of control through the identified risk of a
taxpayer or authorized individual requests received will be treated, namely by:
- General tax audit
- Partial tax inspection
- Unannounced
- Cross-check
- Research on the spot
- Fiscal Verification of the Individuals using the indirect method
AU02 – Auditee Selection
AU02.F.01 List of Taxpayers- The system should be able to create list of potential tax revenue from the highest to the lowest which will need to
Highest to Lowest perform audit (segmented by types of taxpayers, industries, types of taxes, etc.)
AU02.F.02 Identification of The system should transmit to the tax audit department lists of taxpayers with fiscal risk in terms of tax audit. At
taxpayers with fiscal the same time the system should not allow the transmission of lists of taxpayers who were categorized in fiscal risk
risk category but who are not subject to a tax audit.
AU02.F.03 Flagging of cases by The system should allow an authorized user to manually select cases – which are strictly to be subjected for tax
Authorized user audit - for audit on basis of cases flagged for discrepancy or mis-match.
AU02.F.04 Discrepant cases System should be able to flag cases – which are strictly to be subjected for tax audit - of discrepancy, mismatch,
incorrectness or incompleteness in data
AU02.F.05 Noting The system should be able to record the notes when the recommended candidates does not selected by the NAFA
Management
AU02.F.06 Risky Taxpayer System should generate summary of risky taxpayers data filed based on characteristics like region, trade sector,
Summary risk level, etc.
AU03 – Auditor Selection
AU03.F.01 Standards A standard format/ template of notification to auditee and authorization letter should be developed. Such standard
Requirement templates / formats are tax audit forms approved by order of NAFA.
AU03.F.02 Authorization of User The system should allow an authorized user to enter key audit details.
AU03.F.03 Routing of Cases System should allow routing of cases between available and designated officers and staff members.
across Hierarchy
AU03.F.04 Allocation of audit The system should allow allocation of cases depending on risk level and the workload for both inspectors and tax
cases inspection structure. The system should allow supplement / modification / replacement of tax audit team members.
AU04 – Audit Scheduling and Budgeting
AU04.F.01 Transfer of Cases The system should be able to electronically transmit the validation from each local offices to Audit Preparation
Section V. Requirements of the Information System 493

ID Name Description
from Local offices Committee that the notification has been received and to confirm the availability of auditors
AU04.F.02 Conformance to the The system should allow tax audit team to confirm that it is conducting of the tax audit as per the existing available
available Human Human Resource capacity and in terms of other priorities
Resources capacity
AU04.F.03 Allocation of audit If a particular region is not able to complete the audit cases assigned, system should allow the allocation of such
cases to other region cases to other regions provided they have available human resource capacity.
AU04.F.04 Audit Schedule The system should be able to record the audit schedule for each auditor.
AU04.F.05 Auto Notification The system should be able to generate and send the automatic notification regarding the Assignment, schedule and
logistic availability status to each auditor through a defined communication channel
AU04.F.06 Alert Generation for The system should be capable of generating alerts to appropriate authorities in case:
Open Cases  Cases to be selected for audit are not initiated
 Cases selected for audit are not concluded
 Cases selected for audit are not concluded within prescribed time limit
If any audit case is suspended, such cases should be excluded from this alert.
AU05 – Audit Preparation
AU05.F.01 Save Steps and System should enable internal user to save the steps and queries used for analysis as template for future use
Queries
AU05.F.02 Tax audit file The system should ensure the development of a tax audit file preparation (data about taxpayers, statements,
preparation inconsistencies, prior checks, etc.
AU05.F.03 Audit of Un- The system should have provision for audit of un-registered taxpayers and cases identified by NAFA.
registered taxpayers
AU05.F.04 Analysis Techniques System should support identification of common patterns / factors / profile characteristics that could enable
selection of criteria for selection of Audit cases
AU05.F.05 Audit Orders System should be able to generate audit orders with assessing authority inputs.
AU05.F.06 Internal Interface The system should be able to access Document Management System and other database to retrieve all auditee's
Requirement related information and attach into Audit Case Folder.
AU05.F.07 Information capture The system should ensure the documentation of all information from the taxpayer registration, returns, appeals,
decisions of courts, criminal investigations, controls of other control bodies within NAFA, foreclosures, ROI,
reimbursements, etc., and information based on NAFA external data access.
AU05.F.08 Audit Program The system should be able to assist in generating the Audit Program for the upcoming audit cycle.
AU05.F.09 Audit schedule The Audit Schedule, List of Auditor, Audit Program, List of Required Document and the Logistic Checklist should
be able to be attached into the Case Folder
AU05.F.10 Audit plan The system should be able to assist in generating Audit Plan
494 Section V. Requirements of the Information System

ID Name Description
AU05.F.11 Sorting of Notices System should allow for sorting of audit notices based on taxpayers, type of notice, date of notice etc.
AU05.F.12 Flagging of unread System should flag notice/order which are not read by the taxpayer within prescribed number of days for manual
notice / order service
AU05.F.13 Pending audit System should maintain in taxpayer WEBSpace account the status of his previous and ongoing audits
AU06 – Taxpayer Audit
AU06.F.01 Notification of The system should send e-mail to the taxpayer notifying him that he is selected for audit as well the results of the
identified audit cases audit procedure. Also the same should be made available at Taxpayer WEBSpace.
AU06.F.02 Activity Checklist The system should provide a facility to provide checklist which updates the status of audit activities.
AU06.F.03 Working Paper The system should provide a facility to complete the Working Paper.
AU06.F.04 Audit Resolution The system should be able to record the Audit Resolution document as input by auditors
AU06.F.05 Document Submission System should provide facility for online submission of documents by the taxpayers for audit
AU06.F.06 Analysis and System should be able to provide the requisite arithmetic and analysis tools for aiding the preparation of audit
Arithmetic Tools Report. For example, automatic calculation of accessories, penalties, differences of additional amounts on certain
periods, etc.
AU06.F.07 Sample based tax The system should allow the establishment of a sampling method and automatic calculation of the checked sample.
audit
AU07 – Audit resolution
AU07.F.01 Update of data The system should allow updating date and other details of response received against a particular notice
AU07.F.02 Notifying Assessed The system should mark as deemed assessed, all cases not selected for scrutiny under any criteria or manually by
Cases authorized user
AU07.F.04 Flagging Closed Cases In case the audit Order shows no liability from the taxpayer's end, the system will allow tax audit unit to issue “no
liability” notice and close the case
AU07.F.05 Sign Audit Findings The system will record the audit report and decision into Taxpayer WEBSpace and Audit case folder.
AU07.F.06 Re-opening of cases If allowed under the law, the system should have provision to re-open the cases for re-audit / rectification/ remand
cases even if the status of cases is closed
AU07.F.07 Repetition of Saved System should have provision to repeat saved analysis in templates automatically at regular intervals of time
Analysis
AU07.F.08 Integration System should automatically post demand created in audit to the enforcement module
AU07.F.09 Repetition of Saved System should have provision to repeat saved analysis in templates automatically at regular intervals of time
Analysis
AU08 – Audit quality assurance
AU08.F.01 Retrieve Audit Case The system should be able to retrieve any Audit Case Folder by inputting the customizable criteria, parameters,
Section V. Requirements of the Information System 495

ID Name Description
and profile
AU08.F.02 Re-audit Cases The system should have re-audit, Provisional audit and revision of audit modules
AU08.F.03 Electronic Workflow The system should be able to generate electronic workflow for review and approval.
AU08.F.04 Assurance Report The system should provide the facility to record the Approved Quality Assurance Report.
AU09 – Monitoring and Reporting
AU09.F01 Quantitative and The system should allow developing, monitoring and reporting of quantitative and qualitative performance
qualitative indicators.
performance
indicators
AU09.F02 Development of The system should allow development of possible scenarios based on various criteria (types of inspections,
scenarios taxpayers, types of actions, time, structure, types of findings or keywords, etc.) and enable graphical
representations wherever possible.
The system should allow users / administrators to create possible scenarios based on drag & drop system.
AU09.F03 Electronic The system should allow electronic transmission of the tax inspection file and payer form (sheet) to administration
transmission of the department.
tax inspection file
AU09.F04 Data exchange with The system should allow data exchange with other modules (e.g. Information on actions taken by anti-Fraud,
other modules payment status due to tax audits, tax audits due to contested amounts, the appeals stage, the stage reached in court
cases, the allegations of criminal investigation, etc.
AU09.F05 Alerts The system should allow alerts for tax inspection throughout the inspection process, starting with planning,
programming, and implementation to completion.
AU09.F06 Editing and The system should at the completion of any kind of control to allow editing and communication of all documents
communication of related to that control – e.g. fines, criminal complaints, precautionary measures, provision of measures,
control inactivation, fiscal records, reports of settling disputes, transmission of documents to other institutions, various
proposals of the control (tax audit proposal-unannounced control or cross control).
AU09.F07 Exchange of The system should allow the exchange of information with risk analysis module to assess and treat risks.
information with risk
analysis module
AU10 - General Requirements
AU10.F.01 Editing of documents The system should allow editing and issuing of the documents that are used during tax audit.
AU10.F.02 Use of master data The system should allow creation of master data and using the same to fill certain fields automatically. E.g.
- Notifications / approvals (interconnection with the HR database - ONIX)
- Inspectors (HR database - ONIX
496 Section V. Requirements of the Information System

ID Name Description
- Counties / regions
- Types of actions fiscal inspection
- Types of laws
- Acts
- Types of companies
- Type of ownership
- Selection criteria
- Activity
- Types of taxes / duties
- Types of inspection documents
- Places control
- Applicants actions.
AU10.F.03 Tax audit as per The system should allow selection, scheduling and conducting tax audit only as per the provisions of the fiscal
Fiscal Procedure procedure code.
Code
AU10.F.04 Creation of integrated The system should ensure the creation of an integrated framework of risk analysis, selection, planning,
framework implementation, monitoring, reporting and evaluation of the tax inspection.
AU10.F.05 Automatic selection of The system should allow automatic selection of cases / taxpayer for tax audit according to tax risk.
cases / taxpayer
AU10.F.06 Risk analysis and On monthly basis, the system will select taxpayers for the audit on the basis of risk analysis,
selection of taxpayers
for audit
AU10.F.07 Document handling The system should provide editing, transmission, storage and archiving of all documents used in tax audit.
AU10.F.08 User friendly The system should ensure a user-friendly interface and provide increased efficiency, effectiveness and quality of
interface tax inspections acts.
AU10.F.09 reporting of all checks The system should ensure the automatic and reporting of all checks completed or currently underway by units
entrusted with tax audit of the NAFA.
AU10.F.10 Electronic The system should ensure electronic transmission of the tax audit report and providing information on the amount
transmission of the received, the impugned acts, the status settlement in court.
tax audit report
AU11 – Fiscal Verification for Individuals
AU11.F.01 Tax Audit for the The system must allow the selection for taxpayer audit of all categories individuals. A complete workflow for the
individuals using the fiscal verification of the individuals must be implemented, including case opening, case management, risk analysis,
indirect verification fiscal verification of the individual using the indirect method, case resolution, and case archiving.
Section V. Requirements of the Information System 497

ID Name Description
method In this case functional requirements above regarding AU02. Auditee Selection, AU03. Auditor Selection, AU04.
Audit Schedule, AU05. Audit Preparation, AU07. Audit Resolution are applicable to auditees which are
individuals in this workflow.
AU11.F.02 Risk analysis - The system must provide functionality to call the risk analysis subsystem to the risk associated to the individuals
Balance the income using a comparative balance of the amounts spent by each individual, based on the information from the ANAF
and the amounts internal databases, information form the financial institutions (e.g. lists of bank transactions, bank deposits,
spent for risk analysis insurance, capital and securities transactions, etc.), information from open sources, versus the reported income of
centered on the individual, for a certain fiscal period of time.
individuals
AU11.F.03 Interfacing with other The System must interface with the existing application PATRIVEN. MUST interface with the Returns Processing
applications (RP) functional component to extract data regarding the reported income of the individual, the amounts spent for
acquisition of land and other assets and to extract data from the financial statements of the companies related with
the individuals.
AU11.F.04 Risk analysis for The system must provide functionality to build risk analysis for structural risk items in a SWOT format, using
structural risk items information like up/downturn of the capital markets, the evolution of the securities and derivatives market, and the
impact of the changes in the structural risk items on selected categories of individuals (like High Networth
Individuals, other). The system must provide functionality to build, manage and file risk plans for voluntary
compliance.
AU11.F.05 Manage case(s) for The system must provide functionality on the workflow for fiscal verification for indviduals for specific risk
the fiscal verification assessments based on the evaluation of uses of funds compared to the declared income of individuals, selection
based on indirect according to the risk hierarchy so determined, documented preliminary fiscal verification, verification of taxes and
method establishing taxation base by using one of the formal indirect methods.
The system must at the completion of any kind of fiscal verification to allow editing and communication of all
documents related to that verification – e.g. risk analysis results, income/spending balances, evidences, fines,
criminal complaints, precautionary measures, provision of measures, inactivation, fiscal records, reports of settling
disputes, transmission of documents to other institutions, various proposals of the fiscal verification, etc.
AU11.F.07 Build fiscal The system must prepare the draft fiscal verification report using the information collected by the steps above. The
verification report – fiscal auditor must fill in his/her conclusions and recommendation for the case solutioning. The case must be
Step 1 advanced on the workflow to the decision maker, when the draft report is complete.
AU11.F.08 Decision on the case(s) The system must implement a decision delegation scheme, by categories of cases, amounts identified, skills and
professional experience of the decision makers with similar cases. The system must assist the decision maker with
a summary of the case showing the inconsistencies, discrepancies and other information flagged as important by
the auditor. The system must capture the decision on the case – which may be either to continue with the new fiscal
obligations calculated by the indirect method, either to stop the workflow, because there is nothing to do with the
individual under verification.
498 Section V. Requirements of the Information System

ID Name Description
AU11.F.09 Notification of the The system must generate and send the automatic notifications to the Parties (Tax Payer and Local Tax
parties (tax payer, tax Adminstration office) regarding the decision and the associated fiscal obligation (in detail) through a defined
administration local communication channel (like WebSpace and e-mail for the Tax Payers enrolled on the ANAF portal, post mail via
office) the Massive Printing Unit, fax, other as applicable.
AU11.F.10 Archive case in the The system must store and archive the case folder with all the associated documents in the Document Management
Document System.
Management System
AU11.F.11 Quality Assurance The system must implement functionalities for quality assurance similar to AU08.F.01Retrieve Audit Case,
functions AU08.F.02 Re-audit Cases, AU08.F.03 Electronic Workflow, and AU08.F.04 Quality Assurance Report for the
Fiscal Verification for Individuals workflow.
The system must provide operative reports for the management.
The system must collect and push statiscal information abou the cases processed and the activities performed to the
data warehouse and the MIS.
Section V. Requirements of the Information System 499

10 – ANTI-FRAUD / CRIMINAL INVESTIGATION (FR)

ID Name Description
FR01 - Conducting Investigations
FR01.F.1 Case assignment – The system should support workload assignment based on past experience, skills, qualifications of staff
previous experience members
FR01.F.2 Investigation checklist The system should automatically suspend other actions within the NAFA organisation when a case is allocated
- performed tasks e.g. the audit selection process. The automatic suspension of other actions within NAFA will not be transparent
to other NAFA personnel.
FR01.F.3 Suspension of other The system should allow marking all tasks/ control objectives performed within the ones predefined in the
actions investigation checklist.
FR01.F.4 Electronic updates of The system should provide a facility to update the case file electronically with details of action taken, reporting
cases of progress (as % of total work to be done), relevant information such as tax found to be due etc.
FR01.F.5 Case status change - The system should support definition of status variables for the case and status changes (e.g. opened, assigned,
definition pending, resolved) by selection of check box.
FR01.F.6 Case status change - The system should support generation of automatic e-mails to the supervisors/ managers based on status change
notification of the individual cases
FR01.F.7 Case deadline The system should be able to generate reminder e-mails to superiors whenever the case deadline is due.
reminder
FR01.F.8 Case access The system should be able to limit access to a case to selected case workers and subordinates.
FR01.F.9 Case information – The system should provide a facility to upload any relevant documentation to the case file. The system should
attachments able to attach any electronic documents to a case: proving documents, explanatory notes, and additional
comments, in any format.
FR01.F.10 Case information - The system should support the "finalization" of certain documents to prevent any further deletion, overwriting
final version or modification
FR01.F.11 Case subtasks creation The system should support creation of sub-tasks within the cases and assignment of these tasks to selected case
& assignment workers.
FR01.F.12 Case management - The system should allow the inspectors to make proposal to change the scope and timeline.
proposals for change
FR01.F.13 Case management - The system should support rescheduling of case deadline by supervisors.
deadline changes
FR01.F.14 Case management - The system should support approvals of cases linked to milestones (e.g. suspension, closure of the cases).
milestones
500 Section V. Requirements of the Information System

ID Name Description
FR01.F.15 Urgent requests The system should generate automatic notifications in case of extension of deadline for urgent requests.
deadline extension -
notification
FR01.F.16 Case closing The system should show the case file as being closed upon input of the relevant details by the relevant office.
Note: Required details comprise notes, all relevant documentation, copy of court decision where referred to the
Court, tax computation.
FR01.F.17 Case closing - The system should not allow for a case file to be closed without a tax computation being posted to the case file.
conditions
FR01.F.18 Taxpayer's ledger The system should automatically post the tax computation relating to a case file to the taxpayer’s ledger if one
exists, once established and confirmed, without waiting for the case file to be closed.
FR01.F.19 Taxpayer's - If there is no taxpayer’s ledger, the system should automatically notify the tax computation, once established
notification and confirmed, to the Enforcement Directorate, without waiting for the case file to be closed.
FR01.F.20 Closing cases allocated The system should keep the case file allocated to an anti-fraud central or regional directorate open until it is
to an anti-fraud closed by an input coming from relevant structures, through an assessment note.
directorate
FR01.F.21 Closing cases handled The system should keep the case file handled by an external party open until it is closed by an input coming
by external parties from the institutional cooperation Directorate, through an assessment note.
FR01.F.22 Document templates The system should be able to support generation of electronic documents based on document templates (i.e.
assessment notes). The type of template is selected by the inspector from a predefined list.
FR01.F.23 Assessment note - The system should allow changes in the assessment note at any time until the communication to and acceptance
changes by the taxpayer.
FR01.F.24 Assessment note - link The system should allow linking the findings in the assessment note with any sound documents uploaded in the
with documents case file.
FR01.F.25 Assessment note - The system should be able to prefill assessment note template with standard information, including trigger of
prefilled template the investigation, names of the investigation team inspectors, period of investigation.
FR01.F.26 Assessment note - The system should allow the inspector to fill in the findings within the assessment note template.
drafting
FR01.F.27 Documents templates - Document templates should be aligned with the Visual Identity Manual of ANAF and they should contain all
alignment needed elements (headers, logos, footers).
FR01.F.28 Documents templates - Document templates should be in file formats accessible to all users independently on the operating systems /
access document editor versions.
FR01.F.29 Assessment note - The system should include a separate function for the inspector to fill in explanations related to the findings.
comments The explanations should not be used to document the findings but to provide a clear view, if needed, for the
reviewer.
Section V. Requirements of the Information System 501

ID Name Description
FR01.F.30 Assessment note - The system should allow the investigation team to submit the assessment note for approval (e.g. "mark as
submission for prepared").
approval
FR01.F.31 Scoring/rating of The system should allow scoring/ rating of the findings in terms of impact and likelihood (low, medium, high/
findings likely, moderate, unlikely).
FR01.F.32 Assessment note – The solution should support internal quality assurance of case related work, by approval of certain documents.
quality review
FR01.F.33 Assessment note - The system should allow the manager to edit and make comments on the submitted assessment note. There
reviewer comments should be a dedicated section for reviewers.
FR01.F.34 Document The system should allow different document versions and check-in/check-out mechanisms.
management - version
control
FR01.F.35 Assessment note - The system should support approval of the assessment note by supervisor.
approval
FR01.F.36 Assessment note - The system should support rework and resubmission of the assessment note whenever supervisor requires.
resubmission
FR01.F.37 Approval of changed The system should allow approval of all changes on the assessment notes by the supervisor.
assessment note
FR01.F.38 Assessment note The system should allow automated notification for other NAFA structures' action, if the case.
resubmission -
notifications
FR01.F.39 Posting of investigation On closure of the case file, the system should automatically post the result of the investigation to the Taxpayer
results Risk History and Profile database (risk management module); ledger (confirming/ recording the tax found due
as a debt); register of Directors and Managers (updating the risk profile of the relevant persons); audit selection
file (allowing audit selection to recommence); seized goods register (disposal details)
502 Section V. Requirements of the Information System

11 – OBJECTIONS & APPEALS (AP)

ID Name Description

AP01 - Appeal/Application Submission

AP01.F.01 Appeal/Application System should have facility to submit online memorandum for Appeal, Review, or application for reference,
Submission rectification etc.
AP01.F.02 Appeal/Application System checks validity and eligibility of application based on predefined criteria at time of submission
Submission
AP01.F.03 Appeal/Application The system should link the Appeal application with the Order no. (E.g. Assessment case no/Penalty order
Submission no/Cancellation Order no. etc.) against which the remedy has been sought.
AP01.F.04 Appeal/Application The system should facilitate the logging (entry) of a dispute (objection or appeal) that has been submitted
Submission manually
AP01.F.05 Appeal/Application The system should allow the officers and ANAF staff members to post comments on ground of appeal if
Submission directed by appellate authority.
AP01.F.07 Appeal/Application The system should have the ability to provide case management for disputes
Submission
AP01.F.08 Appeal/Application The system should check for completeness of objection using the following criteria:
Submission - Timeliness of the objection (System should check against date of notice of assessment)
- Grounds for Objection (Coding/Parameterized)
AP01.F.09 Appeal/Application The system should have the ability to recognize an objection to the whole or part of an audit assessment.
Submission Consequently, the tax not in dispute should be monitored for collection whilst the part in dispute is held in
abeyance while the objection should be processed.
AP02 - Appeal proceeding process
AP02.F.01 Appeal proceeding The system should permit assignment of dispute cases to the reviewer (based on a flexible case management
process system) and routed through the manager to the authorized officer.
AP02.F.02 Appeal proceeding System notifies concerned authority passing the order against which appeal is sought
process
AP02.F.03 Appeal proceeding System automatically updates the record of concerned district office of the authority passing the order against
process which appeal is sought.
AP02.F.04 Appeal proceeding The system should allow the reviewer to make a request for supporting documents (including return) when the
process taxpayer is disputing a tax determination via a system-generated letter.
AP02.F.05 Appeal proceeding System helps schedule the Hearing dates on Appeal cases in queue and availability of Appellate Authority.
process
Section V. Requirements of the Information System 503

ID Name Description
AP02.F.07 Appeal proceeding The system should provide the User the facility to check next hearing date online
process
AP02.F.08 Appeal proceeding The system should facilitate the processing of a dispute at multiple levels and each level should follow the
process standard steps.
AP02.F.09 Tracing of disputed System should provide functionality to trace a disputed fiscal administrative document from its issue date until
fiscal administrative the final pronouncement of a solution regarding tax obligations established by that fiscal administrative
document document.
AP02.F.10 Data extract System should provide functionality to extract data and information on the activities for remedies (solutionare
a constestatiilor – solving complaints) both at central and regional level necessary for preparation of certain
reports / statements in a timely manner.
AP03 - Appeal Notice / Order Generation
AP03.F.01 Appeal Notice / Order System should be able to generate notices/orders in pre-defined formats with inputs from assessing authority.
Generation The order should contain:
 Summary of appeal case decision containing history of the selected appeal case.
 Legal clauses used in final decision
AP03.F.02 Appeal Notice / Order The system should allow for the updating of the taxpayer’s current account with the outcome of the dispute and
Generation recognizing the applicable collection date. The system should apply interest, penalties and surcharges (if
applicable).
AP03.F.03 Appeal Notice / Order The notices published on the website after resolution of the appeal should not contain any personal reference to
Generation the taxpayer
AP03.F.04 Taxpayer access Regarding the taxpayers, they can have access to depersonalized decisions on issued appeals and can track the
settlement status of an appeal
AO04 - Appeal Rectification / revision processing
AP04.F.01 Appeal Rectification / System should allow for department assessing authority initiated/applicant initiated rectification.
revision processing
AP04.F.02 Appeal Rectification / System should allow online issue of revision notice only if there is material error.
revision processing
AP04.F.03 Appeal Rectification / System should have the capability to record the case history including any hearing dates, hearing proceedings
revision processing and outcome of the hearing.
AP04.F.04 Appeal Rectification / The system will have ability to inform Taxpayer Accounts the impact of the decision taken by the court.
revision processing
AP04.F.05 Appeal Rectification / System should allow rectification/revision to be made in the record.
revision processing
504 Section V. Requirements of the Information System

ID Name Description
AP04.F.06 Appeal Rectification / The system should provide the ability to capture the tax decision of the court
revision processing
AP05 - Record maintenance
AP05.F.01 Record maintenance System should facilitate creation and maintenance of all appeals filed in respective courts of Romania
AP05.F.02 System should automatically post demand created/refund allowed to corresponding module
AP05.F.03 The system should provide the ability to capture decision on whether to grant the appeal
AP05.F.04 The system should provide the ability to capture decision on whether to refer the case to higher court(s)
AP05.F.05 The system should provide the ability to captured all court case details including date of appeal/reference
AP05.F.06 The system should allow for restricted view of case details by users at each level of the dispute.
AP05.F.07 System should allow recording of case proceedings and case outcomes by the departmental officer
AP05.F.08 System should be able to generate reports of appeal, reference, rectification & remand cases on multiple
criteria’s like
a. Pending/Finalized
b. Date of filing
c. Act
d. Area
e. Authority
f. Judgment outcome (demand, refund, remand etc.)
AP06 – LegalCase Management
AP06.F.01 Preparation of case System will allow Legal Department to prepare a “case folder” with points of dispute, taxpayer’s contention,
folder arguments with the Department and a citation.
AP06.F.02 Review of case folder The case folder prepared then will be forwarded to appropriate authority for the approval/review,
AP06.F.04 Preparation of After judgment is passed, system will allow Legal Department to capture the judgment note in the system and
judgment note attach to the original case folder.
AP06.F.07 Intimation to taxpayer The system should have facility to communication the judgment order to other NAFA departments like
enforcement, taxpayer WEBSpace accounts, etc.
 AP06.F.08 Online court System should have facility to receive online court communication and documents regarding the case from any
communication part of the litigation
 AP06.F.09 Validity and eligibility System checks validity and eligibility of application based on predefined criteria at time of submission
of application
 AP06.F.10 Case management for The system should have the ability to provide case management for disputes
disputes
 AP06.F.11  Differentiation among The system should differentiate in the same cause between different departments of NAFA (for example
Section V. Requirements of the Information System 505

ID Name departments
various Description
NAFA central and NAFA regional) that may be involved as part in the court process
 AP06.F.12 Linking of case from After registration, the system should link the case from the court with the file from the other department (such
court as appeals solution case, tax audit department, anti-fraud department or enforcement department)
 AP06.F.13 Case identification System should identify cases that have the same object / taxpayer
 AP06.F.14 Joining of cases System should allow joining of the files when the court joins two cases or if subsequently the court assigns a
new file number
 AP06.F.15 Entry of court case The system should facilitate the logging (entry) of a court case that has been submitted manually
 AP06.F.16 Notifications The system should have the capability to send the notifications to the Legal Department managers of the
registration of a case or of any documents regarding the case regardless of the department that conducted it
 AP06.F.17 Assignment of case The system should permit manual and/or automatic assignment of the dispute cases to the reviewer (based on a
flexible case management system) and routed through the manager to the authorized legal advisers (officers).
 AP06.F.18 Notifications The system should have the capability to send the notifications to the managers and officers about any
communication from the court or other part of the litigation case
 AP06.F.19 Resolution & comment The system should allow the managers to put resolutions online and post comments regarding the case dispute
 AP06.F.20 Notifications After assignment of the case, the system should have the capability to send the notifications to the other
departments involved (appeals, tax audit, anti-fraud, enforcement) at first about the dispute and then about the
decisions of the court. The enforcement department should always be notified when the court grants the
suspension.
 AP06.F.21 Notifications The system should have the capability to send the notifications to the managers and the officers about court
terms and about deadlines for drafting legal representation papers for the court and will allow the updating of
deadlines based on court sites information as well as on subsequent court communications/ summons
 AP06.F.22 Objection to audit The system should have the ability to recognize an objection to the whole or part of an audit assessment.
assessment Consequently, the tax not in dispute should be monitored for collection whilst the part in dispute is held in
abeyance while the objection should be processed.
 AP06.F.23 Tracing of a disputed System should provide functionality to trace a disputed fiscal administrative document from its issue date until
fiscal administrative the final pronouncement of a solution regarding tax obligations established by that fiscal administrative
document document
 AP06.F.24 Data extraction and System should provide functionality to extract data and information on the activities performed by other
exchange departments concerning a case both at central and regional level necessary for preparation of certain reports /
statements in a timely manner
 AP06.F.25 Data access The system should not allow access to the taxpayers to the data and file of the legal department
AP07 – Insolvency Management
AP07.F.01 Amounts requested by The system should highlight the amounts requested by creditors in the statement of affairs, as well as the
506 Section V. Requirements of the Information System

ID Name Description
creditor realized flow proceeds in the insolvency procedure
AP07.F.02 Information update The system should allow the information updating regarding insolvency procedures based on the information
posted on court sites and on the Insolvency Procedures Journal (BPI) site
AP07.F.03 Notification The system should allow notifications concerning the opening of the insolvency procedure, deadline for
joining the statement of affairs, deadlines for declaring appeals, deadlines for court terms, deadlines for
creditors assembly and creditors committee etc.
AP07.F.04 Notification The system should allow notifications of departments involved (taxpayer management, enforcement, tax audit
etc.) with regard to the opening of insolvency procedure to receive from them data concerning debts,
mortgages, warranties etc.
AP07.F.05 Notification The system should allow notifications of the insolvency unit and other departments involved (including the
customs department) concerning the non/ payment of current obligations during the whole procedure
AP07.F.06 Notification The system should notify the tax audit department to perform an audit on the taxpayer and to communicate to
the insolvency unit within the Legal Department the tax decisions within predefined time.
AP07.F.07 Reporting The system should be able to generate reports of insolvency cases based on multiple criteria like amounts
submitted to the statement of affairs, amounts not submitted, amounts collected according to the reorganization
plan, amounts collected following the liquidation of the taxpayer
Section V. Requirements of the Information System 507

12 – REVENUE ACCOUNTING (AC)

ID Name Description
AC01 – Revenue Accounting
AC01.F.01 Payment calculation Support accounting for voluntary payments and charge interest after the deadline expires.
AC01.F.02 Reimbursable amounts Allow accounting of reimbursable amounts.
AC01.F.03 Offsetting and deduction Perform account of offsetting of taxpayer debts
of client liabilities
AC01.F.04 Taxpayer liabilities Allow the recording of deferred and extended taxpayer liabilities, imposed freezing accounts, etc.
AC01.F.05 Accounting treatment Prevent deletion of accounting data but allow reversal of accounting operations (transactions).
AC01.F.06 Reporting collections Generate report for collected cash amounts for a specified period (day/month/year) by revenue receipts,
by type of payment, by staff and generally, and issue reports if any discrepancy of data.
AC01.F.07 Issuance of periodical Allow issuing of periodical reports as per NAFA requirements
reports
AC01.F.08 Liability calculation Calculate and record the new liability in the account.
AC01.F.09 Budgetary accounting Perform budgetary accounting in accordance with MOF requirements:
o Monthly Progressive Statements (Balance sheet)
o Quarterly Progressive Statement (Balance sheet and financial statement)
o Year-end Financial Account statement (Balance sheet and financial statement)
AC01.F.10 MIS reporting System should have the provision of generating reports. The role based access rights should be
provided to respective departments to view the report.
AC01.F.11 Submission of accounts The flow should be automatically submitted to the Treasury after confirmation by the respective
authority within NAFA in the system for submission
AC01.F.12 Query module System should allow Treasury to raise queries / discrepancies in the accounting information submitted
AC01.F.13 Query module System should allow the concerned person to respond to the queries/ discrepancies raised by the
Treasury.
AC01.F.14 Manual accounting notes The system should have functionality to permit manual accounting notes;
AC01.F.15 Taxpayer transactions The system should account for all types transactions from Taxpayer accounts module real-time.
AC01.F.16 Generation of accounting The system should enable automatic generation of accounting notes
notes
AC01.F.17 Account warranties and The system should have capability to account warranties and garnishments as per enforcement process;
garnishments
508 Section V. Requirements of the Information System

ID Name Description
AC01.F.18 Changes in closed The system should not permit changes in accounting for closed periods. Any changing for the closed
periods accounting period should allowed only after appropriate authorization in the system.
AC01.F.19 Generation of balance The system permits generation of balance sheet situation on fiscal unit level, county level, regional
sheet level and NAFA level.
AC01.F.20 Management of The system should have capability to manage accounting information at taxpayer level, debt type level
accounting information and fiscal unit level
AC01.F.21 Change in taxpayer The system should reflect in accounting module the changed in taxpayer status i.e. insolvency,
status bankruptcy, etc.
AC01.F.22 Month-end reconciliation The system should enable the month-end reconciliation between operational system and accounting
system.
Section V. Requirements of the Information System 509

13 – RISK ANALYSIS, RISK MANAGEMENT AND RISK MONITORING (RA)

ID Name Description
RA01 - Risk identification
RA01.F.01 Interface with External The system should have interfaces with external databases (i.e. RMS, business intelligence modules, other
Databases  government institutions and other entities).
RA01.F.02 Extract Information  The system should be able to extract information as defined by the user.
RA01.F.03 Analysis Database The system should create an analysis database, populated with data from external sources, NAFA databases
Creation and other internal sources.
RA01.F.04 Direct Linkage with Data It should be directly linked to the data warehouse or the next level of data formed from data marts where
Source data set formation and analysis can be processed.
RA01.F.05 Enable multiple Different users should able to access and use the same data source at the same time.
simultaneous users
RA01.F.06 Pushing MIS Reports The MIS (Management Information System) should push reports to the Risk analysis, selection and
planning unit within the concerned individual directorate based on parameters defined for the designated risk
officers appointed by concerned directorate.
RA01.F.07 Rules Based Approach The system should be able to maintain rule based mass data collection, management and analysis using data
from the data warehouse which can be organised and presented in and orderly and predetermined way
RA01.F.08 Rule Engine System should allow risk rules/flags to be designed, specified and built into the system to highlight risk
areas and sort data into risks and other specific components. e.g. a flag could highlight variances in income
either up or down by more than 20% on the previous year
RA01.F.09 Data mining functionality System should have ability to examine all data in a data set and highlight and report on trends and patterns
which are not evident when looking at the data on a case by case basis or using traditional spreadsheets or
data lists
RA01.F.10 Graphical user interface System should be capable of working with data and data manipulation has to be enabled with drag and drop
(GUI) / Drag and drop approach
RA01.F.11 Separate query builder The query builder should be separate from table view.
and table view
RA01.F.12 Data Import and Export It has to enable to import and export and use in analysis data from most common spreadsheet format tables
RA01.F.13 Formula/Functions It has to enable the creation and modification of variables through mathematical, logical and statistical
formulas
RA01.F.14 Filtering and Sorting It has to enable filtering of data via :
510 Section V. Requirements of the Information System

ID Name Description

i. simple filters
ii. conditional filtering
iii. combination of filters

Should allow sorting data about the taxpayer or the cases, based on the parameters coming from the risk
analysis.
RA01.F.15 Graphs It has to enable creation of graphs either from tables or datasets.
RA01.F.16 Reporting System It has to enable creation of standard summary reports at least in HTML or PDF format, with chart
functionality. Reports have to be able to be sent via e-mail manually or via automated regular processes
RA01.F.17 Templates It should possible to save the steps that an analyst has gone through during an analysis so that the same
analysis could be repeated automatically without repeating manually the same data steps or queries.
RA01.F.18 Timer It has to enable a routine running of a saved data analysis template so that the analysis can be repeated
automatically. The timing of analysis should be able to be set and changed as necessary
RA01.F.19 Risk Registry Indicators The risk analysis subsystem should check (e.g. by name of the risk indicator, identification number) if the
new indicators have been already uploaded/ already exist in the Risk registry.
RA01.F.20 Defining parameters for The risk officers should be able to provide parameters for each indicator to be used in the selection of
risk indicators taxpayers
RA02 - Risk analysis
RA02.F.01 Parameters for Risk The system should allow introduction of parameters for risk profiles by user.
Profiles
RA02.F.02 Ad-hoc Query Capability  The system should have an interactive dashboard where users can drill, pivot, and filter their data directly.
RA02.F.03 Ad-hoc Query Capability  The system should allow ad-hoc query and analysis capability. The risk analysis subsystem should allow
definition of risk analysis rules (i.e. "IF-THEN-ELSE" logic) in abstract mathematical rules.
RA02.F.04 Risk Profile Creation The risk analysis subsystem should have analytical capacity to merge all information available in the Risk
registry and create unique risk profiles.
RA02.F.05 Preventing too many The risk analysis subsystem should provide a safety mechanism to prevent too many matches occurring on
matches risks identified.
RA02.F.06 Forecasting Newer Risks The risk analysis subsystem should include a facility to forecast the impact of the introduction of new risk
areas.
RA02.F.07 Changing Risk assessment The risk analysis subsystem should have options to maintain and change risk assessment calculations.
Calculations
RA02.F.08 Drill Down Risk The risk analysis subsystem should allow the drill down of information from the Risk registry by sorting,
Section V. Requirements of the Information System 511

ID Name Description
Information filtering, querying, selecting relevant fields, when browsing the list of risk assessments.
RA02.F.09 Sampling The risk analysis subsystem should provide a facility to define the random selectivity risk profiles for
different transactions and adjust sampling levels for particular region, industry, type of goods etc.
RA02.F.10 Storing Calculations and The risk analysis subsystem should allow storing risk calculations and user-defined rules from various
Rules scenarios in each risk area
RA02.F.11 Risk Assessment The risk analysis subsystem should have options to maintain and change risk assessment calculations along
Calculations with automatically computing the total risk value of an identified risk and displaying the value within the
Risk registry.
RA02.F.12 Notifying users The risk analysis subsystem should alert defined users if certain inconsistencies are identified (e.g. non
correlation between the risk title, impact and the risk treatment identified) and also notify organisational
units responsible for further treatment when a single taxpayer triggers more than one risk profiles.
RA02.F.13 Creating Risk Profiles The risk analysis subsystem should provide a facility to create risk profiles on risk indicators using any
combination of matching techniques such as Wildcards, Thesaurus, Calculations and formulas (e.g. size of
the taxpayer, profit and VAT refund claims), Ranges of numeric fields, Phonetic matching - matching
words that sound alike, Fuzzy matching, etc.
RA03 - Risk prioritisation
RA03.F.01 Assigning Priority The system should be able to assign priority based on user-defined parameters.
RA03.F.02 Manual Intervention for The system should allow manual introduction of priority.
Priority
RA03.F.03 Risk Prioritization Where more than one profile exists for a given set of selection criteria, then the risk analysis subsystem
should select the one requiring the greatest degree of checking
RA03.F.04 Risk Treatment The risk analysis subsystem should record the risk profiles that generate intervention, capture data
regarding the results of interventions and perform an analysis of the effectiveness of risk profiles on a
continuous basis.
RA04 - Rating and selection of risky taxpayers
RA04.F.01 Risk Treatment  The system should be able to recommend treatment based on user-defined parameters.
RA04.F.02 Manual Intervention for The system should allow manual introduction of treatment.
Risk Treatment 
RA04.F.03 Notification of Functions  The system should be able notify relevant functions in case the treatment is risk transfer.

RA04.F.04 List of Risks to be The system should be able to generate a list of risks to be addressed properly.
Addressed 
512 Section V. Requirements of the Information System

ID Name Description
RA04.F.05 Estimation of Man-days The list should include estimated time and workload (how many man-days are needed to complete the
task), which should be manually input in the workload estimation step.
RA04.F.06 Hierarchy of Risks The system should be able to make a hierarchy of the risks based on priority.
RA04.F.07 Risk Map The risk analysis subsystem should generate the risk map according to the criteria defined by the used.
Note: The risk map is a graphical representation that illustrates the impact/ significance of risk and the
likelihood or frequency of a risk profiles.
RA05 - Risk evaluation reporting
RA05.F.01 Extract Information  The system should extract information on case re-system related to a respective risk from the case
management system.
RA05.F.02 Push Reports for Risk The system should "push" reports related to accuracy of risk assessment, based on user-defined KPIs (e.g.
Assessment  issued identified / controls conducted, types of issues identified / risks identified etc.).
RA05.F.03 Interactive Reports The risk analysis subsystem should allow interactive reports (inquiry by user), based on specific criteria,
such as: risks associated, area of control, period of control, region, staff.
RA05.F.04 Random Selection of The risk analysis subsystem should allow random selection of risk profiles/ selected taxpayers for verifying
Taxpayers  the accuracy/ the results of the treatment
RA05.F.05 Inquiries on Parameters  The system should allow inquiries by users of various parameters in risk analysis and comparison with case
parameters.
RA05.F.06 Analysing Trends The risk analysis subsystem should automatically analyse trends of the risk assessment results and list all
active cases.
RA05.F.07 Stakeholder Reporting The system should inform all interested parties (internal control staff, NAFA management, and other
NAFA structures) related defined and approved objectives, KPIs and targets. The system should also
generate automatic notification whenever changes in objectives, KPIs and targets occur.
RA05.F.08 Risk Area Reports The BI unit should be notified whenever a new risk area report is uploaded/ updated.
RA05.F.09 Category Risk Definition The risk officers should be allowed to define new categories of risks into the risk registry.
RA06- Rule Engine
RA06.F.01 Calculations and It should possible to compare different fields or datasets within a data base
comparison
RA06.F.02 Calculations and It should possible to set target period and comparable period(s) in the same field (e.g. comparing last year’s
comparison over time income with the previous year, or last month or with average of previous 12 months, etc.)
periods
RA06.F.03 Results’ content definition The system should able to define a specific result from the risk rules/engine. e.g.: a list of audit cases or a
summary report of risky taxpayers grouped by preferred characteristics like region or industry sector,
Section V. Requirements of the Information System 513

ID Name Description
income level or risk level, etc.
RA06.F.04 Directed random selection Where there are more equally risky taxpayers than resources to deal with it may be appropriate to use
random selection within specific risk areas (e.g. if a HNWI has been identified within risk area that is a key
strategic or priority area for NAFA the rule engine can be instructed to select 10% of cases randomly from
every region or industry group to be audited)
RA06.F.05 Criteria for the risk The risk analysis subsystem should assign risk score to a taxpayer with potential risk as criteria to the
profiles selected risk profiles
RA06.F.06 Risk profiles - uploading Risk officers should be able to introduce rules/ criteria for the generation of risk profiles into the risk
rules/ criteria analysis subsystem
RA07 – Risk Management
RA07.F.01 Taxpayer segment risk The system should enable the development of taxpayer segment risk models.
models
RA07.F.02 Steps in risk management The system should provide a process for a continuous risk management via the following steps (for
example):
- Risk Identification
- Risk Assessment and prioritization
- Analyze compliance behavior causes
RA07.F.03 Predictive risk models The system should enable the development of predictive risk models (using deductive and inductive logic)
to identify potential risk. (e.g.: taxpayers who may not be completing their returns properly -- reporting
risk).
RA07.F.04 Analytics risk models The system should have the capability to develop analytic models enabling NAFA to evaluate the tax at risk
for a potential audit, the tax at risk for a missing return or declaration, in addition to the tax at risk for
balances owing or instalments not paid.
These analytic models should use available information to build a given taxpayer’s risk quotient. These
models should be used to assign overall scores to taxpayers based on:
- The taxpayer’s profile
- The taxpayer’s tax history
- The amount of tax revenue at risk
RA07.F.05 Recommendation of risk The system should have the capability to recommend treatment strategies for risk identified:
treatment strategies - Conduct financial analysis of return and other data to automatically select cases for audit.
- Prioritize selected cases based on predetermined risk management criteria.
RA07.F.06 Risk management as per The system should enable the management of risk based on the following risk types:
risk types - Registration – risk that those taxpayers that fulfil the requirements to register fail to do so, or incorrect
information being held on the register
- Filing - Risk that tax yield will be understated / reduced by taxpayers not filing their returns by the due
514 Section V. Requirements of the Information System

ID Name Description
date
- Correct Reporting – risk that tax yield will be affected where the amounts shown on the tax return are
incorrect by error or deliberate act.
- Payment – risk that tax yield will be reduced by non-payment of amounts due on tax returns and
assessments
RA07.F.07 Risk management The system should enable the management of risk at various levels including: tax compliance, taxpayer
segment (i.e.: business function), and continued compliance risk.
RA07.F.08 Risk analysis The system should allow for the analysis of risks using data grouped in the following areas:
- economic and tax data, for example ratio's about the economic growth;
- data supplied by taxpayers, for example the data from the tax return(s);
RA07.F.09 Risk management reports The system should provide the capability to generate management reports on various risk factors such as
(for example):
- Registration - Failure to Register
- Filing - Failure to File Returns on Time
- Reporting - Failure to correctly Report Tax Liabilities
- Payment - Failure to Pay on time
RA07.F.10 Setting up of risk level The system should provide the ability for an authorized officer to set the risk level for a taxpayer. This
manual process will be initially used to input historical risk profiles based upon knowledge of the officials
into the system.
RA07.F.11 Selection of Taxpayers The risk analysis subsystem should have specific risk indicators to be used to select taxpayers for treatment.
The risk analysis subsystem should allow removal of selected cases based on feedback received from the
enforcement units within the NAFA.
RA07.F.12 Balance the income and The risk abalysis subsystem should provide the functionality to analyze the risk associated to the
the amounts spent for risk individuals using a comparative balance of the amounts spent by each individual, based on the information
analysis centered on from the ANAF internal databases, information form the financial institutions (e.g. lists of bank transfers,
individuals etc.), information from open sources, versus the income declared by the individual, for a certain fiscal
period of time. Should interface with existing application PATRIVEN.
RA08 – Managing Risk Indicators
RA08.F.01 Defining KPIs The system should be capable of defining Key Risk Indicators in NAFA’s context and capturing system
generated as well as manually fed KPIs
RA08.F.02 Correlation among risk The system should provide correlation mappings between risk and risk drivers and between Risk and Key
indicators Risk Indicators
RA08.F.03 Alert capability The system should have alert capabilities available in the module
RA08.F.04 Risk Plan The system should allow creating, updating and tracking risk issues and provide a link to an action plan
Section V. Requirements of the Information System 515

ID Name Description
RA08.F.05 Risk limit The system should provide for setting and monitoring risk limits
RA08.F.06 Variance analysis The system should provide ability to provide variance between planned and actual collections
RA08.F.07 Scoring Interventions The risk analysis subsystem should make provisions for weightings of defined NAFA interventions and a
scoring scale for different results of such interventions, to automatically calculate compliance rating of a
taxpayer.
RA08.F.08 Scoring based on The risk analysis subsystem should build-up risk scores for individual taxpayer based on historical
Confidence Factors confidence factor over time
516 Section V. Requirements of the Information System

14 – INTERNAL AUDIT (IA)

ID Name Description
IA01 – Internal Audit Planning
IA01.F.01 Strategic audit plan System will facilitate creation of Strategic audit plan for next 3-5 years. Since each entity is audited every 3
years, system will provide necessary alerts after completion of 3 years of audit activity.
IA01.F.02 Risk Analysis Every three years, Risk Analysis needs to be performed on the basis of available information in RMS.
Triggers of Risk Analysis for Internal Audit
1. Annual deficiencies
2. Change in fiscal code
3. Information from Risk Register
IA01.F.03 Audit Plan System will provide facility to prepare a more detailed annual plan on the lines of strategic audit plan
IA01.F.04 Criteria for annual audit System will enable defining the criteria for annual audit plan. Indicative examples of criteria are as follows:
plan  Periodicity of audit of particular function
 Risk analysis
 Signals / Inputs from Ministry of Finance and other institutes affiliated by law
 Human resources and financial resources available
Based on above criteria, audit missions are finalized for a year
IA01.F.05 Audit Plan Annual Plan is provided to top management for approval. Annual plan could be modified during the year
only after appropriate justification to top management and subsequent approval
IA01.F.06 Avoidance of duplication To prevent multiple audit activities, system should facilitate a common feature for all NAFA divisions (e.g.
audit activities Internal Controls, Internal Audit, etc.) responsible for Internal Audit related activities to manage a common
plan. If any external agency like Court of Accounts is planning to conduct the audit for same business /
entity, a manual intervention needs to be recorded in the system to highlight the same.
IA01.F.07 Scheduling of audit The system should be able to assist in generating the online and offline Audit Program for the upcoming
program audit cycle.
IA02 – Making audit mission
IA02.F.01 Control reports System should have facility to capture the Control reports (control reports are typically provided by agencies
like court of accounts, internal controls, etc.) in a centralized repository (i.e. Document Management
System). When Internal Audit conducts audit mission for the same entity, it should be able to check the
control reports related to that audit mission.
IA02.F.02 Reminder for audit The system should be able to create reminder to to start the new audit cycle.
cycles
IA02.F.03 Electronic workflow The system should be able to generate electronic workflow for review and approval.
Section V. Requirements of the Information System 517

ID Name Description
IA02.F.04 Audit candidates and The system should be able to attach the List of Audit Candidates and the justification Report.
audit report
IA02.F.05 Audit checklist The system should be able to record checklist for information and logistics needed by the auditor.
IA02.F.06 Scheduling of audit The system should be able to record the audit schedule for each auditor.
IA02.F.07 Scheduling of audit The system should be able to assist in streamlining all auditor activities.
IA02.F.08 Case management The system should be able to create electronic Audit Case Folder and identified with unique number.
IA02.F.09 Access to document The system should be able to access Document Management System and other database to retrieve all
management auditee's related information and attach into Audit Case Folder.
IA02.F.10 Access to historic Auditee will get access to the historic information pertaining to audit conducted for him.
information
IA02.F.11 Access to document The system should be able to provide the documents on previous years audit program that can be retrieved by
management auditors.
IA02.F.12 Audit Checklist The system should provide a facility to provide checklist which updates the status of audit activities.
IA02.F.13 Case management The document obtained from auditee should be able to be attached into the Case Folder.
IA02.F.14 Audit mission System should facilitate conducting audit mission covering following points
 Audit mission is strictly conducted as per audit plan i.e. period, objectives, duration and team
 A notice is given to respective department undergoing audit atleast 15 days before. The notice is
provided so that particular department could prepare required documentation
 Each auditor provides no conflict of interest certificate. System should capture this information
 Risk analysis is performed again to identify high risk activities to be audited in detail
 Staff involved in conducting audit goes to the premise of the audit with necessary checklists.
 Team of auditors is led by supervisor. System should identify the supervisor
 Once audit is completed, report is submitted to NAFA president for approval.
 If there are any inconsistencies, then a reconciliation meeting is arranged between audit team and
department undergoing audit. Head of Internal Audit division is moderator in case of doubts
 After report is approved, the action points indicated in the report become mandatory for department
for further action.
 Audit team can review or access documents based on the objectives of the mission.
IA03 – Tracking and reporting the implementation of recommendations
IA03.F.01 Log of activities Audit log of all the activities would be maintained in the system which can be checked by competent
authority as required.
IA03.F.02 Audit history The system should maintain the history and results of previous years’ audit.
IA03.F.03 Variance analysis The system should be able to record the audit time budget which can be compared with the actual time
518 Section V. Requirements of the Information System

ID Name Description
charged during the audit execution.
IA03.F.04 Implementation of audit System should facilitate tracking of the implementation of audit recommendations via 2 methods:
recommendations  Review of audit recommendations during next audit
 Special dedicated audit mission may be conducted to track implementation. This is arranged
depending on the severity of the audit recommendations.
IA03.F.05 Risk severity Risk severity is decreased after monitoring of recommendations provides positive results.
IA03.F.06 Audit recommendations If any audit recommendations are not implemented, system will provide facility to report to appropriate
authority.
Section V. Requirements of the Information System 519

15 – INTERNAL CONTROL (IC)

ID Name Description
IA01 - Resources availability
IA01.F.1 Resource Availability The system should have a staff availability module that contains information about:
  - the employee
  - specialisation
- grade / seniority level
- calendar and status / period (available, not available - fully booked, on vacation, partially available - %
availability)
IA01.F.2 Calendar for Non- The system should have a calendar of non-working days and vacation periods.
working Days
IA01.F.3 Utilization The system should target 90% staff utilisation on control activities.
IA02 - Resources usage
IA02.F.1 Resource Availability The system should be able to compare resource availability (based on user-defined number of employees) with
list of risks to be addressed and the estimated workload.
IA02.F.2 Resource Usage  The system should allow introduction of variables, such as assumption workload generated by requests (%).
IA02.F.3 Resource Usage  The system should be able to compute information on yearly, quarterly and monthly basis.
IA03 - Work plan execution
IA03.F.1 Compare Activity The system should compare status of activities with planned and recalculate the plan.
Status
IA03.F.2 Introduction of New The system should recalculate the plan for a specific period, by comparing (i.e. delayed activities will be
Parameters moved together with necessary resources)
IA03.F.3 Revised Control The system should allow changes during the period by introduction of new parameters related to risks and / or
Plan  staff.
IA03.F.4 Electronic Sign-off The system should generate revised control plan after the changes for the year, quarter or month.
IA03.F.5 Allocation of The system should allow electronic sign off and notifications to relevant parties.
Complexity level 
IA03.F.6 The system should allow evaluation and allocation of a complexity level to the internal control actions, on a
scale from 1 to 5.
520 Section V. Requirements of the Information System

ID Name Description
IA04 – Alerts – General
IA04.F.1 The RMS system should generate an alert each time the tax officers perform manual changes in the automated
processes in those cases when the change involves tax amounts or each time it is requested by the process.
IA04.F.2 The RMS system should generate an alert each time the tax officers access systems and information without
access rights (e.g. these situations may occur due to system errors; the access rights will be mainly be granted
to all tax officers by an assigned administrator.

Note: In case of repeated tries, the alert is going to be generated based on a minimum number of access tries
within a certain period of time (e.g. 2/ day).
IA04.F.3 The RMS system should generate an alert each time an operation is finalised without revision/ approval given
by hierarchical level (when the process involves such approval).
IA04.F.4 The RMS system should generate an alert each time when not all steps of the process are fulfilled by the tax
officers.
IA04.F.5 The RMS system should generate an alert each time it detects the lack of an attachment, although it is
requested by the procedure.
IA04.F.6 The RMS system should generate an alert each time a process step is completed much faster than the defined
time (to 50% of the number of days estimated for an activity).
IA04.F.7 The RMS system should generate an alert each time the tax officers exceed the legal deadlines for case
resolution/ allocated cases or the estimated time needed for fulfilling an activity (any overcome higher than
20% of the legal/ estimated time).

Note: the alert should have a higher priority if the exceedance of deadlines is repetitive in the case of the same
tax officer during a certain amount of time.
IA04.F.8 The RMS system should generate an alert each time the manual allocation of cases does not fulfil the defined
limitations.
IA04.F.9 The RMS system should generate an alert each time it detects deletion of documents from the DMS.
IA04.F.10 In case of alerts, the list with inquired alerts should be uploaded into the risk analysis system regularly
(monthly, twice a month, weekly).
IA04.F.11 The alerts should be connected with source systems as inquiries of those specific databases.
IA04.F.12 The upload should be performed in two stages: into a common data warehouse and, subsequently, into the risk
analysis system.
IA04.F.13 The alerts in the risk analysis system should be grouped by types and sorted based on the defined parameters.
IA04.F.14 The risk analysis system should allow changes into the priorities of the alert types, such as amendments to the
Section V. Requirements of the Information System 521

ID Name Description
values of the parameters.
The risk analysis system should embed a database and data mart in the Datawarehouse for information for risk
IA04.F.15
analysis.
IA05 – alerts related to Taxpayers services
IA05.F.1 The RMS system should generate an alert each time the standard waiting time is exceeded constantly by a
certain tax officer/ team within a determined period (e.g. monthly).
IA05.F.2 The RMS system should generate an alert when the medium duration of the taxpayer interactions (call, visit,
online) is constantly exceeding the standard in case of a certain tax officer/ team within a determined period
(e.g. monthly).
IA05.F.3 The RMS system should generate an alert each time the number of a taxpayer’s interventions related to the
same subject is exceeding a certain threshold (e.g. 3).
IA05.F.4 The RMS system should generate an alert when it detects a lack of records in the system for a certain number
of calls, visits or online interventions of a particular tax officer/team.
IA05.F.5 The RMS system should generate an alert each time theterm response to a request exceeds a certain number of
days (e.g. 3 days).
IA05.F.6 The RMS system should generate an alert each time unauthorized documents are listed.
IA05.F.7 The RMS system should generate an alert each time a large number of documents are listed.
IA06 - alerts related to Taxpayer registration
IA06.F.1 In the case of registration with the help of a tax officer, the RMS system should generate an alert each time the
application has been completed without attaching the minimum documents required, in scanned form.
IA06.F.2 The RMS system should generate an alert each time if the completion of the applications assigned to the same
tax officer has been exceeded repeatedly (e.g. 3 applications per month)
IA06.F.3 The RMS system should generate an alert each time an application for registration is approved without full
documentation.
IA06.F.4 The RMS system should generate an alert each time a taxpayer who has unsubmitted tax returns or unpaid tax
debts is deactivated.
IA06.F.6 The RMS system should generate an alert each time a taxpayer is reactivated with full rights although he has
unpaid tax debts.
IA06.F.7 The RMS system should generate an alert each time inputs are manually changed in the taxpayer history and
risk profile database.
IA06.F.8 The RMS system should generate an alert each time the deadline for conducting verification in case of
registration exceeds the accepted period with a certain number of days (e.g. 5 days).
IA06.F.9 The RMS system should generate an alert each time the checklist for taxpayers’ registration is not fully
522 Section V. Requirements of the Information System

ID Name Description
completed.
IA07 - alerts related to returns processing
IA07.F.1 The RMS system should generate an alert each time the tax return information is manually entered/modified
by the tax officer.
IA07.F.2 The RMS system should generate an alert each time the scanned statement is not attached to the request, in
cases of submission at the counter.
IA07.F.3 The RMS system should generate an alert each time the tax officer will correct material errors (amounts) on
the tax return.
IA07.F.4 The RMS system should generate an alert each time the tax officer decision to reimburse/not reimburse or
refund/not refund is against the recommendation of the system.
IA07.F.5 The RMS system should generate an alert each time a manual reconciliation of information comprised by the
buyer/seller matrix is performed.
IA08 - alerts related to taxpayer records
IA08.F.1 The RMS system should generate an alert each time amounts due are entered or modified manually, if the
source of establishing the debt involves automatic data transmission.
IA08.F.2 The RMS system should generate an alert each time amounts due are entered manually, if the source of
establishing the debt does not involve automatic data transmission and the sum exceeds a minimum value (this
minimum value may differ depending on the type of taxpayer).
IA08.F.3 The RMS system should generate an alert each time it detects a manual intervention has been made on the
default return.
IA08.F.4 The RMS system should generate an alert each time it detects a manual intervention has been made on the
corrected amounts.
IA08.F.5 The RMS system should generate an alert each time it detects a manual intervention on the transmission of
requests to the Treasury (transmission or stopping of the transmission).
IA08.F.6 The RMS system should generate an alert each time a payment is displayed without the consent of the taxpayer
according to the procedures for taxpayer’s services.
IA08.F.7 The RMS system should generate an alert each time it detects a manual intervention on the certificates or in the
databases accessed by third parties.
IA09 - alerts related to enforcement
IA09.F.1 The RMS system should generate an alert each time cases that do not meet the minimum requirements / limits
defined (value, effort) are allocated / assigned.

Note: The rules that generate the alert are defined in the system by ANAF. For example:
Section V. Requirements of the Information System 523

ID Name Description
- cases with a lower value are initiated / allocated even if the estimated effort exceeds x hours
- cases are initiated when the estimated effort exceeds a certain % of the value of the claim.
IA09.F.2 The RMS system should generate an alert each time the same tax officer is assigned repeatedly to cases that
involve the same taxpayer within a defined period of time (for example, 1 year).
IA09.F.3 The RMS system should generate an alert each time payment facilities are allowed although not all required
documents have been uploaded into the system by the tax officer.
IA09.F.4 The RMS system should generate an alert each time the tax officer approves/rejects the request for payment
facilities although not all legal requirements which should be reflected in the system’s parameters are met (the
amount, the history and the risk profile, the number of requests etc.).
IA09.F.5 The RMS system should generate an alert each time the tax officer takes decisions regarding the need to
submit a guarantee contrary to the recommendations of the system.
IA09.F.6 The RMS system should generate an alert each time the tax officer modifies the amounts recommended by the
system as minimum guarantee.
IA09.F.7 The RMS system should generate an alert each time the tax officer repeatedly grants tax incentives that do not
generate the recovery of the debt (more than half of the tax incentives), with the exception of automatic
approval of tax incentives, based on the risk profile.
IA09.F.8 The RMS system should generate an alert each time precautionary measures are issued and imposed without
the attachment of the minimum documents required by legislation.
IA09.F.9 The RMS system should generate an alert each time the seizure procedure is not started immediately after the
case allocation, following the failure of withholding (for example, 3 days).
IA09.F.10 The RMS system should generate an alert each time the tax officer does not physically identify the assets
suggested by the system repeatedly (for example, in more than 20% of the cases allocated to a single tax
officer, the assets are not physically identified).
IA09.F.11 The RMS system should generate an alert each time the assets introduced into inventory do not meet the legal
requirements regarding the prioritization of seized assets (e.g. liquidity).
IA09.F.12 The RMS system should generate an alert each time the essential information regarding the seized asset
(identification information, value) is not fully inserted into inventory.
IA09.F.13 The RMS system should generate an alert each time important information regarding the seized asset (quantity,
value) is subsequently modified.
IA09.F.14 The RMS system should generate an alert each time the tax officer raises the seizure without attaching a
document proving the warranty.
IA09.F.15 The RMS system should generate an alert each time the non-perishable goods are sold without an auction.
IA09.F.16 The RMS system should generate an alert each time the goods are sold under the recommended price without
524 Section V. Requirements of the Information System

ID Name Description
an auction.
IA09.F.17 The RMS system should generate an alert when, in the cases allocated to a tax officer, more auctions without a
participant or with one participant are recorded, within a defined period of time (for example, 50% of the
auctions organized by the tax official during a month had no participants or only one participant).
IA09.F.18 The RMS system should generate an alert each time the price of the assets or the date of the auction is
modified manually.
IA09.F.19 The RMS system should generate an alert each time the responsible tax officer is changed during an auction.
IA09.F.20 The RMS system should generate an alert each time a potential buyer is accepted by the tax officer without any
payment of the registration fee recorded.
IA09.F.21 The RMS system should generate an alert each time a significant undervaluation of the asset is identified (for
example, the selling price is 50% higher than the valuation).
IA09.F.22 The RMS system should generate an alert each time the auction is repeated in a short period of time (for
example, less than 3 days).
IA09.F.23 The RMS system should generate an alert each time the price drops below the accepted limit, in case of
repeated auctions.
IA09.F.24 The RMS system should generate an alert each time the deadline for payment of the assets auctioned is
manually extended over the specified parameters.
IA09.F.25 The RMS system should generate an alert each time it detects a manual intervention on the results of the
auction (winner, amount).
IA09.F.26 The RMS system should generate an alert each time an auction with a significant value (for example,
minimum 5,000 RON) fails repeatedly.
IA09.F.27 The RMS system should generate an alert each time the same buyer wins more public auctions organized by
the same tax officer within a defined period of time (for example, 3 months).
IA09.F.28 The RMS system should generate an alert each time the seized assets exceed the legal prescription period and
are not transferred to state ownership.
IA09.F.29 The RMS system should generate an alert each time the Court’s decision to suspend the enforcement is not
introduced in the system by the responsible tax officer.
IA09.F.30 The RMS system should generate an alert each time the proof of a submitted guarantee is not attached.
IA09.F.31 The RMS system should generate an alert each time the approval for suspension of enforcement procedures is
granted over a period of time by the same tax officer or for the same taxpayer.

Note: The alert will be generated in the following situations:

- the same tax officer approves the suspension of the enforcement procedures x times within a period of x
Section V. Requirements of the Information System 525

ID Name Description
months
- the same taxpayer receives more than x favorable decisions to suspend the enforcement proceedings in a
period of maximum x years
IA10 - alerts related to Tax audit
IA10.F.1 The RMS system should generate an alert each time the same tax officer is allocated for the control of the
same taxpayer, over a certain period (for example, the second time in a year).
IA10.F.2 The RMS system should generate an alert each time the same tax officers are allocated to the same tax audit
team, over a certain period (for example, the second time in a year).
IA10.F.3 The RMS system should generate an alert each time the allocation does not account for the relationship
between the complexity of the case and the level of competence of the tax officer.
IA10.F.4 The RMS system should generate an alert each time a case is opened without being the result of a selection
based on risk analysis or of referrals from other NAFA structures.
IA10.F.5 The RMS system should generate an alert each time the duration of a tax audit has exceeded the initially
estimated duration by a certain % (for example, by 30%).
IA10.F.6 The RMS system should generate an alert each time the duration of the tax inspection is too short (for
example, less than 3 days for simple tax audits, less than 10 days for complex tax audits).
IA10.F.7 The RMS system should generate an alert each time the initial objectives of the control are removed or
replaced during the tax audit.
IA10.F.8 The RMS system should generate an alert each time the responsible tax officer is replaced during the tax audit.
IA10.F.9 During the tax audit, the RMS system should generate an alert each time documents not relevant for the
taxpayer or for the objectives of the inspection are accessed.
IA10.F.10 The RMS system should generate an alert each time the tax audit steps are not documented in relation to
critical aspects (for example, requested/ analyzed documents).
IA10.F.11 The RMS system should generate an alert each time critical elements are missing from the assessment notice.
IA10.F.12 The RMS system should generate an alert each time the assessment notices are delayed more than 3 days from
the tax audit finalization.
IA10.F.13 The RMS system should generate an alert each time the superior review is delayed for a certain amount of
days.
IA10.F.14 The RMS system should generate an alert each time the taxes, contributions and other amounts additionally
established and owed to the general consolidated budget are significantly different from the estimated amounts
(for example, +/-30%).
IA10.F.15 The RMS system should generate an alert when it detects a large number of complaints against the same tax
officer during a defined period (for example, 3 months).
526 Section V. Requirements of the Information System

ID Name Description
IA 11 - alerts related to Appeals
IA11.F.1 The RMS system should generate an alert each time the same tax officer is allocated for solving the appeals of
the same taxpayer, over a certain period (for example, the second time in a year).
IA11.F.2 The RMS system should generate an alert each time the tax officer allocated for solving the appeal has been
involved in issuing the contested decision.
IA11.F.3 The RMS system should generate an alert each time the duration for solving the appeal exceeds the legal
deadline.
IA11.F.4 The RMS system should generate an alert each time the duration for solving the appeal is too short (for
example, less than 3 days for simple tax audits, less than 10 days for complex tax audits).
IA11.F.5 The RMS system should generate an alert each time the steps taken to solve an appeal are not documented in
relation to critical aspects (for example, requested/ analyzed documents).
IA11.F.6 During the contestation, the RMS system should generate an alert each time documents not relevant for the
taxpayer or for the objectives of the appeal clarification are accessed.
IA11.F.7 The RMS system should generate an alert each time the responsible tax officer is replaced during an appeal.
IA11.F.8 The RMS system should generate an alert each time critical elements are missing from the minutes of appeals
resolution.
IA11.F.9 The RMS system should generate an alert each time the superior review is delayed for a certain amount of
days.
IA11.F.10 The RMS system should generate an alert each time it detects significant differences in the amounts owed
following the result of an appeal (for example, +/-30%).
IA11.F.11 The RMS system should generate an alert each time it detects a large number of court decisions contrary to the
appeals solutions, addressed to the same tax officer over a defined period (for example, 1 year).
IA12 - alerts related to fiscal information
IA12.F.1 The RMS system should generate an alert each time the parameters defined in the system are modified (the
risk register, the selection rules, the prioritization criteria etc.) outside the regular risk analysis process.
IA12.F.2 The RMS system should generate an alert each time manual overrides are made to the taxpayers risk scoring.
IA12.F.3 The RMS system should generate an alert each time it detects a manual intervention on the automatic selection
for treatment.
IA13 - alerts related to antifraud function
IA13.F.1 The RMS system should generate an alert each time the same tax officer is allocated to investigate the same
taxpayer over a certain period of time (for example, 1 year).
IA13.F.2 The RMS system should generate an alert each time the same tax officers are allocated to the same control
team over a certain period of time (for example, 1 year).
Section V. Requirements of the Information System 527

ID Name Description
IA13.F.3 The RMS system should generate an alert each time a case is opened without being the result of a selection
based on risk analysis or of referrals from other structures.
IA13.F.4 The RMS system should generate an alert each time a case suggested by the result of a selection based on risk
analysis or of referrals from other structures is not immediately initiated.
IA13.F.5 The RMS system should generate an alert each time the duration of the control exceeds the duration initially
estimated by a certain % (for example, by 30%).
IA13.F.6 The RMS system should generate an alert each time the duration of the control is too short (for example, less
than 3 days for simple controls, less than 10 days for complex controls).
IA13.F.7 The RMS system should generate an alert each time the initial objectives of the investigation are replaced
during the control.
IA13.F.8 The RMS system should generate an alert each time the responsible tax inspector is replaced during the
control.
IA13.F.9 During the investigation, the RMS system should generate an alert each time documents not relevant for the
taxpayer or for the objectives of the control are accessed.
IA13.F.10 The RMS system should generate an alert each time the control steps are not documented in relation to critical
aspects (for example, requested/ analyzed documents, other evidence).
IA13.F.11 The RMS system should generate an alert each time critical elements are missing from the control assessment
notice.
IA13.F.12 The RMS system should generate an alert each time the assessment notice of the control is delayed more than
3 days of its completion.
IA13.F.13 The RMS system should generate an alert each time the superior review is delayed for a certain amount of
days.
IA13.F.13 The RMS system should generate an alert each time it detects a significant difference between the estimated
amounts owed and the amounts established after the control (for example, +/-30%).
IA13.F.14 The RMS system should generate an alert when it detects a large number of appeals addressed to the same tax
inspector during a certain amount of time (for example, 3 months).
IA13.F.15 The RMS system should generate an alert each time the number of referrals to the Prosecution, made by a team
of control is low (for example, less than 20% of the allocated cases).
528 Section V. Requirements of the Information System

16 – MANAGEMENT INFORMATION SYSTEM /DECISION SUPPORT (MIS)

ID Name Description
MIS00. General Requirements
MIS00.F.1 MIS Tools The following tools should run on the MIS Platform:
• MIS 01 - Report Engine
• MIS 02 - Decision Support System (DSS)
• MIS 03 – Executive Information System (EIS)

Should integrate with the Revenue Risk Analysis (RM) and Anti-Fraud / Criminal Investigation (FR)
functional modules, for functions like data analysis, data analytics and risk scoring.

Note: the DSS should also be a part of the Risk and Anti-Fraud system, and licenses purchased in support of
Report analysis should also be purchased to support these functions.
MIS00.F.2 Automated MIS tools All MIS tools should be purchased and configured by the Developer to accommodate reporting and KPI
measurements.
MIS00.F.3 MIS Refresh Rate The MIS Database should be refreshed from Tax Administration production machines periodically (i.e. every
six hours).
MIS00.F.4 MIS Platform The MIS Platform should be capable of generating all periodic reports specified for a 24 hour period.
Performance
MIS00.F.5 Tax Administration MIS Data Warehouse daily, monthly and annual reports should be the basis for documenting trend line reports that
- generated trend lines demonstrate either improvements or problems with tax administration KPIs over time.

MIS00.F.6 The MIS Database The MIS Database should be documented in a Data Dictionary.
MIS00.F.7 The MIS Database – age The MIS Masterfile should contain production records dating back three calendar years for analysis purposes.
of records
MIS00.F.8 The MIS Database - The MIS System should back up to tape or disk MIS Legacy Data that is between 10 and 20 calendar years of
backup age for historical and special trend analysis.
MIS00.F.9 Data Warehouse - The Data Warehouse should store the results of all formatted reports.
results of reports
MIS00.F.10 Reports Database The MIS should store completed reports that were either automated or pushed to users or ad hoc reports
created for special purposes in a separate repository for 10 years.
Section V. Requirements of the Information System 529

ID Name Description
MIS00.F.11 Reports Database – Reports greater than 10 years old should be destroyed.
report disposal
MIS00.F.12 Query by Example The Database supplied with the Data Warehouse should be configured with a Query by Example facility that
(QBE) should allow authorized users the ability to create ad hoc reports using available data from the data
warehouse database.
MIS00.F.13 QBE - Data formatting The Query by Example (QBE) tool should permit data formatting.
MIS00.F.14 Dashboards - filtering The system should have areas in the overall RMS system dashboard display for filtering statistical reports.
reports
MIS00.F.15 Dashboards - content The system should allow to create and change the content of the dashboard or to navigate to a different
personalization view/studio.
MIS00.F.16 Training The developer should create a training class for all tools prescribed in this specification.
MIS00.F.17 Ad hoc searches The Management Information System Database should be searchable using a Query by Example tool that
permits construction of a search from relevant and authorized data stored on the MIS platform.
MIS00.F.18 MIS Scheduler – The scheduler should be capable of launching reports based on a schedule analyzed by the developer and that
scheduling MIS jobs maintains a uniform production workload throughout the day.
MIS00.F.19 OBE tools The QBE Tool should have the capability of seeing all tables, and all data items within a table to formulate
queries and create ad hoc reports.
MIS00.F.20 QBE tools – establish The QBE Tool should permit the user to establish queries in a Romanian Language presentation format, and
search parameters using a logic based on ISO/IMEC 9075 to return information of use to Tax Administration.
MIS01 Reporting (Report Engine)
MIS01.F.1 Reports Engine A reports subsystem should be provided to facilitate the query of information from MIS stores and formulate
a pre-defined report to Tax Administration.
MIS01.F.2 Reports Scheduler Each report should be automatically executed by a scheduler.
MIS01.F.3 Report title Each report should contain a formal title.
MIS01.F.4 Report format Each report should be designed in a “Report Engine” in a form that is clear to management (and validated
during Usability Testing).
MIS01.F.5 Real Time Totalizers All processes nominated for modernization should embed totalizers that permit the collection of real time
data.
MIS01.F.6 Report Templates The MIS Database should contain a repository of all reports templates and queries associated with report
templates.
MIS01.F.7 Schedule Jobs The Operating System or middleware should be configured to schedule reports to be compiled in accordance
with the frequency specified in detailed design documents.
530 Section V. Requirements of the Information System

ID Name Description
MIS01.F.8 Parameters The system should permit authorized users to include parameters in the system for data analysis and reports
generation.
MIS01.F.9 Temporary data store The system data source should be partitioned into a temporary data store for one-off analysis and a permanent
data store for ongoing analysis and reporting (pre-defined).
MIS01.F.10 Report dashboard The system should be able to combine multiple recurring reports into a single "report dashboard".
MIS01.F.11 Report exporting The system should be able to export reports in other formats (e.g.HTML, .XLS, PDF).
MIS01.F.12 Reporting - formatting The system should allow to format reports and to include images.
MIS01.F.13 Reporting - triggers The system should allow definition of different triggers for automatic events/generation of reports.
MIS01.F.14 Reporting - scheduled The system should support scheduled, ad-hoc, and event-driven delivery of reports, by email, network
delivery printer, FTP or fax.
MIS01.F.15 Dashboard - correlated The system should allow that from a dashboard a user can get a recommendation to other relevant dashboards
recommendations with similar topics and data or dashboards that were viewed by other users with similar interests.
MIS01.F.16 Dashboard - push The system should support a contextual engine that pushes relevant reports and dashboard to users according
relevant reports to their topic of interests, patterns of usage and likes.
MIS01.F.17 Reports to be addressed The list of existing reports for both tax and customs activity should be made available to the Supplier after
the contract signature and must be analyzed, further defined, designed, informally tested, and presented to
NAFA for formal testing.
NAFA should have the opportunity to define/ compile other types of reports together with the Supplier, based
on their needs and as such needs will be also legally addressed.
The reporting process is straightforward and should be governed by a series of daily, weekly, monthly and
annual automated tasks that should be created in the detailed system constructions stage. Each task should
generate a report that should be stored in the MIS and that would be used as a basis for generating trends and
costs to be used in NAFA’s strategic planning. In addition, certain system users should have the possibility to
generate reports, based on their needs, by using a dashboard through which they can select criteria that they
wish to use („ad-hoc reports”).
MIS01.F.18 Bid requirement At a minimum the reports should address the following functions of the System:
 Revenue Management
 Enforcement
 Tax audit
 Customs control
 Antifraud
Section V. Requirements of the Information System 531

ID Name Description
 Efficiency and effectiveness of the tax administration
 Tax evasion indicators
There should be two types of reporting:
 Reports of primary indicators – statistical data based on counters/ totalizers implemented in the
system, reports that will be issued and pushed/ generated regularly, as defined by the users
 Reports of computed indicators – compiled data computed based on primary indicators; all data
aggregations and report generating will be done automatically by the system based on the rules
defined by the users

All indicators included in the list of primary indicators should be divided based on:
 Type of taxpayer
o Small, medium, large
o Individuals/ companies
 Type of tax (CIT, PIT, VAT, social security etc.)
 Budget

Any criteria for extracting the information or for its dissemination may be defined subsequently, based on
specific needs of the users.

MIS01.F.19 Customs 3rd Party Data Customs data, which resides on the Customs Systems and contains VAT and other data that is necessary to
completing the Tax Accounts, should be exported periodically to the new Tax MIS Data repository. The
Customs data that resides in the Data Warehouse is used to support both Tax Administration and Customs
reports that will be delivered in accordance with these requirements.
MIS01.F.20 Customs reports Customs Reports are listed in appendix x and should be derived from Customs 3rd Party data exported from
Customs to the Data Warehouse.
MIS01.F.21 Changes in Exported Any change in Customs or any other 3rd Party data that effect already developed reports should be processed
Customs Data in accordance with proper Configuration Change Management with an approved and fully estimated
engineering change request.
MIS01.F.22 Report Queries Each report should contain embedded report queries to populate the form with the latest data stored in the
data warehouse.
MIS01.F.23 Report Engine – All reports should be formatted in a RMS reports tool.
532 Section V. Requirements of the Information System

ID Name Description
formatting
MIS01.F.24 Report Engine – Report All reports formatted in the Reports Engine should be completed with all data warehouse queries necessary to
Queries populate report templates.
MIS01.F.25 Report Dissemination – The system should allow definition of recipients of the reports and should allow changes to the allowed
Beneficiaries recipients.

MIS01.F.26 Report Dissemination – Reports should be addressed and sent to authorize users by posting reports to a space on the Data Warehouse
Posting for retrieval by authorized report recipients.
MIS01.F.27 Report Dissemination The system should permit electronically distribution of any content via preferred delivery vehicles, email,
-Delivery vehicles FTP, or network printers of fax.
MIS01.F.28 Report Dissemination – Authorized end users, authorized access to special sensitive reports should be capable of receiving the reports
retrieval of sensitive from the Reports Repository on the MIS Platform.
reports
MIS01.F.29 Report Encryption All sensitive reports should be encrypted prior to posting to the reports repository.
MIS01.F.30 Report Decryption The authorized User ID and password should decrypt reports for authorized users.
MIS01.F.31 Unclassified Reports – Less sensitive reports should be sent to the user in an encrypted form, by email.
Mailing
MIS01.F.32 Unclassified Reports – Unclassified reports should be stored in the Reports Repository on the MIS in the same manner as sensitive
storing reports were stored, to be used in trend analysis
MIS01.F.33 Report Date Time All reports should be stamped with a date and time signaling when the report was generated.
Stamp
MIS02 Decision support subsystem (DSS)
MIS02.F.1 Data Mart Support for There should be a Data Mart dedicated to Decisions Support System models dedicated to the Strategic
Decision Support Planning function.
MIS02.F.2 DSS Models in Support The Strategic Planning function should be capable of creating specialized Data Models, refreshed
of Strategic Planning periodically (i.e. every six hours)that report on the state of the Tax Administration System
Department
MIS03 Executive Information Sub system (EIS)
MIS03.F.1 Statistics graphics The EIS should be capable of modeling data in support of the DSS and ERP (Enterprise Resource Planning)
in a graphical tool.
MIS03.F.2 EIS Models – access to The EIS should create models that can be accessed in real time by managers reviewing current statistics in
models graphical form.
Section V. Requirements of the Information System 533

ID Name Description
MIS03.F.3 EIS Models – model EIS Models should be refreshed when the Data Warehouse is refreshed (every 6 hours).
refresh rate
MIS03.F.4 Drill Down capability An EIS Model should be created for every report.
MIS03.F.5 Trend analysis Trend lines should be calculated by the EIS, and the EIS trend lines should be changed each time the data
warehouse is refreshed.
534 Section V. Requirements of the Information System

17 – CASE MANAGEMENT (CM)

ID Name Description
CM01 - Case generation
CM01.F.1 Case Management The system will be configurable to create types of cases (function groups and trading activities) and to allow
case modification by including or removing functions.
Types of pre-defined cases include (but not limited to):
 Debt Management, non-stop completion element,registration and cancellation of enrolment
 Audit
 Refund funds
 Appeal
 Litigation
 Request taxpayers Information
 Early tax Decision
 Adjustments of accounts
 Survey
 Operative Information
CM01.F.2 Unique Case The system should be able to generate a unique case identifier related to the created case.
identifier
CM01.F.3 Register Metadata The CMS should be able to register metadata to a freshly created case (inter alia):
for cases - start date/time
- ID Number
- trigger of the case
- objective of case
- location and target function in central or regional structures
- deadline for case resolution
- workflow of the activity (i.e. initiated, in progress, completed)
CM01.F.4 Multiple Location The system should allow multiple location processing.
Controls
CM01.F.5 Add Documents to The system should be able to add any documents to a freshly created case (e.g. scanned petitions, orders etc.).
Case
CM02 - Case allocation
CM02.F.1 Case Allocation The system should require accept/ defer/ reject decision to be input by personnel with the relevant access rights
where the case has originated from the research tool on the command of an authorized user.
CM02.F.2 Staff availability The system should have a staff availability module that contains information about:
Section V. Requirements of the Information System 535

ID Name Description
module - the employee
- specialization
- grade / seniority level
- calendar and status / period (available, not available - fully booked, on vacation, partially available - %
availability)
CM02.F.3 Staff profile The system should maintain information related to all managers and according to rank, staff number and area
of work.
CM02.F.4 Employee The system should notify the employee and his manager on the job allocation.
Notification
CM02.F.5 Employee The system should change employee status in the employee availability list from available to be assigned for
Availability Status the estimated duration of the project.
CM02.F.6 Manual Processing Manual changes in the status should be possible based on access rights.
Right
CM02.F.7 Workload The system should support workload assignment based on past experience, skills, qualifications of staff
Assignment  members
CM02.F.8 Flagging Assigned The system should be able to avoid assigning same staff to same target function for control over one year
Employee  period.
CM02.F.9 Case Allocation over The system should be able to avoid employees being part of the same control team over one year period.
1 year  
CM02.F.10 Calendar The system should have a calendar of non-working days and vacation periods.
CM02.F.11 Staff utilization The system should target 90% staff utilization on control activities.
CM02.F.12 Workload analysis The system should be able to compare resource availability (based on user-defined number of employees) with
list of risks to be addressed and the estimated workload.
CM02.F.13 Workload The system should allow introduction of variables, such as assumption workload generated by requests (%).
assumptions
CM02.F.14 Computation The system should be able to compute information on yearly, quarterly and monthly basis.
CM02.F.15 Case prioritization The system should allow definition of a list of rules for prioritizing cases by the Risk analysis, selection and
rules definition programming Directorate.
CM02.F.16 Case prioritization The system should prioritize each case on acceptance according to prioritization rules defined by the Risk
analysis, selection and programming Directorate.
CM02.F.17 Case classification The system should maintain a list of rules for classifying cases.
536 Section V. Requirements of the Information System

ID Name Description
CM02.F.18 Classification of cases The system should classify each case on acceptance according to classification rules defined by individual
– rules directorate involved in control activities.
CM02.F.19 Classification of cases When an immediate action case is allocated a case number, the system should classify the case according to the
– rules classification rules.
CM02.F.20 Classification of cases The system should automatically classify Immediate Action cases as top priority, and take precedent over the
- immediate case normal monthly case allocation.
action
CM02.F.21 Case assignment – The system should notify the employee and his manager on the job allocation
notification
CM02.F.22 Case prioritization The event will facilitate the addition of a case to be worked on by a NAFA employee on a first in, first out rule
(FIFO), with the ability to reorder priorities through manual authorized intervention.
CM02.F.23 Staff availability - The system should call for staff availability from each of the individual directorate involved in control activities and
information request each of the regional Directorates 7 days before the end of month case allocation day, by creating an automatic
email to the listed managers.
CM02.F.24 Staff availability – The system should notify individual directorate involved in control activities by automatic email when a staff
reminder availability response is not received within 4 days before the end of the month
CM02.F.25 Staff allocation The system should carry out the allocation and notification process for each Directorate immediately after the
staff availability information is supplied.
CM02.F.26 Case classification The system should refer to the classification of each case and will identify the relevant central Directorate
department or to the regional Directorate department to each case.
CM02.F.27 Case assignment_full The system should allocate cases to each of the central Directorate and each of the regional Directorates
allocation according to priority and notified staff availability until all available staff days have been utilized. Cases may
be handled by the regional Directorates under the management of the correspondent Central Directorate, or
directly by the relevant central Directorate.
CM02.F.28 Immediate case The system should notify by an automatic email the relevant authority when an immediate action case is
action – notification allocated.
CM02.F.29 Case assignment - The system should allow for the automatic allocation according to priority and classification to be overridden
manual changes by a manual intervention by personnel with the relevant access rights
CM02.F.30 Case assignment – The system should notify each relevant Deputy General Inspector of the case allocation schedule by an
notification automatic email as soon as the case load for the Directorate is allocated.
CM02.F.31 Case acceptance - The system should allow the relevant authority of NAFA to access the system, identify the cases allocated to
NAFA Regional his Directorate and accept responsibility for taking action by noting the case file. The acceptance will be
Section V. Requirements of the Information System 537

ID Name Description
Directorate recorded against the case file.
CM02.F.32 Case acceptance - The system should allow the relevant NAFA Central Department to access the system, identify the cases
NAFA Central allocated to that department and accept responsibility for the management of the case (regional) or the
Department coordination and management of the case (national) role as appropriate. The acceptance will be recorded
against the case file.
CM02.F.33 Case acceptance – The system should notify named NAFA management by automatic email when a case accepted response is not
reminder received within 4 days after the end of the month
CM02.F.34 Case acceptance - The system should notify named NAFA management by automatic email when an immediate action case
immediate action acceptance response is not received within 2 days of the notification
case reminder
CM02.F.35 Status review and The system should be able to compare status of activities with planned and recalculate the plan for a specific
rescheduling period, by comparing available information (i.e. delayed activities will be moved together with necessary
resources)
CM02.F.36 Revised control The system should generate revised control plan after the changes for the year, quarter or month.
planning
CM02.F.37 Approvals The system should allow electronic sign off on the plan and notifications to relevant parties.
CM02.F.38 New parameters The system should allow changes during the period by introduction of new parameters related to risks and / or
staff.
CM02.F.39 Internal case - no The system should notify the relevant NAFA central Directorate and the Director of the Inter institutional
action notification cooperation Directorate by automatic email every 7 days if no action is recorded against a case file allocated to
a central/ regional Directorate for a reasonable time that will further be defined by the NAFA management.
CM02.F.40 External case - no The system should notify the Director of the Inter institutional cooperation Directorate, by automatic email
action notification every 7 days, if no action is recorded against a case file opened because of action commenced by an external
party (Financial Police, Prosecutors Office).
CM03 - Case set-up and parameterization
CM03.F.1 Pre-defined Checklist The system should have a library with pre-defined checklists and guidelines categorised by control objective /
and Guideline risks address and by function targeted by control.
Library 
CM03.F.2  Automatic Linkage The system should provide automatically links to the respective items in the library after the control objective /
to Library risks address and the function targeted are defined.
CM03.F.3 Populate Checklist of The system should automatically populate the checklist of controls after the control objective / risks address
Controls  and the function targeted are defined.
538 Section V. Requirements of the Information System

ID Name Description
CM03.F.4 Allow Modifications The system should allow changes / additions in the library.
in Library 
CM03.F.5 Notification to The system should send a notification to the methodology service, in case there are no pre-defined items for
Methodology Service  the respective type of control so that they are developed and added in the system.
CM03.F.6 Calendar of The system should have a calendar of activities (e.g. name of the activity, due date and status etc.).
Activities
CM04 - Case execution
CM04.F.1 Attach electronic The system should be able to attach any electronic documents to a case: proving documents, explanatory notes,
Documents  additional comments etc.
CM04.F.2  Finalization of The system should support the "finalization" of certain documents to prevent any further deletion, overwriting
Documents to avoid or modification.
modification
CM04.F.3 Internal Reporting of The system should support internal reporting of progress (as % of total work to be done).
progress 
CM04.F.4 Marking The system should allow marking all tasks/ control objectives performed within the ones predefined in the
tasks/objectives  internal control checklist.
CM04.F.5 Definition of Status The system should allow definition of status variables for the case and status changes (e.g. opened, assigned,
variables  pending, resolved etc.) by selection of check box.
CM04.F.6 Auto E-mails to The system should support generation of automatic e-mails to the supervisors/ managers based on status
Supervisors  change of the individual cases
CM04.F.7  Reminder for Due The system should be able to generate reminder e-mails to subordinates whenever the case deadline is due
date
CM04.F.8 Access right The system should be able to limit access to a case to selected case workers and subordinates:
CM04.F.9 Trigger for another The system will facilitate the setting up of an event that triggers the creation of another similar case or
case different. (e.g.: a case of refund the opening of a case triggers the audit).
CM04.F.10 Notification to The system can be configured to notify the taxpayer regarding to the allocation or assignment of any further
taxpayer delay or unjustified closure of the case.
CM05 - Case related task management
CM05.F.1 Creation of Sub-tasks The system should support creation sub-tasks within the cases and assignment of these tasks to selected case
and Assign to workers
workers
Section V. Requirements of the Information System 539

ID Name Description
CM05.F.2 Modifications to The system should allow the controllers to make proposal to change the scope and timeline.
Scope and Timelines
CM05.F.3 Re-Scheduling by The system should support rescheduling of case deadline by subordinates
Subordinates
CM05.F.4 Approval of Cases to The system should support approvals of cases linked to milestones (e.g. suspension, closure of the cases).
Milestones 
CM05.F.5 Generate Automatic The system should generate automatic notifications in case of extension of deadline for petitioner’s system.
Notifications 
CM05.F.6 Electronic The system should allow electronic submission of the notification/ letter to the Unit for Fast Printing to be sent
Submission to to the petitioner.
Petitioner 
CM05.F.7 Risk Management The system will have the capacity to allocate (and review) a risk value of a case.
CM06 - Case report generation
CM06.F.1 Case Report The system should be able to support generation of electronic document based on document templates: reports
Generation of internal control, notes of internal control, notes for petitioner’s system. The type of template is selected by
the controller from a predefined list.
CM06.F.2 Modification of Case The system should allow changes in the internal control report at any time.
Reports 
CM06.F.3 Embedding of The system should not allow embedding any documents within the report.
Reports
CM06.F.4 Linkage with The system should allow linking the findings in the internal control report with any sound documents uploaded
Documents in Case  in the case file.
CM06.F.5 Pre-Fill Report The system should be able to prefill report template with standard information: trigger of the control, names of
Template  control team members, period of control etc.
CM06.F.6 Controller Rights   The system should allow the controller to fill in the findings within the report template.
CM06.F.7 Controller Rights  The system should include a separate function for the controller to fill in explanations related to the findings.
The explanations should not be used to document the findings but to provide a clear view, if needed, for the
reviewer.
CM06.F.8 Assign for Approval  The system should allow the control team to submit the report for approval (e.g. "mark as prepared").
CM06.F.9 Score/Rate of The system should allow scoring/ rating of the findings in terms of impact and likelihood (low, medium, high/
Findings  likely, moderate, unlikely).
540 Section V. Requirements of the Information System

ID Name Description
CM06.F.10  Documentation Document templates should aligned with the Visual Identity Manual of ANAF and they should contain all
template needed elements (headers, logos, footers, etc.)
CM06.F.11 Availability of Document templates should be in file formats accessible to all users independently on the operating systems /
Document document editor versions.
Templates  to all
users
CM06.F.12 Case history The system will provide the facility to view all cases and the history of cases for the same taxpayer.
CM07 - Case report approval
CM07.F.1 Case Report   The system should support internal quality assurance of case related work, by approval of certain documents
CM07.F.2 Edit Reports  The system should allow the manager to edit and make comments on the submitted report. There should be a
dedicated section for reviewers.
CM07.F.3 Version Check- Documents should allow different document versions and check-in/check-out mechanisms
in/Check-out 
CM07.F.4 Case Report The system should support approval of case report by supervisor
Approval 
CM07.F.5 Case Report The system should support rework and resubmission of case report whenever supervisor requires.
Modification
CM07.F.6  Case Report Re- The system should allow approval of all changes on the internal control reports by the supervisor.
Approval
CM08 - Case notification
CM08.F.1 Case Notification  The system should make automatic notifications to predefined/ interested stakeholders

CM09 - Case execution reporting

CM09.F.1 Case Execution The system should count on a daily, weekly and monthly basis the cases by status, type, region etc.
Reporting 
CM10 - KPI management
CM10.F.1 Define Objectives, The system should allow the definition of objectives, KPIs and targets.
KPIs 
CM10.F.2 Modification in KPIs, The system should allow changes in the initial set of objectives, KPIs and targets.
targets
CM10.F.3 Update Stakeholders  The system should automatically inform all interested parties (internal control staff, NAFA management, and
Section V. Requirements of the Information System 541

ID Name Description
other NAFA structures) related defined and approved objectives, KPIs and targets.
CM10.F.4 Auto Notification in The system should generate automatic notification whenever changes in objectives, KPIs and targets occur.
case of changes 
CM11 - Activity reporting
CM11.F.1 Monitoring and The system should support monitoring and reporting on case activities on an instance level (status changes,
Reporting on Case document additions/deletions, reassignment etc.)
Activities 
CM11.F.2 Case by Case The system should centralise all case by case reporting related to completion of tasks.
reporting
CM11.F.3 Preparation of Based on centralisers compiled in step CM3.9, the system should prepare weekly, monthly activity report for
Reports for Case case workers (e.g. number of cases involved, number of sub-tasks assigned, number of sub-tasks resolved etc.).
workers
CM11.F.4 Push Reports  The system should push reports on a daily, weekly, monthly reports regarding the completion of tasks
assigned, status of the internal control reports compiled, number of tasks in progress, number of approved/
rejected reports, number and types of measures disposed, staff availability, assigned tasks etc.
CM11.F.5 Generation of The system should allow interactive reports (inquiry by user), based on specific criteria, such as: risks
Interactive Reports  associated, area of control, period of control, region, staff etc.
CM11.F.6 List Active Cases  The system should be able to list all active cases
CM11.F.7 Analyse Trends The system should automatically analyse trends of internal control results.
CM11.F.8 Management report The system will facilitate the generation of management reports for all cases (per type of event, location,
region, person, tax type, chronologically, the taxpayer's account number, etc.):
 Cases created
 Cases completed
 Cases in progress
 The audit of adjustments made on the case
 The chronological ratio of cases
CM11.F.9 Management report The system will generate management reports as follows (without being limited to):
 Type and number of queries
 Performance Reports
 By person
 By field of activity
 By industry
542 Section V. Requirements of the Information System

ID Name Description
 By tax type
 By configurable timeframe
CM12 - Case identity and integrity
CM12.F.1 Electronic Signature The system should allow electronic signature of documents.
CM12.F.2 Generation of Unique The system should generate a unique registration number to each report.
Registration
Number 
Section V. Requirements of the Information System 543

18 – DOCUMENT MANAGEMENT (DM)

ID Nature of requirement Description
DM01 – Enterprise Content Management
DM01.F.1 Enterprise Content The system should have the capability to capture documents in electronic format so that they can be created
Management and stored as electronic records from:
► Standard business application
► Standard office applications including open source software
► e-mail client applications
► Images created by a document scanning system

The Document Management should implement stencils for various documents such as protocols,
notifications, decisions, etc., needed by the employees to follow the necessary procedures for their activity.
Those stencils automatically issued by the system will be later filled in with the necessary information and
formalized (stamps, signatures) by the employees with attributions in this area.

The Document Management should interface with the Case management, in such way that the documents
from each case created to have an indicative in order to make the connection with the case.
DM01.F.2 Enterprise Content The system should have the capability to capture documents in electronic format so that they can be created
Management and stored as electronic records from:
► Standard business application
► Standard office applications
► e-mail client applications
► Images created by a document scanning system
DM01.F.3 Enterprise Content The system should support the capture and creation of any electronic document which can be stored as a
Management single electronic file. Examples include:
► Word processing documents
► Documents produced by text editors
► Spreadsheets
► e-mail messages along with attachments and e-mail receipts
► Presentations
► PDF format documents
► Document images from a scanning system
DM01.F.4 Enterprise Content Where the system captures records which are constructed of more than one component, it should able to:
544 Section V. Requirements of the Information System

ID Nature of requirement Description

Management ► Capture and create the record in a way that retains the relationship between its constituent components;
► Retain structural integrity of the record;
► Support later integrated retrieval, display, management of the record as one unit; and
► Dispose of the record as a whole unit, in one operation.
DM01.F.5 Enterprise Content The system should not impose, by its own architecture or design, any practical limit on the number of
Management records which can be captured and created into a folder; or on the number of records which can be captured
and created into the system as a whole.
DM01.F.6 Enterprise Content The system should be able to handle registration, movement and tracking of documents, including
Management electronic archiving.
DM01.F.7 Enterprise Content The system should be able to store and categorize electronic forms and templates for documents.
Management
DM01.F.8 Enterprise Content The system should allow tracking the status of a document processing.
Management
DM01.F.9 Enterprise Content The system should allow registering, scanning and electronically storing any document entered into the
Management organization along with any associated attributes to facilitate rapidly organizing and ordering, by type, date,
sender, recipient or department for which the document is addressed explicitly, or automatically by
information flow defined for this type of document.
DM01.F.10 Enterprise Content The system should allow storing and archiving all documents electronically.
Management
DM01.F.11 Enterprise Content The system should allow document scanning directly within the solution, without the need for reaching an
Management external application or tool.
DM01.F.12 Enterprise Content The system should provide native digital signature functionalities.
Management
DM02 – Document Workflow Management
DM02.F.1 Document Workflow The system should allow activity and workflow management
Management
DM02.F.2 Document Workflow The system should able to define hierarchical document flows.
Management
DM02.F.3 Document Workflow The system should able to define flows describing business processes.
Management
DM02.F.4 Document Workflow For previously defined workflows, the system should allow the creation of electronic forms that can be
Management completed throughout the activities that are performed by the workflow participants.
DM02.F.5 Document Workflow The system should allow submitting electronic documents for consultation, in accordance with the roles and
Section V. Requirements of the Information System 545

ID Nature of requirement Description

Management rights associated to different users
DM02.F.6 Document Workflow The system should display a different user-interface according to the access rights and roles for various
Management users
DM02.F.7 Document Workflow For each document, the system should store different versions that are created for every change made by
Management users who are allowed to edit. This is necessary for document traceability and audit trail.
DM02.F.8 Document Workflow The system should allow ad hoc information/distribution flows or approval/endorsement flows by selecting
Management users or user groups that will be assigned. Also the system should save these flows for subsequent reusing.
DM03 – Document Security and access management
DM03.F.1 Document Security and The system should be able to integrate with RMS to allow both internal and external access to different
access management areas of information and documents.
DM03.F.2 Document Security and The system should be document centric, allowing users with elevated access rights to review/edit an
access management electronic document according to predetermined access rules.
DM03.F.3 Document Security and Access to documents within the system should be made in a controlled and safe way by defining users, user
access management groups and access rights to different system features and documents or folders.
DM03.F.4 Document Security and The system should allow each user to have access only to documents and information to which access was
access management permitted explicitly.
DM03.F.5 Document Security and For each of the system functionalities, the user with administrative rights will define access rights for users,
access management who may or may not have the right to view those functionalities.
DM03.F.6 Document Security and The system should allow access rights to be specified at folder, file or document level. Transfer of access
access management rights should allowed according to the hierarchical structure of document storage.
DM03.F.7 Document Security and The system should allow multiple access rights offerings within the solution, and should facilitate adding
access management new users, transfer of rights, grouping users into groups, assigning user groups administrators.
DM04 – Document Search and Indexing
DM04.F.1 Document Search and The system should allow quickly finding the documents using complex search methods, searching by any of
Indexing its associated attributes (metadata, comments, version, annotation and content).
DM04.F.2 Document Search and The system should provide the feature to use search indexes, and to filter and sort search results.
Indexing
DM04.F.3 Document Search and The system should allow Auto-completion (displaying a list of words that begin with the characters already
Indexing typed).
DM04.F.4 Document Search and The system should allow Auto-correction (automatic correction of search terms).
Indexing
DM04.F.5 Document Search and The system should have Boolean searching functionality using logical operators such as AND, OR,
Indexing exclusion period, exact phrase, search interval, ignore uppercase.
546 Section V. Requirements of the Information System

ID Nature of requirement Description

DM04.F.6 Document Search and The system should enable document indexes as search filters.
Indexing
DM04.F.7 Document Search and The system should allow searching in additional predefined fields.
Indexing
DM04.F.8 Document Search and The system should allow archive searching.
Indexing
DM04.F.9 Document Search and The system should highlight search terms.
Indexing
DM04.F.10 Document Search and The system should allow wildcard searching (type character "*" to replace search elements).
Indexing
DM04.F.11 Document Search and The system should search using range of values.
Indexing
G05. Document Management System General Requirements
G05.F.1 Document Management The Document Management System (DMS)should allow creation of an internal document folder structure
System unrelated to the internal audit cases cases.

G05.F.2 Document Management The DMS should support assignment of user access rights to the elements of the folder structure (read,
System write, update) with possibility to inherit all access rights of a folder to all of its subfolder structure.
G05.F.3 Document Management The DMS should support Optical Character Recognition (OCR) of scanned documents.
System
G05.F.4 Document Management The DMS should support the Optical Character Recognition (OCR) of most widespread imaging formats
System (GIF, PNG, BMP, PDF).
G05.F.5 Document Management The DMS should support the registration of metadata to documents (inter alia: date of creation, date of
System receipt, date of scanning, source, language, classification (security based)).

G05.F.6 Document Management The DMS should provide QA review of scanned images before workflow and/or rejection during the
System processing of document-images.

G05.F.7 Document Management The DMS should allow the images to be zoomed, panned or rotated during the scan-time process.
System
G05.F.8 Document Management The DMS should allow the repositioning of pages within a document such that the pages can be reordered
System after the document has been scanned.
Section V. Requirements of the Information System 547

ID Nature of requirement Description

G05.F.9 Document Management The DMS should allow the manual adjustment of the brightness and contrast settings at scan time.
System
G05.F.10 Document Management The DMS should support industry standard scanners (ISIS drivers must be used
System
G05.F.11 Document Management The DMS should support Automatic Colour Detection (ACD) during scanning.
System
G05.F.12 Document Management The DMS should allow save of different versions (se regăseşte în documentul Draft Bidding la pag. 394) of
System the documents and include check-in/check-out mechanisms.

G05.F.14 Document Management The DMS should be able to search for documents based full text search.
System
G05.F.15 Document Management The DMS should be able to search for documents based combination of metadata and full text search.
System
Document Management
The CMS should support remote access to the functionality using the standard security mechanisms of
G05.F.16 System and Content
ANAF (VPN connections).
Management System
G05.F.17 Document Management The risk analysis system and the CMS should require technical resources only in alignment with the current
System workstations and network environment of NAFA, and should allow the parallel use of other applications
(e.g. Lotus Notes, MS Office, etc.).
G05.F.18 Document Management The CMS should support remote access to the functionality using the standard security mechanisms of
System ANAF (VPN connections).
G05.F.19 Document Management The risk analysis system and the CMS should require technical resources only in alignment with the current
System workstations and network environment of NAFA, and should allow the parallel use of other applications
(e.g. Lotus Notes, MS Office, etc.).
G05.F.20 Document Management The CMS should maintain transactional integrity that is to use commit/rollback mechanisms during
System database operations to avoid carrying out incomplete transactions.
G05.F.21 Document Management The CMS should allow configuration of alert conditions (changes of case deadlines, changes of audit team,
System denied attempts to read/delete/modify case related documents, changes of audit checklists, registration of
external e-mail addresses for notifications, reassignments of audit tasks, etc.) for changes in internal control
processes.
G05.F.22 Document Management The CMS should allow defining group alert conditions and assign them to monitoring personnel.
System
G05.F.23 Document Management The CMS should allow definition of addresses of notifications on alerts by providing e-mail address.
System
548 Section V. Requirements of the Information System

ID Nature of requirement Description

G05.F.24 Document Management The CMS should automatically send alert notification to appropriate personnel whenever alert conditions
System are met.
G05.F.25 Document Management The CMS should support definition of user groups and assignment of users to multiple user groups. Special
System roles of "case worker", "supervisor”, “operational management” etc. should be defined.
G05.F.26 Document Management The CMS should support setting special individual access rights even if users belong to same user group.
System
G05.F.27 Document Management The risk analysis system and the CMS should report on events logged by the centralized database and can
System be fully monitored for ease in overall system auditing and management.
G05.F.28 Document Management System should be able to archive documents.
System
G05.F.29 Document Management The risk analysis system and the CMS should have ability to have granular role and rule-based security
System across the entire environment.
G05.F.30 Document Management The system should permit the creation of password protected documents.
System
G05.F.31 Document Management The risk analysis system and the CMS should provide a universal login window for all modules for
System consistency and ease of use.
G05.F.32 Document Management The users’ access rights should be defined via the administration console.
System
G05.F.33 Document Management The risk analysis system and the CMS should have standards based integration with identity management
System tools (AD).
G05.F.34 Document Management All data transmissions, including attached documents and reports, should be encrypted.
System
G05.F.35 Document Management The CMS should allow net functionality whilst offline working.
System
G05.F.36 Document Management The CMS should allow the linkage of the unique registration number of internal control documents with the
System Document Management system.
Section V. Requirements of the Information System 549

19 – BUSINESS INTELLIGENCE (BI)

ID Name Description

BI01 - Activity Planning

BI01.F.1 Workflow - analysis The BI subsystem should permit customers to launch a request for business intelligence analysis through the
request initiation Workflow subsystem. Examples of business intelligence analysis reports requests: report on current and future
threats with proposed actions, report on non-compliance trends and risks, and report on potential violations and
suspects.
BI01.F.2 Analysis request - To complete an analysis request, the BI subsystem should have multiple selection criteria (e.g. purpose of
selection criteria analysis, type of analysis, deadline).
BI01.F.3 Case number The Case Number Generator should allocate a case number to the analysis request.
allocation The standard case number generator for documents, for audit folders, for collection folders and investigation
folders.
BI01.F.4 Planned analysis The BI subsystem should be able to send planned requests for analysis (for the pre-defined analysis) to the BI
requests unit.
BI01.F.5 Planned analysis In case of planned requests, the BI subsystem should auto-fill the request with the following details:
requests - prefilled client/beneficiary, type of analysis, purpose of analysis, deadline, information sources, and methodologies.
data
BI01.F.6 Analysis request - The BI subsystem should send notifications and alerts whenever a request for analysis is launched to the BI
notifications & alerts managers/supervisors to check and allocate the new request.
BI01.F.7 Analysis request The BI subsystem should have the ability to cancel an analysis request without closing the application.
cancelation
BI01.F.8 Performance reports The monthly BI performance reports should be uploaded to the Management Information System (MIS).

BI01.F.9 Performance reports - The BI subsystem should measure the number of ad hoc and automated analysis requests that were serviced
number of requests during the month.
BI01.F.10 Performance reports - The BI subsystem should measure the number of clients serviced and the average time to service each request.
number of clients
BI01.F.11 Request assignment The BI managers/supervisors should be able to assign an analysis request to a BI officer through the BI
subsystem.
BI01.F.12 Request assignment - The BI subsystem should send notifications to the assigned BI officer that he/she received an assignment.
notification
550 Section V. Requirements of the Information System

ID Name Description
BI01.F.13 Workflow - The workflow subsystem should deliver the request for analysis to the allocated resource.
Identification of
resources
BI01.F.14 Plan of analysis The BI officer should complete the agreed details for the analysis in the BI subsystem in the form of a Plan of
activity analysis activity.
BI01.F.15 Plan of analysis The BI officer should communicate the agreed Plan of analysis activity to the analysis requestor through the BI
activity - dissemination subsystem to the client.
BI01.F.16 KPIs The BI officer/manager should introduce in the BI subsystem KPIs to measure the achievement of the plan and
the impact of the analysis.
BI02 - Data Planning
BI02.F.1 Data accessing The BI subsystem should support data access through:
- Data capturing solution with multiple types of data languages and protocol support (converting data to tabular
form, removing or inferring missing values, converting data to different types, numeric data should often be
normalized or scaled so that they are comparable)
- Accessing data held in ODBC-compliant database (standard data transfer)
- Accessing data in flat files, SAS data sets, .XLS, .odf, .dmp
- Accessing web site data
BI02.F.2 Interfaces The BI subsystem should have interfaces to external databases for extraction of data.
Note: NAFA currently has more than 60 data exchange protocols with different institutions and the list should
be upgraded continuously.
BI02.F.3 Standardized rules The BI subsystem should allow standardized rules and jobs for data extraction.
BI02.F.4 Upload from internal The BI subsystem should allow upload of data from internal sources (i.e. MIS).
sources
BI02.F.5 Data sources The BI subsystem should be able to combine different data sources.
combination
BI03 - Data Collation
BI03.F.1 Standardisation The data needed for analysis should follow a standard and the BI subsystem should support standardization.
For example, a name should represented as name + surname, address should follow Romanian standard,
numeric values should have the same format, the number of decimals should the same, date can only have one
explanation etc.

BI03.F.2 Data formatting The BI subsystem should have Query by Example (QBE) tools for data formatting.
Query by Example (QBE) is a database query language for relational databases. QBE allows retrieving data,
Section V. Requirements of the Information System 551

ID Name Description
inserts, deletes and updates, as well as creation of temporary tables.
BI03.F.3 Consistency checks The BI subsystem should be able to check whether there are mismatches between critical identification data
(i.e. taxpayer name and identification code)
BI03.F.4 Missing data The BI subsystem should be able to check whether the data lacks fundamental information (e.g. taxpayer
code).
BI03.F.5 Temporary data store The BI subsystem should import the selected information into a temporary data store for data cleansing
(quality checks) and manipulation.
BI03.F.6 Scheduled update The BI subsystem should allow scheduled checks in the database for updates.
checks
BI03.F.7 Data update The BI subsystem should delete the old expired data and replace it with the recent one to permit faster access
and running.
BI03.F.8 Data quality checks The BI subsystem should perform quality checks on the data based on defined control keys.
BI04 - Data Analysis
BI04.F.1 Temporary data store The BI subsystem data source should be partitioned into a temporary data store for one-off analysis and a
permanent data store for ongoing analysis and reporting (pre-defined).
BI04.F.2 Hypothesis & The BI subsystem should permit BI officers to include hypothesis/parameters in the system for data analysis
parameters and reports generation.
BI04.F.3 Data model The BI subsystem should permit users to develop models using an intuitive interface.
BI04.F.4 Decision tree The BI subsystem should permit users to develop decision trees, browse and interactively create splits in
decision trees, collapses and expands decision rules.
BI04.F.5 Root cause analysis The BI subsystem should automatically search for the root cause of issues it detected and suggest plausible
explanations to the users.
BI04.F.6 Automatic model The BI subsystem should permit automatic model development option for frequently used data sources, such as
development Excel, reports, csv files.
BI04.F.7 Model altering The BI subsystem should permit impact of model altering - once a model was developed or altered, all
connected views will be affected.
BI04.F.8 Fly results The BI subsystem should permit on the fly results while developing the model - each change that is done in the
model, will be reflected automatically in the Model environment.
552 Section V. Requirements of the Information System

ID Name Description
BI04.F.9 Re-use of existing The BI subsystem should support the re-use of existing models. NAFA should store queries and filters capable
models of recreating the data analysis on demand. The data at the termination of this process is stored in the Analysis
Report. The place in the database that stored the results of the analysis should be cleared (for one-off analysis
jobs). For ongoing analysis jobs, data should reside permanently in the protected area. Data can be changed as
real time conditions dictate.

BI04.F.10 Organisation of data The BI subsystem should support multiple methods to organise data for analysis, such as:
- clustering and segmentation techniques
- filters, sorts, and subsets of association models
- data reduction techniques, factor analysis and principal components analysis
- naming, derivation, categorization and value replacement, merging and concatenating, multiple criteria
selection / filtering, filtering of exceptional records
- creating union, intersection or complement of datasets
- splitting data into n-tile percentage intervals for any numerical variable
- sampling and randomized sampling
BI04.F.11 Column based indexing The BI subsystem should permit column-based indexing for faster data retrieving.
BI04.F.12 Data manipulation The BI analysis subsystem should have the following manipulating functionalities:
- the BI application allows ad hoc data browsing capabilities
- drag & drop dimensions to build the view structure
- layout and filters without re-querying the data at each step
- click to retrieve data and populate the data on a predefined view
- slice on multiple members in multiple dimensions on the grid
- filter out the empty data from grids for easier data navigation
- switch location of the grids rows and columns
- switch location of nested members in columns or in rows
- slice using single selection on a dimension
- slice using multi-selection on a dimension
BI04.F.13 Text manipulation The BI subsystem should be able to extract quality information from text analysis by identifying patterns.
BI04.F.14 Data changes The BI subsystem should be able to process only the data changes and not the full tables. Processing the entire
processing data every time can take significantly more resources, narrowing the ability to obtain real-time BI.
BI04.F.15 Data analysis - The BI subsystem should automatically browse through large data sets to find positive and negative trends
browsing within the data, alerting the viewer upon tracing irregular trends.
BI04.F.16 Data analysis - trends The BI subsystem should be able to:
and patterns - validate discovered trends or patterns
- launch a statistical analysis to verify trend
Section V. Requirements of the Information System 553

ID Name Description
BI04.F.17 Data drilling The BI subsystem should have the ability to drill up/down on a specific member, the ability to drill up/down
directly to specific level in the hierarchy and drill across to other dimensions for an existing member.
BI04.F.18 Data drilling - The BI subsystem should have the ability to drill through:
dashboard - quick and easy drill through from one dashboard to another with all relevant parameters and slicers
- quick and easy drill through from one Dashboard to any 3rd party application (example SSAS, SSRS) with
all the relevant coordinates and slicers.
BI04.F.19 Formulas The BI subsystem should permit use of formulas:
- quickly add predefined calculations by users
- users can visually change parameters in existing formulas
- add custom built formulas to a functions library that can be shared with other users
- advanced formula editor
- supporting DAX formulas for Tabular

BI04.F.20 Exceptions The BI subsystem should support a simple interface that:

- allows the creation of business rules and the ability to highlight the exceptional data that doesn’t meet these
criteria
- automatically analyses lower data levels, which are not visible in the grid, and highlight the insight for quick
analysis
- quickly changes the threshold of the exception using an adjustable parameter (slider)
- clear visual presentation of the exceptions
BI04.F.21 Predictive analysis The BI subsystem should use predictive analysis techniques, such as:
techniques - regression algorithm, multi-variable regression predictive models
- association rules which identify patterns in transaction data for describing which events frequently occur
together
- consistent coder automatically fills in missing values and detects out of range data
- sequence coder aggregates events into a series of transitions
- event log which aggregates events into periods of time
BI04.F.22 Calculation options During the analysis phase, the BI subsystem should be capable of running at minimum:
- statistical and hypothesis testing
- complex query IF-THEN-ELSE logic
- add calculations such as sum, average, moving average, and count to reports, in-built functions, custom
functions
BI04.F.23 Forecasting The BI subsystem should allow introduction of parameters for forecasting (see requirement no BI04.2.F.2).
Example of parameters for anti-fraud data analysis:
Consider a binary classification problem (classifying the elements of a given set into two groups on the basis of
554 Section V. Requirements of the Information System

ID Name Description
a classification rule).
Attributes to describe taxpayers:
- Age, 30 – 45 year
- Gender, Female or Male
- Self-employed, Yes or No
- VAT registration, Yes or No
- Payment remark, Yes or No
- Declared income, less than RON 225,000 or more than RON 225,000
- Region
- Target variable: Fraud, Yes or No
BI04.F.24 Forecasting - real time The BI subsystem should permit real time forecasting. When data is changed by adding more information, the
forecast should also change.
BI04.F.25 Map integration The BI subsystem should be able to show BI data on a map without any pre-configuration. The data from the
map needs to be interactive with the data from grids and charts on the same dashboard page. Map integration
can be possible with any of the following data entries: country, city, geographical regions.
BI04.F.26 Generation of The end user of the BI subsystem should be capable of generating graphical models.
graphical models
BI04.F.27 Reporting The BI subsystem should have the capability to create step-by-step reports, use pre-set templates and to
generate reports automatically.
BI04.F.28 Reporting - report The BI subsystem should be able to combine multiple recurring reports into a single "report dashboard".
dashboard
BI04.F.29 Reporting - report The BI subsystem should be able to export reports in other formats (e.g.HTML, excel, PDF).
exporting
BI04.F.30 Reporting - charts and The BI subsystem should generate various types of charts and graphs such as:
graphs - Bar charts
- Stacked bar
- Column
- Stacked column
- Line charts
- Area
- Numeric or date/time x-axis
- Pie/doughnut
- Scatter plots
- Bubble
- Gauge
Section V. Requirements of the Information System 555

ID Name Description
- Gantt
- Funnel
- Multiple 2D and 3D charts
- Histograms
- Time tables
- Charts and plots etc.
BI04.F.31 Reporting - report The BI subsystem should permit the use of the following report types:
types - cross-tab reports
- form-style reports
- sub-reports
- conditional reports
- top/bottom reports drill-down/summary reports
- OLAP reports
- tabular reports or data visualisation-enabled reports
- compound reports that combine several reports into a single PDF file
- parameterized reports using run-time filtering
- sorting and grouping
- matrix
- freeform
- linked
BI04.F.32 Reporting - formatting The BI subsystem should allow to format reports and to include images.
BI04.F.33 Reporting - real time The BI subsystem should permit real time reports access.
access
BI04.F.34 Reporting - triggers The BI subsystem should allow definition of different triggers for automatic events/generation of reports.
BI04.F.35 Reporting scheduled The BI subsystem should support scheduled, ad-hoc, and event-driven delivery of reports by email, network
delivery printer, FTP or fax.
BI04.F.36 Dashboard - correlated The BI subsystem should allow that from a dashboard a user can get a recommendation to other relevant
recommendations dashboards with similar topics and data or dashboards that were viewed by other users with similar interests.
BI04.F.37 Dashboard - push The BI subsystem should support a contextual engine that pushes relevant reports and dashboard to users
relevant reports according to their topic of interests, patterns of usage and likes.
BI04.F.38 Validation of reports The BI subsystem should permit electronically transmission of the report and the users should have the
possibility to add comments to the reports.
BI04.F.39 Validation of reports - The BI subsystem should allow changes in the initial reports. The subsystem should allow the manager to edit
Reviewer comments and make comments on the submitted report. There should be a dedicated section for reviewers.
556 Section V. Requirements of the Information System

ID Name Description
BI04.F.40 Validation of reports - The BI subsystem should generate notifications to the BI officer whenever comments are released by the
notification reviewer (BI manager/supervisor).
BI04.F.41 Web scraping tools System should be able to crawl (search by product on its own) the web in the pre-defined time intervals to
index relevant pages and content on the web
BI04.F.42 Social network analysis System should have capability for social network analysis
BI05 - Dissemination of Information
BI05.F.1 Reports dissemination The BI subsystem should permit automatically distribution of reports/data on a scheduled or alert or event-
driven basis.
BI05.F.2 Definition of reports The BI subsystem should allow definition of recipients of the BI analysis reports and should allow changes to
beneficiaries the allowed recipients.
BI05.F.3 Delivery vehicles The BI subsystem should permit electronically distribution of any content via preferred delivery vehicles,
email, FTP, or network printers of fax.
BI05.F.4 Document The BI subsystem should be able to store reports in the Data Management System.
management - storing
BI05.F.5 Scheduled delivery of The BI subsystem should allow scheduled delivery of reports by end users or administrators.
reports Reports/dashboards can be sent upon schedule or when changes occur in the data or according to a business
role.
BI05.F.6 Report delivery The Workflow Management subsystem should record the transmission of the approved final report to the
registration client.
BI05.F.7 Access rights The users should have the following rights through the system:
- view reports
- create reports
- modify reports
- print reports
- forward reports
The recipients can be also clients which are not users of the BI system.
BI05.F.8 Report sharing The client of the BI report should be able to share the report through the BI subsystem with other users based
on appropriate access rights.
BI05.F.9 Report storing All BI analysis reports should be stored in the Document Management subsystem.
BI06 – Data Mining
BI06.F.1 Data mining System should enable NAFA to detect patterns and select parameters to be assessed during audit
BI06.F.2 Data mining System should compute a rating related to revenue reliability (risk rating) of the taxpayer based on registration
information
Section V. Requirements of the Information System 557

ID Name Description
BI06.F.3 Data mining System should enable assessment of registration details for determining / modifying risk profile rating and to
detect fraudulent taxpayers
BI06.F.4 Data mining System should enable rule based / cluster analysis for profile grouping and profile matching
BI06.F.5 Data mining System should support assessment /modification of taxpayer profile risk rating, supplier side risk rating and
customer side risk rating based on default history of a particular taxpayer
BI06.F.6 Data mining System should allow NAFA to perform analysis of zero filers and cross check / correlate zero filer information
with internal and external sources of data
BI06.F.7 Data mining System should allow alerts to be generated whenever flagged taxpayers or taxpayers with high risk rating are
present among the zero filer / non filer list
BI06.F.8 Data mining System should support selection of criteria for deciding level of audit activity and frequency of audit so that
yield per audit (revenue collected through audit) is maximized
BI06.F.9 Data mining System should support detection of patterns so that criteria for various thresholds can be reviewed and
modified.
BI06.F.10 Data mining System should support selection of criteria for Identification of cases for special Business audit
BI06.F.11 Data mining System should support impact analysis of selection criteria on coverage across registered taxpayers (through
supply-side and demand-side analytics). [Once a taxpayer is audited, details of suppliers and customers are
also subject to scrutiny. This enables greater coverage across the supply-side and demand-side chain of the
taxpayer. If this is recognized by the system, then the selection of taxpayers for Business Audit can be done
more intelligently].
BI06.F.12 Data mining System should have the capability to assist the NAFA to define the criteria for prioritization of cases for Audit
and assist in conducting system based desk audit / pre audit preparation.
BI06.F.13 Data mining The system should have capability to perform analysis to define criteria / parameters for identifying fraudulent
transactions and evasion of taxes regarding suspected / manipulated / false tax invoices
BI06.F.14 Data mining System should have capability to define the criteria for selecting the cases for investigation where search and
seizure may be required. These criteria need to be configured on the basis of combination of various
parameters that will be decided by anti-fraud unit.
BI06.F.15 Data mining System should enable utilization of the information from several sources for analysis and tracking patterns/
trends of form consumption across regions and commodities, especially for interstate trade
BI06.F.16 Data mining System should support analysis to enable selection of criteria for identification of divisions / officers for
internal audit based on high risk patterns revealed through historical data
BI06.F.17 Data mining System should support identification of divisions / officers for internal audit based on trend analysis of
performance and deviations
BI06.F.18 Data mining System should support detection of different types of concealment patterns
558 Section V. Requirements of the Information System

ID Name Description
BI06.F.19 Data mining System should be scalable to incorporate any additional functional requirements and application of analysis
capabilities of the Data Mining tools, as required by the NAFA in the future.
BI06 – Ad-hoc reporting
BI07.F.1 On demand report System should have feature of user initiated ad hoc (on demand) reports
BI07.F.2 Query tool system should have query tool that serves both power users and occasional users
BI07.F.3 Query tool System should allow the user to enter query parameters, which are then used to select and retrieve only the data
that meet the specified criteria
BI07.F.4 Print and export System should have provision to print and export the report generated in the pre-defined file format (e.g.
report spread sheet, word processing, etc. as per desktop office solution)
BI07.F.5 Reporting tool System should support menu driven query and reporting tool
BI07.F.6 Saving of query System should allow users to save the query and ad hoc report generated
BI07.F.7 Joining of table System should be capable of self-join table more than once and use the self-joined tables
(database)
Section V. Requirements of the Information System 559

20 –MISCELLANEOUS (MISC)
ID ID Description

MISC. Miscellaneous
MISC.F.1 Avoiding double taxation The fiscal unit receives residency certificates and attestation of tax paid certificates
Fiscal Administration (using web services) receives a request on avoiding double taxation.
MISC.F.2 Automatic consultation The system should adaptable and to enable reception and international transmission (exchange) of
of international information regarding the documents used on the avoidance of double taxation, including the receipt of
databases. information.
MISC.F.3 Issuing certificates After verification, the system should capture the required data for the form and to automatically issue
certificates using the model form. Database with model forms should be constantly updated according to
legislation changes from avoidance of double taxation domain.
MISC.F.4 Notification taxpayer The system automatically notifies the taxpayer through SMS, E-mail or Private Area regarding the issue of
certificate
MISC.F.5 Posting the certificate in The system should automatically issue the required certificates and post them in the private space of the
requesting taxpayer applicant.
Private Area
MISC.F.6 Printable certificates The certificate should be sent to the applicant.

MISC.F.7 The tax residency They communicate using Web services at any changes appeared, that can bring changes to the tax residency
changing (arrival / departure from Romania) and including the provision and processing of information in the
database, including the standard documents issuing.

MISC.F.8 Issuing notices It automatically issues notifications regarding the conditions of tax residence.
MISC.F.9 Requesting taxpayer The system automatically notifies the taxpayer through SMS, E-mail (via CRM-IVR) or private spaces for
issuing the notification
MISC.F.10 Taxpayer notification in The system should automatically issue notifications and post them in the private space of the applicant.
Posting Private Space at
requesting taxpayer
MISC.F.11 Taxpayer assistance Receiving request
trough E-mail Requests are received via assistance from the NAFA website or directly by its Virtual Private Area
560 Section V. Requirements of the Information System

ID ID Description

MISC. Miscellaneous
MISC.F.12 Registration and The request is recorded and automatically distributed to tax administration where the applicant is fiscal
automatic allocation registered.
request
MISC.F.13 Transmission response The answer is transmitted through the application.
MISC.F.14 Redirecting request Redirecting request is sent automatically by the software application and send an automatic response to the
applicant.
MISC.F.15 Notification taxpayer The system automatically notifies the taxpayer through SMS, E-mail or private spaces for issuing the
notification
MISC.F.16 Taxpayer assistance Receiving request
trough written Requests are received by the tax administration in written format
correspondence
MISC.F.17 Registration and The request is recorded in the electronic management system documents and assigned a person to solve.
assignment of request
MISC.F.18 Registration of the The request will be recorded in the computer system by scanning document.
request in the informatics
system
MISC.F.19 Sending the answer The answer is scanned and sent to the applicant
MISC.F.20 Redirecting request Redirecting request is sent automatically by the software application to another fiscal body and the answer
to the applicant.
MISC.F.21 Taxpayer notification The system automatically notifies the taxpayer through SMS, E-mail or private spaces for issuing the
notification
MISC.F.22 Taxpayer assistance face Receiving taxpayers to tax administration headquarters
to face Queue management systems within tax administrations and all data held by them should integrated in a
RMS module to enable data extraction and monitoring of service for taxpayers in the real system through
integrated management system.
MISC.F.23 Call Center Integration of IVR System in RMS
Telephone
MISC.F.24 SMS System should allow for SMS and notification to be sent to taxpayers.
MISC.F.25 Authorizations Registration in the computer system of cash registers and maintaining their records, issuance of documents
Cash Register of specific activity (extraction protocols of fiscal memory at cash registers, issuance of the order number in
Section V. Requirements of the Information System 561

ID ID Description

MISC. Miscellaneous
the Register of fiscal electronic devices for taxi, etc.).
MISC.F.26 Checking the flow Creating a module on authorized warehouse keepers and entities who are performing gambling and
regarding authorized electronic data transmission to the requesting institutions.
warehouse keepers and
gambling
MISC.F.28 Lottery of the grocery Periodic lotteries used as incentives to improve the tax (VAT) collection in the small shops and small
bills commerce,
(fiscal receipts for Integration of the actual system in RMS.
purchases in small shops)
562 Section V. Requirements of the Information System

ANNEX 6: DATABASES FOR MIGRATION

A. Large databases
Related
applications / Centralized /
No Short description Name Technology Size M.U.
systems / decentralized
service
ANAF Electronic Archive (data mart in the ARHEL ARHEL / many Oracle 10g 25 TB Centralized
1 ANAF Data warehouse) others
Reporting System for ANAF (data mart in the DWANAF DWANAF / Oracle 10g, 17 TB Centralized
2 ANAF Data warehouse) many others OBIEE
Tax Return D394 (tax returns for services DW-DW394 D394, many Oracle 10g 10 TB Centralized
3
suppliers) other
IT System for the Management of the fiscal SIACF SIACF, SIAC, Oracle 10g, 5.4 TB Centralization in
obligations (SIAC) GOTHICA, Oracle 8, progress (on July
4 other Oracle 11i 2015, expected to
complete by Dec
2015)
ARTHEMIS Risk Management Information ARTHEMIS ARTHEMIS Oracle 11i, 1.8 TB Centralized
5
Database Oracle 10g
CONTABCR Tax payer accounting database CONTABCR CONTABCR, Oracle 11i 1.4 TB Centralized
6 other reporting
applications
DEDOC Tax returns and other documents DEDOC DEDOC, many Oracle 11i 1.8 TB Centralized
7 submitted electronically by the tax payers others
database
DECIMP Database to manage the tax returns DECIMP DECIMP, Oracle 11i 1 TB Centralized
8 from companies and other categories of tax DEDOC, other
payers
SAIVEN Database to manage the information SAIVEN GOTHICA, Oracle 11i 1.6 TB Centralized
9 regarding tax on income of the individuals SIACF, other
(one source of income - salaries)
Section V. Requirements of the Information System 563

A. Large databases
Related
applications / Centralized /
No Short description Name Technology Size M.U.
systems / decentralized
service
  Estimated TOTAL (TB) 65 TB
564 Section V. Requirements of the Information System

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
Specific documents of audit activity AUDIT Lotus 23 GB Centralized
Notes /
The application stores and manages specific Domino
1
audit documents. The users are authorized
persons from DG Internal Audit and DGFP
within the counties.
BILDEC application displays inconsistencies BILDEC Oracle 11g, 2.9 GB Centralized
between data from the annual financial Oracle RAC,
2
statements compared to those recorded in the other
returns.
Information System for activity Control of the CAMELEON - Onix, ACVILA, OBIEE, Other Oracle 11g, 220 GB Centralized
Financial Guard. To be replaced by ACVILA. Arhiva GF Oracle RAC,
The application is an integrated information other
system, for complex activity management of
the Financial Guard that covers most of the
activities of this institution. It is a flexible and
secure information system using various
sources of ANAF (general nomenclatures,
Onyx, identity management, register of legal
entities and individuals) and the existing
database of the Financial Guard. Programming
3 was executed in web-based technology which
implies that future operations can be executed
in real time. The reports reflect the situation to
date across the country. It has a high degree of
standardization, given the user guide and use
the same classification system nationwide,
leading to reports issued by the system that
accurately reflect the real situation. It contains
annual management module of objectives of
the institution and can be used in planning
daily activities at the commissioner and
divisional level.
Section V. Requirements of the Information System 565

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
Tax Record. CAZIER is a computerized CAZIER Oracle 11g, 16.5 GB Centralized
system for the management of taxpayers tax (ASISCAZ, Oracle RAC,
record. It provides assistance for attesting INTCAZ, other
bodies to edit the registration forms / update ELCAZ)
4
actions in the fiscal record. It manages the
registration forms and updating of the facts
which fall in the tax record received from
bodies such as.
Data base that collects and maintains data on CLIBANCI Many other Oracle 11g, 6.4 GB Centralized
5 bank customers and provide data to other Oracle RAC,
systems and other public institutions. other
The application allows generating links charts C-LYNX Many other Oracle 11g, 224 GB Centralized
between taxpayers based on D394 / D390 and Oracle RAC,
on other sources of information (ex .: Imports, other
6
ONRC) by setting the selection conditions (the
transaction percentage to the tax base, VAT,
transaction type, etc. )
Database with shareholders, associates and COMERT Many other Oracle 11g, 9 GB Centralized
7 managers of companies (with information from Oracle RAC,
the Register of Commerce). other
Archive of tax returns filed through the portal. DECLPORTAL DECLPORTAL, DEDOC Oracle 11g, 200 GB Centralized
Oracle RAC,
8 The application stores the tax returns filed other
through the portal and provides the flow
distribution ofthe statements to back-office.
National Electronic System, communication DECLSEN DECLSEN, SIAC, SIAD, Lotus 150 GB Decentralized
between the NAFA portal and the territorial VECTOR, TREZOR, NOMEN, Notes /
back office. all local / Domino
decentralizeapplications in client
9
The application allows transmission of the server technology
statements from SEN and portal to backoffice
and taking the backoffice answer to the portal.
It allows to resolve errors occurred.
566 Section V. Requirements of the Information System

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
Decisions of the Ministry of Public Finances, DECSEN None Lotus 9 GB Centralized
10 other legislation Notes /
Domino
The application contains the central database DWDECONT Oracle 11g, 140 GB Centralized
11 for VAT returns with negative amounts, with Oracle RAC,
reimbursement option. other
Key performance indicators for ANAF, DWIND MIS OBIEE DWRAC – 46 GB Centralized
customs and other (PRELIND) Oracle and
12 Oracle RAC
11g
(11.2.0.3)
The application is a management system of FmAsistenta None Lotus 2.4 GB Centralized
13 requests received through the assistance form Notes /
from the website www.anaf.ro. Domino
INFOPC - query system for information about INFOPC dwrac.fiscnet.ro DWRAC – 31 GB Centralized
taxpayers and tax audit preparation. It is used Oracle and
14 for services / departments within the business Oracle RAC
tax inspection and / or with control attributes 11g
on individuals or legal entities. (11.2.0.3)
General catalogues / lists / table of internal NOMEN All WEB and client0-server Oracle RAC 1 GB Centralized
coding (Nomenclature) (Oracle Forms and Reports) 11.2.0.3
15
applications -ORACENT
R
Fiscal certificates for Non-Residents NRZ_CER Oracle RAC 1 GB Centralized
16 11g
(11.2.0.4)
DWAIF is an area of centralized reports PHOENIX – SI PHOENIX DWRAC – 15 GB Centralized
according to the activity of fiscal inspection on Oracle and
17 legal entities (from PHOENIX database). The Oracle RAC
access of this area of reporting is made through 11g
the NAFA dashboard. (11.2.0.3)
Section V. Requirements of the Information System 567

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
PLA computer system addresses to Services / PLA – SI PLA-SI Oracle RAC 6 GB Centralized
departments of NAFA, DGFPs that carries the 11.2.0.3
corporate tax audit and corporate tax audit -ORACENT
activity from the county / regional Directions R
for Excise and Customs.

The main functions of this system is loading,

18 query, centralization and listing information on
the planning and implementation of actions in
fiscal inspection according to OPANAF
2225/2007.

It was redesigned in web technology and

integrated with the informatic system Phoenix.
Tax Payer Register - Individuals RCNG_PF All WEB and client-server DWRAC – 70 GB Centralized
(Oracle Forms and Reports) Oracle and
19 applications Oracle RAC
11g
(11.2.0.3)
Tax Payer Register - Companies RCNG_PJ All WEB and client-server DWRAC – 90 GB Centralized
(Oracle Forms and Reports) Oracle and
20 applications Oracle RAC
11g
(11.2.0.3)
Register for the applications for a new location REGSEDIU REGSEDIU Oracle 8.0.5, 5 GB Local /
for a company (directory of business (REGADRESE) Oracle decentralized
addresses) Forms and
21 Report, 240
local
instances, 1
central copy
Management of debtors to the state RESTANTE RESTANTE Oracle 8.0.5, 12 GB Local /
22 consolidated budget. (RESTANTE Oracle decentralized
568 Section V. Requirements of the Information System

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
FISCALE) Forms and
Report, 240
local
instances, 1
central copy
Risk Assessment System Administration SERADN / SERADN Oracle 8.0.5, 70 GB Local /
Negative Returns with reimbursement option. SERADA SERADA Oracle decentralized
Forms and
For each negative return of VAT with negative Report, 240
amounts, with reimbursement option (DNOR) local
is established a degree of risk: low, medium, instances, 1
high, according to the law (OMPF 263/2010); central copy
on standard negative individual (SIN),
semester calculated until 2010 and quarterly
23 since 2010, in the case of small taxpayers.

For taxpayers large, medium and exporters

with special scheme approved, the DNOR
analysis is based on the papers.

All information needed to illustrate solving a

DNOR can be found in BD SERADN:
compensation / refund notes, tax decisions,
delaying the settlement terms, etc.
Database for the management of administrative SIAD SIAD Oracle 8.0.5, 3 GB Local /
documents: docket post, car documents, etc. Oracle decentralized
Forms and
24 Report, 240
local
instances, 1
central copy
Documents Registration and Tracking System SIDOC SIDOC Oracle 8.0.5, 13 GB Local /
25 at the General Registry and secretariats level - Oracle decentralized
Section V. Requirements of the Information System 569

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
MFP and ANAF central level. The system is Forms and
based on the current organizational structure Report, 240
and registration numbers, internal numbers in local
the ranges allocated instances, 1
central copy
Database with information on complaints filed SOLCON SOLCON Lotus 12 GB Centralized
and decisions related solving the complaints Notes /
Domino
Appeals may be filed by large taxpayers, may
be directed against the acts issued by the tax
authorities of NAFA body, may challenge the
customs debt and excise, VAT and income tax
on non-resident, income tax, social
 
contributions, grants and subsidies, tax
facilities, etc.
The information stored can be viewed grouped
in several ways: grouped by subject or grouped
according to the type of act. It is possible to
group information by county where the
complaint was filed, or depending on body
found.
TAXA AUTO (Tax for Car Registration) TAXA_AUTO TAXA_AUTO Oracle 11g, 21 GB Centralized
26 Oracle RAC,
other
Database for the management of assessment TRIDENT TRIDENT Oracle 11g, 17 GB Centralized
documents of D088 statement (Statement on Oracle RAC,
27 own responsibility to assess the intention and other
ability to conduct economic operations
involving the actions in the VAT field.
EU VAT refund VATRefund VATRefund Oracle 10g, 180 GB Centralized
28 Oracle RAC,
other
29 Database with the coded information about the VECTOR VECTOR, SIAD, SIAC, SIACF, Oracle 8.0.5, 83 GB Local /
570 Section V. Requirements of the Information System

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
tax obligations and payment terms for each and (Vector fiscal) NOMEN, and many other Oracle decentralized
every tax payer. Forms and
Report, 240
local
instances, 1
central copy
30 Catalogs Database organized in IBM Content WEB_CODFIS WEB_CODFISC Oracle 124 GB Centralized
Manager and Oracle 10.2.0.1 - ORBC (CM), in C WEB_PUBNOMEN 10.2.0.1 -
four partitions of 89 GB, 33 GB, 1 GB and 1 WEBAFISBUNPRIVATE ORCB (CM)
GB respectively. WEBAFISBUNSECHESTRAT
E
WEBAFISSEDIU
WEBAGSPV
WEBANUNTACTEFISCALE
WEBCONCURSURI
WEBEDITPSPV
WEBENERGIE
WEBEVIDAVIZE
WEBEVIDPROC
WEBFMASIST
WEBFMSESIZARI
WEBINACTIV_REACTIV
WEBINREGD112PF
WEBINREGD112PJ
WEBINREGD112Reprezentant
WEBINREGSPV
WEBMON
WEBPATRIM
WEBPERISABILE
WEBPUBL
WEBRAPSPV
WEBREINNOIRE
WEBRESTANTE
WEBRESURSE
Section V. Requirements of the Information System 571

B. Medium size databases

Centralized /
N Related applications / M.U
Short description Name Technology Size decentralize
o systems / service .
d
WEBRGPITVA
WEBRGPITVAINCASARE
WEBRobotD112
WEBRSSMFP
WEBSMS
WEBTRAFIC
   
Estimated TOTAL (size on file system) in 1803. (less than 2
 
GB 2 GB TB)
   
572 Section V. Requirements of the Information System

C. Small databases
Related
Centralized /
No Short description Name applications / Technology Size M.U.
decentralized
systems / service
Tax Payer Assistance Information regarding ANAFI Lotus 22 MB Centralized
1
fiscal topics Notes/Domino
Documents and summons archive on pending CITARH Lotus 111 MB Centralized
files, for the lawsuits in which the MFP Notes/Domino
2
represents a party; older than 2003. It is used very
rarely.
Managing subpoenas and lawsuits pending in the CITER Lotus 800 MB Centralized
courts of the territory, where MFP is a party in Notes/Domino
3 the lawsuit; SIDOC interface, the application that
provides the unique registration number of
documents in the system. Is updated daily
Managing subpoenas and lawsuits pending in the CITMIN Lotus 1100 MB Centralized
courts of the territory, where MFP is a party in Notes/Domino
4 the lawsuit; SIDOC interface, the application that
provides the unique registration number of
documents in the system. Is updated daily
Archive for subpoenas registered at the General CITONOPROC Lotus 20 MB Centralized
Registry that were not taken by the Legal Notes/Domino
Department of MFP. The documents are
5
presented together after filing year after the
Issuer. Searching can be done after the number
given by the Registry.
Manage documents on the MFP party disputes. LITIGII Lotus 20 MB Centralized
6
Notes/Domino
Management of Bulletins received from the MB Lotus 20 MB Centralized
7
National Trade Register Office Notes/Domino
8 Database supporting the allocation of the VAT CODTVA Lotus 3.5 MB Centralized
codes. The application allows submission through Notes/Domino
the MFP-NAFA web portal of the requests for
checking the validity of registration codes for
VAT and for the identification data of persons
registered for VAT in other EU member states.
These requests are distributed to the county said
by the deponent as fiscal domicile. For each
Section V. Requirements of the Information System 573

C. Small databases
Related
Centralized /
No Short description Name applications / Technology Size M.U.
decentralized
systems / service
application is assigned a registration number
1234567 JJ-form-YYYY (ie AB-0000082-2007)
where:

JJ - auto code of the county where he was

assigned

- 1234567 - 7 digit number that is assigned

sequentially and it resets at the beginning of each
year

- YYYY - year in which the request is made.

At the base form is the submitted file sent by the

applicant of the information.
Application for management of programming CONDOR Oracle RAC 12 MB Centralized
9 activities for verification of personal tax situation 11.2.0.3
-ORACENTR
CONTRACT_NRZ application allows user CONTRACT_N Schema 500 MB Centralized
management and the requests processing for RZ(CONTR_NE CONTNER -
contracts with non-residents. REZ, Oracle RAC
10
Contractnrz) 11g (11.2.0.4)
CONTR_NEREZ application allows views of
lists / requests of contracts or statistical reports.
The application takes D400 reports of banks, DOBROUE Oracle 10i 300 MB Centralized
group and extract data and generate containers
11 about beneficiaries of the interest income, for EU
member states and associated states according
with dir. 48 / EC / 2003.
DWAIF is an area of centralized reports DWAIF DWAIF, Oracle 11g 65 MB Centralized
according to the activity of fiscal inspection on PHOENIX,
12 legal entities (from PHOENIX database). The Dashboard
access of this area of reporting is made through
the NAFA dashboard.
574 Section V. Requirements of the Information System

C. Small databases
Related
Centralized /
No Short description Name applications / Technology Size M.U.
decentralized
systems / service
The application is an informatic system for DWGFTC Oracle 11g 180 MB Centralized
viewing statistical reports / operative according to
the transportations made by the economic agents
13
in the intra-Community acquisitions field (based
on information taken from the application
TRAFIC_CONTROL).
Database INACTIVI stores information about the INACTIVI Oracle 10.2.0.1 600 MB Centralized
taxpayers and / or inactive / reactivated by the tax - ORCB (CM)
inspection activity - legal entities. Taxpayers -
14
legal entities - inactive / reactivated by the tax
inspection activity through publication in
OPANAF and / or MO (the Official Gazette).
The database stores information relating to MONS1001 Lotus 7 MB Centralized
declaration S1001. The application can be used Notes/Domino
15
by members of a group, depending on the
interests and rights of access granted.
Manage requests for assistance in recovery SIARC Oracle 11g 60 MB Centralized
16 received or transmitted from / to the competent
authorities of other EU Member States
(less than 4
 
Estimated TOTAL (TB) 3820.5 MB GB)
Section V. Requirements of the Information System 575

ANNEX 7: SELECTED ACRONYMS

Acronym Definition
API Application Programming Interface, in software
ANAF National Agency for Fiscal Administration, Romania, also called
NAFA
BI Business Intelligence
BPEL BPEL (Business Process Execution Language), is an executable
language for specifying actions within business processes with web
services
BPM Business Process Management
BPMN 2.0 Business Process Model and Notation (BPMN) is a graphical
representation for specifying business processes in a business process
model.
BPR Business Process Reengineering
CBT Computer Based Training material
COBIT Control Objectives for Information and Related Technologies
COTS Customized/Commercial Off The Shelf
CRM-IVR Customer Relationship Management (CRM ) – Interactive Voice
Recognition (IVR) – software component
CMS Case Management System
DGTI General Director of Information Technology (in Romanian “Directia
Generala de Tehnologia Informatiei”)
DGRCCB General Directorate for the Collection of the Budgetary Credits (in
Romanian “Direcţia Generală de Reglementare a Colectării Creanţelor
Bugetare”)
DGTAXUD European Commission Taxation and Customs Union
DM Data Migration Project
DMS Document Management System
DSS Decision Support System
DWDC Data Warehouse Data Center
EAI Enterprise Application Integration
EIS Executive Information System
ETL/ELT Extract, transform, load (ETL) / Extract, Load, Transform (ELT), in
databases
576 Section V. Requirements of the Information System

Acronym Definition
EU European Union
FMIS Financial Management Information System
GDP Gross Domestic Product
GDSRIC General Directorate for Strategy, Reform and International
Cooperation
GUI Graphical User Interface
ISACA Information Systems Audit and Control Association
ICT Information and Communications Technology
ICTD Information and Communications Technology Department
IFRS International Financial Reporting Standard
ILT Instructor Lead Training, is a measurement unit for training effort,
equivalent of 1 student x 1 day in class
INTRASTAT Intrastat is the system for collecting information and producing
statistics on the trade in goods between countries of the European
Union (EU)
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
IBRD International Bank for Reconstruction and Development
J2EE Java 2 Platform, Enterprise Edition
JDBC JDBC is a Java database connectivity technology (Java Standard
Edition platform) from Oracle Corporation. This technology is an API
for the Java programming language that defines how a client may
access a database
KPI Key Performance Indicator
METS Metadata Encoding and Transmission Standard
MOPF Ministry of Public Finance
MIS Management Information System – software component
NAFA National Agency for Fiscal Administration
ODBC Open Database Connectivity, a standard programming language
middleware API for accessing database management systems (DBMS).
ODS Open Data Sets
OLEDB Object Linking and Embedding Database, is an API designed by
Microsoft that allows accessing data from a variety of sources in a
uniform manner.
OLTP On Line Transaction Processing in data bases
Section V. Requirements of the Information System 577

Acronym Definition
ONIX IT application for the Human Resources function, used by ANAF
OOAD Object-Oriented Analysis and Design
O/RM Object-Relational Mapping
PDC Primary Data Center
PI Page Impressions (per period of time)
PIC Project Implementation Committee
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PMU Project Management Unit
PRINCE2 PRojects IN Controlled Environments 2
PRR Production Rule Representation, in software
QBE Query By Example, in data bases
RAMP Revenue Administration Modernization Project
RDBMS Relational Database Management System
RMS Revenue Management System
ROL Romanian Leu, the currency of Romania until July 1st, 2005, when it
was replaced by denomination of 10,000 ROL by 1 RON
RON Romanian New Leu, The currency of Romania (ISO 4217 code RON;
numeric code 946)
RTO Recovery Time Objective, in Disaster Recovery
RUP Rational Unified Process
SOA Service Oriented Architecture, in software
SBVR Semantics of Business Vocabulary and Business Rules, in software
SCORM Sharable Content Object Reference Model (SCORM) is a collection of
2004 standards and specifications for web-based electronic educational
technology (also called e-learning).
SDC Secondary Data Center
SLA Service Level Agreement
TREZOR IT application that manages the payments of the Romanian State
Treasury, including the payments of ANAF
TIN / PIN Tax Payer Identification Number / Provisory Identification Number
UML Unified Modeling Language
VoIP Voice over the Internet Protocol
XML Extensible Markup Language
578 Section V. Requirements of the Information System

Acronym Definition
PART 3: CONDITIONS OF CONTRACT AND CONTRACT FORMS 579

PART 3 – CONDITIONS OF
CONTRACT AND CONTRACT
FORMS
Section VI. General Conditions of Contract 581

SECTION VI. GENERAL CONDITIONS OF CONTRACT

Table of Clauses
A. Contract and Interpretation.........................................................................................581
1. Definitions...............................................................................................................581
2. Contract Documents................................................................................................588
3. Interpretation...........................................................................................................588
4. Notices....................................................................................................................591
5. Governing Law.......................................................................................................592
6. Fraud and Corruption..............................................................................................592
B. Subject Matter of Contract...........................................................................................593
7. Scope of the System................................................................................................593
8. Time for Commencement and Operational Acceptance.........................................594
9. Supplier’s Responsibilities......................................................................................594
10. Purchaser’s Responsibilities...................................................................................596
C. Payment...........................................................................................................................597
11. Contract Price..........................................................................................................597
12. Terms of Payment...................................................................................................598
13. Securities.................................................................................................................599
14. Taxes and Duties.....................................................................................................600
D. Intellectual Property......................................................................................................601
15. Copyright................................................................................................................601
16. Software License Agreements................................................................................602
17. Confidential Information........................................................................................603
E. Supply, Installation, Testing, Commissioning, and Acceptance of the System........605
18. Representatives.......................................................................................................605
19. Project Plan.............................................................................................................607
20. Subcontracting........................................................................................................608
21. Design and Engineering..........................................................................................609
22. Procurement, Delivery, and Transport....................................................................611
23. Product Upgrades....................................................................................................614
24. Implementation, Installation, and Other Services...................................................615
25. Inspections and Tests..............................................................................................615
26. Installation of the System........................................................................................616
27. Commissioning and Operational Acceptance.........................................................616
F. Guarantees and Liabilities.............................................................................................620
28. Operational Acceptance Time Guarantee...............................................................620
29. Defect Liability.......................................................................................................621
30. Functional Guarantees............................................................................................624
31. Intellectual Property Rights Warranty....................................................................624
32. Intellectual Property Rights Indemnity...................................................................625
33. Limitation of Liability.............................................................................................627
G. Risk Distribution............................................................................................................628
34. Transfer of Ownership............................................................................................628
582 Section VI. General Conditions of Contract

35. Care of the System..................................................................................................628

36. Loss of or Damage to Property; Accident or Injury to Workers; Indemnification
.................................................................................................................................630
37. Insurances...............................................................................................................631
38. Force Majeure.........................................................................................................633
H. Change in Contract Elements.......................................................................................635
39. Changes to the System............................................................................................635
40. Extension of Time for Achieving Operational Acceptance....................................638
41. Termination.............................................................................................................639
42. Assignment.............................................................................................................646
I. Settlement of Disputes.....................................................................................................646
43. Settlement of Disputes............................................................................................646
Section VI. General Conditions of Contract 583

General Conditions of Contract

A. CONTRACT AND INTERPRETATION

1. Definitions 1.1 In this Contract, the following terms should be interpreted
as indicated below.
(a) contract elements
(i) “Contract” means the Contract Agreement
entered into between the Purchaser and the
Supplier, together with the Contract Documents
referred to therein. The Contract Agreement and
the Contract Documents should constitute the
Contract, and the term “the Contract” should in
all such documents be construed accordingly.
(ii) “Contract Documents” means the documents
specified in Article 1.1 (Contract Documents) of
the Contract Agreement (including any
amendments to these Documents).
(iii) “Contract Agreement” means the agreement
entered into between the Purchaser and the
Supplier using the form of Contract Agreement
contained in the Sample Contractual Forms
Section of the Bidding Documents and any
modifications to this form agreed to by the
Purchaser and the Supplier. The date of the
Contract Agreement should be recorded in the
signed form.
(iv) “GCC” means the General Conditions of
Contract.
(v) “SCC” means the Special Conditions of
Contract.
(vi) “Technical Requirements” means the Technical
Requirements in Section V of the Bidding
Documents.
(vii) “Implementation Schedule” means the
Implementation Schedule in Section V of the
Bidding Documents.
viii) “Contract Price” means the price or prices
defined in Article 2 (Contract Price and Terms
of Payment) of the Contract Agreement.
(ix) “Procurement Guidelines” refers to the edition
specified in the SCC of the World Bank
584 Section VI. General Conditions of Contract

Guidelines: Procurement under IBRD Loans and

IDA Credits.
(x) “Bidding Documents” refers to the collection of
documents issued by the Purchaser to instruct
and inform potential suppliers of the processes
for bidding, selection of the winning bid, and
Contract formation, as well as the contractual
conditions governing the relationship between
the Purchaser and the Supplier. The General and
Special Conditions of Contract, the Technical
Requirements, and all other documents included
in the Bidding Documents reflect the
Procurement Guidelines that the Purchaser is
obligated to follow during procurement and
administration of this Contract.
(b) entities
(i) “Purchaser” means the entity purchasing the
Information System, as specified in the SCC.
(ii) “Project Manager” means the person named as
such in the SCC or otherwise appointed by the
Purchaser in the manner provided in GCC
Clause 18.1 (Project Manager) to perform the
duties delegated by the Purchaser.
(iii) “Supplier” means the firm or Joint Venture
whose bid to perform the Contract has been
accepted by the Purchaser and is named as such
in the Contract Agreement.
(iv) “Supplier’s Representative” means any person
nominated by the Supplier and named as such in
the Contract Agreement or otherwise approved
by the Purchaser in the manner provided in GCC
Clause 18.2 (Supplier’s Representative) to
perform the duties delegated by the Supplier.
(v) “Subcontractor” means any firm to whom any of
the obligations of the Supplier, including
preparation of any design or supply of any
Information Technologies or other Goods or
Services, is subcontracted directly or indirectly
by the Supplier.
(vi) “Adjudicator” means the person named in
Appendix 2 of the Contract Agreement,
appointed by agreement between the Purchaser
and the Supplier to make a decision on or to
settle any dispute between the Purchaser and the
Section VI. General Conditions of Contract 585

Supplier referred to him or her by the parties,

pursuant to GCC Clause 43.1 (Adjudication).
(vii) “The World Bank” (also called “The Bank”)
means the International Bank for Reconstruction
and Development (IBRD) or the International
Development Association (IDA).
(c) scope
(i) “Information System,” also called “the System,”
means all the Information Technologies,
Materials, and other Goods to be supplied,
installed, integrated, and made operational
(exclusive of the Supplier’s Equipment),
together with the Services to be carried out by
the Supplier under the Contract.
(ii) “Subsystem” means any subset of the System
identified as such in the Contract that may be
supplied, installed, tested, and commissioned
individually before Commissioning of the
entire System. As appropriate, specific
Subsystems are defined in the Technical
Requirements (including the Implementation
Schedule, System Inventory Tables), Price
Schedules, Agreed Project Plan, and/or
Contract amendments.
(iii) “Information Technologies” means all
information processing and communications-
related hardware, Software, supplies, and
consumable items that the Supplier is required
to supply and install under the Contract.
(iv) “Goods” means all equipment, machinery,
furnishings, Materials, and other tangible items
that the Supplier is required to supply or supply
and install under the Contract, including,
without limitation, the Information
Technologies and Materials, but excluding the
Supplier’s Equipment.
(v) “Services” means all technical, logistical,
management, and any other Services to be
provided by the Supplier under the Contract to
supply, install, customize, integrate, and make
operational the System. Such Services may
include, but are not restricted to, activity
management and quality assurance, design,
development, customization, documentation,
transportation, insurance, inspection,
586 Section VI. General Conditions of Contract

expediting, site preparation, installation,

integration, training, data migration, Pre-
commissioning, Commissioning, maintenance,
and technical support.
(vi) “The Project Plan” means the document to be
developed by the Supplier and approved by the
Purchaser, pursuant to GCC Clause 19, based
on the requirements of the Contract and the
Preliminary Project Plan included in the
Supplier’s bid. The “Agreed Project Plan” is
the version of the Project Plan approved by the
Purchaser, in accordance with GCC
Clause 19.2. Should the Project Plan conflict
with the Contract in any way, the relevant
provisions of the Contract, including any
amendments, should prevail.
(vii) “Software” means that part of the System
which are instructions that cause information
processing Subsystems to perform in a specific
manner or execute specific operations.
(viii) “System Software” means Software that provides
the operating and management instructions for
the underlying hardware and other components,
and is identified as such in Appendix 4 of the
Contract Agreement and such other Software as
the parties may agree in writing to be Systems
Software. Such System Software includes, but is
not restricted to, micro-code embedded in
hardware (i.e., “firmware”), operating systems,
communications, system and network
management, and utility software.
(ix) “General-Purpose Software” means Software
that supports general-purpose office and
software development activities and is
identified as such in Appendix 4 of the Contract
Agreement and such other Software as the
parties may agree in writing to be General-
Purpose Software. Such General-Purpose
Software may include, but is not restricted to,
word processing, spreadsheet, generic database
management, and application development
software.
(x) “Application Software” means Software
formulated to perform specific business or
technical functions and interface with the
business or technical users of the System and is
Section VI. General Conditions of Contract 587

identified as such in Appendix 4 of the Contract

Agreement and such other Software as the
parties may agree in writing to be Application
Software.
(xi) “Standard Software” means Software identified
as such in Appendix 4 of the Contract
Agreement and such other Software as the
parties may agree in writing to be Standard
Software.
(xii) “Custom Software” means Software identified as
such in Appendix 4 of the Contract Agreement
and such other Software as the parties may agree
in writing to be Custom Software.
(xiii) “Source Code” means the database structures,
dictionaries, definitions, program source files,
and any other symbolic representations
necessary for the compilation, execution, and
subsequent maintenance of the Software
(typically, but not exclusively, required for
Custom Software).
(xiv) “Materials” means all documentation in printed
or printable form and all instructional and
informational aides in any form (including
audio, video, and text) and on any medium,
provided to the Purchaser under the Contract.
(xv) “Standard Materials” means all Materials not
specified as Custom Materials.
(xvi) “Custom Materials” means Materials developed
by the Supplier at the Purchaser’s expense under
the Contract and identified as such in Appendix 5
of the Contract Agreement and such other
Materials as the parties may agree in writing to be
Custom Materials. Custom Materials includes
Materials created from Standard Materials.
(xvii) “Intellectual Property Rights” means any and
all copyright, moral rights, trademark, patent,
and other intellectual and proprietary rights,
title and interests worldwide, whether vested,
contingent, or future, including without
limitation all economic rights and all exclusive
rights to reproduce, fix, adapt, modify,
translate, create derivative works from, extract
or re-utilize data from, manufacture, introduce
into circulation, publish, distribute, sell, license,
sublicense, transfer, rent, lease, transmit or
588 Section VI. General Conditions of Contract

provide access electronically, broadcast,

display, enter into computer memory, or
otherwise use any portion or copy, in whole or
in part, in any form, directly or indirectly, or to
authorize or assign others to do so.
(xviii) “Supplier’s Equipment” means all equipment,
tools, apparatus, or things of every kind
required in or for installation, completion and
maintenance of the System that are to be
provided by the Supplier, but excluding the
Information Technologies, or other items
forming part of the System.
(d) activities
(i) “Delivery” means the transfer of the Goods from
the Supplier to the Purchaser in accordance with
the current edition Incoterms specified in the
Contract.
(ii) “Installation” means that the System or a
Subsystem as specified in the Contract is ready
for Commissioning as provided in GCC Clause
26 (Installation).
(iii) “Pre-commissioning” means the testing, checking,
and any other required activity that may be
specified in the Technical Requirements that are to
be carried out by the Supplier in preparation for
Commissioning of the System as provided in GCC
Clause 26 (Installation).
(iv) “Commissioning” means operation of the
System or any Subsystem by the Supplier
following Installation, which operation is to be
carried out by the Supplier as provided in GCC
Clause 27.1 (Commissioning), for the purpose of
carrying out Operational Acceptance Test(s).
(v) “Operational Acceptance Tests” means the tests
specified in the Technical Requirements and
Agreed Project Plan to be carried out to ascertain
whether the System, or a specified Subsystem, is
able to attain the functional and performance
requirements specified in the Technical
Requirements and Agreed Project Plan, in
accordance with the provisions of GCC Clause
27.2 (Operational Acceptance Test).
(vi) “Operational Acceptance” means the acceptance
by the Purchaser of the System (or any
Section VI. General Conditions of Contract 589

Subsystem(s) where the Contract provides for

acceptance of the System in parts), in
accordance with GCC Clause 27.3 (Operational
Acceptance).
(e) place and time
(i) “Purchaser’s Country” is the country named in
the SCC.
(ii) “Supplier’s Country” is the country in which the
Supplier is legally organized, as named in the
Contract Agreement.
(iii) Unless otherwise specified in the SCC “Project
Site(s)” means the place(s) in the Site Table in
the Technical Requirements Section for the
supply and installation of the System.
(iv) “Eligible Country” means the countries and
territories eligible for participation in
procurements financed by the World Bank as
defined in the Procurement Guidelines.
(v) “Day” means calendar day of the Gregorian
Calendar.
(vi) “Week” means seven (7) consecutive Days,
beginning the day of the week as is customary in
the Purchaser’s Country.
(vii) “Month” means calendar month of the Gregorian
Calendar.
(viii) “Year” means twelve (12) consecutive Months.
(ix) “Effective Date” means the date of fulfillment of
all conditions specified in Article 3 (Effective
Date for Determining Time for Achieving
Operational Acceptance) of the Contract
Agreement, for the purpose of determining the
Delivery, Installation, and Operational
Acceptance dates for the System or
Subsystem(s).
(x) “Contract Period” is the time period during
which this Contract governs the relations and
obligations of the Purchaser and Supplier in
relation to the System, as unless otherwise
specified in the SCC, the Contract should
continue in force until the Information System
and all the Services have been provided, unless
the Contract is terminated earlier in accordance
590 Section VI. General Conditions of Contract

with the terms set out in the Contract.

(xi) “Defect Liability Period” (also referred to as the
“Warranty Period”) means the period of validity
of the warranties given by the Supplier
commencing at date of the Operational
Acceptance Certificate of the System or
Subsystem(s), during which the Supplier is
responsible for defects with respect to the
System (or the relevant Subsystem[s]) as
provided in GCC Clause 29 (Defect Liability).
(xii) “The Coverage Period” means the Days of the
Week and the hours of those Days during which
maintenance, operational, and/or technical
support services (if any) must be available.
2. Contract 2.1 Subject to Article 1.2 (Order of Precedence) of the Contract
Documents Agreement, all documents forming part of the Contract (and
all parts of these documents) are intended to be correlative,
complementary, and mutually explanatory. The Contract
should be read as a whole.
3. Interpretation 3.1 Governing Language
3.1.1 Unless otherwise specified in the SCC, all Contract
Documents and related correspondence exchanged
between Purchaser and Supplier should be written in
the language of these bidding documents (English),
and the Contract should be construed and interpreted
in accordance with that language.
3.1.2 If any of the Contract Documents or related
correspondence are prepared in a language other than
the governing language under GCC Clause 3.1.1
above, the translation of such documents into the
governing language should prevail in matters of
interpretation. The originating party, with respect to
such documents should bear the costs and risks of
such translation.
3.2 Singular and Plural
The singular should include the plural and the plural the
singular, except where the context otherwise requires.
3.3 Headings
The headings and marginal notes in the GCC are included
for ease of reference and should neither constitute a part of
the Contract nor affect its interpretation.
Section VI. General Conditions of Contract 591

3.4 Persons
Words importing persons or parties should include firms,
corporations, and government entities.
3.5 Incoterms
Unless inconsistent with any provision of the Contract, the
meaning of any trade term and the rights and obligations of
parties thereunder should be as prescribed by the current
Incoterms (“Incoterms 2000” or a more recent version if
and as published). Incoterms are the international rules for
interpreting trade terms published by the International
Chamber of Commerce, 38 Cours Albert 1er, 75008 Paris,
France.
3.6 Entire Agreement
The Contract constitutes the entire agreement between the
Purchaser and Supplier with respect to the subject matter of
Contract and supersedes all communications, negotiations,
and agreements (whether written or oral) of parties with
respect to the subject matter of the Contract made prior to
the date of Contract.
3.7 Amendment
No amendment or other variation of the Contract should be
effective unless it is in writing, is dated, expressly refers to
the Contract, and is signed by a duly authorized
representative of each party to the Contract.
3.8 Independent Supplier
The Supplier should be an independent contractor
performing the Contract. The Contract does not create any
agency, partnership, joint venture, or other joint relationship
between the parties to the Contract.
Subject to the provisions of the Contract, the Supplier
should be solely responsible for the manner in which the
Contract is performed. All employees, representatives, or
Subcontractors engaged by the Supplier in connection with
the performance of the Contract should be under the
complete control of the Supplier and should not be deemed
to be employees of the Purchaser, and nothing contained in
the Contract or in any subcontract awarded by the Supplier
should be construed to create any contractual relationship
between any such employees, representatives, or
Subcontractors and the Purchaser.
3.9 Joint Venture
592 Section VI. General Conditions of Contract

If the Supplier is a Joint Venture of two or more firms, all

such firms should be jointly and severally bound to the
Purchaser for the fulfillment of the provisions of the
Contract and should designate one of such firms to act as a
leader with authority to bind the Joint Venture. The
composition or constitution of the Joint Venture should not
be altered without the prior consent of the Purchaser.
3.10 Nonwaiver
3.10.1 Subject to GCC Clause 3.10.2 below, no relaxation,
forbearance, delay, or indulgence by either party in
enforcing any of the terms and conditions of the
Contract or the granting of time by either party to
the other should prejudice, affect, or restrict the
rights of that party under the Contract, nor should
any waiver by either party of any breach of Contract
operate as waiver of any subsequent or continuing
breach of Contract.
3.10.2 Any waiver of a party’s rights, powers, or remedies
under the Contract must be in writing, must be dated
and signed by an authorized representative of the
party granting such waiver, and must specify the
right and the extent to which it is being waived.
3.11 Severability
If any provision or condition of the Contract is prohibited or
rendered invalid or unenforceable, such prohibition,
invalidity, or unenforceability should not affect the validity
or enforceability of any other provisions and conditions of
the Contract.
3.12 Country of Origin
“Origin” means the place where the Information
Technologies, Materials, and other Goods for the System
were produced or from which the Services are supplied.
Goods are produced when, through manufacturing,
processing, Software development, or substantial and major
assembly or integration of components, a commercially
recognized product results that is substantially different in
basic characteristics or in purpose or utility from its
components. The Origin of Goods and Services is distinct
from the nationality of the Supplier and may be different.
Section VI. General Conditions of Contract 593

4. Notices 4.1 Unless otherwise stated in the Contract, all notices to be

given under the Contract should be in writing and should be
sent, pursuant to GCC Clause 4.3 below, by personal
delivery, airmail post, special courier, facsimile, electronic
mail, or Electronic Data Interchange (EDI), with the
following provisions.
4.1.1 Any notice sent by facsimile, electronic mail, or EDI
should be confirmed within two (2) days after
dispatch by notice sent by airmail post or special
courier, except as otherwise specified in the Contract.
4.1.2 Any notice sent by airmail post or special courier
should be deemed (in the absence of evidence of
earlier receipt) to have been delivered ten (10) days
after dispatch. In proving the fact of dispatch, it
should be sufficient to show that the envelope
containing such notice was properly addressed,
stamped, and conveyed to the postal authorities or
courier service for transmission by airmail or special
courier.
4.1.3 Any notice delivered personally or sent by facsimile,
electronic mail, or EDI should be deemed to have
been delivered on the date of its dispatch.
4.1.4 Either party may change its postal, facsimile,
electronic mail, or EDI addresses for receipt of such
notices by ten (10) days’ notice to the other party in
writing.
4.2 Notices should be deemed to include any approvals,
consents, instructions, orders, certificates, information and
other communication to be given under the Contract.
4.3 Pursuant to GCC Clause 18, notices from/to the Purchaser
are normally given by, or addressed to, the Project
Manager, while notices from/to the Supplier are normally
given by, or addressed to, the Supplier's Representative, or
in its absence its deputy if any. If there is no appointed
Project Manager or Supplier's Representative (or deputy),
or if their related authority is limited by the SCC for GCC
Clauses 18.1 or 18.2.2, or for any other reason, the
Purchaser or Supplier may give and receive notices at their
fallback addresses. The address of the Project Manager and
the fallback address of the Purchaser are as specified in the
SCC or as subsequently established/amended. The address
of the Supplier's Representative and the fallback address of
the Supplier are as specified in Appendix 1 of the Contract
Agreement or as subsequently established/amended.
594 Section VI. General Conditions of Contract

5. Governing Law 5.1 The Contract should be governed by and interpreted in

accordance with the laws of the country specified in the
SCC.
6. Fraud and 6.1 If the Purchaser determines that the Supplier and/or any of
Corruption its personnel, or its agents, or its Subcontractors,
subconsultants, services providers, suppliers and/or their
employees has engaged in corrupt, fraudulent, collusive
coercive, or obstructive practices, in competing for or in
executing the Contract, then the Purchaser may, after giving
14 days notice to the Supplier, terminate the Supplier’s
employment under the Contract and cancel the Contract, and
the provisions of GCC Clause 41 shall apply as if such
expulsion had been made under GCCSub-Clause 41.2.1 (c).
For the purposes of this Sub-Clause,
(i) “corrupt practice” is the offering, giving, receiving
or soliciting, directly or indirectly, of anything of
value to influence improperly the actions of
another party1;
(ii) “fraudulent practice” is any act or omission,
including a misrepresentation, that knowingly or
recklessly misleads, or attempts to mislead, a party
to obtain a financial or other benefit or to avoid an
obligation2;
(iii) “collusive practice” is an arrangement between
two or more parties3 designed to achieve an
improper purpose, including to influence
improperly the actions of another party;
(iv) “coercive practice” is impairing or harming, or
threatening to impair or harm, directly or
indirectly, any party or the property of the party to
influence improperly the actions of a party4;
(v) “obstructive practice "is
(aa) deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
1
“Another party” refers to a public official acting in relation to the procurement process or contract
execution]. In this context, “public official” includes World Bank staff and employees of other
organizations taking or reviewing procurement decisions.
2
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement
process or contract execution; and the “act or omission” is intended to influence the procurement
process or contract execution.
3
“Parties” refers to participants in the procurement process (including public officials) attempting to
establish bid prices at artificial, non competitive levels.
4
“Party” refers to a participant in the procurement process or contract execution.
Section VI. General Conditions of Contract 595

investigators in order to materially impede a

Bank investigation into allegations of a
corrupt, fraudulent, coercive or collusive
practice; and/or threatening, harassing or
intimidating any party to prevent it from
disclosing its knowledge of matters relevant
to the investigation or from pursuing the
investigation, or
(bb) acts intended to materially impede the
exercise of the Bank’s inspection and audit
rights provided for under GCCSub-Clause
9.8.
Should any employee of the Supplier be
determined to have engaged in corrupt,
fraudulent, collusive, coercive, or obstructive
practice during the purchase of the Goods,
then that employee shall be removed.

B. SUBJECT MATTER OF CONTRACT

7. Scope of the 7.1 Unless otherwise expressly limited in the SCC or Technical
System Requirements, the Supplier’s obligations cover the provision
of all Information Technologies, Materials and other Goods
as well as the performance of all Services required for the
design, development, and implementation (including
procurement, quality assurance, assembly, associated site
preparation, Delivery, Pre-commissioning, Installation,
Testing, and Commissioning) of the System, in accordance
with the plans, procedures, specifications, drawings, codes,
and any other documents specified in the Contract and the
Agreed Project Plan.
7.2 The Supplier should, unless specifically excluded in the
Contract, perform all such work and / or supply all such
items and Materials not specifically mentioned in the
Contract but that can be reasonably inferred from the
Contract as being required for attaining Operational
Acceptance of the System as if such work and / or items and
Materials were expressly mentioned in the Contract.
7.3 The Supplier’s obligations (if any) to provide Goods and
Services as implied by the Recurrent Cost tables of the
Supplier’s bid, such as consumables, spare parts, and
technical services (e.g., maintenance, technical assistance,
and operational support), are as specified in the
SCC,including the relevant terms, characteristics, and
timings.
596 Section VI. General Conditions of Contract

8. Time for 8.1 The Supplier should commence work on the System within
Commencement the period specified in the SCC, and without prejudice to
and Operational GCC Clause 28.2, the Supplier should thereafter proceed
Acceptance with the System in accordance with the time schedule
specified in the Implementation Schedule and any
refinements made in the Agreed Project Plan.
8.2 The Supplier should achieve Operational Acceptance of the
System (or Subsystem(s) where a separate time for
Operational Acceptance of such Subsystem(s) is specified in
the Contract) in accordance with the time schedule specified
in the Implementation Schedule and any refinements made in
the Agreed Project Plan, or within such extended time to
which the Supplier should be entitled under GCC Clause 40
(Extension of Time for Achieving Operational Acceptance).
9. Supplier’s 9.1 The Supplier should conduct all activities with due care and
Responsibilities diligence, in accordance with the Contract and with the skill
and care expected of a competent provider of information
technologies, information systems, support, maintenance,
training, and other related services, or in accordance with
best industry practices. In particular, the Supplier should
provide and employ only technical personnel who are skilled
and experienced in their respective callings and supervisory
staff who are competent to adequately supervise the work at
hand.
9.2 The Supplier confirms that it has entered into this Contract
on the basis of a proper examination of the data relating to
the System provided by the Purchaser and on the basis of
information that the Supplier could have obtained from a
visual inspection of the site (if access to the site was
available) and of other data readily available to the Supplier
relating to the System as at the date twenty-eight (28) days
prior to bid submission. The Supplier acknowledges that any
failure to acquaint itself with all such data and information
should not relieve its responsibility for properly estimating
the difficulty or cost of successfully performing the Contract.
9.3 The Supplier should be responsible for timely provision of
all resources, information, and decision making under its
control that are necessary to reach a mutually Agreed Project
Plan (pursuant to GCC Clause 19.2) within the time schedule
specified in the Implementation Schedule. Failure to provide
such resources, information, and decision-making may
constitute grounds for termination pursuant to GCC
Clause 41.2.
9.4 The Supplier should acquire in its name all permits,
approvals, and/or licenses from all local, state, or national
government authorities or public service undertakings in the
Section VI. General Conditions of Contract 597

Purchaser’s Country that are necessary for the performance

of the Contract, including, without limitation, visas for the
Supplier’s and Subcontractor’s personnel and entry permits
for all imported Supplier’s Equipment. The Supplier should
acquire all other permits, approvals, and/or licenses that are
not the responsibility of the Purchaser under GCC
Clause 10.4 and that are necessary for the performance of the
Contract.
9.5 The Supplier should comply with all laws in force in the
Purchaser’s Country. The laws will include all national,
provincial, municipal, or other laws that affect the
performance of the Contract and are binding upon the
Supplier. The Supplier should indemnify and hold harmless
the Purchaser from and against any and all liabilities,
damages, claims, fines, penalties, and expenses of whatever
nature arising or resulting from the violation of such laws by
the Supplier or its personnel, including the Subcontractors
and their personnel, but without prejudice to GCC
Clause 10.1. The Supplier should not indemnify the
Purchaser to the extent that such liability, damage, claims,
fines, penalties, and expenses were caused or contributed to
by a fault of the Purchaser.
9.6 The Supplier should, in all dealings with its labor and the
labor of its Subcontractors currently employed on or
connected with the Contract, pay due regard to all recognized
festivals, official holidays, religious or other customs, and all
local laws and regulations pertaining to the employment of
labor.
9.7 Any Information Technologies or other Goods and Services
that will be incorporated in or be required for the System and
other supplies should have their Origin, as defined in GCC
Clause 3.12, in a country that should be an Eligible Country,
as defined in GCC Clause 1.1 (e) (iv).
9.8 The Supplier shall permit, and shall cause its Subcontractors
and consultants to permit, the Bank and/or persons appointed
by the Bank to inspect the Supplier’s offices andall accounts
and records relating to the performance of the Contract and
the submission of the bid, and to have such accounts and
records audited by auditors appointed by the Bank if
requested by the Bank. The Supplier’sand its Subcontractors
and consultants’attention is drawn to GCCSub-Clause
41.2.1(c), which provides, inter alia, that acts intended to
materially impede the exercise of the Bank’s inspection and
audit rights provided for under this GCCSub-Clause
9.8constitute a prohibited practice subject to contract
termination (as well as to a determination of ineligibility
598 Section VI. General Conditions of Contract

pursuant to the Bank’s prevailing sanctions procedures).

9.9 Unless otherwise specified in the SCC the Supplier should
have no other Supplier responsibilities.
10. Purchaser’s 10.1 The Purchaser should ensure the accuracy of all information
Responsibilities and/or data to be supplied by the Purchaser to the Supplier,
except when otherwise expressly stated in the Contract.
10.2 The Purchaser should be responsible for timely provision of
all resources, information, and decision making under its
control that are necessary to reach an Agreed Project Plan
(pursuant to GCC Clause 19.2) within the time schedule
specified in the Implementation Schedule. Failure to provide
such resources, information, and decision making may
constitute grounds for Termination pursuant to GCC
Clause 41.3.1 (b).
10.3 The Purchaser should be responsible for acquiring and
providing legal and physical possession of the site and access to
it, and for providing possession of and access to all other areas
reasonably required for the proper execution of the Contract.
10.4 If requested by the Supplier, the Purchaser should use its best
endeavors to assist the Supplier in obtaining in a timely and
expeditious manner all permits, approvals, and/or licenses
necessary for the execution of the Contract from all local,
state, or national government authorities or public service
undertakings that such authorities or undertakings require the
Supplier or Subcontractors or the personnel of the Supplier
or Subcontractors, as the case may be, to obtain.
10.5 In such cases where the responsibilities of specifying and
acquiring or upgrading telecommunications and/or electric
power services falls to the Supplier, as specified in the
Technical Requirements, SCC, Agreed Project Plan, or other
parts of the Contract, the Purchaser should use its best
endeavors to assist the Supplier in obtaining such services in
a timely and expeditious manner.
10.6 The Purchaser should be responsible for timely provision of
all resources, access, and information necessary for the
Installation and Operational Acceptance of the System
(including, but not limited to, any required
telecommunications or electric power services), as identified
in the Agreed Project Plan, except where provision of such
items is explicitly identified in the Contract as being the
responsibility of the Supplier. Delay by the Purchaser may
result in an appropriate extension of the Time for
Operational Acceptance, at the Supplier’s discretion.
10.7 Unless otherwise specified in the Contract or agreed upon by
Section VI. General Conditions of Contract 599

the Purchaser and the Supplier, the Purchaser should provide

sufficient, properly qualified operating and technical
personnel, as required by the Supplier to properly carry out
Delivery, Pre-commissioning, Installation, Commissioning,
and Operational Acceptance, at or before the time specified
in the Implementation Schedule and the Agreed Project Plan.
10.8 The Purchaser will designate appropriate staff for the
training courses to be given by the Supplier and should make
all appropriate logistical arrangements for such training as
specified in the Technical Requirements, SCC, the Agreed
Project Plan, or other parts of the Contract.
10.9 The Purchaser assumes primary responsibility for the
Operational Acceptance Test(s) for the System, in
accordance with GCC Clause 27.2, and should be
responsible for the continued operation of the System after
Operational Acceptance. However, this should not limit in
any way the Supplier’s responsibilities after the date of
Operational Acceptance otherwise specified in the Contract.
10.10 The Purchaser is responsible for performing and safely
storing timely and regular backups of its data and Software
in accordance with accepted data management principles,
except where such responsibility is clearly assigned to the
Supplier elsewhere in the Contract.
10.11 All costs and expenses involved in the performance of the
obligations under this GCC Clause 10 should be the
responsibility of the Purchaser, save those to be incurred by
the Supplier with respect to the performance of the
Operational Acceptance Test(s), in accordance with GCC
Clause 27.2.
10.12 Unless otherwise specified in the SCC the Purchaser
should have no other Purchaser responsibilities.

C. PAYMENT
11. Contract Price 11.1 The Contract Price should be as specified in Article 2
(Contract Price and Terms of Payment) of the Contract
Agreement.
11.2 The Contract Price should be a firm lump sum not subject to
any alteration, except:
(a) in the event of a Change in the System pursuant to
GCC Clause 39 or to other clauses in the Contract;
(b) theprice adjustment formula specified in the SCC (if
any). However, unless otherwise specified in the
600 Section VI. General Conditions of Contract

SCC there will NOT be a price adjustment formula.

11.3 The Supplier should be deemed to have satisfied itself as to
the correctness and sufficiency of the Contract Price, which
should, except as otherwise provided for in the Contract,
cover all its obligations under the Contract.
12. Terms of 12.1 The Supplier’s request for payment should be made to the
Payment Purchaser in writing. This should include, as relevant and
appropriate: an invoice describing the System or
Subsystem(s) Delivered, Installed, and/or Operationally
Accepted; documents submitted pursuant to GCC Clause
22.5;copies of the relevant Installation and/or Operational
Acceptance Certificates; documents establishing the
fulfillment of any other relevantobligations stipulated in the
Contract.
The Contract Price should be paid as specified in the SCC.
12.2 Installation and Operational Acceptance are governed by
GCC Clauses 26 and 27. No payment made by the Purchaser
herein – in the absence of relevant certificates –should be
deemed to constitute acceptance by the Purchaser of the
System or any Subsystem(s).
12.3 Payments should be made promptly by the Purchaser, but in
no case later than forty-five (45) days after submission of a
valid invoice by the Supplier. In the event that the Purchaser
fails to make any payment by its respective due date or
within the period set forth in the Contract, the Purchaser
should pay to the Supplier interest on the amount of such
delayed payment at the rate(s) specified in the SCC for the
period of delay until payment has been made in full, whether
before or after judgment or arbitration award.
12.4 Payments should be made in the currency(ies) specified in
the Contract Agreement, pursuant to GCC Clause 11. For
Goods and Services supplied locally, payments should be
made as specified in the SCC.
12.5 Unless otherwise specified in the SCC, payment of the
foreign currency portion of the Contract Price for Goods
supplied from outside the Purchaser’s Country should be
made to the Supplier through an irrevocable letter of credit
opened by an authorized bank in the Supplier’s Country and
will be payable on presentation of the appropriate
documents. It is agreed that the letter of credit will be
subject to Article 10 of the latest revision of Uniform
Customs and Practice for Documentary Credits, published
by the International Chamber of Commerce, Paris.
Section VI. General Conditions of Contract 601

13. Securities 13.1 Issuance of Securities

The Supplier should provide the securities specified below in
favor of the Purchaser at the times and in the amount,
manner, and form specified below.
13.2 Advance Payment Security
13.2.1 The Supplier should provide within twenty-eight (28)
days of the notification of Contract award an Advance
Payment Security in the amount and currency of the
Advance Payment specified in SCC for GCC Clause
12.1 above and valid until the System is Operationally
Accepted.
13.2.2 The security should be in the form provided in the
Bidding Documents or in another form acceptable to
the Purchaser. The amount of the security should be
reduced in proportion to the value of the System
executed by and paid to the Supplier from time to time
and should automatically become null and void when
the full amount of the advance payment has been
recovered by the Purchaser. Unless otherwise
specified in the SCC, the reduction in value and
expiration of the Advance Payment Security are
calculated as follows:
P*a/(100-a), where “P” is the sum of all payments
effected so far to the Supplier (excluding the Advance
Payment), and “a” is the Advance Payment expressed
as a percentage of the Contract Price pursuant to the
SCC for GCC 12.1.
The security should be returned to the Supplier
immediately after its expiration.
13.3 Performance Security
13.3.1 The Supplier should, within twenty-eight (28) days of
the notification of Contract award, provide a security
for the due performance of the Contract in the amount
and currency specified in the SCC.
13.3.2 The security should be a bank guarantee in the form
provided in the Sample Contractual Forms Section of
the Bidding Documents, or it should be in another
form acceptable to the Purchaser.
13.3.3 The security should automatically become null and
void once all the obligations of the Supplier under the
Contract have been fulfilled, including, but not limited
to, any obligations during the Warranty Period and
any extensions to the period. The security should be
602 Section VI. General Conditions of Contract

returned to the Supplier no later than twenty-eight (28)

days after its expiration.
13.3.4 Upon Operational Acceptance of the entire System,
the security should be reduced to the amount specified
in the SCC, on the date of such Operational
Acceptance, so that the reduced security would only
cover the remaining warranty obligations of the
Supplier.
14. Taxes and Duties 14.1 For Goods or Services supplied from outside the Purchaser’s
country, the Supplier should be entirely responsible for all
taxes, stamp duties, license fees, and other such levies
imposed outside the Purchaser’s country. Any duties, such
as importation or customs duties, and taxes and other levies,
payable in the Purchaser’s country for the supply of Goods
and Services from outside the Purchaser’s country are the
responsibility of the Purchaser unless these duties or taxes
have been made part of the Contract Price in Article 2 of the
Contract Agreement and the Price Schedule it refers to, in
which case the duties and taxes will be the Supplier’s
responsibility.
14.2 For Goods or Services supplied locally, the Supplier should
be entirely responsible for all taxes, duties, license fees, etc.,
incurred until delivery of the contracted Goods or Services to
the Purchaser. The only exception are taxes or duties, such
as value-added or sales tax or stamp duty as apply to, or are
clearly identifiable, on the invoices and provided they apply
in the Purchaser’s country, and only if these taxes, levies
and/or duties are also excluded from the Contract Price in
Article 2 of the Contract Agreement and the Price Schedule
it refers to.
14.3 If any tax exemptions, reductions, allowances, or privileges
may be available to the Supplier in the Purchaser’s Country,
the Purchaser should use its best efforts to enable the
Supplier to benefit from any such tax savings to the
maximum allowable extent.
14.4 For the purpose of the Contract, it is agreed that the Contract
Price specified in Article 2 (Contract Price and Terms of
Payment) of the Contract Agreement is based on the taxes,
duties, levies, and charges prevailing at the date twenty-eight
(28) days prior to the date of bid submission in the
Purchaser’s Country (also called “Tax” in this GCC Clause
14.4). If any Tax rates are increased or decreased, a new Tax
is introduced, an existing Tax is abolished, or any change in
interpretation or application of any Tax occurs in the course
of the performance of the Contract, which was or will be
assessed on the Supplier, its Subcontractors, or their
Section VI. General Conditions of Contract 603

employees in connection with performance of the Contract,

an equitable adjustment to the Contract Price should be made
to fully take into account any such change by addition to or
reduction from the Contract Price, as the case may be.

D. INTELLECTUAL PROPERTY
15. Copyright 15.1 The Intellectual Property Rights in all Standard Software and
Standard Materials should remain vested in the owner of
such rights.
15.2 The Purchaser agrees to restrict use, copying, or duplication
of the Standard Software and Standard Materials in
accordance with GCC Clause 16, except that additional
copies of Standard Materials may be made by the Purchaser
for use within the scope of the project of which the System is
a part, in the event that the Supplier does not deliver copies
within thirty (30) days from receipt of a request for such
Standard Materials.
15.3 The Purchaser’s contractual rights to use the Standard
Software or elements of the Standard Software may not be
assigned, licensed, or otherwise transferred voluntarily
except in accordance with the relevant license agreement or
unlessotherwise specified in the SCCto a legally
constituted successor organization (e.g., a reorganization of a
public entity formally authorized by the government or
through a merger or acquisition of a private entity).
15.4 Unless otherwise specified in the SCC, the Intellectual
Property Rights in all Custom Software and Custom
Materials specified in Appendices 4 and 5 of the Contract
Agreement (if any) should, at the date of this Contract or on
creation of the rights (if later than the date of this Contract),
vest in the Purchaser. The Supplier should do and execute or
arrange for the doing and executing of each necessary act,
document, and thing that the Purchaser may consider
necessary or desirable to perfect the right, title, and interest
of the Purchaser in and to those rights. In respect of such
Custom Software and Custom Materials, the Supplier should
ensure that the holder of a moral right in such an item does
not assert it, and the Supplier should, if requested to do so by
the Purchaser and where permitted by applicable law, ensure
that the holder of such a moral right waives it.
15.5 Unless otherwise specified in the SCC, escrow
arrangements should NOTbe required.
604 Section VI. General Conditions of Contract

16. Software License 16.1 Except to the extent that the Intellectual Property Rights in
Agreements the Software vest in the Purchaser, the Supplier hereby
grants to the Purchaser license to access and use the
Software, including all inventions, designs, and marks
embodied in the Software.
Such license to access and use the Software should:
(a) be:
(i) nonexclusive;
(ii) fully paid up and irrevocable (except that it
should terminate if the Contract terminates under
GCC Clauses 41.1 or 41.3);
(iii) unless otherwise specified in the SCC valid
throughout the territory of the Purchaser’s
Country;
(iv) unless otherwise specified in the SCC subject
to NO additional restrictions.
(b) permit the Software to be:
(i) used or copied for use on or with the computer(s)
for which it was acquired (if specified in the
Technical Requirements and/or the Supplier’s
bid), plus a backup computer(s) of the same or
similar capacity, if the primary is(are)
inoperative, and during a reasonable transitional
period when use is being transferred between
primary and backup;
(ii) used or copied for use on or transferred to a
replacement computer(s), (and use on the original
and replacement computer(s) may be
simultaneous during a reasonable transitional
period) provided that, if the Technical
Requirements and/or the Supplier’s bid specifies
a class of computer to which the license is
restricted, the replacement computer(s) is(are)
within that class;
(iii) if the nature of the System is such as to permit
such access, accessed from other computers
connected to the primary and/or backup
computer(s) by means of a local or wide-area
network or similar arrangement, and used on or
copied for use on those other computers to the
extent necessary to that access;
Section VI. General Conditions of Contract 605

(iv) reproduced for safekeeping or backup purposes;

(v) customized, adapted, or combined with other
computer software for use by the Purchaser,
provided that derivative software incorporating
any substantial part of the delivered, restricted
Software should be subject to same restrictions as
are set forth in this Contract;
(vi) unless otherwise specified in the SCC,
disclosed to, and reproduced for use by, support
service suppliers and their subcontractors, (and
the Purchaser may sublicense such persons to use
and copy for use the Software) to the extent
reasonably necessary to the performance of their
support service contracts, subject to the same
restrictions as are set forth in this Contract; and
(vii) unless otherwise specified in the SCC disclosed
to, and reproduced for use by, NO other parties.
16.2 The Supplier has the right to audit the Standard Software to
verify compliance with the above license agreements. Unless
otherwise specified in the SCC, the Purchaser will make
available to the Supplier, within seven (7) days of a written
request, accurate and up-to-date records of the number and
location of copies, the number of authorized users, or any
other relevant data required to demonstrate use of the
Standard Software as per the license agreement. If and only
if, expressly agreed in writing between the Purchaser and the
Supplier, Purchaser will allow, under a pre-specified agreed
procedure, the execution of embedded software functions
under Supplier’s control, and unencumbered transmission of
resulting information on software usage.
17. Confidential 17.1 Unless otherwise specified in the SCC, the "Receiving
Information Party" (either the Purchaser or the Supplier) should keep
confidential and should not, without the written consent of
the other party to this Contract (“the Disclosing Party”),
divulge to any third party any documents, data, or other
information of a confidential nature (“Confidential
Information”) connected with this Contract, and furnished
directly or indirectly by the Disclosing Party prior to or
during performance, or following termination, of this
Contract.
17.2 For the purposes of GCC Clause 17.1, the Supplier is also
deemed to be the Receiving Party of Confidential
Information generated by the Supplier itself in the course of
the performance of its obligations under the Contract and
relating to the businesses, finances, suppliers, employees, or
other contacts of the Purchaser or the Purchaser’s use of the
606 Section VI. General Conditions of Contract

System.
17.3 Notwithstanding GCC Clauses 17.1 and 17.2:
(a) the Supplier may furnish to its Subcontractor
Confidential Information of the Purchaser to the extent
reasonably required for the Subcontractor to perform
its work under the Contract; and
(b) the Purchaser may furnish Confidential Information of
the Supplier: (i) to its support service suppliers and
their subcontractors to the extent reasonably required
for them to perform their work under their support
service contracts; and (ii) to its affiliates and
subsidiaries,
in which event the Receiving Party should ensure that the
person to whom it furnishes Confidential Information of the
Disclosing Party is aware of and abides by the Receiving
Party’s obligations under this GCC Clause 17 as if that
person were party to the Contract in place of the Receiving
Party.
17.4 The Purchaser should not, without the Supplier’s prior
written consent, use any Confidential Information received
from the Supplier for any purpose other than the operation,
maintenance and further development of the System.
Similarly, the Supplier should not, without the Purchaser’s
prior written consent, use any Confidential Information
received from the Purchaser for any purpose other than those
that are required for the performance of the Contract.
17.5 The obligation of a party under GCC Clauses 17.1 through
17.4 above, however, should not apply to that information
which:
(a) now or hereafter enters the public domain through no
fault of the Receiving Party;
(b) can be proven to have been possessed by the Receiving
Party at the time of disclosure and that was not
previously obtained, directly or indirectly, from the
Disclosing Party;
(c) otherwise lawfully becomes available to the Receiving
Party from a third party that has no obligation of
confidentiality.
17.6 The above provisions of this GCC Clause 17 should not in
any way modify any undertaking of confidentiality given by
either of the parties to this Contract prior to the date of the
Contract in respect of the System or any part thereof.
Section VI. General Conditions of Contract 607

17.7 Unless otherwise specified in the SCC, the provisions of

this GCC Clause 17 should survive the termination, for
whatever reason, of the Contract for three (3) years.

E. SUPPLY, INSTALLATION, TESTING,

COMMISSIONING, AND ACCEPTANCE OF THE SYSTEM
18. Representatives 18.1 Project Manager
If the Project Manager is not named in the Contract, then
within fourteen (14) days of the Effective Date, the
Purchaser should appoint and notify the Supplier in writing
of the name of the Project Manager. The Purchaser may
from time to time appoint some other person as the Project
Manager in place of the person previously so appointed and
should give a notice of the name of such other person to the
Supplier without delay. No such appointment should be
made at such a time or in such a manner as to impede the
progress of work on the System. Such appointment should
take effect only upon receipt of such notice by the Supplier.
Unless otherwise specified in the SCC (if any), the Project
Manager should have the authority to represent the Purchaser
on all day-to-day matters relating to the System or arising
from the Contract, and should normally be the person giving
or receiving notices on behalf of the Purchaser pursuant to
GCC Clause 4.
18.2 Supplier’s Representative
18.2.1 If the Supplier’s Representative is not named in the
Contract, then within fourteen (14) days of the
Effective Date, the Supplier should appoint the
Supplier’s Representative and should request the
Purchaser in writing to approve the person so
appointed. The request must be accompanied by a
detailed curriculum vitae for the nominee, as well as a
description of any other System or non-System
responsibilities the nominee would retain while
performing the duties of the Supplier’s Representative.
If the Purchaser does not object to the appointment
within fourteen (14) days, the Supplier’s
Representative should be deemed to have been
approved. If the Purchaser objects to the appointment
within fourteen (14) days giving the reason therefore,
then the Supplier should appoint a replacement within
fourteen (14) days of such objection in accordance
with this GCC Clause 18.2.1.
18.2.2 Unless otherwise specified in the SCC (if any), the
608 Section VI. General Conditions of Contract

Supplier’s Representative should have the authority to

represent the Supplier on all day-to-day matters
relating to the System or arising from the Contract,
and should normally be the person giving or receiving
notices on behalf of the Supplier pursuant to GCC
Clause 4.
18.2.3 The Supplier should not revoke the appointment of the
Supplier’s Representative without the Purchaser’s
prior written consent, which should not be
unreasonably withheld. If the Purchaser consents to
such an action, the Supplier should appoint another
person of equal or superior qualifications as the
Supplier’s Representative, pursuant to the procedure
set out in GCC Clause 18.2.1.
18.2.4 The Supplier’s Representative and staff are obliged to
work closely with the Purchaser’s Project Manager
and staff, act within their own authority, and abide by
directives issued by the Purchaser that are consistent
with the terms of the Contract. The Supplier’s
Representative is responsible for managing the
activities of its personnel and any subcontracted
personnel.
18.2.5 The Supplier’s Representative may, subject to the
approval of the Purchaser (which should not be
unreasonably withheld), at any time delegate to any
person any of the powers, functions, and authorities
vested in him or her. Any such delegation may be
revoked at any time. Any such delegation or
revocation should be subject to a prior notice signed
by the Supplier’s Representative and should specify
the powers, functions, and authorities thereby
delegated or revoked. No such delegation or
revocation should take effect unless and until the
notice of it has been delivered.
18.2.6 Any act or exercise by any person of powers,
functions and authorities so delegated to him or her in
accordance with GCC Clause 18.2.5 should be
deemed to be an act or exercise by the Supplier’s
Representative.
18.3 Objections and Removals
18.3.1 The Purchaser may by notice to the Supplier object to
any representative or person employed by the Supplier
in the execution of the Contract who, in the reasonable
opinion of the Purchaser, may have behaved
inappropriately, be incompetent, or be negligent. The
Section VI. General Conditions of Contract 609

Purchaser should provide evidence of the same,

whereupon the Supplier should remove such person
from work on the System.
18.3.2 If any representative or person employed by the
Supplier is removed in accordance with GCC Clause
18.3.1, the Supplier should, where required, promptly
appoint a replacement.
19. Project Plan 19.1 In close cooperation with the Purchaser and based on the
Preliminary Project Plan included in the Supplier’s bid, the
Supplier should develop a Project Plan encompassing the
activities specified in the Contract. The contents of the
Project Plan should be as specified in the SCC and/or
Technical Requirements.
19.2 Unless otherwise specified in the SCC, within thirty (30)
days from the Effective Date of the Contract, the Supplier
should present a Project Plan to the Purchaser. The
Purchaser should, within fourteen (14)days of receipt of the
Project Plan, notify the Supplier of any respects in which it
considers that the Project Plan does not adequately ensure
that the proposed program of work, proposed methods,
and/or proposed Information Technologies will satisfy the
Technical Requirements and/or the SCC (in this Clause 19.2
called “non-conformities” below). The Supplier should,
within five (5) days of receipt of such notification, correct
the Project Plan and resubmit to the Purchaser. The
Purchaser should, within five (5) days of resubmission of the
Project Plan, notify the Supplier of any remaining non-
conformities. This procedure should be repeated as
necessary until the Project Plan is free from non-
conformities. When the Project Plan is free from non-
conformities, the Purchaser should provide confirmation in
writing to the Supplier. This approved Project Plan (“the
Agreed Project Plan”) should be contractually binding on the
Purchaser and the Supplier.
19.3 If required, the impact on the Implementation Schedule of
modifications agreed during finalization of the Agreed
Project Plan should be incorporated in the Contract by
amendment, in accordance with GCC Clauses 39 and 40.
19.4 The Supplier should undertake to supply, install, test, and
commission the System in accordance with the Agreed
Project Plan and the Contract.
19.5 Unless otherwise specified in the SCC, the Supplier should
submit to the Purchaser Monthly Progress Reports
summarizing:
610 Section VI. General Conditions of Contract

(i) results accomplished during the prior period;

(ii) cumulative deviations to date from schedule of
progress milestones as specified in the Agreed Project
Plan;
(iii) corrective actions to be taken to return to planned
schedule of progress; proposed revisions to planned
schedule;
(iv) other issues and outstanding problems; proposed
actions to be taken;
(v) resources that the Supplier expects to be provided by
the Purchaser and/or actions to be taken by the
Purchaser in the next reporting period;
(vi) other issues or potential problems the Supplier foresees
that could impact on project progress and/or
effectiveness.
19.6 The Supplier should submit to the Purchaser other(periodic)
reports as specified in the SCC.

20. Subcontracting 20.1 Appendix 3 (List of Approved Subcontractors) to the

Contract Agreement specifies critical items of supply or
services and a list of Subcontractors for each item that are
considered acceptable by the Purchaser. If no
Subcontractors are listed for an item, the Supplier should
prepare a list of Subcontractors it considers qualified and
wishes to be added to the list for such items. The Supplier
may from time to time propose additions to or deletions from
any such list. The Supplier should submit any such list or
any modification to the list to the Purchaser for its approval
in sufficient time so as not to impede the progress of work on
the System. The Purchaser should not withhold such
approval unreasonably. Such approval by the Purchaser of a
Subcontractor(s) should not relieve the Supplier from any of
its obligations, duties, or responsibilities under the Contract.
20.2 The Supplier may, at its discretion, select and employ
Subcontractors for such critical items from those
Subcontractors listed pursuant to GCC Clause 20.1. If the
Supplier wishes to employ a Subcontractor not so listed, or
subcontract an item not so listed, it must seek the
Purchaser’s prior approval under GCC Clause 20.3.
20.3 For items for which pre-approved Subcontractor lists have
not been specified in Appendix 3 to the Contract Agreement,
the Supplier may employ such Subcontractors as it may
select, provided: (i) the Supplier notifies the Purchaser in
Section VI. General Conditions of Contract 611

writing at least twenty-eight (28) days prior to the proposed

mobilization date for such Subcontractor; and (ii) by the end
of this period either the Purchaser has granted its approval in
writing or fails to respond. The Supplier should not engage
any Subcontractor to which the Purchaser has objected in
writing prior to the end of the notice period. The absence of
a written objection by the Purchaser during the above
specified period should constitute formal acceptance of the
proposed Subcontractor. Except to the extent that it permits
the deemed approval of the Purchaser of Subcontractors not
listed in the Contract Agreement, nothing in this Clause,
however, should limit the rights and obligations of either the
Purchaser or Supplier as they are specified in GCC
Clauses 20.1 and 20.2, or in Appendix 3 of the Contract
Agreement.
21. Design and 21.1 Technical Specifications and Drawings
Engineering
21.1.1 The Supplier should execute the basic and detailed
design and the implementation activities necessary for
successful installation of the System in compliance
with the provisions of the Contract or, where not so
specified, in accordance with good industry practice.
The Supplier should be responsible for any
discrepancies, errors or omissions in the
specifications, drawings, and other technical
documents that it has prepared, whether such
specifications, drawings, and other documents have
been approved by the Project Manager or not,
provided that such discrepancies, errors, or omissions
are not because of inaccurate information furnished in
writing to the Supplier by or on behalf of the
Purchaser.
21.1.2 The Supplier should be entitled to disclaim
responsibility for any design, data, drawing,
specification, or other document, or any modification
of such design, drawings, specification, or other
documents provided or designated by or on behalf of
the Purchaser, by giving a notice of such disclaimer to
the Project Manager.
21.2 Codes and Standards
Wherever references are made in the Contract to codes and
standards in accordance with which the Contract should be
executed, the edition or the revised version of such codes and
standards current at the date twenty-eight (28) days prior to
date of bid submission should apply. During Contract
execution, any changes in such codes and standards should
612 Section VI. General Conditions of Contract

be applied after approval by the Purchaser and should be

treated in accordance with GCC Clause 39.3.
21.3 Approval/Review of Controlling Technical Documents by
the Project Manager
21.3.1 Unless otherwise specified in the SCC, there will
NO Controlling Technical Documents required.
However, if the SCC specifies Controlling Technical
Documents, the Supplier should prepare and furnish
such documents for the Project Manager’s approval or
review.
Any part of the System covered by or related to the
documents to be approved by the Project Manager
should be executed only after the Project Manager’s
approval of these documents.
GCC Clauses 21.3.2 through 21.3.7 should apply to
those documents requiring the Project Manager’s
approval, but not to those furnished to the Project
Manager for its review only.
21.3.2 Within fourteen (14) days after receipt by the Project
Manager of any document requiring the Project
Manager’s approval in accordance with GCC Clause
21.3.1, the Project Manager should either return one
copy of the document to the Supplier with its approval
endorsed on the document or should notify the
Supplier in writing of its disapproval of the document
and the reasons for disapproval and the modifications
that the Project Manager proposes. If the Project
Manager fails to take such action within the fourteen
(14) days, then the document should be deemed to
have been approved by the Project Manager.
21.3.3 The Project Manager should not disapprove any
document except on the grounds that the document
does not comply with some specified provision of the
Contract or that it is contrary to good industry
practice.
21.3.4 If the Project Manager disapproves the document, the
Supplier should modify the document and resubmit it
for the Project Manager’s approval in accordance with
GCC Clause 21.3.2. If the Project Manager approves
the document subject to modification(s), the Supplier
should make the required modification(s), and the
document should then be deemed to have been
approved, subject to GCC Clause 21.3.5. The
procedure set out in GCC Clauses 21.3.2 through
21.3.4 should be repeated, as appropriate, until the
Section VI. General Conditions of Contract 613

Project Manager approves such documents.

21.3.5 If any dispute occurs between the Purchaser and the
Supplier in connection with or arising out of the
disapproval by the Project Manager of any document
and/or any modification(s) to a document that cannot
be settled between the parties within a reasonable
period, then, in case the Contract Agreement includes
and names an Adjudicator, such dispute may be
referred to the Adjudicator for determination in
accordance with GCC Clause 43.1 (Adjudicator). If
such dispute is referred to an Adjudicator, the Project
Manager should give instructions as to whether and if
so, how, performance of the Contract is to proceed.
The Supplier should proceed with the Contract in
accordance with the Project Manager’s instructions,
provided that if the Adjudicator upholds the Supplier’s
view on the dispute and if the Purchaser has not given
notice under GCC Clause 43.1.2, then the Supplier
should be reimbursed by the Purchaser for any
additional costs incurred by reason of such
instructions and should be relieved of such
responsibility or liability in connection with the
dispute and the execution of the instructions as the
Adjudicator should decide, and the Time for
Achieving Operational Acceptance should be
extended accordingly.
21.3.6 The Project Manager’s approval, with or without
modification of the document furnished by the
Supplier, should not relieve the Supplier of any
responsibility or liability imposed upon it by any
provisions of the Contract except to the extent that any
subsequent failure results from modifications required
by the Project Manager or inaccurate information
furnished in writing to the Supplier by or on behalf of
the Purchaser.
21.3.7 The Supplier should not depart from any approved
document unless the Supplier has first submitted to
the Project Manager an amended document and
obtained the Project Manager’s approval of the
document, pursuant to the provisions of this GCC
Clause 21.3. If the Project Manager requests any
change in any already approved document and/or in
any document based on such an approved document,
the provisions of GCC Clause 39 (Changes to the
System) should apply to such request.
22. Procurement, 22.1 Subject to related Purchaser's responsibilities pursuant to
Delivery, and GCC Clauses 10 and 14, the Supplier should manufacture or
614 Section VI. General Conditions of Contract

Transport procure and transport all the Information Technologies,

Materials, and other Goods in an expeditious and orderly
manner to the Project Site.
22.2 Delivery of the Information Technologies, Materials, and
other Goods should be made by the Supplier in accordance
with the Technical Requirements.
22.3 Early or partial deliveries require the explicit written consent
of the Purchaser, which consent should not be unreasonably
withheld.
22.4 Transportation
22.4.1 The Supplier should provide such packing of the
Goods as is required to prevent their damage or
deterioration during shipment. The packing, marking,
and documentation within and outside the packages
should comply strictly with the Purchaser’s
instructions to the Supplier.
22.4.2 The Supplier will bear responsibility for and cost of
transport to the Project Sites in accordance with the
terms and conditions used in the specification of
prices in the Price Schedules, including the terms and
conditions of the associated Incoterms.
22.4.3 Unless otherwise specified in the SCC, the Supplier
should be free to use transportation through carriers
registered in any eligible country and to obtain
insurance from any eligible source country.
22.5 Unless otherwise specified in the SCC, the Supplier will
provide the Purchaser with shipping and other documents, as
specified below:
22.5.1 For Goods supplied from outside the Purchaser’s
Country:
Upon shipment, the Supplier should notify the
Purchaser and the insurance company contracted by the
Supplier to provide cargo insurance by telex, cable,
facsimile, electronic mail, or EDI with the full details
of the shipment. The Supplier should promptly send
the following documents to the Purchaser by mail or
courier, as appropriate, with a copy to the cargo
insurance company:
(a) two copies of the Supplier’s invoice showing the
description of the Goods, quantity, unit price, and
total amount;
Section VI. General Conditions of Contract 615

(b) usual transportation documents;

(c) insurance certificate;
(d) certificate(s) of origin; and
(e) estimated time and point of arrival in the
Purchaser’s Country and at the site.
22.5.2 For Goods supplied locally (i.e., from within the
Purchaser’s country):
Upon shipment, the Supplier should notify the
Purchaser by telex, cable, facsimile, electronic mail, or
EDI with the full details of the shipment. The Supplier
should promptly send the following documents to the
Purchaser by mail or courier, as appropriate:
(a) two copies of the Supplier’s invoice showing the
Goods’ description, quantity, unit price, and total
amount;
(b) delivery note, railway receipt, or truck receipt;
(c) certificate of insurance;
(d) certificate(s) of origin; and
(e) estimated time of arrival at the site.
22.6 Customs Clearance
(a) The Purchaser will bear responsibility for, and cost of,
customs clearance into the Purchaser's country in
accordance the particular Incoterm(s) used for Goods
supplied from outside the Purchaser’s country in the
Price Schedules referred to by Article 2 of the Contract
Agreement.
(b) At the request of the Purchaser, the Supplier will make
available a representative or agent during the process of
customs clearance in the Purchaser's country for goods
supplied from outside the Purchaser's country. In the
event of delays in customs clearance that are not the
fault of the Supplier:
(i) the Supplier should be entitled to an extension in
the Time for Achieving Operational Acceptance,
pursuant to GCC Clause 40;
(ii) the Contract Price should be adjusted to
compensate the Supplier for any additional
storage charges that the Supplier may incur as a
616 Section VI. General Conditions of Contract

result of the delay.

23. Product 23.1 At any point during performance of the Contract, should
Upgrades technological advances be introduced by the Supplier for
Information Technologies originally offered by the Supplier
in its bid and still to be delivered, the Supplier should be
obligated to offer to the Purchaser the latest versions of the
available Information Technologies having equal or better
performance or functionality at the same or lesser unit prices,
pursuant to GCC Clause 39 (Changes to the System).
23.2 At any point during performance of the Contract, for
Information Technologies still to be delivered, the Supplier
will also pass on to the Purchaser any cost reductions and
additional and/or improved support and facilities that it
offers to other clients of the Supplier in the Purchaser’s
Country, pursuant to GCC Clause 39 (Changes to the
System).
23.3 During performance of the Contract, the Supplier should
offer to the Purchaser all new versions, releases, and updates
of Standard Software, as well as related documentation and
technical support services, within thirty (30) days of their
availability from the Supplier to other clients of the Supplier
in the Purchaser’s Country, and no later than twelve (12)
months after they are released in the country of origin. In no
case will the prices for these Software exceed those quoted
by the Supplier in the Recurrent Costs tables in its bid.
23.4 Unless otherwise specified in the SCC,during the Warranty
Period, the Supplier will provide at no additional cost to the
Purchaser all new versions, releases, and updates for all
Standard Software that are used in the System, within thirty
(30) days of their availability from the Supplier to other
clients of the Supplier in the Purchaser’s country, and no
later than twelve (12) months after they are released in the
country of origin of the Software.
23.5 The Purchaser should introduce all new versions, releases or
updates of the Software within eighteen (18) months of
receipt of a production-ready copy of the new version,
release, or update, provided that the new version, release, or
update does not adversely affect System operation or
performance or require extensive reworking of the System.
In cases where the new version, release, or update adversely
affects System operation or performance, or requires
extensive reworking of the System, the Supplier should
continue to support and maintain the version or release
previously in operation for as long as necessary to allow
introduction of the new version, release, or update. In no
case should the Supplier stop supporting or maintaining a
Section VI. General Conditions of Contract 617

version or release of the Software less than twenty four (24)

months after the Purchaser receives a production-ready copy
of a subsequent version, release, or update. The Purchaser
should use all reasonable endeavors to implement any new
version, release, or update as soon as practicable, subject to
the twenty-four-month-long stop date.
24. Implementation, 24.1 The Supplier should provide all Services specified in the
Installation, and Contract and Agreed Project Plan in accordance with the
Other Services highest standards of professional competence and integrity.
24.2 Prices charged by the Supplier for Services, if not included
in the Contract, should be agreed upon in advance by the
parties (including, but not restricted to, any prices submitted
by the Supplier in the Recurrent Cost Schedules of its Bid)
and should not exceed the prevailing rates charged by the
Supplier to other purchasers in the Purchaser’s Country for
similar services.
25. Inspections and 25.1 The Purchaser or its representative should have the right to
Tests inspect and/or test any components of the System, as
specified in the Technical Requirements, to confirm their
good working order and/or conformity to the Contract at the
point of delivery and/or at the Project Site.
25.2 The Purchaser or its representative should be entitled to
attend any such inspections and/or tests of the components,
provided that the Purchaser should bear all costs and
expenses incurred in connection with such attendance,
including but not limited to all inspection agent fees, travel,
and related expenses.
25.3 Should the inspected or tested components fail to conform to
the Contract, the Purchaser may reject the component(s), and
the Supplier should either replace the rejected component(s),
or make alterations as necessary so that it meets the Contract
requirements free of cost to the Purchaser.
25.4 The Project Manager may require the Supplier to carry out
any inspection and/or test not specified in the Contract,
provided that the Supplier’s reasonable costs and expenses
incurred in the carrying out of such inspection and/or test
should be added to the Contract Price. Further, if such
inspection and/or test impedes the progress of work on the
System and/or the Supplier’s performance of its other
obligations under the Contract, due allowance will be made
in respect of the Time for Achieving Operational Acceptance
and the other obligations so affected.
25.5 If any dispute should arise between the parties in connection
with or caused by an inspection and/or with regard to any
component to be incorporated in the System that cannot be
618 Section VI. General Conditions of Contract

settled amicably between the parties within a reasonable

period of time, either party may invoke the process pursuant
to GCC Clause 43 (Settlement of Disputes), starting with
referral of the matter to the Adjudicator in case an
Adjudicator is included and named in the Contract
Agreement.
26. Installation of the 26.1 As soon as the System, or any Subsystem, has, in the opinion
System of the Supplier, been delivered, Pre-commissioned, and
made ready for Commissioning and Operational Acceptance
Testing in accordance with the Technical Requirements, the
SCC and the Agreed Project Plan, the Supplier should so
notify the Purchaser in writing.
26.2 The Project Manager should, within fourteen (14) days after
receipt of the Supplier’s notice under GCC Clause 26.1,
either issue an Installation Certificate in the form specified in
the Sample Contractual Forms Section in the Bidding
Documents, stating that the System, or major component or
Subsystem (if Acceptance by major component or
Subsystem is specified pursuant to the SCC for GCC Clause
27.2.1), has achieved Installation by the date of the
Supplier’s notice under GCC Clause 26.1, or notify the
Supplier in writing of any defects and/or deficiencies,
including, but not limited to, defects or deficiencies in the
interoperability or integration of the various components
and/or Subsystems making up the System. The Supplier
should use all reasonable endeavors to promptly remedy any
defect and/or deficiencies that the Project Manager has
notified the Supplier of. The Supplier should then promptly
carry out retesting of the System or Subsystem and, when in
the Supplier’s opinion the System or Subsystem is ready for
Commissioning and Operational Acceptance Testing, notify
the Purchaser in writing, in accordance with GCC
Clause 26.1. The procedure set out in this GCC Clause 26.2
should be repeated, as necessary, until an Installation
Certificate is issued.
26.3 If the Project Manager fails to issue the Installation
Certificate and fails to inform the Supplier of any defects
and/or deficiencies within fourteen (14) days after receipt of
the Supplier’s notice under GCC Clause 26.1, or if the
Purchaser puts the System or a Subsystem into production
operation, then the System (or Subsystem) should be deemed
to have achieved successful Installation as of the date of the
Supplier’s notice or repeated notice, or when the Purchaser
put the System into production operation, as the case may be.
27. Commissioning 27.1 Commissioning
and Operational
Acceptance 27.1.1 Commissioning of the System (or Subsystem if
Section VI. General Conditions of Contract 619

specified pursuant to the SCC for GCC Clause 27.2.1)

should be commenced by the Supplier:
(a) immediately after the Installation Certificate is
issued by the Project Manager, pursuant to
GCC Clause 26.2; or
(b) as otherwise specified in the Technical
Requirement or the Agreed Project Plan; or
(c) immediately after Installation is deemed to have
occurred, under GCC Clause 26.3.
27.1.2 The Purchaser should supply the operating and
technical personnel and all materials and information
reasonably required to enable the Supplier to carry out
its obligations with respect to Commissioning.
Production use of the System or Subsystem(s) should
not commence prior to the start of formal Operational
Acceptance Testing.
27.2 Operational Acceptance Tests
27.2.1 The Operational Acceptance Tests (and repeats of
such tests) should be the primary responsibility of the
Purchaser (in accordance with GCC Clause 10.9), but
should be conducted with the full cooperation of the
Supplier during Commissioning of the System (or
major components or Subsystem[s]), to ascertain
whether the System (or major component or
Subsystem[s]) conforms to the Technical
Requirements and meets the standard of performance
quoted in the Supplier’s bid, including, but not
restricted to, the functional and technical performance
requirements. Unless otherwise specified in the
SCC, the Operational Acceptance Tests during
Commissioning will be conducted as specified in the
Technical Requirements and/or the Agreed Project
Plan.
At the Purchaser’s discretion, Operational Acceptance
Tests may also be performed on replacement Goods,
upgrades and new version releases, and Goods that are
added or field-modified after Operational Acceptance
of the System.
27.2.2 If for reasons attributable to the Purchaser, the
Operational Acceptance Test of the System (or
Subsystem[s] or major components, pursuant to the
SCC for GCC Clause 27.2.1) cannot be successfully
completed within ninety (90) days from the date of
620 Section VI. General Conditions of Contract

Installation or any other period agreed upon in writing

by the Purchaser and the Supplier, the Supplier should
be deemed to have fulfilled its obligations with respect
to the technical and functional aspects of the
Technical Specifications, SCC and/or the Agreed
Project Plan, and GCC Clause 28.2 and 28.3 should
not apply.
27.3 Operational Acceptance
27.3.1 Subject to GCC Clause 27.4 (Partial Acceptance)
below, Operational Acceptance should occur in
respect of the System, when
(a) the Operational Acceptance Tests, as specified in
the Technical Requirements, and/or SCC and/or
the Agreed Project Plan have been successfully
completed; or
(b) the Operational Acceptance Tests have not been
successfully completed or have not been carried
out for reasons that are attributable to the
Purchaser within the period from the date of
Installation or any other agreed-upon period as
specified in GCC Clause 27.2.2 above; or
(c) the Purchaser has put the System into production
or use for sixty (60) consecutive days. If the
System is put into production or use in this
manner, the Supplier should notify the Purchaser
and document such use.
27.3.2 At any time after any of the events set out in GCC
Clause 27.3.1 have occurred, the Supplier may give a
notice to the Project Manager requesting the issue of
an Operational Acceptance Certificate.
27.3.3 After consultation with the Purchaser, and within
fourteen (14) days after receipt of the Supplier’s
notice, the Project Manager should:
(a) issue an Operational Acceptance Certificate; or
(b) notify the Supplier in writing of any defect or
deficiencies or other reason for the failure of the
Operational Acceptance Tests; or
(c) issue the Operational Acceptance Certificate, if
the situation covered by GCC Clause 27.3.1 (b)
arises.
27.3.4 The Supplier should use all reasonable endeavors to
promptly remedy any defect and/or deficiencies and/or
Section VI. General Conditions of Contract 621

other reasons for the failure of the Operational

Acceptance Test that the Project Manager has notified
the Supplier of. Once such remedies have been made
by the Supplier, the Supplier should notify the
Purchaser, and the Purchaser, with the full cooperation
of the Supplier, should use all reasonable endeavors to
promptly carry out retesting of the System or
Subsystem. Upon the successful conclusion of the
Operational Acceptance Tests, the Supplier should
notify the Purchaser of its request for Operational
Acceptance Certification, in accordance with GCC
Clause 27.3.3. The Purchaser should then issue to the
Supplier the Operational Acceptance Certification in
accordance with GCC Clause 27.3.3 (a), or should
notify the Supplier of further defects, deficiencies, or
other reasons for the failure of the Operational
Acceptance Test. The procedure set out in this GCC
Clause 27.3.4 should be repeated, as necessary, until
an Operational Acceptance Certificate is issued.
27.3.5 If the System or Subsystem fails to pass the
Operational Acceptance Test(s) in accordance with
GCC Clause 27.2, then either:
(a) the Purchaser may consider terminating the
Contract, pursuant to GCC Clause 41.2.2;
or
(b) if the failure to achieve Operational Acceptance
within the specified time period is a result of
the failure of the Purchaser to fulfill its
obligations under the Contract, then the
Supplier should be deemed to have fulfilled its
obligations with respect to the relevant
technical and functional aspects of the Contract,
and GCC Clauses 30.2 and 30.3should not
apply.
27.3.6 If within fourteen (14) days after receipt of the
Supplier’s notice the Project Manager fails to issue the
Operational Acceptance Certificate or fails to inform
the Supplier in writing of the justifiable reasons why
the Project Manager has not issued the Operational
Acceptance Certificate, the System or Subsystem
should be deemed to have been accepted as of the date
of the Supplier’s said notice.
27.4 Partial Acceptance
27.4.1 If so specified in the SCC for GCC Clause 27.2.1,
Installation and Commissioning should be carried out
622 Section VI. General Conditions of Contract

individually for each identified major component or

Subsystem(s) of the System. In this event, the
provisions in the Contract relating to Installation and
Commissioning, including the Operational Acceptance
Test, should apply to each such major component or
Subsystem individually, and Operational Acceptance
Certificate(s) should be issued accordingly for each such
major component or Subsystem of the System, subject to
the limitations contained in GCC Clause 27.4.2.
27.4.2 The issuance of Operational Acceptance Certificates for
individual major components or Subsystems pursuant to
GCC Clause 27.4.1 should not relieve the Supplier of its
obligation to obtain an Operational Acceptance
Certificate for the System as an integrated whole (if so
specified in the SCC for GCC Clauses 12.1 and 27.2.1)
once all major components and Subsystems have been
supplied, installed, tested, and commissioned.
27.4.3 In the case of minor components for the System that
by their nature do not require Commissioning or an
Operational Acceptance Test (e.g., minor fittings,
furnishings or site works, etc.), the Project Manager
should issue an Operational Acceptance Certificate
within fourteen (14) days after the fittings and/or
furnishings have been delivered and/or installed or the
site works have been completed. The Supplier should,
however, use all reasonable endeavors to promptly
remedy any defects or deficiencies in such minor
components detected by the Purchaser or Supplier.

F. GUARANTEES AND LIABILITIES

28. Operational 28.1 The Supplier guarantees that it should complete the supply,
Acceptance Time Installation, Commissioning, and achieve Operational
Guarantee Acceptance of the System (or Subsystems, pursuant to the
SCC for GCC Clause 27.2.1) within the time periods
specified in the Implementation Schedule and/or the Agreed
Project Plan pursuant to GCC Clause 8.2, or within such
extended time to which the Supplier should be entitled under
GCC Clause 40 (Extension of Time for Achieving
Operational Acceptance).
28.2 Unless otherwise specified in the SCC, if the Supplier fails
to supply, install, commission, and achieve Operational
Acceptance of the System (or Subsystems pursuant to the SCC
for GCC Clause 27.2.1) within the time for achieving
Operational Acceptance specified in the Implementation
Schedule or the Agreed Project Plan, or any extension of the
time for achieving Operational Acceptance previously granted
Section VI. General Conditions of Contract 623

under GCC Clause 40 (Extension of Time for Achieving

Operational Acceptance), the Supplier should pay to the
Purchaser liquidated damages at the rate of one half of one
percent per week as a percentage of the Contract Price
(exclusive of Recurrent Costs if any), or the relevant part of the
Contract Price if a Subsystem has not achieved Operational
Acceptance. The aggregate amount of such liquidated damages
should in no event exceed the amount of ten (10) percent of the
Contract Price (exclusive of Recurrent Costs if any). Once the
Maximum is reached, the Purchaser may consider termination
of the Contract, pursuant to GCC Clause 41.2.2.
28.3 Unless otherwise specified in the SCC, liquidated damages
payable under GCC Clause 28.2 should apply only to the
failure to achieve Operational Acceptance of the System
(and Subsystems) as specified in the Implementation
Schedule and/or Agreed Project Plan. This Clause 28.3
should not limit, however, any other rights or remedies the
Purchaser may have under the Contract for other delays.
28.4 If liquidated damages are claimed by the Purchaser for the
System (or Subsystem), the Supplier should have no further
liability whatsoever to the Purchaser in respect to the
Operational Acceptance time guarantee for the System (or
Subsystem). However, the payment of liquidated damages
should not in any way relieve the Supplier from any of its
obligations to complete the System or from any other of its
obligations and liabilities under the Contract.
29. Defect Liability 29.1 The Supplier warrants that the System, including all
Information Technologies, Materials, and other Goods
supplied and Services provided, should be free from defects
in the design, engineering, Materials, and workmanship that
prevent the System and/or any of its components from
fulfilling the Technical Requirements or that limit in a
material fashion the performance, reliability, or extensibility
of the System and/or Subsystems. Unless otherwise
specified in the SCC, there will be NO exceptions and/or
limitations to this warranty with respect to Software (or
categories of Software). Commercial warranty provisions of
products supplied under the Contract should apply to the
extent that they do not conflict with the provisions of this
Contract.
29.2 The Supplier also warrants that the Information
Technologies, Materials, and other Goods supplied under the
Contract are new, unused, and incorporate all recent
improvements in design that materially affect the System’s
or Subsystem’s ability to fulfill the Technical Requirements.
29.3 Unless otherwise specified in the SCC, the Supplier
624 Section VI. General Conditions of Contract

warrants that: (i) all Goods components to be incorporated

into the System form part of the Supplier’s and/or
Subcontractor’s current product lines, and (ii) they have been
previously released to the market.
29.4 Unless otherwise specified in the SCC, the Warranty
Period should commence from the date of Operational
Acceptance of the System (or of any major component or
Subsystem for which separate Operational Acceptance is
provided for in the Contract) and should extend for thirty-six
(36) months.
29.5 If during the Warranty Period any defect as described in
GCC Clause 29.1 should be found in the design, engineering,
Materials, and workmanship of the Information
Technologies and other Goods supplied or of the Services
provided by the Supplier, the Supplier should promptly, in
consultation and agreement with the Purchaser regarding
appropriate remedying of the defects, and at its sole cost,
repair, replace, or otherwise make good (as the Supplier
should, at its discretion, determine) such defect as well as
any damage to the System caused by such defect. Any
defective Information Technologies or other Goods that have
been replaced by the Supplier should remain the property of
the Supplier.
29.6 The Supplier should not be responsible for the repair,
replacement, or making good of any defect, or of any
damage to the System arising out of or resulting from any of
the following causes:
(a) improper operation or maintenance of the System by the
Purchaser;
(b) normal wear and tear;
(c) use of the System with items not supplied by the
Supplier, unless otherwise identified in the Technical
Requirements, or approved by the Supplier; or
(d) modifications made to the System by the Purchaser, or a
third party, not approved by the Supplier.
29.7 The Supplier’s obligations under this GCC Clause 29 should
not apply to:
(a) any materials that are normally consumed in operation or
have a normal life shorter than the Warranty Period; or
(b) any designs, specifications, or other data designed,
supplied, or specified by or on behalf of the Purchaser or
any matters for which the Supplier has disclaimed
responsibility, in accordance with GCC Clause 21.1.2.
Section VI. General Conditions of Contract 625

29.8 The Purchaser should give the Supplier a notice promptly

following the discovery of such defect, stating the nature of
any such defect together with all available evidence. The
Purchaser should afford all reasonable opportunity for the
Supplier to inspect any such defect. The Purchaser should
afford the Supplier all necessary access to the System and the
site to enable the Supplier to perform its obligations under
this GCC Clause 29.
29.9 The Supplier may, with the consent of the Purchaser, remove
from the site any Information Technologies and other Goods
that are defective, if the nature of the defect, and/or any
damage to the System caused by the defect, is such that
repairs cannot be expeditiously carried out at the site. If the
repair, replacement, or making good is of such a character
that it may affect the efficiency of the System, the Purchaser
may give the Supplier notice requiring that tests of the
defective part be made by the Supplier immediately upon
completion of such remedial work, whereupon the Supplier
should carry out such tests.
If such part fails the tests, the Supplier should carry out
further repair, replacement, or making good (as the case may
be) until that part of the System passes such tests. The tests
should be agreed upon by the Purchaser and the Supplier.
29.10 Unless otherwise specified in the SCC, the response
times and repair/replacement times for Warranty Defect
Repair are specified in the Technical Requirements.
Nevertheless, if the Supplier fails to commence the work
necessary to remedy such defect or any damage to the
System caused by such defect within two weeks the
Purchaser may, following notice to the Supplier, proceed to
do such work or contract a third party (or parties) to do such
work, and the reasonable costs incurred by the Purchaser in
connection with such work should be paid to the Purchaser
by the Supplier or may be deducted by the Purchaser from
any monies due the Supplier or claimed under the
Performance Security.
29.11 If the System or Subsystem cannot be used by reason of
such defect and/or making good of such defect, the Warranty
Period for the System should be extended by a period equal
to the period during which the System or Subsystem could
not be used by the Purchaser because of such defect and/or
making good of such defect.
29.12 Items substituted for defective parts of the System during
the Warranty Period should be covered by the Defect
Liability Warranty for the remainder of the Warranty Period
applicable for the part replaced or three (3) months,
626 Section VI. General Conditions of Contract

whichever is greater. For reasons of information security,

the Purchaser may choose to retain physical possession of
any replaced defective information storage devices.
29.13 At the request of the Purchaser and without prejudice to any
other rights and remedies that the Purchaser may have
against the Supplier under the Contract, the Supplier will
offer all possible assistance to the Purchaser to seek warranty
services or remedial action from any subcontracted third-
party producers or licensor of Goods included in the System,
including without limitation assignment or transfer in favor
of the Purchaser of the benefit of any warranties given by
such producers or licensors to the Supplier.
30. Functional 30.1 The Supplier guarantees that, once the Operational
Guarantees Acceptance Certificate(s) has been issued, the System
represents a complete, integrated solution to the Purchaser’s
requirements set forth in the Technical Requirements and it
conforms to all other aspects of the Contract. The Supplier
acknowledges that GCC Clause 27 regarding
Commissioning and Operational Acceptance governs how
technical conformance of the System to the Contract
requirements will be determined.
30.2 If, for reasons attributable to the Supplier, the System does
not conform to the Technical Requirements or does not
conform to all other aspects of the Contract, the Supplier
should at its cost and expense make such changes,
modifications, and/or additions to the System as may be
necessary to conform to the Technical Requirements and
meet all functional and performance standards. The Supplier
should notify the Purchaser upon completion of the
necessary changes, modifications, and/or additions and
should request the Purchaser to repeat the Operational
Acceptance Tests until the System achieves Operational
Acceptance.
30.3 If the System (or Subsystem[s]) fails to achieve Operational
Acceptance, the Purchaser may consider termination of the
Contract, pursuant to GCC Clause 41.2.2, and forfeiture of
the Supplier’s Performance Security in accordance with
GCC Clause 13.3 in compensation for the extra costs and
delays likely to result from this failure.
31. Intellectual 31.1 The Supplier hereby represents and warrants that:
Property Rights
Warranty (a) the System as supplied, installed, tested, and accepted;
(b) use of the System in accordance with the Contract; and
(c) copying of the Software and Materials provided to the
Section VI. General Conditions of Contract 627

Purchaser in accordance with the Contract

do not and will not infringe any Intellectual Property Rights
held by any third party and that it has all necessary rights or
at its sole expense should have secured in writing all
transfers of rights and other consents necessary to make the
assignments, licenses, and other transfers of Intellectual
Property Rights and the warranties set forth in the Contract,
and for the Purchaser to own or exercise all Intellectual
Property Rights as provided in the Contract. Without
limitation, the Supplier should secure all necessary written
agreements, consents, and transfers of rights from its
employees and other persons or entities whose services are
used for development of the System.
32. Intellectual 32.1 The Supplier should indemnify and hold harmless the
Property Rights Purchaser and its employees and officers from and against
Indemnity any and all losses, liabilities, and costs (including losses,
liabilities, and costs incurred in defending a claim alleging
such a liability), that the Purchaser or its employees or
officers may suffer as a result of any infringement or alleged
infringement of any Intellectual Property Rights by reason
of:
(a) installation of the System by the Supplier or the use of
the System, including the Materials, in the country
where the site is located;
(b) copying of the Software and Materials provided the
Supplier in accordance with the Agreement; and
(c) sale of the products produced by the System in any
country, except to the extent that such losses, liabilities,
and costs arise as a result of the Purchaser’s breach of
GCC Clause 32.2.
32.2 Such indemnity should not cover any use of the System,
including the Materials, other than for the purpose indicated
by or to be reasonably inferred from the Contract, any
infringement resulting from the use of the System, or any
products of the System produced thereby in association or
combination with any other goods or services not supplied
by the Supplier, where the infringement arises because of
such association or combination and not because of use of
the System in its own right.
32.3 Such indemnities should also not apply if any claim of
infringement:
(a) is asserted by a parent, subsidiary, or affiliate of the
Purchaser’s organization;
628 Section VI. General Conditions of Contract

(b) is a direct result of a design mandated by the

Purchaser’s Technical Requirements and the possibility
of such infringement was duly noted in the Supplier’s
Bid; or
(c) results from the alteration of the System, including the
Materials, by the Purchaser or any persons other than
the Supplier or a person authorized by the Supplier.
32.4 If any proceedings are brought or any claim is made against
the Purchaser arising out of the matters referred to in GCC
Clause 32.1, the Purchaser should promptly give the Supplier
notice of such proceedings or claims, and the Supplier may
at its own expense and in the Purchaser’s name conduct such
proceedings or claim and any negotiations for the settlement
of any such proceedings or claim.
If the Supplier fails to notify the Purchaser within twenty-
eight (28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Purchaser
should be free to conduct the same on its own behalf. Unless
the Supplier has so failed to notify the Purchaser within the
twenty-eight (28) days, the Purchaser should make no
admission that may be prejudicial to the defense of any such
proceedings or claim. The Purchaser should, at the
Supplier’s request, afford all available assistance to the
Supplier in conducting such proceedings or claim and should
be reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
32.5 The Purchaser should indemnify and hold harmless the
Supplier and its employees, officers, and Subcontractors
from and against any and all losses, liabilities, and costs
(including losses, liabilities, and costs incurred in defending
a claim alleging such a liability) that the Supplier or its
employees, officers, or Subcontractors may suffer as a result
of any infringement or alleged infringement of any
Intellectual Property Rights arising out of or in connection
with any design, data, drawing, specification, or other
documents or materials provided to the Supplier in
connection with this Contract by the Purchaser or any
persons (other than the Supplier) contracted by the
Purchaser, except to the extent that such losses, liabilities,
and costs arise as a result of the Supplier’s breach of GCC
Clause 32.8.
32.6 Such indemnity should not cover
(a) any use of the design, data, drawing, specification, or
other documents or materials, other than for the
purpose indicated by or to be reasonably inferred from
Section VI. General Conditions of Contract 629

the Contract;
(b) any infringement resulting from the use of the design,
data, drawing, specification, or other documents or
materials, or any products produced thereby, in
association or combination with any other Goods or
Services not provided by the Purchaser or any other
person contracted by the Purchaser, where the
infringement arises because of such association or
combination and not because of the use of the design,
data, drawing, specification, or other documents or
materials in its own right.
32.7 Such indemnities should also not apply:
(a) if any claim of infringement is asserted by a parent,
subsidiary, or affiliate of the Supplier’s organization;
(b) to the extent that any claim of infringement is caused
by the alteration, by the Supplier, or any persons
contracted by the Supplier, of the design, data,
drawing, specification, or other documents or materials
provided to the Supplier by the Purchaser or any
persons contracted by the Purchaser.
32.8 If any proceedings are brought or any claim is made against
the Supplier arising out of the matters referred to in GCC
Clause 32.5, the Supplier should promptly give the Purchaser
notice of such proceedings or claims, and the Purchaser may
at its own expense and in the Supplier’s name conduct such
proceedings or claim and any negotiations for the settlement
of any such proceedings or claim. If the Purchaser fails to
notify the Supplier within twenty-eight (28) days after
receipt of such notice that it intends to conduct any such
proceedings or claim, then the Supplier should be free to
conduct the same on its own behalf. Unless the Purchaser
has so failed to notify the Supplier within the twenty-eight
(28) days, the Supplier should make no admission that may
be prejudicial to the defense of any such proceedings or
claim. The Supplier should, at the Purchaser’s request,
afford all available assistance to the Purchaser in conducting
such proceedings or claim and should be reimbursed by the
Purchaser for all reasonable expenses incurred in so doing.
33. Limitation of 33.1 Provided the following does not exclude or limit any
Liability liabilities of either party in ways not permitted by applicable
law:
(a) the Supplier should not be liable to the Purchaser,
whether in contract, tort, or otherwise, for any indirect
or consequential loss or damage, loss of use, loss of
production, or loss of profits or interest costs, provided
630 Section VI. General Conditions of Contract

that this exclusion should not apply to any obligation of

the Supplier to pay liquidated damages to the
Purchaser; and
(b) the aggregate liability of the Supplier to the Purchaser,
whether under the Contract, in tort or otherwise, should
not exceed the total Contract Price, provided that this
limitation should not apply to any obligation of the
Supplier to indemnify the Purchaser with respect to
intellectual property rights infringement.

G. RISK DISTRIBUTION
34. Transfer of 34.1 With the exception of Software and Materials, the ownership
Ownership of the Information Technologies and other Goods should be
transferred to the Purchaser at the time of Delivery or
otherwise under terms that may be agreed upon and specified
in the Contract Agreement.
34.2 Ownership and the terms of usage of the Software and
Materials supplied under the Contract should be governed by
GCC Clause 15 (Copyright) and any elaboration in the
Technical Requirements.
34.3 Ownership of the Supplier’s Equipment used by the Supplier
and its Subcontractors in connection with the Contract
should remain with the Supplier or its Subcontractors.
35. Care of the 35.1 The Purchaser should become responsible for the care and
System custody of the System or Subsystems upon their Delivery.
The Purchaser should make good at its own cost any loss or
damage that may occur to the System or Subsystems from
any cause from the date of Delivery until the date of
Operational Acceptance of the System or Subsystems,
pursuant to GCC Clause 27 (Commissioning and Operational
Acceptance), excepting such loss or damage arising from
acts or omissions of the Supplier, its employees, or
subcontractors.
35.2 If any loss or damage occurs to the System or any part of the
System by reason of:
(a) (insofar as they relate to the country where the Project
Site is located) nuclear reaction, nuclear radiation,
radioactive contamination, a pressure wave caused by
aircraft or other aerial objects, or any other occurrences
that an experienced contractor could not reasonably
foresee, or if reasonably foreseeable could not
reasonably make provision for or insure against, insofar
as such risks are not normally insurable on the
Section VI. General Conditions of Contract 631

insurance market and are mentioned in the general

exclusions of the policy of insurance taken out under
GCC Clause 37;
(b) any use not in accordance with the Contract, by the
Purchaser or any third party;
(c) any use of or reliance upon any design, data, or
specification provided or designated by or on behalf of
the Purchaser, or any such matter for which the
Supplier has disclaimed responsibility in accordance
with GCC Clause 21.1.2,
the Purchaser should pay to the Supplier all sums payable in
respect of the System or Subsystems that have achieved
Operational Acceptance, notwithstanding that the same be
lost, destroyed, or damaged. If the Purchaser requests the
Supplier in writing to make good any loss or damage to the
System thereby occasioned, the Supplier should make good
the same at the cost of the Purchaser in accordance with
GCC Clause 39. If the Purchaser does not request the
Supplier in writing to make good any loss or damage to the
System thereby occasioned, the Purchaser should either
request a change in accordance with GCC Clause 39,
excluding the performance of that part of the System thereby
lost, destroyed, or damaged, or, where the loss or damage
affects a substantial part of the System, the Purchaser should
terminate the Contract pursuant to GCC Clause 41.1.
35.3 The Purchaser should be liable for any loss of or damage to
any Supplier’s Equipment which the Purchaser has
authorized to locate within the Purchaser's premises for use
in fulfillment of Supplier's obligations under the Contract,
except where such loss or damage arises from acts or
omissions of the Supplier, its employees, or subcontractors.
632 Section VI. General Conditions of Contract

36. Loss of or 36.1 The Supplier and each and every Subcontractor should abide
Damage to by the job safety, insurance, customs, and immigration
Property; measures prevalent and laws in force in the Purchaser’s
Accident or Country.
Injury to
Workers; 36.2 Subject to GCC Clause 36.3, the Supplier should indemnify
Indemnification and hold harmless the Purchaser and its employees and
officers from and against any and all losses, liabilities and
costs (including losses, liabilities, and costs incurred in
defending a claim alleging such a liability) that the Purchaser
or its employees or officers may suffer as a result of the
death or injury of any person or loss of or damage to any
property (other than the System, whether accepted or not)
arising in connection with the supply, installation, testing,
and Commissioning of the System and by reason of the
negligence of the Supplier or its Subcontractors, or their
employees, officers or agents, except any injury, death, or
property damage caused by the negligence of the Purchaser,
its contractors, employees, officers, or agents.
36.3 If any proceedings are brought or any claim is made against
the Purchaser that might subject the Supplier to liability
under GCC Clause 36.2, the Purchaser should promptly give
the Supplier notice of such proceedings or claims, and the
Supplier may at its own expense and in the Purchaser’s name
conduct such proceedings or claim and any negotiations for
the settlement of any such proceedings or claim. If the
Supplier fails to notify the Purchaser within twenty-eight
(28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Purchaser
should be free to conduct the same on its own behalf. Unless
the Supplier has so failed to notify the Purchaser within the
twenty-eight (28) day period, the Purchaser should make no
admission that may be prejudicial to the defense of any such
proceedings or claim. The Purchaser should, at the
Supplier’s request, afford all available assistance to the
Supplier in conducting such proceedings or claim and should
be reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
36.4 The Purchaser should indemnify and hold harmless the
Supplier and its employees, officers, and Subcontractors
from any and all losses, liabilities, and costs (including
losses, liabilities, and costs incurred in defending a claim
alleging such a liability) that the Supplier or its employees,
officers, or Subcontractors may suffer as a result of the death
or personal injury of any person or loss of or damage to
property of the Purchaser, other than the System not yet
achieving Operational Acceptance, that is caused by fire,
explosion, or any other perils, in excess of the amount
recoverable from insurances procured under GCC Clause 37
Section VI. General Conditions of Contract 633

(Insurances), provided that such fire, explosion, or other

perils were not caused by any act or failure of the Supplier.
36.5 If any proceedings are brought or any claim is made against
the Supplier that might subject the Purchaser to liability
under GCC Clause 36.4, the Supplier should promptly give
the Purchaser notice of such proceedings or claims, and the
Purchaser may at its own expense and in the Supplier’s name
conduct such proceedings or claim and any negotiations for
the settlement of any such proceedings or claim. If the
Purchaser fails to notify the Supplier within twenty-eight
(28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Supplier
should be free to conduct the same on its own behalf. Unless
the Purchaser has so failed to notify the Supplier within the
twenty-eight (28) days, the Supplier should make no
admission that may be prejudicial to the defense of any such
proceedings or claim. The Supplier should, at the
Purchaser’s request, afford all available assistance to the
Purchaser in conducting such proceedings or claim and
should be reimbursed by the Purchaser for all reasonable
expenses incurred in so doing.
36.6 The party entitled to the benefit of an indemnity under this
GCC Clause 36 should take all reasonable measures to
mitigate any loss or damage that has occurred. If the party
fails to take such measures, the other party’s liabilities
should be correspondingly reduced.
37. Insurances 37.1 The Supplier should at its expense take out and maintain in
effect, or cause to be taken out and maintained in effect,
during the performance of the Contract, the insurance set
forth below. The identity of the insurers and the form of the
policies should be subject to the approval of the Purchaser,
who should not unreasonably withhold such approval.
(a) Cargo Insurance During Transport
as applicable, 110 percent of the price of the
Information Technologies and other Goods in a freely
convertible currency, covering the Goods from physical
loss or damage during shipment through receipt at the
Project Site.
(b) Installation “All Risks” Insurance
as applicable, 110 percent of the price of the
Information Technologies and other Goods covering
the Goods at the site from all risks of physical loss or
damage (excluding only perils commonly excluded
under “all risks” insurance policies of this type by
reputable insurers) occurring prior to Operational
634 Section VI. General Conditions of Contract

Acceptance of the System.

(c) Third-Party Liability Insurance
On terms as specified in the SCC, covering bodily
injury or death suffered by third parties (including the
Purchaser’s personnel) and loss of or damage to
property (including the Purchaser’s property and any
Subsystems that have been accepted by the Purchaser)
occurring in connection with the supply and installation
of the Information System.
(d) Automobile Liability Insurance
In accordance with the statutory requirements
prevailing in the Purchaser’s Country, covering use of
all vehicles used by the Supplier or its Subcontractors
(whether or not owned by them) in connection with the
execution of the Contract.
(e) Other Insurance (if any), as specified in the SCC.
37.2 The Purchaser should be named as co-insured under all
insurance policies taken out by the Supplier pursuant to GCC
Clause 37.1, except for the Third-Party Liability, and the
Supplier’s Subcontractors should be named as co-insured
under all insurance policies taken out by the Supplier
pursuant to GCC Clause 37.1 except for Cargo Insurance
During Transport. All insurer’s rights of subrogation against
such co-insured for losses or claims arising out of the
performance of the Contract should be waived under such
policies.
37.3 The Supplier should deliver to the Purchaser certificates of
insurance (or copies of the insurance policies) as evidence
that the required policies are in full force and effect.
37.4 The Supplier should ensure that, where applicable, its
Subcontractor(s) should take out and maintain in effect
adequate insurance policies for their personnel and vehicles
and for work executed by them under the Contract, unless
such Subcontractors are covered by the policies taken out by
the Supplier.
37.5 If the Supplier fails to take out and/or maintain in effect the
insurance referred to in GCC Clause 37.1, the Purchaser may
take out and maintain in effect any such insurance and may
from time to time deduct from any amount due the Supplier
under the Contract any premium that the Purchaser should
have paid to the insurer or may otherwise recover such
amount as a debt due from the Supplier.
Section VI. General Conditions of Contract 635

37.6 Unless otherwise provided in the Contract, the Supplier

should prepare and conduct all and any claims made under
the policies affected by it pursuant to this GCC Clause 37,
and all monies payable by any insurers should be paid to the
Supplier. The Purchaser should give to the Supplier all such
reasonable assistance as may be required by the Supplier in
connection with any claim under the relevant insurance
policies. With respect to insurance claims in which the
Purchaser’s interest is involved, the Supplier should not give
any release or make any compromise with the insurer
without the prior written consent of the Purchaser. With
respect to insurance claims in which the Supplier’s interest is
involved, the Purchaser should not give any release or make
any compromise with the insurer without the prior written
consent of the Supplier.
38. Force Majeure 38.1 “Force Majeure” should mean any event beyond the
reasonable control of the Purchaser or of the Supplier, as the
case may be, and which is unavoidable notwithstanding the
reasonable care of the party affected and should include,
without limitation, the following:
(a) war, hostilities, or warlike operations (whether a state
of war be declared or not), invasion, act of foreign
enemy, and civil war;
(b) rebellion, revolution, insurrection, mutiny, usurpation
of civil or military government, conspiracy, riot, civil
commotion, and terrorist acts;
(c) confiscation, nationalization, mobilization,
commandeering or requisition by or under the order of
any government or de jure or de facto authority or
ruler, or any other act or failure to act of any local state
or national government authority;
(d) strike, sabotage, lockout, embargo, import restriction,
port congestion, lack of usual means of public
transportation and communication, industrial dispute,
shipwreck, shortage or restriction of power supply,
epidemics, quarantine, and plague;
(e) earthquake, landslide, volcanic activity, fire, flood or
inundation, tidal wave, typhoon or cyclone, hurricane,
storm, lightning, or other inclement weather condition,
nuclear and pressure waves, or other natural or
physical disaster;
(f) failure, by the Supplier, to obtain the necessary export
permit(s) from the governments of the Country(s) of
Origin of the Information Technologies or other
Goods, or Supplier’s Equipment provided that the
636 Section VI. General Conditions of Contract

Supplier has made all reasonable efforts to obtain the

required export permit(s), including the exercise of due
diligence in determining the eligibility of the System
and all of its components for receipt of the necessary
export permits.
38.2 If either party is prevented, hindered, or delayed from or in
performing any of its obligations under the Contract by an
event of Force Majeure, then it should notify the other in
writing of the occurrence of such event and the
circumstances of the event of Force Majeure within fourteen
(14) days after the occurrence of such event.
38.3 The party who has given such notice should be excused from
the performance or punctual performance of its obligations
under the Contract for so long as the relevant event of Force
Majeure continues and to the extent that such party’s
performance is prevented, hindered, or delayed. The Time
for Achieving Operational Acceptance should be extended in
accordance with GCC Clause 40 (Extension of Time for
Achieving Operational Acceptance).
38.4 The party or parties affected by the event of Force Majeure
should use reasonable efforts to mitigate the effect of the
event of Force Majeure upon its or their performance of the
Contract and to fulfill its or their obligations under the
Contract, but without prejudice to either party’s right to
terminate the Contract under GCC Clause 38.6.
38.5 No delay or nonperformance by either party to this Contract
caused by the occurrence of any event of Force Majeure
should:
(a) constitute a default or breach of the Contract;
(b) (subject to GCC Clauses 35.2, 38.3, and 38.4) give rise
to any claim for damages or additional cost or expense
occasioned by the delay or nonperformance,
if, and to the extent that, such delay or nonperformance is
caused by the occurrence of an event of Force Majeure.
38.6 If the performance of the Contract is substantially prevented,
hindered, or delayed for a single period of more than sixty
(60) days or an aggregate period of more than one hundred
and twenty (120) days on account of one or more events of
Force Majeure during the time period covered by the
Contract, the parties will attempt to develop a mutually
satisfactory solution, failing which, either party may
terminate the Contract by giving a notice to the other.
38.7 In the event of termination pursuant to GCC Clause 38.6, the
Section VI. General Conditions of Contract 637

rights and obligations of the Purchaser and the Supplier

should be as specified in GCC Clauses 41.1.2 and 41.1.3.
38.8 Notwithstanding GCC Clause 38.5, Force Majeure should
not apply to any obligation of the Purchaser to make
payments to the Supplier under this Contract.

H. CHANGE IN CONTRACT ELEMENTS

39. Changes to the 39.1 Introducing a Change
System
39.1.1 Subject to GCC Clauses 39.2.5 and 39.2.7, the
Purchaser should have the right to propose, and
subsequently require, the Project Manager to order
the Supplier from time to time during the
performance of the Contract to make any change,
modification, addition, or deletion to, in, or from the
System (interchangeably called “Change”), provided
that such Change falls within the general scope of
the System, does not constitute unrelated work, and
is technically practicable, taking into account both
the state of advancement of the System and the
technical compatibility of the Change envisaged
with the nature of the System as originally specified
in the Contract.
A Change may involve, but is not restricted to, the
substitution of updated Information Technologies
and related Services in accordance with
GCC Clause 23 (Product Upgrades).
39.1.2 The Supplier may from time to time during its
performance of the Contract propose to the
Purchaser (with a copy to the Project Manager) any
Change that the Supplier considers necessary or
desirable to improve the quality or efficiency of the
System. The Purchaser may at its discretion
approve or reject any Change proposed by the
Supplier.
39.1.3 Notwithstanding GCC Clauses 39.1.1 and 39.1.2, no
change made necessary because of any default of the
Supplier in the performance of its obligations under
the Contract should be deemed to be a Change, and
such change should not result in any adjustment of
the Contract Price or the Time for Achieving
Operational Acceptance.
39.1.4 The procedure on how to proceed with and execute
Changes is specified in GCC Clauses 39.2 and 39.3,
638 Section VI. General Conditions of Contract

and further details and sample forms are provided in

the Sample Contractual Forms Section in the
Bidding Documents.
39.1.5 Moreover, the Purchaser and Supplier will agree,
during development of the Project Plan, to a date
prior to the scheduled date for Operational
Acceptance, after which the Technical Requirements
for the System should be “frozen.” Any Change
initiated after this time will be dealt with after
Operational Acceptance.
39.2 Changes Originating from Purchaser
39.2.1 If the Purchaser proposes a Change pursuant to GCC
Clauses 39.1.1, it should send to the Supplier a
“Request for Change Proposal,” requiring the
Supplier to prepare and furnish to the Project
Manager as soon as reasonably practicable a
“Change Proposal,” which should include the
following:
(a) brief description of the Change;
(b) impact on the Time for Achieving Operational
Acceptance;
(c) detailed estimated cost of the Change;
(d) effect on Functional Guarantees (if any);
(e) effect on any other provisions of the Contract.
39.2.2 Prior to preparing and submitting the “Change
Proposal,” the Supplier should submit to the Project
Manager a “Change Estimate Proposal,” which
should be an estimate of the cost of preparing the
Change Proposal, plus a first approximation of the
suggested approach and cost for implementing the
changes. Upon receipt of the Supplier’s Change
Estimate Proposal, the Purchaser should do one of
the following:
(a) accept the Supplier’s estimate with instructions
to the Supplier to proceed with the preparation
of the Change Proposal;
(b) advise the Supplier of any part of its Change
Estimate Proposal that is unacceptable and
request the Supplier to review its estimate;
(c) advise the Supplier that the Purchaser does not
intend to proceed with the Change.
Section VI. General Conditions of Contract 639

39.2.3 Upon receipt of the Purchaser’s instruction to

proceed under GCC Clause 39.2.2 (a), the Supplier
should, with proper expedition, proceed with the
preparation of the Change Proposal, in accordance
with GCC Clause 39.2.1. The Supplier, at its
discretion, may specify a validity period for the
Change Proposal, after which if the Purchaser and
Supplier has not reached agreement in accordance
with GCC Clause 39.2.6, then GCC Clause 39.2.7
should apply.
39.2.4 The pricing of any Change should, as far as
practicable, be calculated in accordance with the
rates and prices included in the Contract. If the
nature of the Change is such that the Contract rates
and prices are inequitable, the parties to the Contract
should agree on other specific rates to be used for
valuing the Change.
39.2.5 If before or during the preparation of the Change
Proposal it becomes apparent that the aggregate
impact of compliance with the Request for Change
Proposal and with all other Change Orders that have
already become binding upon the Supplier under this
GCC Clause 39 would be to increase or decrease the
Contract Price as originally set forth in Article 2
(Contract Price) of the Contract Agreement by more
than fifteen (15) percent, the Supplier may give a
written notice of objection to this Request for
Change Proposal prior to furnishing the Change
Proposal. If the Purchaser accepts the Supplier’s
objection, the Purchaser should withdraw the
proposed Change and should notify the Supplier in
writing of its acceptance.
The Supplier’s failure to so object to a Request for
Change Proposal should neither affect its right to
object to any subsequent requested Changes or
Change Orders, nor affect its right to take into
account, when making such subsequent objection,
the percentage increase or decrease in the Contract
Price that any Change not objected to by the
Supplier represents.
39.2.6 Upon receipt of the Change Proposal, the Purchaser
and the Supplier should mutually agree upon all
matters contained in the Change Proposal. Within
fourteen (14) days after such agreement, the
Purchaser should, if it intends to proceed with the
Change, issue the Supplier a Change Order. If the
Purchaser is unable to reach a decision within
640 Section VI. General Conditions of Contract

fourteen (14) days, it should notify the Supplier with

details of when the Supplier can expect a decision.
If the Purchaser decides not to proceed with the
Change for whatever reason, it should, within the
said period of fourteen (14) days, notify the Supplier
accordingly. Under such circumstances, the
Supplier should be entitled to reimbursement of all
costs reasonably incurred by it in the preparation of
the Change Proposal, provided that these do not
exceed the amount given by the Supplier in its
Change Estimate Proposal submitted in accordance
with GCC Clause 39.2.2.
39.2.7 If the Purchaser and the Supplier cannot reach
agreement on the price for the Change, an equitable
adjustment to the Time for Achieving Operational
Acceptance, or any other matters identified in the
Change Proposal, the Change will not be
implemented. However, this provision does not
limit the rights of either party under GCC Clause 43
(Settlement of Disputes).
39.3 Changes Originating from Supplier
If the Supplier proposes a Change pursuant to GCC
Clause 39.1.2, the Supplier should submit to the Project
Manager a written “Application for Change Proposal,”
giving reasons for the proposed Change and including the
information specified in GCC Clause 39.2.1. Upon receipt
of the Application for Change Proposal, the parties should
follow the procedures outlined in GCC Clauses 39.2.6 and
39.2.7. However, should the Purchaser choose not to
proceed or the Purchaser and the Supplier cannot come to
agreement on the change during any validity period that the
Supplier may specify in its Application for Change Proposal,
the Supplier should not be entitled to recover the costs of
preparing the Application for Change Proposal, unless
subject to an agreement between the Purchaser and the
Supplier to the contrary.
40. Extension of 40.1 The time(s) for achieving Operational Acceptance specified
Time for in the Schedule of Implementation should be extended if the
Achieving Supplier is delayed or impeded in the performance of any of
Operational its obligations under the Contract by reason of any of the
Acceptance following:
(a) any Change in the System as provided in GCC
Clause 39 (Change in the Information System);
(b) any occurrence of Force Majeure as provided in GCC
Clause 38 (Force Majeure);
Section VI. General Conditions of Contract 641

(c) default of the Purchaser; or

(d) any other matter specifically mentioned in the Contract;
by such period as should be fair and reasonable in all the
circumstances and as should fairly reflect the delay or
impediment sustained by the Supplier.
40.2 Except where otherwise specifically provided in the
Contract, the Supplier should submit to the Project Manager
a notice of a claim for an extension of the time for achieving
Operational Acceptance, together with particulars of the
event or circumstance justifying such extension as soon as
reasonably practicable after the commencement of such
event or circumstance. As soon as reasonably practicable
after receipt of such notice and supporting particulars of the
claim, the Purchaser and the Supplier should agree upon the
period of such extension. In the event that the Supplier does
not accept the Purchaser’s estimate of a fair and reasonable
time extension, the Supplier should be entitled to refer the
matter to the provisions for the Settlement of Disputes
pursuant to GCC Clause 43.
40.3 The Supplier should at all times use its reasonable efforts to
minimize any delay in the performance of its obligations
under the Contract.
41. Termination 41.1 Termination for Purchaser’s Convenience
41.1.1 The Purchaser may at any time terminate the
Contract for any reason by giving the Supplier a
notice of termination that refers to this GCC
Clause 41.1.
41.1.2 Upon receipt of the notice of termination under GCC
Clause 41.1.1, the Supplier should either as soon as
reasonably practical or upon the date specified in the
notice of termination
(a) cease all further work, except for such work as
the Purchaser may specify in the notice of
termination for the sole purpose of protecting
that part of the System already executed, or any
work required to leave the site in a clean and
safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to GCC
Clause 41.1.2 (d) (ii) below;
(c) remove all Supplier’s Equipment from the site,
repatriate the Supplier’s and its Subcontractors’
personnel from the site, remove from the site any
642 Section VI. General Conditions of Contract

wreckage, rubbish, and debris of any kind;

(d) in addition, the Supplier, subject to the payment
specified in GCC Clause 41.1.3, should
(i) deliver to the Purchaser the parts of the
System executed by the Supplier up to the
date of termination;
(ii) to the extent legally possible, assign to the
Purchaser all right, title, and benefit of the
Supplier to the System, or Subsystem, as at
the date of termination, and, as may be
required by the Purchaser, in any
subcontracts concluded between the
Supplier and its Subcontractors;
(iii) deliver to the Purchaser all nonproprietary
drawings, specifications, and other
documents prepared by the Supplier or its
Subcontractors as of the date of
termination in connection with the System.
41.1.3 In the event of termination of the Contract under
GCC Clause 41.1.1, the Purchaser should pay to the
Supplier the following amounts:
(a) the Contract Price, properly attributable to the
parts of the System executed by the Supplier as
of the date of termination;
(b) the costs reasonably incurred by the Supplier in
the removal of the Supplier’s Equipment from
the site and in the repatriation of the Supplier’s
and its Subcontractors’ personnel;
(c) any amount to be paid by the Supplier to its
Subcontractors in connection with the
termination of any subcontracts, including any
cancellation charges;
(d) costs incurred by the Supplier in protecting the
System and leaving the site in a clean and safe
condition pursuant to GCC Clause 41.1.2 (a); and
(e) the cost of satisfying all other obligations,
commitments, and claims that the Supplier may
in good faith have undertaken with third parties
in connection with the Contract and that are not
covered by GCC Clauses 41.1.3 (a) through (d)
above.
Section VI. General Conditions of Contract 643

41.2 Termination for Supplier’s Default

41.2.1 The Purchaser, without prejudice to any other
rights or remedies it may possess, may terminate
the Contract forthwith in the following
circumstances by giving a notice of termination
and its reasons therefore to the Supplier, referring
to this GCC Clause 41.2:
(a) if the Supplier becomes bankrupt or insolvent,
has a receiving order issued against it,
compounds with its creditors, or, if the Supplier
is a corporation, a resolution is passed or order is
made for its winding up (other than a voluntary
liquidation for the purposes of amalgamation or
reconstruction), a receiver is appointed over any
part of its undertaking or assets, or if the
Supplier takes or suffers any other analogous
action in consequence of debt;
(b) if the Supplier assigns or transfers the Contract
or any right or interest therein in violation of the
provision of GCC Clause 42 (Assignment); or
(c) if the Supplier and/or its subcontractors, in the
judgment of the Purchaser, have engaged in
corrupt, fraudulent, collusive, coercive or
obstructive practices, in competing for or in
executing the Contract, including but not limited
to willful misrepresentation of facts concerning
ownership of Intellectual Property Rights in, or
proper authorization and/or licenses from the
owner to offer, the hardware, software, or
materials provided under this Contract.
41.2.2 If the Supplier:
(a) has abandoned or repudiated the Contract;
(b) has without valid reason failed to commence
work on the System promptly;
(c) persistently fails to execute the Contract in
accordance with the Contract or persistently
neglects to carry out its obligations under the
Contract without just cause;
(d) refuses or is unable to provide sufficient
Materials, Services, or labor to execute and
complete the System in the manner specified in
the Agreed Project Plan furnished under GCC
Clause 19 at rates of progress that give
644 Section VI. General Conditions of Contract

reasonable assurance to the Purchaser that the

Supplier can attain Operational Acceptance of
the System by the Time for Achieving
Operational Acceptance as extended;
then the Purchaser may, without prejudice to any
other rights it may possess under the Contract, give a
notice to the Supplier stating the nature of the
default and requiring the Supplier to remedy the
same. If the Supplier fails to remedy or to take steps
to remedy the same within fourteen (14) days of its
receipt of such notice, then the Purchaser may
terminate the Contract forthwith by giving a notice
of termination to the Supplier that refers to this GCC
Clause 41.2.
41.2.3 Upon receipt of the notice of termination under GCC
Clauses 41.2.1 or 41.2.2, the Supplier should, either
immediately or upon such date as is specified in the
notice of termination:
(a) cease all further work, except for such work as
the Purchaser may specify in the notice of
termination for the sole purpose of protecting
that part of the System already executed or any
work required to leave the site in a clean and
safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to GCC
Clause 41.2.3 (d) below;
(c) deliver to the Purchaser the parts of the System
executed by the Supplier up to the date of
termination;
(d) to the extent legally possible, assign to the
Purchaser all right, title and benefit of the
Supplier to the System or Subsystems as at the
date of termination, and, as may be required by
the Purchaser, in any subcontracts concluded
between the Supplier and its Subcontractors;
(e) deliver to the Purchaser all drawings,
specifications, and other documents prepared by
the Supplier or its Subcontractors as at the date
of termination in connection with the System.
41.2.4 The Purchaser may enter upon the site, expel the
Supplier, and complete the System itself or by
employing any third party. Upon completion of the
System or at such earlier date as the Purchaser
Section VI. General Conditions of Contract 645

thinks appropriate, the Purchaser should give notice

to the Supplier that such Supplier’s Equipment will
be returned to the Supplier at or near the site and
should return such Supplier’s Equipment to the
Supplier in accordance with such notice. The
Supplier should thereafter without delay and at its
cost remove or arrange removal of the same from
the site.
41.2.5 Subject to GCC Clause 41.2.6, the Supplier should
be entitled to be paid the Contract Price attributable
to the portion of the System executed as at the date
of termination and the costs, if any, incurred in
protecting the System and in leaving the site in a
clean and safe condition pursuant to GCC
Clause 41.2.3 (a). Any sums due the Purchaser from
the Supplier accruing prior to the date of termination
should be deducted from the amount to be paid to
the Supplier under this Contract.
41.2.6 If the Purchaser completes the System, the cost of
completing the System by the Purchaser should be
determined. If the sum that the Supplier is entitled
to be paid, pursuant to GCC Clause 41.2.5, plus the
reasonable costs incurred by the Purchaser in
completing the System, exceeds the Contract Price,
the Supplier should be liable for such excess. If
such excess is greater than the sums due the Supplier
under GCC Clause 41.2.5, the Supplier should pay
the balance to the Purchaser, and if such excess is
less than the sums due the Supplier under GCC
Clause 41.2.5, the Purchaser should pay the balance
to the Supplier. The Purchaser and the Supplier
should agree, in writing, on the computation
described above and the manner in which any sums
should be paid.
41.3 Termination by Supplier
41.3.1 If:
(a) the Purchaser has failed to pay the Supplier any
sum due under the Contract within the specified
period, has failed to approve any invoice or
supporting documents without just cause
pursuant to the SCC, or commits a substantial
breach of the Contract, the Supplier may give a
notice to the Purchaser that requires payment of
such sum, with interest on this sum as stipulated
in GCC Clause 12.3, requires approval of such
invoice or supporting documents, or specifies the
646 Section VI. General Conditions of Contract

breach and requires the Purchaser to remedy the

same, as the case may be. If the Purchaser fails
to pay such sum together with such interest, fails
to approve such invoice or supporting documents
or give its reasons for withholding such
approval, fails to remedy the breach or take steps
to remedy the breach within fourteen (14) days
after receipt of the Supplier’s notice; or
(b) the Supplier is unable to carry out any of its
obligations under the Contract for any reason
attributable to the Purchaser, including but not
limited to the Purchaser’s failure to provide
possession of or access to the site or other areas
or failure to obtain any governmental permit
necessary for the execution and/or completion of
the System;
then the Supplier may give a notice to the Purchaser
of such events, and if the Purchaser has failed to pay
the outstanding sum, to approve the invoice or
supporting documents, to give its reasons for
withholding such approval, or to remedy the breach
within twenty-eight (28) days of such notice, or if
the Supplier is still unable to carry out any of its
obligations under the Contract for any reason
attributable to the Purchaser within twenty-eight
(28) days of the said notice, the Supplier may by a
further notice to the Purchaser referring to this GCC
Clause 41.3.1, forthwith terminate the Contract.
41.3.2 The Supplier may terminate the Contract
immediately by giving a notice to the Purchaser to
that effect, referring to this GCC Clause 41.3.2, if
the Purchaser becomes bankrupt or insolvent, has a
receiving order issued against it, compounds with its
creditors, or, being a corporation, if a resolution is
passed or order is made for its winding up (other
than a voluntary liquidation for the purposes of
amalgamation or reconstruction), a receiver is
appointed over any part of its undertaking or assets,
or if the Purchaser takes or suffers any other
analogous action in consequence of debt.
41.3.3 If the Contract is terminated under GCC
Clauses 41.3.1 or 41.3.2, then the Supplier should
immediately:
(a) cease all further work, except for such work as
may be necessary for the purpose of protecting
that part of the System already executed, or any
Section VI. General Conditions of Contract 647

work required to leave the site in a clean and

safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to
Clause 41.3.3 (d) (ii);
(c) remove all Supplier’s Equipment from the site
and repatriate the Supplier’s and its
Subcontractor’s personnel from the site.
(d) In addition, the Supplier, subject to the payment
specified in GCC Clause 41.3.4, should:
(i) deliver to the Purchaser the parts of the
System executed by the Supplier up to the
date of termination;
(ii) to the extent legally possible, assign to the
Purchaser all right, title, and benefit of the
Supplier to the System, or Subsystems, as
of the date of termination, and, as may be
required by the Purchaser, in any
subcontracts concluded between the
Supplier and its Subcontractors;
(iii) to the extent legally possible, deliver to the
Purchaser all drawings, specifications, and
other documents prepared by the Supplier
or its Subcontractors as of the date of
termination in connection with the System.
41.3.4 If the Contract is terminated under GCC
Clauses 41.3.1 or 41.3.2, the Purchaser should pay
to the Supplier all payments specified in GCC
Clause 41.1.3 and reasonable compensation for all
loss, except for loss of profit, or damage sustained
by the Supplier arising out of, in connection with, or
in consequence of such termination.
41.3.5 Termination by the Supplier pursuant to this GCC
Clause 41.3 is without prejudice to any other rights
or remedies of the Supplier that may be exercised in
lieu of or in addition to rights conferred by GCC
Clause 41.3.
41.4 In this GCC Clause 41, the expression “portion of the
System executed” should include all work executed, Services
provided, and all Information Technologies, or other Goods
acquired (or subject to a legally binding obligation to
purchase) by the Supplier and used or intended to be used for
the purpose of the System, up to and including the date of
648 Section VI. General Conditions of Contract

termination.
41.5 In this GCC Clause 41, in calculating any monies due from
the Purchaser to the Supplier, account should be taken of any
sum previously paid by the Purchaser to the Supplier under
the Contract, including any advance payment paid pursuant
to the SCC.
42. Assignment 42.l Neither the Purchaser nor the Supplier should, without the
express prior written consent of the other, assign to any third
party the Contract or any part thereof, or any right, benefit,
obligation, or interest therein or thereunder, except that the
Supplier should be entitled to assign either absolutely or by
way of charge any monies due and payable to it or that may
become due and payable to it under the Contract.

I. SETTLEMENT OF DISPUTES
43. Settlement of 43.1 Adjudication
Disputes
43.1.1 If any dispute of any kind whatsoever should arise
between the Purchaser and the Supplier in connection
with or arising out of the Contract, including without
prejudice to the generality of the foregoing, any
question regarding its existence, validity, or
termination, or the operation of the System (whether
during the progress of implementation or after its
achieving Operational Acceptance and whether before
or after the termination, abandonment, or breach of
the Contract), the parties should seek to resolve any
such dispute by mutual consultation. If the parties fail
to resolve such a dispute by mutual consultation
within fourteen (14) days after one party has notified
the other in writing of the dispute, then, if the
Contract Agreement in Appendix 2 includes and
names an Adjudicator, the dispute should, within
another fourteen (14) days, be referred in writing by
either party to the Adjudicator, with a copy to the
other party. If there is no Adjudicator specified in the
Contract Agreement, the mutual consultation period
stated above should last twenty-eight (28) days
(instead of fourteen), upon expiry of which either
party may move to the notification of arbitration
pursuant to GCC Clause 43.2.1.
43.1.2 The Adjudicator should give his or her decision in
writing to both parties within twenty-eight (28) days
of the dispute being referred to the Adjudicator. If the
Adjudicator has done so, and no notice of intention to
Section VI. General Conditions of Contract 649

commence arbitration has been given by either the

Purchaser or the Supplier within fifty-six (56) days of
such reference, the decision should become final and
binding upon the Purchaser and the Supplier. Any
decision that has become final and binding should be
implemented by the parties forthwith.
43.1.3 The Adjudicator should be paid an hourly fee at
the rate specified in the Contract Agreement plus
reasonable expenditures incurred in the execution of
duties as Adjudicator, and these costs should be
divided equally between the Purchaser and the
Supplier.
43.1.4 Should the Adjudicator resign or die, or should the
Purchaser and the Supplier agree that the Adjudicator
is not fulfilling his or her functions in accordance with
the provisions of the Contract, a new Adjudicator
should be jointly appointed by the Purchaser and the
Supplier. Failing agreement between the two within
twenty-eight (28) days, the new Adjudicator should be
appointed at the request of either party by the
Appointing Authority specified in the SCC, or, if no
Appointing Authority is specified in SCC, the
Contract should, from this point onward and until the
parties may otherwise agree on an Adjudicator or an
Appointing Authority, be implemented as if there is
no Adjudicator.
43.2 Arbitration
43.2.1 If
(a) the Purchaser or the Supplier is dissatisfied with
the Adjudicator’s decision and acts before this
decision has become final and binding pursuant
to GCC Clause 43.1.2, or
(b) the Adjudicator fails to give a decision within the
allotted time from referral of the dispute pursuant
to GCC Clause 43.1.2, and the Purchaser or the
Supplier acts within the following fourteen (14)
days, or
(c) in the absence of an Adjudicator from the
Contract Agreement, the mutual consultation
pursuant to GCC Clause 43.1.1 expires without
resolution of the dispute and the Purchaser or the
Supplier acts within the following fourteen (14)
days,
then either the Purchaser or the Supplier may act to
650 Section VI. General Conditions of Contract

give notice to the other party, with a copy for

information to the Adjudicator in case an Adjudicator
had been involved, of its intention to commence
arbitration, as provided below, as to the matter in
dispute, and no arbitration in respect of this matter
may be commenced unless such notice is given.
43.2.2 Any dispute in respect of which a notice of
intention to commence arbitration has been given, in
accordance with GCC Clause 43.2.1, should be finally
settled by arbitration. Arbitration may be commenced
prior to or after Installation of the Information System.
43.2.3 Arbitration proceedings should be conducted in
accordance with the rules of procedure specified in
the SCC.
43.3 Notwithstanding any reference to the Adjudicator or
arbitration in this clause,
(a) the parties should continue to perform their respective
obligations under the Contract unless they otherwise
agree;
(b) the Purchaser should pay the Supplier any monies due
the Supplier.
Section VII. Special Conditions of Contract 651

SECTION VII. SPECIAL CONDITIONS OF CONTRACT

(SCC)

Table of Clauses
A. Contract and Interpretation.........................................................................................651
1. Definitions (GCC Clause 1)....................................................................................651
2. Contract Documents (GCC Clause 2).....................................................................651
3. Interpretation (GCC Clause 3)................................................................................651
4. Notices (GCC Clause 4)..........................................................................................652
5. Governing Law (GCC Clause 5).............................................................................652
6. Fraud and Corruption (GCC Clause 6)...................................................................652
B. Subject Matter of Contract...........................................................................................652
7. Scope of the System (GCC Clause 7).....................................................................652
8. Time for Commencement and Operational Acceptance (GCC Clause 8)..............652
9. Supplier’s Responsibilities (GCC Clause 9)...........................................................652
10. Purchaser’s Responsibilities (GCC Clause 10).......................................................653
C. Payment...........................................................................................................................653
11. Contract Price (GCC Clause 11).............................................................................653
12. Terms of Payment (GCC Clause 12)......................................................................653
13. Securities (GCC Clause 13)....................................................................................654
14. Taxes and Duties (GCC Clause 14)........................................................................654
D. Intellectual Property......................................................................................................655
15. Copyright (GCC Clause 15)....................................................................................655
16. Software License Agreements (GCC Clause 16)....................................................655
17. Confidential Information (GCC Clause 17)............................................................655
E. Supply, Installation, Testing, Commissioning, and Acceptance of the System
................................................................................................................................................656
18. Representatives (GCC Clause 18)..........................................................................656
19. Project Plan (GCC Clause 19)................................................................................656
20. Subcontracting (GCC Clause 20)............................................................................657
21. Design and Engineering (GCC Clause 21).............................................................657
22. Procurement, Delivery, and Transport (GCC Clause 22).......................................657
23. Product Upgrades (GCC Clause 23).......................................................................657
24. Implementation, Installation, and Other Services (GCC Clause 24)......................657
25. Inspections and Tests (GCC Clause 25).................................................................657
26. Installation of the System (GCC Clause 26)...........................................................657
27. Commissioning and Operational Acceptance (GCC Clause 27)............................657
F. Guarantees and Liabilities.............................................................................................658
28. Operational Acceptance Time Guarantee (GCC Clause 28)..................................658
29. Defect Liability (GCC Clause 29)..........................................................................658
30. Functional Guarantees (GCC Clause 30)................................................................658
652 Section VII. Special Conditions of Contract

31. Intellectual Property Rights Warranty (GCC Clause 31).......................................658

32. Intellectual Property Rights Indemnity (GCC Clause 32)......................................658
33. Limitation of Liability (GCC Clause 33)................................................................658
G. Risk Distribution............................................................................................................659
34. Transfer of Ownership (GCC Clause 34)...............................................................659
35. Care of the System (GCC Clause 35).....................................................................659
36. Loss of or Damage to Property; Accident or Injury to Workers;
Indemnification (GCC Clause 36)..........................................................................659
37. Insurances (GCC Clause 37)...................................................................................659
38. Force Majeure (GCC Clause 38)............................................................................659
H. Change in Contract Elements.......................................................................................659
39. Changes to the System (GCC Clause 39)...............................................................659
40. Extension of Time for Achieving Operational Acceptance (GCC Clause 40)
.................................................................................................................................660
41. Termination (GCC Clause 41)................................................................................660
42. Assignment (GCC Clause 42).................................................................................661
I. Settlement of Disputes.....................................................................................................661
43. Settlement of Disputes (GCC Clause 43)...............................................................661
Section VII. Special Conditions of Contract 653

Special Conditions of Contract

The following Special Conditions of Contract (SCC) should supplement or amend the
General Conditions of Contract (GCC). Whenever there is a conflict, the provisions
of the SCC should prevail over those in the General Conditions of Contract. For the
purposes of clarity, any referenced GCC clause numbers are indicated in the left
column of the SCC.

A. CONTRACT AND INTERPRETATION

1. Definitions (GCC Clause 1)

GCC 1.1 (a) (ix) The applicable edition of the Procurement Guidelines is dated: January
2011.

GCC 1.1 (b) (i) The Purchaser is: the National Agency of Fiscal Administration.

GCC 1.1 (b) (ii) The Project Manager is: [ insert: name and/or the official title of
Project Manager].

GCC 1.1 (e) (i) The Purchaser’s Country is: Romania

GCC 1.1 (e) (iii) There are no Special Conditions associated with GCC 1.1 (e) (iii)..

GCC 1.1 (e) (x) There are no Special Conditions associated with GCC 1.1 (e) (x).

2. Contract Documents (GCC Clause 2)

GCC 2 There are no Special Conditions of Contract applicable to GCC Clause
2.

3. Interpretation (GCC Clause 3)

GCC 3.1.1 There are no Special Conditions of Contract applicable to GCC Clause
3.1.1

4. Notices (GCC Clause 4)

GCC 4.3 Address of the Project Manager:

17, Apolodor Street, 050741, Sector 5, Bucharest, Romania,

654 Section VII. Special Conditions of Contract

Phone: +4021 387 20 57

+4021 38720 58

Facsimile: +4021 319 96 71

E-mail:[email protected]

5. Governing Law (GCC Clause 5)

GCC 5.1 The Contract should be interpreted in accordance with the laws of:
Romania.

6. Fraud and Corruption (GCC Clause 6)

GCC 6 There are no Special Conditions of Contract applicable to GCC Clause
6

B. SUBJECT MATTER OF CONTRACT

7. Scope of the System (GCC Clause 7)

GCC 7.3 The Supplier’s obligations under the Contract will include the following
recurrent cost items: Technical Support (as specified in
Paragraph 6.17 of the Technical Requirements)

8. Time for Commencement and Operational Acceptance (GCC Clause 8)

GCC 8.1 The Supplier should commence work on the System within: thirty
(30)days from the Effective Date of the Contract.

9. Supplier’s Responsibilities (GCC Clause 9)

GCC 9.9 It is forbidden for the Supplier to recruit and hire during the entire
period of Contract implementation and for a period of 3 (three)
years after completion of the Contract, either on limited time or
permanent basis or through any other contractual agreement,
any of the Purchaser’s staff members, involved in the
implementation of the Contract.
Section VII. Special Conditions of Contract 655

10. Purchaser’s Responsibilities (GCC Clause 10)

GCC 10.12 There are no Special Conditions of Contract applicable to GCC Clause
10.12

C. PAYMENT

11. Contract Price (GCC Clause 11)

GCC 11.2 (b) There are no Special Conditions of Contract applicable to GCC
Clause 11.2 (b)

12. Terms of Payment (GCC Clause 12)

GCC 12.1 Subject to the provisions of GCC Clause 12 (Terms of Payment), the
Purchaser should pay the Contract Price to the Supplier in the
following manner – against the milestones specified in the
Implementation Schedule (with the characteristics specified in
the Technical Requirements) and in accordance with the
acceptance procedures specified in Paragraph 8 of the Technical
Requirements (and any subsequent refinements made through
the Agreed Project Plan or, as appropriate, contract
amendments).
(a) Agreed Project Plan (formally accepted Project Plan)
one percent (1%) of the entire Contract Price
(b) Delivery (of formally accepted System analysis and designs and
fully-paid up software licenses)
twenty four percent (24%) of the entire Contract Price
(c) Installation (of the formally accepted Pre-Production
Configuration V.2)
twenty percent(20%) of the entire Contract Price
(d) Operational Acceptance (of the formally accepted Full National
Roll-Out Configuration V.4)
Thirty five percent (35%) of the entire Contract Price– net the
cost of any ICT platform elements purchased by ANAF to
remedy any short fall in the performance of the System (as
specified in the Technical Requirements Paragraph 5) due to an
insufficient ICT technical specification provided by the Supplier
(as specified in Technical Requirements Paragraphs  6.5 and
6.6).
656 Section VII. Special Conditions of Contract

(e) Technical Support(of the formally accepted services)

twenty percent (20%) of the entire Contract Price paid in equal
shares at six month intervals over the five year Warranty Period.

GCC 12.3 The Purchaser should pay to the Supplier interest on the delayed
payments at a rate of: five (5) percent per annum (accumulated
interest not to exceed the value of the relevant payment or 10
percent of the total Contract Price, whatever is lowest).

GCC 12.4 The Supplier will invoice the Purchaser in the currencies specified in the
Contract Agreement.

GCC 12.5 There are no Special Conditions of Contract applicable to GCC

Clause 12.5

13. Securities (GCC Clause 13)

GCC 13.2.2 There are no Special Conditions of Contract applicable to GCC
Clause 13.2.2
GCC 13.3.1 The Performance Security should be denominated in Euro for an
amount equal to ten (10) percent of the Contract Price.
GCC 13.3.3 During the Implementation Period (i.e. before Operational Acceptance
of the System), the amount of the Performance Security cannot
be reduced.
GCC 13.3.4 During the Warranty Period (i.e., after Operational Acceptance of the
System), the Performance Security should be reduced to two (2)
percent of the Contract Price.

14. Taxes and Duties (GCC Clause 14)

GCC 14 There are no Special Conditions of Contract applicable to GCC Clause
14

D. INTELLECTUAL PROPERTY

15. Copyright (GCC Clause 15)

GCC 15.3 There are no Special Conditions of Contract applicable to GCC Clause
15.3
Section VII. Special Conditions of Contract 657

GCC 15.4 As specified in Paragraph 8.4 of the Technical Requirements, at the

conclusion of the Contract (i.e., at the end of the Warranty
Period), the Supplier MUST deliver to the Purchaser the up-to-
date, fully documented and commented source code or all
Custom Software developed under the Contract (and formally
designated as such). The Purchaser should formally document to
the Supplier that the Purchaser will NOT to transfer the code to
any other external party and will use it ONLY for the purpose of
updating/further developing NAFA's IT system(s).
GCC 15.5 There are no Special Conditions of Contract applicable to GCC Clause
15.5

16. Software License Agreements (GCC Clause 16)

GCC 16.1 (a) There are no Special Conditions of Contract applicable to GCC Clause
(iii) 16.1 (a) (iii).

GCC 16.1 (a) (iv) There are no Special Conditions of Contract applicable to GCC

Clause 16.1 (a) (vi)
GCC 16.1 (b) There are no Special Conditions of Contract applicable to GCC Clause
(vi) 16.1 (b) (vi)
GCC 16.1 (b) There are no Special Conditions of Contract applicable to GCC Clause
(vii) 16.1 (b) (vii)
GCC 16.2 There are no Special Conditions of Contract applicable to GCC
Clause 16.2

17. Confidential Information (GCC Clause 17)

GCC 17.1 There are no Special Conditions of Contract applicable to GCC
Clause 17.1
GCC 17.7 There are no Special Conditions of Contract applicable to GCC
Clause 17.7

E. SUPPLY, INSTALLATION, TESTING, COMMISSIONING, AND

ACCEPTANCE OF THE SYSTEM

18. Representatives (GCC Clause 18)

GCC 18.1 There are no Special Conditions of Contract applicable to GCC
Clause 18.1
658 Section VII. Special Conditions of Contract

GCC 18.2.2 There are no Special Conditions of Contract applicable to GCC

Clause 18.2.2

19. Project Plan (GCC Clause 19)

GCC 19.1 Chapters in the Project Plan should address the following subject:

o Project Organization and Management Sub-Plan

o Testing and Quality Assurance Sub-Plan

o Analysis and Detailed Design Sub-Plan

o Installation, Configuration, Customization and

Integration Sub-Plan

o Data Migration Sub-Plan

o Production Transition and Roll-out Sub-Plan

o Human Capacity Building Sub-Plan

o Warranty Defect Repair and Technical Support Service

Sub-Plan
Further details regarding the required contents of each of the
above chapters and the corresponding Services are contained in
Paragraph 6 of the Technical Requirements.
GCC 19.2 There are no Special Conditions of Contract applicable to GCC
Clause 19.2
GCC 19.5 There are no Special Conditions of Contract applicable to GCC
Clause 19.5
GCC 19.6 The Supplier should submit to the Purchaser (in formats specified in the
Agreed Project Plan):
(i) monthly inspection and quality assurance reports
(ii) monthly training participants test results
(iii) monthly log of service calls and problem resolutions

20. Subcontracting (GCC Clause 20)

GCC 20 There are no Special Conditions of Contract applicable to GCC
Clause 20.
Section VII. Special Conditions of Contract 659

21. Design and Engineering (GCC Clause 21)

GCC 21.3.1 There are no Special Conditions of Contract applicable to GCC Clause
21.3.1.

22. Procurement, Delivery, and Transport (GCC Clause 22)

GCC 22.4.3 There are no Special Conditions of Contract applicable to GCC Clause
22.4.3.

GCC 22.5 There are no Special Conditions of Contract applicable to GCC Clause
22.5.

23. Product Upgrades (GCC Clause 23)

GCC 23.4 There are no Special Conditions of Contract applicable to GCC Clause
23.4.

24. Implementation, Installation, and Other Services (GCC Clause 24)

GCC 24 There are no Special Conditions of Contract applicable to GCC Clause
24.

25. Inspections and Tests (GCC Clause 25)

GCC 25 There are no Special Conditions of Contract applicable to GCC Clause
25.

26. Installation of the System (GCC Clause 26)

GCC 26 There are no Special Conditions of Contract applicable to GCC Clause
26.

27. Commissioning and Operational Acceptance (GCC Clause 27)

GCC 27.2.1 There are no Special Conditions of Contract applicable to GCC Clause
27.2.1.

F. GUARANTEES AND LIABILITIES

28. Operational Acceptance Time Guarantee (GCC Clause 28)

GCC 28.2 The rate for liquidated damages shall be one tenth of one percent
660 Section VII. Special Conditions of Contract

(0.1%) per day.

GCC 28.3 There are no Special Conditions of Contract applicable to GCC Clause
28.3.

29. Defect Liability (GCC Clause 29)

GCC 29.1 There are no Special Conditions of Contract applicable to GCC Clause
29.1.
GCC 29.3 There are no Special Conditions of Contract applicable to GCC Clause
29.3.
GCC 29.4 The Warranty Period should extend for sixty (60)months.
GCC 29.10 There are no Special Conditions of Contract applicable to GCC Clause
29.10

30. Functional Guarantees (GCC Clause 30)

GCC 30 There are no Special Conditions of Contract applicable to GCC Clause
30.

31. Intellectual Property Rights Warranty (GCC Clause 31)

GCC 31 There are no Special Conditions of Contract applicable to GCC
Clause 31.

32. Intellectual Property Rights Indemnity (GCC Clause 32)

GCC 32 There are no Special Conditions of Contract applicable to GCC
Clause 32.

33. Limitation of Liability (GCC Clause 33)

GCC 33 There are no Special Conditions of Contract applicable to GCC
Clause 33.

G. RISK DISTRIBUTION

34. Transfer of Ownership (GCC Clause 34)

GCC 34 There are no Special Conditions of Contract applicable to GCC
Clause 34.
Section VII. Special Conditions of Contract 661

35. Care of the System (GCC Clause 35)

GCC 35 There are no Special Conditions of Contract applicable to GCC
Clause 35.

36. Loss of or Damage to Property; Accident or Injury to Workers;

Indemnification (GCC Clause 36)
GCC 36 There are no Special Conditions of Contract applicable to GCC
Clause 36.

37. Insurances (GCC Clause 37)

GCC 37.1 (c) The Supplier should obtain Third-Party Liability Insurance in the
amount of 1,000,000.00 (one million) Euro equivalent with
deductible limits of no more than 10,000.00 (ten thousand)
Euro equivalent. The insured Parties should beNAFA. The
Insurance should cover the period from Effective Date of the
Contract untildate of the Contract completion.

GCC 37.1 (e) There are no Special Conditions of Contract applicable to GCC
Clause 37.1 (e).

38. Force Majeure (GCC Clause 38)

GCC 38 There are no Special Conditions of Contract applicable to GCC
Clause 38.

H. CHANGE IN CONTRACT ELEMENTS

39. Changes to the System (GCC Clause 39)

GCC 39 All changes in the scope, timing and Contract Price of the System shall
be documented through formal Contract Amendment(s) duly
signed by the authorized representatives of the Purchaser and the
Supplier.

40. Extension of Time for Achieving Operational Acceptance (GCC Clause 40)
GCC 40 There are no Special Conditions of Contract applicable to GCC
Clause 40.
662 Section VII. Special Conditions of Contract

41. Termination (GCC Clause 41)

GCC 41.2.1 The provisions in clause GCC 41.2.1 (c) of Section IV. General
Conditions of Contract are replaced with the following
If the Purchaser determines that the Supplier and/or any of its personnel,
or its agents, or its Subcontractors, consultants, service providers,
suppliers and/or their employees has engaged in corrupt, fraudulent,
collusive, coercive or obstructive practices, in competing for or in
executing the Contract, then the Purchaser may, after giving 14 days
notice to the Supplier, terminate the Supplier's employment under the
Contract and cancel the contract, and the provisions of GCC Clause 41.1
shall apply as if such expulsion had been made under GCC Sub-Clause
41.1.2.
(a) For the purposes of this Sub-Clause:
(i) “corrupt practice” is the offering, giving, receiving or soliciting,
directly or indirectly, of anything of value to influence improperly the
actions of another party1;
(ii) “fraudulent practice” is any act or omission, including a
misrepresentation, that knowingly or recklessly misleads, or attempts to
mislead, a party to obtain a financial or other benefit or to avoid an
obligation2;
(iii) “collusive practice” is an arrangement between two or more
parties3 designed to achieve an improper purpose, including to influence
improperly the actions of another party;
(iv) “coercive practice” is impairing or harming, or threatening to
impair or harm, directly or indirectly, any party or the property of the
party to influence improperly the actions of a party4;
(v) “obstructive practice” is
(aa) deliberately destroying, falsifying, altering or concealing of
evidence material to the investigation or making false statements to
investigators in order to materially impede a Bank investigation into
allegations of a corrupt, fraudulent, coercive or collusive practice; and/or
threatening, harassing or intimidating any party to prevent it from
disclosing its knowledge of matters relevant to the investigation or from
pursuing the investigation; or
(bb) acts intended to materially impede the exercise of the Bank’s
inspection and audit rights provided for under GCC Clause 9.8.

1
“Another party” refers to a public official acting in relation to the procurement process or
contract execution. In this context, “public official” includes World Bank staff and
employees of other organizations taking or reviewing procurement decisions.
2
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the
procurement process or contract execution; and the “act or omission” is intended to
influence the procurement process or contract execution.
3
“Parties” refers to participants in the procurement process (including public officials)
attempting to establish bid prices at artificial, non competitive levels.
4
“Party” refers to a participant in the procurement process or contract execution.
Section VII. Special Conditions of Contract 663

Should any employee of the Supplier be determined to have engaged in

corrupt, fraudulent, collusive, coercive, or obstructive practice during
the purchase of the Goods, then that employee shall be removed.

42. Assignment (GCC Clause 42)

GCC 42 There are no Special Conditions of Contract applicable to GCC
Clause 42.

I. SETTLEMENT OF DISPUTES

43. Settlement of Disputes (GCC Clause 43)

GCC 43.1.4 The Appointing Authority for the Adjudicator is: International Chamber
of Commerce, Paris, France.

GCC 43.2.3 If the Supplier is from outside the Purchaser’s Country arbitration
proceedings should be conducted in accordance with the rules of
arbitration of the International Chamber of Commerce (ICC).
These rules, in the version in force at the time of the request for
arbitration, will be deemed to form part of this Contract.
If the Supplier is a national of the Purchaser’s Country, any dispute
between the Purchaser and a Supplier arising in connection with
the present Contract should be referred to arbitration in
accordance with the laws of the Purchaser’s country.
664 Section VIII. Sample Contractual Forms

SECTION VIII. SAMPLE CONTRACTUAL FORMS

Notes to Bidders on working with the Sample Contractual Forms

The following forms are to be completed and submitted by the successful Bidder
following notification of award: (i) Contract Agreement, with all Appendices; (ii)
Performance Security; and (iii) Advance Payment Security.
• Contract Agreement: In addition to specifying the parties and the Contract
Price, the Contract Agreement is where the: (i) Supplier Representative;
(ii) if applicable, agreed Adjudicator and his/her compensation; and (iii)
the List of Approved Subcontractors are specified. In addition,
modifications to the successful Bidder’s Bid Price Schedules are attached
to the Agreement. These contain corrections and adjustments to the
Supplier’s bid prices to correct errors, adjust the Contract Price to reflect –
if applicable - any extensions to bid validity beyond the last day of original
bid validity plus 56 days, etc.
• Performance Security: Pursuant to GCC Clause 13.3, the successful
Bidder is required to provide the Performance Security in the form
contained in this section of these Bidding Documents and in the amount
specified in accordance with the SCC.
• Advance Payment Security: Pursuant to GCC Clause 13.2, the successful
Bidder is required to provide a bank guarantee for the full amount of the
Advance Payment - if an Advance Payment is specified in the SCC for
GCC 12.1 - in the form contained in this section of these Bidding
Documents or another form acceptable to the Purchaser. If a Bidder
wishes to propose a different Advance Payment Security form, it should
submit a copy to the Purchaser promptly for review and confirmation of
acceptability before the bid submission deadline.
The Purchaser and Supplier will use the following additional forms during
Contract implementation to formalize or certify important Contract events: (i) the
Installation and Operational Acceptance Certificates; and (ii) the various Change Order
forms. These and the procedures for their use during performance of the Contract are
included in the Bidding Documents for the information of Bidders.

1. Contract Agreement.......................................................................................................664
Appendix 1. Supplier’s Representative...........................................................................668
Appendix 2. Adjudicator / Appointing Authority...........................................................669
Appendix 3. List of Approved Subcontractors...............................................................670
Appendix 4. Categories of Software...............................................................................671
Appendix 5. Custom Materials.......................................................................................672
Section VIII. Sample Contractual Forms 665

Appendix 6. Minutes of Contract Finalization Discussions and Agreed-to Contract

Amendments...........................................................................................................673
2. Performance Security Form...........................................................................................675
2.1 Performance Security Form (Bank Guarantee).......................................................676
3. Installation and Acceptance Certificates.....................................................................678
3.1 Installation Certificate.............................................................................................679
3.2 Operational Acceptance Certificate........................................................................680
4. Change Order Procedures and Forms..........................................................................681
4.1 Request for Change Proposal Form........................................................................682
4.2 Change Estimate Proposal Form.............................................................................684
4.3 Estimate Acceptance Form.....................................................................................686
4.4 Change Proposal Form............................................................................................688
4.5 Change Order Form................................................................................................690
4.6 Application for Change Proposal Form..................................................................692
666 Section VIII. Sample Contractual Forms

1. CONTRACT AGREEMENT

THIS CONTRACT AGREEMENT is made

the [ insert: ordinal ] day of [  insert: month ], [ insert: year ].

BETWEEN
(1) National Agency of Fiscal Administration within Ministry of Public
Finance of the Government of Romania and having its principal place of
business at 17, Apolodor Street, Sector 5, Bucharest, Romania
(hereinafter called “the Purchaser”), and
(2) [  insert: name of Supplier], a corporation incorporated under the laws of
[  insert: country of Supplier] and having its principal place of business at
[  insert: address of Supplier ] (hereinafter called “the Supplier”).

WHEREAS the Purchaser desires to engage the Supplier to supply, install, achieve
Operational Acceptance of, and support an integrated Revenue Management System
(RMS) for administering all the taxes, levies, and social insurance contributions
specified under Romanian Law (excluding customs duties and excise taxes) – under a
single-responsibility contract encompassing all the necessary software and services
(but excluding ICT hardware)(“the System”), and the Supplier has agreed to such
engagement upon and subject to the terms and conditions appearing below in this
Contract Agreement.

NOW IT IS HEREBY AGREED as follows:

Article 1. 1.1 Contract Documents (Reference GCC Clause 1.1 (a) (ii))

Contract The following documents should constitute the Contract

Documents between the Purchaser and the Supplier, and each should be read
and construed as an integral part of the Contract:
(a) This Contract Agreement and the Appendices attached to
the Contract Agreement
(b) Special Conditions of Contract
(c) General Conditions of Contract
(d) Technical Requirements (including Implementation
Schedule)
(e) The Supplier’s bid
(f) [ Add here: any other documents ]
1.2 Order of Precedence (Reference GCC Clause 2)
Section VIII. Sample Contractual Forms 667

In the event of any ambiguity or conflict between the Contract

Documents listed above, the order of precedence should be the
order in which the Contract Documents are listed in Article 1.1
(Contract Documents) above, provided that Appendix 7 should
prevail over all provisions of the Contract Agreement and the
other Appendices attached to the Contract Agreement and all the
other Contract Documents listed in Article 1.1 above.
1.3 Definitions (Reference GCC Clause 1)
Capitalized words and phrases used in this Contract Agreement
should have the same meanings as are ascribed to them in the
General Conditions of Contract.
Article 2. 2.1 Contract Price (Reference GCC Clause 1.1(a)(viii) and GCC
Clause 11)
Contract Price and The Purchaser hereby agrees to pay to the Supplier the Contract
Terms of Payment Price in consideration of the performance by the Supplier of its
obligations under the Contract. The Contract Price should be the
aggregate of: [ insert: amount of foreign currency A in
words  ],[insert: amount in figures ],plus [  insert: amount of
foreign currency B in words ],[insert: amount in figures ],
plus [ insert: amount of foreign currency C in words  ],
[insert: amount in figures ], [ insert: amount of local
currency in words  ], [ insert: amount in figures  .
Article 3. 3.1 Effective Date (Reference GCC Clause 1.1 (e) (ix))
The time allowed for supply, installation, and achieving
Effective Date for Operational Acceptance of the System should be determined
Determining Time from the date when all of the following conditions have been
for Operational fulfilled:
Acceptance
(a) This Contract Agreement has been duly executed for and
on behalf of the Purchaser and the Supplier;
(b) The Supplier has submitted to the Purchaser the
performance security and the advance payment security, in
accordance with GCC Clause 13.2 and GCC Clause 13.3;
(c) The Purchaser has paid the Supplier the advance payment,
in accordance with GCC Clause 12;
Each party should use its best efforts to fulfill the above
conditions for which it is responsible as soon as practicable.
3.2 If the conditions listed under 3.1 are not fulfilled within two (2)
months from the date of this Contract Agreement because of
reasons not attributable to the Supplier, the parties should
discuss and agree on an equitable adjustment to the Contract
Price and the Time for Achieving Operational Acceptance and/or
other relevant conditions of the Contract.
Article 4. 4.1 The Appendixes listed below should be deemed to form an
integral part of this Contract Agreement.
668 Section VIII. Sample Contractual Forms

Appendixes
4.2 Reference in the Contract to any Appendix should mean the
Appendixes listed below and attached to this Contract
Agreement, and the Contract should be read and construed
accordingly.

APPENDIXES
Appendix 1. Supplier’s Representative
Appendix 2. Adjudicator/ Appointing Authority
Appendix 3. List of Approved Subcontractors
Appendix 4. Categories of Software
Appendix 5. Custom Materials
Appendix 6. Minutes of Contract Finalization Discussions and Agreed-to
Contract Amendments

IN WITNESS WHEREOF the Purchaser and the Supplier have caused this Agreement to
be duly executed by their duly authorized representatives the day and year first above
written.

For and on behalf of the Purchaser

Signed:
in the capacity of [ insert: title or other appropriate designation ]

in the presence of

For and on behalf of the Supplier

Signed:
in the capacity of [ insert: title or other appropriate designation ]

in the presence of

CONTRACT AGREEMENT
dated the [ insert: number  ]day of [ insert: month ], [  insert: year ]
BETWEEN
[  insert: name of Purchaser  ],“the Purchaser”
Section VIII. Sample Contractual Forms 669

and
[  insert: name of Supplier ], “the Supplier”
670 Section VIII. Sample Contractual Forms

Appendix 1. Supplier’s Representative

In accordance with GCC Clause 1.1 (b) (iv), the Supplier’s Representative is:

Name: [  insert: name and provide title and address further below ]

Title: [  if appropriate, insert: title ]

In accordance with GCC Clause 4.3, the Supplier's addresses for notices under the
Contract are:

Address of the Supplier's Representative: [ as appropriate, insert: personal

delivery, postal, cable, telegraph, telex, facsimile, electronic mail, and/or EDI
addresses.  ]

Fallback address of the Supplier: [ as appropriate, insert: personal delivery,

postal, cable, telegraph, telex, facsimile, electronic mail, and/or EDI
addresses. ]
Section VIII. Sample Contractual Forms 671

Appendix 2. Adjudicator / Appointing Authority

In accordance with GCC Clause 1.1 (b) (vi), the agreed-upon Adjudicator is:

Name:[  insert: name  ]

Title:[  insert: title ]

Address: [ insert: postal address ]

Telephone: [  insert: telephone ]

In accordance with GCC Clause 6.1.3, the agreed-upon fees and reimbursable expenses
are:

Hourly Fees:[ insert: hourly fees ]

Reimbursable Expenses:[ list: reimbursable ]

Pursuant to GCC Clause 6.1.4, the agreed-upon Appointing Authority is:

Organization:[  insert: organization]

Address: [ insert: postal address ]

Telephone: [  insert: telephone ]

672 Section VIII. Sample Contractual Forms

Appendix 3. List of Approved Subcontractors

The Purchaser has approved use of the following Subcontractors nominated by the
Supplier for carrying out the item or component of the System indicated. Where more
than one Subcontractor is listed, the Supplier is free to choose between them, but it must
notify the Purchaser of its choice sufficiently in advance of the time when the
subcontracted work needs to commence to give the Purchaser reasonable time for review.
In accordance with GCC Clause 20.1, the Supplier is free to submit proposals for
Subcontractors for additional items from time to time. No subcontracts should be placed
with any such Subcontractors for additional items until the Subcontractors have been
approved in writing by the Purchaser and their names have been added to this list of
Approved Subcontractors, subject to GCC Clause 20.3.

[ specify: item, approved Subcontractors, and their place of registration that the
Supplier proposed in the corresponding attachment to its bid and that the Purchaser
approves that the Supplier engage during the performance of the Contract. Add
additional pages as necessary. ]

Item Approved Subcontractors Place of Registration

Section VIII. Sample Contractual Forms 673

Appendix 4. Categories of Software

The following table assigns each item of Software supplied and installed under the
Contract to one of the three categories: (i) System Software, (ii) General-Purpose
Software, or (iii) Application Software; and to one of the two categories: (i) Standard
Software or (ii) Custom Software.

(select one per item) (select one per item)

General-
System Purpose Application Standard Custom
Software Item Software Software Software Software Software
674 Section VIII. Sample Contractual Forms

Appendix 5. Custom Materials

The follow table specifies the Custom Materials the Supplier will provide under the
Contract.

Custom Materials
Section VIII. Sample Contractual Forms 675

Appendix 6. Minutes of Contract Finalization Discussions and

Agreed-to Contract Amendments

The attached Contract amendments (if any) should form part of this Contract Agreement
and, where differences exist, should supersede the relevant clauses in the GCC, SCC,
Technical Requirements, or other parts of this Contract as defined in GCC Clause 1.1 (a)
(ii).
676 Section VIII. Sample Contractual Forms

2. PERFORMANCE SECURITY FORM

Section VIII. Sample Contractual Forms 677

2.1 Performance Security Form (Bank Guarantee)

[The bank, as requested by the successful Bidder, shall fill in this form in accordance
with the instructions indicated]

[Guarantor letterhead or SWIFT identifier code]

Beneficiary: [insert name and Address of Purchaser ]

Date: _ [Insert date of issue]

PERFORMANCE GUARANTEE No.: [Insert guarantee reference number]

Guarantor: [Insert name and address of place of issue, unless indicated in the
letterhead]

We have been informed that _ [insert name of Supplier, which in the case of a joint
venture shall be the name of the joint venture] (hereinafter called "the Applicant") has
entered into Contract No. [insert reference number of the contract] dated [insert date]
with the Beneficiary, for the supply of _ [insert name of contract and brief description of
Goods and related Services] (hereinafter called "the Contract").

Furthermore, we understand that, according to the conditions of the Contract, a

performance guarantee is required.

At the request of the Applicant, we as Guarantor, hereby irrevocably undertake to pay the
Beneficiary any sum or sums not exceeding in total an amount of [insert amount in
figures] ( ) [insert amount in words],1 such sum being payable in the types
and proportions of currencies in which the Contract Price is payable, upon receipt by us
of the Beneficiary’s complying demand supported by the Beneficiary’s statement,
whether in the demand itself or in a separate signed document accompanying or
identifying the demand, stating that the Applicant is in breach of its obligation(s) under
the Contract, without the Beneficiary needing to prove or to show grounds for your
demand or the sum specified therein.

This guarantee shall expire, no later than the …. Day of ……, 2… 2, and any demand for
payment under it must be received by us at this office indicated above on or before that
date. This guarantee is subject to the Uniform Rules for Demand Guarantees (URDG)

1 1
The Guarantor shall insert an amount representing the percentage of the Accepted Contract Amount
specified in the Letter of Acceptance, and denominated either in the currency(ies) of the Contract or a
freely convertible currency acceptable to the Beneficiary.
2 2
Insert the date twenty-eight days after the expected completion date as described in GC Clause 18.4.
The Purchaser should note that in the event of an extension of this date for completion of the Contract,
the Purchaser would need to request an extension of this guarantee from the Guarantor. Such request
must be in writing and must be made prior to the expiration date established in the guarantee. In
preparing this guarantee, the Purchaser might consider adding the following text to the form, at the
end of the penultimate paragraph: “The Guarantor agrees to a one-time extension of this guarantee
for a period not to exceed [six months][one year], in response to the Beneficiary’s written request for
such extension, such request to be presented to the Guarantor before the expiry of the guarantee.”
678 Section VIII. Sample Contractual Forms

2010 Revision, ICC Publication No. 758, except that the supporting statement under
Article 15(a) is hereby excluded.

_____________________
[signature(s)]

Note: All italicized text (including footnotes) is for use in preparing this form and
shall be deleted from the final product.
Section VIII. Sample Contractual Forms 679

3. Installation and Acceptance Certificates

680 Section VIII. Sample Contractual Forms

3.1 Installation Certificate

Date: [ insert: date  ]
Contract: RAMP/5

To: [ insert: name and address of Supplier ]

Dear Sir or Madam:
Pursuant to GCC Clause 26 (Installation of the System) of the Contract entered
into between yourselves and the [ insert: name of Purchaser ](hereinafter the
“Purchaser”) dated [  insert: date of Contract ], relating to the an integrated Revenue
Management System (RMS) for administering all the taxes, levies, and social
insurance contributions specified under Romanian Law (excluding customs duties and
excise taxes) – under a single-responsibility contract encompassing all the necessary
software and services (but excluding ICT hardware), we hereby notify you that the
System (or a Subsystem or major component thereof) was deemed to have been correctly
installed on the date specified below.
1. Description of the System (or relevant Subsystem or major component: [ insert:
description ]
2. Date of Installation: [ insert: date ]
Notwithstanding the above, you are required to complete the outstanding items
listed in the attachment to this certificate as soon as practicable. This letter should not
relieve you of your obligation to achieve Operational Acceptance of the System in
accordance with the Contract nor of your obligations during the Warranty Period.

For and on behalf of the Purchaser

Signed:
Date:
in the capacity of: [ state: “Project Manager” or state the title of a higher level
authority in the Purchaser’s organization ]
Section VIII. Sample Contractual Forms 681

3.2 Operational Acceptance Certificate

Date: [ insert: date  ]

Contract: RAMP/5

To: [ insert: name and address of Supplier ]

Dear Sir or Madam:

Pursuant to GCC Clause 27 (Commissioning and Operational Acceptance) of the

Contract entered into between yourselves and the [ insert: name of Purchaser ]
(hereinafter the “Purchaser”) dated [ insert: date of Contract ], relating to the an
integrated Revenue Management System (RMS) for administering all the taxes, levies,
and social insurance contributions specified under Romanian Law (excluding customs
duties and excise taxes) – under a single-responsibility contract encompassing all the
necessary software and services (but excluding ICT hardware), we hereby notify you
the System (or the Subsystem or major component identified below) successfully
completed the Operational Acceptance Tests specified in the Contract. In accordance
with the terms of the Contract, the Purchaser hereby takes over the System (or the
Subsystem or major component identified below), together with the responsibility for care
and custody and the risk of loss thereof on the date mentioned below.
1. Description of the System (or Subsystem or major component): [ insert:
description ]
2. Date of Operational Acceptance: [ insert: date ]
This letter should not relieve you of your remaining performance obligations
under the Contract nor of your obligations during the Warranty Period.

For and on behalf of the Purchaser

Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the
Purchaser’s organization ]
682 Section VIII. Sample Contractual Forms

4. CHANGE ORDER PROCEDURES AND FORMS

Date: [ insert: date  ]

Contract: RAMP/5
General
This section provides samples of procedures and forms for carrying out changes to
the System during the performance of the Contract in accordance with GCC Clause
39 (Changes to the System) of the Contract.
Change Order Log
The Supplier should keep an up-to-date Change Order Log to show the current
status of Requests for Change and Change Orders authorized or pending. Changes
should be entered regularly in the Change Order Log to ensure that the log is kept
up-to-date. The Supplier should attach a copy of the current Change Order Log in
the monthly progress report to be submitted to the Purchaser.
References to Changes
(1) Request for Change Proposals (including Application for Change Proposals)
should be serially numbered CR-nnn.
(2) Change Estimate Proposals should be numbered CN-nnn.
(3) Estimate Acceptances should be numbered CA-nnn.
(4) Change Proposals should be numbered CP-nnn.
(5) Change Orders should be numbered CO-nnn.
On all forms, the numbering should be determined by the original CR-nnn.
Annexes
4.1 Request for Change Proposal Form
4.2 Change Estimate Proposal Form
4.3 Estimate Acceptance Form
4.4 Change Proposal Form
4.5 Change Order Form
4.6 Application for Change Proposal Form
Section VIII. Sample Contractual Forms 683

4.1 Request for Change Proposal Form

(Purchaser’s Letterhead)

Date: [ insert: date  ]

Contract: RAMP/5

To: [ insert: name of Supplier and address ]

Attention: [ insert: name and title ]

Dear Sir or Madam:

With reference to the above-referenced Contract, you are requested to prepare and
submit a Change Proposal for the Change noted below in accordance with the following
instructions within [ insert: number ] days of the date of this letter.

1. Title of Change: [ insert: title ]

2. Request for Change No./Rev.: [ insert: number  ]

3. Originator of Change: [  select Purchaser / Supplier (by Application for Change

Proposal), and add: name of originator ]

4. Brief Description of Change: [ insert: description ]

5. System (or Subsystem or major component affected by requested Change):

[  insert: description ]

6. Technical documents and/or drawings for the request of Change:

Document or Drawing No. Description

7. Detailed conditions or special requirements of the requested Change: [ insert:

description ]

8. Procedures to be followed:
684 Section VIII. Sample Contractual Forms

(a) Your Change Proposal will have to show what effect the requested Change
will have on the Contract Price.
(b) Your Change Proposal should explain the time it will take to complete the
requested Change and the impact, if any, it will have on the date when
Operational Acceptance of the entire System agreed in the Contract.
(c) If you believe implementation of the requested Change will have a negative
impact on the quality, operability, or integrity of the System, please provide a
detailed explanation, including other approaches that might achieve the same
impact as the requested Change.
(d) You should also indicate what impact the Change will have on the number and
mix of staff needed by the Supplier to perform the Contract.
(e) You should not proceed with the execution of work related to the requested
Change until we have accepted and confirmed the impact it will have on the
Contract Price and the Implementation Schedule in writing.
9. As next step, please respond using the Change Estimate Proposal form, indicating
how much it will cost you to prepare a concrete Change Proposal that will describe
the proposed approach for implementing the Change, all its elements, and will also
address the points in paragraph 8 above pursuant to GCC Clause 39.2.1. Your
Change Estimate Proposal should contain a first approximation of the proposed
approach, and implications for schedule and cost, of the Change.

For and on behalf of the Purchaser

Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the
Purchaser’s organization  ]
Section VIII. Sample Contractual Forms 685

4.2 Change Estimate Proposal Form

(Supplier’s Letterhead)

Date: [ insert: date  ]

Contract: RAMP/5

To: National Agency of Fiscal Administration; 17, Apolodor Street, Sector 5,

Bucharest, Romania
Attention: [ insert: name and title ]

Dear Sir or Madam:

With reference to your Request for Change Proposal, we are pleased to notify you
of the approximate cost of preparing the below-referenced Change in accordance with
GCC Clause 39.2.1 of the Contract. We acknowledge that your agreement to the cost of
preparing the Change Proposal, in accordance with GCC Clause 39.2.2, is required before
we proceed to prepare the actual Change Proposal including a detailed estimate of the
cost of implementing the Change itself.

1. Title of Change: [ insert: title ]

2. Request for Change No./Rev.: [ insert: number  ]

3. Brief Description of Change (including proposed implementation approach):

[  insert: description ]

4. Schedule Impact of Change (initial estimate): [ insert: description ]

5. Initial Cost Estimate for Implementing the Change: [insert: initial cost estimate]

6. Cost for Preparation of Change Proposal: [ insert: cost in the currencies of the
Contract ], as detailed below.

For and on behalf of the Supplier

686 Section VIII. Sample Contractual Forms

Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or other higher level authority
in the Supplier’s organization ]
Section VIII. Sample Contractual Forms 687

4.3 Estimate Acceptance Form

(Purchaser’s Letterhead)

Date: [ insert: date  ]

Contract: RAMP/5

To: [ insert: name of Supplier and address ]

Attention:[ insert: name and title ]

Dear Sir or Madam:

We hereby accept your Change Estimate and agree that you should proceed with
the preparation of a formal Change Proposal.

1. Title of Change: [ insert: title ]

2. Request for Change No./Rev.: [ insert: request number / revision ]

3. Change Estimate Proposal No./Rev.: [  insert: proposal number / revision ]

4. Estimate Acceptance No./Rev.: [ insert: estimate number / revision ]

5. Brief Description of Change: [ insert: description ]

6. Other Terms and Conditions:

In the event that we decide not to order the Change referenced above, you should be
entitled to compensation for the cost of preparing the Change Proposal up to the
amount estimated for this purpose in the Change Estimate Proposal, in accordance
with GCC Clause 39 of the General Conditions of Contract.

For and on behalf of the Purchaser

Signed:
688 Section VIII. Sample Contractual Forms

Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the
Purchaser’s organization ]
Section VIII. Sample Contractual Forms 689

4.4 Change Proposal Form

(Supplier’s Letterhead)

Date: [ insert: date  ]

Contract: RAMP/5

To: National Agency of Fiscal Administration;17, Apolodor Street, Sector 5,

Bucharest, Romania

Attention: [ insert: name and title ]

Dear Sir or Madam:

In response to your Request for Change Proposal No. [ insert: number ],we

hereby submit our proposal as follows:

1. Title of Change: [ insert: name ]

2. Change Proposal No./Rev.: [  insert: proposal number/revision ]

3. Originator of Change: [  select: Purchaser / Supplier; and add: name]

4. Brief Description of Change: [ insert: description ]

5. Reasons for Change: [ insert: reason ]

6. The System Subsystem, major component, or equipment that will be affected by the
requested Change: [ insert: description ]

7. Technical documents and/or drawings for the requested Change:

Document or Drawing No. Description

8. Estimate of the increase/decrease to the Contract Price resulting from the proposed
Change: [  insert: amount in currencies of Contract ], as detailed below.
Total lump sum cost of the Change:
690 Section VIII. Sample Contractual Forms

Cost to prepare this Change Proposal (i.e., the amount payable if the Change is not
accepted, limited as provided by GCC Clause 39.2.6):

9. Additional Time for Achieving Operational Acceptance required due to the Change:
[  insert: amount in days / weeks  ]

10. Effect on the Functional Guarantees: [ insert: description ]

11. Effect on the other terms and conditions of the Contract: [ insert: description ]

12. Validity of this Proposal: for a period of [ insert: number ] days after receipt of
this Proposal by the Purchaser

13. Procedures to be followed:

(a) You are requested to notify us of your acceptance, comments, or rejection of
this detailed Change Proposal within [ insert: number ] days from your
receipt of this Proposal.
(b) The amount of any increase and/or decrease should be taken into account in
the adjustment of the Contract Price.

For and on behalf of the Supplier

Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or other higher level authority
in the Supplier’s organization ]
Section VIII. Sample Contractual Forms 691

4.5 Change Order Form

(Purchaser’s Letterhead)

Date: [ insert: date  ]

Contract: RAMP/5

To: [ insert: name of Supplier and address ]

Attention: [ insert: name and title ]

Dear Sir or Madam:

We hereby approve the Change Order for the work specified in Change Proposal
No. [ insert: number ], and agree to adjust the Contract Price, Time for Completion,
and/or other conditions of the Contract in accordance with GCC Clause 39 of the
Contract.

1. Title of Change: [ insert: name ]

2. Request for Change No./Rev.: [ insert: request number / revision ]

3. Change Order No./Rev.: [ insert: order number / revision ]

4. Originator of Change: [  select: Purchaser / Supplier; and add: name ]

5. Authorized Price for the Change:

Ref. No.: [ insert: number ] Date: [ insert: date  ]

[  insert: amount in foreign currency A ] plus [ insert: amount in foreign

currency B ] plus [ insert: amount in foreign currency C  ] plus [ insert:
amount in local currency  ]

6. Adjustment of Time for Achieving Operational Acceptance: [ insert: amount and

description of adjustment ]

7. Other effects, if any: [ state: “none” or insert description ]

692 Section VIII. Sample Contractual Forms

For and on behalf of the Purchaser

Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the
Purchaser’s organization ]

For and on behalf of the Supplier

Signed:
Date:
in the capacity of: [ state “Supplier’s Representative” or higher level authority in the
Supplier’s organization ]
Section VIII. Sample Contractual Forms 693

4.6 Application for Change Proposal Form

(Supplier’s Letterhead)

Date: [ insert: date  ]

Contract: [ insert: name of System or Subsystem and
number of Contract ]

To: National Agency of Fiscal Administration;17, Apolodor Street, Sector 5,

Bucharest, Romania

Attention: [ insert: name and title ]

Dear Sir or Madam:

We hereby propose that the below-mentioned work be treated as a Change to the

System.

1. Title of Change: [ insert: name ]

2. Application for Change Proposal No./Rev.: [ insert: number / revision] dated:

[  insert: date ]

3. Brief Description of Change: [ insert: description ]

4. Reasons for Change: [ insert: description ]

5. Order of Magnitude Estimation: [  insert: amount in currencies of the Contract ]

6. Schedule Impact of Change: [  insert: description ]

7. Effect on Functional Guarantees, if any: [ insert: description ]

8. Appendix: [ insert: titles (if any); otherwise state “none” ]

For and on behalf of the Supplier

694 Section VIII. Sample Contractual Forms

Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or higher level authority in the
Supplier’s organization ]