Reconciliation of travel reports is essential in the functioning of a travel agency. Reconciliation of GST amounts from the travel agencies’ and airlines’ side, ensuring that a passenger hasn’t underpaid the travel agency, comparing base fares of reports generated by the travel agency and the airline are some of the several types of checks an organization would want to implement. It is an important step in ensuring the smooth flow of finances of the company and the client’s organization. The company would want to ensure that they’ve not charged a customer lesser than what the airline would charge them, or that they’ve not made any losses due to a GST mismatch, etc.
On the other hand, the client/business might require an automated system that can compare invoices submitted by their employees and that generated by the services they availed while on the business trip. This would ensure no discrepancy in values quoted by the employees and availed services such as hotels, flights, etc., and thereby ensure that no losses incurred have been by the business in the process of reimbursement.
How is reconciliation currently being implemented?
As of August 2018, invoice reconciliation is a cumbersome process requiring human effort due to there not being a unified invoice format followed by all companies. Machine learning algorithms that can replace human intelligence in correctly extracting information from these invoices have not been developed yet.
This allows room for human errors, malicious actors modifying invoice contents and makes verifying records very time consuming. To sum up, two major loopholes stand out in the current system in place:
- cant amount of time is spent on checking these records — time that could otherwise be used to inspect invoice mismatches etc. Additionally, there is quite a bit of room for human error.
- The travel agencies and airlines currently store records on centralised servers. We rely on the fact that the records are unchanged and will remain so in the future, that the server is guaranteed to function at all times with 100% uptime, and that these records are secure. In other words, this system requires one party to trust another. (Fig 1).
Fig 1: Current setup used in client side reconciliation. All of the data processing and storage is done in a central server.
As a proof of concept, we wrote a Node.js script hardcoded to understand 3 report formats. This module can be substituted with a more sophisticated piece of code that can parse any input invoice to output a common object format. This script can take as inputs 2 invoice files, a list of arguments pertaining to each invoice that have to be compared, and logical operations between these two fields. On invoking the “reconcile function”, the two invoices with their specified fields are reconciled and a .csv file is generated with information about whether each entry passes or fails the test.
Fig 2: CSV report generated upon reconciliation of two records.
Why blockchain?
The current system of managing invoices is fails to address the following concerns:
- Invoices are stored in a central database which introduces a single point of failure. That is, all of the records are permanently lost if that server goes down.
- Invoices are open to the risk of being modified by anyone with access to the database or a malicious third party. On a similar note, invoices can be stolen, deleted and tampered with in such a setting.
- A central database doesn’t guarantee the permanence of a record stored on it. Once the record is lost, there is no way to retrieve it.
- We would like there the database to serve as an efficient version control service so we can keep track of any authorized modifications and when they were made, or go back to a previously existing version of the record along with recording these changes permanently.
A blockchain can act as an efficient distributed file storage solution that addresses all of the concerns mentioned above in the following ways:
- A centralised server always runs the risk of being a single point of failure in the sense that all that is stored in the database is lost if it goes down. A blockchain is a distributed ledger that keeps track of all the data and entering and leaving it. Since it is distributed by nature, this removes the risk of having a single point of failure. A copy of this blockchain exists on several nodes spread across the world. And this ensures that a universal, updated copy of the blockchain is always present on other nodes regardless whether your local copy is present, deleted or outdated.
- A blockchain is an immutable ledger. The content present in a blockchain cannot be modified or deleted. Content cannot be injected into the blockchain and the order of the blocks present in a blockchain cannot be changed. This would mean that if the content of these invoices was to be stored on the blockchain, it cannot be modified, swapped in order, deleted or injected someplace it doesn’t belong. In other words, once a transaction/travel entry is uploaded onto the blockchain, it remains there permanently.
- Any entry that goes on the blockchain has a unique transaction ID. If an entry is modified, the modified version is given a new transaction ID and both of these copies exist on the blockchain. In this way, all versions of an entry are maintained and the blockchain hence serves as an efficient means for version control.
- Since a blockchain is distributed in nature, everyone has access to the data stored on it. Maintaining privacy of sensitive information such as travel data stored on the blockchain is hence necessary. For this purpose, the data was encrypted using symmetric key encryption before being uploaded to the blockchain.
Fig 3: Alternate setup that could be used in client side reconciliation. All of the data processing and storage is done in a decentralised storage solution such as the Ethereum blockchain.
As a proof of concept, we used the Ethereum blockchain to manage invoices of the travel company (Tripeur) and all of the airlines that it collaborates with. These invoices can then be retrieved for reconciliation from the agency’s side.
Fig 4 shows the workflow of the module that interacts with the blockchain.
Fig 4: Hierarchical view of the workflow of the module used to interact with the Ethereum blockchain.
This module has the following features:
- Invoice entry objects are symmetrically encrypted using the ‘crypto-js’ package made available by node package manager. The user is allowed to specify the key with which he/she wants the entries encrypted.
- Using the web3 API, these entries are uploaded to the blockchain.
- Using the web3 API, entries can be retrieved given a specific date, PNR and key used for decryption.
- Excel reports of the invoices can be recreated from the blockchain by specifying a start-date, end-date, and key used for decryption.
- Information on the blockchain can only be modified by the admin (currently set as the smart contract creator).
- View and access privileges to this information can only be set/revoked by the admin. (Typically only the admin and data owner can have access to a particular data entry).
- The admin can create or revoke multiple admin identities if necessary.
Room for improvement:
It would be beneficial to use a distributed file storage solution such as IPFS (Interplanetary file system) to store records and ensure their permanence. Since storing data is expensive on the blockchain, storing data pointers (hash values of the entries in this case) could potentially reduce cost of storage of entries on the blockchain.