DEPLOYMENT OF e-INVOICE IN CROATIA

Zvonimir Vanjak, Vedran Mornar

Faculty of Electrical Engineering and Computing,University of Zagreb, Unska 3, Zagreb, Croatia

Ivan Magdalenić

Faculty of Organization and Informatics, University of Zagreb, Varaždin, Croatia

Keywords: e-Invoice, e-Business, ebXML, Web services.

Abstract: Deployment of e-Invoice infrastructure promises great savings in business transactions costs. But, due to

slow transition from socialist economy, Croatia has just begun planning deployment of e-Invoice

infrastructure in accordance with recently released national strategy for development of e-Business.

Unfortunately, existence of globally competing standards makes decision making much harder. Technical

sophistication of ebXML standard hasn't prevailed in struggle for global dominance with much broadly

implemented technology of web services. Some compromise will therefore be necessary. Paper presents

overview of different standards considered as candidates for deployment of e-Invoice infrastructure in

Croatia, as well as details regarding particularities of Croatia's legal and business environment.

1 INTRODUCTION

Landscape for doing business has changed

dramatically in the last decade, thanks to advances in

information technology, coupled with big expansion

of available network bandwidth. Although EDI

(Electronic Data Interchange) systems have been

around for decades (Hayes, 2002), gains from their

introduction were realized mostly by large

enterprises because of the economies of scale EDI

required in order to get return on investment. EDI

was introduced over value-added networks (VANs),

which served as the common communication

method but were expensive, with an initial cost of

about US$ 250,000 for a mainframe installation and

subsequent fees as high as US$ 0.70 per transaction

(Albrecht et al, 2005).

Because of this high demand on ICT

investments, small and medium-sized enterprises

(SMEs) that form the backbone of developed world

economies have hesitated with adoption of EDI

(Banerjee and Golhar, 1994), but explosive growth

of Internet as cheap and widely available

information exchange platform has given them

affordable alternative.

Emergence of XML and Web Services standards

and their fast global adoption has certainly helped in

that regard. From Clipper and dBase to Java and

.NET, software development industry has come a

long way. Ease of developing simple business

applications with the use of modern integrated

development environments (Microsoft Visual

Studio, Eclipse, IBM WebSphere) has put e-

Commerce definitively within reach for SMEs.

Unfortunately, fundamental problem has

remained the same – how to enable secure and

semantically meaningful communication between

different information systems. XML as a standard

certainly defines „how“ to construct a valid XML

document, but it doesn't say (nor it is its purpose)

„what“ to put in XML schema that will represent

some business information. Problem is similar with

the set of specifications related to the technology of

Web Services. They define basic infrastructure for

message exchange, but there are multitude of issues

regarding security and service discovery that have to

be agreed between parties before message exchange

can take place.

E-Invoice, as the most used electronic document

(dubbed as „queen of commercial documents“)

provides a case in point. There are literally hundreds

of different definitions for XML schema

representing e-Invoice in the world today and this

was, and still is, one of the major stumbling blocks

348

Vanjak Z., Mornar V. and Magdaleni

c I. (2008).

DEPLOYMENT OF e-INVOICE IN CROATIA.

In Proceedings of the Third International Conference on Software and Data Technologies, pages 348-354

DOI: 10.5220/0001888903480354

 SciTePress

for wider adoption and implementation of e-

Procurement. Fortunately, at least there is

widespread agreement that XML must be the

underlying format for the message (Nurmilaakso,

2008).

Situation is much worse regarding

standardization of infrastructure for message

exchange, usually called “interoperability

framework”. Efforts at standardization by

UNCEFACT/OASIS alliance which started in 1999

and resulted in ebXML standard didn’t lead to wider

adoption, mostly due to technical complexity of

implementation and lack of support from major

software vendors. Prevalence of web services as

message-exchange “standard” on the Internet hasn’t

gone unnoticed by ebXML committees and in its

most recent version 3.0, ebXML turns to Web

Services technologies, using WS-Security and WS-

Reliability as standards for security and reliable

transport.

In the following sections we will first give an

overview of efforts at e-Invoice standardization in

Europe and then proceed with the review of basic

technologies relevant for deployment of e-Invoice.

Situation in Croatia regarding e-Invoice is described

in the final part of the paper.

2 e-INVOICE IN EUROPE

Realization of electronic invoicing has potential to

reduce supply chain transaction cost in corporate and

public sector by 243 billion Euros annually (Bryant

and Liezenberg, 2008). Although such projections

must always be taken with the grain of salt, it is

clear that electronic invoicing is the way of the

future.

The European Commission has made the

development of e-Invoicing an objective in both the

2002 and the 2005 eEurope Action Plans and

recently launched European Commission Expert

Group with the objective of developing a European

Electronic Invoicing Framework (EEI) in the

timeframe 2008-2009. EEI has the scope and

objective to „provide the basis to achieve

interoperability of e-Invoicing solutions in the public

and private sector” and to “help strengthen the

positive commercial incentives for electronic

trade as a replacement to manual paper-based

processes” (European Commission Informal

Task Force on e-Invoicing, 2007).

Considering the national differences in EU

regarding status of e-Business development, it is not

at all surprising that some countries didn’t wait for

EU-wide initiative and had started work on e-

Invoice on their own. Northern European countries

in particular are leaders in this area. Probably the

most cited example is Denmark with reported

savings of 100+ million Euros after their “big-bang”

implementation of e-Invoice in 2005 (Brun, 2007).

After initially introducing e-Invoice based on

traditional EDI Value Added Network combined

with OIOXML and UBL 0.7, Denmark is currently

in the progress of introducing service-oriented e-

Commerce network based on UBL 2.0, SOAP 1.1

(1.2), UDDI 3.0 and WS-* standards.

Finland is another example. Its implementation,

Finvoice, uses custom XML format for representing

invoice, enclosed in an electronic envelope with the

additional use of ePI (Electronic Payment Initiator)

standard (Cimander and Kubicek, 2006). In

Croatia’s neighborhood, Italy is in the process of

deploying CBI as a variant of interbanking VAN

where banks act as portals and intermediaries for e-

Invoice users. Slovenia has ambitiously started e-

Slog project, trying first with direct translation of

EDIFACT (EANCOM) norms to XML but recently

there are signs of a preference for a switch to GS1

BMS.

Obviously, this proliferation of national

initiatives in deployment of e-Invoice infrastructure

creates many problems when it comes to cross-

border interoperability. Problem is especially hard

for small countries like Croatia that currently aren't

at the forefront of e-Invoice development, and, in

Croatia's case, not even in the EU yet. Of course,

there is a readily available possibility of „wait-and-

see“ approach with all the usual benefits for late

adopter, but e-Business is too important as an engine

for growth and innovation for this scenario to be

realistic. Notwithstanding problems created by

different standards available, some basic

requirements for e-Invoice infrastructure are clear:



secure message transport



existence of common interoperability

framework



standardized format for message

Next three sections give an overview of current

situation in these areas.

3 SECURITY OF ELECTRONIC

EXCHANGE

Security considerations are paramount whenever

there is an electronic exchange of sensitive

DEPLOYMENT OF e-INVOICE IN CROATIA

349

information over public network. There are five

security criteria that must be satisfied in such

communication: trust, authenticity, non-repudiation,

integrity and confidentiality. Solution exists in the

form of public key infrastructure (PKI) where

certificate authority guarantees binding of user

identities with public keys, thus solving the biggest

problem of public key cryptography - proving that a

public key is authentic, and has not been tampered

with or replaced by a malicious third party.

Although technical aspects are relatively clear,

there are problems in implementation and

deployment of such systems, mostly related to the

distribution of keys, and especially their revocation:

privilege of key revocation, distribution of a new

key, spreading the revocation and recovery of a

leaked key.

Another issue is cross-border interoperability and

standardization. Internet is becoming global

marketplace, and EU started efforts at

standardization in 1999, when European

Commission in its Directive 1999/93/EC adopted

legislation regarding advanced electronic signature.

Of importance for digitally signing e-Invoice is also

Directive 2001/115/EC and provisions of this law

have been transferred to new EU VAT Directive

2006/112/EC.

In 2005, Croatia’s government adopted

legislation concerning electronic signature (Narodne

novine, 2002) and electronic document (Narodne

novine, 2005) that are in compliance with EU

legislation. FINA (Financial Agency) was given

central role as national certificate authority and since

then some 10.000 digital certificates were issued.

Croatia’s banks, mostly in foreign ownership,

didn’t wait for government legislation, and started

development of e-Banking on their own. With more

than 80.000 certificates issued so far banks are at the

forefront of e-Business development in Croatia.

Unfortunately, although these certificates certainly

satisfy technical requirements for secure message

transport, they weren’t issued in formal accordance

to the law and use of these certificates within e-

Invoice infrastructure would require legislative

changes.

Although there are issues that need further

addressing, mainly in regard with cross-border (i.e.

EU) interoperability of national PKI infrastructures,

current development in the area of electronic

security is sufficiently advanced for the purposes of

e-Invoice.

Be advised that papers in a technically unsuitable

form will be returned for retyping. After returned the

manuscript must be appropriately modified.

4 INTEROPERABILITY

FRAMEWORK

Interoperability framework (IF) is a crucial

component for deployment of e-Business

infrastructure and all its aspects, including e-Invoice.

IF can be described as a set of policies, technical

standards and guidelines which enable solving

interoperability issues between different IT systems.

Some interoperability issues arise from the

differences in the meaning of terms and modes of

operations and some are related to the fact that

different informational systems cannot share

information easily. Within interoperability

framework communication is done using a

predetermined framework based on open

international standards. As Croatia is a country

where most companies are small and medium in size

and EDI infrastructure is not so widely used, legacy

considerations can be put aside.

Interoperability can be analyzed and

implemented on three main layers: technical,

semantic and process layer. Technical layer of

interoperability encapsulates standards and norms

for binding different systems and it forms a basis for

enabling communication between them. It also

specifies the envelope to package the content of

business document with necessary headers as well as

security and transportation standards.

Semantic level of interoperability deals with the

meaning of data and ensures that data will be

interpreted the same at both communication ends.

Semantic layer also defines structures and elements

of the business documents as well as the meanings

of the terms used in these documents.

On the process layer, main concern is

reconciliation of business processes. This layer

defines roles of business partners, order of business

documents exchange and how to respond to

information in business documents with appropriate

actions within defined business process. To take

advantage of new technology business processes

should be reexamined and reengineered and this

issue goes to the heart of e-Business infrastructure.

Today, there are several competing standards on

each layer and following sections give overview of

different standards considered as candidates for

deployment of e-Invoice infrastructure in Croatia.

There are several XML frameworks that handle

interoperability issues on different levels of

interoperability, with twelve of them listed and

compared in (Nurmilaakso, 2006).

On technical layer our candidates are:

ICSOFT 2008 - International Conference on Software and Data Technologies

350



ebXML - a modular suite of specifications for

conducting business using Internet, that puts at

enterprise disposal standardized methods for

business message exchange, data

communication, definition and registration of

business processes



Web Services – based on a collection of XML

technologies with the core consisting of three

standards: SOAP (Simple Object Access

Protocol) for transport, UDDI (Universal

Description, Discovery and Integration) for

discovery and WSDL (Web Services Definition

Language) for description. Additional standards

extend these basic standards and implement

different capabilities such as security and

reliable messaging.

4.1 ebXML

ebXML, in development since 1999 and now in its

version 3.0, provides solutions on all three layers. It

encompasses following set of standards, most of

them accepted as ISO 15000 standards:



ebMS (ebXML Messaging Services, accepted as

ISO 15000-2) - standard for exchanging

messages reliably and securely. It also provides

means to route a payload to the appropriate

internal application once an organization has

received it.



ebRIM (Registry Information Model, ISO

15000-3) and ebRS (Registry Service, ISO

15000-4) - standards for publishing and

discovery



ebCPP (Collaboration Protocol Profile and

Agreement, ISO 15000-1) - standard for

specifying the details of how an organization is

able to conduct business electronically. It

specifies such items as how to locate contact

and other information about the organization,

the types of network and file transport protocols

it uses, network addresses and security

implementations.



ebCCTS (ebXML Core Components Technical

Specification, ISO 15000-5) - standard for

defining business documents semantics



BPSS (Business Process Specification Schema)

- standard for describing business processes

One of the primary strengths of the ebXML

infrastructure lies in its modularity. With a few

exceptions listed standards may be used somewhat

independently as they are only loosely related. The

elements of the ebXML infrastructure may interact

with each other, but in most cases are not required

to.

ebMS operates on technical level of

interoperability framework and its version 2.0 is the

most implemented ebXML specification with many

successful implementations. ebMS is complete

solution which provides ways to pack data and

transport them reliably and securely. On the other

hand, ebMS is technically complicated standard and

for some features implemented in version 2.0, such

as security and reliability, more advanced

implementations appeared. Weakness of ebMS

version 2.0 was recognized and new ebMS

specification version 3.0 carries significant changes

and it is turning up to Web services technologies.

ebMS 3.0 still relies on SOAP and SOAP with

Attachments, but it uses WS-Security and WS-

Reliability or WS-ReliableMessaging for security

and reliable transport respectively.

4.2 Web Services

Web Services core standards, SOAP, WSDL and

UDDI, are not sufficient to handle successfully all

aspect of e-Business infrastructure. A couple years

ago lack of standardization concerning service

discovery and business semantics significantly

impeded usefulness of Web Services (Albrecht et al,

2005). In the meantime situation has improved and

is still changing rapidly with many standards

concerning e-Business in the process of

formalization by relevant standardization bodies.

The most important standards for e-Business are the

following:



WS-Security – this part of WS-* specification is

meant to provide a flexible set of mechanisms

that can be used to construct a range of security

protocols. The main goal is to accomplish end-

to-end message content security and not just

transport-level security. Message integrity is

provided by XML Signature. Message

confidentiality leverages XML Encryption in

conjunction with security tokens to keep

portions of a SOAP message confidential.



WS-Reliability/WS-ReliableMessaging – this

standard is intended to provide quality of

service in the reliable delivery of messages.



WS-Addressing – purpose of this standard is to

provide transport-neutral mechanisms for

addressing Web services and messages.

Standard defines XML elements to identify

Web service endpoints and to secure end-to-end

endpoint identification in messages.

Two of the greatest strengths of Web Services are

support from major software vendors and support for

its core standards in many different languages from

DEPLOYMENT OF e-INVOICE IN CROATIA

351

very beginning. Implementation libraries exist in

languages such as Java, .NET, Perl, Python, Visual

Basic etc. and this was probably the major factor in

their fast acceptance. Web services standards are

also modular in nature and they do not depend on

each other with the exception that all of them use

SOAP as base protocol.

4.3 ebXML/WS Final Remarks

Existence of two competing standards confuses

users and puts them in uncomfortable situation.

There are not many complete ebXML

implementations around, and only ebMS is well

accepted and implemented. On the other side Web

Services technology is still evolving and WS

specifications are not yet mature nor do they have

significant reference implementations. Denmark’s

experience after it completes its transition to UBL

2.0 and WS-* will provide valuable and eagerly

awaited input.

First step in resolving such situation was made

recently by ebMS technical committee when it put

development direction of ebMS version 3.0 towards

Web Services technologies. This move resulted in

lack of backwards compatibility with ebMS version

2.0 and ramifications of this are yet to be seen in

practice. On the other hand, new version has

introduced new features such as different processing

modes, message pulling and message partition

channels which are step ahead comparing to Web

Services technology.

Some authors say that the ebXML organization

views the ebXML standard not as an alternative to

Web services, but as the standard for "Business"

Web services. "Business" Web services are based on

a peer-to-peer collaborative business process model,

while the basic Web services are based on a client-

server, RPC style model. ebXML provides a

modular suite of specifications that is designed to

enable standards-based, peer-to-peer, collaborative,

business communication between enterprises.

ebXML is complementary to basic Web services and

builds upon them to enable "Business" Web services

(Endrei et al, 2004).

5 MESSAGE STRUCTURE

After resolving issues regarding technical layer of

the interoperability framework and establishment of

message exchange protocols, there is one more

question that needs to be addressed – agreeing on a

format for the message. As has already been stated

in the introduction, today XML is the first, and for

all practical purposes the only solution for sharing

structured data across different IT systems.

But, porting flexibility of a paper invoice to the

digital domain proved difficult to achieve. Even

though defining XML schema for exchange of data

in specific situation and between parties that know

each other business well is fairly easy task,

interoperability becomes important sooner or later.

How to represent date in such communication is the

simplest example of interoperability problems (is it

DD-MM-YYYY or MM-DD-YYYY?) and situation

is similar regarding different conventions for use of

decimal point in North America and Europe.

Bottom-up approach, without agreement on

interoperable standards, resulted in a whole array of

different XML schemas for e-Invoice in use today.

Most of them were defined ad hoc as an extension of

ERP systems currently in use or for some specific

industry or market segment (large customers, for

example).

To realize maximum benefits and savings from

implementation of e-Invoice infrastructure,

integration with ERP (Enterprise Resource

Planning) and SCM (Supply-Chain Management)

systems is essential and this requires adoption of

standards for semantic and process layer of

interoperability framework. Unfortunately, as is the

case with the technical layer, there are three globally

competing standards in existence today:



UBL (Universal Business Language) –

currently in version 2.0.



GS1 BMS (Business Message Standard)



UN/CEFACT CII (Cross Industry Invoice) –

awaiting formal acceptance, work has already

started on version 2.0

There is multitude of criteria that can be used for

deciding this question, and authority of

UN/CEFACT standards body weighs heavily here

with UN/TDED norm (ISO 7372) and its follow up

ebCCTS (ISO 15000-5) norm. ebCCTS serves as

foundation for both UBL and CII, and GS1 BMS

committee has announced its intention to follow

similar path in next versions of BMS. Delay in

formal acceptance of CII standard gives an edge to

UBL, but question is far from settled.

Additionally, there is a question of integration

with product catalogs and the role of e-Invoice in the

wider e-Procurement picture. GS1 BMS standard

requires existence of GLN and GTIN catalogs, while

UBL can work even without them. CII on this

account has the advantage because it can work with

catalogs across different industries. Successful

resolution of this problem hinges heavily on the

ICSOFT 2008 - International Conference on Software and Data Technologies

352

Figure 1: Croatian e-Invoice project organizational framework.

involvement of business subjects, but also on ERP

vendors and their willingness to support adopted

standards.

6 e-INVOICE IN CROATIA

Development of e-Business in Croatia was slow and

progressed in piecemeal steps. Although there is

visible improvement in providing basic electronic

services for dealing with government, for example

enabling submission over Internet of social security

and tax forms (but only for firms and not for

individuals), National strategy for development of e-

Business was adopted only recently, at the end of

2007. Main goal is to increase economic

competiveness and to enable wider adoption of e-

Commerce. e-Invoice and e-Procurement are among

its most important projects.

The main obstacles in e-Invoice adoption are

Croatian legislation, especially VAT legislation, and

absence of interoperability framework. Our

legislation is currently being adjusted as a result of

negotiation with EU legislation and it is expected

that this obstacle will soon be removed.

There are many open questions in adoption of an

interoperability framework in Croatia. Starting

points in building our interoperability framework are

use of common standards and compatibility with EU

directives. The first step is initiation of a pilot

project with the intention of providing answers to

business and technical dilemmas. Proposed

organizational framework for e-Invoice pilot project

is shown in Figure 1.

Taking into consideration reluctance of firms and

their software vendors to change and adapt their IT

systems to newly defined format, one possibility is

for service providers to assume responsibility for

converting exchanged messages to appropriate

format. Exchanges of e-Invoices with international

systems are encouraged to go through service

providers.

Basic roles of service providers, as defined by

Croatian legislation, are receiving, sending,

archiving and securing of electronic documents in

the name of contracted users (Narodne novine,

2005). We are planning to take into account

directives from European Committee for

Standardization that additionally defines roles such

as conversions between different formats,

authentications and digital signing.

DEPLOYMENT OF e-INVOICE IN CROATIA

353

7 CONCLUSIONS

Croatia has started deployment of e-Invoice as first

of several planned e-projects in accordance to

recently adopted National strategy for e-Business.

First task is to define common ICT infrastructure

that will serve as foundation for further development

of e-Business. There is a common agreement that it

should be based on XML family of standards, and as

much as possible in compliance with EU directives

and practice.

Croatian Government and several public and

private institutions are in the process of starting a

pilot project with the primary goal of choosing

appropriate standards for defining secure and

reliable communication, business documents

description and business process description. There

are several competing standards in each area and

choosing between them is not a trivial task.

Beside technology characteristics other issues

should be taken into account such as future direction

of technology development and progress of situation

in European Union. At the moment we are leaning

towards Web services as technology for enabling

secure and reliable communication although we are

closely monitoring ebXML suite of standards. There

are still open questions about standards for

describing business documents and standards for

registry implementations. Our hope is that pilot

project will provide us with further insights

necessary for successful implementation and

deployment of e-Invoice infrastructure.

REFERENCES

Albrecht, C. C., Dean, D. L., Hansen, J. V., 2005,

Marketplace and technology standards for B2B e-

commerce: progress, challenges, and the state of the

art, In Information & Management, Volume 42, Issue

Banerjee, S., Golhar, D.Y., 1994, Electronic data

interchange: characteristics of users and nonusers, In

Information & Management 26 (1) 65-74.

Bryant, C., Liezenberg, C. (editors), 2008, E-invoicing

2008, European market description and analysis, Euro

Banking Association and Innopay

Brun, M., 2008, Electronic invoicing to the public sector

in Denmark, http:// www.epractice.eu/cases/EID,

accessed 15.03.2008.

Cimander, R., Kubicek, H., 2006, eInvoicing in Finland –

The Example of the Region of South Karelia, Case

Study, www.epractice.eu/files/upload/gpc/document/

1958-1165416631.pdf, accessed 17.03.2008.

Endrei M., J. Ang, A. Arsanjani, S. Chua, P. Comte, P.

Krogdahl, M. Luo, T. Newling, 2004, Patterns:

Service-Oriented Architecture and Web Services, IBM

Redbooks

European Commission Informal Task Force on e-

Invoicing, 2007, European electronic invoicing final

report

Hayes, F., 2002, The story so far: e-commerce,

ComputerWorld (June 17) (2002).

Narodne novine, 2005, Zakon o elektroničkoj ispravi, NN

br. 150/2005 (in Croatian)

Narodne novine, 2002, Zakon o elektroničkom potpisu,

NN br. 10/2002 (in Croatian)

Nurmilaakso, J., Kotinurmi, P., Laesvuori, H., 2006,

XML-based e-business frameworks and

standardization, In Computer Standards & Interfaces

Nurmilaakso, J., 2008, EDI, XML and e-business

frameworks: A survey, In Computers in Industry 59.

ICSOFT 2008 - International Conference on Software and Data Technologies

354