Memberships and VAT (UK Specific)

Hello,

 

I'm trying to figure out how to make Tessitura do VAT on memberships (its relatively simple on tickets!).  I'm given to understand that if your membership offers any kind of benefit, such as priority booking, then it falls into scope for VAT.  Unfortunately I can't see any way of doing this automatically for contributions as you can for ticketing, and it would be up to the agent to calculate the VAT element and assign it to a different fund.  I believe this is an unfair expectation to put on the agent, and surely there must be some way of automatically splitting a payment over multiple funds?  Has anyone come across this before, and have a solution?

Parents
  • Former Member
    Former Member $organization

    Hi Simon

    At Sydney Opera House, as part of dealing with GST and some other gnarly bits of accounting trickery, we decided to implement a secondary posting process.

    After a batch or batches is posted, the $$ people run a report (for the posting number) which splits certain transactions (which are tagged by GL code in a local table), into multiple amounts. The report proc populates a secondary posting table, which is then returned as the result set, and exported instead of the original, for journaling into the finance system.

    That's a bit messy, and you need to constantly be checking that the local table is kept up to date as new GL's are invented and when people get Creative in other ways, but it does achieve the result of splitting off the tax share (or whatever)  without needing the agents to do it. And of course you need to have access to the SQL skills to do a bit of custom work.

    That kind of process has the other advantage, of course, of not being irrevocable once the sale/contribution is processed. The posting process can be adjusted or reversed and repeated fairly easily when errors are found.

    Ken

Reply
  • Former Member
    Former Member $organization

    Hi Simon

    At Sydney Opera House, as part of dealing with GST and some other gnarly bits of accounting trickery, we decided to implement a secondary posting process.

    After a batch or batches is posted, the $$ people run a report (for the posting number) which splits certain transactions (which are tagged by GL code in a local table), into multiple amounts. The report proc populates a secondary posting table, which is then returned as the result set, and exported instead of the original, for journaling into the finance system.

    That's a bit messy, and you need to constantly be checking that the local table is kept up to date as new GL's are invented and when people get Creative in other ways, but it does achieve the result of splitting off the tax share (or whatever)  without needing the agents to do it. And of course you need to have access to the SQL skills to do a bit of custom work.

    That kind of process has the other advantage, of course, of not being irrevocable once the sale/contribution is processed. The posting process can be adjusted or reversed and repeated fairly easily when errors are found.

    Ken

Children