go to home page | go to navigation | go to page content | go to contact | go to sitemap
Home > Blogs > a glimp into the future of e-invoicing

practice a glimp into the future of e-invoicing

The ePractice blog: discuss, praise, disagree.

ePractice.eu provides its members with a blog in which all registered users can post opinions, questions and links to news related to eGovernment, eInclusion and eHealth. Your point of view is what makes ePractice.eu relevant to other public administrators all over Europe, so feel free to post and...

a glimp into the future of e-invoicing

17 April 2009 | 5203 Visits | Rating: 4 (maximum:5)

Vision on electronic invoicing (business) in the future
The most important theme on the agenda of companies and government bodies at this moment is electronic invoicing. Many companies see electronic invoicing as an instrument to realize cost savings and to improve the socially responsible undertaken - image. Not always will electronic invoicing lead to cost savings but generally it is assumed it will.

My advice is to conduct a thorough investigation of the impact on the organization, systems, applications, processes and information. Such a study should provide a view on the vision on electronic invoicing within the company and deliver information for drawing up the Business Case. Do not forget Electronic Invoicing is part of the end-to-end trade process (Electronic Business). The study will have to mind the overall trade process including purchase-to-pay and order-to-cash.

In addition Electronic Business refers to Exchange Services (exchange of messages) between customers and suppliers. An activity that takes place in the Exchange Domain, the domain area with focus on interoperability and not on the purchase and sales process.

Based on several investigation and implementation projects combined with extensive study of technological developments and innovative business concepts a vision emerged on the future of Electronic Business, more specific Electronic Invoicing.

“My vision on Electronic Invoicing is of an electronic business highway located in the cloud above us.”

My vision on Electronic Invoicing is of an electronic business highway in the cloud above us. Emerging technologies and growing electronic business networks are shaping the future of Electronic Business into an open an intelligent information service highway wherein Electronic Invoicing fits as a tiny little exchange instance that enables smart and fast reach to connected partners.

Actually I mean that intelligent instances on the electronic business highway make it possible to exchange information and establish processes to work together with others that are also using the highway. Companies will focus more and more on the reason of their existence and move core-functions like generate and send, receive and process invoices to the outside or transfer to third parties whom are specialized therein.

The electronic business highway will become a shielded area of the Internet or another IP-network comparable to Internet telephony (Voice over IP). The electronic business highway will be an open and for everyone accessible instance that is in no way identical to the Value Added Network (VAN) from the EDI age.

Three possible scenario's for the emergence of the electronic business highway
It is my expectation that the emergence of the electronic business highway will follow the same scenario's as developed by the World Economic Forum for the Digital Ecosystem. The Digital Ecosystem is about the digital space - the convergence between IT, Telecommunications, Media and Entertainment - where users evolve from mere consumers to active participants and governments face major policy and regulatory challenges.

Three scenarios are developed to gain a better understanding of the possible outcomes of the Digital Ecosystem in the near future. These scenarios deal with answers around two critical questions that influence the realization and adoption of the electronic business highway.

Firstly, will social and economic value creation be industry controlled and led, or organic and community-led. Secondly, will the digital business environment evolve toward a more open or closed system.

To the year 2015 three possible roads will be followed to arrive at the Digital Ecosystem:

1) Safe Havens describes a digital world in which the industry plays an important role and responds by vertically integrating to create secure walled environments that provide all digital services and is based on closed standards.

2) Middle Kingdoms describes a digital world in which consumers, governments and forward-looking businesses push for interoperability, enabling the emergence of a Digital Ecosystem dominated by intermediaries that effectively connect users to like-minded individuals and highly specialized suppliers that can best meet their needs. In the middle of the space between consumers and suppliers lie the kingdom where the power lies.

3) Youniverse describes a digital world in which the rise of organic grassroots communities as powerhouses of economic value turns traditional business thinking on its head. This leads to the rise of new organizational structures and to digital experiences that are highly personalized. This digital world will mainly be based on common standards and open systems. The line between users and producers will be further blurred as open source supporting software and collaborative community structures become more sophisticated.

Who is going to build the electronic business highway ?
The electronic business highway will evolve from safe havens to middle kingdoms whereby governments, communities and/or market sectors will play an important role in the realization of the superhighway. It is clear that in the coming years not everyone need to start building its own electronic business highway but that one umbrella highway will emerge to which every enterprise and existing electronic business (invoicing) network (e-hub) can connect.

It will still take several years before we are that far but this highway will surely be established. Currently suppliers of e-business (invoicing) networks already are confronted with questions from customers to connect trading partners that are not on their network.

Much attention arise for the phenomenon roaming that a number of players in the domain area define as “Roaming is interconnecting networks to provide real cross border reach, in a way that an operator can reach another operator’s users directly, nationally and internationally”.

In other words realizing the interoperability between the e-business (invoicing) networks, the régime of fees that form the basis for the usage of each others services / networks and the way the taxation takes place to the customer / client. Universal reach for clients is one of the most important drivers to realize interoperability between networks and will ultimately lead to a network of networks AND something or someone will in time grab the role of super administrator.

When are you ready for the electronic business highway ?
Many around us have presumably been thinking about going for gmail, yahoo-mail or live-mail abandoning their own e-mail server. A number of companies will take this step in the coming years. In my opinion the predominant argument is “why pull in complexity when others can do it better and cheaper”. I believe that in the near future G-invoicing or Y-invoicing or M-invoicing has much possibility to be successful. Yahoo, Google and Microsoft have the power-to-execute and are able to realize the dream of the electronic business highway.

Why pull the complexity of Electronic Invoicing into your own organization and systems when the only goal you have is “send, receive and process invoices” ? Electronic Invoicing is non-intrusive, in fact the invoicing process will not be hampered, and around us there are strong players that made Electronic Business their core-competence. Perhaps you ask yourself when you will be ready for Electronic Invoicing and where you stand at this moment. The evolution path of Electronic Business (e-Business) provides a notion on the growth and future of Electronic Invoicing.

“Technology is shaping the future e-invoicing world” and demands a growing understanding of technology, standards, data security and control. It should be clear to everyone that Electronic Business goes through a shift from “tightly coupled to loosely coupled systems” .

From left below to right above Electronic Business evolves from Traditional to Synchronization.

1) Traditional: phone, fax, EDI and paper
Paper is still the most important medium for the transmission of an invoice while e-mail has taken up a strong position for the exchange of product information and order data. However the amended European regulations will strongly stimulate the use of e-mail in the next coming years.

Electronic Data Interchange, in the last years became synonym for the exchange of documents via Value Added Networks based on non-XML standards such as EDIFACT and ASC X12. Especially international companies and certain industry sectors have embraced EDI in the past although this not always leaded to the desired success. Nevertheless Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) is still heavily employed in the automotive and retail industry.

2) Communication: e-mail, online web presentment
Invoices - like other documents - will be transmitted using e-mail in PDF or other format but at the same time Electronic Invoice Presentment solutions are further being implemented. These solutions enable us to present invoices in HTML format in a personalized environment. In addition it is possible to download the invoice in different formats. The said means of communication distinguish themselves in the way the invoice is offered to the customer. When using e-mail the invoice is send to the customer - push-mechanism - while when using online presentment a pull-oriented approach is followed. The customer receives a notification message, e-mail or sms, when there is an invoice available that can be downloaded.

3) Integration: XML standards and web-oriented architectures
The rise of the eXtensible Markup Language (XML) drifted the world of Electronic Business more apart. This seems a contradiction to those that scream XML is the Esperanto of the future. However the different industry-specific XML-based vocabularies that have been developed (OAGI, UBL, PIDX, CIDX, RosettaNet, ...) the past years lead to the well-known interoperability question, the lack of information (data) interoperability. These XML-vocabularies define business information-elements in the context of the industry as such that everyone can understand and process them. The XML-language takes care of defining the structure and the industry-specific methodology for modeling and representing the semantics, the meaning of the information elements.

In the EDIFACT era industry-specific subsets were developed to further restrict the number of data elements. The basis for these subsets is/was the EDIFACT syntax and semantics as defined in the EDIFACT directories (libraries).

The XML-vocabularies on the other hand are based on different methodologies (semantics) and have different structures (syntax). Ultimately these create the luxury problem that most companies wrestle with, “the business standards dilemma”. Enterprises are not able to make a choice between the multitude of standards.

Standardization is one of the biggest hurdles for global adoption of Electronic Business (invoicing) but not the end of Electronic Business. The interoperability question is in fact about systems and people not having a common understanding of the meaning of the underlying data because there is no shared grammar and library on which the meaning is based.

A few international initiatives are started that should lead to one universal grammar library:
- The UN/CEFACT Core Components Technical Specification (CCTS) is a syntax-neutral methodology for the development of a common set of semantic building blocks of information-elements. The Core Components Technical Specification is based on the ISO Standard 150000-5 (ebXML Core Components Technical Specification ebCCTS). More information can be found on the website of SAP, the driving force behind the CCTS, under Message Definition Languages.

- The Open Group Universal Data Element Framework (UDEF) is a method for categorizing information-elements by means of an alphanumeric key (tag) and assigning a simple name to an element.

Those initiatives will not directly solve the interoperability question because none of these will be implemented on short notice in all the available XML-vocabularies. The luxury problem will continue to exist for a while.

4) Collaboration: a process-centric approach stimulated by business processes that interact using standardized B2B protocols containing message-formats, transport protocols and business process management components.

This stage of Collaboration where companies apply all kinds of integration to realize Electronic Business goes through interconnected networks. Especially the e-business (invoicing) networks that support the exchange of messages between trading partners constitute the most important link in this stage.

5) Synchronization: pure peer-to-peer networks that have no central control and where data gets replicated. Further away in the future Ecosystem oriented architectures will evolve. This stage in the evolution path will not obtain the required level of maturity in the next few years to enable major adoption.

What influence do distribution models have ?
The last years several distribution models emerged or were identified by institutions. For simplicity I will identify four models whereby the difference is mostly based on the position of the trading partners.

1) Seller Direct Model
In this model the seller is the dominant party and makes the invoice available to customers via an online presentment environment, web-portal, in different formats (EDI, XML, CSV, PDF, ...). Invoices can also be transmitted in PDF format via e-mail.

The model is most appropriate from the perspective of the seller because of the opportunity to tighten the connection with customers (vendor lock-in), at the same time the seller can recommend more products and services (cross- and up selling) and strengthen its brand name. Moreover the invoice has the same look-and-feel as the paper invoice.

2) Buyer Direct model
In this model the buyer is the dominant party and forces the supplier to enter or deliver the invoice via the online environment or via EDI / XML.

The model is most appropriate from the perspective of the buyer because of the opportunity to tighten the connection with suppliers (buyer lock-in) and reduce the administrative burden when the seller delivers the invoice in a standardized format in the online environment. When this online environment is integrated with the financial system the buyer is able to automatically process the invoice. More benefits can be achieved if the sellers retrieve the purchase orders from the same online environment and also confirm delivery dates and pricing.

The choice for one of these distribution models is partly determined by the bargaining or market power, and the desired wish of flexibility of involved parties. When the power is concentrated in the begin of the supply chain, on the selling side, the result will most often be a Seller Direct model while a dominating customer result in a Buyer Direct Model. Both models benefit from a limited number of standards and transport protocols, leading the highest possible interoperability.

Soon or later both customers and suppliers are confronted with the digital spaghetti architecture.

This structure evolves from the growing number of point-to-point connections and requires increasing efforts to connect new trading partners.

The Seller and Buyer Model in time will not increase the reach of trading partners and certainly not when buyers and sellers are faced with strong dominating partners. For most small and medium-sized companies, but also for dominating buyers and sellers willing to establish electronic business the Consolidator Model is the best fit and less intrusive.

3) Consolidator model
In the consolidator model a third party, a service provider, facilitates the exchange of documents between sellers and buyers providing various exchange services among web-enabled presentment environments and all kind of methods and standards for exchanging messages.

This model is most appropriate for small and medium-sized companies because the provider takes the complexity of different electronic standards out-of-their hands. There is a one time costs for connecting to the network of the consolidator and a transaction or monthly fee for the use of the service depending on the agreements made.

The main advantage for enterprises lies in the speed of connecting a large group of partners that already use the network of the consolidator. Especially when the service provider is running an extensive network of companies in the same market sector. Such an e-business (invoicing) network can be decisive in the choice of a service provider.

A provider who understands the problems in an industry sector is able to respond faster and provide additional services closely related to the business domain. For example in the world of Telecommunications and Utilities (energy, water,waste) Expense Management Solutions will add significant value to connected users.

The increasing number of e-business (invoicing) networks requires extra efforts from these network operators (consolidators) to ensure reach of trading partners over these networks. This gave rise to the networked environments (multiple connected hubs). The networked environments enable hub-owners to respond quickly to requests for exchanging messages with partners that use another network.

The network operators are now facing the same challenges that originally, not so long ago, gave birth to the e-business (invoicing) networks and are still the main reasons for their existence. E-business (invoicing) networks need to ensure widespread interoperability and interconnectivity to better serve - and keep on serving - senders and receivers.

Main aspects to address are cross-network addressing and routing, (message) content standards and transformation rules (format conversion), authenticity of origin and integrity of content. Answers are needed for questions such as how can a sender and receiver be uniquely identified, which message standard or grammar will be used as the common library, and how to ensure authenticity of origin, integrity of content and security.

Currently e-business (invoicing) network providers are tackling these questions by establishing bilateral agreements to ensure interoperability and interconnectivity. The Hub Alliance, an affiliation of Business-to-Business e-Trading Service Providers (or 'hubs') who have implemented a ground breaking initiative to interconnect different hubs ensuring that electronic trading is easier for all the hub users. Participants are a few of the big players in Europe: Certipost, Basware, Burns Business Exchange, Liaison, Causeway and Asite.

The Alliance was established to enable hub-to-hub interoperation and to encourage the wider use of electronic messaging between businesses. Members are currently prohibited from charging additionally for documents that are processed between hub members. Message standards, communications protocols, service levels and responsibilities are all defined by the membership and are intended to be as broad as possible to encourage the ease and speed of interconnectivity.

4) Four Corner model
The last model is the Four Corner model where the banking world will take care of the exchange of invoices between customers and suppliers. The already mentioned benefits of a consolidator apply and additionally banks provide possibilities to directly issue the payment of an invoice. There is not yet a working example of this model but it probably will not take years.

Mapping the distribution models on the evolution path ?
Now that the distribution models passed the revue let us look on how these models are plotted on the evolution path.

Some valuable and informative business and technological considerations to take into account.
Small, medium-sized and large companies should carefully investigate the business models and technologies of available solutions and service providers. The current e-business (invoicing) service providers are coming from many different backgrounds. Some players literally are involved in the gaming industry like B2Boost, the leader in transaction management.

Others rolled into the game of e-business and e-invoicing because paper-based invoices in the future are no longer an option:
- Output & Document Management Solution providers: StreamServe, Bringing Documents to Life, and Bottomline Technologies.

- Document & Information Logistics companies: TNT Post, the Dutch mail and logistic company, Certipost, the former Belgian Post company and Itella Corporation, formerly the Finland Post Corporation.

Even companies that have been providing B2B and EDI solutions for ages are Jumping on the Bandwagon of the e-business (invoicing) networks: Axway, Tie Commerce and SEEBURGER.

What all of these players have in common is that during the past years they developed solutions for solving the lack of interoperability between their clients with the objectives to reduce the amount of spaghetti. These solutions are based on different architectures, standards and types of software.

Two architectural approaches are generally followed:
1) Firstly, the use of a Common Information Model as the backbone for the solution.

The standards and models from clients are transformed into the common information model in the middle which is mostly based on a proprietary standard. Data is stored in a relational database or in an XML file system or database.

2) Secondly, the digital spaghetti structure is transferred into the solution

The existing point-to-point connections between trading partners are restated in the solution. There is no common information model and the power resides in the transformation capabilities of the underlying software. For each information flow between supplier and customer two transformation mappings are developed.

Not the most cost effective and efficient approach to solve the lack of interoperability between trading partners. As long as these providers can live up to their promises and ensure 100% client satisfaction this approach will work.

Will standardization solve the business standards dilemma ?
Once again it is a misunderstanding that XML is the solution, the Esperanto of the future. Some people even say XML is just plain text and does nothing. XML was created to structure, store and transport information. The XML-language takes care of defining the structure, the syntax, and the industry-specific methodology for modeling and representing the semantics, the meaning of the information elements.

The biggest challenge for all of us is solving the lack of interoperability between XML-based vocabularies and EDI libraries. True global electronic data interoperability requires more than an XML-based vocabulary.

For establishing global electronic collaboration and information exchange there must be a common understanding of the underlying data, the semantics of business information elements should be based on a standardized grammar, commonly available for everyone.

Many industry consortia and standardization committees have defined specific XML-based vocabularies. All of these vocabularies are based on different methodologies for representing the semantics of the business information elements. As such similar information elements in vocabularies are designed and named differently. This makes it hard to automatically translate these elements from one vocabulary to the other instead a mapping definition is required.

Due to the many XML-based vocabularies this becomes difficult and expensive, often identified as the business standards dilemma.

Standardization of the Content is not the breaking stone. It is not about speaking the same language but about understanding what we speak. Therefore standardization should focus on grammar, transformation rules and tools as such that both humans and machines are able to understand and work with it.

Initiatives that have been launched are:
- the UN/CEFACT Core Components Technology Specification (ISO 15000-5 ebCCTS)
- the Open Group Universal Data Element Framework

Adoption and incorporation of the UN/CEFACT CCTS methodology is agreed upon by most international standards but real cross-use of core components is not yet visible. Furthermore the UN/CEFACT CCTS is becoming a bit too complex with the extensive object-oriented approach propagated by the UN/CEFACT standardization committee.

Nevertheless it is the best initiative available at this moment and when the focus is brought back to the right perspectives, simply grammar, things will work out fine. The best architecture for an  e-business (invoicing) network solution that has no problem with the business standards dilemma in the communication with other networks looks as follows:

This will also be the underlying architecture framework for the electronic business highway.

Will the electronic business highway fulfill the interoperability requirements  ?
First of all it is imperative that the electronic business highway provides access to all sending and receiving trading entities and allows for inclusion of different e-business (invoicing) network providers.

Moreover there are common and open technology standards needed for message content and transport protocols including transformation and/or format conversions. These could best be based on a shared grammar and library such as the UN/CEFACT Core Components Technology Specification. These standards should be globally available to everyone without restriction and cost, or for a reasonable fee, 'en principe' no enterprise should feel excluded.

On top of these requirements enterprises need a smooth transition path from their existing integration approach to the new vibrating driving-experience on the electronic business highway. This demands ease of use, the ability to accommodate different existing and new solutions and free choice of service provider.

The road to Middle Kingdoms requires 'government' policies promoting innovation and competition, measures to encourage the industry to voluntarily contribute their best technology and to participate in the development of open standards.

Governments on a pan-European and international level with support of international standardization committees need to develop Common User Identifiers for addressing that are portable across Europe, similar to telephone numbers, open and independent from a service or network need to be developed. Two initiatives to mention are: the OASIS Customer Information Quality Technical Committee (OASIS CIQ TC) and the eGreen Pages Association.

The OASIS CIQ TC develops a set of XML specifications for defining, representing, interoperating and managing “PARTY (Person or Organization) CENTRIC INFORMATION” that are truly open, vendor neutral, industry and application independent, and importantly “Global” (ability to represent international data formats such as different types of party names and addresses used in 241+ countries).

Basware and Itella Information Oy are establishing a centralized directory containing messaging profiles and electronic addresses of ebusiness partners used for automated discovery and pairing of partners and routing of messages. The Open Initiative for Global Address Book in B2B Messaging - eGreen Pages - will be run by an open, non-profit e-invoicing operator association.

Is there a Business Case for e-business (invoicing) ?

Stay on board, more will come in a few days

Tags: EDIFACT, electronic data interchange, Interoperability Frameworks, UBL, UDEF, e-Invoicing

[Last update: 26-11-2011]

starstarstarstarempty starIn order to vote, you need to be logged in!

Showing 5 comments

To difficult

11 June 2009 | 6272 Visits | Rating: 4.5 (maximum:5)

In my opinion this will not be the future of e-invoicing. Because of several reasons:

- the models presented al show banks as actors. This more frequently not the case. 

- the models lack the presence of accounting software. Accounting software plays a pivotal role in facilitating e-invoicing in the B2B segment. Especially with regard to SME's: which consists over 95 percent of the entire B2B segment.

-  The vision in this article shows a growing complexity on e-invoicing in time. However, e-invoicing is as 'service innovation' aided by technical means. Apart from that, e-invoicing is no more than an instrument to get paid. And it could even be determined social innovation. It certainly is not technical innovation: all components to achieve e-invoicing are available. Those who promote e-invoicing as technical innovation or promote the need for consultancy when it comes to e-invoicing, have far greater interest in promoting those points of view than actually adding value and fuel to the adoption of e-invocing.

 

- In the future that lies ahead e-invoicing will increasingly become less complex and eventually become a mere commodity within a networked economy. From that perspective, e-invoicing has a striking resemblance with telecommunications.

 
F.W. (Friso) de Jong
EEI Platform 

 

 

Simplicity of e-invoicing is my main objectives and vision

14 June 2009 | 6205 Visits | Rating: 4 (maximum:5)

Dear Friso,

Thanks for reading the weblog entry on e-invoicing and for going through the vision presentation.

I need to clarify a few things before commenting on your remarks. The weblog posting is the first in a series of articles / writings about e-invoicing. In the next writings I am elaborating on the topics in the vision presentation. Unfortunately the first article is about distribution models and technology. The others will be about: implementing e-invoicing from inception to operation, the maturity of a company for e-invoicing and understanding the influence of maturity on the business case, building a vision statement on e-invoicing and chosing the right model, the onboarding process and influencing the rate of adoption.

The past months I have been lucky to present the vision statement to a few of the largest companies in the Netherlands. The main concerns I sensed during these sessions were about:
- unclarity of standards or better the lack of a one-size-fits-all standard supporting both full integration (data) and digitalisation (image) enabling reach to all business partners

- uncertainty about legal and fiscal regulations especially for cross border trade

- the business case, more specific the real story / doubts behind the savings and the lack of sufficient knowledge to determine the required investments and roadmap

Most importantly is the fear for vendor lock-in resulting in a lack of flexibility and reduced reach and the uncertainty about the financial stability of operators.

Everyone will recognise the first concerns as these are the barriers and inhibitors on the e-invoicing agenda for several years now. Although much has been done from a technology and standardisation point of view and from a legal and fiscal perspective (the new proposed VAT Directives) the discussions I had show the companies are reluctant to implementing e-invoicing.

The mindset of the companies I spoke towards my vision is positive. They support the idea that "exchange services" should become a commodity and encourage the work being done. They even confirm having considered going for Gmail or Ymail. Of course it is one bridge too far at current for e-invoicing exchange services but who knows what Google or Salesforce is doing. There are already dozens of these type of applications available on the Web.

At the same time the companies indicate they need support but due to their high level of maturity are not willing to outsource e-invoicing moreover ebusiness completely. The exchange of e-invoices is seen as only one element of their total supply chain process.

There is definitely a need for an ebusiness knowledge community driven by users and independent advisors, with participation of government organisations and standardisation commmittees. A place where people can find unbiased information. Precisely the objectives of what I am trying to establish. Spreading the word good or bad, pioneering in the search to new innovative approaches that make e-invoicing easy for users, helping others in finding their way through complexity. I am working in this domain field since I did my first implementation of ERP and EDI in the period of 1996 and have since 2005 guided several ebusiness projects from inception to operation.

If you are interested and "really" want to participate and share knowledge in an open collaborative environment on a voluntary free basis with no strings attached check out the Electronic Business Knowledge Village on linkedin.com.

Commenting on your remarks:
The vision propagates that a global communication and integration network should be established and explains it should be a technology neutral driven preferable by communities of like minded people and organisations with less or no commercial interest, which can not be said of some communities that emerged recently.

The road to get there will resemble the one telecommunications went through years ago. The distribution models shown are NOT AT ALL based on four-corners models in which banks are the main actors because there are simply no working examples of these models. The models are based on the electronic invoice operators (hubs) which could be or are participating in the EEI platform.

Whether or not this electronic business highway is established is not the main issue. The message merely is that Businesses should experience e-invoice as simple and easy, and should have the flexibility to choose and swith operator when they want. It is imperative that Supplier lock-in disappears and suppliers standardise their connectivity and data services . e-invoicing should fit as a tiny instance in the proposed network and ERP / Financial systems providers are urged to realise standard connectors in the next coming months.

Organisation like the EEI platform are encouraged to push for this simplicity and flexibility, and should encourage their members to strive for uniformity and standardisation. Although all components are available the framework to make e-invoicing simple for users still has to be build.

I know PEPPOL is working hard on establishing such an electronic business infrastructure. There have been other examples such as ABILITIES (Application Bus for InteroperabiLITy In Enlarged Europe SMEs) that could have been a good start. A standardised infrastructure based on Open Source and Open Standards provides companies a low cost and easy way to enter into e-invoicing.

Likewise to the telecommunication industry connectivity and exchange services are complex but the telecom companies have succeeded to make it look easy for all of us . Just buy a phone and establish a contract with one of the telecom providers and it works. When you want to switch just ask your new provider to handle the switch. What happens behind the scene is not visible to us and is not that easy, at least it was not in the past but standardisation made it easy.

Only when e-invoicing operators succeed in solving the interoperability and connectivity problems businesses will make the move to e-invoicing en masse.

In the future , hopefully the near future, companies should see e-invoicing like a commodity similar to energy, water, telecommunications, and internet services.

Last but not least the electronic business highway is not only about e-invoicing but is about all types of (document) exchange services in the purchase-to-pay and order-to-cash processes , but also health care related exchanges and other market.

Stimulating e-invoicing for SME's requires a framework that enable SME's to exchange invoices and other documents with any type of business partner, small and large companies, technology neutral.

Only then the rate of adoption will increase exponentially.

The worst e-invoicing could overcome is that businesses end-up dealing with electronic invoicing operators or solution providers that are unable to enable the required reach due to lack of uniform data and connectivity standards. I am not saying this will happen but the risk is there that the point-to-point spaghetti repeats itselve.

My vision and I am working for a consultancy firm, is that all of us should strive for standardisation and simplicity . Users of e-invoicing should in time , best would be next week, be able to connect their ERP / Financial system to the electronic business highway without having to spend large amounts of money to establish this.

As a firm we are talking to the big electronic invoice operators in Europe and to the ERP suppliers to get them buying in this vision and make e-invoicing simple for its users. We are also talking with organisations that have the technology to combine data standards, visual images and digital signatures in one document type.

Kind regards,

Danny Gaethofs

Both the Vision document on ebusiness (e-invoicing) and these comments are my own personal opinions.
Hope to see you next week in Brussel during the CEN eInvoicing Conference.

 

Lack of focus on implementing e-commerce today in the real world

14 June 2009 | 5999 Visits | Rating: 4.5 (maximum:5)

Dear Danny,

An interesting paper, but perhaps in some ways it is too complex and in other ways it makes simplified claims that miss important issues. Then again perhaps not because of your focus on the future and not doing something today with technology. I'll make some observations and then conclusions in the context of your paper.

Regarding complexity, are you perhaps trying too hard to design for serendipity? When a government wants all invoicing to be electronic (as has been true since February 2005 for the government of Denmark), or when a business in a specialized industry wants all invoicing to be electronic (say an industry with information components described by custom semantics not found in any CCTS registry), it needs to use a framework where standard semantics are understood and the model can be customized to accommodate the special needs. The standardization world does not provide all solutions off the shelf for real-world implementations and organizations need to move faster than the speeds that standardization has to offer. Thus, those standardization approaches that accommodate customization are more practical for today's solutions than other standardization approaches.

Regarding simplicity, are you overlooking the technical benefits of XML and the opportunity to extend an information set within an XML syntactic framework without breaking the underlying syntax that can be recognized commonly between implementations?

Regarding the comment that "CCTS is becoming a bit too complex" remember that there was a CCTS 2.01 release with a base set of data types suitable as a base for implementation.

I'm pleased to see that you cited PEPPOL and ABILITIES in your response to Friso. In all the cases of Denmark, PEPPOL and ABILITIES the semantics chosen are described by the OASIS Universal Business Language (UBL) and the syntax chosen is XML as a uniquely designed implementation of CCTS 2.01. The uniqueness is the use of a common library shared across multiple document types thus ensuring a common expression for business objects shared across multiple documents.

I find your paper strong on theory but lacking in implementation and operational details ... both of which are incredibly important (more important?) to organizations because of their need to be running successfully and quickly once embarking on electronic invoicing.

Too much theory and not enough practicality killed typesetting when replaced with desktop publishing.

Too much theory and not enough practicality killed hypertext when replaced with the web and HTML.

I find the same thing happening in Canada when I talk about how one can quickly get up and running with UBL. Too many consultants who are advising government offices are postponing the opportunities to prototype and build working solutions. Rather, they are spending time and money proposing and writing up lengthy and elaborate conceptual frameworks and unimplementable designs, bending the ears of people in charge with complex terminology and nice sounding phraseology.

Denmark, PEPPOL and ABILITIES show evidence of taking UBL off the shelf and using it successfully for electronic commerce, much like one takes HTML off the shelf and uses it successfully for electronic commerce. A line has to be drawn at some point in the continuum of brainstorming elaborate conceptual designs. These projects are examples of communities of users sharing electronic commerce requirements on a practical and implementable base. All communities of users of UBL can set out that part of UBL that is important to the interactions expected within the community.

As for addressing custom semantics and extra requirements not found in the suite of standardized semantics of UBL, the UBL document model provides for customization and the XML document syntax provides for extensibility.

The UBL technical committee especially recognized the needs for a community to use "less than everything" where there are UBL constructs not of import to them, and to use "more than everything" where there are no UBL constructs where they are needed. Every document type provides for both the common base constructs (for serendipitous interactions outside of the community of users) and unique extension constructs (for interactions within the community of users).

As I understand the Denmark, PEPPOL and ABILITIES projects, however, none of the projects needed to take advantage of customized extensions. I would anticipate private business building on UBL to define extensions suitable to augment the inter-community use of UBL with the intra-community use of extensions.

Note that the UBL Technical Committee does not standardize process models ... it only documents example process models to support the choices made in the document models. Denmark, ABILITIES and (through CEN/ISSS BII) PEPPOL each define their own process models. User communities of users have existing processing models. It will be important not to have to make them change but to be able to accommodate their existing process models and semantic description requirements.

I'm concerned your paper (as well as the papers from the consultants I come across in Canada) tries to change the way people do business by dictating too much. It will take too long before people change the way they do business in order to accommodate consultants' abstract models, and the world of electronic commerce will pass them by.

I suggest it isn't helpful trying to find the ideal 10,000 meter perspective of electronic commerce and it is more helpful starting to help organizations implement functional electronic-based interactions with their commerce partners. Planning too much for serendipity could be seen as a waste of the customer's time. Organizations that need electronic commerce today have choices they can make on which they can build solutions that meet their needs. UBL is an illustration of that. UBL is the desktop publishing of typesetting and the HTML of hypertext, built on open standards in a transparent fashion, not beholden to any vendor or fixed for any platform.

So, to conclude, this is a lovely paper to read, but I personally find it fails to provide a practical roadmap for those curious about electronic commerce to get up and running quickly with a system that meets their needs for their users. Organizations can worry about serendipitous exchanges after they solve their immediate needs for successful interaction between trading partners using open systems.

Yes, I recognize that the titles of your post and your paper are "a glimpse into the future of e-invoicing" and "vision of electronic invoicing in the future". So it obviously isn't in the scope of your paper to address the issues I've raised. But I think many readers will be like Friso who are looking to address real-world issues. I read your paper thinking about real-world issues. And you cited real-world projects in your response to Friso, yet you didn't cite in your paper these projects, or the issues of vendor independence, or other issues that are being met today with existing available technology. Perhaps your paper needs to carefully distinguish for the reader that the paper is conceptual and is addressing future requirements that are beyond the needs of real-world users today.

I truly hope you find these comments supportive.

. . . . . . . . . . . . . . Ken

p.s. BTW, I found your circular iconic representations of the distinctions between youinverse, middle kingdoms and safe havens to be particularly well expressed!

p.p.s. As a disclaimer, I am a co-editor of UBL 2.0 and a technical co-lead on many of the XML aspects of the specification definition, and I teach UBL and code lists and consult in the real-world implementation of the XML processes involved:

http://www.CraneSoftwrights.com/bio/gkholman.htm

... so readers of my own comments in this response should be aware of my personal bias.

p.p.p.s. I'm sad not to be able to be in Brussels next week ... I hope real-world issues are being addressed there in the conference

Real live examples based on open source and open standards

15 June 2009 | 6468 Visits | Rating: 3.3 (maximum:5)

Ken,

Just a note. You got the picture it is a vision statement aimed at getting people to think about the real issues of e-invoicing. Encourage people to express their opinions and experiences .

Real-world users experience e-invoicing as difficult and one of the goals of the paper is to give them an insight in the world behind e-invoicing.

ABILITIES is a perfect example of using Open Source software (Apache ServiceMix) and Open Standards UBL 2.0. I have dedicated an article on the ABILITIES Interoperability Bus on my weblog last year september.

Two of the most appealing projects outside of Europe are:

- NIEM (the National Information Exchange Model) from the U.S. Department of Justice and the Department of Homeland Security which builds on the demonstrated success of the Global Justice XML Data Model (GJDXM).

- Freight Information Highway from the EFM (Electronic Freight Management) initiative sponsored by the U.S. Department of Transport. An information heighway infrastructure that contains a logical data modle derived from UBL. This approach comes close to what I propagate in my vision statement. But shows that an electronic business highway is only possible with the strong support of open communities and governments.

But to answer your question give me some time to write down the practical approach for implementing ebusiness. Writing practical guides about implementing e-invociing requires understanding of all distribution models, project management methodologies, the influence of standards and models on chosing approaches, and so on. I went through all this the last 4 years and am writing a guideline for implementing e-invoicing.

Is it difficult to establish e-invoicing , no it is not , there are Open Source tools and there are Open Standards like UBL BUT you need to understand all aspects of e-invoicing and project management to get this done. 

In fact last year I guided a pilot project with the Dutch Tax Authorities which started in february 2008 and ended june 2008. The aim was to implement electronic ordering and invoicing, including time sheets based on the international standard HR-XML Sides.

In three months time we managed to implement from scratch an open source communication and integration infrastructure based on the Open Source software XAware and the international standard HR-XML . The internal common information model we have deployed is based on UBL 2.0 and extension. The platform integrates at our side with SAP and uses IDOC. So transformation takes place from HR-XML to the common information model (UBL) and thereafter to SAP IDOCS OR vice versa.

Although nobody thought it was possible we managed to accomplish all of this including the definition of the content in just two months , just in time to start and succesfully finish the pilot project. Meanwhile we are up and running for almost 9 months.

For this project I examined the different XML standards intensively last year and defined the transformation rules between HR-XML, UBL, UNCEFACT and the OAGIS INVOICE indicating also the CCTS id and the UDEF ID.

Have a look at this the article I wrote on my weblog about this. Just click the button English/Dutch in the upper rigth corner.

Nevertheless UBL only is not solving the problem of SME's when they require a visual image. Adobe XPD at current has the highest potential because it can produce a file based on whatever XSD scheme, as such provides one file containing data that can be processed and is also readable with Adobe reader, and last but not least can be digitally signed.

UBL did not fit our pilot project because it provides no standard elements for exchanging time sheets related data in the invoice BUT in general UBL the most suitable standard for ebusiness as I already pointed out in an article on my weblog in July 2008

About the roadmap for companies I am preparing a weblog posting on the topic of implementing ebusiness. It is based on the experiences of the last project I managed and projects I did in 2005 based on EDIFACT.

kind regards,

Danny Gaethofs

Pictures not clear

02 July 2009 | 5803 Visits | Rating: 3 (maximum:5)

Some pictures in the original 'glimp' are not clear enough.

Robots should not follow this link
eGovernment