Project Partners Blog


Posts Tagged ‘Revenue Recognition’

Part 2 of 2
LEVERAGING ORACLE PROJECTS TO MANAGE PERFORMANCE BASED REVENUE

As stated previously, the core principle in the new Standard requires that an entity recognize revenue to depict the transfer of goods or services to a customer in an amount that reflects the consideration given in exchange for those goods or services.

Impact to Balance Sheet and Income Statement

When a contract is signed, an asset and a liability are created for the total amount of goods and services promised to the customer.

Upon fulfillment of an identifiable performance obligation (commonly referred to as a “deliverable”), the liability is reduced, and revenue is recognized when that performance obligation is satisfied and accepted by the customer.

When payment is received for the goods and services provided, the asset is reduced.

This new methodology differs from the previous generally accepted practice of recognizing revenue when the customer is billed, and a receivable is created.  No longer will a company track unbilled revenue streams.  Oracle Projects provides the ability to configure your projects to meet the requirements of Step 5 of the new ASC 606 guideline with standard functionality.

Step 5 of the Standard requires a two-step approach.   Using Oracle Projects, work is performed, and delivery is recorded.  Then, a process to Generate Draft Revenue for the projects is run to complete the recognition process.

The following is an example of how your company can leverage Oracle Projects to meet ASC 606 compliance.

Service Contracts based on selling hours (T&E)

  • Work Based Revenue Recognition
    • Standard Oracle functionality of Time & Expense Billing
    • Set up project and billing information

  • Identify the Performance Obligations and set up as Budget Lines for the contracted number of hours

  • Delivery Team Charges Time & Expenses to the Project

  1. Revenue based on hours charged
  2. Acceptance of work performed implicit when customer signs timecard
  3. Invoicing takes place when the timecard is approved. This process can precede the actual recognition of revenue as the performance obligation is not yet complete.
  4. As each phase of the project is finished, revenue is recognized.

Run the Generate Draft Revenue Process for your projects to recognize revenue

Perform Work and Record Delivery

  • T&M Service Contracts based on specific Deliverables
  • Fixed Price Service Contracts based on Milestones
    • Mark Deliverable as Complete. Mark Billing Action as Complete

Run the Generate Draft Revenue Process for your projects to recognize revenue:

T&M/Fixed Price Service Contracts

  • A Fixed Price Service Contract requires the use of Billing Events generated from deliverables to generate revenue.
  • Invoicing can be generated per the terms of the contract; however, revenue cannot be recognized until the performance obligation has been met.

Unit Price Based Contracts

Oracle Planning and Control offers the ability to utilize a structure called Schedule of Values (“SOV”).  The SOV allocates value for various parts of the work from a contractual agreement.  The SOV schedule is also used as the basis for monitoring progress, tracking deliverables, and submitting and reviewing payment certificates for billing the client.  The user can either enter a contract in Oracle Project Contracts, or directly enter one.  Once a project is created, it can be updated from Oracle Project Contracts or directly entered in Oracle Planning and Control.

  • Enter Progress and record quantity completed for each SOV Task
  • In this case, a task has been set up for each performance obligation under the contract. As the task is completed and accepted, revenue can be taken

  • Billing Events are generated from Schedule Of Values progress and are used to generate revenue

Recent Enhancements to Support ASC 606

Oracle has been supporting organizations implementing these changes in their business to accommodate the new Standard.  To aid in the implementation and management of project revenue according to the new accounting standards, new consolidated patch sets to Oracle Projects have been released.

For companies using Oracle EBS Projects Suite Release 12.1.3 and above and Release 12.2.7 and above, Oracle has issued a patch set specific to each release to support management of project revenue according to ASC 606.

Below you will find screen shots of some of the new standard functionality available with these changes, recently published by Oracle.  As you can see, Oracle Projects addresses set up, tracking and revenue recognition via the use of a new Structure for Performance Obligations.

The new processes allow for the user to enable the use of Performance Obligation, create said obligations, publish and track progress against the performance obligation and generate revenue in accordance with the new standards.

As you can see Oracle Projects provides the ability to configure your projects to meet the requirements of the new ASC 606 guideline with standard functionality.

Oracle Licensing Requirements

  • Project Costing and Billing are required for all features discussed in this paper
  • Project Planning and Control (formerly known as Project Management) must be implemented to leverage Deliverable functionality
  • Schedule of Values functions are available in Oracle Project Planning and Control release 12.2.5
  • Application of Patch sets as described in this paper to take advantage of the ability to record and track Performance Obligations

CONTRACT MODIFICATIONS

Contract modifications, commonly referred to as change orders or amendments, occur when the price or scope of a contract is changed.  Depending on the circumstances, these changes are accounted for either as a modification to an existing contract, or as a separate contract.  Proper accounting treatment for modifications differs based upon this determination.

There are three steps to determine the proper treatment for a contract modification.

Determine Whether the Change Qualifies as a Contract Modification – A contract modification is any change to an enforceable rights and obligations of the parties to the original contract.  The Standards defines this as a change in scope and/or price of the original contract.  It does not need to be written, it can also be oral or implied through customary business practices.  Once an entity determines that a change is indeed a contract modification, it determines whether to account for it as a change to the original contract or as a separate contract.

Determine Whether the Modification is a Separate Contract – To determine that a modification is a separate contract, these two criteria must be met.

  1. The scope of the contract has increased with the addition of distinct goods or services, and
  2. The price of the contract increased by an amount comparable to the entities standalone selling price of the additional goods or services. (Selling price less ordinary selling costs)

Determine the Proper Accounting Treatment for Contract Modifications – If a contract modification is considered a separate contract, no changes to the existing revenue on the original contract are required.  The new contract is recognized as the performance obligations in the new, separate contract are met.  However, if the contract modification is not considered separate, then the modification is combined with the original contract.  There are two methods defined in the Standard for proper revenue recognition of a combined contract modification.

  • Prospective Treatment

If the remaining goods/services are distinct from those of the original contract and do not meet the criteria for a separate contract, the entity treats the original contract as terminated and accounts for both the original contract and modifications together as a newly created contract (ASC 606-10-25-13).

Revenue already recognized on the original contract is not adjusted.  All remaining transactions are accounted for on a prospective basis.

  • Cumulative Catch-up Adjustment

If the remaining goods/services are not distinct, the entity combines the increase or decrease of goods or services with the original contract’s promised goods/services to create a single performance obligation that is partially completed at the date of the modification.  The entity must adjust previously recognized revenue to reflect the changes of the modification to the transaction price.

USING ORACLE PROJECTS TO MEET THE OBJECTIVES OF CONTRACT MODIFICATIONS AS DEFINED
IN ASC 606

Begin by increasing the amount of the Agreement on the project, then adding an additional funding line for the increased contract amount to the project tasks.

If the contract modification is Prospective, the Date Allocated should reflect the date from which revenue recognition will occur.

Create a Revenue Event using the new Date Allocated and run revenue generation processes.  The new revenue amount will begin as of the new date as indicated.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

If the contract modification is cumulative, the Additional funding should be entered with the original Allocated Date.  When a new Revenue Event is created, use an event date that is retroactive to the original date.

 

The new revenue will “catch-up” in the currently open accounting period upon generation.

 

 

 

 

MANAGING PERFORMANCE BASED REVENUE RECOGNITION

Accounting Standards Codification (ASC) 606

-CURRENT UPDATES-

This paper provides an update to one of our previous six-part blog series “Are you Ready for the New Revenue Recognition Standards?”

It outlined the May 28, 2014 announcement that the FASB and IASB jointly issued ASC 606, Revenue from Contracts with Customers.  The intention around this change was to standardize revenue recognition practices across industries as existing practices fall short when it comes down to how value is delivered to the client based on obligations explicitly or implicitly specified in contracts.

IN THIS LATEST SERIES, WE WILL RECAP AND HIGHLIGHT THE MOST CURRENT CHANGES SINCE THE DEADLINES FOR COMPLIANCE HAS PASSED.

On May 28, 2014, FASB and IASB jointly issued ASC 606, Revenue from Contracts with Customers.  Due to inconsistencies in revenue recognition among industries, and the disconnect between U. S. GAAP and IFRS reporting, the Boards collaborated to reduce or eliminate those inconsistencies and thereby improve comparability between domestic and international best practices.  The resulting standards will therefore significantly affect the revenue recognition practices of many companies.

Depending upon the business’ current model and revenue recognition practices, this standard could have a significant impact on the amount and timing of revenue recognition, which in turn will impact key performance measures and debt covenant ratios, and may even change the way the company looks at capital investment and compensation.  The new standards are poised to change budgets, contract negotiations and current business practices.

Industry-Neutral Revenue Recognition

The core principle in the converged standard requires that an entity recognize revenue to depict the transfer of promised goods or services to a customer in an amount that reflects the consideration in exchange for those goods and services.  To accomplish this goal, a five-step process has been outlined in the new standard.  Every contract with a customer should be analyzed using these five steps to afford accurate reporting.

Step 1 – Identify the Contract with the Customer – A contract is defined as an agreement between two or more parties that creates enforceable rights and obligations.  The guidance applies to all contracts that meet specific criteria as defined within the standard.

Step 2 – Identify the Performance Obligations in the Contract – Performance obligations are promises to deliver certain goods and services to a customer.

Step 3 – Determine the Transaction Price – The transaction price is the amount an entity is expected to receive in exchange for transferring goods and services to a customer.

Step 4 – Allocate the Transaction Price – The relative standalone transaction price of each good or service being transferred to a customer, including discounts and other variable amounts of consideration.

Step 5 – Recognize Revenue as Performance Obligations are Satisfied – This step happens when the goods or services are transferred to the customer.  The customer will have taken control of the goods or services at this time.  The amount of revenue that is recognized is the amount allocated to satisfy a performance obligation.

HOW CAN WE HELP YOU SUCCESSFULLY NAVIGATE THROUGH THESE CHANGES?

Project Partners will demonstrate how project-centric companies, using Oracle Projects and/or Oracle Project Contracts, can comply to the new standards with minimum disruption to existing business practices.  View 5-Step recap below.

ASC 606:  REVENUE FROM CONTRACTS WITH CUSTOMERS

PART 1

The core principle in the converged standard requires that an entity recognize revenue to depict the transfer of promised goods or services to a customer in an amount that reflects the consideration in exchange for those goods and services.  To accomplish this goal, a five-step process has been outlined in the new standard.  Every contract with a customer should be analyzed using these five steps to afford accurate reporting.

STEP 1   IDENTIFY THE CONTRACT WITH A CUSTOMER

The new revenue guidance defines a contract as an agreement between two or more parties that creates enforceable rights and obligations.  Essentially, all parties to the contract have to approve the agreement, are committed to fulfilling their obligations, and have Identifiable rights.  The contract must have commercial substance and collectability is probable.

STEP 2   IDENTIFY THE PERFORMANCE OBLIGATIONS IN THE CONTRACT

This step requires an entity to identify all the distinct performance obligations in a contract or arrangement.  A performance obligation (commonly referred to as deliverables) is a promise to transfer goods or services to a customer.  A good or service is distinct when the customer can benefit from said good or service on its own or with resources the customer already has, and the good or service can be transferred to the customer independent of other performance obligations in the contract.  Goods and services that are not distinct should be combined with other goods or services until the whole group is distinct.

To be distinct, a good or service must meet two criteria:

  1. It must be capable of being distinct, and
  2. It must be separately identifiable.

STEP 3   DETERMINE THE TRANSACTION PRICE

The Transaction Price is the amount of consideration an entity expects to receive for the transfer of goods or services to the customer.  The amount can be fixed, variable or a combination of both.  Transaction Price is allocated to the identified performance obligations in the contract.  These amounts are what are recognized as revenue when the performance obligation is fulfilled.

STEP 4   ALLOCATE THE TRANSACTION PRICE

Allocation of the Transaction Price comes into play when a contract contains more than one performance obligation.  The seller should allocate the total amount of the selling price to each performance obligation based on its relative Standalone Selling Price (“SSP”).  The Standard permits any method of allocation of the SSP, just as-long-as that estimation is an accurate representation of what price would be charged in separate transactions.

STEP 5   DELIVER SERVICES AND RECORD OUTCOME

The last step in the new revenue recognition standard is to recognize revenue when or as the performance obligations in the contract are completed.  A performance obligation is completed when or as control of the good or service is transferred to a customer.  The Standard defines control as “the ability to direct the use of and obtain substantially all of the remaining benefits from the asset.” (ASC 606-10-20).

The Standard allows for revenue recognition based upon two methods for measuring progress, Output and Input.

Outputs are the result of inputs and processes   of a business and are goods or services finished and transferred to the customer.  The output method measures results achieved.  Surveys, appraisals, milestones reached, and units produced or delivered are all examples of output methods.  Value to the customer is the objective measure of an entity’s performance.

Examples of an output method would include the number of feet of pipe used for a specific distribution project, or the number of electrical poles used from a transmission plant, to a final destination.

The input method is a more indirect measure of satisfying a performance obligation.  Inputs are measured by determining the amount of effort put into completing the contract.  The input method is implemented by estimating the inputs required to satisfy a performance obligation, and then comparing the effort expended to date against that estimate.

Examples of input methods would be cost-to-cost, labor hours, or material quantities.

The Board decided that, at least conceptually, an output measure is the best depiction of the entity’s performance because it directly measures the value transferred to the customer.  Although the Boards did not state that the output method is the preferred method, they felt that in most cases it is the most appropriate method that is consistent with recognizing revenue as value is transferred to the customer.  A drawback to this method is that there may not always be a directly observable output to reliably measure progress.

 

CLICK HERE for a more in-depth discussion of this topic and read full posts to the ASC 606 Series on our website.

CONTINUE TO NEXT POST 2 OF 2…

“Let’s take another in-depth look at how to use Oracle to comply with the newest revenue recognition rules”  

 

www.projectp.com | Phone: +1.650.712.6200

 

 

 

Providing Our Customers With Better Project Delivery Through Full-Service…

PROJECT APPLICATION | PROCESS ASSESSMENTS

Whether helping you uncover hidden project challenges stemming from your current functional and operational applications/processes to understanding the why and how to migrate to the cloud, our PROJECT APPLICATION/PROCESS ASSESSMENT services give you the rigorous framework you need to achieve success quickly.

We Will Partner With You to Assess Your Project Applications and Background Processes Inside and Out. 

Projects is the link that can penetrate your entire organization and requires careful analysis to maximize efficient operations.  If you are experiencing what appears to be a pain in your organization’s business process and applications, then now is the time to take another look and assess with the experts.

SPECIAL ASSESSMENT OFFER

With Your SIMPLE next steps to obtain Project Partners holistic approach to a full assessment and associated discount offer.

PROJECT PARTNERS PROUDLY ACHIEVES PLATINUM PARTNER STATUS IN
ORACLE PARTNERNETWORK (OPN)

HALF MOON BAY, Calif., January 16, 2019 – Project Partners, a global leader in optimizing business processes and IT investments within project-driven organizations, today announced that it has achieved Platinum partner status in Oracle PartnerNetwork (OPN).  By attaining Platinum level membership, Oracle has recognized Project Partners for its in-depth expertise and continued excellence in providing services for Oracle applications and technology.

“We are honored to be in the highest level of the OPN Program. With our new designation as a Platinum Partner in the Oracle PartnerNetwork (OPN), Project Partners will continue to strengthen and build upon its 20+ year relationship with Oracle,” said Randy Egger, President/CEO, Project Partners.  Our global team has continually demonstrated deep application expertise and are working to obtain additional certified specializations across Oracle application solutions areas to better serve our project-centric customers.”

The company offers deep industry expertise across key Oracle applications and technologies including the Oracle ERP Cloud, Oracle E-Business Suite, and Oracle Primavera applications.  In addition, we have developed products and solutions to support and augment our customers’ off-the-shelf products.  We are proud to be widely recognized as The Experts in Solutions for Project-Driven Organizations™ and look forward to continuing collaboration, sharing industry experiences and leveraging our Platinum Partner status to enable organizations, partners and Oracle.

With its Platinum status, Project Partners will benefit with the high level of engagement, commitment and resources available to OPN partners.  Platinum members receive dedicated virtual account management support to build joint development plans and help broaden specialization areas and revenue opportunities. Additional benefits include priority placement in the OPN Solutions Catalog, one free application integration validated by Oracle, joint marketing and sales opportunities, discounted training and more. For more information about the benefits of becoming an OPN Platinum level partner, please visit: http://www.oracle.com/us/partnerships/index.htm

———————————–

About Project Partners, LLC.

Headquartered in Half Moon Bay, California | Project Partners is the global leader in optimizing business processes and IT investments within project-driven organizations. We are dedicated to helping businesses achieve their goals with smart, effective and scalable Oracle Application solutions that improve processes and deploy technology to maximize project life cycle ROI. Our business process experts understand and support customers with their evolving business models and help them drive productivity to meet the demands of the market and their organization.

Project Partners has a diverse team who is expert in leveraging Oracle’s ERP Cloud, E-Business Suite and Primavera solutions. We have global locations worldwide to support multi-geographical operations and have executed implementations for hundreds of clients who manage tens of thousands of projects, thousands of users, multiple languages and currencies. In addition, we have developed products and solutions to support and augment our customers’ off-the-shelf products.  Project Partners is proud to be widely recognized as The Experts in Solutions for Project-Driven Organizations™.

Project Partners is a proud Oracle Platinum Partner, Oracle Certified Education provider and authorized Reseller of Primavera and Oracle Cloud PPM, and Cloud Financials.  We hold an Oracle Cloud Standard certification, with specializations in Oracle® E-Business Suite™ with Projects, Primavera and Oracle Validated Integration’s in EBS.

For more information, visit: http://www.projectp.com/

———————————–

About Oracle PartnerNetwork

Oracle PartnerNetwork (OPN) is Oracle’s partner program that provides partners with a differentiated advantage to develop, sell and implement Oracle solutions. OPN offers resources to train and support specialized knowledge of Oracle’s products and solutions and has evolved to recognize Oracle’s growing product portfolio, partner base and business opportunity. Key to the latest enhancements to OPN is the ability for partners to be recognized and rewarded for their investment in Oracle Cloud. Partners engaging with Oracle will be able to differentiate their Oracle Cloud expertise and success with customers through the OPN Cloud program – an innovative program that complements existing OPN program levels with tiers of recognition and progressive benefits for partners working with Oracle Cloud.

To find out more visit: http://www.oracle.com/partners

 

# # #

 

_________________________________________________________________________________________________________

 Project Partners Blog Author: Donna Dignam | Principal Functional Consultant 
____________________________________________________________________________________________________________________

In April 2015, FASB (Financial Accounting Standards Board) issued ASU (Accounting Standards Update) 2015-05 to assist entities to determine when a customer in a cloud computing arrangement “CCA” (i.e. hosting arrangement) included a software license.

If a CCA includes a license to internal use software, the software license is accounted for by the customer as an intangible asset.  Basically, the intangible asset is recognized for the software license, and the payments or said license made over time are recognized as a liability.  If no software license is included in the contract, the company should account for the arrangement as a service contract, and the fees associated with the hosting service of the arrangement are expensed as incurred.

The Update did not give any guidance regarding the implementation costs for activities performed in a cloud computing arrangement as a service contract.  Since the FASB guidance in this area was not explicit, the Board decided to issue an Update to specifically address the resulting diversity in practice.

Who Is Affected by ASU 2018-154?

These Amendments on the accounting for implementation, setup and other upfront costs (commonly referred to as implementation costs) apply to entities that are a customer in a hosting arrangement that is a service contract.  Oracle Cloud computing arrangements where a license is sold to the customer along with a hosting arrangement with Oracle Cloud would be one such customer.

Main Provisions of ASU 20184

The Update’s intent is to align the requirements for capitalizing implementation costs incurred in a hosting arrangement that is a service contract with the requirements for capitalizing implementation costs incurred to develop or obtain internal use software and hosting arrangements that include an internal-use software license.  The current accounting for the service element of a hosting arrangement is not affected.

It is up to the company to determine which implementation costs to capitalize as an asset related to the service contract and which to expense.  Costs to develop or obtain internal use software that could not be capitalized under Subtopic 350-40, such as training costs and certain data conversion cost, also cannot be capitalized for a hosting arrangement that is a service contract.  The company in a hosting arrangement that is a service contract determines which project stage an implementation activity relates to.  Project stages include preliminary project stage, application development stage or post implementation stage.  Costs incurred for the application development stage are capitalized, while those costs related to the preliminary project stage or the post implementation stage are expensed as the activities are performed.

In addition, the company is required to amortize the capitalized implementation costs over the terms of the hosting arrangement.  The term of the hosting arrangement includes the noncancellable period of the arrangement plus periods covered by:

  1. Option to Extend – customer must be reasonable expected to exercise this option
  2. Option to Terminate the Arrangement – where the customer is reasonably expected NOT to exercise this option
  3. Option to Extend or Not to Terminate – where the vendor has control of exercising the option.

Impairment guidance, as if the costs were long-lived assets, and abandonment are to be applied based upon the existing guidance in SubTopics 350-40 and 360-10, respectively.

Income Statement presentation by the entity should be the same line item as the fees associated with the hosting service of the arrangement.  Similarly, classification of payments for capitalized implementation costs in the Statement of Cash Flows are done in the same manner as payments made for fees associated with the hosting arrangement.  In the Statement of Financial Position, capitalized implementation costs are presented in the same line item that a prepayment for fees associated to the hosting arrangement would be presented.

How is This Different and Why is it an Improvement?

Currently, GAAP does not specifically address accounting for implementation costs associated with a HASC.  Therefore, the Update improves current GAAP as it clarifies accounting and aligns the accounting for implementation costs for hosting arrangements, regardless of whether a license is conveyed.

For consulting firms, the new standards present an improved selling point as costs that were previously required to be expensed can now be capitalized.  For capital intensive industries, where cloud applications are being considered and dismissed due to financial considerations around increased expenses (and resulting decreased profitability metrics) due to cloud implementation, the new standard allows a way to capitalize the costs associated to both the license and the implementation and development costs around getting that application stood up.

When Does This New Update Take Affect?

For public entities, the amendments are effective for fiscal years beginning after December 15, 2019 and interim periods within those fiscal years. For all other entities, annual reporting periods beginning after December 15, 2020, and interim periods within annual periods beginning after December 15, 2021 are required.  Early adoption is permitted at any time.

The amendments in this Update should be applied either retrospectively or prospectively to all implementation costs incurred after the date of adoption.

Have Questions?
Simply reach out to us and our experts will immediately assist, provide additional information,
and answer any of your questions.

P: #1.650.712.6203  |   Email: cfryc@projectp.com

 

Author: Wendy Lamar | Managing Principal Consultant | Project Partners
Oracle E-Business Suite R12 Project Certified Implementation Specialist


Through this three (3) part educational web-series, Project Partners will arm you with critical steps and insight into a Project Financials cost-effective solution. This unique solution offering will assist administratively burdened organizations like yours to effectively manage Project Financials around Capital spend through all phases of the Capital Lifecycle (Concept Definition, Funding Approvals, Execution, Reporting, and Managing Project Costs).

WHY CAPITAL PROJECTS? – WEBINAR REGISTRATION INFORMATION

CLICK TO REGISTER HERE for our FINAL PART (3) of the three (3) part series as we explore how Project Partners has addressed the pain associated with AFE’s and the manual efforts.  We will showcase how we’ve developed an easy to use Authorization for Expenditure solution that extends the functionality of Oracle EBS Projects applications and walk you through the solution focused around project costing to your specific business requirements, robust functionality, and use of authorizations for expenditures to further efficiency gains and extensive return on investments.

MISSED PART 2?  Don’t Worry…CLICK HERE to get a downloadable recording so you will be up-to-speed!   

Have Questions?
Simply reach out to us and our experts will immediately assist, provide additional information, and ensure you have associated playbacks. We look forward to your attendance, and will set up a call to fully understand your needs, and offer next steps around a Project Financials cost-effective solution that best fits your organization.

P: #1.650.712.6203 Email: cfryc@projectp.com

This blog is part of a series where we examine the impacts of ASC 606, Revenue from Contracts with Customers, and introduce the use of Oracle Projects as a solution for facilitating compliance with the new revenue recognition standards and five-step process.

Previous posts in our revenue recognition blog series include: Introduction to Achieving ASC 606 ComplianceStep 1: Identify the Contract with the CustomerStep 2: Identify Performance Obligations in the Contract, Step 3: Determine the Transaction Price – Revenue Recognition Standards, Step 4: Allocate the Transaction Price, and Step 5 (Part One): Recognize Revenue as Performance Obligation is Satisfied.

Step 5 Recognize Revenue as Performance Obligation is Satisfied

In part one of Step 5, we discussed the various items that need to be taken into consideration for Compliance.  One of the key concepts discussed was the determination of Input and Output Progress Methods to properly record outcome of services delivery.  To conclude the discussion on Step 5 we will discuss the methods for properly measuring progress so that outcome is accurately recorded and provide case studies for the various methods of progress measurement.

Methods for Measuring Progress

After determination that a performance obligation is satisfied over time, an entity must determine how far complete the entity’s progress is at any given reporting period.  This is referred to in the new Standard as Measure of Progress.

For example, if a calendar year reporting entity enters into a software support agreement for a 12 month period beginning on January 1, there are three ways an entity can measure progress:

  1. Based upon costs incurred, which is the physical percent complete of costs incurred to the total expected costs of the contract.
  2. Based on labor hours – in which the number of hours are incurred each month are a percentage of the total hours estimated for the year.
  3. Based on time elapsed – where the revenue is generated as 1/12 of the total contract value each month.

The object when measuring progress is to depict an entity’s performance in transferring control of goods or services promised to the customer. (ASC 606-10-25-31)

Selecting a Method to Measure Progress

When performance obligations are satisfied over time, an entity must determine a single method of measuring progress toward the completed satisfaction of the obligation. The objective is to transfer the control of the goods or services to the customer.  To accomplish this, the entity selects either the output or input method and applies it consistently to similar performance obligations.  Both methods are acceptable under the new standard, but they are not interchangeable.

The method used must be appropriate for the circumstances of the contract, as it can result in material differences in the timing of revenue recognition.  Careful determination of which method best reflects the substance of the contract should be considered.

The Output method is based on the direct measurement of the value of the goods or services transferred to date, relative to the other goods or services promised under the contract.  In Oracle Projects, these measurements are referred to as Physical Percent Complete, Milestones and Schedule of Values, and Deliverables.

The Input method is based upon the entity’s efforts toward satisfying a performance obligation relative to the total expected input to the satisfaction of that performance obligation.  In Oracle Projects, these measurements are referred to as Cost to Cost Revenue and Time and Materials.

The Standard allows an entity, in certain contracts that have the right to bill an amount for each unit of service provided, to recognize revenue for the amount being billed.  This is referred to in the Standard as a “practical expedient”.  In this instance, the entity has the right to invoice a customer at an amount equal to its performance to date.  This amount does not need to reflect the fixed amount per unit for this to be applied.  The invoiced amount should directly correspond to the value that is transferred to the customer.

If an entity’s inputs are incurred evenly over time, then it may be appropriate to recognize revenue on a straight-line basis (for example in the case of a 1-year fixed amount contract).

Determining which measure of progress to apply is not a free choice.

An entity needs to exercise judgment in identifying a method that fulfills the stated object of the new standard.  The Standard requires the entity to select a method consistent with the objective of depicting its performance.  The entity needs to consider the nature of the good or service that it has promised to transfer to the customer.

Examples are given within the standard of circumstances where a particular method does not necessarily depict performance.  (Units of production may not be appropriate where there is a material amount of work in progress.)  In addition, an entity must be able to apply a method that is both reliable and relevant.  If the information used to apply the output method is not directly observable or would require a large cost to obtain, then the input method may be appropriate.  In these cases, judgment is required to identify the appropriate method to use.

Neither method is preferred over the other since both methods have advantages and disadvantages that make them more or less appropriate to the facts and circumstances of the contract.  While the output method is generally preferable, a measure of output may not always be directly observable or provide an appropriate measure of performance.  While the new standard does not prescribe which method to use, the entity should select an approach that depicts its performance in transferring control of goods and services promised to a customer.

Single Measure of Progress

Significant judgment and understanding of the nature of the promise to the customer is key to selecting a reasonable measure of progress.  The new Standard requires a single method of measuring progress for each performance obligation.  If multiple performance obligations are to be transferred to the customer over time, this may prove to be difficult.

The entity needs to consider the assessment of performance obligations and whether there are multiple distinct obligations or a single obligation.  Using multiple methods of measuring progress for the same performance obligation is not appropriate.  Therefore, for a single performance obligation, regardless of the number of goods or services and payment streams, the entity is required to identify a single measure of progress that appropriately depicts its progress toward complete satisfaction of that performance obligation.

Should it prove difficult to identify a single measure of progress that accurately determines progress toward satisfaction due to the number of goods and services that make up the performance obligation, the entity may need to reassess the performance obligations identified in the contract to see if there are more performance obligations than originally identified.  If so, each performance obligation can be taken on its own merit when determining the appropriate method to use for revenue recognition.

In addition, when determining the appropriate method for measuring progress, an entity should be aware that the standard requires them to apply the same method to all similar performance obligations in similar circumstances.

Subsequent Measurement of Measure of Progress

Since estimates of an entity’s level of progress will change as the performance obligation is fulfilled, such estimates should be updated with the most current information available.  Changes in estimates should be accounted for in a manner consistent with the guidance on accounting changes which states that changes in accounting estimates shall be accounted for in the period affected by the change and in future periods if the change affects both.  This does not refer to a change in scope or price, but rather a change in an accounting estimate, so the new revenue standards for contract modifications would not apply.

For example:  A company contracts for a fixed price of $2,000,000 and the entity concludes that a cost to cost revenue approach should be used for revenue recognition.  To date, costs incurred total $450,000 with a total cost estimate of $900,000.  If the total cost estimate is dropped to $800,000, the revenue would need to be adjusted to reflect the new estimate as shown here:

  • Revenue recognized to date = ($450K/$900K) * $2M = $1M
  • Adjusted revenue based on new estimate = ($450K/$900K) * $2M = $1.125M
  • Increase in revenue recognized due to change in estimate = $125K.

Oracle Projects functionality allows for the automatic recalculation of recognized revenue. Oracle Projects posts the change to the total to be recognized ($125K) in the current accounting period.  In addition, future revenue streams are calculated using the new accounting estimate, per the new Standards requirements.

Reasonable Measure of Progress

In some circumstances an entity may not be able to reasonably measure progress toward completion as it lacks the reliable information required to apply an appropriate method of measuring progress (such as a long-term contract).  In some circumstances, an entity may not be able to reasonably measure progress but expects to recover the costs incurred in satisfying the performance obligation.

In those instances, the entity should recognize revenue for its progress by recognizing revenue solely in the amount of the costs incurred. This will result in a net margin of zero.  This would only be appropriate until such time that the entity can reasonably measure progress or until the performance obligation becomes too arduous.

When the new revenue standard was being developed, the Board used legacy GAAP as well as measures of progress used in current practice.  Two measures of progress were carried forward in the new standard and will be addressed in detail in a future release in this series.

Comparison of ASC 606 to ASC 605

The key differences between the prior methodology and the new Standard of revenue recognition revolve around Scope, Timing and Control, and Control vs. Risks and Rewards of Ownership.

Scope

The old standard consisted of industry-specific guidance.  The new standard consolidates revenue guidance across most industries, meaning that for all entities with performance obligations satisfied over time, they will be required to select the revenue recognition method that best depicts performance measures in transferring of goods and services to their customers.

Timing and Control

The new standard outlines three criteria that improve upon the distinction between contracts that are satisfied over time and those that are satisfied at a point in time.  To be considered “over time”, the following criteria needs to be met:

  1. The customer simultaneously receives and consumes the benefit provided by the entity as the entity performs.
  2. The entity’s performance enhances or creates assets that the customer controls while the assets are being enhanced/created.
  3. The performance does not create an asset with an alternative use to the entity and the entity has an enforceable right to payment for performance completed to date (ASC 606-10-25:27).

Companies will need to rethink how they recognize revenue depending upon the criteria laid out in the new standard.

Companies that utilized the straight-line method of revenue recognition under the old standard must now choose a method and put in a process to track progress using the chosen method going forward.  Entities must follow the method that best depicts performance in transfer of goods or services, making accounting for contracts more complex.  Reevaluation of the timing of revenue recognitions with customers may be necessary.

Control vs. Risks and Rewards of Ownership

The key issue for revenue recognition is determining exactly when the goods or services are transferred to the customer.  The new standard shifts the focus from the “risks and rewards of ownership” to assessing whether control has been passed to the customer (ASC 606-10-25-25).  This may affect the timing of revenue recognition.

Under the old standard, only construction and production type contracts utilized the input and output methods.  Now, all performance obligations that are satisfied over time, regardless of industry, must use the input and output methods.  The differences between these two methods can result in material differences of revenue being recognized.  Objective judgement is required in deciding which method to apply.

Using Oracle Projects to Meet the Objectives Of Step 5 of ASC 606

Case Studies

In our previous blogs on ASC 606 Revenue Recognition, we described three types of contracts typical to service delivery organizations:

  • Service Contracts based on selling hours (Time & Expense-“T&E”): In this scenario, the delivery organization contracts to provide a specified number of hours of specialized resources to meet the client’s requirements. There are no specific deliverables listed in the contract. These types of contracts are slowly disappearing as clients demand more specifics before signing contracts.
    • Pure Professional Service Organizations (“PSO”) – Management Consulting
  • Time & Material (“T&M”) Service Contracts based on specific Deliverables AND Fixed Price Service Contracts based on Milestones: These are very typical service contracts. They are combined together here even though they have completely different billing methods because they will need to be treated the same for revenue recognition purposes under the new standard. Additional contract types, such as Cost Plus or some variant of this with different types of fees, will also fall under this category for Revenue Recognition as long as these contracts all specify obligations or deliverables on the service provider.
    • PSOs, Engineering, IT Services, Marketing/Advt. Services
  • Unit Price Based Contracts: Commonly referred to as Schedule of Values (SOV) contracts. These contracts typically specify numbers of units to be delivered for one or more types of items after an initial design/confirmation period.
    • Construction, ATO/ETO based Manufacturing Firms
    • Schedule of Values functionality is delivered in release 12.2.5

We will continue to Steps 5 using the case studies previously discussed.

In Oracle Projects, Step 5 of the Standard requires a two-step approach.   Work is performed and delivery is recorded in Oracle Projects.  Then, a process to Generate Draft Revenue for the projects is run to complete the recognition process.

Service Contracts based on selling hours (T&E)

  • Delivery Team Charges Time & Expenses to the Project

Service Contracts based on selling hours

Run the Generate Draft Revenue Process for your projects to recognize revenue:

  • Service Contracts based on selling hours (T&E)
    • Revenue based on hours charged

Perform Work and Record Delivery

T&M Service Contracts based on specific Deliverables and Fixed Price Service Contracts based on Milestones

  • Mark Deliverable As Complete. Mark Billing Action as Complete

Run the Generate Draft Revenue Process for your projects to recognize revenue:

  • T&M/Fixed Price Service Contracts
    • Billing Events Generated from Deliverables are used to generate Revenue

Unit Price Based Contracts

  • Enter Progress and record Quantity completed for each SOV Task

Run the Generate Draft Revenue Process for your projects to recognize revenue:

Unit Price Based Contracts

  • Billing Events Generated from SOV Progress are used to generate Revenue

As you can see Oracle Projects provides the ability to configure your projects to meet the requirements of Step 5 of the new ASC 606 guideline with standard functionality.  In the next blog in the series we will cover Contract Modifications.

Oracle Licensing Requirements

  • Project Costing and Billing are required for all features discussed in this paper
  • Project Planning and Control must be implemented to leverage Deliverable functionality
  • Schedule of Values functions are available in Oracle Project Planning and Control release 12.2.5

Learn more on managing ASC 606 revenue recognition with Oracle E-Business Suite (EBS) Projects –
Read the white paper
View the presentation

Questions?
Contact Us!

This blog is part of a series where we examine the impacts of ASC 606, Revenue from Contracts with Customers, and introduce the use of Oracle Projects as a solution for facilitating compliance with the new revenue recognition standards and five-step process.

Previous posts in our revenue recognition blog series include: Introduction to Achieving ASC 606 ComplianceStep 1: Identify the Contract with the CustomerStep 2: Identify Performance Obligations in the Contract, Step 3: Determine the Transaction Price – Revenue Recognition Standards, and Step 4: Allocate the Transaction Price

Step 5 Recognize Revenue as Performance Obligation is Satisfied

Deliver Services and Record Outcome

The final step required for recognizing revenue is Step 5: Recognize Revenue as Performance Obligation is Satisfied. In this blog, we will review an additional step pertaining to the delivery of services and recording completion of the performance obligations identified that must be addressed before final revenue recognition can take place.

A performance obligation is satisfied when or as control of the good or service is transferred to a customer.  The Standard defines control as “the ability to direct the use of, and obtain substantially all of the remaining benefits from the asset.” (ASC 606-10-20).

Performance obligations that are fulfilled at a point in time are fulfilled when that obligation is satisfied.  For performance obligations that are satisfied over time, the entity must decide how to appropriately measure the progress and completion of the performance obligation.

The following issues should be considered when applying Step 5 of the Standard:

Performance Obligation Satisfied Over Time

Entities are required to make the determination as to whether each performance obligation in a contract is satisfied over time.  Any obligations not completed over time are assumed to be satisfied at a point in time.  To be considered “over time”, the following criteria needs to be met:

  1. The customer simultaneously receives and consumes the benefit provided by the entity as the entity performs.
  2. The entity’s performance enhances or creates assets that the customer controls while the assets are being enhanced or created.
  3. The performance does not create an asset with an alternative use to the entity and the entity has an enforceable right to payment for performance completed to date (ASC 606-10-25:27).

 

Transfer of Control

An entity must determine when control is transferred to the customer in order to determine when revenue should be recognized.  The Standard provides several examples of indicators that the transfer of control has occurred and these should be considered when determining when to recognize revenue.

Transfer of control indicators - Revenue Recognition step 5

Input vs Output Methods

Entities can use either the input or output measure when satisfaction of a performance obligation occurs, whichever is the better indicator.  The output method measures progress by results achieved, such as miles of electrical distribution lines completed.  The input method measures progress based on the materials consumed, such as the feet of electrical cable used.  The Standard prefers the output method as it tends to better reflect the transfer of goods and services to the customer.  However, if an alternative method better represents the transfer of goods and services, the Standard will allow its use.  (For more in-depth information on revenue recognition methods, please refer to Input vs. Output Methods for Measuring Progress, below.)

Stand-Ready Obligations

Promises by an entity to stand ready to perform a service or transfer a good can sometimes constitute a performance obligation. The entity will need to determine what method is appropriate to use to recognize revenue.

Consignment Arrangements

Revenue should not be recognized until control is transferred from the company to either the intermediary or to a customer through the intermediary.

Consignment arrangement revenue recognition step 5

Bill and Hold Arrangements

Unlike consignments, the customer has purchased goods from a company and requested that the goods be held by the entity until the customer is ready to receive them.  The Standard has simplified the prior criteria for when revenue is to be recognized under this arrangement, but the end result is expected to be the same for the majority of transactions.

Input vs. Output Methods for Measuring Progress

Output Methods

One of two methods for measure progress, the output method “recognizes revenue on the basis of direct measurements of the value to the customer of goods or services transferred to date, relative to the remaining goods or services promised under the contract” (ASC 606-10-55-17).

Outputs are the result of inputs and processes of a business and are goods or services finished and transferred to the customer.  The output method measures results achieved.  Surveys, appraisals, milestones reached, and units produced or delivered are all examples of output methods.  Value to the customer is the objective measure of an entity’s performance.

The Boards decided that, at least conceptually, an output measure is the best depiction of the entity’s performance because it directly measures the value transferred to the customer.  Although the Boards did not state that the output method is the preferred method, they felt that in most cases it is the most appropriate method that is consistent with recognizing revenue as value is transferred to the customer.  A drawback to this method is that there may not always be a directly observable output to reliably measure progress.

Units-of-production or units-of-delivery methods may not be appropriate in contracts that provide design and production services as the transfer of produced items may not correspond to the actual progress made on the entire contract.  To determine if these methods are acceptable, the entity should carefully consider all the facts and circumstances of the arrangement and how value is transferred to the customer.

Examples of an output method would include the number of feet of pipe used for a specific distribution project, or the number of electrical poles used from a transmission plant to a final destination.

Practical Expedient for Measuring Progress

The Standard provides a special output method of revenue recognition called a “practical expedient”.  A practical expedient can be applied to performance obligations that meet the criteria in Step 5 for obligations satisfied over time. This measure is commonly referred to as the “invoice practical expedient” since it allows an entity to recognize revenue in the same amount to which the entity is entitled to invoice to the customer, when that invoice amount directly corresponds to value transferred to the customer.  If this requirement is not met, the practical expedient cannot be applied.  In addition, the practical expedient can only be applied to performance obligations satisfied over time, not at a point in time.  An example would be a service contract in which an entity bills a fixed amount for each hour of service provided.

In the case where the unit price varies during the contract period or a contract where the rate varies during the contract period, the practice expedient can be used as the changes reflect the value to the customer of each incremental good or service.

Input Method

“Input methods recognize revenue on the basis of the entity’s efforts or inputs to the satisfaction of a performance obligation relative to the total expected inputs to the satisfaction of that performance obligation.”  (ASC 606-10-55-20)

The input method is a more indirect measure of satisfying a performance obligation.  Inputs are measured by determining the amount of effort put into completing the contract.  The input method is implemented by estimating the inputs required to satisfy a performance obligation, and then comparing the effort expended to date against that estimate.  Examples of input methods would be cost-to-cost, labor hours, or material quantities.

When choosing the input method for revenue recognition, there are several issues the entity needs to consider.

Inefficiencies and Wasted Materials

Even through an entity may decide that the input method is the most appropriate method to measure progress, there may be times when inefficiencies or wasted materials do not contribute to the satisfaction of the performance obligation.  Abnormal waste costs do not represent additional progress toward completion of an entity’s performance obligation and, if revenue is recognized over time, should be excluded from the measurement of such progress.  If the entity is using costs incurred to date as an input method, it should be careful to ensure that revenue is not increased to offset the additional costs incurred when abnormal or excessive costs arise as a result of inefficiency or error.

Uninstalled Materials

One of the problems with the input method is that the correlation between the inputs and the transfer of control of a good or service to the customer may not have a direct relationship.  A customer may obtain control of the good significantly before receiving services related to the good.  For example, a piece of equipment for which the entity is also providing installation, may be transferred to the customer before the installation is done.  In this instance, the equipment and installation are component parts of the overall project being provided to the customer.  Since it may be difficult for the entity to determine the amount of revenue to recognize for the delivery of the equipment, and since the equipment is no longer a part of the entity’s inventory, the Boards have deemed it appropriate to only recognize revenue in the amount of the cost of the equipment transferred and not include any amount of profit margin (cost-to-cost measure of progress).

As you can see Oracle Projects provides the ability to configure your projects to meet the requirements of Step 5 of the new ASC 606 guideline  using standard functionality.  In the next blog in the series we will cover Step 5b: Recognize Revenue as Performance Obligation is Satisfied – Methods to Properly Measuring Progress.

Oracle Licensing Requirements:

  • Project Costing and Billing are required for all features discussed in this paper
  • Project Planning and Control must be implemented to leverage Deliverable functionality
  • Schedule of Values functions are available in Oracle Project Planning and Control release 12.2.5

Learn more on managing ASC 606 revenue recognition with Oracle E-Business Suite (EBS) Projects –
Read the white paper
View the presentation

Questions?
Contact Us!

Project Partners’ blog series examines the impacts of the ASC 606 revenue recognition standards and how the use of Oracle E-Business Suite (EBS) Projects can facilitate compliance with the new standards. We continue here by discussing the fourth step to revenue recognition under the new standard: Allocate the Transaction Price.

Part of our ASC 606 New Revenue Recognition Standards blog series. Previous posts include: Introduction to Achieving ASC 606 ComplianceStep 1: Identify the Contract with the CustomerStep 2: Identify Performance Obligations in the ContractStep 3: Determine the Transaction Price – Revenue Recognition Standards.

ASC 606 Revenue Recognition Standard Step 4 Allocate the Transaction Price

Step 4: Allocate the Transaction Price comes into play when a contract contains more than one performance obligation.  The seller should allocate the total amount of the selling price to each performance obligation based on its relative Standalone Selling Price (“SSP”).  The Standard permits any method of allocation of the SSP as long as the estimation is an accurate representation of what price would be charged in separate transactions.

ASC 606 does mention three acceptable methods of allocation, discussed in their section on SSP.  These methods include adjustment market assessment, expected cost plus margin and residual.

Allocating Variable Consideration and Volume Discounts
If the contract includes any variable consideration or discounts, and there are multiple performance obligations in the contract, the consideration should only be allocated to the performance obligation to which it is related.

Using Oracle EBS Projects to Meet the Objectives of Step 4 of the ASC 606 Revenue Recognition Standards

Again, let’s review the three types of contracts typical to service delivery organizations:

  • Service Contracts based on selling hours (Time & Expense-“T&E”): In this scenario, the delivery organization contracts to provide a specified number of hours of specialized resources to meet the client’s requirements. There are no specific deliverables listed in the contract. These types of contracts are slowly disappearing as clients demand more specifics before signing contracts.
    • Pure Professional Service Organizations (“PSO”) – Management Consulting
  • Time & Material (“T&M”) Service Contracts based on specific Deliverables AND Fixed Price Service Contracts based on Milestones: These are very typical service contracts. They are combined together here even though they have completely different billing methods because they will need to be treated the same for revenue recognition purposes under the new standard. Additional contract types, such as Cost Plus or some variant of this with different types of fees, will also fall under this category for Revenue Recognition as long as these contracts all specify obligations or deliverables on the service provider.
    • PSOs, Engineering, IT Services, Marketing/Advt. Services
  • Unit Price Based Contracts: Commonly referred to as Schedule of Values (SOV) contracts. These contracts typically specify numbers of units to be delivered for one or more types of items after an initial design/confirmation period.
    • Construction, ATO/ETO based Manufacturing Firms
    • Schedule of Values functionality is delivered in release 12.2.5

Now, we’ll use Oracle E-Business Suite (EBS) Projects to complete Step 4, allocate the transaction price across obligations, for each of the three service contracts discussed.

Allocate the total contract price across obligations and set up in Projects as follows:

Service Contracts based on selling hours (T&E)

Setup Hourly Bill Rates and assign to Project.

Step 4 to Allocate the total contract price across obligations

 

Step 4 requires you to setup Hourly Bill Rates and assign to Project

 

T&M Service Contracts based on specific Deliverables and Fixed Price Service Contracts based on Milestones

Setup a Billing Action for each Deliverable and assign a Billing Event type for revenue recognition and allocated price.

Step 4 for Time and Material and Fixed Price Service Contracts

 

Step 4 billing for Time and Material and Fixed Price Service Contracts

Unit Price Based Contracts

For each SOV line, setup a unit price and total line amount based on allocated values.

Step 4 for Unit Price Based ContractsYou will also need to assign each SOV line to a task on your work plan and publish it.

Oracle EBS Projects can be used to help you meet the ASC 606 requirements and achieve revenue recognition compliance. Our New Revenue Recognition Standards blog series demonstrates how project-centric companies can use Oracle EBS Projects to manage and comply to the new standards with minimum disruption to existing business practices.

In the next blog, we will review an operational step in the process Step 5: Recognize Revenue as Performance Obligation is Satisfied – Part 1: Deliver Services and Record Outcomes.

Learn more on managing ASC 606 revenue recognition with Oracle E-Business Suite (EBS) Projects –
Read the white paper
View the presentation

Questions?
Contact Us!