E-billing 

E-billing is the sending and receiving of invoices in the form of a data file (the e-invoice), between the supplier's ERP, accounting or order to cash system and the customer's ERP, accounting or purchase to pay system. Without manual intervention.

Not looking for general information about e-billing? Read about our e-billing solution.

Automation

Accounts payable and accounts receivable are in the midst of a digital transformation. This transformation has mainly taken shape in sending invoices in PDF form by e-mail. The automation aspect therefore lags behind because it is employees who create, read, review, send or enter the PDF invoice. OCR is usually applied to speed up the input process.

In recent years, transformation has been pushed more. On the one hand by labor market and HR savings and on the other by the government. The government itself wants to be able to work more efficiently and also get a better grip on tax collection.

HR and cost savings

Both accounts payable and accounts receivable are greatly helped by a digital transformation of invoice receiving and invoice delivery, respectively. By automatically converting invoices to a digital standard, invoices can be processed much faster. Accounts payable can circulate invoices for approval (or have them automatically approved based on POs). Accounts receivable can get invoices to customers faster.

For accounts payable, manually receiving, entering and checking several invoices, a fraction of which require corrective action, can add up to considerable processing costs. General costs for the total processing, i.e. including coding and approval, for a PDF invoices can amount to an average of 35 euros per invoice and with an associated 15 days of processing time. For e-billing / XML invoices, this amount can be reduced to a few Euros. For EDI, the amount is under Euro.

Multiply this number by the invoice volume and the cost picture takes shape. And it's not just cost savings that are realized with e-billing . The much faster turnaround time provides cash flow benefits for accounts payable as well as accounts receivable. For accounts receivable, this is obvious. Accounts payable could negotiate discounts for early payment.

Tax collection

Government as client

Within Europe, there are agreements on e-billing. Those agreements are laid down in the European directive on electronic invoicing in public procurement (Directive 2014/55/EU of the European Parliament and of the Council.

The Dutch government has incorporated the European directive into the Procurement Act. Since April 18, 2019, all Dutch governments, government organizations and other contracting authorities are required to be able to receiving and process e-invoices from their suppliers. Since that date, companies doing business with the Dutch government are required to submit electronic invoices according to the European standard for electronic billing (EN 16931).

Government as tax collector

The government's role in the adoption of e-billing is going to get much bigger. The current VAT gap, or the difference what the Dutch Government should receiving and actually collects, is 2.8%. While that is well below the European average of 9.1%, it is billions of Euros being lost.

In countries, mainly outside Europe, national governments are moving from a post-audit model to continuous transaction controls models. Implementation differs, but have in common that every invoice sent between parties is also registered with the government. Such an operation is only possible with e-billing.

E-billing

The e-invoice

E-billing is a digital and standardized process of invoice receiving and invoice delivery. In e-billing , invoices are sent and received in a data file, between the supplier's ERP, accounting or order to cash system and the customer's ERP or purchase to pay system. Without any manual intervention. We call the data file e-invoice.

The challenge here is the pluriformity of systems and data files. And the fact that a lot of parties send invoices as PDF files via e-mail. And there are differences in that too. 

XML invoice

An e-invoice almost always takes the form of an XML file. XML (eXtensible Markup Language) is a data file that contains instructions on how to code or interpret information in the file. These instructions are readable by applications like humans. By now, XML has become the standard for data exchange between applications.

But XML is not the same as an invoice standard. A comparison with speech creates clarification.

The ability to speak and thus transmit information from person to person can be performed by different speech sounds. With this speech ability, different groups of people, speak different languages. So they use different speech sounds, to communicate basically the same thing.

Similarly, there are differences in the instructions used in XML files. These are the different standards used between different regions and/or industries, such as. UBL standards, Peppol, and UN/CEFACT.

A piece of XML for the UBL 2.1 standard looks like this:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"

       xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">

   <ID>INV456</ID>

   <IssueDate>2023-11-30</IssueDate>

   <!-- Other invoice elements using common components -->

</Invoice>

 

For PEPPOL

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"

         xmlns:peppol="urn:www.cenbii.eu:transaction:biitrns010:ver3.0">

   <ID>PEP789</ID>

   <IssueDate>2023-11-30</IssueDate>

<!-- Additional PEPPOL-specific elements or extensions -->

   <peppol:AdditionalInformation>PEPPOL-specific data</peppol:AdditionalInformation>

</Invoice>

 

For UN/CEFACT

<CrossIndustryInvoice xmlns="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:1">

   <ID>CII_INV_001</ID>

   <IssueDate>2023-11-30</IssueDate>

   <!-- Other CII-specific invoice elements -->

   <PaymentMeans>

       <PaymentChannelCode>CC</PaymentChannelCode>

       <!-- Additional payment means details -->

   </PaymentMeans>

</CrossIndustryInvoice>

And so there are many more standards. Some of the standards have similarities, but some do not.

XML is such a versatile format that it is not the exclusive domain for invoices. XML is used in numerous domains; from computational data to GPS information and from vector graphics to billing information.

Paper, PDF, EDI invoices

Many vendors send invoices not as XML files, but in the form of a PDF file. PDF is a digital image. Sometimes with data layer, sometimes without data layer. In many countries, paper invoices are popular. And in some industries, EDI is used.

EDI is much like e-billing. EDI is admittedly broader in that it includes POs and packing slips in addition to invoices. EDI invoices are sent directly from the supplier's system to the customer's system. EDI invoices, like XML invoices, are standardized with the goal of a faster and error-free process.

Let us quote the metaphor of speech again. Language is not only spoken but also written or acted out. The ability is the same. So is the meaning. Only the form is different.

EDI is not XML. An example of a piece of EDI:

ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *030101*1253*U*00501*000000123*0*T*:~
GS*IN*SENDERID*RECEIVERID*20030315*125300*1*X*005010~
ST*810*0001~
BIG*20111207*12345678*20111206*87654321~
N1*ST*ABCCorporation~
N3*123Main St~
N4*Anytown*CA*98765~
N1*BT*XYZRetailers~
N3*456Oak St~

And again, EDI has different standards, such as ANSI X12, EDIFACT, TRADACOMS and ODETTE. In short, there is a jumble of documents and files by which billing information is communicated.

Standardization

E-billing refers to the exchange of invoices in "electronic" form. In practice, this refers to receiving and sending XML invoices.

The variety of forms and standards prevents parties from embracing e-billing . Or they only include an XML file as an attachment in an e-mail, simply because the accounting package offers this option. But the accounts payable department then retrieves the PDF and with OCR software they convert the PDF image to a data file that is presented to the purchase to pay system.

As long as the receiving system cannot directly receiving and process the e-invoice, e-billing does not really exist. Not in terms of cost savings and not in terms of government.

A single standard for invoices would help. The challenge lies in speaking a single language. Then invoices can be sent directly from one system to another and receiving. Without manual intervention. And also the use of a single communication protocol. An XML file can be sent by e-mail or, for example, using FTP or API.

This seems obvious. Just as well, communication would become easy if the whole world spoke "Algemeen Beschaafd Nederlands (ABN). Moving to a uniform standard also means that people have to give up their existing ways of working, adapt, make concessions and invest in something new.

The move to EDI, for example, is no easy task. Not only for one's own organization, but also because it requires the cooperation of suppliers and customers. And each party in turn cooperates with many others, working with their own systems.

There have been several initiatives in the past, but on a smaller scale. EDI is a good example of this. PEPPOL is another example. Originally set up by the Norwegian Ministry of Finance and the Norwegian IT and Telecommunications Agency, but now embraced in several European countries.

Because a global standard is a long way off, received invoices will have to be received and sent manually or semi-manually for the time being.

Óor outsourced to a service provider that automatically converts invoices, and other types of documents, in real time to a format requested by the receiving party. This is the core business of 4Exchange.

Digital transformation

Processing XML files is the linchpin in the digital transformation of accounts payable and accounts receivable. After all, to enable process automation, information must be available in data form.

Data quality

An XML file alone is not enough. The information in the file may be incorrect or different from the data in the ERP system. Or information may be missing. Then a file is processed in the organization or sent to a customer, days pass, only to be noticed as incorrect and correction must be made.

To reduce turnaround time, key checks can be performed immediately after an invoice is available in the desired XML form. A comparison with data in ERP or other systems in use is an excellent start to validate data and keep consistency high. Depending on the outcome, automated steps can be taken based on definable IF-DEN rules. Even before the invoice is forwarded to an invoice processing / purchase to pay system, or sent to a customer.

Process Automation

A unified data flow offers opportunities to transform the purchase to pay and order to cash process into a much faster processing and much more transparent system. If the front end is well organized, it all becomes a lot easier at the back end. Examples:

Order matching
As easily as a standardized XML invoice can be compared with data from an ERP system, so easily can this invoice be compared with data from the corresponding Purchase Order. Provided, of course, that a PO exists. And the basic data in this PO is validated. The PO is can then be placed next to that of the invoice, and the contents compared. For example, do the items and amounts match? If not, what tolerances are we willing to accept. After all, correcting data also costs time and money. And this process of matching occurs automatically, of course. The technology that makes this possible has been available for years.

Discount on early payment
The best boy in the class may be rewarded for his good behavior. We still see little of this in practice. But the hands freed up by digital transformation can be used, for example, to make agreements with preferred suppliers and monitor the agreements.

Compliance

E-invoices, of course, are also very easy to mold into compliance. Not only content, but also the edits made to the invoice, from receipt to delivery of a document, are logged. This ensures the integrity of every receiving or invoice to be sent.

From tax collection, form is becoming increasingly important. We already see this very clearly in Latin American countries, for example, but also in Europe it is getting closer for the Netherlands. Italy is already there and Poland and France are the next countries, where every invoice exchanged between companies must be registered.

Standardization is also a challenge here. Not only regarding the desired format, but also the process and exchange protocol. In the French model, the invoice is sent directly from supplier to customer, but both parties will have to register the transaction with an accredited service provider.

In short, e-billing opens the way to real-time, touchless and compliant invoice processing, reducing the cost per invoice from tens of Euros to one Euro.