Oracle JD Edwards Revenue Recognition

Revenue Recognition vs. Profit Recognition

The major difference between Revenue Recognition and Profit Recognition is that Revenue Recognition depends on an invoice to trigger the process. Profit Recognition is job and project-centric. Both are ingenious in their design and execution. The modules that “feed into” either process, with the exception of setup, remain visually untouched. For the user community of Accounts Receivable, Sales Order, Contract and Service Billing Invoices and Job Cost entries there are no retraining implications. The heavy lifting is all done behind the scenes.

From the FASB/IASB ruling on, this is a new way of looking at customer service and for E1, a new method for allowing the user community to recognize revenue. As I’m sure we’ve all heard by now, the ruling states that a provider’s revenue can only be recognized when the performance obligation to the receiver of the goods or services has been completed. In the past, in JD Edwards (JDE) revenue was recognized at the time the invoice was created.

Oracle needed to provide us with a choice.

A Case Study

Smartbridge was approached by a new client that requested assistance with Revenue Recognition setup. We started our investigation and discovered that, for the majority of the projects that required this under the FASB/IASB ruling, there was no direct connection between revenue and cost. Invoices created, largely through Contract Billing in this instance, were not correlated to the cost in any way except for being in the same period. While the FASB/IASB ruling doesn’t directly mention cost, it is logical and reasonable to keep the Cost of Goods Sold (COGS) in the same period as the revenue to which it is related. This is a prerequisite for JDE Revenue Recognition to work.

We began looking at alternatives, modifications, etc. and, just before we proposed a solution to the client, Profit Recognition or Revenue Performance Obligation using the data from the Job Cost module was published. While in its infancy, this is exactly what we’d been looking for. The client project then switched focus to Profit Recognition and Job Costing.  As anyone that has ever been a beta test site for any software can tell you, it is a double-edged sword. You are more likely to get attention more quickly, particularly as the deadline for its full-fledged implementation approaches, but you will need it as you are the first to discover the bugs. No software is ever bug-free unless it is mature, tried and true.

Here we are, almost a full year later – it turns out that some of the projects fit well for Revenue Recognition and others, conveniently in another company, are managed and billed to fit the processing of Profit Recognition better. Profit Recognition is working very well. Revenue Recognition, which was the first product, still has two outstanding bugs that we submitted that need to be resolved. However, one very large inconvenience remains with no announced intent to remedy it; if one line of an invoice meets the criteria to be included in Revenue Recognition, the entire invoice is pulled into the Revenue Recognition process.

What does the future hold for Revenue Recognition?

.

INTRODUCTION

CONTRACT, SERVICE BILLING

PROFIT RECOGNITION

LOOKING AHEAD

Keep Reading:  The Scoop on Revenue Recognition for Food Service