As GL is used as the primary and source of truth for Cost Allocation in CT, in specific situations we have transactions in GL's that are accrual entries for multiple months where we have not received vendor invoices and then we get an invoice after 3 months of accrual and then you start seeing reversal of accruals and the invoice paid for the previous 3 months. Looks like this type of accruals and reversals and then actual invoice paid for multiple previous months in the correct month could result in a skewed App TCO when we look at it on a monthly basis? Specifically we are seeing this in Cloud billing that is based on consumption rather than a fixed fee. 

Has anyone faced similar situations and if yes how was it solved? This also happens in our Managed Service billings where financial GL transactions that hit monthly could be significantly varying due to accruals, reversals, credits, disputes etc.?

Any insight would be much appreciated!

@Debbie Hagen @Taryn Kane @Melanie Ercoli @Ericka Norman @Raquel Garcia @Babu Hussainsab Mehrunnesa @Pablo Santana

Yes, we see that as well.  I look forward to others jumping on and chiming in.  We've just been explaining the accrual process whenever the question arises about the negative values in our reporting. Definitely open to suggestions!

@Chris Armour @Chris Davidson

We're having the same issues plus additional ones with prepayments (we're now using an order tracker to map the GL transactions directly to towers for these) - I will be following this post with the hope of some final answers to this query!!

Hi Srikanth Satakopan, at one of our clients we faced the same issue. We decided at the very beginning that we will not include accruals into the allocation out of cost source. In fact, the accruals are allocated to the Cost Source Object and thus we have them in all the financial reports. From cost source object to vendor, labor, fixed assets etc. objects they are falling out on purpose.

Why did we do this?

Two simple reasons:

1. It simplified the model dramatically.

2. The client wanted to see the real cost and when they really hit the cost base. They did not want to see the nice flattened out cost.

We added some reports and some slicers to show the difference of cost base with and without accruals.

Hi Srikanth Satakopan,

I think that you always choose between two approaches - balancing the allocations 100% against the GL, and balancing against the consumption of IT services.

The latter approach requires setting fixed unit rates to be able to translate consumption to cost.

This approach is useful if you're trying to get to an App TCO that reflects reality more closely and consistently.

The trade-off is that you'll always be under or over-allocating compared to the GL, but hopefully on a FY or YTD view, the differences shoukd not be huge. You would of course need to have a set of reports to be able to explain the differences and in order to help you set more accurate unit rates over time.

Another approach you could consider is "restating history", by showing the cost of the accruals and reversals in the month that the services were recieved. However, this makes all reports "tentative" because they can always change next month, making them not very effective for decision making.

So, I think it's a question of who your audience is. LOBs and service owners will typically not care too much about the GL; they want to make decisions based on consumption and "real time" cost.

On the other hand, any report shown to finance must eventually tie to the GL in order to make sense.

Thanks,

Guy

Hi Srikanth Satakopan 

Another approach is to look at the way the accruals are processed in the general ledger. At one of my clients they allocate all of their accruals to the vendor codes and made it a mandatory field in the general ledger system for all non-payroll accruals. Another example was utilising the project codes in the general ledger to create an Opex project which then utilises the WBSE structure from the projects module as the mandatory field.

Good luck, Paul