Aller directement à la fin des métadonnées
Aller au début des métadonnées

Documentation Search

CiviCRM 4.1 Documentation

Developer Resources

CiviCRM books!

Make sure to check out our Online User/Administrator and Developer Guides! You can also support this project by ordering a hard copy.

Or support us by buying an eBook or hard copy of Using CiviCRM from Packt Publishing.


Many organizations are required to collect additional taxes and fees on some, but not all financial transactions. Typically the country or political area that they are located in governs the exact rules, rates and details about which transactions require a tax/fee to be collected and also the percentage rate that should be used.  These details may likely change over time as local laws change. There should be an administrative area that allows for the administrator to set up and change the  percentage rate that is used and which transactions are covered.

The features described here could be used whenever the organization needs to collect an extra fee, even if it is not imposed by a government body.  For example: An organization could ask people to pay a "convenience fee" of 2% to help offset the costs of credit card processing. A school that is using CiviEvent for course registration may charge a registration fee.

The requirements described here are heavily impacted by the current project CiviAccounts, which is slated for the CiviCRM 4.2/4.3 release cycle.    There has already been discussion of possible approaches at:

This wiki page is meant to document requirements and specifications, and to define scope of work, and possibly split this into phases.

Possible Phases:

Phase 1:  Decide on data structure where tax/fee details should be be stored in the CiviCRM database tables for each transaction.  Based on what is happening with the financial data structure for CiviAccounts, it seems like most likely that tax/fee details be attached to priceset line items.

Phase 2: Update back-office data entry screens to allow manual entry of taxes/fees for a transaction.  Provide a simple admin area to store the tax rate for this one environment. Provide basic back-office reporting about taxes/fees collected.

Phase 3: Update self-service screens for payment towards membership/events/contributions/pledges to include taxes/fees.  Create more robust admin area that comes with default tax rules for various countries/areas, including layered taxes such as for province and federal taxes.


Country/Area Specific Details

This section is intended to cover requirements for specific countries or areas. If you do not see your country/area listed, please add it along with any details.


Australian organizations are subject to a set of Australian government regulations known as GST (Goods and Services Tax) which is documented at:

For non-profits, most income they receive is not subject to GST. However, if they provide a tangible benefit or product in exchange for a payment, then those transactions are subject to GST.   Common examples of transactions where GST applies is when they sell tickets for a dinner, or sell a DVD, or a decorative item from their gift shop. 

In the case of a payment for a $100. dinner, the non-profit would need to mark that $10. is the GST amount.  GST can be done either "inclusive" or "exclusive" meaning does the transaction amount ( $100.) already include the GST, or is GST being added on top of the $100.   

The non-profit also needs to produce periodic reports that show the aggregate of the GST-type transactions total amounts, as well as the total amount of GST collected. Typically these need to be produced on a quarterly basis.   This information also needs to be available to the General Ledger, as the GST amount goes to a different general ledger code than other money.  


An organization uses CiviEvent to run workshops. Each workshop is subject to a "tuition" fee, and HST needs to be calculated.

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.

British Columbia  has a HST tax field. Previous work done to handle the taxes in British Columbia is documented at:

European Union

The EU  has what is called a "Value Added Tax" (VAT) which is based around the concept of a "chargeable supply" of goods or services. In VAT a supply may be "exempt" or "zero rated" (the equivalent of NULL and zero) or taxed at specific rates (there are a few discounted rates for "worthy" things like fuel, essential food, books, children's clothes and a general rate for everything). In any sale of goods, services (or memberships) VAT may be chargeable to the buyer. VAT is an EU tax, so all 27 EU (and EEA as well?) countries have a version of it, but each sets their own rates.

Because of the way EU VAT rules are specified, any tax implementation would need the following possibilities:

  • allow to charge tax or exempt tax entirely based on if the user enters a VAT number (if you have a VAT number, and you are not from the country where the tax is being charged, tax is 0%, otherwise it is normal)
  • set the tax rate for each individual item
  • charge tax depending on where the user is based (VAT is applied within the EU, but not outside of it)

United States

Some transactions are subject to state, county, and city taxes.  Depending on the location of the organization, they may only need to collect just state tax, OR state and county tax, OR state, county and city tax.  There are a number of cities that fall into multiple counties.  So an organization in one part of the city would charge a different tax rate than a organization in a different part of the same city. In some cases, the tax depends only on the location of the organization. In other cases, the tax depends on both the location of the constituent AND the location of the organization.

Use cases Needed

Back-office recording of transactions with taxes/fees

When a back-office user is recording a contribution in CiviCRM, they must be able to record a) Is this Contribution subject to taxes/fees or not?   b) What amount of taxes/fees was collected?       Ideally there is an administrative setting that stores the correct tax rate so that the calculation can be done automatically for the user.    It would also be helpful if certain contribution types defaulted the user to "taxable" is yes, and filled in the correct tax/fee amount to reduce the amount of errors or mistakes. 

My simple idea for implementing this:

Create a new Custom Field set called "Tax Info" that is used for any contribution. It should have 2 fields:   a) yes/no field called "Is Taxable?"   b) a numeric field called "Taxable Amount".   Create some Javascript that looks at the contribution amount entered, and calculates and fills in the field "Taxable amount" based on the correct tax rate. 

Self-service set up and recording of transactions with taxes/fees

When a visitor is paying online for something (typically an event) that is subject to taxes/fees, the contribution record should get automatically filled in behind the scenes with the correct tax/fee details. The administrator who set up a paid CiviEvent page (or CiviContribute page) will need a way of controlling if that page should include taxes/fees or not.

Reporting requirements

The non-profit needs a report that summarizes contributions fer a selected date range (typically last quarter) total income for tax/fee-type contributions, and how much tax/fee income was collected? for example:  $10,000. total amount collected, taxes collected is $1,000. 

The export to their General Ledger needs to separate out how much was collected for each tax/fee as that is associated with a different General Ledger code than other income. 


  • Aucun
  1. Jun 01, 2012

    JoeMurray dit :

    I think that this might be a good area for a CMS-agnostic extension approach for implementation. The reason is that there are fairly diverse ways that taxes are determined and calculated on different kinds of things in different jurisdictions. Like payment processor plugins, there is lots of high-level overlap, but lots of low-level variations in the details. Perhaps as part of 4.3 we could aim to release a tax module for one or two jurisdictions to make sure that all of the hooks and basic reporting needs are covered between the CiviAccounts project and projects for the particular extensions, eg for Australia and Canada and maybe the EU, depending on funding.