the best compromise between suppliers and buyers for a fast adoption of e-invoicing Build some intermediate floors and stairs in the e-invoicing House in order to create a path to the roof and enjoy the view 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 if we have built a magnificent 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: an image of the invoice as suppliers are used to produce in paper and as buyers are used to process, and a few datas to manage the electronic invoice and bring a first level of benefits for the customers. 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. Cyrille Sautereau Cyrille.Sautereau@admarel.com February 2013 Page 1 / 5
Electronic invoicing through a full structured dataset excludes nearly 90% of companies 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: Concentrated suppliers: 10 to 20% of suppliers that send more than 50 to 100 invoices per year for this buyer, which represents about 30 to 60% of invoice received by the buyer. Decentralized suppliers: 80 to 90% of the suppliers who are naturally not eligible for the implementation of point to point relationship in a full structured format (except if they can re-use exactly the same format for another customer, which is rare, or if they accept to fulfill manually their invoices in a buyer portal). If we extend this approach to all companies in France that are broken down as follows (in order of size): Large companies (over 5000 people): 200, representing 36% of total turnover of companies, ETI (Intermediate Size Companies from 250 to 5000 people): 4 500, representing 27% of companies, SMEs (10 249 people): 150 000, representing 21% of total turnover of companies, Micro companies (1-9 people): 1 000 000, representing 16% of total turnover of companies, Cyrille.Sautereau@admarel.com February 2013 Page 2 / 5
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. In order to deploy some decentralized invoice flows, the market needs an e-invoicing mode and format which must be TOTALLY independent from each business relationship. 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). Cyrille.Sautereau@admarel.com February 2013 Page 3 / 5
So, today, invoices are essentially: Either in paper form: in the best case, they are processed through an industrial scanning chain that produces an image and 10 to 15 invoice s fields reliable with a few % of error margin, Either in structured file form (EDI): for which the richness of information is not necessarily fully used as datas for process automation (but more on the settlement and validation process when it can be implemented for automation). 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: identification of the sender and the receiver: VAT identification number, SIREN / SIRET GLN, maybe addresses... Invoice number, date and type (invoice / credit note, ) References: purchase order number, contract number, period of service, dispatch / receipt notice number, buyer's reference necessary to settle the validation cycle (business unit, ), Total amounts as VAT (with details per VAT rate : bases, amounts), gross amounts, net amounts, deposit, Due Date, If needed, footer allowances (shipment costs,...), If needed, payment references (IBAN, ), 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. Cyrille.Sautereau@admarel.com February 2013 Page 4 / 5
From an enhanced / indexed PDF to a full structured e-invoice: a model in 3 stages to build a progressive path towards a greater 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 this chart: 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: Level 1: full "fiscal" standard invoice: the light dataset is enriched with standard lines datas (basically the fiscal mandatory fields), which enables suppliers who are able to manage those information as datas in their information system, to include them in this level 1 dataset for their customers. This meets exactly what has been done in the MUG project (Core Industry Invoice, to be extended to credit notes). Level 2: full structured invoice: the next step is an extension of the subsets by business / industry in order to complete a full structured file agreed in a point to point relationship or within a community, dedicated to concentrated streams of invoices that justify greater integration between a customer and its supplier. 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. Cyrille.Sautereau@admarel.com February 2013 Page 5 / 5