Use cases

Invoices

The ZUGFeRD invoicing standard uses a combination of PDF/A-3 with an XML file that follows the Cross-Industry Invoice (CII) standard, which can be a great solution for automating the payment process of invoices. Unfortunately, the ZUGFeRD standard doesn't provide a solution to avoid fraud. Just like a paper invoice, any digital invoice can be intercepted and altered. Some criminal organizations specialize in changing the wiring information on invoices, so that people receiving an invoice pay the invoiced amount to the wrong party. Digital signatures on invoices can protect customers or companies against this type of fraud, but adoption of digital signature technology in the context of invoices is slow because the technology turned out to be too complex.

It would be great if standard PDF viewer would have a button, so that when someone opens a PDF and clicks that button, some information about that invoice is shared, e.g. if the invoice was altered, and who issued the invoice when. That information could be retrieved from the blockchain, and the identity of the vendor could be checked in a web of trust, including for instance whether or not the vendor has fulfilled his tax obligations. See also an article published in De Tijd, a Belgian financial newspaper.

Another real-world use case consist of a bank that grants a loan for buying a car. In this case, the bank requests an invoice. More often than not, a paper invoice is used in this context, and that invoice can be forged to get a higher loan. Wouldn't it make more sense if someone applying for a loan just gave the bank the unique ID of the invoice, after which the bank can look up a URL of that invoice in the blockchain, so that the original invoice can be downloaded from a secure location?

Registering invoices in the blockchain also has added benefits for governments, in the sense that they can scan the blockchain for invoices for tax purposes. If customers only pay invoices that are registered in the blockchain, companies will no longer be able to "forget" to declare some invoices. It will also be impossible to create fake invoices in the hope to get a VAT reduction or to artificially lower the profits of the company. The fact that a hash of each invoice is stored in the blockchain, the government will also be able to sample batches of invoices to check whether or not the documents were tampered with.

Supply chain

Invoices are merely a first step, we could use the principle for every document in the supply chain. A document that starts off as a quote request can spawn different quotes being issued by different vendors. After examining the different quotes, one quote could be chosen and result in a quote request. That quote request can then fork into an invoice and a delivery note. A bank that processes the invoice can mark the invoice as paid.

A simplified example of this process is shown in figure 1.

Figure 1: Document Workflow

The different nodes in these figures represent CRM and ERP systems at different companies. Each time an invoice leaves the CRM at the vendor, that invoice could be registered automatically in the blockchain. When this invoice is received in the ERP system on the buyer's side, it can be validated in the blockchain before it is sent to the bank to process the payment. Once the bank marks an invoice as paid, the CRM of the vendor will notice this immediately when the block containing a record created by the bank reaches the CRM's blockchain client.

It's easy to imagine how this system can be used to automate all kinds of workflows.

Port of Antwerp

The port of Antwerp, largest port of Belgium and second largest port of Europe in terms of container capacity, is experimenting with blockchain technology for the automation of logistics. This way, the port aims to speed up the many interactions between clients and stakeholders. They also aim to reduce the cost: not only the cost of the enormous paper trail, but also price fluctuations not being communicated clearly, a dollar to euro conversion not having been fixed, or a bill of lading mismatch.

Transporting even a single container includes a minimum of 30 different parties, going from the truck drivers that delivered the goods that went into the container, to the people loading the container, the people taking the goods out of the container, as well as the harbormaster. Communication between all these parties occurs over a wide variety of platforms and media: the most common ones are e-mail, fax, and phone. It's no surprise that information is leaked, gets lost, or is distorted along the way.

Security is the largest issue. In order to ensure containers can only be moved and opened by the correct people, they are often locked with a code. The code has to pass through all the communication-channels mentioned above. Most of these are insecure, and containers often go missing, their content stolen. And because the container isn't continuously tracked, nobody can be blamed for its disappearance.

This is where blockchain provides the perfect fit. A single source of truth, e.g. the bill of lading, can be passed and signed (as a token) between all parties. This offers stakeholders a way of tracking the container in real time. It also enables stakeholders to see where the container went missing, and under whose responsibility.

Avoid Link rot

Suppose that you have a huge repository of documents that you want to share publicly. To do this, you use third party Cloud storage from vendors such as Akamai, Box, Dropbox, Amazon, Google,... However, due to the nature of your business, these documents can move around from one place to another. Either after an upgrade to a different Content Management System (CMS), or because you want to switch from one vendor to another. Your repository is very much alive, and this results in your customers getting a "404 - File Not Found" error. This phenomenon is also known as link rot. The document is available somewhere, but the original link no longer works.

Often you see that a CMS solves this problem by creating a redirect, but when a file moves too frequently, you risk getting a Too Many Redirects error, or worse: an infinite redirect loop. All of this can be avoided by registering every document in the blockchain, and have your CMS add a new record every time the location of the document changes. Then, instead of sharing the document or the document's location, you merely have to share the document's ID. Whoever wants to consult the document, can get the location by searching the blockchain for the latest location record on the blockchain. Given the right credentials –in case the URL can't be accessed publicly–, the corresponding document can be downloaded. Since the record also contains a signed hash of the file, whoever consumes the document can also check if the file is authentic and hasn't been tampered with. This also implies that it's not mandatory to centralize all of your documents on one and the same storage system. Different cloud storage services can be used with blockchain routing document consumers to the appropriate service.

Asset management

When setting up a blockchain for documents, it will be important to make a clear distinction between the content that needs to remain secret and the information that can be public. Keep in mind that all the information that is stored in the blockchain can eventually be exposed publicly, even if it's encrypted.

Imagine that we'd use the blockchain to register certificates of real estate property, works of art, diamonds, and other valuable assets. An owner might not want the specific description of all of his assets to be displayed publicly, yet he might want to be able to prove that he is indeed the owner of an assets that corresponds with the description on a certificate. This can be achieved by having the certificate registered in the blockchain e.g. signed by the previous owner selling the asset, along with metadata about the new owner.

This also implies that given an ID of a certificate, you'll be able to go back in time and discover every previous owner of the asset. However, without access to the certificate, you'll never know the specifics about the asset, except for the information stored as extra metadata. You'll have to choose that metadata wisely. For instance, if the assets consist of real-estate, do you really want a public ledger listing the address of each property, along with a historic overview of every owner?

Last will and testament

Some documents need to be verifiable for a long period in time. For instance: if you write your last will and testament at the age of 40, you hope that no one will have to consult that document for another 40 years in the future. Unfortunately, the document will have to surface one day, and on that day, you want your heirs to give the assurance that the document they are looking at is genuine. They won't have that assurance if you created a hash of the document in the year 2000 using SHA-1.

One way to ensure the Long-Term Validation of your last will and testament could be to deposit it with a trusted third party that registers an original of your last will and testament on a public blockchain with centralized ledger control on a regular basis, always using the latest hashing algorithms.

Sensitive information

Journalists were able to write about tax evasion because they had access to a massive amount of documents. They discovered these documents in an indirect way. Instead of investigating the people and the companies mentioned in the Panama or Paradise Papers, they targeted the consultants working on behalf of the alleged tax evaders. Thanks to whistleblowers and data breaches at these consultants, they even discovered targets they previously didn't even know of.

Obviously, this isn't good news for the people and companies involved, nor for their consultants. All of this could have been avoided if only the consultants wouldn't have kept an archive consisting of documents with sensitive information. Consultants will probably argue that they needed to keep a trail of historical documents to ensure the continuity of their service. True as that may be, they could also have put the burden of archiving documents on their customers, making the consultant less vulnerable for exposing sensitive data. Consultants will argue that they can't always trust the customer to provide original, authentic, genuine documents, but that problem can easily be solved. A consultant could easily create a private blockchain with centralized ledger control to store hashes of the documents, instead of the actual documents. The moment a consultant –such as a law firm, a fiscal advisor– is no longer working on a specific case, all documents related to that case can be registered in the private blockchain, transferred to the customer, and physically removed from the consultant's own archive.

To avoid "expiration", one could think of a subscription, where the customer returns to the consultant on a regular basis –e.g. every three years– giving temporary access to the customer's private archive of documents. The consultant can then verify if that set of documents is complete, authentic, untampered with, and register the set of documents anew using the latest hashing algorithms. Once the verification and renewal of the registration is done, the consultant can once more physically delete the documents, so that, when there's a breach at the consultant –e.g. by a hacker or a thief–, that intruder can only access the documents the consultant is currently working on. He'll only find a hash of all the other, historical documents. If an intruder wants access to all the documents, he has to break into the system of every single customer.

This use case is also important in the context of GDPR. GDPR is a European regulation that –among others– gives European Citizens the right to have their personal data removed from the systems of a company in specific situations. In the case such a company only stores a hash of the personal data, and not the actual data, there is no personal data to remove.

There's more

These are only a handful of examples. Once you start looking at existing document problems, you'll easily find many other use cases of registering documents in the blockchain. Feel free to share those ideas with iText; we can provide the technology that will help you getting started.