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.

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 merchants 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 that 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.

Payment detail view

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.

Payout detail view

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)

  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.

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.

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.

There are two possible approaches:

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
  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
  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 Y N paid
Category B Y N fx_rate_confirmed
Category C Y Y tax_exchange_rates_confirmed
Category D Y Y fx_rate_confirmed and tax_exchange_rates_confirmed
Category E N N 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

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 which 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.