Deferred Revenue Recognition

So… huh?

Doesn’t 11.04 not equal 0 ?

I am very new to deferred revenue (we just bought the module), but I’m not new to accounting.

PE Log viewer shows 11.04 for every “Value” in this edit list, yet when I post this, the TranGLC table shows zeroes for this transaction.

This seems totally wrong. Why don’t I get a move to sales revenue?

Well, I did a better BAQ on this invoice and it does seem to hit the right accounts after all.

So that edit list is pointless?

Alright, I am lost now. One of three show in the edit list today in the recap section.

I guess that is true. Here is the GL report.

But like I said yesterday, it looks right in TranGLC…

The only difference between these that I see being relevant is that the one that actually hit the GL, it did NOT reference a sales order in the service contract.

No one is familiar with this? I guess I’ll try support. :grimacing:

I haven’t looked through all the info in your posts… so with that said, my first guess would be that the GL transaction is using the same account for both the credit and the debit. And the Posting engine won’t create a transaction with a zero debit and credit. so those transactions wouldn’t show up on edit lists or the Invetory WIP Recon report.

1 Like

Well, as usual, you are right.

Now I have to figure out why the last iteration is different. Same customer and company for every test.

Yeah, the tech ref is not as, ahem, technical as I would like. (It’s a whopping 7 pages front to back; 4 of those are TOC and legal.)

Yeah, I can’t decipher this.

I mean, it looks like maybe if I had a GL control on this customer, I could avoid all this. Maybe. But I shouldn’t need to.

It’s supposed to go up a level to company, but that’s a lie: it goes to the invoice line next. (Why on earth is it not the other way around?)

But then it looks for a context called “Recognized Revenue” in the GL Control Code of the line (say what?) which is some 9-digit number.

This is awful. I feel like my users do. It’s a black box with magic inside. I’ll put in that ticket now.

I may be wrong, but I thought the TranGL entries are created at the time of the record that will use them in the future is created. For example, the GL account specified by a Part Class GLC, used on PO, will create the TranGL entry is created at the time the PO Release is created. Not when it is actually received.

So maybe the original Invoice was not setup properly, or the GLC changed since it the invoice was created.

1 Like

OK, I think I get it.

By the way, I’m testing Service Contracts at the same time. Not sure if that matters.

I changed the GL account on the control code for the contracts. Apparently the invoice remembers the SALES account that the GLC WOULD HAVE USED if it wasn’t deferred revenue.

So even now, every time I do a revenue recognition, it’s pinging off of the GLC snapshot in time - even though it didn’t use the sales account in the invoice.

I even tried invoicing with one sales account (that’s not used since it’s DR) and then changing the account on the GLC and then doing rev. rec. and it still goes back to the snapshot in time. Oh this is so bizarre.

And I can’t even trace it! I don’t have any record of the sales account that was never used on an invoice. But it’s got to live somewhere.

That 9 digit “GL Control code” looks like some sort integter used as an ID (like an auto-numbered field). Like whatever is sued to fetch the real GLC Control ID Like how 154590002 fetches acct 2090-RID-00.
edit: (see post #10 below, for info on this “code”)

And are you looking at the AR Hierarchy Tech Ref? I see more than 7 pages. The relevant info being:

There is a field in TranGLC called SysGLControlCode, which appears to be an integer identifier of the record.

Do a quick quuery on your TranGLC table to see if any records exist for 159540004

No, DR has its own tech ref. And “Revenue Recognition” is a screen you can’t see if you don’t have the DR module. (NOT Capture Project Revenue Recognition)

This is all of the info:


But there is WAY more to the hierarchy than that, when I look at the posting engine. (PE Log viewer)

Lol it’s 154590004, so that threw me for a minute. But, still, no, nothing comes up. Not in that column. Not in Key1.

I even dug into EntityGLC (which is where InvcHead GLCs are, for example) and nothing.

I do appreciate all the help. I got farther than I could have without you.

I have to leave in 30 minutes, so this is good for today. Thanks again.

First … sorry about the typo.

The lack of a TranGLC record with that filed value is what is creating the error in the posting engine.

It seems like maybe that TranGLC record was created, and its Code# strored in some other table for later use. Then the TranGLC record was deleted (not sure why, maybe the source record was deleted). Then when the posting engine goes to figure out which accts to use for which transactions, its fetching that missing Code# from the refernecing table, but can’t find it in TranCGL.

@JasonMcD We just discovered the reusable piece in the posting engine. As of 1/1 we restructured our GL since we were acquired last year. Even with every GL control in the hierarchy pointing to new accounts it will find the previous entries account and use it. I had to customize several posting rules to get around this behavior.

1 Like

@gpayne Thank you for the validation. Yes, this is bizarre behavior.

Wow, and you can’t leave the Sales context blank in the Field Service GLC when you post the invoice (not the recognition; just the original invoice).


So weird - the two accounts you see in the tree are the DR and AR accounts and they are valid. The “invalid” one is neither of those; it’s the fact that I left the Sales context empty (though it is not “required”).

So, wrapping this up, looks like we will just skip the Service Contract piece of this entirely.

  • The restrictions it imposes are insane if you are trying to make it part of the same sales order as the thing it is servicing. (Imagine that.)
  • You can’t invoice (or ship) the contract and its shipment at the same time.
  • And in our case, it’s a third party that is tracking the service anyway, so we don’t really NEED the contract to be an Epicor contract.

Instead we will add lines to the sales order with a special part number rather than a contract, and then manually defer the revenue each time. It’s still much less work than the contract.

They REALLY need a better tech ref for this thing. Yeesh.

1 Like

I used this to set up and test and all worked as expected


What is Deferred Revenue Accounting and how to recognize the revenue.




*Deferred Revenue Accounting

Deferred revenue stems from the accounting concept of revenue recognition, under which revenues are recognized only when the earnings process is complete.

If funds are received and no goods or services have been provided, the process is not complete, and revenue cannot be recognized. In this case, a deferred revenue liability is recorded. Specifically, the deferred revenue account is credited and cash, or other assets, are debited.

*Revenue Recognition Process.

Run this process when you would like to recognize the revenue.


Path: System Management > Company Maintenance > Company

Navigate to the Modules > All Modules > GL Control > List sheet.

Highlight the AR Account GL Control Type.

In the GL Control Code field for AR Account, right-click Default and select Open With > GL Control Code Entry.

GL Control Maintenance displays.

In the tree view, navigate to Company ID - Company Defaults > Account Context > Main Book > Deferred Revenue.

From the Account > Detail sheet, in the Account field, you can see the Deferred Revenue account.


Path: Financial Management >Deferred Revenue Accounting >Setup>Revenue Amortization Code.

  • Click File

  • New.

  • Enter any code and description. (in this case I put TEST as a RA Code)

  • Scope = (AR)

  • Select fiscal calendar = (your fiscal calendar)

  • Duration = (enter 3)

  • Calculation method = (Equal Amounts)

  • Save


Path: Financial Management + Accounts Receivable + Set Up + Customer (Customer Maintenance)

  • Search and Select the desired Customer (it should be created first)

  • Select the Billing and Details tab

  • Click Deferred Revenue check box

  • Set the RA Schedule as the code that you set up on step 2

  • Click on Save


Path: Financial Management >Accounts Receivable>General Operations> Invoice Entry

  • Click File

  • New> New Group

  • Enter any Group ID

  • In the Invoice Date and Apply Date fields, select the first day of last month.

  • Save

  • File> New > New Miscellaneous invoice.

After you select “New Miscellaneous Invoice” option, you will be referred to Header and Detail tabs.

  • Select the customer that you’ve selected before. To locate this field, look for the “Sold To Customer” option.

  • File> New > New line

Once you select the “New Line” option, you’ll be redirected to Line and Detail tabs

  • Enter any part and description in Part/Rev option

  • Enter quantity = 1 unit and price = 1000

  • If the checkbox is unchecked, select it, and select RA Code. If there is no End Date, you can add it, but even if it is not added will not affect the process so far.

  • Press Save

  • Then a window will appear, answer YES to “Do you want to generate the amortization schedules?"

  • Actions Post. The Credit account will go to deferred revenue. Revenue has not recognize yet.

Step 5: Recognize Revenue.

Path: Financial management>Deferred Revenue> General Operations> Revenue Recognition

  • On the As of Date enter the last day of the current month

  • Go to Filter tab > AR Invoice in order to Filter by invoice>select Invoice option and enter the invoice number that you created above. (You can also filter by Customer.)

  • Navigate to the Detail sheet.

  • Actions>Get Amortizations.

  • Actions > Print Edit list. The revenue will be recognized in the current month. (1000 / 3 = 333.33)

  • In the Amortizations grid, highlight the invoice amortization sequences that you want to post.

  • Click Submit.

Sales/Revenue account for current month will be 333.33 posted to GL.

Verified product versions: 10.1.400.x, 10.1.500.x, 10.2.100.x

1 Like

@aclements - I have not looked at deferred revenue since this post in February, but I tried to follow why your scenario worked… I think it may be because of this step, that you put a GL on the customer?

That seems to have been my prediction here after I had dissected the PE Log viewer.

If that is the only way for Deferred Revenue to work properly (assign GL to every customer), then

  1. It’s not documented well at all
  2. That’s silly - it is supposed to trip up to company if no GL is assigned to a customer.


I didn’t set it at customer level, I set it at company level


In addition to Amortized Invoices, the Project Module also does deferred revenue if your revenue depends on activities instead of a schedule.