February 25, 2015 | Written by: Tom Limanek
Categorized: B2B Integration
Share this post:
Last month, IBM’s Chris Hayes walked us through some of the complexities of e-Invoicing based on the country-by-country legal requirements for electronic documents. Today, I’ll cover what electronic invoices themselves have looked like, and into what they might transform.
My journey with B2B / EDI started in the United States back in the late 80s, when it was all about keeping things small and compact. The X12 standard for invoice allowed for fairly straightforward “turnaround” of purchase order data. The transactions fit into the overall X12 enveloping structure, which made it simple to identify sender and receiver and to pass the data on a value added network (VAN), and between VANs with interconnects. EDIFACT has had a similar structure, allowing for easy routing through networks, and fairly compact structure. EDI folks could “read” these but pretty much no one else could.
Our concerns back then were mainly about having the information available from a purchase order, or other originating documents, and getting it back onto the invoice, in the place that our customer required. As long as the data was available, EDI translation software was up to the task. With fairly simple, structured data, automating a three-way match was a real possibility.
By 2001, a few things were happening. XML as the format of choice for B2B documents was becoming much stronger, “Direct Connections” outside the EDI VAN infrastructure with protocols like AS2 were ready to take off, and the European Union was tackling the issues about evidence on electronic documents for Value Added Tax audits.
XML is much more “programmer friendly” than X12 or EDIFACT, but it also has meant many more groups could define their own schemas. A lot of EDI translation software initially couldn’t handle XML. Nowadays, first class B2B software, like IBM Sterling B2B Integrator, will handle both the traditional EDI standards, and the many varieties of XML without issue.
At that time, it appeared point-to-point communications, like EDIINT AS2, would completely take over VAN traffic. What we see now is that when VAN pricing dropped significantly, there became a balance between companies utilizing the very simple mail boxing schemes of the VANs and handling their own Direct Connections.
Today, issues of whether companies choose EDI standards, or a variety of XML, and whether they prefer VAN-based communications or Internet Direct Connections do not cause great concern. They all allow for very fast transfer of highly structured data.
The wrinkle that has made “e-invoicing” a particularly tricky transaction is the higher bar for integrity and authenticity that the invoice is subjected to based on the long term history of auditing of physical paper invoices. The EU Directive 115 of 2001 and subsequent Directives have clarified the legality of an “electronic only” invoice, but the country-to-country implementation of the regulations has been the challenge.
Another issue is that in the rush to “electronic invoicing” many companies have chosen PDF formats, which allow for speed in movement of the information, and imbedded signatures, but the structured data of EDI and XML formatted documents has often been lost. The automatic reconciliation in three-way matches becomes hard to execute when the emphasis is on the graphical nature of the document, rather than on the structure of the data. PDFs are simple, and virtually anyone can handle receiving and rendering them, but true automation gets lost.
So, what can be done?
Many companies offer their trading partners multiple options, transmitted PDF, structured EDI, XML, Portals from which to pull the invoices. But, with each new option comes the possibility of slightly different business rules and interpretations.
ZUGFeRD to the Rescue!
A German consortium of government and non-governmental entities has defined and is promoting the PDF / A version 3 as the format for e-invoices. The ZUGFeRD guideline defines how the PDF/ A3 standard can be used to contain both the human readable version, PLUS embedded XML, and they would both be sent each time. Sending “extra” data like this would have caused heartache back in the early days, but now transmitting documents of a megabyte or more is hardly an issue. Now, you can leave it your partner to decide how they can best handle the document.
So, what should you do?
Whether you are on the customer or supplier side of a relationship, push to trade the legal e-invoice with the greatest potential for automation, and the cleanest means of audit. It is worth the time to work with each of your partners to REALLY UNDERSTAND each other’s information and be able to process it automatically. The benefits of good automation are well documented. Tax authorities are continuing to revise their regulations, and you may be able to utilize something like ZUGFeRD that will work for all your trading partners. At IBM, we are happy to talk with you about your issues and opportunities for getting closer to your partners with e-invoicing.
Find more on IBM’s e-invocing and other B2B Integration Services here.