More than 15 years of development of B2B electronic invoicing services, with one hundred projects of large companies and thousands of counterparties connected, have built a conviction: the apparent slowness of e-invoicing market development is mainly due to the high level of integration that we intend to reach directly by focusing on full structured e-invoice exchanges.
It is like we have built a magnificient e-invoicing house and get some early adopters on the roof where they can enjoy the view and ask to the people in the street to climb up. However, as everyone can not be a mountaineer, we need to work on building floors and stairs (and maybe elevators) to make them join us. First, we have to start with a ground floor, just to make all companies enter in the e-invoicing house. Some of them will stay there. Some will try to rise to the first floor before reaching the roof.
Indeed, full structured e-invoices remain EDI processes, even when they are mutualized through service providers, with the virtues of integration and ultimate automation that we know. But we also know that EDI finds its return on investment for regular and concentrated exchanges (more than 50 to 100 invoices per year between a supplier and a buyer), with an important counterparties deployment issue among community users (suppliers or customers), and a point to point business model in terms of setup costs at least.
This structural border limits the potential e-invoicing users to less than 10% of companies (excluding almost all SMEs) for about 20% of invoices in electronic full structured form (as most of counterparties have no economic incentive to switch).
This also explains in part the significant investments made by e-invoicing service providers in the deployment phase of their customer network (as, in addition to set up or testing costs, there are also sales management and administration costs to handle), as well as interoperability issues, network access issues and associated roaming business model.
Then, in order to switch to electronic the 80% of invoices that are not within this EDI scope, we need something else, simpler, more universal, less personalized, and close to the paper in order to facilitate a fast adoption:
This is the zero-level of e-invoicing, the ground floor for all companies, especially SMEs. It is not too late to move on, to finish the first floor, and to PROMOTE the whole thing.
The deployment of electronic invoicing is first guided by the benefits it provides. Mainly, it means for the buyers optimizing and automating the accounting integration process in one hand, and the validation process in a second hand. As a consequence, suppliers are welcome to produce invoices that facilitate the process automation for the buyers, in order to reduce disputes and lead to a faster and more certain payment.
This explains why the development of electronic invoicing has been first developed through an exchange of full structured data files, sometimes with a PDF attached for legibility, which can be digitally signed in order to meet the fiscal regulation constraints. In reality, the French market is more focused on the EDI mode (ex 289bis and new 289 VII-3 of CGI) to ensure the authenticity of the origin, the integrity of the content and the legibility of an full structured electronic invoice.
Since companies exchange invoices, which means share invoices information, and integrate invoice’s data, interoperability between sender’s and receiver’s structured formats, including business rules, is the key point of success. Obviously, the solution is to define a standard invoice format. For almost the last 30 years, many working groups have worked (and still do) on this standardization process, especially through EDIFACT and, more recently, through XML formats (CII of UN / CEFACT and UBL OASIS or ISO20022).
However, invoice information are numerous and dependent of each type of business or sectors (sellers or buyers). As a result, the standardization workgroups are defining and documenting a large and complete library of business objects specified as datas, from where users can create “derivative” formats, called subsets. In practice, they are different formats based on a common syntax.
As it is a matter of integration and interoperability, these subsets, even from a common standard syntax, must be shared between each couple sender-receiver.
As a result, each pair of parties who exchange e-invoices in a full structured format has to agree on the message format and the business rules (on the basis of a detailed documentation of more than 50 pages generally). Then, they have to implement the same format and finally to test it from end to end. Even within a community where we can imagine that the format and the business rules of implementation are common, the richness of required datas, which implies in particular that suppliers are able to manage them in their information system in every particular cases, imposes a testing phase from end to end which involves at least some half-days of work on both sides.
Thus, for each relationship between a supplier and a buyer, there is a set up cost for a full structured invoice format exchange, which is somewhere between 500 to a few thousand euros. On the basis of 5 to 10 euros per invoice of processing costs' reduction, a return on investment is reachable within one year only for a relationship that counts more than 50 to 100 invoices per year.
This threshold is cleaving. In fact, it excludes the vast majority of companies, particularly SMEs. Indeed, as shown in the diagram below (in broad terms), we can postulate reasonably, as observed in many buyers, that for a standard buyer, the limit from 50 to 100 invoices per year, splits its suppliers in 2 groups:
If we extend this approach to all companies in France that are broken down as follows (in order of size):
we see that all “micro-companies” and more than 90% of SMEs have no economic incentive and return on investment in order to switch to electronic invoicing on a full structured format. As a consequence, it significantly reduces the potential deployment for large and intermediate Companies, which are their business relationships.
Thus, the overall picture is that e-invoicing in full structured formats excludes about 90% of companies and focuses only a target of less than 20% of invoices. It is then not a surprise that e-invoicing penetration is less than 8% in France.
This simple segmentation between concentrated and decentralized invoice flows explains why e-invoicing is experienced as a restricted perimeter project in most companies, especially SMEs, only necessary in order to build customers loyalty or to integrate their "strategic" suppliers.
As a result, the threshold of usage for electronic invoicing is too low to enable a switch from paper processes and practices. Furthermore, in the vast majority of SMEs, it does not allow to even consider the implementation of electronic invoicing for inbound invoices.
The complexity and richness of the information required in a full structured e-invoice imposes a bilateral relationship. Then, we must reduce the richness and complexity in order to reach a compromise between what suppliers can easily produce as an e-invoice and what buyers really need for a first level of integration and automation.
If we look at how buyers are dealing with different forms of invoices (paper, pdf, pdf + indexing datas or full structured file), we note that in practice, a first level of integration or validation can be done with 10 to 15 datas from invoice’s header and footer, like what is processed in a scanning chain.
It can be observed that the accounting integration phase is done generally on the basis of only a few datas. Thus, line’s details are mainly used for matching on validation process or for analytical purposes, as long as the business and matching rules have been implemented by the buyer (and as receptions are properly carried out by the buyer’s employees).
So, today, invoices are essentially:
Thus, with an invoice image and 10 to 15 of header / footer fields, the buyer can automate the integration of its invoices and organize a settlement and validation process in a workflow.
For a supplier, it is easy to produce an image of the paper invoice that it usually prints (and therefore that its client is used to process on an image base). Most invoicing softwares (ERP, CRM, …) manage header and footer invoices’ information that are necessary for their accounting and for monitoring their payments. On the contrary, the management of specific invoice's information as datas streams (lines and/or business / sectorial information), which need to be shared with its customers through a structured file, implies to implement shared data models, and to have reached a significant step of maturity of the information system.
Therefore, the supplier can easily produce a PDF invoice and a set of few data as:
This is a compromise that may be the Greatest Common Denominator between buyers and suppliers for a zero level of the electronic invoice, able to replace rapidly paper invoices.
This kind of “mixted” format for an invoice has in fact the same attributes than paper invoices (same readable image), but in an electronic form that allows its circulation through a workflow and some reliable information that the buyer does not have to "enter" in order to automate its integration.
The achievable aims of an enhanced / indexed PDF format for e-invoices is to replace paper invoices rapidly. For doing it, it is necessary to standardize the information that can be embedded in a “light” set of data, with a very few mandatory fields (only necessary for on line access to archives).
Once this “light” set of data defined, it would be reasonable to use the ongoing standardization works in order to encode those datas in some standard syntaxes, starting with CII (UN / CEFACT in the MUG for example), or UBL (within BII workgroups). It is also possible to encode them into an EDIFACT syntax, knowing that the simplification of the dataset makes possible a bijective (one to one) correspondence between these different syntaxes (on which libraries of transformation tools can be developed for the benefits of everyone).
The minimum “light” dataset structure for a zero-level of electronic invoice could be as proposed in the chart below:
Such a model can be implemented rapidly on the sender side as an archiving format for electronic copies of paper invoices sent. This will make it easier to switch from paper to electronic invoices.
The choice of encoding this “light” dataset in standard syntaxes allows an extension of the model in two additional stages:
In order to simplify the set up phase, it may be preferable to provide a full structured format as it is currently in place, as an attached file to a zero-level “light” dataset / PDF invoice.
Pour toute question ou prise de rendez-vous, vous pouvez utiliser notre formulaire de contact.