Since the 1500s, accounting and bookkeeping have followed the practice of Double-entry Bookkeeping. It implies that every entry to an account requires a corresponding and opposite entry to a different account. The double-entry has two equal and corresponding sides known as debit and credit. The left-hand side is debit while the right-hand side is credit.
For instance, recording a sale of $100 might require two entries: a debit of $100 to an account named "Cash" and a credit of $100 to an account named "Revenue."
Assets = Equities + Liabilities
The accounting equation is an error detection tool; if at any point the sum of debits for all accounts does not equal the corresponding sum of credits for all accounts, an error has occurred. However, satisfying the equation does not guarantee that there are no errors; the ledger may still "balance" even if the wrong ledger accounts have been debited or credited.
Triple entry accounting has an enhancement over the conventional system as all the accounting entries involving outside parties that are cryptographically sealed by a third entry. These may include purchases of inventory and supplies, sales, tax and utility payments, and other expenses. The bookkeeping entries of both parties are placed beside each other to ensure that the given transaction is congruent. A seller books debit to account for cash received, and a buyer books a credit for cash spent in the same transaction, however, in separate sets of accounting records. This is where blockchain and DLTs come in: rather than these entries occurring separately in independent sets of books, they occur in the form of a transfer between individual ledgers of the two parties that reflect in the same distributed public ledger, creating an interlocking system of enduring accounting records. Since the entries are distributed and cryptographically sealed, their immutability and transparency are assured.
A “Forward” transaction is one in which the operating node sends multiple transactions as a single transaction to the next recipient. For example, Company A sends 100 pieces of a component to Company B, thus “sending” the components to the next stakeholder in the value chain.
A “Return” transaction is one in which the operating node returns a received transaction to the sender of the transaction, in part or full. For example, a Company B receives 100 units of an item from a Company A and may wish to return all or some of the items while paying for the rest of items to Company A. Company B initiates the return as two different transactions, one of goods and the other as payment for accounts to be reconciled with full settlement of quantities, amount and tax.
A “Split” transaction is one during which an operating node splits a single input transaction into two or more nodes with multiple attributes. For example, Company A receives 100 units of an item and then splits them into two batches of 50 each and sends each of the batches to two downstream buyers. The reconciliation requires Company A to receive payments from both the buyers and reconcile accounts with its bank transactions as well as buyers.
A “Merge” transaction is one in which the operating node merges multiple transactions received into a single transaction and sends it to the next recipient. For example, a Manufacturer receives 100 sets of five components from five different vendors to manufacture 100 units of a finished product, thus “merging” the components into one unit each and sends them to the next stakeholder in the value chain.
Incumbent upon the transaction, reconciliation would be required on attributes like quantity, rate, amount and tax applicable on all 3.
Forward and Return Transaction will handle all tagged attributes for reconciliation along with any value addition. In addition, the transaction ownership now changes to the initiator of the Forward or Return and the receivers cannot modify the transaction until they operate upon it. The reconciliation requires the First party to receive goods and services along with related documents such as invoices, vouchers, orders from the second party. The First party may then make payments through the bank to the second party which will need to be reconciled for settlement. On the other hand, the First Party may pay, return or reverse inventories in part or in full, requiring him to reconcile inventories, corresponding payments, taxes, and other expenses with payments through the bank where reconciliation may become slightly difficult to track, especially if its spread out over time. A Forward or Return will require a pair of ledgers for each party along with reconciliation by both parties with their respective banks and statutory filings such as GST.
A Merge or Split requires at least three pairs of ledgers to be reconciled, in addition to their respective banks and statutory filings such as GST and multiple ledgers for the goods in transit, which are to be reconciled. With Aurigraph DLT, all of the above can be achieved through API integrations with their respective sources, thereby reducing manual intervention and Operational effort and cost significantly for administration, accounting and audit.
Aurigraph protocol and platform supports Real-time reconciliation and audits across multiple stakeholders and their ledgers. Built on Application layer Atomic Multicast protocol, the platform ensures complete transparency and immutability of any transaction, from transaction initiator to the consumer also cutting costs. Aurigraph Distributed Ledger offers near-Zero-latency with transaction cost while being able to support over 100000 Transactions/second, thus breaking all barriers and challenges in scaling, latency and atomicity. Further, such a solution can reduce and eliminate the risk of human error and fraud. Aurigraph is end-to-end quantum secure, thus eliminating any possibility of breaching data. Unlike conventional blockchain solutions, Aurigraph can operate on mobile phones running Android/iOS and desktops running Windows, Linux or macOS.
Aurigraph DLT Platform uses NoSQL Graph Database that supports Real-time analytics and reporting. High volume transactions with multiple stakeholders for data generation and consumption in use cases such as Track-and-Trace and Reconciliation-and-Audit applications are ideal applications for Aurigraph. Aurigraph nodes can be embedded with Apache Camel to integrate with Enterprise Applications of all stakeholders further helps in analytics and reporting.
Aurigraph DLT works best in Real-time Track and Trace scenarios requiring reconciliation and audit across multiple parties in a value chain requiring immutability and transparency with a high volume of transactions.
Real-time reconciliation and settlement reducing over 15% of OpEx across value chains. Realtime evidence-based audit reducing 8 % of OpEx across value chains
Transaction-based pricing model, ensuring high Return on Investment and low Total Cost of ownership Easy to build and maintain DApps
Subbu Jois has been involved in start-ups as Strategic Technology Leadership roles involving Blockchain, DLT and Microservices Platforms in Fintech, Retail, E-Commerce, Healthcare and E-Learning verticals, having built products, teams and organizations over the last 29 years. Subbu Jois has filed for patent for Aurigraph and other decentralized platforms and solutions in fintech, healthcare, gaming, among others Subbu is credited with having implemented the first e-governance solution for village administration in 1999-2006 near Bangalore, earning him recognition from
Business transformation strategist with over 20 years of progressive leadership experience in the IT, Security and Telecom industries in India and abroad. He has worked with companies like SLK, Ericsson, SingTel, Tata Communications, and Vodafone etc. In his last corporate avatar, he was the Head of Datacenter for a large Telecom & prior being Chief Technology Officer (CTO) for large global BPO based at Pune. Speaks regularly in India & Outside on Blockchain & emerging Technologies