Use Actuals Through Date, System Revenue, and Reports

Revenue Allocation

When Projector allocates system revenue across a fixed price engagement report, it looks at what revenue you have already recognized, how much work you have done, how much work you have left, and finally how much revenue still needs to be recognized. Projector then intelligently splits the revenue up amongst your timecards. I'll be using the following acronyms in this article.

• UATD - Use Actuals Through Date
• RRD - Revenue Recognition Date, which represents the last date through which revenue has been recognized

If you are unfamiliar with how Projector calculates percent complete, please see the Engagement Contract Tab and read up on it.

RRD Before UATD

This is the most likely case you'll run into. If you can understand this case, then you'll be able to understand all cases. Imagine a case where you ran revenue recognition through end of last month and have a UATD date of today. This creates three time period buckets in which Projector can place revenue.

• Revenue before the RR date
• Revenue between the RR date and the UATD date
• Revenue after the UATD date

In the example picture below you have already recognized 10% of this engagements revenue. This is your first bucket. Projector then looks at all the time you have entered between the start of the engagement and the UATD date. It then calculates how "done" you are as of the UATD date. In this example Projector thinks you are 40% done. The difference between the RRD and UATD is then placed in the second bucket, or 30%. The remaining 60% of the revenue is allocated to our third bucket, all time after the UATD date.

RRD on UATD

If the RR date and UATD date happen to be the same, then not much changes. The only difference to the previous example is that the second bucket is gone. Now all the revenue that Projector allocates lands after the date.

RRD after UATD

This case is a little more interesting. What happens in this case is that Projector ignores all recognized revenue after the UATD date. This is similar to rolling the RRD backwards to match the UATD. You can see in the screenshot below that the 30% of revenue that sits between the UATD and RRD is being ignored. Rather, we just look at everything up to the UATD as one bucket, and everything after the UATD as the second bucket.

Special Cases

These are some special cases that might arise in your reports. They are a little unusual, but not impossible.

No Hours after RR

When there are no hours in our second bucket, between the RRD and UATD, then you can end up in a situation where Projector has revenue, but no timecards to place it on. When Projector can't find a timecard, it instead places it on the UATD date. You may be asking yourself how the percent complete could change between the RRD and UATD if no work was performed. Well, if you are manually overriding the percent complete, then you have created a disparity between Projector internal tracking and your own tracking. This disparity will land on the UATD.

No Hours after UATD

In this case we have hours in bucket two, but none in bucket three. Here we introduce another date, the Revenue Earned By Date which is specified on your engagement contract tab. This is a date by which you expect this engagement to be finished. Any revenue that can't land on time cards, ends up on this date.

Negative System Revenue

You might end up in a situation where your reports are showing negative system revenue. How is this possible? Shouldn't a project always be more complete, not less complete as time goes on? This occurs when you have overridden Projector's built-in revenue recognition calculations and specified your own. If you overstate your earned revenue, Projector will try and compensate in later periods by reducing revenue. That reduction may be so severe that it actually goes negative as a correction. For example, let's say you worked 1 hour on a million dollar engagement and said you were half done. Great, you've earned 500k of revenue! But then next month you realize it will take 10 total hours to complete. You weren't 50% done, you were 10% done. The next revenue recognition period would likely contain a -400k revenue correction to get things back in line.

Large Amount of Revenue Lands in One Time Period

When you run a report, you may see a large amount of revenue land in a single time period. This is similar to the negative system revenue case we just discussed, but in the opposite direction. You have run revenue recognition, but have under recognized revenue in preceding months. When Projector creates the three buckets for allocating system revenue, a large adjustment chunk lands in the middle bucket, greatly affecting a single time period. To resolve this you have a few options. One option is to set your Use Actuals Through Date equal to your last revenue recognition date. This eliminates the middle bucket and remaining revenue is spread across the rest of the project. The other option is to add more booked hours. It is likely you haven't finished planning this project out. By adding hours, you make the project "less done" and you'll see the middle bucket receive a smaller adjustment. 

Reports Contain <blank>

When Projector allocates revenue to a time bucket, it tries to assign it to a time card. If there are no actuals, no hours in the middle bucket, or no projections, Projector has no way of knowing which project is supposed to receive the revenue. Therefore we assign it to <blank>. If you need to get project information in, you'll need to add hours into the appropriate time bucket.