The Intercompany Settlement Blockchain: Benefits, Risks, and Internal IT-Controls

Abstract

Blockchain is a novel technology that can be employed for a plethora of business applications. A blockchain provides highly reliable transaction data because it has a number of properties that guarantee the integrity of the data that is processed and stored. Paradoxically, the use of blockchain technology is associated with peculiar risks that need to be controlled. Therefore, the sophistication of this technology warrants a rethink of current IT-controls to manage accounting processes while novel controls need to be established to control the technology itself. In this chapter we discuss the impact of blockchain technology on IT-controls, and what IT-controls should be in place to mitigate risks using a case study of a blockchain implementation at the KLM Royal Dutch Airlines.

The author would like to express his gratitude for the support of Eric Westhoek from Erasmus School of Accounting & Assurance and the KLM Royal Dutch Airlines former Vice Presidents Internal Audit, Eric Wittgen and Gijsbert Woelders.

1 Introduction

Blockchain is a novel technology that can be employed for a plethora of business applications. In recent years, blockchain projects are gaining traction using new blockchain and Distributed Ledger Technology (DLT) platform providers, such as Ethereum, Corda, and Hyperledger (Revet et al., 2021). Blockchain technology establishes a protocol of trust between mutually distrusting parties by employing a combination of a Secure Hash Algorithm (SHA), encryption technology, and Peer to Peer internet networks (P2P). This combination of technologies ensures that a blockchain provides highly reliable transaction data, and as such the technology is finding increasing support among banks and other companies (Rauchs & Hileman, 2017).

A blockchain provides highly reliable transaction data because it has a number of properties that guarantee the integrity of the data that is processed and stored. Using encryption techniques, transaction data becomes immutable and thus tamperproof, while a consensus mechanism ensures that new transactions are validated and the nodes in the P2P network verify the transactions and broadcast them to the other nodes (Kloch & Little, 2019; Butijn et al., 2020; Yaga et al., 2019). These properties aid companies that employ a blockchain for accounting in exerting more control over their financial processes. Paradoxically, the use of blockchain technology is associated with peculiar risks that need to be controlled (ISACA, 2021; Bernsen et al., 2019). Therefore, the sophistication of this technology warrants a rethink of current IT-controls to manage accounting processes while novel controls need to be established to control the technology itself. In this chapter we discuss the impact of blockchain technology on IT-controls, and what IT-controls should be in place to mitigate risks using a case study of a blockchain implementation at the KLM Royal Dutch Airlines.

The remainder of this chapter will proceed as follows. In the next section (Sect. 2), a brief background on IT-controls will be provided. Furthermore, an examination of the impact of IT on financial processes, the external financial accountability, and the role of the IT auditor is provided. Subsequently, Internal Control over Financial Reporting, ICFR, and the interaction of the IT General Controls (ITGC), Application Control (AC) and Manual Controls (MC) in the Business Control Framework (BCF) quadrant are discussed. Finally, the SOx act in relation to COSO and COBIT is explained with a focus on IT-controls. The section concludes by discussing the benefits of blockchain for accounting. In the third section, the case study of a financial in-company blockchain settlement process is described. The case study depicts this process both with and without a blockchain application. In the fourth section, we present the analysis of the impact of blockchain on the IT-controls discussed in the case study. A graph shows the impact of the corporate blockchain at the process and IT level on IT-controls at the entity, process, and ITGC level. These IT-controls are related to the identified risks of the chosen DLT implementation. Finally, in the conclusion section we present several conclusions on the basis of the analysis in the case study.

2 Internal Control over Financial Reporting (ICFR): “IT-Controls”

Large companies are required to annually organize an internal audit on Internal Control over Financial Reporting (ICFR) by an external auditor, as a result of the Sarbanes-Oxly (SOx) Act 404, enacted in response to large-scale accounting fraud within the chemical group Enron. The internal audit control looks at the “design effectiveness” (type 1, design and existence) and “operational effectiveness” (type 2, operation) of controls. The costs and effort of setting up an ICFR and performing the annual audits are relatively big. Besides meeting legal obligations imposed by the SOx, an effective ICFR provides benefits such as (Center for Audit Quality, 2019):

• Reasonable assurance that financial records, knowingly or unknowingly, have not been misrepresented. It exposes the material weaknesses and imperfections.

• A structure that identifies and mitigates risks and raises awareness and alertness at all levels of the organization to prevent fraud.

• Guarantees the integrity of the financial reporting and creates an image of trust towards stakeholders.

Despite concerns raised by firms about regulatory burdens imposed by the US Securities and Exchange Commission (SEC) and the costs to ensure ICFR compliance, the Center for Audit Quality (CAQ) has provided evidence that the SOx act has a positive impact on the robustness of the US capital market, corporate valuation, and corporate fraud prevention (COSO, 2013). ICFR controls are designed to reduce internal and external business risks in a manner that allows day-to-day operations to be conducted in an effective and efficient manner. Internal control prevents that the objectives set by the company are not achieved. It constitutes a total of measures, guidelines, and controls in terms of IT and organization that should ensure that the reliability of the financial reports is safeguarded. Material errors in financial accounting negatively influence decisions and have an impact on the achievement of strategic and financial objectives.

2.1 IT-Controls

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) provides companies with a framework for internal management and control. COSO is a “top-down and risk-based approach” framework. It has been inserted at the highest level of the Audit Committee, the board of directors, and senior management to create broader support for the urgency, importance, and follow-up. The COSO cube in Fig. 1 depicts the framework.

Fig. 1

The COSO cube (COSO, 2013)

On the top face of the COSO cube the objectives that a company strives for are displayed, and on the front face the required five components to attain these objectives are shown. The right-hand panel indicates that it applies to all layers of the organization. The five components are the foundation for setting up your ICFR and can be set up iteratively and cyclically (COSO, 2013). IT-control objectives aim to ensure that systems can guarantee availability, continuity, and integrity and can be classified into preventive, detective, and corrective IT-controls (Otero, 2018). An example of a preventive control type is the arrangements on access to the IT or setting upper bounds to payment approvals above a certain amount. Detective IT-controls are for example the comparison of extractions from different databases and can be considered as IT-dependent manual controls. Patch upgrades to prevent vulnerabilities are covered with corrective IT-controls.

Within the ICFR, controls take place at all levels of the organization. The organization of IT governance, IT strategy, and IT-business alignment is controlled at the entity level. IT security choices such as software on premises, or in the cloud are decisions made at the entity level. The standard on which these decisions are based is what is more cost effective and more secure in current market conditions. At the process level, controls such as segregation of duties and manual controls are established to detect risks such as conspiracy. At this level, data in applications is checked by means of extractions in order to manually compare the data from independent data sources.

IT-controls can be deployed and set up at all levels and have a different relationship to each other. For example, IT access management at entity level control concerns issues such as access policies and procedures. On a process level, IT access management is about which function or department has decision-making rights in the system. At the ICFR, the IT General Controls (ITGC) and application controls (AC) are the most important IT-controls and are applied to the relevant information systems at application and infrastructure level. Examples of application controls are the establishment of authorization matrices, that define who has which rights, payment approvals, and an automated 3-way match for purchasing.

The ITGCs apply to the processes related to system components such as databases, operating system, and network that are present in an organization. The objective of ITGCs is to control the process in and around the information system. The most used and most relevant ITGCs are (ISACA, 2014):

• Logical access security: Granting access to systems.

• Program change management: Implementing changes on systems.

• IT Security: Securing systems.

• Backup and recovery: Safe data storage and recovery of data.

• System development: Assessing whether systems need to be replaced.

• Computer operations: Configuring and setting up systems.

Control measures, ITGCs, are necessary to prevent IT risks and thus guarantee the continuous operation of the application controls. The deployment of control measures, application controls and IT-dependent controls, in relation to ITGCs are visible in the BCF quadrant (Fig. 2).

Fig. 2

The business control framework (Folkers & Westra, 2017)

The first quadrant includes the segregation of duties that describes the powers within the organization, what you are allowed to do. The plan has been established to segregate duties. In the second quadrant that concerns the IT General Controls, comprehends several processes. Within this quadrant, the operation is tested over a period of time. A third quadrant is related to the Application controls (AC). The AC configuration device of an application allows automatic controls to be done within the application. In contrast to quadrant 1 (what you are allowed to do), in this quadrant it becomes clear what you can actually do. It is a recording of the existence of the control. The final and fourth quadrant concerns the manual controls (MCs). Manual procedures are obviated herein. Between the MC and AC there is an intermediate form “the IT-dependent control.” An example of this is extractions from databases that are subsequently checked manually.

The effective design of application controls can be demonstrated by proof of existence. For application controls and IT-dependent controls to work continuously and undisturbed, it is important that the ITGCs have also worked effectively during a control period. The ITGCs are preconditional and test the operation of the controls over a period of time. Without a sufficient level of segregation of duties and ITGCs, it cannot be determined with reasonable certainty whether user controls or application controls have worked during the controlling period.

In the financial external audit, it is possible to deviate from relying on the ITGCs if these prove insufficient during the systems audit. Then firms can choose to use data analysis to determine whether there has been a deviation during that period, to which is referred as the data-oriented checks. If there is no deviation or unfamiliar data patterns in the sampled population of the data, it can be stated that the risk has not materialized during that period and that there is no reason to believe that a material error has occurred in that process.

In the SOx Act Section 404, there is hardly any description of the necessary controls that a company should apply, let alone IT-controls. The COBIT methodology supplements the COSO framework with a set of predefined IT-controls at different organizational levels. Depending on the company and risk analysis, the IT-controls required are implemented within a company’s ICFR framework. Below are the minimal IT-controls in an IT environment of a large company from the COBIT framework in relation to the ITGCs (ISACA, 2019) (Table 1).

Table 1 COBIT controls (ISACA, 2019)

The further implementation of the IT-controls is elaborated in work programs based on the objective and the risk. The activities to test the controls are carried out annually. The test work is performed by the IT owner or IT auditor of this program at application and infrastructure level. For the ICFR, this framework covers the risks and the company can issue a letter of representation confirming that it has prepared the financial report in accordance with the applicable reporting frameworks such as IFRS or GAAP (KPMG, 2018).

2.2 Benefits of Blockchain for Accounting

Blockchain-based financial transaction processing affects the financial landscape of the accountant. The benefits created by the use of blockchain technology specifically have the following impact on quality aspects in a financial audit:

• Integrity—The transactions are permanently encrypted in the network after they have been validated. Once this is done, the transactions cannot be changed. The transactions become “immutable” thanks to the validation and encryption.

• Availability—The transactions are replicated and distributed to all participating nodes. These “shared ledgers” are identical in every node and are continuously updated with new validated transactions. This increases the transparency and availability of transactions between companies, or within a firm.

• Continuity—An individual node that shares a ledger may fail or go down. Thanks to the decentralized nature and replication of data, the nodes in the P2P network can load the failed node with the historical data after activation. Once the node can fully participate again it can simply retrieve all historical data.

• Traceability—Each block has a hash pointer to the previous block. Because all blocks in a chain follow this principle, the entire history can be traced back to the origin of the transaction and makes it easier to audit this data.

• Reliability—The transactions cannot be changed; an audit trial makes all transactions traceable and the origin is unequivocally established. The validation of the transactions together with the above properties makes the network highly resistant to errors or fraud thanks to the consensus mechanism—the “trust protocol.”

• Efficient/effective—High volumes of transactions are quickly shared in a blockchain network without the intervention of third parties (disintermediation). Participation with a node is easy thanks to the P2P network configuration that makes the network scalable (Fig. 3).

Fig. 3

Properties vs. audit quality aspects

The shared immutable financial records prevent financial information from being misappropriated, falsified, or destroyed between trading partners or stakeholders. Keeping opaque financial records is more difficult in the blockchain. Using a blockchain agents, subsidiaries, or chain partners can share each other’s financial information to be transparent about the transactions they make. Blockchain technology can also influence the following quality dimensions of the International Financial Reporting Standards (IFRS) (Bonsón & Bednárová, 2019; Liu et al., 2019):

• Accuracy—The financial data is validated with a consensus mechanism or smart contract in the nodes before being added to the blockchain.

• Timeliness—All transactions are continuously provided with an up-to-date timestamp. Also, in the hardware layer of the network, metadata is continuously updated as time.

• Completeness—The data in a node is the complete transaction consisting of a number of required fields. The predefined fields are easy to compare and should be filled in to get the transaction validated on the network (Fuller & Markelevich, 2020).

Blockchain is regarded as a promising technology to increase trust between parties. The advantage for the accountant would be that blockchain technology improves the processing of financial records, increases the detection of material errors and reduces the risk of human error. It would enable the accountants and auditors to save on cost and time in various audit aspects (Seibold & Samman. 2016).

• Evidence—The data integrity and quality are guaranteed and therefore data-oriented control of the entire population can be done easily and quickly. This allows “continuous auditing” for the ICFR to be applied in the blockchain. The time saved ensures that there is leeway for other system-oriented audit tasks regarding the blockchain system, such as detection of fraudulent smart contracts outside the blockchain, off chain.

• Transaction Validation and Verification—The validation and verification of transactions is done by the blockchain consensus mechanism. The use of financial shared service centers (FSSC) to perform checks or make interim bookings is unnecessary, which reduces the chance of errors.

• Reconciliation—The blockchain network provides all parties with the financial records. It makes the reconciliation process more efficient and no FSSC is needed to support the creation of settlement invoices. Paper administration can be reduced thanks to the digital audit trial created in real time.

• Financial Reporting—Due to the fast automated settlement and data encryption of transactions, the blockchain facilitates the efficiency and reliability of financial reporting.

• Compliance—The blockchain smart contracts have been drawn up to digitally record agreements and have them executed if the rules are met. The digital recording makes it easier to check whether the transaction complies with the smart contract.

In contrast to such advantages in doing an audit, the blockchain also has its limitations, e.g., the processing of sensitive financial information that may not be shared publicly, off-chain applications that fraudulently interact with the blockchain, or the lack of blockchain standards complicating “trading partners” to participate. The execution of the tasks of accountants and auditors is changing as a result of this disruptive technology (Seibold & Samman, 2016).

3 Case Study: “Intercompany Settlement Blockchain”

In February 2020, KLM Royal Dutch Airlines launched the financial intercompany settlement (ICS) in a private permissioned blockchain network, in this article referred to as the corporate blockchain. This Proof of Concept (PoC) places the semi-manual process of payments between trading partners in a blockchain. This blockchain records the conditions between trading partners with a smart contract and then books the payment when these conditions are met. This PoC, which is a simplified representation of the ICS process with intercompany bookings without VAT and forecasting, optimizes making payments between trading partners. In this case study, it focuses on a payment between a parent and subsidiary whereby the subsidiary provides services to the parent company. This case study will mainly focus on the IT-controls of the intercompany settlement process and will compare these IT-controls in the “AS-IS” situation with the “TO-BE” situation in a blockchain. The data sent herein are ledger bookings with transaction data and no privacy data.

Based on data from the ERP system, for this type of intercompany payments 230–300 bookings are made per month which are processed by at least 3 employees with an average processing time of approximately 10 min per employee without their control activities.

3.1 AS-IS: “Intercompany Settlement (ICS)”

Intercompany settlements are transactions between two or more related internal legal entities where one company invoices another. Managing these transactions is one of the biggest challenges for finance departments because in many cases, financial processing takes place across different departments and systems. Prior to the financial processing, agreements are made between the various companies about the goods or services to be purchased, the price, the payment, and the administration forms. When there are unclear agreements together with a long lead time before the actual invoicing, the chances of “imbalances” in the transit account and balance differences in the “month-end closing” increase.

Below you can see a schematic representation of the payment process with an intercompany document: the actions that take place with the financial entries recorded in the Enterprise Resource Planning (ERP) application. The actions of this process are manual and consist of: creating intercompany forms, Excel sheet uploads with bookings and entering payments into the ERP. This makes the process slow and labor-intensive with a high probability of errors (Fig. 4).

Fig. 4

Intercompany settlement process AS-IS

Subsidiary B provides services to parent company A. The relevant business controller of the department from company A has made agreements with Subsidiary B. The contract contains various details, including which services will be provided at what price. In the “AS-IS” method, eight steps are required for the settlement of the payment between company A and B, carried out by different persons (Table 2).

Table 2 Steps in AS-IS intercompany settlement process

In this process there are two Accounting Houses involved and multiple business controllers from different departments of Company A. Each business controller handles his own domain with specific attributes such as cost centers, general ledger accounts, intercompany document numbers, etc.

3.2 TO BE: “Intercompany Settlement Blockchain”

The blockchain configuration uses a smart contract for validation of transactions in this financial ICS process. In the AS-IS situation, the validation of the transaction is done manually. In the intercompany blockchain, manual tasks are minimal (Fig. 5) (Table 3).

Fig. 5

Intercompany settlement process TO-BE

Table 3 Handling in TO-BE blockchain-based intercompany settlement process

This ICS process starts with the one-time configuration of a smart contract between two trading parties. Company A checks the smart contract of Subsidiary B and accepts it or vice versa (Steps 1–3.) After that, all transactions from Subsidiary B are checked against the smart contract and no longer by the Accounting Houses. A total of three steps are performed once creating a smart contract, after that all entries are made automatically (Steps 4 and 5).

Before elaborating further on the IT-controls, this paragraph starts by elucidating the architecture of this customized corporate blockchain. In this case study, the network configuration is set up with a so-called “notary node,” which is the node in the network that stores and activates the smart contracts. Company A and Subsidiary B are present in the network with their own network “node.” After validation and execution of the smart contract, only the bookings are made to their ledgers. This is different in a “public permissionless” network such as bitcoin blockchain. In that type of blockchain, everyone receives a copy which is not the case in this corporate blockchain. Node-to-Node is the consensus mechanism that makes this possible and is a bilateral consensus mechanism between the nodes. It does not need an energy-consuming intermediary as miners or stakes for consensus. This makes it possible for this blockchain network to send the payments to the parties involved as agreed in the smart contract. Each smart contract can be drawn up by parties other than A and B. Companies B and D can make mutual agreements and include this in their smart contract. In this case, only B and D get the bookings but with the same attributes as cost center, GL accounts, type of activity, intercompany form number, etc. A new company can sign up and have a node configured and make agreements as a “trading partner” with all other nodes, “trading partners,” in the blockchain network. This makes this blockchain scalable (Seibold & Samman, 2016) (Fig. 6).

Fig. 6

Corporate blockchain node architecture

One of the risks with blockchain applications is the integration with off-chain applications. The challenge is that both technologies function differently and are configured different. This is solved by an ERP node that ensures that all bookings are sent to the ERP system at once in the correct format. The ERP node facilitates the “transit” bookings to the Parent A Holding and Parent A Department (account 190000) that are necessary for processing the transactions in the ERP system. This guarantees the integration with backend ERP systems. This node and the “notary node” are the technical nodes that take care of the validation and handling of the transactions. The figure below (Fig. 7) shows a snapshot of the financial transactional data interfaced to the ERP backend system.

Fig. 7

Output flat file from the interface between ERP node and ERP backend

The total booking is interfaced in real time and the transactions are grouped. These transaction entries have been validated against the smart contract #23569 in the notary node and enriched with the intercompany transit account 190000 in the ERP node. The end state forms a zero-balanced account for the involved nodes: notary, ERP, A and B, each having this total booking recorded in their node.

3.3 IT-Controls: “AS-IS Control Environment”

This case study includes several stakeholders. Together they form the “control environment.” The risks that hinder the achievement of the goal are mitigated with controls. In this case study, the three categories are:

• 1. Entity Level Controls (ELC)

  Entity level controls are the controls on the basic structures on which the organization rests. This varies from risk matrices to management guidelines. In this case study, entity level control is the entire chain of companies and departments that do business with each other. In this example, the relationship between company A and company B is a parent-subsidiary relationship. The control environment of the “period-end closing cycle” is carried out according to the same accounting principles and procedures for both companies. In this case study, we only name the IT-related ELCs and their relationship to ITGCs.

• 2. Transaction Level Controls (TLC)

  This control, “Business-IT,” focuses mainly on the transactions that take place within the ERP. It also looks at the interfaces between systems and the interactions between departments. Within this process, financial employees carry out transaction entries in the ERP system. To ensure the transactions, the following “controls” can be distinguished:

  • (a) Manual controls

    For example, check whether the transaction input is correct with the intercompany document.

  • (b) IT-dependent manual controls

    For example, comparing extracts from ERP tables with financial data with each other, checking whether the suspense accounts are “zero-balanced.”

  • (c) IT application controls

    For example, restriction on booking on certain balance sheet items or computerized entries.

• 3. IT general controls (ITGC)

  All IT aspects that have an impact on IT processes and IT technical matters are safeguarded by ITGCs. The processing in the IT landscape is thus controlled. They can be divided into manual controls, emptying flooded server buffers, and application controls, restrictions when logging in. It concerns IT-related matters such as IT processes and IT technology in operating systems and databases and not directly about the end-user interaction as with transaction level controls.

These TLCs are included in a work program and this control is carried out by a control employee checking the clearing of the transit accounts within the ERP application. The entity level controls are relatively general and generic compared to the transaction level controls. The ITGC for financial reporting has been elaborated in detailed control documents and is derived from COBIT 5-“IT-control Objectives for Sarbanes-Oxley” of ISACA (2014). In this framework, the risks, control objective, the owners, the audit trail/evidence and which tests need to be executed are documented in control matrices. In this case study, the focus will be on IT-controls.

3.4 Objective and Risks: “Top-Down”

The goal of this intercompany settlement process is to efficiently and effectively process financial transactions and ensure the reliability of financial reports. The risks of an intercompany process are present at different control levels. The different entities may have their own vision on ICFR control tasks and their implementation. At the process level, the employees may be tempted or instructed to book away the differences on the transit balance sheets. Detecting unwanted actions takes time because of the manual and IT-dependent checks. The IT-control objectives are present on all control levels and apply to the central financial ERP system and its surroundings and are described in Table 4 below.

Table 4 Risks and control objectives AS-IS

3.5 Objective and Risks: “ICS Blockchain”

The purpose of the intercompany settlement process in a corporate blockchain remains unchanged; the real-time transaction processing and encryption contribute to an improvement of the efficient and effective processing of transaction data and the integrity of the financial data. Transparency has increased thanks to “shared ledgers.” In the current situation, the financial ERP is leading in financial accountability. With differences in the blockchain “shared ledgers,” the risk is that an entity can claim to have the financial “single source of truth.” The smart contract can offer a solution in case of a difference, but parties can create and delete fraudulent smart contracts. The changing risks have an impact on the IT-control objectives and are described in Table 5 below.

Table 5 Risks and control objectives ICS blockchain

The risks described above assumes that the nodes run on decentralized data centers. As can be observed in the entity level of Tables 6 and 7, the ITGC control in the blockchain takes place at a “corporate level” instead of only application or system level. A blockchain is a network and therefore demands a need of collaboration between blockchain parties when they decide to deploy changes on the network. In a consortium with blockchain participants, agreements will be made about these vital network components, which can impact the integrity and confidentiality of the blockchain network. The “AS-IS and TO-BE” Intercompany settlement objectives, efficient and effective processing of transaction data and the integrity of the financial data, remain the same in both situations. The risks and control objectives change. The existing risks are identified to secure a central ERP application. The new risks are based on a blockchain network and are having direct impact on the IT-controls on all levels.

Table 6 AS-IS entity level controls

Table 7 TO-BE entity level controls

3.6 Entity Level Controls: “Corporate Level”

Within the business units the ELCs are translated into for example “segregation of duties” in which the control activities are separated from the payment activities. In this case study, there are five legal entities: companies A and B, accounting houses 1 and 2, and the (IT) division where the applications are managed. Each entity organizes separately in its organization the control environment, risk assessment, control activities, and monitoring. These are periodically controlled by the control department in the Holding (Table 6).

In this intercompany settlement process, companies A and B are the owners of the financial data but have separate administration. The accounting standards are the mutually agreed international standards. The IT landscape is centrally set up and all entities use the same ERP system, single source of truth. The individual entities are linked to the IT business unit with the central ERP system. The ELC-IT Governance is mainly done within this unit. Without IT Governance, there is a risk that each entity will create its own access to the central ERP system, which can lead to insecure accesses. Within the entities, they ensure that the entities have met the access standards before granting them access to the central data center where the ERP system is located. The IT Business unit is responsible for the entire ERP IT configuration, they organize this with an internal IT-controls framework.

3.7 Blockchain and ELC: “IT-Control Environment”

In this case study the entities are a virtual representation, a full node. A full node has its own operating system, database, and network configuration. Each node has a specific task, which creates a virtual segregation of duties. The notary node validates the transaction, the ERP node books it in the off-chain application, and the other nodes distribute the bookings among themselves. Every entity in the blockchain network owns the distributed financial data. In the corporate blockchain, the emphasis of control at ELC level is in the “IT-control environment” (See green area Figs. 5 and 6) and less in the separate entities. The technical integration of the entities results in this IT-control environment in which control activities and monitoring are needed to mitigate the new risks (Table 7).

The disintermediation property of the blockchain makes the accounting houses obsolete in the ICS process. The remaining entities will need to discuss common IT topics such as: encryption, consensus protocols, smart contracts, and access security in a consortium meeting which will be IT-related ELCs. The entities are now part of and have access to a blockchain network. This makes all IT General Controls such as manage IT configuration and Access security, ELC topics that need to be discussed on an entity level.

3.8 Transaction Level Controls: “IT-Dependent Controls”

The audit work is carried out in the financial department by an internal control employee using a control work program. It defines some 25 audit topics, ranging from negative credit account entries to IFRS16 special accounts. The TLC that are applicable for this case study is the control of the “transit/in between” balance items. This is to prevent an intercompany invoice from stranding on a transit account or landing on a wrong account. The total number of trading partners with a similar intercompany invoice are in total 31. In this case study we only discuss the audit procedures of 1 “trading partner” Subsidiary B (Fig. 8).

Fig. 8

Intercompany settlement control steps AS-IS

Due to the many manual actions in this ICS process, the risk that mistakes are made can be high. The checks are done based on extracts from the ERP system, IT-dependent control, with the support of self-created Excel sheet macros. These are done on top of the user manual checks that take place daily and monthly. This check is done based on attributes: Trading partner, balance sheet item, date, intercompany document number, and amount. A total of five control steps are performed by eight persons. At process level there are seven types of TLC controls. The “evidence” can differ from downloads from databases, comparisons in excel sheets and paper administration (Table 8).

Table 8 AS-IS transaction level controls

3.9 Blockchain and Transaction Level Controls: “IT-Dependent Controls”

The manual controls in the intercompany process become application controls in the corporate blockchain. The entire intercompany ICS process is carried out automatically in a blockchain (Table 9).

Table 9 TO-BE transaction level controls

At the process level, the impact is large and the blockchain contributes to efficient and effective processing of Intercompany settlement invoices. All manual and IT-dependent controls are overtaken by a total of nine application controls. The transactions are verified and validated against the smart contract in which the agreements between a “buyer” and “seller” are digitally recorded. This digital process optimization eliminates the involvement of accounting houses in the ICS process and their controls are totally automated.

3.10 IT General Controls: “IT in Control”

The IT-controls framework can be traced back to some 23 IT-controls that relate to this case study where the entire spectrum of ITGCs is covered. The ITGCs apply to the ERP application. The goal is to guarantee the Confidentiality, Integrity, Availability of this financial application and this is done along two axes: by sufficiently controlling IT processes, applications, and infrastructure and by continuing to comply with internal and external laws and regulations for the purpose of ICFR. Below are the ITGCs further elaborated with IT-control activities and evidence with a reference to the risk in Table 10.

Table 10 AS-IS IT General controls (for associated risks R, refer to Table 4)

3.11 Blockchain and IT General Controls: “IT-Controls”

The full nodes with financial data in the network form an IT-control environment that requires more ITGC coordination between parties. For example, change management will have an impact on multiple nodes in the network and affect multiple trading partners. A centrally coordinated change management in this IT-control environment is needed to control the impact on partner nodes. The specific blockchain items will be added to the IT-control framework to mitigate the new blockchain specific risks. (See risks R1, R2, etc. in Table 11.) In the table below, the change of the controls are described with a reference to Table 10. (See also Appendix TO-BE framework)

Table 11 TO-BE IT General controls (for associated risks R, refer to Table 5)

This case study demonstrates that the number of IT-controls within the ITGC are changing. In addition it shows, the need of a consortium discussing the network components centrally. Both changes are a consequence of the changing risk profile as described in Sects. 3.4 and 3.5.

4 Analysis: “IT-Control Change”

The blockchain is a new kind of IT network that can exchange value in addition to information. The semi-manual intercompany settlement (ICS) process is automated by employing the blockchain. This process and its control environment has been transformed into an IT environment. On the blockchain, financial business data is encrypted, validated and distributed. Risks of material errors in the blockchain lie in the mechanisms used such as smart contracts and the key pairs that provide the validation and security of the business data. An important implication of using blockchain is that the immediate risk of errors and fraud on business data has shifted to manipulation of these blockchain components which controls the business data. The new IT-control objectives therefore change with the focus on the vital blockchain components as described in the case study. In this analysis, we will further elaborate on the case study in activities performed on a process level and on an IT level.

4.1 Process Level Controls

The intercompany settlement process is optimized by the corporate blockchain for one ICS process with one subsidiary in this case study. Due to the disintermediation of the accounting houses, there are fewer manual invoicing and controls. The optimization can be seen in the control steps and in the transaction level controls (see Figs. 9 and 10).

Fig. 9

Intercompany process steps

Fig. 10

Intercompany control steps

The total number of process steps has decreased from eight in the AS-IS situation, to four in the new TO-BE situation. The one-time drafting of the smart contract consists of three steps and leads to the fact that the continuous steps, or daily back-office work, are reduced from eight to one step. The trading partner regularly executes the trade(s) and after validation with the smart contract, all bookings are automatically settled in “real time.” As such less manual administrative activities are required, resulting in a faster throughput of the transactions from the seller and buyer.The control steps in the ICS process have decreased and are carried out by fewer persons. In the new TO-BE situation the only control step is the drafting and digital acceptance, after verification, of the smart contract by the “trading partners.” Labor-intensive controls that take place in the ICS process are reduced to one thanks to the corporate blockchain. This results in lesser control administration pressure on the ICS process.

In more detail in Fig. 11, we see that the AS-IS control process consists of a total of seven controls across different departments ranging from manual, IT-dependent, and application controls. These controls are carried out daily or monthly by the various accounting houses.

Fig. 11

AS-IS transaction level controls

In the TO-BE blockchain situation (depicted in Fig. 12), all transaction controls in this ICS process become application controls. The total, nine application controls, consist of the seven “automated” AS-IS controls, plus the two controls for drawing up and accepting the smart contract. Due to the effective and efficient reconciliation, the manual and IT-dependent controls from the internal control work program became obsolete and all entries are zero-balanced. In total there are about 31 similar intercompany settlement flows. The manual and IT-dependent transit account checks of the 31 ICS flows are shifting to application controls thanks to the corporate blockchain. The internal control at process level of transaction level controls are improved by reducing manual controls, facilitating fast reconciliation and creating real-time reporting.

Fig. 12

TO-BE transaction level controls

4.2 IT Level Controls

Participants in the blockchain network own a full node with the shared financial data, which adds extra complexity to the control. The emphasis will be on collaboration and central coordination when it comes to IT-control to mitigate the internal, external as well as blockchain specific vulnerabilities across the entire network. Figure 13 depicts a comparison between the entity level controls in the old AS-IS situation and the new TO-BE situation.

Fig. 13

IT entity level controls

The increase in ELCs despite the disappearance of the accounting houses can be explained by IT consortium consultations. The purpose of these consortia is to keep control over the private blockchain network. The common configuration items and multiple participants make it necessary to inform each other about their technical status of their blockchain node. With regard to the number of ITGCs, there is no difference with or without a corporate blockchain (see Fig. 14). Only the IT-controls, at ITGC level, are increasing in numbers and are an addition to the ITGC (see Fig. 15). The ITGCs also require control over the entire network in a consortium on corporate ELC level, because the financial data is not only secured and stored in an “on premise” application, database, and server stack but can be operating on separate data centers making the financial data decentralized. The elaboration per ITGC on IT-controls is shown in Fig. 15. Most ITGCs have an increase on IT-controls. Only Backup and Recovery and computer Operations show a decrease or limited change in their IT-controls. The decrease in Backup and Recovery can be explained by the fact that the notary node and the ERP node are each other’s backup. From the ledgers of the other nodes the Notary node and ERP node can be replicated or vice versa. The limited increase in Computer operations has to do with the real-time transaction processing feature in the blockchain. Job scheduling of external triggers become unnecessary. The explanation for the high increase in the number of IT-controls for Logical Access Security is the access to the blockchain nodes from various locations and the API connectors to the blockchain. Also, security of blockchain critical assets like key pairs and smart contracts desire new advanced IT security controls. Change management, system development, and life cycle management have a profound impact on the entire network with additional IT-controls on forking, and the source code of consensus mechanisms.

Fig. 14

IT General Controls (ITGC)

Fig. 15

IT-controls per ITGC

By placing the intercompany settlement process in a corporate blockchain, a change is taking place in the ICFR-COBIT IT-controls framework. The corporate blockchain automates its intercompany settlement control environment. The effective and efficient processing of transactions and assurance of the integrity of financial data are technically integrated into a financial blockchain network. The reduction of manual and IT-dependent controls by application controls is visible in the numbers in Fig. 11 in Fig. 12.

At the process level, the segregation of duties of the accounting houses are embedded in the blockchain by the separate nodes. A new risk at this level is drawing up fraudulent smart contracts through the conspiracy of the “trading partners.” It is therefore necessary that at process level a preventive control is designed to ensure the mitigation of this risk. At the IT level segregation of duties together with the ITGCs are preconditions for the proper functioning of the application controls during the control period. At this level it becomes necessary that logging on unwanted adjustments to smart contracts is available, either on the code or by deactivating the smart contract. This is a necessary IT-control to detect fraudulent smart contract.

4.3 Process Level: “Application Level”

The blockchain process optimization of the intercompany settlement (ICS) process has a direct impact on the transaction level controls, manual and IT dependent. The verification and validation of transactions are done by a smart contract. Reconciliation of ledgers then takes place “instantly,” the reports are immediately available, and incorrect bookings are rejected thanks to the smart contract. The completeness, timeliness, and accuracy of transactions is covered by the blockchain partly due to the real-time settlement with a timestamp. This digital process optimization eliminates the control task “check transit/interim accounts for imbalances” for some 31 ICS flows.

4.4 IT Level: “Corporate Level”

The intercompany settlement (ICS) process is automated and each participant has their own node with the same financial data. The ICFR internal control measures for the ICS process are focused on a central financial ERP application running on an “on premise” data center. Most of the AS-IS IT-controls of this financial ERP application remains intact in a financial blockchain network. In this case, the IT-controls for the ITGCs, backup and recovery decreases and computer operations there is a small increase. The other ITGCs have an increase of IT-controls because of the new risks and blockchain critical configuration items. The automation of the ICS process further shifts IT-control monitoring to a corporate level due to the control over distributed databases on different data centers. A further shift from ELCs and ITGCs to corporate level becomes necessary due to the collaboration aspects of a blockchain network.

4.5 The External Auditor: “Controls”

At the process level, the blockchain audit trail together with the application controls provides validated and encrypted financial data on which substantive checks can be carried out, on the entire population, to discover deviations in patterns. The evidence is easy to extract from a node with a sample and a search on a smart contract ID provides a complete audit trail. The data-oriented control of blockchain data in an external audit can be done relatively quickly and in less hours. In this case study, a data-oriented control of the blockchain data compared to the off-chain ERP system data would be a relevant data-oriented control. The system-oriented control will focus on the critical aspects around and partly in the blockchain at the IT level. The IT-controls at ITGC level play a major role because of the distributed databases with “shared ledgers.” The essential notary node and ERP node have a major impact on the integrity of the data and the efficiency and effectiveness of the operation of transactions. These deserve extra attention in the system-oriented controls.

5 Conclusions

We conclude from the case study that a “corporate blockchain” for the intercompany settlement (ICS) process digitally optimizes and thus automates the mutual cooperation between companies. Potential new risks that are introduced by a corporate blockchain depend on the use case and the design of this Distributed Ledger Technology (DLT) solution. Some technical risks such as encryption cracking, failing consensus mechanisms, failing nodes, and hacked smart contracts exist on all blockchains.

The case study presented in this chapter demonstrates that the frequently cited risks associated with a blockchain, such as transaction fees, data block size, transaction processing time, and power consumption in consensus mechanisms, do not apply to all DLTs. These are more likely to occur on a public blockchain due to its consensus mechanisms. In this corporate blockchain, these risks are minimal or non-existent because of another type of consensus mechanism, the Node-to-Node (N2N). In this case study the new risks are located around the corporate blockchain and not directly within the blockchain data, because blockchain data is validated, immutable, verifiable and including audit trail. The new risks are the technical risks such as stolen encryption key pairs, interoperability and interaction with off-chain applications and relate to blockchain components that guarantee the integrity of the data.

The advantage of the corporate blockchain is that data quality and security is supported by this technology. The benefits for the auditor such as evidence, transaction validation and verification, reconciliation, real-time reporting, and “smart contract” compliance are increasing, as is the transparency of the transactions at the process level. The data is shared with different nodes which makes obtaining, verifying, and validating of evidence by sampling easier. The blockchain data makes continuous auditing possible and provides proper quality conditions for data-oriented auditing and foresees in correct, complete, and timely data, see the audit trail in Sect. 3.2, Fig. 7.

The objective effective, efficient, and reliable processing of transactions in the ICS process remains the same in the AS-IS and the TO-BE “corporate blockchain” situation. As demonstrated in the case study, the corporate blockchain turns manual administration and control tasks into application controls on process level with the potential of facilitating back-office employees with data-driven administrative control tooling. At IT level the risks associated with encryption, consensus mechanisms, and/or node governance in a decentralized network requires further enhancements of the ICFR with blockchain-related IT-controls. The risks affecting vital blockchain components require coordination at the corporate level from an IT perspective as the risk effects all the nodes in the network. This makes it necessary to make agreements in a consortium on joint topics such as interoperability, trusted third parties and ICFR audit procedures. The complexity in the management and design of IT-controls is increasing because of the decentral nature and the multitude of participants in this automated and therefore “IT-control environment.” The case study shows that ITGCs need to be done on corporate level instead of the usual application and system level. The segregation of duties and the ITGCs need to ensure the proper functioning of the increased application controls in the whole network during the control period.

The amount of test work depends on the decisions made in the consortium and the design of IT-controls, either through agreements between participants or through further automation of controls in the IT-control environment. Options are central IT policy on on- and off-chain components or the configuration of administrator nodes. The ultimate impact on the ICFR and the systems- and data-oriented audit work program depends on this.

The starting point for an Internal Control over Financial Reporting (ICFR) adjustment or external audit when confronted with a financial blockchain system begins with determining the use case, the chosen DLT platform provider, the type of blockchain, the type of consensus mechanism, and the infrastructure. In the preparation phase of your audit, these are the topics to take into account due to the impact on the audit scope and expected IT knowledge when performing the control tasks. Based on this research, a pattern emerges in the ICFR, IT controls. With a corporate blockchain you can observe following patterns in the ICFR:

• 1. At the entity level, the extensive network automation ensures that an IT-control environment is created between different trading partners and separate legal entities. This leads to more central coordination of IT topics on a corporate level to provide conditions and supervision on the blockchain network.

• 2. At the transaction level, the manual and IT-dependent controls are replaced by application controls. The process optimization ensures disintermediation reducing manual administrative tasks.

• 3. A corporate blockchain has big impact on ITGCs. The ITGCs shift to entity level. These require a coordinated approach due to the IT technical control over the entire blockchain network instead of a central application.

Figure 16 depicts the changes in controls on the different levels with the dashed lines. This pattern relates to a DLT, corporate blockchain. It is likely that the same pattern also applies to other blockchain systems with some nuances in IT-controls. This is based on the literature review and the case study. Further research will have to show whether this pattern applies to multiple blockchain solutions.

Fig. 16

Overview of the impact of blockchain technology on ICFR

Appendix: Framework TO-BE Corporate Blockchain

Risk	(IT) control objective	(IT) controls
Entity level controls
The entities, full nodes, receive incorrect or no information from partner nodes.	– Securing segregation of duties of the nodes. – Centrally coordinated audit work for the ITGCs for all nodes.
Transaction level controls
Drafting and executing fraudulent smart contracts and collusion.	More eyes principle when drawing up a smart contract.	One-time check when drafting a smart contract. The former manual and IT-dependent controls have been replaced with application controls
IT General Controls (ITGC)
R1. User access (authorization) and devices (API) to smart contracts and key pairs can indirectly compromise business data on confidentiality and integrity.	– Securing access to the critical components of the blockchain in such a way that unauthorized access is impossible and to prevent unauthorized permission to validate or broadcast transactions. – Provisioning of administrator nodes.	1. All facets that have to do with login authentication: user ID, session time, passwords are stored encrypted, password length and renewal, number of login attempts, etc. 2. Access of privileged accounts for maintenance. Granting the account, its duration, and its revocation. 3. Having local admin rights to install things on your PC or server. 4. Monitoring access of privileged account by logging of activities (change log) done in the application, database, or server.
	Logical access security (consortium)	The abovementioned AS-IS existing controls 1–4 will continue to apply. The emphasis will be on mutual agreements and cooperation of participants in the blockchain when it comes to IT access and permission management.
		1. Consortium with administrator nodes that control access to the blockchain. 2. Monitoring on API connectors with the blockchain. 3. Setting up permission management to check transactions: “validate or write” and who can “broadcast” 4. Access to critical components such as smart contract, key pairs, and consensus protocols.
R2. Suppliers do not facilitate sufficient certainty of their systems and knowledge of blockchain implementations – Not being able to connect with other blockchains. – Upgrading the network is too complex to perform.	– Suppliers must comply with laws and regulations and certifications and have suitable blockchain knowledge and skills in-house. – The blockchain can easily interact with off-chain applications and other blockchains, interoperability. – LCM with a hard fork procedure	1. Purchase of IT hardware and software, cloud applications, and IT contract management. Issues such as security, certification, and financial maturity of the supplier are considered. 2. IT development street, Development, Test, Acceptance, Production (OTAP) in separate environments. 3. Service management, taking care of the IT solution based on acceptance criteria. usability, availability, security, and continuity.
	System development and life cycle (consortium)	The abovementioned AS-IS existing controls 1–3 will continue to apply. The cooperation aspects of joint IT topics require mutual agreements about standards and the recruitment of skilled suppliers.
		1. Consortium on mastery of source code, encryption, data storage capacity, interoperability, and supplier selection 2. Setting up data migration strategy—replication from the old to the new nodes (see also backup and recovery) 3. Life Cycle Management strategy with a (hard) fork upgrade procedure.
R3. Changes in a blockchain that have a negative impact on partner nodes and other critical network components.	– Changes are centrally authorized and properly tested in consultation with other blockchain participants. – Changes to the data are “append only.”	1. Changes in the production environment on hardware, software, interfaces, or network are recorded, documented as executed. 2. Urgent changes as a result of incidents that have a high business impact due to an error or bug in the IT service.
	Change management (consortium)	The abovementioned AS-IS existing controls 1 and 2 continue to apply. The changes relate to the network and will be centrally regulated and monitored.
		1. Impact analyses on critical components such as smart contract, encryption, and consensus mechanisms. 2. Data changes or smart contract changes “append-only” functionality only correction bookings allowed no change of transaction data. 3. Monitoring for changes in off-chain applications.
R4. The confidentiality and integrity of business data have been compromised by theft of keypairs, code modification in smart contracts, hijacking of a node and making “malicious” changes to the consensus mechanism.	– The blockchain, various nodes and related systems are sufficiently protected against unauthorized access and against stealing, modifying, or damaging smart contracts, keypairs, consensus mechanisms or hijacking of nodes. – The blockchain has detection logging especially on the vital network components.	1. Security violations are detected in the IT service and reported to IT departments that ensure appropriate action. 2. Up-to-date anti-virus software. 3. Vulnerabilities are regularly scanned for the different layers and threats are immediately reported to the responsible IT department who take corrective action. 4. The version of the operating and database management systems are regularly updated with the latest security updates for that version. 5. Known security vulnerabilities should be checked and appropriate action taken. 6. High impact security updates are registered, evaluated, and tested before they are installed on the IT services in a planned service window. 7. Security patches on the software and hardware should be checked and installed and monitored to be up to date.
	Security (ELC)	The abovementioned AS-IS existing controls 1 and 7 continue to apply and cover the entire blockchain network. The security consortium will ensure that the security and protection of the entire network remains controlled.
		Security consortium 1. Node governance and security 2. Key ownership and management 3. Protection of critical digital assets: smart contracts and consensus mechanisms.
R5. Damage to nodes and business data that can no longer be repaired.	The entire business data can be quickly replicated from the partner nodes that are unaffected.	1. Backup of software and data are regularly backed up. The critical database information is roll back enabled. 2. Recovery Time Objective and Recovery Point Objectives are configured in the architecture. 3. Periodic test of the backup and recovery scenarios and process works.
	Backup and recovery (ELC)	The abovementioned AS-IS existing controls 1–3 are immediately affected and are obsolete due to the redundancy of data in a blockchain network. The ITGC’s system development and security, node governance, capture part of this ITGC. System development when it comes to the data migration and node governance location of the nodes that are not affected by a “disaster.”
		1. Consortium backup and recovery procedures. 2. Speed of reactivation of a node and the synchronization of data to affected partner node.
R6. The efficiency and effectiveness of transaction processing are hampered by changes in software and hardware configuration items. The scalability cannot be achieved.	– Secure oracles with off-chain applications and other blockchains or smart contracts. – Node scale-up procedures/standards. – Fast network communication of central and decentralized network components.	1. Access to job scheduling tooling and applications 2. The baseline settings for the infrastructure are checked, based on the best practices of the hardware and checked after corrections to the software. 3. Data base management system (DBMS) and monitoring. Servicing the database, e.g., cleaning repositories or analyzing system loggings. This is done based on privileged account, actions are logged. 4. Maintenance on the IT application, database, network, or server are monitored with procedures and logging.
	Computer operations	The abovementioned AS-IS existing control 1 will be obsolete, 2 will be overtaken in ITGC change management. Controls 3 and 4 will continue to exist but will be arranged centrally because the work has an impact on the entire network.
		1. Consensus mechanism maintenance. 2. Integration and interfacing of data with off-chain applications 3. Control of node scalability