Introduction

As an independent consultant I operate from my own one-man company. That means I am participating in the world of invoicing. In the last couple of years I have seen a steady rise in electronic invoices. Before electronic invoices I received all my invoices in my letter box and believe me, compared to electronic invoices, that was easy and cheap. In short, I don’t like electronic invoices.

The most important downside is that they don’t arrive in my letter box. Most providers of electronic invoices offer me a portal where I can login and download the invoice. Of course, every single one of these portals has its own registration system, its own credentials and its own password polices. Needless to say, it’s very cumbersome to fetch invoices. Most of the time I end up ‘logging in’ through the ‘password forgotten’ use case. I don’t even bother to change the generated password since next time I’ll be logging in through the ‘password forgotten’ use case anyway.

After taking the first hurdle, logging in to the website, I am greeted by the second one: user interface and functionality. Some look nice, some look like a website that would have been great in 1994 but not so anymore in 2013. Tastes differ so I’ll assume it’s me. But in terms of functionality, some of these portals seem to make it a sport to provide the worst possible user experience in finding and downloading invoices.

They also differ greatly in what kind of functionality they offer. There are portals that offer me an online archive (although there is no mention whatsoever about any long term guarantees of the archive existence). Others encourage me to download the invoice as soon as possible since they only offer access for a limited amount of time. Hint: since not all of them offer archive functionality and since I can’t afford to have an archive of invoices scattered all over the internet (with varying service level agreements), I can’t make use of those archives anyway. Whatever functionality they offer, in my world they are just temporary inboxes: I download the invoices and archive them locally as soon as I can after which I forget about the copy on the portal.

All sources of electronic invoices notify me through email when a new invoice is available through the portal. One source even is so kind as to include a direct download link in the email. Convenient as it may seem (and it really is) it’s also a security risk: the direct download link does not require any form of authentication. It acts like a ‘bearer token’ with a long life span, a token that is transmitted in clear text as part of the email and can be intercepted.

Current Architecture

All this is the consequence of one-sided view on the problem by publishers of electronic invoices. If you look at the challenge of issuing invoices from the point of view of a company, the architecture below is an obvious solution. Invoices are generated internally in a digital format, they are distributed using a portal and the company can even track which invoices have been accessed and which haven’t.

If you take the point of view of a customer and assume the same architecture as above, the picture looks different and a lot less shiny. We see that a customer is faced with dozens of point-to-point access paths to invoices, all of which are implemented differently and act differently.

Better Architecture?

As an architect I feel this can be done better, a lot better in fact. In my proposal for an architecture, there are four roles involved in getting electronic invoices from a publisher to a customer: (1) Customer, (2) Collector, (3) Distributor and (4) Publisher.

The primary function of a Collector is to collect all invoices for specific consumers and make them available to those consumers. The role of the Distributor is to collect invoices from publishers and route them to the correct Collector so they end up at the correct consumer. The main goal of the Collector and Distributor is to cater for their respective customers: Customers and Publishers. That is a significant difference from the current architecture: both stakeholders (Consumers and Publishers) have a party who will act in their best interest as catering them is their reason for existence. In the current architecture no party exists which will do their best to cater the Customer. Of course, Publishers may say they do when they offer their portals but reality is that it’s not their primary reason for existence and the above mentioned problems prove that they only go so far in providing services for the customer.

In my specific case, I could opt for a Collector service that prints and mails the invoices to me while at the same time keeping an electronic archive for me.

In Belgium you have a few services that seem to be offering services related to the Collector role: ZoomIt and Unified Post. If you look at their websites and service offerings it becomes obvious their primary focus is on the publisher of invoices and not the customer.