Economic Exchange in a Regulated Shared Ledger

Abstract

Blockchain and Smart Contract technology suggests a new way to implement the Accounting Information System (AIS), and for setting the Accounting Standards. How exactly this can be done and what are limitations is still very much an open question. After reviewing the current literature our conclusion is that an ontologically sound consensus-based design is missing to date. Against this research gap, the paper introduces a blockchain-based shared ledger conceptual solution, regulated by Financial Reporting Standards. It is shown how consensual and participant-specific parts of the business exchange transaction can be represented in a concise way.

Keywords

• Accounting Information System
• Accounting Ontology
• Smart Contracts
• IFRS

Introduction

Blockchain and Smart Contract technology suggests a new way to implement an Accounting Information System (AIS), and for setting Accounting Standards [ 13 ]. How exactly this can be done and what are limitations is still very much an open question [ 9 ]. A bit more has been said already about the possible benefits. Based on the literature so far, these AIS benefits are the following:

Immutability – The public blockchain as underlying Bitcoin claims to provide an immutable tamper-proof storage for transactions that is completely under the control of the technology.

Actor-independence – AIS systems are traditionally kept inside an enterprise and represent the company perspective on economic exchanges. Evidence from the environment, e.g. invoices from suppliers, is used by the auditor and considered important, but there is no systematic connection between the invoices sent in company A with the invoices recorded in company B. Triple-entry accounting [ 10 ] has been proposed as an independent and secure mechanism to improve the reliability of financial statements based on a neutral intermediary, however, this requires dependence on a third party. A blockchain-based shared ledger (SL) can solve this problem. An actor-independent mechanism may not only drastically reduce the need for multiple copies of the same data, but also contributes the validity of the transactional data because it is based on consensus.

Smart control – Smart contracts encoded with accounting and business rules can enable not only efficient control of the recording process ([ 9 ]), e.g. authorization checks, and error-detection, but also increase its effectiveness. For traditional internal control measures, auditors must check the design, implementation, and operation. Implemented controls could have been switched-off. Building these controls into Smart Contracts that are accessible to auditors (or the parties they represent themselves) makes the design transparent, ensures a 1-1 implementation, and provides a transparent operation (preventive or detective)

Tight integration – The AIS offers a representation of the (economic) reality of an enterprise, but so far relies on human interfaces with this reality. The “reality” consist of social and physical processes. A purchase order or invoice is such a social process. With SL, the order can be put into the blockchain or be tightly connected to it, so that the relationship between order and the AIS representation of it becomes 1-1. In terms of Grigg [ 10 ]: “the entry is the transaction”. For physical processes, such as the delivery of physical goods, the blockchain combined with IoT infrastructure can achieve a close 1-1 correspondence by setting up the SL as the register of enforceable property rights. We also mention here the integration with other parties, such as tax and customs (realtime taxing), regulatory bodies, financial/integrated reporting and assurance services.

Additional disclosure – The new technologies allow to disclose the information relevant to smart contracts and proofs of resource availability, not disclosing information sensitive to the participant.

Other advantages mentioned in the literature are continuous assurance and real-time reporting, but in our view, these are not specifically bound to the blockchain technology. Given the potential advantages, a few papers have already explored the design of a blockchain-based Distributed Ledger Technology (DLT). Dai & Vasarhelyi [ 9 ] sketch a system based on triple-entry accounting [ 10 ]. In this framework, each company keeps its double-entry bookkeeping system, but the blockchain ledger glues the two together, by (a) having a copy of each account of the local system in the DLT, and (b) adding “obligation” tokens and their transfer from one company account to the other that should match – perhaps enforced by Smart Contract – the Payables or Receivables account and (c) having aggregating accounts of total assets, liabilities and equities whose correspondence with the individual accounts can be monitored by a Smart Contract.

Appelbaum & Nehmer [ 2 ] discuss the design requirements for a blockchain-based DLT system and its repercussions for auditing tasks, giving special attention to cloudbased DLT solutions. When reviewing the triple-entry solution of [ 9 ] we wonder why still so much duplication of accounting entries is needed, given the DLT robustness.

Furthermore, from an accounting ontology point of view, the status of “obligation” in this model needs more explanation. Both papers are exploratory in nature. Wang & Kogan [ 21 ] introduce a blockchain-based AIS, including a prototype implementation. The main concern addressed in their paper is the tension between the protection of private data and the desirable public blockchain transparency. The authors solve the tension using Zero-Knowledge Proof encryption. Apart from the encryption solution, the description of the AIS is sketchy. The paper defines a blockchain-based AIS as “a neutral and independent infrastructure that underpins business event recording” However, whether (or how) such a neutral representation – consensus view – is possible within current accounting standards, is not discussed. Our general conclusion is that an ontologically sound and truly consensus-based design is missing to date.

Against this research gap, the goal of this paper is to introduce a DLT solution in a formal way, grounded in accounting ontology. We build on the blockchain ontology developed in [ 15 ] that distinguishes between a Datalogical level (or platform-dependent), an Infological (platform-independent) and an Essential (conceptual) level. In the line of [ 14 ], we extend the REA ontology [ 16 ] used in [ 15 ] for the essential layer to the core COFRIS accounting ontology [ 4,5 ] that is based on current Accounting and Financial Reporting Standards (IFRS) [ 12,13 ]. An innovative characteristic of COFRIS is that it does not put the economic event in the center, but the evolving economic relationship on which the economic exchange takes place. Hence events are not viewed in isolation, but as contributing to the development of the exchange. Because of this choice, COFRIS includes an ontological grounding of the obligation concepts and provides a good basis for a consensus view.

Section 2 is a brief overview of the Economic Exchange pattern in COFRIS. In section 3, a Shared Ledger model is described that realizes this pattern in an SL environment. 2

The Economic Exchange

In [ 4 ] an economic exchange reference ontology and pattern was introduced in the context of Conceptual Framework (CF) for Financial Reporting [ 12 ]. This exchange ontology is grounded on UFO-S – the core reference ontology on services [ 17, 19 ], which characterizes the service phenomena as activity by considering service commitments and claims established between service provider and customer along the service life-cycle phases: offering, negotiation/agreement and delivery. UFO-S presents general concepts spanning across several application domains so that its conceptualization can be reused for the economic exchange activity life-cycle. Economic Resource/Claim and Transfer/Receipt concepts were added in COFRIS [ 4, 5 ] based on the UFO ontology [ 1 ]. The treatment of the Rights to receive as Resources, and consequently as material relations make COFRIS different from REA Ontology [ 14 ], but compliant to existing accounting frameworks [ 12, 23 ]. Economic Performance (Revenue), Exchange and Consensus concepts were not enough explicated in the IASB Conceptual Framework [ 12 ] but play a major role in most of the Standards [ 13 ]. These concepts are being incorporated in COFRIS in a way described in this paper.

Legal aspects of UFO-S contracts were further elaborated in [ 8 ] within the UFO-L Legal ontology, that is based on Hohfeld’s/Alexy’s theory of fundamental legal concepts. The legal positions of UFO-L include not only those corresponding to claims and commitments from UFO-S (i.e., right and duty) but also other elements: permission and no-right, power and subjection, immunity and disability. All these legal relators are from two classes of entitlement and burden (lack), which we refer further to as rights and obligations respectively. The abovementioned pairs of the rights and obligations, and economic relationships, that are based on them, form correlative associations, which are foundations for a shared ledger view.

Economic Contract Life-cycle Accounting

We cannot describe the whole COFRIS ontology but will briefly recall (see Fig. 1) the main concepts of the exchange (contract) lifecycle [ 5 ] before positioning it within a shared ledger context.

Fig. 1(a). OntoUML [ 1 ] diagram of Economic relator and Economic exchange of a Party. Here and further the blue boxes/lines represent the sequence of exchange events, red lines – the value outflow, black lines - the inflow, green lines – the fulfil relationship Following [ 12 ] we define a Market participant (or Economic agent) as a UFO social role-mixin [ 17 ] played by UFO social agents - persons and enterprises, contractual groups of people and enterprises, or the contractual society at large. Market participants are capable of self and social committing and fulfilling economic actions. Market participants are represented by Actors that in turn comprise of accounts for economic relationships that mediate a market participant with society and other market participants. Market participant is identified in the Market and represented in Accounting system; it complies to Local regulations; has its Local currency with the spot exchange Rates; reports its Economic relationships and Performance activities by Financial periods; is bound by Offerings, Contracts; controls its Assets including Daughter enterprises and, Places (Locations); it cannot avoid Liabilities and Equity claims; it plays different economic Roles in Economic events and Economic relators, such as of Debtor and Creditor, Customer and Provider (or more specialized, such as of Lessor and Lessee).

An Economic relator is a UFO social relator [ 17 ] existentially dependent on involved market participants playing the roles of the Party (e.g., by the reporting enterprise) and the Counterparty (e.g., by another enterprise or society at large) and having two or more pairs of mutually dependent Obligations and/or Rights, valued in monetary terms - Current Value, over some Underlying objects, at some Timing. For example: an obligation (a liability) of a theatre to perform to the customers valued at the price of the tickets sold; an enterprise’s ownership rights (against all other market participants) of a house valued at market price; an obligation and a right to exchange (i.e., an Economic contract), e.g., an obligation to transfer ownership rights for an iPhone XX priced at 1000€ for the trade-in rights1 to receive an iPhone X ownership rights2, plus a payment of 500€.

Economic relations are grounded on legal relations or emerge constructively [ 12,13 ]. As emphasized e.g., in EU CF for Financial Reporting [ 23 ] - “In most circumstances, the substance of an economic phenomenon and its legal form are the same”. Since accounting is pretending to be international, it must not ground on local laws, but on international ones, e.g. EU Contract Law [ 18 ] and a legal relation ontology, e.g., [ 8 ]. Thus, elementary economic relationships in UFO-L [ 8 ] terms represent rights and obligations (duties), permissions and no-rights, while second-order relationships represent powers that can produce new economic relationships from older ones. So, an offering transfers power on the offeree, who by accepting it, creates an obligation and a right to exchange in the offeror.

An Economic event, framed in Time Interval, is an Economic exchange (manifestation of a disposition [ 17 ] that inhere in economic relationship) or another event in environment and society, that affects economic relationships. For example, following [ 12 ], an economic resource (e.g., an iPhone XX) control transfer event, in fulfillment of the obligation to exchange, creates a power that changes the transferor’s Right and obligation to exchange economic resources into a Right to receive an economic resource – a Receivable (the iPhone X and the 500€).

Generalizing Income/Expenses definitions in [ 12 ] we state that: An Exchange pattern [ 4 ] is a pattern of a party’s interaction (or disposition for interaction) with a counterparty. The interaction fulfils party’s obligation/right to exchange outflow for inflow, where [with possible reversal]: • outflow is decrease of party’s resources and/or increase of claims against party, caused by their transfer to the counterparty, and • inflow is increase of party’s resources and/or decrease of claims against party, caused by their receipt from the counterparty.

The Economic exchange life-cycle, as in [ 4 ], is conceived as an Offering of interaction made by one of two parties, followed by its acceptance (agreement) by the counterparty, resulting in a contract (of mutual obligations and rights to exchange), that is fulfilled by mutual transfer of the resources (claims) in exchange for the enforcement of rights to receive, and subsequent settlement of unconditional rights to receive.

A Complex economic exchange is regarded as two opposite performance processes progressing towards their realization (settlement), gradually fulfilling the contract obligations (rights) over time by transfers (receipts) of resource control, and service effects.

A Resource is a right [ 12 ] – a combination of the claim-right to exchange/receive, permission to use/consume, power and immunity to transfer, that [combined with other resources and/or passage of time] has the disposition to produce or produces economic benefits.

An Claim against a market participant is an obligation to the resource exchange/transfer to which the market participant is legally or constructively bound.

Party’s obligations/rights are often bound together to specify performance required to produce a revenue/product forming a Performance Obligation/Right (PO/PR), e.g., combination of transfer of a title and transportation services for some object.

Obligations and Rights are often combined in Units of Account that is a group of rights and/or obligations which are usually or mandatory transferred (fulfilled, consumed/used, produced, valued) together, such as a business, an Economic Contract Clause. Unit of Account and thus its underlying Obligations/Rights in their fulfillment process go through Phases such as Commitment/Claim or Obligation/Right to Exchange, Payable//Receivable, Contract or Transferred//Received Asset (Liability or Equity Claim).

Resource/Obligation is characterized by its: • Timing/Condition that denotes a [due] date or period, condition, and queue of expected underlying object availability; • Object rights2 - a bundle of rights over underlying object, such as rights of ownership, use, custody, interest, market operation and service; • Underlying object that denotes physical or intellectual object or their type or service type is characterized by: o Quantity (of collective objects or Amount of matter or of value) of underlying objects or their feature, such as kWh for electricity, and is regarded additive and in some relation with the price; o Place [ 18 ] or Container that denotes [fiat] location at [and in] which the object is or will be available for control; • Dual concept of the Price (Current value [ 12 ]) to a resource is the amount, in currency units, which must be paid now for the (future) availability of that resource (Thus, transfers are simple exchange events exchanging transferred resources for their claimed price).

Assets (Liabilities or Equity Claims) are present rights (obligations) for resources controlled (claims unavoidable) by a market participant, as a result of past events [ 12 ]. They are characterized by their participation in the party’s future actions (Function), and their role in these actions (Nature), as well as Historical cost, from the event that created them, and to be recovered/fulfilled by future actions.

Income and Expenses are inflow and outflow respectively of an enterprise’s assets (liabilities), other than those relating to contributions from and distributions to holders of equity claims [ 12 ]. Specializations of income are revenue and gains, specializations of expenses - cost of sales and losses. When we say increase/decrease, it primarily applies to the quantity that proportionally extends to amount. Value amounts, though can be enhanced separately by using other economic resources or changed by revaluation events. Traditional accounting Debit and Credit notation may be regarded as analogues to inflow and outflow effects, for recognized assets, liabilities (and equity claims), i.e., each event has a form: Dr expenses Cr asset (liability); Dr asset (liability) Cr income, with possible shortcuts in cases when a transfer event results in no change in equity nor cost/revenue.

The fulfil is a multi-level instance-of relationship between an Obligation (Payable), as a disposition (that determines the scope and the type of the fulfilling transfer events), and the manifested [part of the] transfer event.

An Economic contract (see Fig 1(b)) is an agreement between two or more parties that creates enforceable rights and obligations [ 12 ]. Economic contract fulfils Contract offering and contains a bundle of Contract clauses which at inception comprise inseparable and mutual Obligations and Rights to exchange, but during their fulfillment the transferred/received Assets (liabilities), and accrued Contract Assets (liabilities) and Receivables/Payables are added as parts of the contract. Contract resource or asset is a party’s asset accrued for the fulfillment of obligations of a contract clause. Contract asset of PO is a contract asset accrued for the fulfillment of a performance obligation - PO. Performance payable - PO is a party’s liability – unavoidable performance obligation, enforceable by law, and is counterparty’s right to receive, conditioned only on passage of time [ 13 ]. Notice that these concepts refer also to non-cash objects. For counterparty’s Performance rights – PRs, Contract claim or liability, and Performance receivable - PR are introduced symmetrically. 2.2

Behavioral Semantics

The OntoUML diagram in Fig.1(b), besides structural elements, has also some behavioral semantics (depicted by blue lines and boxes) that we describe here only semiformally. Symmetrical party/counterparty elements here are combined into one by showing party’s events and relations before the ”//” symbol, but counterparty’s after, e.g., transfer by party//receive from counterparty, and payable by party//receivable from counterparty. Notice though that the diagram represents the party’s view.

Let’s start with the exchange event, that for some contract clause triggers transfer events that fulfil performance obligation - PO, exchanging transferred Assets (Liabilities) valued at cost for Contract asset of this PO valued at price. Simultaneously a Receipt event (e.g. prepayment from the customer) may happen, forming a Contract liability of PR.

If some PO is wholly fulfilled by the promised transfers, the Revenue recognition event decreases the Contract asset of this PO and increases (by revenue) the Contract asset of this clause. The increase of contract asset by amount of asset of the PO constitutes Revenue.

If all POs of a contract clause are fulfilled, a Receivable recognition (or Realization) event takes place that, fulfilling the contract, exchanges the contract asset of this contract clause for Performance receivables (that enforce rights - PRs of this contract clause).

Receivable settlement event (in accordance with timing) offsets performance receivables against contract liabilities for each PR. If any receivables remain, the Receipt event (in accordance with timing) is activated by e.g. pre-agreed withdrawals or sent dunning letters or simply by counterparty action.

If all the rights of a contract clause are fulfilled before the obligations fulfillment, e.g., full prepayment is made, an alternative Payable recognition event takes place that, fulfilling the contract, exchanges the Contract liability of this contract clause for Performance payables, that can be fulfilled by transfer and settlement events.

All events may be actioned by the market participant or its agent or specified in a [smart] contract as automatically executable - triggered by conditions (specified on the lines that connect event boxes in the diagram) and timing of fulfil.

Due to market conditions the current value of a right/obligation in a contract may change giving raise to inflow/outflow called gain/loss. In the exchange process this triggers special transfer events that increase/decrease contract assets for gain/loss respectively for rights, and special receipt events that increase/decrease contract liabilities for loss/gain respectively for obligations.

If some transfer//receipt event is expired/violated/not-conforming, this is specified as triggered transfer//receipt event of a remedy liability(equity) in addition to or by fulfilling the original obligation//right or payable//receivable. These cases as well as contract modification, suspension and termination events are not further regarded in this paper. 2.3

Towards a Shared Ledger

An advantage of the shared ledger is the [participant] actor-independent view that it offers. This does not necessitate that all information in it is accessible to all parties. Information sharing in a shared ledger must be selective, ranging from global, i.e., among all members of society at large, to particular – among contractual group members, or a party and a counterparty, or participants within an enterprise. The accounting interpretation of the contracts and their fulfillment may be different for each party. Still, the goal should be to obtain more consensus for asset (liability) and resource (claim) interpretation in the contracts. At the same time the related party relation between market participants deserves a special attention to preserve the faithfulness gains of the consensus.

We assume that conceptually there is a shared contract – a pair of mutual obligations to exchange of the parties and contract fulfillment exchange events, and their effects related to the contract in consensus. However, the AIS tagging of the entries may be different for each party, for several syntactic and semantic reasons: • party (or even its parent) specific financial period, account name, unit of account granularity, local currency, rounding rules and other qualities; • party specific resource function, nature, current/non-current timing, or specific restrictions; • different accounting standards classification and valuation requirements for each of the parties.

Therefore, in COFRIS market participants may specialize/generalize (at recognition/derecognition) the claims and resources in consensus, as their own assets (liabilities) per accounting standards and their own operational purposes and include their specific (de)recognition modules into smart contracts that extend the contract manipulation and transfer events. For example, if a provider sells a product, such as fuel, the customer may classify it either as a raw material or as held for sale or for administrative expense – all these asset types are subtypes of the transferred resource.

The existing accounting often loses the semantics of transfer events, because it recognizes the effects of resource transfer instead of transferred resources themselves. The capturing of events that are shared and in consensus should serve as an additional source for (financial) disclosures. An example is services or other resources that are consumed as transferred. The accounts usually recognize only their effects and carrying value increase in e.g. equipment for which installation and testing services were provided. In general, we propose to have the transfers with the transferred resources to be shared and the party specific effects of the transfers on the respective accounts, to be not shared – although this account information can still be part of the smart contract and does not need to be stored in a distinct company database.

To maintain consistency, the phenomena should be correlated in the shared ledger: Those include not only relationships, like Transferror’s PO correlates with Transferee’s PR, but also events, e.g. transfer vs receipt, as shown in Fig. 2. Fig. 3. OntoUML diagram of Provider’s transfers (Shared ledger view). The basic exchange pattern in Fig.1 remains the same, but a shared ledger reflects not only the party specific view for each participant but also transfer consensus view, as depicted in Fig. 2. The general rule for a contract ledger to be reconciled: Transferor view forms the events for the contract, transferee shared consensus appears as a correlative view. Specific accounts of the parties – assets (liabilities) are specializations of the affected by the transfer event resources (claims). Fig.3 depicts effects of provider’s transfer events. In addition to the benefits the shared ledger provides to its participants, the shared ledger view and correlation associations should benefit financial reporting and its standard-setting. 2.4

Examples

We provide a couple of examples, with particular attention to the question of what should be shared in the shared ledger and what should not. We illustrate the economic exchange ontology [ 4 ] and its extension for a shared ledger using examples, represented in the form of a hierarchical Economic event table (see Fig. 4).

Fig. 4. Economic event table for Example 1 (consensus in blue) In the header (in dark blue) of a [Transfer] economic event, the fields denote Event identifier (EID) and characteristics: Transferor type - Customer or Provider (or more specialized role), that specifies the context for the correlativity, Event type - Offer, Agreement, Transfer, Revenue or Receivable Recognition, Settlement or Revaluation (or more specialized subtype), Date or Period and Currency Unit (CU). Provider and Customer identification and their Local currency units with the spot exchange Rates, conclude the event header.

Event detail lines depict events that fulfil (and are triggered by fulfillment) the obligations identified by referenced event, by transferring the promised resource (claim) in exchange of accruing rights to receive or obtaining a settlement: (1) [Resource (claim)] transfer exchanges specified resources (claims) for increases in contract asset of PO, (2) Revenue recognition specifies transfer which constitutes or finalizes fulfillment of some PO, (3) (Receivable recognition) Realization, given that all POs are fulfilled, exchanges Contract asset for specified Receivable increase, (4) Settlement specifies fulfillment and decrease of some PO performance payable in exchange for contract asset of PO decrease (or Resource (claim) transfer) . Fulfil events also specify the Phase of exchanged resources (claims) since there is a difference e.g. of weather Receivable/Payable is transferred versus settled. The PO/PR, Timing, Rights, Object, Quantity, Price, Place are described in Section 2.1. Provider and Customer have their specific, but similar and potentially correlative columns: Place (Container) is a [fiat] from/to location for the resources (claims) transfer, it can be previously established, such as bank account, or established by the actual event (and further identified by that event id), such as received inventory batch.

For transferor, the transfer event, fulfilling obligations, credits the carrying Amount of asset (liability) (of transferred or affecting resource (claim)) account and debits the expenses account by the same amount, debits the accrued contract asset and credits the income account by the same amount of price. For transferee, the transfer event has the correlative effect. Here the posting format [Dr Account, Cr Account, Amount]* is used, convertible to more traditional [[Dr Account, Amount]+; [Cr Account, Amount]+]*. While the former format may look slightly redundant, it contains more information than the latter, because the opposite conversion is not generally possible.

Example 1. Performance Obligation Bundle. This example is about provider P contracting customer C, depicted by EID:11 (that fulfils some offering with EID:10), whereby P commits to an obligation and right to exchange ownership bundle as one performance obligation (PO number 1) of some goods and accompanying setup, by specified dates, for the rights to the cash of 110€ in the specified P’s bank account (IBAN) to be received by 30.09.2018, with the preceding advance payment by 29.08.2018. The participant-specific account meaning should be regarded in the context of the transfer events, thus for contracts, accounts should be regarded as being in contracted state, not yet recognized (those are underlined in Fig. 4), and when such accounts are fulfilled by the transfer event, the debiting/crediting of the contracted accounts is implied. Event 12 partially fulfils the P’s obligation by transferring the goods promised in the contract 11 and accruing the P’s rights to receive - contract asset of PO 1. Matching of costs and revenue by period is not required [ 12 ] but can be reconstructed. Event 13 advances customer payment and creates provider contract liability. Event 14 provides setup services and completes performance obligation fulfillment that in turn leads to P’s realization event that recognizes provider revenue, accrues customer payable and Event 15 offsets contract assets (liabilities). Event 16 settles previous customer liabilities incurred in event 14 by transfer of the total cash amount. Example 2. Revenue Recognition without Immediate Accrual of Receivables. This example, depicted in Fig.5, is like example 1, but has two distinct POs and introduces separate revenue recognition. Revenue in [ 13 ] is defined as “Income arising in the course of an entity’s ordinary activities”. This perhaps is too broad, because income (but not necessarily revenue) arises as an increase of contract asset by particular ordinary transfer. Some other definitions that tie revenue recognition to increase in receivables/cash, or realization of contract obligations, may be too narrow. For instance, Illustrative example 39 of IFRS 15 [ 13 ] shows that a revenue is recognized at some stage, but the receivable is not immediately accrued.

Extending [ 13 ] we regard Revenue as inflow arising in the course of an enterprise ordinary performance, and a fulfillment of performance obligation/payable agreed with a counterparty. It implies that a specific Contract Asset of PO and correlative Contract Liability of PR is recognized, as well as correlative event to Revenue recognition Product recognition, by the counterparty. Such an asset (liability) besides revenue recognition may be important to distinguish for legal purposes, in the cases of contract breaches.

Example 3. Prepayment in Foreign Currency. Economic relationships measured in

foreign currencies need to be constantly revaluated into local currency according to the actual exchange rate. So, if the contract is specified in foreign currency the requirements to the contract asset (liability) valuation are established by accounting standards and interpretations, e.g., IAS 21 and IFRIC 21 [ 13 ].

Let’s analyze the contract asset (liability). According to [ 13 ] a Contract asset is a party’s right to consideration, in exchange for resources transferred to a counterparty, conditioned on something other than the passage of time (for example, the party’s future performance), and Contract liability is an obligation to transfer resources to a counterparty for which the party has received consideration. These definitions are forwardlooking and assign some features of the receivable product to these factors. Thus IFRIC 21 interprets contract liability, formed from prepayments, as a source for future non-cash assets and thus not subject to revaluation.

However, we advocate the present view to these in-process assets and liabilities, meaning that they represent in consensus cash rights/obligations for the transferred resources, to be reimbursed in the case of a breach (for example, a return of a prepayment), thus they need to be constantly revaluated, as shown in Fig 6, depicting Example 3, that is like the Example 1, but with another customer C1, who has USD as its local currency. EID:31 Provider Agreement 01.08.2018 CU: € Provider: P € Customer: C1 € Rate: 1.1 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 30 Obligation 1 31.08.2018 Ownership Widget 5 100 Cost Finished goods 70 Raw materials ContractLiability 110

Contract Asset Income 100 Consideration 1 01.08.2018 Ownership Cash 40 IBAN Cash in bank ContractLiability 40 IBAN Contract Asset Cash in bank 44 2 30.09.2018 Ownership Cash 60 IBAN Cash in bank ContractLiability 60 IBAN Contract Asset Cash in bank 66 EID:32 Customer Transfer 01.08.2018 CU: € Provider: P € Customer: C1 € Rate: 1.1 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 31 Transfer 1 01.08.2018 Ownership Cash 40 IBAN Cash in bank ContractLiability 40 IBAN Contract Asset Cash in bank 44 EID:33 CustomerRevaluation 31.08.2018 CU: € Provider: P € Customer: C1 € Rate: 1.1 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 32 1 Loss Contract Asset 4 EID:34 Provider Transfer 31.08.2018 CU: € Provider: P € Customer: C1 € Rate: 1.2 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 31 Realization 1 31.08.2018 Ownership Widget 5 100 IBAN Cost Finished goods 70 IBAN Raw materials Payable 120 Receivable Revenue 100 ` EID:35 Customer Setlement 31.08.2018 CU: € Provider: P € Customer: C1 € Rate: 1.2 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 32 Setlement 1 30.09.2018 Ownership Cash 40 IBAN ContractLiability Receivable 40 IBAN Payable Contract Asset 48 EID:36 Customer Transfer 30.09.2018 CU: € Provider: P € Customer: C1 € Rate: 1.5 USD Fulfil Event PO/R Timing Rights Object Qty Price Place Debited Credited Amt Place Debited Credited Amt 34 Setlement 2 30.09.2018 Ownership Cash 200 IBAN Cash in bank Receivable 60 IBAN Payable Cash in bank 90 Loss Payable 18

Example 4. Cost-plus Smart Contracts. E, a construction company, enters into a

cost-plus smart contract with a customer D to build an object. D reimburses E for all its allowed expenses plus an additional variable payment that allows E to make a profit. E contracts with the subcontractors and vendors Vs and allows these contracts and contract events [complying to IFRS requirements] to serve as inputs to the contract with D, sharing with D [and the global Financial Reporting system] all the required details in consensus with Vs, possibly omitting the names of Vs. Furthermore, in consensus with D, E shares all the required and non-sensitive details of the contract with D with the Financial Reporting system. During the warranty period, D shares all relevant events involving the built object with E. This set-up benefits from having a single source of truth, simplifying administrative and control procedures, and the possibility of semiautomated execution of the smart contract.

It is important that provider and receiver share and have consensus on the asset (liability) evaluation/classification, especially in the case of obligations remaining/ongoing, such as a lease. Unfortunately, existing accounting standards [ 13 ] are ambivalent on the correlation and prescribe different (not-correlated) lease accounting for the lessor and lessee [ 5 ]. In particular, when deciding between services and lease, the decision is not-correlative, while the decision has certain accounting consequences.

Many contracts contain warranty or prohibition clauses. Those relevant to Financial Reporting must be shared, in consensus and tracked. Even the provider’s costs may be tracked as in Example 4. Similar tracking is needed in the pay as paid type agreements. Another example of partial sharing is to prove the available quantity in an offer, is the possibility of the provider to share only resource quantities and dates contracted/received, but not the parties involved nor prices. The value co-creation process should share the internal processes of all parties, so they gain a better understanding of the resources required on the opposite side.

The mapping from the event to participants accounts is similar to recording intra company transfers, and even cases when an enterprise is required to keep several sets of books complying e.g. to local and international regulations (as suggested by one of the reviewers – Pavel Hruby). The difference lies in the fact that there are confidential parts of event posting. 3

Shared Ledger

It might look trivial to realize an AIS on a “Distributed Ledger”. However, more is needed than a logistic transfer of money or other resource tokens. To meet the requirements of our ontological analysis – in particular, the distinction between consensus and specific information, and the ability to deal with the whole contract cycle – a pure blockchain does not suffice. However, the contract accounting model can be realized by (translated and extended to) a Smart Contract-based Shared Ledger model. We start by listing the most important principles for this realization: 1. Smart contracts (and contract offerings) of market participants, containing mutual (unilateral) obligations of resource (claim) transfer, including information sharing specification, and IFRS [ 13 ] relevant characteristics are added to a shared ledger by consensus of the parties. Smart contracts comprise a hierarchy of rules and include general principles and regulations, particular rules in consensus, and rules specific to the particular participant for producing assets (liabilities) from resources (claims).

Refinements may be unilateral or for exchanges, often in consensus. 2. A Digitized resource (claim) or token represents the valued rights of a participant (for an underlying object) which can be transferred to a counterparty by simply transferring the token. For a referenced resource the token transfer can be a representation of another action of rights transfer or it can effectuate the rights transfer itself (depending on legal context). Digitized resources and consensus are eliminating the need for reconciliation. Economic relationships are represented by referenced or digitized resources, and reciprocities by smart contracts or their offerings in a shared ledger. Following the resources of the exchange ontology, we have several token types. 3. Initial or subsequent negotiation comprises a contract offering token transferred from provider (offeror) to customer (offeree) and subsequent contract agreement token transferred from customer to provider. Atomic transfer event happens in point in time or over time when, fulfilling contract obligations, tokens representing rights/obligations of resources are conveyed from one market participant to another, with simultaneous conveying the tokens of other obligations/rights of resources from the transferee to the transferor. 4. Transfers of digitized resources (claims) are immutably recorded in consensus in a shared ledger, completely, distinctively or partially fulfilling the smart contracts. Transfers together with the accrual of liabilities caused by transfers or their settlement are accounted within smart contracts, including information sharing and IFRS relevant characteristics. 5. The effects of events involving resources (claims) are [de]recognized as assets (liabilities) per IFRS requirements and enterprise policies in the shared or in the individual ledger part, according to information sharing specification. 6. Financial Reporting relevant information gathered in activities 1 through 5 is abstracted to the type level, hiding sensitive instance details and forming an enterprise’s multi-dimensional cube within the [global] Financial Reporting system, possibly using XBRL. 7. The multi-dimensional cube is then aggregated, calculated, viewed, and mined per the IFRS or other GAAP Taxonomy requirements and financial reports are issued and possibly used for preparing national accounts.

Conclusion

Shared ledger systems built on blockchain technology may have a high impact on current Accounting Information Systems, not only because of the claimed immutability of the records but also because of the shift from an internal actor-dependent to an external consensus view. In this paper, we have taken an ontological approach, focusing on the economic exchange pattern. Explicit attention has been given to the question what is to be shared in the shared ledger and what not, and how the two parts can be related in a rigid way. Where there are concerns that the triple-entry accounting suggested earlier “may not be advanced enough” [9: p18], the paper aims to contribute to a foundation that is both ontologically sound and fully compliant with the Accounting and Financial Reporting Standards.

Financial reporting and thus its standard-setting should be based primarily on economic relationships and events (including revenue recognition), in consensus among market participants.

Blockchain platforms are evolving rapidly now. For that reason, we have focused on a platform-independent model, and not on the coding, although we are also experimenting with the PIM to PSM level transformation now [ 20 ]. We are planning to bring these efforts together.

References

1. Guerson J. , et al., OntoUML Lightweight Editor: A Model-Based Environment to Build, Evaluate and Implement Reference Ontologies , EDOC 2015 , Demo Track , Adelaide, Australia, 2015 .

2. Appelbaum , D , Nehmer, R. , Designing and Auditing Accounting Systems Based on Blockchain and Distributed Ledger Principles, working paper Feliciano School of Business , 2017 .

3. Ben-Sasson , E. , et al, Decentralized Anonymous Payments from Bitcoin. Security and Privacy (SP) , 2014 IEEE Symposium , 459 - 474 .

4. Blums , I. , Weigand , H. , Towards a Reference Ontology of Complex Economic Exchanges for Accounting Information Systems . EDOC 2016 : 119 - 128 .

5. Blums , I. , Weigand , H. , Financial reporting by a Shared Ledger , JOWO , Bolzano, 2017 .

6. Buterin , V. , A Next Generation Smart Contract & Decentralized Application Platform , 2014

7. Coyne , J.G. , McMickle , P. , Can Blockchains Serve an Accounting Purpose? Journal of Emerging Technologies in Accounting In-Press, 2017 .

8. Criffo , C. , Almeida , J.P.A. , Guizzardi , G. , From an Ontology of Service Contracts to Contract Modeling in Enterprise Architecture , 21st IEEE Enterprise Computing Conference EDOC 2017

9. Dai , J. , Vasarhelyi , M. , Toward Blockchain-Based Accounting and Assurance . Journal of Information Systems , 31 ( 3 ), Fall 2017 .

10. Grigg , I. 2005 . Triple entry Accounting . Systemics Inc. http://iang.org/papers/triple_entry.html .

11. Hevner AR , March ST , and Park J ( 2004 ) Design Research in Information Systems Research . MIS Quarterly, 28 ( 1 ): 75 - 105 .

12. IASB Exposure Draft ED/ 2015 /3. Conceptual Framework for Financial Reporting, IASB , 2015 .

13. IASB homepage, http://www.ifrs.org/issued-standards/list-of-standards, IASB , 2018 .

14. ISO/IEC. Information Technology - Business Operational View - Part 4: Business Transactions Scenarios - Accounting and Economic Ontology, ISO/IEC FDIS 15944-4 : 2015 .

15. Kruijff , J. de, Weigand, H. , Understanding the Blockchain Using Enterprise Ontology . CAISE, 2017 : 29 - 43 .

16. McCarthy , W.E. , “ The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment” , The Accounting Review , ( 1982 ), 544 - 577 .

17. Nardi , J. , et al., Towards a Commitment-based Reference Ontology for Services , EDOC, 2013 .

18. The Principles Of European Contract Law 2002 (Parts I , II , and III), European Union , 2002 .

19. Guarino N. , Services as Activities: Towards a Unified Definition for (Public ) Services . EDOC Workshops 2017 : 102 - 105 .

20. Syahputra , H. , Weigand , H. 2017 . The Development of Smart Contracts for Heterogeneous Blockchains (in press).

21. Wang , Y. , Kogan , A. , Designing Privacy-Preserving Blockchain Based Accounting Information Systems (May 24 , 2017 ). http://dx.doi.org/10.2139/ssrn.2978281

22. Warren , W. , Bandeali , A. , 0x: An open protocol for decentralized exchange on the Ethereum blockchain , February 2017 .

23. Presentation of a policy paper by “Elements for a European conceptual framework” by Philippe Danjou and Isabelle Grauer-Gaynor , 2017 . http://www.anc.gouv.fr