Project Partners Blog


Posts Tagged ‘ASC 606’

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

 

 

 

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

 

# # #

 

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!

Part of our ASC 606 New Revenue Recognition Standards blog series. Previous posts include: Introduction to Achieving ASC 606 Compliance, Step 1: Identify the Contract with the Customer, and Step 2: Identify Performance Obligations in the Contract.

This blog continues our discussion on the impacts of the new ASC 606 revenue recognition standard issued by FASB and IASB and reviews the third step in the five-step model for recognizing revenue from contracts with customers.

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.

Future options for a contract are excluded when determining Transaction Price, as are the amounts third parties will eventually collect, like sales tax.

When dealing with a fixed amount to be received, Transaction Price is easy to determine.  However, other situations require more judgment:

Variable Consideration
If the amount of consideration is subject to change due to timing or other performance factors, it is considered variable.  Examples would be refunds, credits, discounts, incentives and other items of this type.  Since the Transaction Price is an estimate on the amount of consideration an entity expects to receive, any constraints on that amount must be considered.

Significant Financing Component
This occurs when the timing between the receipt of consideration and the transferring of goods/services is more than one year.  The entity must therefore recognize revenue at an amount that reflects the cash payment the customer would have made at the time the goods/services were transferred to them (cash selling price).  Financing components in the Transaction Price therefore considers the time value of money.

Noncash Consideration
If a customer receives payment in a noncash form, then the fair value of the noncash payment is included in the Transaction Price.  If the fair value cannot be determined, the standalone selling price of the goods/services is used.

Consideration Paid or Payable to a Customer
At times the entity will be required to make a payment to the customer, such as with a manufacturers rebate.  This payment reduces the Transaction Price and the revenue recognized.  In some cases, however, this could be considered a purchase expense from the customer.

Nonrefundable Upfront Fees
Membership fees or activation fees for services such as television or internet services are examples of a nonrefundable upfront fee.  These fees are paid in advance for the right to a service or good with no guarantee that the fee payment will be returned.  The entity must make the determination whether the fee relates to a specific transfer of goods/services or a renewal option at a reduced price.  The changes in the new Standard require that all products and services must have a Standalone Selling Price (“SSP”).  This SSP must represent the fair value of the products and services being offered.  All entities need to monitor and adjust their SSP on a regular basis, at least annually.

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

In our previous paper, 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 who in turn will deliver to 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 like 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 contract all specify specific obligations/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 Step 3 using the case studies previously discussed.

T&E Services, including T&M Service Contracts based on specific Deliverables and Fixed Price Service Contracts based on Milestones

The total transaction price identified in the contract will be setup in Oracle as the Project Agreement and the funding of the project from the agreement as shown below:

Unit Price Based Contracts

The total transaction price identified in the contract will be setup in Oracle as the contract amount under the SOV setup.

As you can see Oracle Projects provides the ability to configure your projects to meet the requirements of Step 3 of the new ASC 606 guideline with standard functionality. The next blog in the series we will cover Step 4: Allocate the Transaction Price.

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

Up next – Step 4: Allocate the Transaction Price – Revenue Recognition Standards

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 paper is part of the blog series on the impact of ASC 606 and how the use of Oracle Projects can facilitate compliance with the new revenue recognition standards.  Previous posts on this subject covered an Overview of the ASC 606 and Step 1: Identify the Contract with the Customer.  This paper addresses Step 2: Identify the Performance Obligations in the Contract.

ASC 606 Revenue Recognition Standards 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.

In addition to performance obligations explicitly outlined in a contract, obligations that a customer may expect because of an established business history must be examined.  For example, if a vendor has always provided free shipping to a customer, and the customer therefore expects the goods to be shipped for free, the shipping would represent a performance obligation even though it is not specifically stated in the contract.

How to Determine When a Good or Service 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.

The first criterion is similar to standalone value, originally defined in ASC 605.  The customer should be able to benefit from the good or service on its own or in combination with other resources it has on hand.

The second criterion is a new concept.  The underlying concept in determining whether a good or service is separately identifiable is the notion of “separable risks”.  Separable risks relate to whether the risk associated with the obligation to transfer the goods/services are separate from the risk associated with the transfer of other goods/services.  Interpretation of this concept has varied, and the Board decided that entities should evaluate if promised goods/services represent individual promises or inputs in making up a combined output.

The Standard puts forth three factors that may indicate when goods/services are not separately identifiable and should be combined as one performance obligation:

  1. The entity provides a significant service of integrating the good/service with other goods/services in the contract
  2. The good/service significantly modifies or customizes another good or service in the contract
  3. The good/service is highly interrelated or dependent upon another good or service in the contract.

These factors should not be used exclusively to determine if they are separable, and the Board requires the use of judgment by the entity of all facts and circumstances within the contract.

Factors Affecting an Entity’s Evaluation of Performance Obligations

Principal vs Agent

If other parties are involved in providing goods or services to an entity’s customer, the entity must determine whether its performance obligation is to provide the goods/services themselves (Principal) or to arrange for another party to provide the goods/services (Agent).  This will determine the amount of revenue that the entity can recognize.  If the entity is the principal, it will recognize the gross amount received from the customer, but if the entity is the agent, they can only recognize the amount of fee or commission received for facilitating the sale.  This identification is critical to correctly recognizing revenue in these situations.

Warranties

The new standard now distinguishes two different types of warranties which are accounted for differently.  An Assurance-Type Warranty only guarantees that the good/service functions as promised and is not a distinct performance obligation.  A Service-Type Warranty provides benefits beyond what the Assurance Warranty offers and would create a distinct performance obligation.

Customer Options for Additional Goods or Services

This would pertain to options like customer loyalty points or discounted contract renewals.  If the option provides a material right to the customer, then a distinct performance obligation is created.  A material right is not clearly defined, but must be more than the standard discount available.

Nonrefundable Upfront Fees

This is similar to a customer option.  For example, a customer signs up for a martial arts class with a one-year contract and an upfront fee is charged.  That fee is not required when the customer renews his contract.  Because the second year is being purchased at a “discount”, a material right is created and should be accounted for as a distinct performance obligation.

Stand-Ready Obligations

This can happen either through contract specifications or customary business practices.  This happens when an entity is required to have services ready whenever a customer decides to use them.  An example would be a 24-hour health club.  Revenue received is recognized over the period of time an entity offers the stand-ready service.

Rights of Return

A right of return obligates a customer to accept the product should it be returned.  This adds variability to the transaction price and should be considered when evaluation variable consideration.

Using Oracle Projects to Meet The Objectives of Step 2 of ASC 606

In our previous paper, 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 who in turn will deliver to 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 like 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 contract all specify specific obligations/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
  • SOV functionality is introduced in release 12.2.5

We will continue to Step 2 using the case studies previously discussed.

Service Contracts Based on Selling Hours (T&E)

Budget for contracted number of hours.

Edit budget and forecasts - Service contracts

 

Service Contracts based on selling hours - Identify Performance Obligations for Revenue Recognition

 

Time & Material Service Contracts AND Fixed Price Service Contracts 

Enable and setup deliverables for each performance obligation.

Time and Materials and Fixed Price Service Contracts - Setup deliverable

 

 

Unit Price Based Contracts

Enable Schedule of Values (“SOV”) lines with Type, and Number of each contracted item.

Unit Price Contracts-Enable Schedule of Values-Revenue Recognition Standards


Unit Price Contracts-Schedule of Values-Revenue Recognition Standards

As you can see, Oracle Projects provides the ability to configure your projects to meet the requirements of Step 2, Identify the Performance Obligations in the Contract, of the new ASC 606 guideline with standard functionality.  In our next blog of the series we will cover Step 3: Determine the Transaction Price and Step 4: Allocate the Transaction Price.

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

Up next – Step 3: Determine the Transaction Price – Revenue Recognition Standards

Learn more on managing ASC 606 revenue recognition with Oracle EBS Projects-
Read the white paper
View the presentation

Questions?
Contact Us!

ASC 606, Revenue From Contracts With Customers is the newest revenue recognition standard issued by FASB and IASB. The new standard provides a five-step model for recognizing revenue from contracts with customers. This blog outlines the first step, Identify the Contract with the Customer, and demonstrates how to complete step 1 for the three common contract types.

ASC 606 Revenue Recognition Step 1 - Identify the Contract with the Customer

What is a Contract?
The new revenue guidance defines a contract as an agreement between two or more parties that creates enforceable rights and obligations. The essential parts of a contract include:

  1. All parties have approved the agreement – Contracts may be written, oral or implied by an entity’s normal business practices. Contract enforceability is a matter of law, and as such, an entity should consider the legal jurisdiction in which it operates as the rules for contract enforceability.
  2. All parties are committed to fulfilling their obligations – If each party has the unilateral right to terminate a wholly unperformed obligation, then the standards states that no contract exists. This criterion addresses termination clauses.
  3. Each party’s rights are identifiable – The agreement must clearly identify the goods and/or services to be provided. If this cannot be accomplished, there is no way to determine when a transfer of control has occurred, which is a prerequisite for recognizing revenue.
  4. The contract has commercial substance –This means that a contract can only exist if the risk to the customer, timing of the delivery of goods/services or the amount of cash flows to an entity are expected to change as a direct result of the contract.
  5. Collectability is probable – the new standard requires vendors to evaluate a customer’s credit risk at the inception of the contract. Revenue can only be recognized when payment is likely to be received.

Other Considerations for Revenue Recognition:

Payment for Agreement with No Contract
When payment is received for an agreement that does not qualify as a contract, the vendor can only recognize revenue when one of two events occurs. Either the agreement has been terminated and the payment received is not refundable, or the vendor does not owe any goods or services to the customer and all of the transaction price has been received and is not refundable.

To illustrate: A developer enters into a contract to sell a building to a customer who plans to open a retail shop. The developer receives a non-refundable deposit from the customer. The remaining amount owed is to be paid over time from the shops revenues. There is significant risk that the remaining amount will be collected, so a contract does not exist according to the standard. The upfront deposit cannot be recognized as revenue until substantially the entire remaining amount owed is received, or the shop closes and the contract is terminated.

Combining Contracts

If multiple contracts with the same vendor are entered into at or near the same time and meet at least one of the following criteria, the standards requires the vendor to combine the contracts into one contract.

  • Contracts are negotiated as a single package with one business objective.
  • The payment amount for one contract is dependent on the performance of the other contract.
  • At least some of the promised goods or services in the contracts are a single performance obligation.

ASC 606 gives vendors the option to use the portfolio method of contract combination, permitting vendors to combine contracts that would otherwise not be combined in order to simplify the revenue recognition process. This method will only be allowed if the result is not materially different from accounting for each contract individually.

Contract Modifications

Parties to a contract may change the transaction price and/or scope of the contract. These changes may be accounted for as a separate contract or as a modification to the existing contract, depending upon circumstances. The final part of this series will address contract modifications in more detail.

CASE STUDIES
To demonstrate how to effectively use Oracle EBS Projects to drive compliance with ASC 606 Revenue Recognition standards, the following case studies will be presented for each step outlined in the new revenue standard.

Case Study 1: Service Contracts based on selling hours (T&E)

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 who in turn will deliver to 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. Most often, these contracts are used in Pure Professional Service Organizations (“PSO”) in Management Consulting.

For service contracted based on time & expense billing, the Project would be set up as shown below.
Work Based Revenue Recognition – Accrues revenue as work occurs.

Service Contracts based on selling hours (T&E)

 

Case Study 2:  Service Contracts based on Deliverables / Milestones

Time & Material (“T&M”) Service Contracts based on specific Deliverables AND Fixed Price Service Contracts based on Milestones 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 like 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 contract all specify specific obligations/deliverables on the service provider. These contracts are commonly used by PSOs, Engineering, IT Services, Marketing/Advt. Services organizations.

For Contacts based on specific Deliverables or Fixed Price Contracts based on Milestones, the Projects will be setup as follows:

Event Based Revenue Recognition – Accrues revenue and bills based on events.

Service Contracts based on Deliverables -Milestones

 

Case Study 3: Unit Price Based Contracts
Unit Price Based Contracts: Also 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. These contracts are commonly used by Construction and ATO/ETO based Manufacturing Firms.

  • SOV functionality is introduced in release 12.2.5

For Contacts based on Unit Price, the Projects will be setup as follows:
Schedule of Values Enabled Project – Accrues revenue based upon events defined in a Schedule of Values.

Unit Price Based Contracts

 

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

Oracle Licensing Requirements

Our Revenue Recognition Standards blog series will demonstrate how project-centric companies can use Oracle EBS Projects to manage and comply to the new standards with minimum disruption to existing business practices.

Up next – Step 2: Identify Performance Obligations in the Contract – Revenue Recognition Standards

Learn More on managing ASC 606 revenue recognition with Oracle EBS Projects-
Read the white paper
View the presentation

Are You Ready for the New Revenue Recognition Standards?

Part one of the six-part blog series

On May 28, 2014, FASB and IASB jointly issued ASC 606, Revenue From Contracts With Customers. The new standard will significantly affect current 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.

A few clarifications have been issued subsequently via Supplemental Updates: ASU 2014-09, regarding the effective dates of the new standard. The new standards are effective for public entities and some non-profit companies for the first interim period within the annual reporting periods beginning after December 15, 2017. Non-public entities have an additional year, beginning with interim periods within annual reporting periods after December 15, 2018.

The whole intention here is 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.

These changes are only a few quarters away. Are you ready?

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.

Five Steps to Revenue Recognition

Five steps to ASC 606 Revenue Recognition

There are specific rules defined for each of these steps. Follow our blog series for a deep dive into each of the five required steps.

Mapping the New Standard to Oracle EBS Projects

The following diagram shows how the five steps shown above map to Oracle e-Business Suite (EBS) Projects. The Purple colored steps need a determination to be made by the business based on the contract. The roles involved in this determination include Finance, Legal, Contract Administration and Project Managers.

An additional step (between the original steps 4 and 5) has been added to the overall process that talks to delivery of services and recording of completion of the performance obligations identified, before final revenue recognition can take place.

ASC 606 Customer Contract Revenue recognition Oracle EBS Projects

Contract Types

In order to better understand each of the steps shown above, let’s take into consideration 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 who in turn will deliver to 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 like 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 contract all specify specific obligations/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
  • SOV functionality is introduced in release 12.2.5

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. A case study for each contract type will be used to explain how each step can be interpreted and implemented within Oracle EBS Projects Applications.

Up Next –  Step 1: Identify the Contract with the Customer – Revenue Recognition Standards

Learn more on managing ASC 606 revenue recognition with Oracle EBS Projects-
Read the white paper
View the presentation

Questions?
Contact Us!