Hello,

You did not described how POC is calculated in your setup and what was the POC used for calculations and what was your actual (billed) revenue. POC factor plays crucial role in calculations.

In short, recognition formula for revenue (in case of project with positive margin, loss-making projects have additional considerations) is:

• for “POC income first” method: actual cost + (POC * estimated margin)
• for “POC revenue first” method: POC * estimated revenue 

and for costs:

• for “POC income first” method: actual cost 
• for “POC revenue first” method: POC * (estimated costs/estimated revenue)

I would suggest to use POC calculation as “cost completion” (actual cost/estimated costs) together with “POC income first” recognition method; it will give you expected results in (normal) underbudget case, and for overbudget scenario you should adjust budget of this project - making planned costs greater or equal actual costs - before recognition calculation (otherwise system will raise calculation error of POC > 100%).

Good Morning @Adam Bereda ,

Andrei and I worked on these scenarios just before he posted the question. Here are some more details for our use case. 

All billings are advanced bill and are not CD invoiced until final shipments which could span multiple periods. So during the revenue recognition process we will not have any posted or actual revenue on the activities. Final CD Billings generally occur just before project completion. 

So we are left with projects over multiple periods in over or under recognized scenarios. We are looking for the path of lest resistance we could have 200-400 active projects during any given revenue recognition process. Having to manually adjust these on the fly seems like a very onerous task for the finance department.   

We are looking for a configuration in rev rec to accommodate actual cost vs estimated cost to calculate percent complete while posting recognized portions to COGS / REV accounts. All of that with a little adjustment as possible, none would be ideal. 

From what I have gathered in your post that does not seem to be possible, and we will be required to do some manual manipulation to get where we need to be. 

Can you please confirm that I understand this correctly, or please provide an explanation of we might test next. 

These are the scenarios we have tested thus far. All tests are running Capitalization posting method of Transaction.

1. Capitalized Rev/Exp // POC Income First // Actual Cost // Catch Up --- Project Ran Over Budget
2. Capitalized Rev/Exp // POC Income First // Actual Cost // Catch Up --- Project Ran Under Budget
3. Capitalized Rev/Exp // POC Revenue First // Actual Cost // Catch Up --- Project Ran Over Budget
4. Capitalized Rev/Exp // POC Revenue First // Actual Cost // Catch Up --- Project Ran Under Budget

None of these quite fit the mold as we wanted. Is there any benefit in looking into Capitalized Exp or Revenue separately rather than the combined method? Will Revision accounting prospectively help us in any way?

Our end goal is to capture as following 

Project Over Budget
Estimated - Revenue 10,000 Costs 7,000 = 30% 
Actual - Revenue 10,000 Costs 8,000 = 20%

We are seeing 2 different outcomes in the above configurations 

1. Some number larger than 10,000 revenue with 8,000 costs - Wrong
2. 10,000 Revenue with 7,000 Cost. Missing 1,000 cost - Wrong 

In all scenarios where we were underbudget they worked OK… but other than manually editing we were unable to increase to 100% and collect 10,000 revenue with 5,000 cost at 50%

All of this manual work seems daunting. I hope this provides more insight into our issue, I look forward to your feedback. 

Hello, 

Revision accounting applies to loss-making project - “catch-up” recognizes entire loss in current period, while “prospectively” option is following project POC (recognizing part of the loss corresponding to the project progress). I doubt if it applies to your case. 

In my current organization, to handle IAS15 (previously IAS11/18) standard, we are using capitalization of revenues only (keeping actual cost intact) - with setup Capitalized Revenue // POC Income First // Actual Cost or Manual, depending on the case // Catch Up. 

But each quarter (as we are reporting quarterly) we are verifying estimated figures - as for revenue recognition estimated income is crucial. Revenue recognition tool is defined to calculate result rather than cost or revenue separately…

From this point of view, project may run over its initial budget, but estimations for RMR must be realistic and estimated costs cannot be less than actual costs. It is impossible physically (if we expect credit notes decreasing actual costs - we should book accruals...)

If your actual costs are going over budget:

Project Over Budget
Estimated - Revenue 10,000 Costs 7,000 = 30% 
Actual - Revenue 10,000 Costs 8,000 = 20%

you should update estimated costs to be equal to at least current actual or book manual accrual/provision decreasing actual costs…

In such a way you will land in 100% progress and your recognized figures will be equal to estimated.

Please note that estimated costs and estimated revenue for RMR purpose is not initial project budget - it is rather current forecast, verified each time…

I am afraid there is no option in the system to recognize 100% of estimated revenue for project running over estimated costs.

Adam, 

Firstly thank you for your prompt response. 

To elaborate on the quoted section above. You are suggesting that as a project runs over budget we should be adjusting the estimates to account for the over run. In your experience are you suggesting that we update the following with the over run prior to running rev rec.  
 

This would then update the Financial Project with the new numbers and have the project run “over” original plan. 
 

Can you elaborate on “RMR purpose is not initial project budget - it is rather current forecast” 

We have been attempting to use the projects built in forecasting tool / set as budget however it becomes quite difficult to adjust as the project progresses. Things become locked down and unable to adjust when things change in our projects like ECO/ECR. We were planning to use each activities estimate tab’s to maintain project “budget” while the Project Margin tab to capture project overall budget. However with the above statements it sounds like we can continue to maintain activity level budget, but manipulate the project margin tab to reflect over under scenarios. 

Hello, 

Yes, you have understood me correctly. I do not have access right now to IFS v10 to check exact screen, I am using older one, and in this version estimated figures are visible in General Ledger/ Project Accounting/ Accounting project Details window on Project Totals tab (together with actual, capitalized etc.) - I think same figures are visible in Project module.

Differentiating between budget and forecast, I am talking about functions: I consider “budget” as general project plan, set before project is started, and perhaps verified from time to time, while “forecast” is used at operational level - updated frequently and considering achieved project progress and actuals as well as what is needed to complete it. From this posit of view, project might run over its initial budget, but never over its current, updated forecast.