A MODEL FOR E-ORDERING AND E-INVOICING

(1)

A MODEL FOR E-ORDERING AND E-INVOICING

Kiril Kiroski Marjan Gusev

Institute of Informatics, Faculty of Natural Sciences and Mathematics

Skopje, Macedonia Skopje, Macedonia

ABSTRACT

In this paper we introduce a new model for ordering and e-invoicing. Today, electronic means to conduct purchases and sales are becoming the overwhelming way in which companies operate, and they need to adjust their existing ordering and invoicing applications to be interoperable with new, electronic means for exchanging produced documents. The most sophisticated solutions are built on cloud computing and using web services, and work with SaaS (Software as a Service) idea. Due to non-existence of such services in Macedonia, our primary goal is to present proposed solution that will be interoperable with today’s most sophisticated international platforms which address this problem. Proposed model satisfies interoperability requirements of today’s most sophisticated and desired e-procurement platform in Europe (PEPPOL), and regional initiatives (EBiz4All). Our model will propose a number of different user roles which will use described choreography to fulfill complete electronic paperwork for completing an e-purchase procedure. We will present use cases which this solution should be able to perform, and give brief descriptions of produced data and transactions required to occur for completion of the business collaborations.

I. INTRODUCTION

With the model proposed in this study, we are continuing our work on e-ordering and e-invoicing, and adopting the approach proposed by EU initiatives. These initiatives produce solutions that have been developed on an international scale, and intended to work on European level, such as PEPPOL [10], or regional level (EBiz4All) [11]. PEPPOL goals are to implement common standards which will enable public e-procurement process on EU level. This should lead to one big market, where all participating countries and companies can compete, thus increasing competition and enabling any supplier to respond to any European public tender, while in the same time utilizing existing national platforms. Companies and public institutions will benefit from PEPPOL with introduced wider market, and it will boost innovation and strengthen the competitiveness of all European companies. It is estimated that annual savings, if e-procurement is adopted in entirety will be exceeding Euro 50 billion. One of the regional initiatives that follows the ideals and goals set by PEPPOL is EBiz4All. It is project funded by the Austrian Research Promotion Agency (FFG), and involves companies from Austria, Macedonia, Serbia and Croatia. Research made in the course of this project [2] helped in the extraction of the legal and business frame needed to facilitate the software solution. The main characteristics of this solution are that it will closely follow

standards proposed by the European Committee for Standardization (CEN) [3], and will be based on CEN-developed XML standards.

Our model will propose system interoperable with these initiatives, with accent on complete ordering and e-invoicing transaction. Taking this step came as natural continuation of our work with benchmarking e-ordering and e-invoicing solutions [1], [9]. We also guided our efforts in the lines drawn by one of the leading European efforts involving e-ordering and e-invoicing, a project developed by IADBC and called e-PRIOR. It aims at “… a practical implementation of interoperable electronic services at a pan-European level, within the post-awarding phase of public procurement” [14]. In this paper we give brief description of our proposed model, and how it complies with profiles and processes described by international platforms.

II. MOTIVATION

Previous research involving e-ordering and e-invoicing and associated literature [4] [5] [6] [7] [8], helped us in drawing out the main features that our desired solution has to incorporate. We also concluded that developing a solution that will follow standards proposed by CEN will be most preferable, since all international initiatives in Europe comply with these standards. Having defined the main features, and message and document standards, we concentrated on the technology required to enable them. We previously established that large enterprises in most cases have implemented ERP and CRM systems, with modules enabling them to make orders and invoices inside the system and transmit them to their business partners. What our solution should do is give adaptable, inexpensive way for small and medium enterprises to compete on the same market as large enterprises, and also provide these large enterprises interface to the system.

Thus, desired solution has to be built so that enables use of thin client (internet browser) and web services. The issue of interoperability is addressed through following CEN standards, which should enable order produced by our solution to be transferred through PEPPOL network and received and processed by supplier’s software, and vice versa. Invoices produced by the supplier must be able to be processed by buyer’s system, and properly archived. Another requirement that this system satisfies is that it is built according to SaaS idea, and capable of working in the Cloud, thus enabling it to grow and be used by varying number of clients.

The purpose of the system is to enable companies to use it so as to be able to produce electronic orders and invoices for clients. The general idea is to enable a company to use the software product as a tool for creating orders and invoices,

(2)

and distributing them by electronic means, as a full replacement for hard paper documents. Authorized users can allocate employee which can create invoices, and give permit to customers for creating orders. They can analyze all incoming requests for customer account and produce workflows for produced documents according to company’s business rules. Our model will propose a number of different user roles which will use this choreography to fulfill complete electronic paperwork for completing an e-purchase procedure. We will present use cases which this solution should be able to perform, and give brief descriptions of produced data and transactions required to occur for completion of the business collaborations.

III. APPROACH

A. Profiles

To be able to describe functionalities used in our model, we use Profiles, similar (but not entirely equal) to CEN/BII Profiles. Our starting point were CEN/BII profiles [12], but we added 3 new basic profiles (Basic Order using catalogue, Revoke Order and Revoke Invoice), extracted 2 basic profiles from advanced CEN/BII profiles (Order response and Invoice dispute from Procurement), and used them to build our advanced profiles (Advanced ordering using catalogue, Advanced ordering without catalogue, Advanced invoicing, Procurement without catalogue, and Procurement using catalogue) – each of them unique and distinguishable from advanced CEN/BII profiles. The final model is consisted of twelve profiles (seven basic and five advanced).

We defined following basic profiles:

- Basic Order,

- Order Response,

- Basic Order using Catalogue,

- Basic Invoice,

- Invoice Dispute,

- Revoke Invoice, and

- Revoke Order.

Using our basic profiles we derived five advanced profiles to use in our model:

- Advanced Ordering without Catalogue,

- Advanced Invoicing,

- Procurement without Catalogue, and

- Procurement using Catalogue.

B. Service Lifecycle

Looking at our profiles, we observed that each of our basic profiles belongs to exactly one state of produced documents’ lifecycle. We also noticed that each of the advanced profiles belongs to two or more states of the lifecycle. This is shown on Figure 1. For the purposes of electronic purchasing, we have defined four states for created documents, each of them uniquely named as:

1. Ordering – In this state we place profiles used to create orders, and responses to orders, so the final outcome will be accepted order (contract between Buyer and Seller is established, and proceeds to next phase), or rejected order

(there is no contract, and both parties have no further legal obligations). Basic profiles defined in this state are: Basic Order, Order response, and Basic Order using catalogue. Advanced profiles using one (or more) of basic profiles above are: Advanced ordering using catalogue, Advanced ordering without catalogue, Procurement using catalogue, and Procurement without catalogue.

Description

Lifecycle states

Related profiles

Debtor finds errors or inconsistencies in the invoice and disputes its content by sending message to the Creditor. Creditor views the dispute, and solves the problem that created it.

Basic profile(s): Invoice dispute

Advanced profile(s): Advanced Invoicing Procurement without catalogue Procurement using catalogue Buyer creates an order by filling

an order form, and then submits it to the Seller.

Basic profile(s): Basic Order Order response Basic Order using catalogue Advanced profile(s): Advanced ordering using catalogue Advanced ordering without catalogue Procurement without catalogue Procurement using catalogue

Creditor creates an invoice by filling the invoice form, or by choosing the option to create invoice from previously submitted order, and then submits it to the Debtor.

Basic profile(s): Basic Invoice

Advanced profile(s): Advanced Invoicing Procurement without catalogue Procurement using catalogue

Buyer may not be able to buy goods and services already ordered, so he wants to cancel the entire order; Seller may not be able to deliver ordered goods, so he wants to revoke already submitted invoice.

Basic profile(s): Revoke Invoice Revoke Order

Advanced profile(s): Advanced ordering using catalogue Advanced ordering without catalogue Advanced Invoicing Procurement without catalogue Procurement using catalogue

Ordering Invoicing Disputing Cancelling

Figure 1: e-ordering and e-invoicing service lifecycle. 2. Invoicing – In this state we have profiles concerning invoice creation, where Creditor creates an invoice (either by filling the invoice form, or creating it from previously submitted order) and sends it to the Debtor. Final outcome is an invoice received by the Debtor, claiming payment for delivered goods or services. The only basic profile defined in this state is Basic Invoice. Advanced profiles using it are: Advanced invoicing, Procurement using catalogue, and Procurement without catalogue.

3. Disputing – This state is concerned with disputing and solving the contents of an invoice. This means that if Debtor finds errors or inconsistencies in the invoice, he can dispute them by sending dispute message to the Creditor. Creditor can issue new, corrected invoice, or he can issue credit note to the Debtor. Basic profile defined in this state is Invoice dispute, and advanced profiles using it are: Advanced invoicing, Procurement using catalogue, and Procurement without catalogue.

4. Cancelling – This state is concerned with optional, more advanced problems, and are matter of agreement between concerned parties. If Buyer is not able or don’t want to buy goods or services he previously ordered, he can revoke (cancel) the entire order. Similarly, if Seller can’t deliver goods or services he billed, he can revoke the invoice. Outcome can be acceptance (with or without royalties) or rejection (contract is still valid, and both parties are obliged to drive it to the end). Basic profiles defined in this state are: Revoke Invoice and Revoke Order. All five advanced profiles use this state.

C. Service Reference Architecture

A Cloud service needs to have a number of key components which define its functionalities. Cloud Service Reference Architecture (see Figure 2) describes these key components – actors, interfaces, data artifacts, and profiles – and connections and relationships existing among these components [13].

(3)

Every organization involved with Cloud Services can play roles made in combination between primary actors defined with the architecture:

- Cloud Service Provider – negotiates service level and

costs, and makes services available according to this agreement. Provider is concerned with managing technical infrastructure, billing, and other reports to consumers.

Provider Interface Cloud Service

Developer Cloud Service Consumer

Cloud Service Provider

ecorin Profiles Request, SLA, Contracts, Agreements, Service Templates, Offerings, Images, ... Data Artifacts Functional Interfaces Service Catalog Security Manager Service Manager

Figure 2: Service architecture for our solution (ecorin)

- Cloud Service Consumer – Organization or individual

contracting for services with Cloud Service Providers. They use contracted services or (as another cloud) provide them to other consumers. Their responsibility is to select desired services, administer them and make payment for their use.

- Cloud Service Developer – Designer and implementer of

a service. His job is to (using service template) describe the service, and deploy the service components using description provided in the templates. Provider can choose to customize the service before making it available in their offerings.

D. Actors and Roles

For the purposes of describing our model, we will use Actors who can take corresponding Roles, depending on the profile and documents and messages produced in their interaction. Actors are parties involved in ordering and invoicing process, and in our case we have two actors – Customer and Supplier. These actors can take one of the seven roles, of which two can be taken by Customer, and five by the Supplier. Actors and roles are shown on Figure 3.

Manager

Buyer Seller's systemSeller Administrator

Customer Supplier

Debtor Creditor

make purchase

Figure 3: Actors involved and corresponding roles. In our model, the Customer can take one of the following roles:

- Buyer – Customer takes this role when making orders, or

revoking orders and invoices.

- Debtor – Customer takes the role of Debtor when

invoicing is involved.

On the other side, Supplier can take one of the following five roles:

- Seller – Supplier takes the role of Seller in situations

involving manual work with received orders.

- Seller’s system – role actually not taken by a human,

instead it is used when Supplier is receiving orders from catalogue, which can be automatically processed.

- Creditor – Supplier takes the role of Creditor when

dealing with invoices.

- Administrator – users on the Supplier side taking this role

deal with general settings for the application, maintenance and user administration.

- Manager – manager is responsible for delegating

permissions to different users, capable of bringing decisions in case of dispute or revoking, and manages the workflow of documents.

E. Business process, collaborations and transactions

Business process represents a set of activities in a predefined order, intended to produce specific product or goal. Every profile uses at least one business process. For the purposes of our model we defined three business processes:

- Ordering – business process involving Buyer and Seller

roles with Order as final product.

- Billing – business process involving the roles of Creditor

and Debtor, dealing with invoices and credit notes.

- Ordering from Catalogue – business process similar to

Ordering, with the difference of involving automated system response instead of living person in the role of Seller. All profiles and business processes are described using one or more collaborations. The choreography of business collaborations defines the sequence of interactions when the profile is run within its context. In Table 1 we can see processes and collaborations related to them.

Table 1: Business processes and collaborations defined within each process.

Business Process Collaboration Coll. ID

Ordering Ordering 001 OrderResponse 003 NullifyOrder 008 RevokeOrder 009 RevokeResponse 010 Billing Invoicing 004 InvoiceDispute 005 ResolveInvoiceDispute 006 RevokeInvoice 007 Ordering from Catalogue CatalogueOrdering 002

Messages exchanged between supplier and customer are described with structured electronic business documents called transactions. Source and destination of these transactions is one of the involved parties, or automated

(4)

system. The entire list of transactions and corresponding data models is shown in Table 2.

Table 2: Transactions (messages) exchanged by Supplier and Customer and their Data Models.

Transaction Trns ID Data Model

SubmitOrder 001 Order SubmitCatalogueOrder Trns002 Order AcceptOrder Trns003 OrderAcceptance RejectOrder Trns004 OrderRejection SubmitInvoice Trns005 Invoice DisputeInvoice Trns006 InvoiceDispute CorrectWithCredit Trns007 CreditNote CorrectWithInvoice Trns008 CorrectiveInvoice RevokeInvoice Trns009 InvoiceRevoke OrderNullified Trns010 OrderNullification RevokeOrder Trns011 OrderRevoke RevokeRejected Trns012 RevokeRejection

IV. THE MODEL

We will give brief view of the model using one profile (Advanced Invoicing), since the entire model is too big to be presented in this paper. We choose this profile since it involves two business processes (Ordering and Billing), and a number of collaborations and transactions. Every other profile in our model is built in a similar way using collaborations and transactions to describe main flow and possible scenarios for the given profile. Main advantage of this model is that it is interoperable with international initiatives, while it gives new options and opportunities for e-business collaboration, not implemented in CEN/BII profiles.

A. Business requirements

The Supplier sends an electronic Invoice that can be received and processed by the Customer.

An Invoice containing VAT information must comply with VAT rules of the country where Supplier is registered. The Invoice content enables the Customer’s system to route the document to a specific person, department or unit within the organization; this may be required for authorization etc. The Invoice content facilitates automatic validation of legal and tax values, tax accounting and payment.

The Customer processes an electronic Invoice sent by the Supplier, and notifies Supplier of inconsistencies in the Invoice.

Supplier resolves the dispute and sends corrected document(s) to be processed by the Customer.

B. Actors involved and roles

Customer The customer is the legal person or organization who is in demand of a product or service. Examples: buyer, consignee, debtor, contracting authority (in case of public organizations) Supplier Supplier The supplier is the legal person or

organization who provides a product or service. Examples: seller, consignor, creditor, economic operator

Party Role/actor Description

Supplier Creditor One to whom a debt is owed. The Party that claims the payment and is responsible for resolving billing issues and arranging settlements. The Party that sends the Invoice. Also known as Invoice Issuer, Accounts Receivable, Seller Supplier Seller The seller is the legal person or

organization acting on behalf of the supplier and who sells goods or services to the customer. Customer Debtor One who owes a debt. The Party

responsible for making settlements relating to a purchase.

The Party that receives the Invoice. Also known as Invoicee, Accounts Payable, Buyer.

Customer Buyer The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

Diagram shown on Figure 4 links the business processes to the Roles performed by the Business Partners.

Figure 4: Business processes, actor and corresponding roles involved in the profile.

C. Choreography of business collaborations

Each business process in scope contains within itself one or more business collaborations:

Business Process Business

Collaboration(s) Collaboration ID Billing Invoicing InvoiceDispute ResolveInvoiceDispute RevokeInvoice 004 005 006 007 Ordering NullifyOrder 008

Figure 5 shows the relationships (i.e. links) between the collaborations of each business process implemented by the profile. The choreography of business collaborations defines the sequence of interactions when the profile is run within its context. Each sequence of interactions can be understood as a run-time scenario.

(5)

Figure 5: Profile choreography.

Description The Creditor creates an Invoice that claims a payment for goods or services, and sends the Invoice to the Debtor.

Debtor may dispute the Invoice by creating and sending a Dispute notice. In that case, Creditor corrects by sending a Credit Note and/or a corrective Invoice.

Due to unanticipated chain of events, Creditor must revoke already created invoice. Creditor sends Revoke notification to Debtor. Revoked invoice is stored, and in the case of existing Order connected to the Invoice, the Order in question is nullified.

Pre-conditions The Debtor and the Creditor have identified each other and a contract between the two or an Order exists.

The Debtor has agreed to accept electronic Invoices that use this profile.

Post-conditions a. The Debtor has received and processed an Invoice.

b. The Debtor has received and processed the RevokeInvoice notification.

- If an Order associated to the Invoice in question exists, it is nullified by the system. c. The Debtor has received an Invoice or a combination of Invoices and Credit Notes which he accepts for payment.

Exceptions None.

Remarks None.

D. Business rules 1) Process rules

-

If documents make references to contracts such as

framework agreements, those contracts supersede the document content.

- Penalties for cancelled contract have to be previously agreed upon both by Customer and Supplier.

2) Information constraints

- In case of existing Order referencing the Invoice in question, it must be nullified.

E. Collaboration detailed description 1) Invoicing collaboration

- Overview

Categories Description and Values

Collaboration ID 004

Description The collaboration is used to deliver an Invoice from a Creditor to a Debtor but it does not require the Debtor to produce any business level response.

Pre condition None.

Post condition(s) The Debtor has received an Invoice Transactions SubmitInvoice - Trns005

Roles Creditor

Debtor

- Diagram

- Activity description

Role Activity Description

Creditor Create and send SubmitInvoice

The Creditor creates and sends Invoice to the Debtor Debtor Receive and process

SubmitInvoice

The Debtor receives the Invoice

2) InvoiceDispute collaboration

- Overview

Description Following the reception of an Invoice the Debtor may electronically raise a dispute. Pre condition Note: this profile does not preclude the

Creditor from noticing an error and taking corrective action independently. The Customer in the role of a Debtor, has received an Invoice from the Supplier in the role of Creditor.

Post condition(s) The Invoice in concern is being disputed. Transactions DisputeInvoice - Trns006

Roles Creditor

Debtor

- Diagram

Main flow

Debtor Raise dispute of invoice

In disputing the Invoice, the Debtor sends a

DisputeInvoice transaction to the Creditor with details of the dispute.

3) ResolveInvoiceDispute collaboration

- Overview

Description Following a disputed invoice this

collaboration is used to exchange documents to resolve the invoice dispute.

Pre condition Debtor Has received an invoice, and he has disputed it.

Post condition(s) a. The Debtor has received a resolution to the dispute.

b. The Creditor has recognized that the dispute concerns a request for additional documents.

(6)

CorrectWithInvoice - Trns008

Roles Creditor

Debtor

- Diagram

Scenario All

Creditor External reception of a dispute

The Creditor has externally received a dispute to an invoice and proceeds to identify how to resolve it.

Scenario Overcharge

Create and send CorrectWithCredit

If there is an overcharge, which is resolved by giving credit, the Creditor creates and sends a

CorrectWithCredit transaction to the Debtor.

Scenario Undercharge

Create and send CorrectWithInvoice

If there is an undercharge, which is resolved by issuing an additional invoice, the Creditor creates and sends a CorrectWithInvoice transaction to the Debtor.

Scenario Replace Invoice

Cancel invoice with CorrectWithCredit and send

replacement invoice as

CorrectWithInvoice

If the Creditor decides to resolve the disputed invoice by replacing it, the Creditor creates and sends a CorrectWithCredit transaction (zero balancing the disputed Invoice) and also sends a new replacement invoice by using a CorrectWithInvoice transaction.

Scenario All Above Post condition

Evaluate CorrectWithCredit and/or

CorrectWithInvoice

The Debtor receives and processes the

CorrectWithCredit and/or CorrectWithInvoice transactions and proceeds to verify that they sum up to the right amount and/or information has been corrected.

4) RevokeInvoice collaboration

- Overview

Description The collaboration is used to deliver an

notification of Revoking an Invoice from a Creditor to a Debtor but it does not require the Debtor to produce any business level response.

Pre condition The Debtor has received an Invoice Post condition(s) The Debtor receives notification of cancelled

Invoice. Transactions RevokeInvoice - Trns009 Roles Creditor Debtor - Diagram - Activity description

Creditor Create and send RevokeInvoice

The Creditor creates and sends notification of revoking an Invoice to the Debtor Debtor Receive and process

RevokeInvoice

The Debtor receives the RevokeInvoice 5) NullifyOrder collaboration

- Overview

Categories Description and Values

Description The collaboration is used to deliver an notification of Nullifying an Order from a Seller to a Buyer but it does not require the Buyer to produce any business level response. Pre condition An Order has been placed by Customer and

an Invoice has been produced on Order's basis.

Post condition(s) The Buyer has received an notification of nullified Order Transactions OrderNullified - Trns010 Roles Creditor Debtor - Diagram - Activity description

Seller Create and send OrderNullified

The Seller creates and sends notification of Order nullification to a Buyer Buyer Receive and process

OrderNullified

The Buyer receives the Order nullification

F. Transactions

Electronic messages exchanged within the profile, and the sequence in which the documents are exchanged is shown on Figure 6.

(7)

Figure 6: Transactions and document exchange sequence.

1) SubmitInvoice transaction

Categories Description and values

Identifier Trns005

Description A structured electronic business document claiming payment for goods supplied under conditions agreed between the Supplier and Customer.

Authorized Roles Creditor Debtor

Initial Event Create and send invoice. Terminal event Receive and process invoice. Scope Invoicing for purchased goods.

2) DisputeInvoice transaction

Identifier Trns006

Description A structured electronic business document providing a business level response to an invoice.

Authorized Roles Debtor Creditor

Initial Event Raise dispute of invoice. Terminal event Receive and process dispute

Scope To inform Creditor that the Debtor has objections to an invoice.

3) CorrectWithCredit transaction

Identifier Trns007

Description A structured electronic business document for a Creditor to specify a reduced payment for a disputed Invoice, or for fully canceling an Invoice.

Initial Event Create and send CorrectWithCredit Terminal event Receive and process CorrectWithCredit Scope Reducing the amount claimed in an invoice or

fully canceling the invoice.

4) CorrectWithInvoice transaction

Identifier Trns008

Description A structured electronic business document for replacing an existing invoice.

Initial Event Create and send CorrectiveInvoice Terminal event Receive and process CorrectiveInvoice Scope Corrective invoice used when undercharged

or for replacing erroneous invoice.

5) RevokeInvoice transaction

Identifier Trns009

Description A structured electronic business document revoking claim for payment between the Supplier and Customer.

Initial Event Create and send invoice revoking notification.

Terminal event Receive and process invoice revoking notification.

Scope To revoke claim for payment.

6) OrderNullified transaction

Identifier Trns010

Description A structured electronic business document informing Buyer that his Order has been nullified.

Initial Event Order placed by the Buyer in the Supplier's system has been nullified.

Terminal event Receive Order nullification.

Scope To inform the Buyer that his obligations regarding the corresponding order have been nullified.

V. CONCLUSION

In the previous sections, we stated that what we hope to achieve with the model is not to invent and develop entirely new solution with its own elements. Instead, this new solution must be interoperable with primarily European platforms, so as to enable users of our software to cooperate with international companies, and to compete for international public tenders.

We also stated that, since Macedonia’s e-procurement platform does not involve elements required in the post-award phase of the public procurement, it will help reduce required paper documentation and help increase transparency of the entire process.

Our future work will be developing the solution we modeled, and bringing new quality into e-ordering and e-invoicing software, which will help in making it more attractive and useful to the end users. Using this solution, on the other hand,

(8)

will help decrease expenses and increase competition in public tendering.

REFERENCES

[1] Kiroski K., Gusev M., e-Invoicing and e-Ordering: Analysis and Comparison, Proceedings of The 7th International Conference for Informatics and Information Technology (CIIT 2010)

[2] Sonntagbauer, P., Gusev, M., Tomic Rotim, S., Stefanovic, N., Kiroski, K., and Kostoska, M., e-Government and e-Business in Western Balkans 2010, Proceedings of the 2nd

ICT Innovations Conference, Macedonia, 2010

[3] E-Invoicing compliance guidelines, CEN Workshop Agreement 16047, December 2009

[4] Benchmarking of existing national legal e-business practices, from the point of view of enterprises (e-signature, e-invoicing and e-contracts), European Commission Directorate-General for Enterprise and Industry, November 2006

[5] The E-Payables Benchmark Report, Aberdeen Group, March 2007 (http://www.ob10.com/ Docs/Aberdeen_The_E-Payables_Benchmar_%20Report_March%202007.pdf )

[6] Capgemini, Rand Europe, IDC, Sogeti and DTI (November 2009). Smarter, Faster, Better eGovernment: 8th Benchmark Measurement; (http://ec.europa.eu/information_society/eeurope/i2010/docs/benchmarki ng/egov_benchmark_2009.pdf)

[7] OECD. The e-government imperative: main findings, Policy Brief, Public Affairs Division, Public Affairs and Communications Directorate, OECD, 2003

[8] Final Report of the Expert Group on e-Invoicing, DG Internal Market

and Services, November 2009

(http://www.ob10.com/Docs/eInvoicingExpertGroup_final_report_e-invoicing_EN_1.pdf)

[9] Kiroski, K., Gusev, M., and Kostoska, M., A new methodology to benchmark sophistication of e-Invoicing and e-Ordering, Proceedings of the Second International Conference, ICT Innovations 2010.

[10] PEPPOL, PEPPOL facilitating cross-border eProcurement, http://www.peppol.eu/work_in_progress, as seen on 1.3.2011. [11] EBIZ4ALL, Requirements document, project sponsored by Austrian

government - COIN (Cooperation and Innovation) program

[12] CEN/ISSS Business Interoperability Interfaces for Public procurement in Europe (CENBII), http://www.cen.eu/cwa/bii/specs/ as seen on 1.4.2011 [13] Interoperable Clouds - A White Paper from the Open Cloud Standards

Incubator, DMTF International, DSP-IS0101, November 2009 [14] e-PRIOR, e-ordering and e-invoicing project, found at