Guides: 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.
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.
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.
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 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 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.
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.
For each payout item that has a
taxesarray, iterate through each item and apply the corresponding tax in your system using thetax_rate_idandexchange_rateprovided
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).
Group the fees by
taxes[tax_rate_id]If the taxes have to be converted (e.g. Category C & Category D
), then also grouped by the exchange rate
taxes[exchange_rate].Create one transaction for each of these ‘groups’, summing the fees, and using the
tax_rate_idandexchange_rateprovided
Tax Applied? | Tax Exchange Rate required? | Payout Webhook(s) required to process | |
|---|---|---|---|
Category A | Yes | No |
|
Category B | No | No |
|
Category C | Yes | Yes |
|
Category D | Yes | Yes |
|
Category E | No | No |
|
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
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 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
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.