Receivables: How to convert invoices that have zero receivables but unearned revenue
A reader asked a question on how to convert the invoices from the legacy system that are already paid by the customer but have deferred (unearned revenue) to be recognized in Oracle after conversion. Thought it makes sense write a post on this topic as the topic has enough to cover.
Basically here is the scenario. Say you have sold service or subscription for entire year in advance. Example is the yearly subscription price I pay in advance for my HBR copy. I pay about 144 USD in advance. What HBR does with this advance payment I make? Basically they had an invoice created on my name for that amount. But since the magazine needs to be delivered 12 months into the future, they have to recognize the revenue appropriately every month for each issue that is delivered. They cannot recognize the revenue in one month for all the144 USD. But I have already paid for it so they apply cash to this invoice thus bringing down the receivables to zero.
Imagine if HBSP was using a legacy system when I was a subscriber and would like to move to Oracle in the middle of my subscription. My subscription is from Jan-09 to Jan-10 and if they are migrating in Aug-09, how will this invoice converted?
In general this invoice is not considered as open because I have already paid for it (usually we convert open invoices only). So the invoice that is converted should have zero outstanding balance but outstanding revenue or in other words deferred or unearned revenue.
Why is this hard? The reason is accounting. Let us take the same example and create accounting entries for the same. In the first month when the invoice is created here is the entry.
|
Account |
GL Date |
Cr |
Dr |
|
Unearned Revenue Account |
01-Jan-2009 |
144 |
|
|
Receivables Account |
01-Jan-2009 |
|
144 |
|
Unearned Revenue Account |
01-Feb-2009 |
|
12 |
|
Revenue Account |
01-Feb-2009 |
12 |
|
|
Unearned Revenue Account |
01-Mar-2009 |
|
12 |
|
Revenue Account |
01-Mar-2009 |
12 |
|
|
Unearned Revenue Account |
01-Apr-2009 |
|
12 |
|
Revenue Account |
01-Apr-2009 |
12 |
|
|
Unearned Revenue Account |
01-May-2009 |
|
12 |
|
Revenue Account |
01-May-2009 |
12 |
|
|
Unearned Revenue Account |
01-Jun-2009 |
|
12 |
|
Revenue Account |
01-Jun-2009 |
12 |
|
|
Unearned Revenue Account |
01-Jul-2009 |
|
12 |
|
Revenue Account |
01-Jul-2009 |
12 |
|
|
Unearned Revenue Account |
01-Aug-2009 |
|
12 |
|
Revenue Account |
01-Aug-2009 |
12 |
|
|
Unearned Revenue Account |
01-Sep-2009 |
|
12 |
|
Revenue Account |
01-Sep-2009 |
12 |
|
|
Unearned Revenue Account |
01-Oct-2009 |
|
12 |
|
Revenue Account |
01-Oct-2009 |
12 |
|
|
Unearned Revenue Account |
01-Nov-2009 |
|
12 |
|
Revenue Account |
01-Nov-2009 |
12 |
|
|
Unearned Revenue Account |
01-Dec-2009 |
|
12 |
|
Revenue Account |
01-Dec-2009 |
12 |
|
|
Unearned Revenue Account |
01-Jan-2010 |
|
12 |
|
Revenue Account |
01-Jan-2010 |
12 |
|
Since the one issue of the magazine will be delivered in this month they need to recognize 12 USD in the month of Jan-09. Also mind that I am paying this invoice. Accounting entries are:
When cash is applied against the invoice:
|
Account |
GL Date |
Cr |
Dr |
|
Receivables Account |
01-Jan-2009 |
144 |
|
|
Cash Account |
01-Jan-2009 |
|
144 |
When revenue is recognized:
|
Account |
GL Date |
Cr |
Dr |
|
Revenue Account |
01-Jan-2009 |
12 |
|
|
Unearned Revenue Account |
01-Jan-2009 |
|
12 |
And this recognition continues till August in the legacy system. In August when we convert the invoice into Oracle, how to convert this? Should we convert the entire balance of receivables and unearned revenue or only the remaining unearned revenue about should be the amount in the invoice to convert?
In general cases are:
1. Invoice is completely paid, and unearned amount is greater than receivables amount (receivables is zero)
2. Invoice is partially paid and remaining receivable balance is less than the remaining unearned amount.
3. Invoice is partially paid and the open balance on the invoice is more than the unearned amount.
Two important things to keep in mind are: how much should be the invoice value in all these cases? This question is relevant because receivables balance is not the same as the original invoice amount in the legacy system. And the second question is which GL date to use? And we need an accounting rule to make this happen. As invoices in the legacy can have different number of periods to recognize revenue, we define this rule as Variable type? As we schedule the revenue as soon the revenue recognition is run, we do not check the deferred flag in the accounting rule.
You can convert the invoice amount as is from the legacy and then use adjustments to reduce the receivables balance to appropriate number(zero or partial). As for the revenue use the rule start date as the equal to the transaction date (as it is in the source). If you keep only current period open gl date will be current for all the past revenue (when revenue recognition is run) and future date for the future periods as per the schedule till the end of it. The future revenue will be recognized on that appropriate date.
But again this falls into bigger picture of your migration strategy and depends on how you convert GL balances for these accounts.
Usually we resort to solutions like creating a new program and sandwiching that program between GL transfer and Journal Import program. It works, but again, we need run the Gl interface program setting the value for the parameter Journal Import as ‘No’. This approach has inherent issues. What should we do if the custom program fails? Should we let the journal import run? If it runs, the objective is failed. On the other hand if you want to stop the journal import from picking the rows, you need to manage the status in the interface table (one way of doing it). This gets complicated as you need to manage all the rows that go in as pair of accounting entries. On top of it the issue gets complicated based on summary posting versus detail posting. So let the journal import manage the business of balancing of accounting entries and let us do our part of managing the rows in the gl_interface table the way we want it.
So this post is to address the first one where the requirement is to update one of the references in gl_interface with the comments from the Miscellaneous Cash Receipts coming from Receivables. This update will happen after your transfer to GL from Receivables and before Journal Import is run. I can understand why this is a common requirement. Usually people who use GL as well as auditors require reasons why the miscellaneous cash was posted. Updating these reference columns makes those comments visible in journal entries screen. Just to warn you, this works only if you transfer from source in Detail and not in Summary mode. See the images of miscellaneous cash receipt and journal entries screen.
But whatever is the nature of the project we have different teams working towards a same goal (question of who is doing what). Each project goes through several stages: from gathering business requirements to production go live (question of when). In this process we go through a number of testing cycles to keep the progress in check.
These questions of who, what and when drives the demand for number instances of eBusiness suite and when they are needed. Typically we go through the following process (simplified) before we go live.
All these setups have to performed manually. These setups are interdependent and need to be setup carefully as some of them are irreversible. Business Accelerators help in these setups to a great extent. You can find more information in the following links.
iSetup is set to change all that.
You can clearly see how isetup streamlines the process by comparing the figures with and without isetup.
Subscribe Via Email