Keywords

1 Introduction

The “digitisation” of production and logistics provides many significant, new advantages to modern supply chain management in the so-called Industry 4.0 concept. Design features of Industry 4.0 are interoperability, virtualisation, decentralisation, quick response, service orientation and modularity. This paper is concerned with document exchanges to facilitate collaboration between business partners and, in particular, e-invoicing.

Regulations play an important role in adopting e-invoicing within one country or region. Such regulations mandate the use of certain standards to guarantee the security and integrity of business document exchanges and fight against tax evasion and fraud. For example, the EU Commission implemented in April 2014 new regulations relating to public procurement across Europe in the form of the e-invoicing Directive 2014/55/EU, which sets out deadlines by which European government bodies must be able to receive structured electronic invoices from suppliers. The introduction of e-invoicing legislation across Europe in particular has greatly boosted the number of companies wishing to be able to exchange structured electronic invoices. Currently the number of invoices sent across Europe annually is estimated to exceed 40 billion. Meanwhile, the annual growth rate for e-invoicing is around 10–20%.

Although, e-invoicing has enabled businesses to efficiently generate e-bills and track them in real-time to reduce the possibilities of fraud and avoid any data entry errors. However, e-invoicing is creating many challenges, such as compliance, cross-border issues, data heterogeneity, changeable rules and regulations, and the identification of errors in complex systems. Compliance issues arise when different regulations within each country change very quickly. For example, in France, medium companies must use e-invoicing by 1 July 2025 and small companies by 1 July 2026. Rules and regulations differ from country to country and even region within countries. Some countries and states within one country impose additional requirements such as archiving and e-reporting, which can be tricky to implement, raising additional issues related to compliance of cross-border transactions. The issue of heterogeneity arises when the system deals with various data and messaging standards and formats, particularly when messages need to be sent via different delivery protocols (hub, Web Service, PEPPOL). Moreover, error handling is another big issue in e-invoicing. Systems with a high degree of complexity and automation mean errors are very hard to detect and correct in a timely fashion.

The paper proposes creating an e-invoicing ecosystem of services to address these challenges. The proposed system can be composed, configured, and customised according to different contexts under Service-Oriented Architecture (SOA) and Business Process Modelling (BPM) principles [18]. We demonstrate this idea through a pilot case study on the rapid development of an e-invoicing application using existing services and a workflow engine.

The paper is structured as follows. Section 2 presents some background and related work on e-invoicing discussing the standards in place. Section 3 describes our solution and Sect. 3.4 an implementation using the WASP worflow portal. Section 4 describes some preliminary evaluation results and Sect. 5 concludes this paper.

2 Related Work

We first describe the area of e-invoicing with its main drivers and challenges. This is followed by an overview of existing standards and solutions. In the next section, we review existing efforts that can lead to opportunities to deliver efficient e-invoices services via API marketplaces.

2.1 e-Invoicing Drivers and Barriers

Electronic invoicing (e-invoicing) enables businesses to exchange digital invoices in a safe, efficient and secure manner through software without the intervention of humans. E-invoicing depends on secure networks and opens common data standards that enables software to exchange business information seamlessly and automatically [13].

The drivers and challenges associated with the adoption of e-invoicing are illustrated in several publications. For example, [16] runs 3 case studies and observes the drivers and barriers to the adoption of e-invoicing in large scale Greek manufacturing industries. The main drivers are acceleration of invoicing process, reduced costs and improved auditing and compliance with tax rules and regulations. The barriers related to navigating through complex regulations and costs are caused by changes to existing IT infrastructure to adapt to standards.

[12] states that although the benefits associated with the adoption of e-invoicing have been highlighted in numerous reports and international forums, the adoption rate in most countries has not reached 20%. The firm must perceive the benefits derived from e-invoicing both before and after adopting the IT and communication infrastructure since they have a positive and significant influence on the firm’s behaviour. Perceived security is also necessary for a firm to use e-invoicing for the first time. Nevertheless, once adoption has taken place, this factor no longer influences the user’s intentions. Therefore, security cannot be considered a differentiating aspect of e-invoicing but, rather, an indispensable and inherent characteristic. Finally, ease of use will increase intentions of continuing to use e-invoicing among firms that have already adopted it. It accelerates the learning process and means that the benefits obtained will be more highly valued.

The two main barriers inhibiting the growth of e-invoicing are systems issues and supplier reluctance [1]. The Basware study found that companies’ reasons for engaging in e-invoicing include improved processes, increased accuracy, and lower costs. Those that implemented e-invoicing most frequently cited foster transactions, improved processes, greater accuracy, and improved compliance and audits as key benefits they have achieved. Improved customer service and supplier relations were also mentioned as benefits. One reason for the low adoption rate is that the business world is riddled with legacy systems. For instance, many companies have multiple systems for ordering, accounting, and paying and are still struggling to get these internal systems to communicate with each other, let alone with all their suppliers’ different systems. For these reasons, many standards have emerged to facilitate interoperability at different levels (e.g. data, transport, business process).

2.2 e-Invoicing Standards and Solutions

As mentioned earlier, the European Parliament and Council defined a common standard for e-invoicing named Directive 2014/55/EU to provide a common template to develop interoperability within the European Union [6]. This has triggered the development of several standards, one of which is a common business term dictionary or data model (the European Norm EN16931Footnote 1). Where necessary, however, countries or organisations can create a separate Core Invoice Usage Specification (CIUS). For example, XRechnung is a Core Invoice Usage Specification (CIUS) of the EN 16931 used in Germany. In addition to the data model, message representation standards are based on notations such as XML. For example, there are two supported XML formats of XRechnung (as with the EN 16931). The first one is CII (UN/CEFACT Cross Industry Invoice). The second one (from Oasis Open) is the evolution of an older standard [19] called UBL 2.x ISO/IEC 19845 in 2015Footnote 2.

In addition, Germany also uses the ZUGFeRD 2.1 standard for hybrid in- voicing (in France, the same standard is referred to as Factor-X). This standard uses a human-readable PDF/A3 invoice document in which a CII invoice is embedded. The e-invoicing format used in Spain is FacturaE, an XML-based invoice format that uses e-signatures and follows the XAdES standard. Italy also uses an XML standard format called InvoicePA with two digital signature formats: CAdES-BES (CMS) and XAdES-BES (XML).

In 2014, the European Commission declared that UBL 2.1 was officially eligible for referencing tenders from public administrations (one of the first non-European standards recognised). It is expected that the adoption of UBL as a standard message representation will increase as it defines a royalty-free library of standard XML business documents that not only supports invoicing but also all other aspects related to the digitisation of the commercial and logistical processes for domestic and international supply chains (e.g. procurement, purchasing, transport, logistics, intermodal freight management).

In addition to data and messaging standards, there are multiple alternatives for communicating invoices:

  • Centralised system: in which invoices can be uploaded and transferred via file transfer protocols or web services. This is the most common method for B2G exchanges such as PPF (formerly Chorus-Pro) in France. However, there are exceptions. For example, in Italy, all invoices, including B2B, have been exchanged via Sistema di Interscambio (SdI) from 1 January 2019.

  • 2-corner model: supplier and buyer exchange invoices directly via a private network (e.g. EDIFACT) or email but the latter is less common as there are no guarantees of delivery.

  • 4-corner model: supplier and buyer exchange invoices via Accredited Service Providers that provide the required connection to a network. This is the model used in the PEPPOL network, described next.

PEPPOL [7] is a set of artifacts and technical specifications which facilitate easy data exchange across disparate government systems and their suppliers. Many EU countries have adopted PEPPOLFootnote 3 as a communication method, including Belgium, Croatia, Cyprus, Denmark, Greece, Ireland, Latvia, Lithuania, Luxemburg, Malta, Norway, Poland, Slovenia, Sweden and the UKFootnote 4.

In addition to communication protocols, there are various business processes (involving different business entities) that can be used to exchange invoices. These business processes depend on the type of e-invoicing (B2G, B2B, B2C), the application domain, the communication method used (hub, 2-corner, 4-corner), and the business’s nature relationship. For example, UBL defines several business processes that can be used to exchange invoices, such as pre-payment, spot payment, payment in advance of delivery, invoices with references to despatch advice, etc.

Besides e-invoicing, there are now a number of e-reporting requirements being introduced. For example, the French tax authorities are discussing defining a lifecycle for e-invoices, e.g. created, rejected, paid etc. Changes in status of an e-invoice must be reported to tax authorities alongside other data. PEPPOL is also introducing the capacity for service providers to do e-reporting (the so-called 5-corner model). There are many ongoing standardisation efforts: CEN/TC 440 [10], which consolidates standardisation efforts in several supply chain processes, including electronic ordering, tendering, notification, and fulfilment across 14 business sectors.

Many e-invoicing solutions come under a variety of forms to address the challenges of implementing these standards, such as:

  • Enterprise systems: e-invoicing functionalities are integrated within a large enterprise system such as IBM or SAP, providing all necessary functions behind the scene.

  • Accounting systems: similarly, e-invoicing functionalities are integrated within an accounting application such as Xero or MYOB.

  • E-Invoicing systems: complete e-invoicing solution which can be customised to different data formats, and delivery protocols, offering all functions to be integrated with a local information system or ERP. Examples include Pagero.

Whilst these solutions are suitable for Government agencies and large companies, they present difficulties when adopted by SMEs, namely high cost, lack of flexibility and vendor lock-in.

As a result, we believe that there is a need for cost-effective solutions that are both open and flexible to allow companies to better leverage their existing assets.

3 Proposed Solution

3.1 Towards an API Marketplace for e-Invoicing Services

The proposed solution is based on leveraging the concepts of cloud computing, Software-as-a-Service concept, API economy and Business Process Modelling (BPM). These are explained briefly next.

Cloud computing is the primary delivery vehicle for a new generation of software services referred to as Software-as-a-Service (SaaS). Essentially the in- infrastructure and software are no longer on “premise” and the SaaS provider supplies the network access, security, application software, and data storage from a server. On a technical level, any SaaS functionality is delivered via an Application Programmable Interface (or API) accessible through a web browser, mobile device, or another application. These APIs are developed according to four key factors; necessity, reliability, usability, and scalability. SaaS charging models are generally aligned with the fact that users pay for what they use rather than paying a high upfront standardised cost regardless of their usage. One key target market for the SaaS model is small to medium-sized businesses [3], as it lowers entry costs. Providers can use a range of charging models such as perpetual licence, subscription, transaction-based, and ad-funded. In Information Systems (IS) research, APIs are conceptualised and analysed as boundary resources, i.e., resources at the interface between platform owners and third-party developers [3].

The SaaS model has enabled the emergence of API marketplaces which provide a place for developers to build and share their APIs and a consumer to find a suitable API for integration into their applicationsFootnote 5. Such marketplaces exist (e.g. Rapid API), but many researchers pointed out that it is not a trivial job for a consumer to find suitable APIs from a myriad of APIs in a constantly growing and evolving API landscape [17, 22, 24]. Multiple studies have attempted to address the issue by exploring the relationship between consumers, APIs and consumers with APIs for optimal recommendations [9, 23, 25]. Chen et al. [5] proposed an API recommendation model using a deep learning method that aggregated the text details in source code with the API usage by API Context Graph Network and Code Token Network. Authors found that combing textual code details improve the accuracy. In a similar approach, Qi et al. [21] proposed a text description-driven web API recommendation that assures the suggested API’s compatibility using mashup creation records. Lian and Tang [14] proposed an API recommendation method using a graph collaborative filtering method that identifies the relationship between a consumer and an API. The authors experimented using a real dataset from Programmableweb.com and found that the approach performed better than other approaches.

The availability of APIs makes it possible to rapidly compose them and build new applications via business process modelling (BPM) principles and technologies. BPM can be categorised as any process modelling that is performed to enhance the overall operation of a business, a way to understand and optimise workflows and create data-driven visual representations of key business processes [2]. A BPM language allows the definition of a graphical representation of a business process or workflow that includes attributes such as events that occur within a workflow, who owns and starts those activities, decision points and different paths workflows can take based on their outcomes, devices involved, a timeline of each step and success and failure rates of the process. According to Penker [8] a business process model may have six different reasons to be created, which are: to understand the key mechanisms of an existing business; to orient the creation of suitable information systems that support the business; to implement improvements in the current business; to show the structure of an innovated business; to experiment new business concepts; and to identify business elements not considered part of the core, which could be delegated to an outside supplier [20].

BPMN, the most popular business process modelling languageFootnote 6 provides a standardised graphical notation that is easy to use for business analysts, allowing them to document and communicate their business processes within their company and external business partners. For more details about BPMN, see [4]. Several open-source and commercial tools support BPM, such as Signavio, Camunda and Kissflow. The availability of these tools is used as a basis for our solution described next.

3.2 Proposed Architecture

As illustrated in Fig. 1, the proposed architecture has the following components:

Fig. 1.
figure 1

Proposed Architecture

Full size image

  • Workflow Engine: This component is the core for controlling all e-invoicing processes. It executes all process instances and their activities as well as the communication with component services invoked via their API.

  • Process Workflow Designer: this allows the user to define and manage processes graphically. Such processes are based on the BPMN 2.0 standard.

  • Workflow Control Portal: this component allows the user to control workflow instances creation, execution, and monitoring.

  • API Marketplace: a marketplace in which several APIs offer functionality that can be integrated into service in the workflow.

This architecture supports two types of users, service providers and end-users (typically SMEs). Service providers consist of developers and technology providers whose aim is to create a range of e-invoicing services. Once deployed, they advertise these services, as mentioned earlier, as APIs in the workflow marketplace.

End-users that are part of companies involved in e-invoicing exchanges will collaboratively design and form certain workflows by combining different services in a logical flow. One example is a seller that uses a workflow supporting the sequence of invoice creation, validation and sending with special cases, e.g. receiving a notification if the invoice is malformed. These workflows, once designed are run on a workflow engine. This engine is responsible for calling the linked services and following the flow. Compared to controlling the flow using a bespoke application, end-users benefit from rapid deployment and modification of workflow (this is important in a fast-changing environment). In addition, these workflows can be executed and simulated manually using the workflow execution portal and/or using automated triggers set up using the web application. Finally, the workflow web portal serves as a third party between the user and the workflow engine and provides the user with human-readable updates on the processes.

3.3 Definition of the Case Study

We define a case study that will be used to drive the implementation of a prototype based on a realistic e-invoicing scenario. We have the simple case of a buyer and a seller in this case study. The seller’s responsibilities are:

  • Create an invoice in the format expected by the buyer. We assume that the seller has a legacy system that uses EDIFACT, and the buyer requires invoices in UBL to be sent over the PEPPOL network. The seller must check that invoices do not contain an error before sending them.

  • The seller must monitor the status of the invoice (see Fig. 2 showing invoice status changes) after it has been sent.

Fig. 2.
figure 2

How invoice status changes during an exchange

Full size image

The Buyer’s responsibilities are:

  • Read the invoice and check there are no errors

  • Verify if the invoice should be Rejected or Approved based on the invoice contents.

  • Pay the invoice

This process simplifies real-life e-invoicing processes that can include many more statuses and other participants besides a single seller and buyer but will be sufficient to demonstrate the usefulness of the proposed architecture. As an example, Table 1 represents the seller’s dashboard in which Inv_2 was sent to the buyer. Table 2 represents the buyer dashboard in a scenario where the buyer has approved the contents of this invoice and will now proceed to pay it using the “Pay” workflow action.

Table 1. Seller Dashboard after sending an invoice
Full size table
Table 2. Buyer Dashboard after approving an invoice
Full size table

3.4 Implementation

Many ongoing research efforts propose comprehensive workflow development and management platforms such as IceCoreFootnote 7. In this implementation, we chose to use the Workflow and Service Automation Platform (WASP)Footnote 8 provided via the EFPF PortalFootnote 9 as a basis for our implementation.

Five e-invoicing services have been made available to workflow designers through the WASP marketplace:

  • Get Pending Messages to Send: this allows messages to be retrieved from the ERP for a particular customer (a seller). It creates an invoice in the UBL XML standard and sends it over the PEPPOL network

  • Create and send Invoice: this allows an invoice to be created in the destination format and sent over the relevant network.

  • Check status: Checks the status of a message that has been sent

  • Retrieve received messages: allows messages to be retrieved from the network for a particular customer (a buyer)

  • Set status: allows the status of a message to be changed

Two workflows are designed via WASP Designer: one for the seller and one for the buyer. A snapshot of the seller workflow is shown in Fig. 3.

Fig. 3.
figure 3

BPMN Workflow for Send Invoice

Full size image

The first task in this workflow is to create and send the message containing the invoice. This service itself performs multiple tasks like format conversion, checking for errors in the format, validation rules, etc. If the invoice has some errors, the user is notified. Otherwise, the invoice is sent. From that point, the user can check the changes in the status of the invoice until it gets rejected or paid. The buyer has a similar workflow that checks for received invoices and then offers the user the possibility to perform actions such as Approve, Reject or Pay the invoice.

Fig. 4.
figure 4

WASP Control Panel

Full size image

4 Evaluation

4.1 Running the Workflows

Running the workflows is conducted via the WASP platform. Users can access and create instances of different processes using the control panel as shown in Fig. 4. Here we can see that the process Send Invoice v5 is started using the actions tab on the right.

Upon the execution of the process instance, the task assignee is required to complete the user actions required for the completion of the process. The seller is also presented with a confirmation tab which is displayed to make sure that all the user information is correct and gives the seller an option to complete the said process by using the confirm button, as shown in Fig. 5.

Fig. 5.
figure 5

Confirmation pop up

Full size image

For the buyer, “My Tasks” panel would contain different actions which will have the impact of changing invoices statuses and triggering other actions. For example, approving the invoice will have the impact of triggering the action of paying invoices. These actions will result in the display status action on the seller side to display the latest status of the invoice.

4.2 Discussion

The prototype implementation has confirmed that the use of an API marketplace combined with the power of BPM technology gives the flexibility for solution providers to rapidly select relevant APIs and form workflows based on the needs of their customers.

There are still many limitations in the proposed approach. Firstly, the creation of workflows still require technical skills and existing workflow portals need to enable business users more control over the creation and execution of their workflows without IT support. Secondly, the number of e-invoicing APIs is still very low so there is a need for e-invoicing authorities to encourage the creation of API marketplaces e.g. via API standardisatrion and accreditation processes.

In addition, the business processes selected in the case study are very simplified versions of those used in reality. There are many more variations such as invoicing of deliveries of goods and services against purchase orders, based on a contract, invoicing the delivery of an incidental purchase order, pre-payment, spot payment, payment in advance of delivery, invoices with references to a dispatch advice etc. Many of the business processes listed above require the use of additional services which either utilise the information produced by one of the services above or sends information to them in order to produce an end result, hence forming a new workflow.

5 Conclusion and Future Work

This paper has reviewed recent developments in the area of e-invoicing and has shown that as e-invoicing processes will mature amongst trading partners, the demand from customers will increase and the entry costs to adopt e-invoicing will be reduced. However, due to the multitude of fast evolving standards and regulations, maintaining such infrastructures will be costly in the long run.

The availability of cloud-based software, storage, and computing resources without upfront infrastructure costs or high fixed costs is becoming an attractive solution for developers to deliver and monetise specialised and customisable solutions to a group of clients with specific needs [11]. Our paper advocates the use of ecosystem of SaaS components for the rapid composition of e-invoicing solutions. Although this idea has been used in different application areas (e.g. [4, 15], this paper is first one to suggest its use in e-invoicing.

In the short term, future work will focus on improving the existing prototype to include a realistic business process that gives visibility on all invoice status changes required by existing French tax regulationsFootnote 10. In the long term, the ecosystem should be extended to include more services that play a broader role in e-invoicing such as PDF invoice fields recognition, integration with public tax authorities portals, integration with accounting systems etc.