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: http://groups.drupal.org/node/182444
This wiki page is meant to document requirements and specifications, and to define scope of work, and possibly split this into 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: http://www.ato.gov.au/nonprofit/pathway.aspx?sid=42&pc=001/003/103&mfp=001/004&mnu=44792#001_003_103
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: http://groups.drupal.org/node/182444
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:
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:
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.
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.