Blockchain-Based Accounting: General-Ledger Posting

For more details see the following link:

CRYPTOGRAPHIC METHOD AND SYSTEM FOR SECURE EXTRACTION OF DATA FROM A BLOCKCHAIN

Executive Summary

This white paper defines a blockchain-based service for extracting, classifying, and posting transactions that have been posted to the blockchain into an accounting-ready format using information from the transaction inputs/outputs to determine the appropriate posting formula and calculations.

The method defined within this paper ensures that the posting to the general ledger (GL) can be publicly demonstrated to be a true and accurate reflection of the activities of the entity in regards to the blockchain. The method allows automated posting into a modern accounting system for both Bitcoin and tokenised transactions, whilst not placing any restrictions upon how the entity chooses to allocate their keys. GL states (i.e. reports at any point in time) can be stored as a permanent unchangeable record by storing a ‘hash’ of the state onto the blockchain.

A general ledger typically uses the double-entry bookkeeping method — where each financial transaction is posted twice, as both a debit and a credit, and where each account has two columns. The general ledger is generally comprised of a series of sub-ledgers which are rolled up to produce the overall general ledger.

Modern best practice for general ledgers keeps them ‘thin’, where each entry is an aggregated set of individual transactions, rather than recording the lowest level of accounting information into them — although each record can drill-down to bring back the lowest level of information from the relevant sub-system. The best practice for Bitcoin (for example, frequently changing the key used for a transaction) makes the posting of information to an entity’s general ledger complex.

Background

The general ledger is the master set of accounts that summarise all the transactions occurring within an entity. The structure of this set of accounts is up to the individual entity itself, but would include the accounts reported on a business financial statement (cash, accounts payable, expense accounts, and purchases and loans). Each ledger in the general ledger maintains a separate balance or a running balance of the financial position based on a monetary exchange for each account which the business needs to track.

To keep the number of transactions within the general ledger manageable, frequently the general ledger account features a single transaction line of the balance from a sub-ledger, where the sub-ledger contains the breakdown of the individual transactions themselves (and this process can be nested further if necessary).

The accounting setup for entities can get massively complex with hundreds or thousands of separate reporting points (e.g. business units, departments, products, etc.). In complex organisations, parallel books are required (e.g. an accounting treatment for legal purposes, and one by product line and one by department).

Large enterprises implement complex financial systems based on large database structures in order to track these large entries. These complex financial systems act as a master repository for the overall general ledger of the organisation; this leads to the creation of a complex financial system where various accounts are added, viewed, or edited in such a way that they manage to effectively keep the chart of accounts valid for the enterprise and allow it to be reported on. Enterprises also employ other information technology systems to add additional specialised or specific task functions to the organisation; some of these that reference the master data stored in an enterprise general ledger include a variety of means of mapping the chart of accounts to produce valid accounting entries that will enable reports to be extracted from the general ledger system. These reports and the tracking data can be created such that a combination of account, department, project, or other specific report formats can be extracted.

The more complex enterprise-GL systems allow for rule-based engines that provide combinations of accounts or data to be verified against a series of rules. In these systems, account combinations do not need to be maintained explicitly, but can be extracted dynamically. Such complexity has led many businesses to externalise the chart of accounts with general-ledger clerks performing multiple tasks, including the setup of a chart of accounts and maintaining selected individual combinations of functions within their individual set of accounts that they manage. It can lead to problems between account synchronisation, with master data being required to be synchronised between multiple systems. In many large accounting systems including Oracle, it is proven to be extremely complex, and the limitations or assumptions around the integration of these accounts make the accurate reporting between different entities difficult. This tends not to be a limitation of the GL solution itself, but rather the ad-hoc nature of the feeds into such a system from various packages that may or may not be financially aware and therefore require complex mapping and consolidation.

The result is a set of solutions that are prone to problems. In complex systems, data can become stale in one system, where the clerk updating the account does not maintain data to an adequate standard. A delay in updating data can lead to discrepancies between systems. Tree-based rule structures cannot easily be implemented and deployed in many of such distributed systems due to the requirement to map disparate data sources, where account fields may be named differently.

Functional Overview

There is a separate white paper 0060 that covers a closely related mechanism for how to perform the full general-ledger accounting solution directly on the Bitcoin blockchain.

But, the present specification covers the ability to automatically extract, categorise, and feed an existing general-ledger system from information that has been stored on the blockchain (and for certain accrual-based functions from information in the pending transaction store) by other processing systems (note that the information stored on the blockchain may also contain tokenised input, so this is not a solution for booking only Bitcoin transactions).

This mechanism, together with the tokenisation defined in white paper 0165, will allow an automated, consistent, and reliable method of posting:

• simple financial transactions (denominated in BSV, paid into or from an entity’s account);
• complex financial transactions (denominated in tokenised form, paid into or from an entity’s account);
• multi-party transactions (multiple inputs, and/or multiple outputs) in either simple or complex form; and
• inter-entity transactions both simple and complex.

Through this method, it will also be possible to produce more complex extracts that allow full substantiation of the account balance for the chart of accounts, including:

• assets and debts; and
• cash flow.

The solution will monitor the public keys and derived public keys (see white paper 0042 for details of deterministic sub-keys), and other addresses in a hierarchical fashion and map that tree structure against the chart of accounts. This key hierarchy allows other systems to generate financially robust data, without having to build the complexity into those legacy solutions, as the blockchain will enforce the controls automatically.

As with a standard ledger solution, the rules allow the entity to post at the granularity that meets their needs from a coarse rolled-up value to a granular individual transaction (or a combination of the two).

The specialised extract-and-posting solution itself relies on a blockchain oracle (see white paper 0160 for details) to constantly monitor the blockchain and use the canonical rule-set defined by this white paper to detect, aggregate, and post the relevant transaction inputs and outputs[1].

The derived accounting system can be set up to automatically consolidate and post individual sections of the chart of account values as a part of, or a combination with other sections of the chart of accounts, allowing users to either validate and report on their own area or as an overall summary of the organisation as a whole.

This model simplifies the ongoing audit requirements for the company, since the source data used for the posting is the underlying cash movement (for the most part) and is a publicly unalterable record.

In addition, by using the same cryptographic techniques to sign the posting rule-set that was used and the posting data itself, it provides a robust chain of evidence to support the requirements of any external auditor.

Technical Specification

In order to post entries to the general ledger package, the system must first extract all the transactions from the blockchain that have not already been posted.

Use-Case Model

The following use case model demonstrates the steps involved in a generic blockchain-posting approach.

Key Use Cases

[100] Determine Accounting Configuration

Description

As an Account Posting Agent I need to get the details about how to detect what it is that I must post, plus where I must post that to.

Primary Actor

Account Posting Agent

Main Success Scenario

The following diagram shows the data set that is built up by the various steps.

This highlights a number of key features about the configuration:

• There is no requirement that every account must have a posting rule applied to it; equally, there is no requirement that multiple rules can’t point to the same account.
• There is no requirement to ensure that all keys are covered by an allocation rule (although best practice would be to ensure that there was at least a single allocation rule for each root key to ensure that transactions were not dropped by accident).
• It is possible to double-stack rules within the hierarchy (e.g. have an allocation rule defined at the child and at a parent). This is interpreted as posting at the child and not at the parent (to prevent double-posting), but allows ‘exception’ rules to be created without complicating the sub-key model.

[200] Extract Transactions from Blockchain

Description

As an Account Posting Agent I wish to extract all the transactions that I am interested in and have not already posted.

Primary Actor

Account Posting Agent

Main Success Scenario

[300] Create Posting

Description

As an Account Posting Agent I consolidate all the individual account postings into a posting report.

Primary Actor

Account Posting Agent

Main Success Scenario

[400] Post to General Ledger

Description

As a General Ledger I need to post all the blockchain transactions into the relevant accounts.

Primary Actor

General Ledger

Main Success Scenario

Key Variations

Using the Blockchain as the General Ledger

This paper covers the solution where the Bitcoin transactions are simply part of the organisation’s trading position, and therefore need to be included within their existing accounting model. Such a scenario is likely to be the case until the Bitcoin environment becomes ubiquitous — in particular around areas such as tax liabilities, which currently require calculations to be performed within the fiat currency, and those liabilities to be paid through ‘traditional’ banking payments in that fiat currency.

Once Bitcoin ubiquity has been achieved, it is possible to migrate the general ledger itself onto the blockchain and simplify further the process defined within this paper. White paper 0060 describes the method for achieving this.

Accrual Postings

As described above, this mechanism effectively only allows cash-based accounting, which supports many companies and businesses but can be inflexible in some circumstances.

It is possible to use the same methods above to handle accruals-based accounting, by running the posting rules off of the transactions rather than the blockchain block (in practice, the method would likely post from the transaction, then reverse and re-post from the published blockchain block, as this would allow the general ledger (GL) to determine certain liabilities more accurately). In practice, to support this, the Account Posting Agent would need to be a Bitcoin node in its own right (although it would probably be implemented as such regardless).

This means that transactions that should be accrued for later settlement (for example those published with an nLocktime value) can be fully accounted for before the underlying settlement is committed to the blockchain.

Substantiation

As an alternative to posting the accruals from the blockchain (which is very complicated in terms of rules when some of the other techniques such as using the blockchain to operate an Accounts Receivable solution described in White Paper 0124 are used due to the complexity in deriving the redeem scripts here), the mechanism used in this white paper can be used to generate the substantiation for the general ledger.

In this situation, the actual postings to the general ledger are generated from the application systems themselves (e.g. the payroll system posts directly into the GL).

But, in order to validate that what the payroll system has posted matches what has actually occurred, a substantiation report against the cash (or in this case BSV) movement is produced and apportioned.

Whilst the process for generating this report is identical to the process for posting, the advantage is that — generally — the rules and the consolidation are broader, thus reducing the implementation complexity of the solution.

Notes:

[1] Note that whilst the paper talks about posting blockchain transactions, in practice the mechanism is at a lower level of monitoring individual transaction inputs and outputs, which allows a single blockchain transaction to be posted against multiple accounts simultaneously, although it is important that the solution ensures that integrity is maintained such that partial posting cannot occur.

[2] Whilst the rules to derive redeem scripts here work, it is unlikely to be pragmatic to implement the model in this manner and would be more efficient to implement a ‘sweep’ address to which fragmented individual redeem scripts are collated and the account posting generated from this account.

[3] Note that this step is simple for BSV transactions, since the value of the transaction remains the value of the transaction. But when posting tokenised transactions (e.g. the actual transaction is in USD or ounces of gold), then the rule must specify how to derive the value from the metadata within the transaction.