You are currently browsing the category archive for the ‘Governance Risk & Compliance (GRC)’ category.

For most of the past decade businesses that decided not to pay attention to proposed changes in revenue recognition rules have saved themselves time and frustration as the proponents’ timetables have slipped and roadmaps have changed. The new rules are the result of a convergence of US-GAAP (Generally Accepted Accounting Principles – the accounting standard used by U.S.-based companies) and IFRS (International Financial Reporting Standards – the system used in much of the rest of the world). Now, however, it’s time for everyone to pay close attention. Last year the U.S.-based Financial Accounting Standards Board (FASB, which manages US-GAAP) and the Brussels-based International Accounting Standards Board (IASB, which manages IFRS) issued “Topic 606” and “IFRS 15,” respectively, which express their harmonized approach to governing revenue recognition. A major objective of the new standards is to provide investors and other stakeholders with more accurate and consistent depictions of companies’ revenue across multiple types of business as well as make the standard consistent between the major accounting regimes.

The impact of the new standards will vary greatly depending on the nature of the business. The rules cover companies that enter into contracts with their customers to transfer goods or services or enter  into contracts for the transfer of nonfinancial assets – unless those contracts are within the scope of other standards (for example, insurance or lease contracts). Their scope includes most industrial and business services as well as many that have direct-to-consumer relationships. Specifically, aerospace and defense, automotive, communications, engineering and construction, entertainment, media, pharmaceuticals and technology industries are likely to feel the greatest impact. Investment management companies that receive performance-based incentive fees will also be affected. However, it’s likely that some “contracts” covered by the new standards are informal. For instance, there is an implied contract when the seller of a video console ships a product with a game that has only half of the levels but promises to provide the remaining levels at a later date.

It has taken years to reach agreement because creating a codified approach to revenue recognition across all industries was a complex undertaking. It has required the standards bodies to go to the conceptual heart of revenue recognition to devise a common, workable approach. Implementation has been delayed to provide the affected corporations additional time to address the often significant process and systems changes they must put in place to adapt to the new standard. As of now, it looks likely that publicly held companies will begin applying them for annual reporting periods beginning after Dec. 15, 2017, and private companies a year later. Software vendors have been preparing for the new revenue recognition rules, some for several years.

Another main objective of the new standards is to simplify preparation of financial statements. That is unlikely to happen as companies affected by the new standards deal with the transition. In the long run, how well a finance and accounting organization uses software to manage contracting, invoicing, billing and the revenue recognition process will have a significant impact on the amount of work involved. Here software can help; it is a natural fit for principles-based accounting standards. In the absence of prescriptive rules, auditors must be able to confirm that a corporation’s accounting treatments were appropriate and applied consistently. Because softwarevr_ss21_errors_in_spreadsheets codifies these treatments and automates their application, it functions as a high-level control that, in theory, should make governance and auditing of this aspect of a company’s books much easier to enforce. Moreover, while the new standards may be more useful for investors, they may make a company’s statutory accounting numbers less practical for managing the business. To address this issue, software can reduce the workload involved in preparing management accounting. It also can facilitate a planning process that must be able to view the pro-forma numbers for future income statements, balance sheets and cash flow in both statutory and management contexts. We urge organizations to avoid the use of spreadsheets for this and other enterprise purposes. Our benchmark research finds that various types of errors are common even in the most important spreadsheets; errors that relate to revenue are likely to be material.

For those not familiar with the accounting issue being discussed, here is a quick summary of what has been driving the change. Revenue recognition accounting issues have a long history in the U.S. because of the early rise of a market for publicly traded software companies in this country. Rules grew in scope and specificity in response to successive scams and frauds involving inflated sales numbers perpetrated on investors. Many software companies’ revenue recognition policies were extremely aggressive until 1991, when the first rules were put in place. Those first iterations proved too feeble, and further revisions attempted to prevent abuse, but in the process the rules have become highly detailed and unwieldy. From the standpoint of U.S. companies, replacing the increasingly complex and onerous rules became necessary. It’s easy to make mistakes trying to abide by regulations that include more than 100 requirements governing recognition of revenues and gains. The new approach is aimed at reducing this complexity. For its part, IFRS relied more on principles to guide accounting treatment. Although that approach was less complex, it was also less comprehensive and harder to interpret. Dissatisfaction grew because for different reasons, US-GAAP and IFRS each were failing to present a consistent picture of the economic health and performance of companies, which is a core purpose of accounting. And harmonizing revenue recognition rules between the two systems has been a major objective of eliminating differences between US-GAAP and IFRS.

The particulars of the new standards are so detailed that I will highlight only three key points. First, “Topic 606” and “IFRS 15” employ a novel customer-focused framework that represents a fundamental conceptual change in how revenue is measured. Under the new approach, revenue is recognized when the customer gains control of some combination of a good or a service and not necessarily (as has been the case) when the customer acquires title to or takes physical possession of the asset or when a service has been billed. This interjects a considerable amount of opinion into the process. Moreover, sellers are required to parse the sales contract (which may be formal or implied) to identify separate performance obligations (if any) to the customer and allocate the transaction price to these individual performance obligations. Auditors will have to agree that the approach is sound and applied consistently. Complications to the process arise when a contract even implicitly includes multiple performance obligations such as the correct installation of machinery or periodic updates to firmware needed for the machinery to operate properly. To be sure, a good deal of uncertainly will be resolved over the next three years during the phase-in period, but the change is likely to be a major distraction to many companies’ finance and accounting organizations over the next five years.

Second, it will be interesting to see to what extent the new rules improve transparency of financial statements. The new framework hews to an approach that has academic consistency on the revenue line but can bend accounting’s matching principle (matching revenue to related expenses). For example, at this stage in the evolution of the rules, companies that have multiyear contracts will recognize revenues in some ratable fashion over the life of the contract but – in contrast with past practices – will have to recognize some costs related to the contract immediately. Wireless communications vendors, for instance, might find that the handset subsidy they currently provide to customers would have to be expensed at the start of the contract rather than over the life of the contract because the matching principle would no longer apply to the way revenues are classified. In this respect, the new approach is a more accurate reflection of the cash flows of the transaction but not of the economics or the nature of the customer relationship. Professional investors will be able to see through the numbers because they have the training to do so; ordinary individuals will not. To the extent that the new standards create a gulf between reported results and those that are meaningful to running the business, they will proliferate the reporting of non-GAAP results to investors.

Third, while the objectives of the revised revenue recognition standards are laudable and will benefit some investors in some respects, they may complicate corporate financial management in companies materially affected by the new standards. Those that use written contracts or discover they have somewhat contractual relationships with their customers will experience a more complicated revenue recognition process that demands more stringent control of a more complex and detailed record-keeping regime. Importantly, the customer-first framework is divorced from longstanding internal processes, management reporting needs and tax management. So accounting and planning for taxes, commissions, bonus plans and debt covenants may require more attention. Because of this, almost all companies that adopt the new methods of revenue recognition will have to adapt their financial management software and accounting practices to handle the new rules. They will need to review contract wording and related processes as well.

Let me repeat that there is a natural relation between principles-based accounting standards and software. In addition to ensuring consistency in treatment and facilitating governance and control, software also is capable of automating the process of presenting a company’s results from multiple perspectives in a consistent fashion. This is important because many companies will find that their statutory books alone will not provide the right numbers to manage their business. Although public company managements will want to see how their numbers look to Wall Street, they may find that these figures are inconsistent with business practices required to achieve sustainable long-term objectives. Software can systematize the simultaneous translation of events into increasingly divergent financial and management accounting contexts.

Many ERP and financial management software vendors have been preparing for the new revenue recognition rules. I see three main requirements for such companies in preparing to handle the new revenue recognition rules.

  • One is process management for the five-step process that determines when revenue can be recognized. That begins with identifying the “contract,” which may be formal or informal. After that it must identify the performance obligations established by the contract, determine the contract price, allocate that price to the individual performance requirements and recognize revenue when that obligation is satisfied.
  • An integrated contract management system or tight integration with third-party contract management products (including sales force automation) can ensure that the data regarding the contract can pass back and forth easily between systems. Invoicing and billing software must be elastic enough to capture the full palette of transaction information in order to provide the appropriate treatment of the debits and credits for that specific transaction. And it is necessary to handle any subsequent events related to that transaction such as cancellations, adjustments and modification of contracts. Processes vary across industries, and even companies in similar businesses may have slightly different contracting processes. So accounting software vendors must provide customers with unlimited freedom to define the characteristics they need to capture in the invoice and the specific accounting treatment of all of the components of that record based on those characteristics.
  • Finally vendors must have a method for instantly recasting results and plans accurately and consistently to satisfy financial and management accounting revenue requirements as well as cash flow for treasury management and a taxable view for tax management purposes. ERP and other software vendors will take different approaches in making this feasible depending on their software architectures. Thus it’s important for finance executives to understand that the approach a vendor might be touting is simply an adaptation to its existing architecture, rather than the best method for their company’s purposes.

It’s not clear at this point how much disruption the new revenue recognition standards will create in finance and accounting organizations. One reason is that it’s hard to know how external auditors will behave. In the United States, the shift to a principles-based methodology will challenge a generation of auditors who grew up in a rules-heavy environment. The framework is straightforward, but the implementation of the Sarbanes-Oxley Act is a cautionary tale of how unnecessary complications can needlessly disrupt the accounting function.

vr_ss21_spreadsheet_maintenance_is_a_burdenWhat should be abundantly clear, though, is that companies should avoid using desktop spreadsheets as much as possible in handling the revenue recognition process. Because of the complexity, it will be a nightmare to try use desktop spreadsheets for all but truly one-off calculations and prototyping work. Our research finds that in many situations spreadsheet maintenance is a burden, and this certainly will be the case here. Revenue recognition will be in a state of flux for years because of the highly predictable spate of rulemaking and “clarifications” of these treatments and maybe even requirements to recast numbers. Automating and controlling the flow of contract information from the negotiating phase all the way to invoicing can preclude the need for multiple adjustment, allocation and reconciliation steps. It can facilitate the process of creating statutory and management accounting statements and analysis of the difference between them as well as planning, budgeting and reviewing.

I recommend that companies that might be affected by the new revenue recognition standards review the adequacy of their ERP and financial management software to handle the new rules, including how it captures contract information in the sales process and passes it to the accounting system. They should examine their vendors’ plans for adapting to the new regulations to determine whether they are adequate for their specific needs. They should recognize that while software companies will be tempted to spread fear, uncertainty and doubt to generate business, some businesses really are in danger of being overwhelmed by the new rules.

Regards,

Robert Kugel – SVP Research

There’s a long history of companies not paying close enough attention to the contractual elements of acquiring software. Today, this extends into the world of cloud computing. Many companies are choosing to acquire software services through cloud-based providers and increasingly rely on access to cloud-based data, as is shown by our forthcoming benchmark research, in which a large majority of participating companiesvr_DAC_01_importance_of_cloud_data said that having access to data in the cloud is important or very important. As they say, I’m not a lawyer and I don’t play one on television, so what follows is intended to be nothing more than a conversation starter with legal counsel. But I do advise companies on how to use software to improve their business performance and provide guidance on what software they need to achieve their objectives. From that perspective, let me offer this blanket recommendation: Your company should examine the terms and conditions of its contracts carefully to be certain that it has the ability to control, access and retain its data in single or multitenant cloud-based systems. It should be prepared to add terms and conditions to any software-as-a-service (SaaS) contract to preserve ownership of and access to the data as well as other proprietary elements of that business relationship.

The fact is that choosing a cloud-based option presents a different set of legal issues that purchasers do not face with on-premises software, so it’s important that they consider the terms and conditions of the contract. Some of these issues aren’t completely new – they go back to the days before perpetual contracts and “open systems” were the norm. In that era, a company could find itself hostage to a vendor that shut down the company’s system remotely and prevented it from using the technology to run its business and retrieving its data from the system. Before entering into any SaaS contract or renewal, it’s important to review the details of the contract and its terms and conditions. The company should insist on modifying the wording of the contract if necessary to the satisfaction of both parties. It’s essential to perform this review early on, when vendors are short-listed, not at signing. It’s also important to review and, if necessary, revise the contract before each renewal. Customers have leverage at renewal since the most expensive event in a subscription-based business is losing a customer.

There are many facets to a SaaS contract, including performance, reliability and security as well as data. My focus here is on the last item.

Going into a relationship with a SaaS vendor, it’s essential that the contract specify what data the customer owns, whether that ownership is shared with any other parties, including the SaaS provider, and how the customer can obtain its data from the vendor. A SaaS contract should delineate what data the customer will have the right to take at the time it terminates the contract. This should include its data in the database tables but also might cover data about its specific configuration of the application and data from the database logs that pertains to its use of the system. It also should specify the form and format for that data as well as the timing of when the customer will obtain that data (for example, how many hours or days from when the customer requests it), how often the customer will be provided with data (unlimited requests is preferable) and the charges for such data transfers. Creating a set of extraction reports that harvests all the data from the buyer company’s tables may be adequate, but then again it may not be sufficient. The contract also should address contingencies for change of control (that is, if the vendor is acquired by another company) and bankruptcy.

Having database table data and information about the database structure is useful in the process of moving from one cloud vendor to another. Migrating from one vendor to another almost always involves setting up the successor system before the previous vendor’s contract expires. Also, in the process of finding and selecting a new vendor, a company will find it necessary to provide information about its existing system and the data that’s in it. This should be part of the background information included in a request for proposal (RFP), which should include a section detailing how the implementation service provider will manage the migration. Clarifying this part of the process ought to be a part of the selection process, and getting the details of the migration in writing before selecting a vendor and implementation partner reduces the possibility of encountering a potentially time-consuming and expensive problem. The responses to the RFP can help the buyer craft the contract terms and conditions with the successor vendor and implementation partner.

How often the customer can transfer data from the system vendor’s system is important because it’s likely that a customer will need to do so multiple times. For example, in most cases it will need to extract the data from the current vendor’s system at least once before the contract terminates in order to begin the implementation process for the follow-on system. This will be necessary weeks if not months before the termination date, followed by additional data extracts from the old to the new system. Companies also should consider how to replicate the process of running the incumbent and new systems in parallel during a testing phase. There may be fewer potential “gotchas” in migrating from one cloud to another because there are no system configuration and other infrastructure issues with which to contend, but there still will be many process, business logic and configuration kinks to work through. Even after migration, a company may find it necessary to maintain its instances with the old vendor for legal or audit purposes for several years. Setting the parameters of pricing a decommissioned version in a contract is likely to save money down the road.

There’s also the related issue of data ownership. A contract with a SaaS provider should acknowledge that the customer is the sole owner of its data and lay out the ability of the service provider to access that data with the objective of ensuring that the data can be used only to provide services to the cloud customer. Also, the legal ramifications of connecting a company’s cloud system to other applications or an operational data store should be spelled out.

Data retention and third-party access should also be covered in the contract because during a civil, regulatory or criminal legal proceeding, the customer may be subject to electronic discovery. This involves the exchange of information from electronic systems in electronic format. Data identified as relevant by the attorneys involved in such a process is placed on legal hold, which means that it cannot be deleted or altered. Making this explicit in a SaaS contract may reduce the possibility of legal repercussions if, for example, the vendor inadvertently eliminates or alters data that is covered by a legal hold.

The physical location or locations where the customer company’s data is held, as well as any backup sites, ought to be included in the contract. This is important because of requirements by some countries (for example, the EU Data Protection Directive) that specify where data can or cannot be located and whether data transfers are permitted. The contract also should spell out how the customer company will be notified ahead of time if the locations where its data is stored will change.

It strikes me that we are still in the naïve stage of the cloud software revolution, but it’s time to imagine the worst that can happen. I recommend that SaaS vendor user groups focus on the contractual aspects of their relationship with vendor, especially with respect to their data. They can collectively engage their corporate counsels in crafting a set of desired contract terms and establishing best practices for ongoing access to data and for facilitating migration from that vendor’s environment when customers wish to make the move. They also should focus on how secure their position would be in the event of a corporate bankruptcy and on the change of control provisions (if any) should their vendor be acquired. For their part, I recommend that vendors develop their side of contracts to anticipate having to meet their customers’ demands for open access and control. Just as buyers forced vendors to adopt a more open systems approach two decades ago, SaaS customers are unlikely to want to find their data locked in. Developing a legal framework to handle unfortunate contingencies makes better sense than trying to deal with issues on an ad hoc treadmill.

Regards,

Robert Kugel – SVP Research

Twitter Updates

Stats

  • 94,189 hits
Follow

Get every new post delivered to your Inbox.

Join 75 other followers

%d bloggers like this: