You are currently browsing the monthly archive for July 2016.

The blockchain distributed database was invented to create the peer-to-peer digital cash called bitcoin in 2008. Although the future potential of bitcoin and other cryptocurrencies has been debated, the distributed ledger structure using a blockchain database that supports bitcoin is likely to be adopted for a range of commercial and governmental purposes. Distributed ledgers are a secure and transparent way to digitally track the ownership of assets while enabling faster transaction speeds and reducing potential for fraud. How quickly companies, governments and individuals start using distributed ledgers and for what specific purposes remain to be seen, but their use will be independent of cryptocurrencies’ fortunes. Expansion in the use of distributed ledgers will depend heavily on the success of the initial applications and whether there are major hiccups in their use.

To the extent that people have even heard of distributed ledgers, most associate the technology with bitcoin or some sort of payment system. However, it can do more than that. The technology can complement and enhance a variety of enterprise applications, facilitate commercial transactions of all types and provide governments with the ability to streamline interactions with the public.

Here’s a summary of the technologies involved: A distributed ledger is a shared database of assets and their owners located on multiple nodes (sites) on a network. All nodes have an identical copy of the ledger, and any changes to the ledger are incorporated rapidly (at a maximum within minutes; ideally within seconds) in all copies. Distributed ledgers’ distinct value is their ability to securely identify ownership of any form of asset – physical, financial, legal or virtual – and faithfully record all transactions involving these assets. The security of the validity and dependability of the distributed ledger depend on several factors: its blockchain construction, decentralized ownership of identical copies of a ledger, the use of public key encryption of the entries in the database and the use of digital signatures for access control. An important advantage of it lies in moving much of the complexity of managing security onto the structure of the system itself, making such systems easier and less expensive to manage and use than conventional on-premises and cloud-based applications.

Blockchain algorithms enable transactions to be aggregated in blocks that are added sequentially to a chain of existing blocks using a cryptographic signature. A transaction may be, for example, the sale and purchase of an asset or the addition of a health record or a patent filing.

When someone wants to add to the database, each owner of the distributed ledger runs a set of algorithms to evaluate and then verify the proposed transaction. If a consensus (usually a majority of participants) agrees that the transaction looks valid – that is, the identifying information matches the blockchain’s history – then the new transaction will be approved and a new block added to the chain in that ledger. If the participants deciding on the validity of the transactions are preselected, the ledger is said to be “permissioned.” If the process is open to everyone (like bitcoin), the ledger is “unpermissioned.” The advantage of an unpermissioned ledger is that it evades control by authorities. This may be to achieve ethical objectives (for instance, overcoming censorship or theft by autocratic or kleptocratic governments) or for nefarious purposes (money laundering or trade in contraband). Permissioned ledgers can have an advantage if managed by actors (such as self-regulated commercial body or governments) that have the trust of the participants. Permissioned blockchains provide highly verifiable data sets because the consensus process creates a digital signature visible to all parties.

The cryptographic signature using public key encryption can provide individual privacy while validating the identity of the individual making the change. Already in wide use public key encryption enables anyone to encrypt a message using the public key of the receiver, but such a message can be decrypted only with the receiver’s private key. Public key encryption is often compared to a locked mail box with a mail slot. The mail slot is accessible to the public, and its location – the street address – is the public key. Anyone can drop a message through the slot, but only the individual who has the private key can open the mailbox and read the message.

The blockchain structure provides a permanent audit trail since no records can be deleted without collusion on a massive scale. Distributed mirrored databases substantially reduce the ability of anyone to tamper with data since each instance would have to be altered in an identical fashion almost simultaneously. A cryptographic hash function provides a fast and highly efficient means of detecting if a blockchain has been tampered with and for assuring the integrity of transmitted data. That said, distributed ledgers are not invulnerable to attack. Anyone who can find a way to modify one copy legitimately might be able to modify all copies of the ledger. This will happen if systems can be compromised through, for example, phishing or pretexting.

How a given distributed ledger is controlled can vary. Although the ledgers are distributed, there can be varying degrees of centralized control to suit the specific purpose of the ledger. Unpermissioned ledgers (such as bitcoin) are not owned by any individual or entity and anyone can contribute data to the ledger. At the other end of the spectrum, permissioned ledgers may have one or many owners and only they can determine who can add records and verify the contents of the ledger. In practice, the latter can only be considered a distributed ledger (in the definition I’m using) if the number of owners and their independence are sufficient to ensure that the possibility of successful collusion to alter the database is sufficiently low to achieve public confidence. I’ll leave it to others to decide for themselves if a distributed ledger organized and controlled solely by a single organization such as the financial network SWIFT should be regarded as a “true” distributed ledger. By my definition it is. It’s likely that some existing single-entity controlled networks (such as those that manage supply chains) will adopt the distributed ledger structure for all or part of their operations to provide new services or to modify their existing architecture to reduce costs, enhance performance or gain flexibility.

There is no shortage of potential uses of distributed ledgers. There are so many that they – and the underlying blockchain methodology – can appear to be another example of a new technology in search of a mission. Distributed ledgers are not an application but a facility that can support application functions. They can, for example, record the basics of a transaction (such as the details of the item that has been exchanged and the corresponding payment) or serve to signal events (such as accepting a shipment).

Distributed ledgers could serve as a secure platform for all forms of contracts; potentially they could make it easier to enforce contracts of all types in parts of the world where the rule of law is weak because the platform could ban all participants that renege. Distributed ledgers also could be used in settling securities trades of all types – this is more of an evolutionary improvement over today’s systems. In concept, a distributed ledger could cut reconciliation costs by more fully automating the trade settlement process and substantially improving the quality of data, as well as enabling financial institutions to make more efficient use of collateral and regulatory capital by limiting the volume of trades in limbo because they failed to settle.

In commerce, distributed ledgers have the potential to substantially enhance visibility in multitier supply chains and multistep distribution, increase traceability of materials and combat drug counterfeiting. They can provide accurate and immediate customer records or immediately reflect changes to the properties in product life-cycle management and product information management. Networks for connecting members of a value chain have been difficult to establish because typically they have been set up by one of the major players. Competitors of that major player cannot (will not) participate in that network, blunting its effectiveness and leading to network fragmentation. Distributed ledgers might be less prone to this defect because they provide a secure, auditable mechanism for data capture and exchange that can complement but not replace the functionality of a value-added network. Companies therefore would be able to operate on different value-added networks that all use the same transaction data.

In the public sector there are many ways in which governments can use distributed ledgers including property record-keeping, healthcare data, a digital notary system, recording government contracts and handling tax and other payments.

Despite these potential uses it’s not clear how quickly distributed ledgers will gain traction and profitability in the commercial realm. In developed economies, there already are many trusted networks and methods for transacting business governed by commercial codes. Ultimately they may adopt a distributed ledger structure because it’s superior to the technology they are currently using in terms of speed and robustness. Some observers estimate that banks collectively could save billions of dollars in IT infrastructure costs by employing them for payments across borders, securities trading and regulatory compliance. Beyond savings, the desire to improve service or the threat of competition from an upstart will drive the process. There are many opportunities to create permissionless networks in less developed economies, but it may be difficult to make them more than marginally profitable initially until some combination is achieved of their networks becoming large enough and their costs getting small enough.

Much work still needs to be done to make distributed ledgers a reality. One serious issue for distributed ledgers is the large amounts of computing (and electrical) power required to make them work. Another issue to be addressed is auditing. Accountants will need to be able to audit records on permissioned ledgers. Then, too, there is the matter of governance structures. This is less of an issue in largely free-market jurisdictions with solid rules of law. Rules established by the owners and participants of a ledger that safeguard their private interests must be supported by legislation and regulation consistent with existing commercial codes. In turn legislation and regulation must balance public and private interests without being so rigid as to stifle innovation and growth.

For the time being, it’s not clear that distributed ledgers will displace trusted networks such as those offered by ERP vendors because it won’t have the functionality and process control that are part of those products. Those running trusted networks probably will not be in a hurry to open up their management to others since all have some value associated with being in charge. And the security issues that SWIFT has encountered (hackers managed to steal $US 81 million from Bangladesh’s central bank) would not have been prevented through the use of blockchain. It’s likely that there are scores of opportunities to create blockchain networks that are economically workable, but it’s not clear how soon these will become economically significant.

I’ll leave it to others to comment on the future of cryptocurrencies. I’m fairly certain that their impact on the adoption of blockchain technology is neutral. All the attention that bitcoin and others have showered on blockchain is fully offset by entities that hold a negative view on cryptocurrencies because of their association with illegal commerce and theft. Nevertheless it is likely to have an impact someday, and software executives and information technology service providers would be well-advised to familiarize themselves with the technology and its potential.


Robert Kugel

Senior Vice President Research

Follow Me on Twitter and

Connect with me on LinkedIn.

I recently wrote about the challenge some companies will face in planning and budgeting when new revenue recognition rules go into effect in most countries in 2018. It’s important for companies that will be affected to be sure they have the appropriate systems, processes and training to handle the more difficult demands imposed by the new rules. With the change in accounting, the time lag between when a contract is signed and when a company recognizes revenue from it may be more variable and less predictable than in the past. In extreme cases, performance measured by financial accounting will diverge materially from the “real” economic performance of the organization. Consequently, executives – especially those leading publicly listed companies – will need the ability to look at their plans from both perspectives and be able to distinguish between the two in assessing their company’s performance. In companies where the timing of revenue recognition can diverge substantially from current methods, financial planning and analysis (FP&A) groups will need to be able plan using models that incorporate financial and managerial accounting methods in parallel. They will need to be able to identify actual-to-plan variances caused by differences in contract values booked in a period and differences between the expected and actual timing of revenue recognized from contracts signed in a period.

I don’t want to overemphasize the impact the new revenue recognition rules will have on companies’ planning. While some companies need to understand that they will have to alter their planning and review processes, I expect that most will be unaffected by the new accounting for contracts, for at least one of three reasons:

  • A majority of their revenue does not come from contracts. (Retailing is one industry in which many companies do not transact business using contracts.)
  • No single contract or type of contract is large enough to have a material impact on reported revenue.
  • The time lag between signing a contract and fulfilling the contract is short (a month or less) or the time lag between booking a contract and fulfilling it is reliably consistent from month to month or quarter to quarter.

For many companies, tracking individual contracts will be unnecessary, impractical or both. It may be unnecessary because the relative size of contracts matters. Even if an organization’s individual contracts differ significantly in terms of the interval between signing it and recognizing revenue from the transaction, if there are enough of and even the largest represents an insignificant percentage of total revenue, the difference won’t matter. That is, in most cases the difference between expected and actual timing of revenue recognition of individual contracts is likely to be cancelled out. Moreover, tracking individual contracts will be impractical for many organizations because their volume will make it is too expensive and time-consuming to capture the relevant terms and conditions for each contract, which is necessary to be able to isolate the factors driving actual to forecast or budget variances. For FP&A groups the challenge will be in creating models that accurately forecast the average lag between contract signing and when revenue is recognized. Analysts also should confirm that the standard deviation of this lag under the new rules will be small enough to avoid the need to segment contracts into major types. (I’ll return to this point shortly.)

Nonetheless, a significant number of organizations – either entire corporations or business units with revenue responsibility – will need to change their approaches to creating and using planning models in order to accurately measure variances between their plans or budgets and their actual results. This means developing models that enable them to separate variances that are the result of differences in when business was booked and those in which the timing of the revenue recognition process turned out to be longer or shorter than expected. Certain types of businesses that have large, complex contracts with their customers, such as aerospace, construction and engineering, are likely to find that they need to plan and track results by contract – at the very least the 20 percent of their contracts that account for 80 percent of their revenues.

Another type of company or business unit that will need to adopt a more granular approach to tracking contracts  under the new rules is one in which there are significant differences between the timing of revenue recognition for different types of contracts. Even though the value of individual contracts booked in a period is an insignificant percentage of the total, it may be necessary for organizations to segment contract bookings and revenue recognized for each major type of contract. This would be the case if there are significant differences in the timing of revenue between types of contracts and the mix of contract types varies from one month to the next. For example, imagine that Company X has contracts that have three distinct revenue recognition profiles. In one of them, which accounts for one-quarter of annual bookings, there is a consistent one-month interval between when the contract is signed and when revenue is recognized. For a second type of contract (representing 40 percent of annual bookings) it can take up to several months before revenue can be recognized, and then it happens all at once. The remaining contracts are recognized over a year after a contract is signed. Any significant differences in the mix of contract types signed from month to month will make it difficult to reconcile variances and accurately identify differences caused by better than expected or inadequate contract bookings and those caused by timing differences.  So it’s necessary to create and use models that segment revenue by mix of contract types.

It is time for companies to get serious about adapting their business to the new revenue recognition rules. They will have to cut over to new processes and systems in 2017 to comply with the new standards and be able to make year-on-year comparisons when the new methods go into effect in 2018. Financial planning and analysis groups should be considering whether their forecasting, planning, budgeting and reporting models and processes will need to change under the new accounting standards. Those that will have to change should look into acquiring a dedicated planning and budgeting application if they (or affected business units) are currently using spreadsheets for planning. That will include many organizations: Our next-generation business planning research vr_NGBP_09_spreadsheets_dominant_in_planning_softwarefinds that two-thirds (65%) of companies use spreadsheets to manage their budget process. A dedicated planning application will help them prepare better to understand whether a difference was due to the new accounting rules or poor performance using actual data rather than opinions.

FP&A groups should be aware of their company’s exposure to new revenue recognition rules. If the rules will have a material impact on how the company accounts for contracts, they should determine whether it will be necessary to plan and budget for “real” and accounting data in parallel. If so, and if their company currently plans and budgets using desktop spreadsheets, I strongly recommend that they look into acquiring a dedicated planning application. In addition to dealing with increased complexity, this type of software can improve the budgeting and planning processes, making them more efficient.


Robert Kugel

Senior Vice President Research

Follow Me on Twitter and

Connect with me on LinkedIn.

RSS Robert Kugel’s Analyst Perspectives at Ventana Research

  • An error has occurred; the feed is probably down. Try again later.

Twitter Updates


  • 127,142 hits
%d bloggers like this: