Supporting tax rules worldwide

Published
2012-05-12 07:26
Written by

I am starting a project that will allow CiviCRM to support the needs of an Australian non-profit. This non-profit is subject to the Australian Goods & Services Tax rules (GST) for some but not all transactions.

The GST requirements apply whenever the non-profit provides a tangible good or service in exchange for a payment. This is most common with their dinners, selling DVDs, and items from their gift shop. 

 I have written up the requirements and possible approaches on the CiviCRM wiki at:

http://wiki.civicrm.org/confluence/display/CRMDOC41/Taxes+and+Fees+for+CiviCRM

 

I would love to get feedback from anyone who would like to participate or later use the new module. 

 

- Sarah

Comments

I have a similar use case with a non-profit that runs training workshops in Canada.  They are using CiviEvent to manage the registration process.  Each workshop is subject to a "tuition" fee, and HST needs to be calculated.

The simple approach you outlined in the Wiki page would easily cover our requirements as well.

Note that in some Canadian provinces, more than one sales tax might apply to the workshop scenario I described above.  There might be one provincial rate and one federal rate.  Both rates need to be calculated and applied separately to the amount; and they would have different GL codes on the accounting side.  It might be nice to work out a way to apply more than one sales tax to an online payment, but it is not a requirement in our case.

It would also be great if the sales tax was reported as a separate line item on any receipts and confirmation screens.  Under Canadian tax law, many organizations keep track of the HST they pay out for various reasons.  Charities registering for a workshop, for example, might be HST-exempt and would report any HST they paid in order to receive a refund.

Hi Sarah,

I'm in!

 

As Lobo mentioned we have added a British Columbia HST tax field in an installation of civiCRM. It works well enough but it is limited in flexibility and is painfull to deal with when we preform minor civiCRM core updates. My goal now is to take the work and experience we gained and put it into a module that we can give back to the community so that anyone can just plug it in and run with it.

 

The timing of your post is impecible as I was just creating a thread in the civiCRM forums to try and spur some support in moving forward with a group to take our existing work and create a civiCRM plugin when I received an email from Lobo mentioning this posting.

 

I'll scrap my posting and we can move forward on your WIKI or this discussion (whatever works). Let me know.

 

Cheers,
Andrew

For everyone who has expressed interest in this project, please update the wiki page I started with your requirements/ideas and other details.

 Instead of calling the wiki page "Australian+GST+for+CiviCRM"

It could be called "Taxes and Fees for CiviCRM" as it seems like the module could be used in any country/area that requires some kind of tax/fees to be collected. 

Seems likethis could also be used to impose a "sucharge/convenience fee"on a transaction for other purposes as well. For example, ask people to pay a 2% charge to cover the credit card processing charges.

 

I've updated my bookmarks with the new Wiki page and I'll start contributing shortly.

 

BTW: Does anyone know how to go about adjusting your civiCRM account so that you receive email notifications for Blogs and topics you are part of?

 

Thanks,
Andrew

FYI:  I am not in Australia myself. I am in Chicago, US.    If I am ever in Melbourne, I will attend the CiviCRM meetup there.

Hi Sarah,

I noticed on the Wiki page that JoeMurray made a valid comment about the development of the proposed plugin and I wanted to add a follow up comment but I can't comment on the Wiki page for some reason... Do you know if that is to do with the page settings or do I need to talk to Lobo or Dave Greenberg or someone to have my Wiki settings adjusted?

Further on the subject of development, I wonder if we shouldn't have a meeting of the minds with anyone who is interested in moving forward with a prototype... I'm with JoeMurray about making this CMS-agnostic because in my development experience forcing civiCRM to manage/track tax, all of the custom code surrounded civiCRM and very little had to do wth the CMS (Drupal). With this in mind, it seems that we need to build a civiCRM plugin and perhaps almost ignore the CMS except for administration hooks.

I'm interested in porting our code into a prototype so we can move forward with testing and such in a non-production environment and would like to collaborate with other like minded folks.

Cheers,
Andrew Wasson