# Handling Tax

Source: https://docs.gocardless.com/docs/tutorials/handling-tax

# Handling Tax

GoCardless has been instructed by the relevant authorities to start charging tax on its fees. These guidelines aim to help accounting partners implement the required changes to ensure their merchant's accounts can still reconcile, and accurately report tax.

> **Info:**
> This guide may be relevant to you if you are an accounting software partner or interfacing with an
>   accounting software and you need to account for VAT correctly.

## Which merchant does this impact?

At this time, this change will impact any merchants who have a `country_code` of "GB" or "FR". It is possible that we may have to start charging VAT (or equivalent) in other areas where we operate in the future.

## UX/UI best practice

Based on the rounds of user testing we conducted with participants, we recommend the following patterns for UX/UI best practice.

### Payment detail view

When showing tax in the payment in detail view, we recommend surfacing the total amount of tax from fees within the source currency at the time the payment was taken.

![01-payment-detail-view-example](https://images.ctfassets.net/b2dmfxhmyqno/5dTMBxMemLwc1hADH8wpJu/ceb80740efe27fbcbcecb310623525a4/01-payment-detail-view-example.png)

### Payout detail view

The same recommendation should be applied on the payout level. Show the total amount of tax on fees within the source currency.

![02-payout-detail-view-example](https://images.ctfassets.net/b2dmfxhmyqno/47vlh78SVuxBLeJumNXqnG/f5972b97cd37df50819161daa39d417d/02-payout-detail-view-example.png)

_We recommend following the same best practice when showing VATs within emails._

There are now three different properties of a payout that we need to think about:

**Payer Currency** - this is the currency the money was originally collected in

**FX Currency** - this is the currency that the money will be received in a merchant bank account in

**Tax Currency** - this is the currency in which the merchant pays tax

To help our discussion, we are going to imagine a set of different payouts. If your product does not support all of these, you may ignore the guidance related to those categories. We are using the tax_jurisdiction 'GB' for these examples. Any merchants with a tax jurisdiction 'FR' will apply the same logic (but with Euros)

| Category       | Payer Currency | FX Currency | Tax Currency |
| -------------- | -------------- | ----------- | ------------ |
| **Category A** | GBP            | -           | GBP          |
| **Category B** | USD            | GBP         | GBP          |
| **Category C** | USD            | -           | GBP          |
| **Category D** | NZD            | AUD         | GBP          |
| **Category E** | USD            | USD         | -            |

## A Note on Tax Exchange Rates

Tax is still due on money moved in currencies other than GBP. For example, our _Category C_ merchant is a GB merchant taking USD payments into a USD bank account. However, GoCardless still needs to pay tax to the UK government in GBP. To accomplish this, we have to apply an exchange rate to the tax, for reporting purposes. When the exchange rate has been finalised you will receive the `tax_exchange_rates_confirmed` webhook. This could be a long time (e.g. a few weeks) after the payout is created. At this point, you can pull [payout_items](/docs/api-reference/payout-item#get-all-payout-items-in-a-single-payout) and the `tax_exchange_rate` will be present on each `taxes` object. We recommend that you store this exchange rate in your own systems, as it will be required so that the merchant can correctly claim back tax from the relevant government.

## Handling tax before September 1st 2020?

From the 1st September, any [payout_items](/docs/api-reference/payout-item#get-all-payout-items-in-a-single-payout) will include tax information in the API. If you want to see tax information on payout items between April 2020 and September 2020, you must opt in by providing the `include_2020_tax_cutover` parameter when querying the `payout_items` API endpoint.

## How to process payout fees

When processing your payout, this change should only impact the way you process fees. Everything else (the net payout and any FX realised gains) should remain the same.

> **Info:**
> The total amount of fees deducted from a payout will still be in the payout object under
>   `deducted_fees`. However, previously it was possible to handle all the separate fee line items as
>   one entity, ignoring payout_items and just using the `deducted_fees` value. Unfortunately, it is
>   possible (although unlikely) that different fees within the same payout could have a different tax
>   rate - e.g. if the tax rate changes.

### Option 1: Create one transaction per fee line item

This may be what you are already doing, in which case it's the obvious choice. This is useful if you want to display fees connected to specific payments, and also future-proofs your integration against more complicated tax setups (e.g. with multiple taxes applied to one fee.

1. [`Get the payout_items`](/docs/api-reference/payout-item#get-all-payout-items-in-a-single-payout)
2. For each payout item that has a `taxes `array, iterate through each item and apply the corresponding tax in your system using the `tax_rate_id `and `exchange_rate `provided

### Option 2: Group wherever possible

If you currently only create one fee transaction per payout, this may be a useful approach to avoid confusing merchants. The vast majority of payouts will have a single tax type applied, and the same exchange rate across all items (or no exchange rate), so you can group them and (most of the time) you will end up with a single fee transaction per payout. However, it's more complicated to implement. It also relies on the current behaviour that there will only be one tax applied to each transaction (which is true in GB and FR, but might not be forever).

1. [`Get the payout_items`](/docs/api-reference/payout-item#get-all-payout-items-in-a-single-payout)
2. Group the fees by `taxes[tax_rate_id]`
3. If the taxes have to be converted (e.g. _Category C & Category D_ ), then also grouped by the exchange rate `taxes[exchange_rate]`.
4. Create one transaction for each of these 'groups', summing the fees, and using the `tax_rate_id `and `exchange_rate `provided

|                | **Tax Applied?** | **Tax Exchange Rate required?** | **Payout Webhook(s) required to process**              |
| -------------- | ---------------- | ------------------------------- | ------------------------------------------------------ |
| **Category A** | Yes              | No                              | `paid`                                                 |
| **Category B** | No               | No                              | `fx_rate_confirmed`                                    |
| **Category C** | Yes              | Yes                             | `tax_exchange_rates_confirmed`                         |
| **Category D** | Yes              | Yes                             | `fx_rate_confirmed `and `tax_exchange_rates_confirmed` |
| **Category E** | No               | No                              | `paid`                                                 |

You can tell if tax is applied by seeing whether the payout `tax_currency` is populated. You can tell if the tax exchange rate is required by seeing if `tax_currency` is the same as the payout `fx[currency]` or `currency` if not FX.

As shown in the above table, for any payouts with a tax exchange rate required (i.e. _Category C_ or _Category D_), you will need to wait for the new `tax_exchange_rates_confirmed` webhook.

### Using Tax Rates

Each tax rate has an ID (e.g. `FR_VAT_1`). The number at the end will be incremented if the tax rate changes, a full list of tax rates can be [found here](/docs/api-reference/tax-rates)

If you need more information about our tax rates programmatically (e.g. if you want to be able to auto-create tax rates in your own system) there is a new [Tax Rates API](/docs/api-reference/tax-rates) that will provide the percentage and jurisdiction.

### Special Cases

#### Committed Revenue Merchants

Merchants with committed revenue contracts do not have any fees deducted from their payouts and are instead invoiced at the end of the month. At this time, we expect these invoices (and therefore the tax implications) to be handled outside of a partner integration. Therefore we believe no change will be required. These merchants can be identified because the `deducted_fees` property on the `payout` will be 0.

#### Overseas Territories

Territories such as Guadeloupe have their own tax regimes, and as such can have different tax rates. They will have their own tax rates, with different IDs, and will need to be processed accordingly.

A full list of tax rates can be [found here](/docs/api-reference/tax-rates)

### Fee Reversals

If a payment undergoes a late failure, the GoCardless fee is also reversed. The `taxes` array will be the same as when it was originally charged. Depending on your setup, you may want to reverse the original transaction or create an inverse transaction to 'cancel' the previous one. Late failures can happen a long time after the original payment was taken, so it's worth considering that the accounts for the previous year may have already closed.

## What's next?