Six System Objectives For Meeting the New Rev Rec Standards

December 6th, 2019

Within a matter of weeks, the new standards for revenue recognition will become audit guidance for non-public companies (public companies have reported under these standards since 2018).  This global standard –Revenue from Contracts with Customers— jointly authored by the Financial Accounting Standards Board (FASB), and counterpart, International Accounting Standards Board (IASB), creates a framework for revenue recognition consistent with performance and entitlement.  The FASB version of the joint standard is published under ASU 2014-09, Topic 606, or ASC 606, with the IASB version titled IFRS 15.  While changes to the timing and amount of revenue businesses recognize will vary depending on the type of contracts they execute, the need to reconfigure accounting/ERP systems will be broad-based (see below table “Managing Standardized, Variable Agreements”).  Such changes will be further prompted for companies adopting subscription-based models, a growing trend in customer agreements.      

As a primer to meeting the new rev rec standards, and managing a contract portfolio, consider these six objectives for your ERP:

Source Transactions to a System-Based Contract – As the title of the new standard implies –ASC 606 is specific to contracts with customers.  From a system’s standpoint, this means that all revenue, and related incremental and fulfillment cost postings (see below “Match Contract Expenses with Revenues”), should be traceable to a source contract.  A system-based contract transaction, or “container,” has two purposes.  First, it acts as the source ID for all transactions related to the contract.  Thus, each system-managed contract has its own ID, or unique dimension, which related downstream transactions share.  Prior to the implementation of the new standards, auditors and businesses were dependent on document, customer, and G/L posting identifiers to trace the source of an account balance.  For reporting purposes, the contract ID should be an available filter at both the subsidiary and general ledger levels.  Secondly, the system-based contract acts as a container, or manager, of all contract deliverables (performance obligations), and associated expenses.  That is, it manages all items that will be billed, or posted against the contract; customer invoices and contract expenses are the downstream postings related to the system-based contract.  By comparison, typical legacy systems have no contract object, with system administrators using an order transaction as a contract proxy.  This arrangement becomes difficult to manage when modifications to the underlying contract occur, and additional order transaction(s) must be created to track the modifications.  In this case, the activity of a single customer contract is segmented over multiple, and seemingly unrelated system transactions, with traceability difficult.        

Allow Modifications to Scope and Price – Contract modifications involve a change in price and/or scope to the original contract, with, of course, a subsequent effect on revenue recognition.  The new standard considers whether modifications trigger accounting for a wholly separate transaction.  While tests to determine the need for a separate contract, or other alternatives for termination, modification, or a combining result, are beyond the scope of this evaluation, the overriding requirement going forward is for system flexibility.  Specifically, that the ERP supports a system-based contract that can be modified during the contract lifecycle.  As previously discussed, a system-based contract should contain and manage all items (think performance obligations, or PO’s), and contract expenses; these, of course, are dynamic and may require updates over the underlying contract cycle, given that modifications do not trigger accounting for a wholly separate contract, or termination.  If circumstances do not require such treatment, then the original system transaction/contract must be modified to incorporate the changes, with retroactive price treatment (see below “Allocate and Reallocate Revenue”).  In addition, other system governances of contacts, including options to hold, resume, and cancel, are necessary to manage revenue recognition consistent with the principal of performance (Viz. until there is performance, and subsequent benefit, revenue must remain deferred). The auditability of contract modifications is also an important consideration, with a contract-based system giving internal and external parties a single reference point to any update.   

Allocate and Reallocate Revenue – The new standard calls for the allocation of total contract price to its related performance obligation(s) (POs, deliverables, or items, in a system’s context).  Note: allocation is not revenue recognition, but the assignment of assessed fair value to each PO;` once allocated, then revenue recognition commences as the seller satisfies its obligations.  From a system’s standpoint, this represents a two-step process: posting as deferred revenue the fair value assigned to the individual PO(s)/item(s), and then amortization of that deferral, or revenue recognition, as performance occurs.  If the contract calls for the delivery of a single PO, the allocation of price is straight forward.  However, if the contract calls for the delivery of multiple POs, then those items are “bundled” for price allocation purposes when the selling price of the individual items in the bundle are greater than the amount the customer pays (AKA customer gets a bundled discount), or when some, or all the POs, are interdependent (goods or services that are highly integrated, or dependent upon each other for the performance of the contract, or components of the contract).  Such interdependent items are combined, and treated as a single performance obligation.  POs that are independent, meaning they’re sold together, but aren’t dependent upon each other for the performance of a contract are not included in a bundle, unless the first condition of a bunded discount arises.  Finally, whether all items of a contract are bundled together, or there’s a collection of bundles, price allocation, and/or reallocation to the bundle(s), is based on the fair value of each distinct deliverable.  This excludes usage-based amounts because of variability in the quantity of goods or service delivered, but includes goods or services which are priced per fixed or flat amounts.

The mechanics of price allocation, reallocation, and then recognition, involves a complex workflow.  Consider a business that manages a portfolio of contracts, which typically incorporates multiple deliverables.  For this portfolio, finance and accounting will need to: 1) bundle interdependent items,  2) bundle all discounted items (the combination of 1 and 2, could potentially result in a bundle of bundles), 3) compare the actual selling price to the observable fair value for those distinct items, 4) allocate the contract’s overall selling price to each item based on the relative fair value for those items, 5) recognize revenue in accordance with this allocation method, until such time as contract modifications require reallocation of the new contract price based on a walk-forward or catch-up method.  To say the least, an elaborate set of Excel schedules and updates.  To better manage the process, utilize an ERP system designed for bundling, tracking of fair value prices, price allocation, reallocation, and revenue recognition based on the allocated, and possibly reallocated price.       

Recognize Revenue According to Performance and Entitlement – As previously identified, a defining characteristic of the new standard involves the recognition of revenue as the entity performs, and expects to be entitled to compensation based on the customer’s potential to pay (these respectively answer the questions of when, and how much revenue to recognize).  In contrast to this principals-based approach, is the outgoing method of recognizing revenue according to asset receipt and delivery; that is, recognition occurring when an entity receives cash or records receivables, and goods and/or services are delivered.  In practice, this changes the timing and amount of recognition for certain transactions, and, while generally following paths distinct to point-in-time recognition for the delivery of goods, and period of time recognition for the delivery of services, has nuances.  Revenue recognition is also undergoing change as businesses further incorporate right to access, or subscription-based models, away from right to use, or single point-in-time delivery (see below graph, Figure 1, courtesy, February 2019).  These arrangements typically involve options for tiered pricing, and billing schedules; “non-linear” agreements, or those that involve variability in unit pricing over a range of quantity sold, and/or the frequency of billing.    

To accommodate both standards-based changes for revenue recognition, and a shift toward subscription-based agreements, systems need flexibility to manage the gating of revenue and other non-linear pricing, and billing options.  Central to this flexibility is the need to separate customer billing from revenue recognition; while these schedules can coincide, thus, harmonizing billing and recognition periods, performance and benefit are often deferred, requiring recognition as the customer later obtains control of the goods and/or services.  System functionality also needs to extend to the line item, as contracts often call for multiple deliverables or performance obligations that exact different treatment.  Finally, revenue schedules need to manage differentiated amortization scenarios, including straight line, daily rate, quantity based, and percentage of completion.  Certain of these can be fully automated, or automated according to input methods (EG timesheet entry reflecting labor hours expended), while others need further governance to allow recognition measured according to output methods such as delivery milestones.  

Match Contract Expenses with Revenues – As opposed to existing accounting rules, the new standards incorporate comprehensive guidance on contract related costs.  Specifically, they require capitalization of the incremental costs of obtaining and fulfilling a contract as incurred, if the entity expects to recover those costs.  If capitalized, as a deferred cost, to be amortized on a systematic basis consistent with the transfer of goods or services over the length of the contract, with anticipation of extension.  Given this backdrop, costs to obtain a contract, including sales commissions related to service contracts greater than a year, and costs for contract fulfillment such direct labor, materials, and other allocable costs, need to be amortized over the contract’s length, with reasonable provision for extension.  Further, amortization of cost should be allocated to specific POs, not the contract as a whole “consistent with the goods or services to which the asset relates” (ASC 340-40-35-1).  Costs that do not meet the capitalization standard, or costs to obtain a contract that would have been incurred regardless of whether the contract was obtained, or fulfillment costs not directly related to a contract, are expensed as incurred.  As noted earlier, a system designed for the new standards must provide a contract object, or “container,” which acts as the source entry, and reference, for all contract related revenue and expense items.  The posting of related contract expense schedules should match the periodicity and methodology of associated revenue schedules. 

Report on Contract Renewals, Backlog, and Cash Flows – Although non-public companies are afforded a practical expedient for certain disclosure requirements expected of public entities reporting under ASC 606/IFRS 15, they would do well to meet each of the following to provide for a consistent analysis of revenue recognition (see table below “Disclosure Schedule and Practical Expedient”).  This is particularly the case for optional segment and backlog reporting.  Given the requirements, and other options for detailed analysis of company performance and financial position, the question is how do I architect my business systems/ERP to provide for the disclosures?  In summary, entities will need to capture data related to their contracts according to specified financial (GL) account balances, separate books, and revenue segments.  In detail, GL accounts should be added for posting unbilled, billed, and paid balances related to accounts receivable, deferred revenue, and sales.  In turn, these will support disclosures for contract assets, liabilities, revenue, and cash flow.  Further, postings to the GL accounts unbilled A/R and deferred revenue allow for analysis of contract backlog.  If your system architecture supports multi-book, or separate books, these should be utilized to capture postings according to outgoing revenue standards (ASC 605), and the new standards (ASC 606), as businesses must report on their differences as they transition from old to new.  For segment reporting, businesses should use system dimensions to meet the optional standard for disaggregation of revenues according to product line, service type, and geography.  By rearchitecting a system for the reporting requirements demanded of non-public companies, and adopting optional disclosures, businesses will enhance their view of contract-based results, and add additional metrics for insight of overall financial performance and position.               

To meet sweeping changes in rev rec standards you look for ways to modify your ERP system.  You’ve also recognized the need for better financial metrics –especially related to your contracts.  To meet these objectives, an overall consideration of moving from the “As Is,” or a transaction-based ERP, to the “To Be,” or Contract-Based ERP system must be advanced (summary listed in table below “As Is Systems, To Be Systems.”)  Your options include retrofitting your current ERP with new “parts” that can help address the new standards, or migrating to a system with the underlying architecture required to address contract-based processing, and reporting.  Changes must be considered in light of the principals of performance and entitlement, a shift toward subscription-based agreements and the advent of more dynamic contracts which are more likely to incorporate options for modification, and variable consideration.  A confluence of factors contributes to the need for contract-based ERP systems, and new options to interact with customers during the next wave of changes in the broader economy.

Seth Pomeroy

Partner, NDH

For additional information on options to adopt a contract-based ERP click here.