Delayed timing, net of fees are all complicating factors with Stripe and other payment processors. Also, if you’re dealing with international receipts, some of your sales should have GST / VAT included. We've got this.
Many of our clients are receiving payments from their customers using one of the above payment methods. And some of the marketplaces are also using these same services to payout.
When you’re just starting out you may simply see the end result of any cash received land in your main bank account.
But, under the hood, there’s a bunch of things to be aware of like whether you’ve charged GST (in Australia) or VAT (in the UK), which currency it’s in, what cut the payment services take for processing etc.
We therefore always recommend setting up an extra bank feed in Xero for these payment services.
In the bank feed you’ll then see:
- the underlying, individual payment transactions;
- depending on the feed the transaction level information can include customer, invoice reference, product/service level data, country code etc - this will also depend on how you’ve integrated these payment processors into your own App/website
- the separate fee charged by the payment processor; and
- the (net) payout from the payment processor as it clears to your nominated bank account.
What this means is that:
- We can accurately record the top-line revenue (not netted off by the fee amount) so it’s a true-r reflection of the actual revenue you’re receiving (this looks good for investors); and
- We can record the payment processor fee separately (typically as a Cost of Sale)
Foreign Currency
Many clients are born global and selling direct into other countries.
Some clients use a single (typically USD) currency, globally.
Some, progressively, build into their App/website specific currencies as they roll out into those different jurisdictions - we often see AUD, CAD, EUR, GBP, HKD, NZD, SGD and USD as the top currencies.
While it’s somewhat clunky, the way this is usually handled is by setting up a different bank feed for payment processor so for example you may have separate “Airwallex - AUD” and “Airwallex - USD” feeds in your Xero dashboard. You’ll need the Xero multi-currency level subscription and each currency setup within Xero but once the currencies and feeds are setup, it’s pretty straightforward.
GST / VAT
If you’re making sales in you're typically charging GST (Australia) or VAT (UK) - see our How does GST and VAT work FAQ for more information.
Some clients use a a single top-line price, with a small note that, in Australia or UK, GST or VAT is either included, or will be added. This is typically something you will need to have figured out when building your App/website.
The challenge is when you’re receiving payment … through a payment processor … that you need to be able to identify what payments come from Australian customers. The Australian transactions need to be correctly recorded as including GST (and UK transactions including VAT) so that this can be included in your ATO / HMRC reporting.
Again, depending on the payment processor, the country-level information may come through into Xero and we then may be able to straightforwardly identify the GST/VAT-able transactions accordingly. If it’s not clear from the direct feed we may therefore need to do something different (see below).
Note also that GST/VAT matters, regardless of currency. You could be selling in USD to Australian/UK customers, and you would need to account for the GST/VAT … in USD initially, but ultimately calculated and paid to the ATO in AUD equivalent.
Invoices
Depending on your business you may be:
- either raising invoices to customers in Xero, which may be paid via Stripe etc;
- or through your App/website you may be processing payments and immediately (within your App/website) generating and sending an invoice to your customers;
- or both at the same time (eg a mix, say, of retail customers self-serving through your App/website; as well as corporate customers requiring an invoice).
With both direct payments and payments of Xero invoices being processed through your payment processor.
- Where the payment is in respect of a previous Xero invoice these are usually pretty easily identified in the feed with the Xero invoice reference so they can be matched as part of your bookkeeping.
- Where there are larger volumes of transactions directly handled through your App/website the (many) transactions come into Xero, typically with a payment / invoice reference generated by your App/website. These are usually directly allocated to a Sales account without, necessarily, a corresponding invoice within Xero. This invoice / payment reference is contained with your App/website as needed. You may want, but do not need to explicitly have an invoice within Xero and we recommend against this for larger volumes … unless you are automatically generating the corresponding invoices from your App/website and purchasing them into Xero via Xero’s API.
What else can you do?
We’ve had a *lot* of experience with different circumstances.
Ideally through a combination of the different feeds and rules within Xero this will meet your needs, neatly. However, there are times when what you’re trying to do needs something extra. Examples of this include:
- Where there is no direct feed currently available for your payment processor
- Where you are selling different products and services and you want these allocated to multiple Sales accounts so you can see your different revenue streams on your Profit & Loss; and
- Where the feed doesn’t provide enough information into Xero to see whether GST/VAT is applicable.
In these circumstances we need to “go back to source”. ie we typically need to go back and login to the underlying payment processor to help us identify the necessary information, for example:
- to see the product / service description that is on the payment transactions … so that we can allocate it to a Sales account; or
- to see what the originating country is for an end-users credit card payment [we cannot see other credit card details] to help us, then, identify the GST / VAT status
In a nutshell, as long as the information is available somewhere in the payment record we can get to it for recording purposes. In these circumstances to help both deal with the volume of transactions, as well as for integrity purposes we will typically build a spreadsheet based “pre-processor”, whereby we would:
- download the payment records into our spreadsheet
- “parse” the transaction record for the information we need
- code the transactions accordingly (eg different accounts based on product/service, or with GST/VAT for AU/UK transactions); and lastly
- manually import the completed, coded spreadsheet into Xero as a manual bank feed.
Note that the upfront development of any pre-processor and the actual regular weekly or monthly processing to import these transactions is additional work above and beyond our Standard bookkeeping service, and hence additional fees will apply
More information
For more information on the key different types of feeds available, check out these Xero articles:
- Airwallex
- eWay
- Paypal
- Pin Payments - requires manual importing
- Stripe
- (Transfer)Wise