E-invoicing – back to basics

E-invoicing – back to basics

Posted by Richard Manson in AP Automation, e-invoicing, Electronic Invoicing 13 Feb 2014

Today we’re pleased to welcome a post from Richard Manson from CloudTrade.

E-invoicing means different things to different people.  For some it can be an enabler for supply chain finance and initiatives such as dynamic discounting. For others it provides visibility of spend and support for sourcing and rationalisation opportunities.

Complementary services and related marketing jargon have evolved hand in hand over the years but they mask the real reason why most organisations want to roll out e-invoicing:  Organisations have paper – loads of it. Most companies simply want to remove as much of it as possible from their processes to reduce operating costs and increase control and visibility.

So if the goal for most is to simply remove paper – and it’s an accepted fact that e-invoicing benefits all – why aren’t more people doing it?

Purchasing Insight logo

Unfortunately the market has been tainted by a history of (some) service providers over promising and under delivering.  You often hear providers claiming on one hand they “can move all your suppliers over to e-invoicing” but on the other, only offering solutions appropriate for the largest suppliers.

Sound familiar?  Supplier adoption rates have remained low and the paperless finance department has remained a dream.  There are three main reasons for this:

1)      E-invoicing solutions often demand that suppliers submit their invoices in XML or EDI format, which usually only the largest suppliers can do because of the changes needed to  infrastructure and the costs associated with this

2)      ‘Freemium’ portals which promised to remove these costs and thereby draw in the smaller suppliers simply don’t work for any except a micro business.  A  supplier that already uses an accounting package doesn’t want raise their invoice in one application, then do it all over again in another

3)      Suppliers also don’t want to pay for the privilege of sending their invoices to their own customer – a model many providers adopt.

For an e-invoicing solution to truly work and achieve high supplier adoption rates it needs to provide an easy way for suppliers to send their invoices – which doesn’t cause them any additional work or cost. It has to be simple to use and non-disruptive to their business:

  • Don’t ask them to change their applications or infrastructure to send XML or EDI
  • Don’t ask them to raise their invoice in their own accounting package and then do it again in a 3rd party portal
  • Don’t charge them!

If the ‘traditional’ e-invoicing models worked, we’d have a much higher adoption rate already. This in itself is sufficient evidence to point to the need for a different approach.  It’s not rocket science. The answers are staring us in the face. It’s simply a matter of getting back to basics and building on the win-win that we all know e-invoicing can deliver.

  • Roger Gregg February 14, 2014 at 12:12 am /

    Well said Richard

  • Hugh Chatfield February 15, 2014 at 5:40 pm /

    Well said…

    I think I say similar things, but perhaps in a stronger fashion.

    • Technical changes to existing customer/supplier systems should be minimal – ideally zero
    • Process changes to current workflows for both customer and supplier should be minimal – ideally zero
    • Suppliers will not pay to send invoices.  Cost should be minimal – ideally zero

    See the following blog item in ITBusiness for a more detailed discussion.
    http://www.itbusiness.ca/blog/universal-business-language-implications-benefits-for-smes/44589

    My company is a founding member of the gUBL.com business ecosystem to promote the use of UBL in North America.

    It may not be obvious why a standard such as the Universal Business Language (UBL) can achieve any advancements in this e-invoicing problem domain.

    UBL is designed:

    “to provide a universally understood and recognized syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees.”

    The Organization for the Advancement of Structured Information Standards (OASIS) had the following as an objective for UBL:

    “UBL is designed to plug directly into existing business, legal, auditing and record management practices, eliminating the re-keying of data in existing fax- and paper- based supply chins and providing an entry point into electronic commerce for small and medium-sized businesses.”

    It is important to understand that UBL deals ONLY with the business documents exchanged between organizations in a customer/supplier arrangement – not on how any organization handles these documents internally, or what applications they use to do so.

    As you correctly point out, no organization needs any further complexity or costs associated with sending and receiving invoices.

    For a large customer receiving invoices, if they receive their invoices in standard UBL, they need a single conversion from UBL to their internal proprietary format. This conversion can be handled by off the shelf XSL tools, and once in the proprietary format, everything works as before.

    Now for those who use large application suites (such a SAP), although you could easily build your own UBL to proprietary conversion, I believe you will see this functionality emerge from the vendor, or third parties add-ons. The pressure for this, especially in our global environment, is that much of the world has already converted to UBL as the means for document exchange, and software vendors don’t want to “miss the boat”

    The key problem though is “onboarding” all their suppliers – getting them all to send their invoices as UBL instances. No supplier wants to add any expense, and as you point out especially doesn’t want to have different solutions for every customer. Again the solution that I think will emerge is software vendors that supply SME solutions (i.e. Intuit, Sage, etc.) will simply provide a back end interface. You work as normal – but what gets sent out is a UBL invoice.

    But here we hit a key problem – send it how? By what means- using what infrastructure can we exchange these business documents. Somebody has to build a digital infrastructure to do exactly this. Denmark built an infrastructure called NemHandel (Easy Trade) that supports both B2G and B2B document exchanges. The EU built PEPPOL that does the same, but handles trans-country transactions.

    Companies such as Tradeshift have developed an off the shelf infrastructure. Yes they are based on a “Freemium model”, but they support very large implementations, not just micro businesses.

    Software vendors such as Intuit, are building backend interfaces to the Tradeshift infrastructure to send invoices world wide. Intuit works exactly as before, but they add a conversion from internal proprietary format to UBL, and send it out via the Tradeshift infrastructure. This is basically transparent to the Intuit users.

    Wait – what happens when we have dozens of such infrastructures (probably implemented differently) – aren’t we back into the same problems. No – because as long as their traffic is all UBL based, and they provide portals between infrastructures (and this software is now provided as OPEN source software), the boundaries are transparent.

    For example, since Canada is signing a free trade agreement with the EU, how can a tiny company such as myself invoice a EU country that specifies invoicing MUST be electronic and UBL based. I detail an almost zero cost solution here: http://www.itbusiness.ca/blog/why-the-canada-eu-trade-agreement-means-its-time-to-implement-e-invoicing/44519

    North America is indeed seriously behind the rest of the world in this arena, although Canada is showing serious indications it wants to move on this quickly, with an RFP expected out in early 2014. I still have hopes for our future.

    My collection of UBL articles can be found at http://www.itbusiness.ca/author/hchatfield

  • Richard Manson February 21, 2014 at 12:11 pm /

    Hugh – I feel there are some contradicting statements in your post. Although it appears we agree that “technical changes to existing customer/supplier systems should be minimal – ideally zero” , you then promote UBL as the saviour of B2B trading. At this point in time, I simply have to disagree. The Nirvana we all want to get to is one where one organisation can communicate with another seamlessly, without really having to think about it: everything is out of the box and there are no technical or infrastructure changes needed.

    Until the time where UBL – or any other standard file format for that matter – is a default output / input structure for all ERPs / Accounting packages (it is far from this at the moment), then there will be a need for sending organisations to spend considerable time and effort developing or deploying software to generate UBL files (from our own experience of cross border UBL mapping in Scandinavia, we also now appreciate the country / schema specific varieties!)

    I am not anti UBL or standardisation as a whole. Far from it. What I do feel strongly about – which is based on years of experience on-boarding suppliers – is the only way you can guarantee high supplier for an e-invoicing programme, is to make it as easy for the supplier to join the party as possible (and free!). Asking a supplier to send UBL definitely does NOT fall into the ‘easy to use’ box. For the record, we as a firm do process UBL transactions – and dozens of other formats. Ironically in Denmark – where UBL is probably more widely used than any other country – we act as the interface between numerous organisations and NemHandel. Supporting those suppliers who can’t generate UBL… but can generate a PDF (which definitely falls into the ‘easy to use and out-of-the-box’ category of invoice submission methods).

    As an organisation we accept whatever type of invoice data file the supplier can generate – we don’t mandate X or Y file structure. As soon as you do, barriers to adoption are erected and adoption rates are significantly reduced. Typically greater than 90% of suppliers that we are asked to on-board by our customers simply want to send a PDF invoice. As you are aware, almost every accounting package can generate a PDF invoice ‘out of the box’. If you look at the reports from the likes of accounts payable news, PDF invoicing is ubiquitous and second only to paper (for now ). We act on the data passed in machine generated PDFs and map to an e-invoice structure…. Although the PDF carries the data, our service is a akin to mapping one flavour of XML (or UBL!) to another.

    The other great thing about PDF invoicing is speed of adoption: we support EDI, UBL and other direct feeds. Every time a supplier wants to go down that route, you have to write off 2 – 3 months before they go live as there are so many discussions and activities that have to happen in the suppliers organisation to make it happen. PDF invoicing can be activated by the billing clerk that raises the invoice. We’ve had many instances where a supplier has been asked in the morning to move to PDF invoicing and by the afternoon and their very next invoice they are live.

    Hugh – just to repeat myself, I’m not anti UBL. It may well be the way organisations trade in 5 or 10 years from now. However, if an organisation wants high supplier adoption TODAY, asking suppliers to send UBL is not the way forward.

Post a comment