Disclaimer: I am not an accountant, so apologies for any gross misrepresentation of actual accounting practices below!
We launched on Tessitura in late 2018, and are gradually trying to sort through various reconciliation issues we're still seeing between Tessitura and our GL system. One of these seems to have to do with deferred program revenue.
For example, we run summer camps in the summer that go on sale in February. Many of these are purchased before our FY rolls over on April 1. Our accounting folks want to keep this revenue in a deferred revenue account until after the FY rollover and then recognize it in the year the program occurs.
Currently they have been doing this by manually altering the target accounts when they enter the revenue from the posting reports. But this means that we have major discrepancies between the amount of revenue Tessitura thinks we've posted for a particular business unit and the amount that the GL system thinks we've posted, and it requires a lot of manual work to figure out how much deferred revenue needs to move back into the individual business unit accounts after the FY rollover.
As we were looking at this, we realized that we think we could use a second set of time-triggered price types to indicate a different GL code for programs purchased before and after the FY cutover, at least making it easier to ensure that things are automatically credited to the right initial account. But this still doesn't truly solve the reconciliation problem since it someone refunds one of the purchases from the prior fiscal year it's still presumably going to post against the wrong account once accounting moves the money around on the GL side. And it's also a little messy since it doubles the number of price types we have to set up for each performance. The documentation appears to address this situation obliquely without really recommending a solution. The link below basically acknowledges that Tessitura doesn't support this type of accounting (which is unfortunate!), and further says you should not "change the GL account used for an event from a deferred account to a current account after the tickets have gone on sale" because this will cause problems for returns. But it's not clear what the problems are, nor whether the time-based solution discussed above will cause the same problems. And it's not clear how else you can do this in a way that isn't going to cause reconciliation issues.
www.tessituranetwork.com/.../Tessitura.htm
So we find ourselves a bit stumped by this. In my dream world, it would seem like adding a process to allow for tickets to be sold into a deferred account and then scheduled to move into the correct account once the fiscal year rolls over would be ideal. IE, a FY rollover utility that would look for all transactions for events in the upcoming fiscal year that were sent to deferred revenue and would create a posting that would move them into the current account. (Any developers out there want to comment - is this more complicated than it sounds?) Given the apparent lack of a real solution at present, can anyone shed light on how they are dealing with this?
Thanks,
David DwigginsIT Officer, Historic New England
I am interested to find out if you get an answer to this. We also handle our deferred revenue in a similar manner, except that ALL of our ticket revenue (subscription sales are often sold in the spring before our fall season, with FY end of June 30th) being posted to deferred revenue. Then when we recognize the revenue for accounting purposes based on actual shows performed, we will make manual journal entries to pull it out of the deferred revenue account based on our revenue recognition principles. This helps, some, when trying to reconcile Tessitura to G/L because all of the revenue is flowing to the same account. Because we can run reports by fiscal year, if we have to do that with a prior fiscal year, but current fiscal year transaction posting dates, we can isolate any "unusual" activity, like refunds posting to a different fiscal year by running reports on transactions posted to a specific G/L account.
Obviously, for accuracy purposes, and audit trails, it would be nice if Tessitura could handle this and we didn't have to go back and adjust for these things manually. We have to explain, regularly, to the auditors why we can just run a report in Tessitura and have it tie to our G/L.
I am interested this conversation as well. We spend far too much time on reconciling deferred revenue and recognized revenue and would welcome any input.
Our previous software actually handled deferred revenue quite well; so from the Finance standpoint, I'm would welcome more capacity in Tessitura in this area.
I agree. I'm sure there are a lot of people dealing with this manually. It would be fantastic if Tessitura had more functionality in this area based on performance dates.