eBilling - E-invoicing : Lost in translation

Honestly I still don't really see the difference, after all E-invoicing is just like ebilling the replacement of paper with electronic documents for saying in a regulated way: "you owe me X dollars". Or is the just the mapping that is different because the so bills need a clientfriendly lay-out and e-invoices may need a little more coding to automate the supply chain of buyer and seller even more?

I mean... the purpose of a bill and an invoice are the same I suppose (unless my English is failing on me too), why then would one try to make 2 standards for it?

First of all, I fully agree that we need to get the terminology right so we talk about the same things. 
However I also have an isse with separating B2B from B2C, the main reason for this is that a company does not always know if they are invoicing a B, C or even a G. 
If I am sending an invoice to a 1 person business, is that a B or a C?, it might be a Business but he/she might act like a Consumer, e.g. by directly making the payment online. 
Its a 2 sided market of senders and receivers, so overall we should not try to force eInvoicing into 1 fixed model.

Tonnis de Boer

Innopay.com

@Rik - You are right that in most cases the invoice and bill contain the same information - however the processes that accompany each are different in the "e" world.

E-invoicing is an automated process - not typically in human readable or display format -in fact the objective of an end to end e-invoicing process is that there is no human intervention. Although the data may be decipherable by someone that understands XML - there is actual print version that needs to be produced. Therefore e-invoicing shouldn't be discussed in terms of B2C processes as consumers will not be automating their payments for many years (although I can see this in the distant future).

eBilling is totally focused on providing a human readable format - just electronic rather than paper based and hence this is not trying to automate the exchange the information in the document but only trying to replace the costly paper and print process.

So it is the mapping that is different - but also the intention of the process and the format of the document vs the data and the use of the document or data once received.

My point is that companies shouldn't be thinking that these are the same thing and can be achieved by a single solution. It should be fairly simple to start - are you changing the delivery method of the document or automating the delivery, receipt and input of the information within the document ?

regards

Michael - Striata.com

Micheal,

I think a company should not have to make a difference whether there is a customer or a business at the other side of the chain. As long as the output has a decent translation of the message, the same info could be given in a readable lay-out to the customer, in a coded lay-out to the business.

I think that is perfectly possible if for example banks could play a role in it, or another company that makes the translation... in that case company A sends an XML-invoice out and then there are 2 possibilities at the other side:

- a company B => they choose how to interpret the given info

a customer => gets this via an online banking platform, where the bank services his customer by translating it to a propor lay-out.  Or a simple tool generates an email with the info of the XML-invoice for example.

So to me sending out invoices/bills electronically need only 1 standard to work on.

@Rik - what you describe with a generic XML invoice format would be the nirvana of eBilling.

Banks would be a good place for the rendering and the presentation as they would wish to facilitate the payments. This is a growing feature of Internet Banking in the US.

The issue is that billers won't ever relinquish their control of the final format of the bill - they use the bill for more than just conveying a total owed, there is marketing customer service and feedback elements built in. Billing and payment are still separate (see point 5 on this newsletter).

Therefore the invoice or bill, as we know it, is here to stay for B2C customers. 

For B2B customers - who don't care about the additional messaging and just want the financial information - the XML would be perfect -and this is what e-invoicing is trying to bring about.

Hence I believe that the goals and objectives are different for ebilling and e-invoicing and that they will require different solutions - even for those businesses that have with SME customers and may have to do both.

Michael Wright - Striata.com

@Tonnis – while we shouldn’t force one model as you say, the distinction between the terminology will allow us to start to define the different models with more accuracy.

E-invoicing will generally not have a B2C component as consumers are unlikely to have the automated processes that will drive the efficiencies of an e-invoicing system.

eBilling may have B2B components as pointed out – but if these are SME type businesses then they can probably be treated as B2C and will benefit from the electronic delivery rather than the automation.

My argument is that when companies are approaching electronic billing,  they will generally only be interested in either automation or electronic document delivery – both will provide cost savings but the projects, collaboration and solutions are vastly different.

Michael Wright - Striata.com