We're currently running an evaluation license of Folio. Things look pretty good in general, but a question cropped up from our accountant around the Revenue at Completion (RAC) field on the Overview tab of a Folio. From what we've been able to derive, the RAC is based on a formula that variable on the actual revenue and the amount of work completed to date. However, we're often working fixed bid projects where the actual revenue is not going to change. It doesn't make sense to us that the RAC would change as the project progresses. Is there a setting or configuration we're overlooking to make Folio behave more like what we're expecting?
On a related note, it appears the Revenue to Date simply uses the date of operating revenues and assumes that if the date has passed for the revenue, the money has been earned. Is there a setting or configuration that allows Revenue to Date to be driven off of Completion Ratio? This would be similar to EV, but instead of basing it on BAC (EV = BAC * %) it would be based on RAC (noting that it's fixed in the first part of my question).
As I understand your scenario, there is an option that you might want to try out. In the case you describe, the revenue at completion you refer to is in fact the planned revenue (the expected total revenue at the end of the project). You can achieve that in FOLIO by configuring a Folio to be based on Revenue, rather than Cost. To do that, open the configuration of a Folio, click the Accounting tab and then select Track Revenues option, and then the Use Revenue as Actual Value option. This indicates to FOLIO that the amounts entered in the Budget view are Planned Revenues, rather than Planned Costs. Then you can go to the Budget tab and create, for instance, a lump sum budget, specifying the total expected revenue at the end of the project. This would provide you the numbers you want:
1) The Budget Total (BAC) gives you the planned Revenue at Completion.
2) The Earned Value (EV) gives you the Revenue to Date (= BAC * % earned issues)
Another consequence is that performance metrics will be based on comparing Actual Revenues (stuff you enter in the Revenue tab) with the Budgeted Revenue. The Cost tab also lets you enter your Actual Expenses, that will be used to compute your Profitability (by comparing it to the Actual Revenues). Also worth noting that what's entered in the Revenue tab should reflect what is actually billed to the client. If all the revenue comes from a single payment at the end of the project, then you should consider entering a single entry in the Revenue tab with the total amount, and then specify it as Recurring Daily and select the Amortized option. This will have the effect of spreading the revenue evenly over time and provide you more meaningful performance metrics because in that case, the Earned Value being over Actual Revenue will indeed indicate a good performance, and vice-versa.
As a side note, the Revenue at Completion (RAC) as it is displayed in the Overview is really an Estimated RAC, which is, as you said, based on the actual progress to date. You are right that it can be confusing and we will consider renaming it to Estimated Revenue at Completion in an future release).
Does this help?
To add a little bit to the discussion above, you might also be interested to know that we decided to include new features in our next release (due in around a month from now) that will allow users to enter Planned values for both Costs AND Revenues in the same Folio. As of now, a Folio allows you to enter either Planned Revenues OR Planned Costs, not both. Though you can enter both Actual Revenues and Actual Costs. So depending on your situation, the solution I described might be enough to fulfill your needs but if not, you won't have too much time to wait for the more complete solution... :)
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs