Blog

Release 11, Release 12 and Project Accruals

Introduction

In most modern companies “accruals” are a routine fact of life and reflect one of the key principles of accountancy, which is the “accruals basis” or “cost and income matching” principle.  Put simply this core principle requires financial statements covering a period of time to reflect the costs incurred and income earned in that period, matched to each other and to the period in question.

For many years Oracle Projects did not adhere directly to this principle, at least for costs, as it only dealt in invoiced costs.  This had all sorts of consequences:  home built accrual routines, work in progress audit adjustments for capital projects and a rather eccentric concept of commitment to include goods received not invoiced (GRNI) that would be regarded as incurred costs everywhere else.

Developments in Oracle Projects

This rather unsatisfactory situation lasted until well into Release 11 but then it became possible to “accrue at receipt” in Purchasing and interface supplier costs into Projects based on goods received  (the interface supplier costs process allowed receipt based costs to be interfaced to Projects.)  This was sometimes known as “perpetual accruals” as the process was continuous and the coming and going of period ends largely irrelevant.

While some of us still yearned for old-fashioned month end accruals this was a big step forward and we duly implemented accruing at receipt and stood back to admire our handiwork.  It was at this point that we noticed a few odd things.  In particular the new accrue at receipt functionality worked well if the purchasing cycle followed the “normal” or “classical” flow.

1. Raise an order, possibly from a requisition.
2. Receive some goods against the order.
3. Get an invoice.

In the step 1 we took up a commitment, at 2 we took up a real accrued cost and reduced the commitment and at 3 we would sweep up any price variances and initiate the payment cycle for the invoice.  Unfortunately if steps 2 and 3 were reversed, a very common real world occurrence, then costs would be brought into the project by the invoice, whether there had been a receipt or not (assuming any holds on the invoice are released).  Trying to reconcile GL to Projects became even more of an issue and all manner of rather artificial disciplines had to be applied to enforce the classical cycle and so avoid trouble and irate accountants.

The accruals “issue” duly arrived in Metalink and you can see it described in Bug 6476580 and Note 462197.1, of which more later. The bug had the dreaded “intended functionality” statement against it, which I suspect left many affected company accountants foaming at the mouth.  As to what functionality had been in the designer’s mind I cannot say, but what we got contravened one of the cardinal principles of accountancy, the accruals principle, and was therefore unacceptable.

So far so not very good, but Release 12 promised to remove the problem.  Note 462197.1 (again) compares Release 11 and 12 and states:

In R11i with accrue_on_receipt_flag as ‘Y’, a PO can have multiple distributions. If for one of the distributions, invoicing is completed and is interfaced to Projects, then receipt for that distribution will not be interfaced into Projects.

If Invoicing has been completed on a receipt, but it is not interfaced to Projects, then receipts are still eligible for interface to Projects.

For the remaining distributions not associated to an invoice, receipts would come into Projects if interface process is run for ‘Receipts’ and no invoicing is done for those distributions.
In R12, if accrue_on_receipt_flag is ‘Y’ on po_distributions we always interface from PO to Projects the cost from receipts directly.

And any variance while creating the matching invoice will be interfaced from Payables to Projects.

So, there is no question of the invoice getting interfaced (unless it has some variance) when the invoice is matched to po distributions with accrue_on_receipt_flag as ‘Y’ as receipts will not interface to Projects via Payables matched invoice.

So the question is does it fix the problem?  The short answer is “yes, more or less” and the rest of this blog shows you how I got to that conclusion.

Release 11 and 12 accruals compared

First let us reproduce the R11 issue. So here in a Release 11 Vision are my purchasing options, which you will notice include “accrue at receipt”:

I raise my order:

Then process an invoice and match to this order.  I have 3-way matching set for this supplier.  My order quantity was 1,000 at $60 and my invoice quantity was 800 but no receipts yet.  I get an invoice hold of  Invoice against a Billing Qty exceeds Receiving which is a bit of a warning but I can release and carry on.

My invoice distributions look like below.  Now really this $48,000 should stay in commitments as nothing is yet received.

I interface across to Projects, using the PRC: Interface Supplier Costs process with the parameter set to collect receipt accruals, update my summary values with PRC: Update Project Summary Amounts for a Single Project and I get this:

So as you can see the invoiced costs without receipts, the last two at $24,000 each, have come across into my project.

Commitments, using PSI, look like this:

And there you have the issue as clear as day.  No costs should have hit the Project, all should still be commitments but as you can see the commitment has “ripened” into a cost through the receipt and matching of the invoice.  The only commitment I have left is for the un-invoiced 200 items.  The implicit assumption in the design appears to be that by the time an invoice arrives receiving should have happened.

Well, using Release 12, I will follow the same sequence with an order of 1,000 @ $70, an invoice of 400 @ $75 and a receipt after the invoice of 300.

After raising the Order #6029 (and allowing for US sales tax of $4,380) my commitment is $74,380.  I match the invoice to the order.  Again I will have an Invoice against a Billing Qty exceeds Receiving hold that I can release.  I still have no receipt  at this stage.  Now I run the interface process again.  This is the PRC: Interface Supplier Costs process and has these parameters:

So now I run this with the parameter set as you can see to collect receipt accruals.  Then I need to update PSI by running PRC: Update Project Summary Amounts for a Single Project so that my view of commitments is up to date and I get this:

My commitment, the last of these three, is still $74,830 and has not moved, so that is right.

Some US sales tax things have happened here but the only cost to come over from the invoice is the price variance, $2,000 that is 400 items @ ($75 – $70).  Now you could question whether the whole variance should arrive against the project now and I should really like to hear your views but the major talking point is that no cost has come over for the 400 invoiced.

If it had we would see 400 @ 70 = $28,000 of cost plus the sales tax, so we can safely say there is no “assumed” receipt, even though getting the invoice and matching it to the order preceded the receiving step. So now I can receive my 300 items, re-run my processes and Commitments in PSI show as $74,830 * 700 / 1,000 = $52,381.

Costs show as $74,830 * 300 / 1000 = $22,449.  This is in two parts: $21,000 of pipe received and $1,449 of sales tax.

And status of the order itself also looks right:

Conclusion

Oracle Projects in Release 12 is much more observant of the accruals principle than was Release 11. I would still like to hear from you about taking up the whole invoice price variance into project cost, as I think one could argue that it should only happen when goods are received, the balance going to commitment and staying there until items are received.

So in this case the $2,000 first goes to commitment when the invoice is received and matched, and then $1,500 moves with the matched receipt of $21,000 into actual costs.  All the same it really looks as though Release 12 has largely resolved the issue and given us a system much more able to cope with the reality of receiving processes, rather than working only within an ideal but rare flow.

28 Oct, 2009 by Barry Goodsell

E-Business Suite