Hello, I'd love to get some perspective on what I think is a fairly simple question. We are a professional services firm that has both a subscription business and and custom services. Our custom services are typically consulting and research projects that last 4-6 weeks in length. As a practice, given the short length, we have recognized revenue at completion. One of the things we are dealing with is defining completion for our project teams for the purposes of closing the books each month. The general gray area is whether the date we send the deliverable is the finish date or the date we present and/or receive acceptance from the client that there are no major updates. These are typically small, $5-$25k projects. This makes a difference as if we send a deliverable on 6/30, but present on 7/2, it affects monthly revenue. I know this is pretty straightforward, but would appreciate a few perspectives. Thanks
Basic Rev Rec Question
Answers
In the grander scheme of things, materiality and timing (month vs year end) matters. That being said, it depends on the wordings of your contracts and what you define as the time you can enforce payment (send the bill or final bill). Whether it be on the delivered date, presentation and/or accepted. No matter what you decide or define, consistency of treatment across all contracts should also be considered.
And this might be a "perspective" comment .....Do NOT base your decision on the Rev Rec guidelines but focus on the intent/agreement of the parties. In other words, the Rev Rec guidelines should NOT be the basis (use as a starting point) of your revenue model. Decide on the model and see if it is allowed by the guidelines or if there are necessary tweaks you can make to conform with the guidelines.
Remember, the (evolving) revenue models are DRIVING the evolution of the guidelines and not the other way around.
Thanks emerson. Really helpful to see your reference to the contract. The below is an example bullet from the payment section of the project proposals where we always reference the deliverable date of the project. Seems that is when we should recognize the revenue if that is when we bill.
All project costs will be invoiced on the deliverable date of the project – July 24, 2015.
I would ask first why you are tying revenue to invoice/cash? If you have a contract and the ability to collect is reasonably assured, record the revenue when the work is performed. Emerson's comment of when can you "enforce payment" is spot on. Consistency is also key, but I would recognize the revenue when you perform the work. I would assume that is when you are taking the expense as well. Good luck.
I would suggest looking at the guidance and examples in ASC 605-10-S99 A3b questions 1 & 2.
From my perspective, what you need to evaluate is your "customer acceptance provision". As you state, you deliver your product (a research report, your findings, recommendations, etc) but you need to present it to the customer and your customer may indicate that you still have more work to do. To me, even the fact that you haven't presented it means you aren't done with the earnings process.
Ultimately, the guidance looks at customer acceptance provisions a few ways and you can definitely get treatment that it is just accounted for like a warranty (if customer acceptance is to vendor specified performance specs and you have a strong history of making those specs), but it could also make you defer revenue (if the specs are customer unique and you can't demonstrate in advance that you will meet them). Sounds like your customer acceptance provisions is the latter and not the former.
All of this assumes that you are under a completed performance model (i.e., the customer doesn't get any value until you deliver the report and present your findings), but be aware that the new standard which goes into effect in 2018 for public entities might change how you would need to account for this (i.e., some companies might find that based on their fact-pattern that they should basically adopt a percentage complete model if certain criteria are met - i.e, the product is unique / customized and the vendor doesn't have any alternative use for it, etc, etc).
To me, it's not revenue under the current standard until you get customer acceptance because you haven't completed everything you need to do to be entitled to the revenue (it would be hard to support a position that presenting your findings is inconsequential and perfunctory, as I would imagine this has a lot of value in the customer's eyes - which is another way that perhaps revenue could be recorded earlier).