eBay/API in Context of Making Tax Digital

Good Morning,

I wonder if you can offer some guidance please. We are using QuickFile in conjunction with our bespoke website. We use the QF API to push invoices from our website into QF with great success (circa 4000 invoices p/a).

The invoice number is generated in our website and then pushed across to QF. Our Invoice numbers are in ascending numerical order.

With making tax digital in the back of my mind, I am looking to grow my business and develop an eBay model to complement our website sales.

Having talked to a couple of accountants about how we might go about this from an ‘digital paper trail’ perspective we have a few ideas, however I would like to enquire if you can suggest how I might pull my eBay sales into QF without interrupting my current processes/integration.

One suggestion/consensus we are playing with is importing the PayPal statement into QF and then marrying our eBay sales to a weekly or monthly sales invoice (which could be generated in our website and then pushed to QF), however this seems to be a grey area, but I think given the size of our business and the resources we have available, the digital PayPal statement could be argued as ample justification for a digital paper trail in the context of making tax digital.

One issue I have with this, is that currently, our website obtains the PayPal transaction ID automatically, which is the trigger to mark a website sales invoice as paid and thus when a sales invoices is pushed from our website to QF, it is automatically marked as paid in QF (this is also the case if customer pays by credit card, Cheque, BACS etc….) and thus we are not currently importing the PayPal statement as all Sales Invoices in QF are currently marked as paid.

I did wonder if there was a way of continuing to push our web sales invoices from our website to QF as we are doing, and then importing my eBay sales directly into QF, however my initial thought is that there would be a conflict with how the invoice numbers are generated between the 3 platforms (QF, Website & eBay).

In my mind it is advantageous to import each sale independently, especially when it comes to administering refunds/credits etc…… however I might be overcomplicating the problem.

I hope this makes sense, please feel free to ask any questions.

Many Thanks

Since it sounds like you’re happy with API programming, Ebay have a fulfillment API that you can poll to get details of orders that have been placed but not yet fulfilled, including whether and by what means they have been paid. That should give you enough information to create matching invoices and payments in QuickFile as you do now from your website orders. QuickFile invoice numbers can contain letters as well as digits so you could avoid clashes by numbering the ebay ones something like “EBAY0000001” etc. (not just “E000000” as that’s the format used by default for estimates in QuickFile).

Hi Ian,
Many thanks for the response, which is great. Can you suggest a way of integrating our eBay model without using the API for the time being, as we might move to a seller omnichannel seller hub model at a later date.

I was holding out for a simple manual process that satisfies ‘Making Digital’ & and at the same time is relatively easy to administer.

Many thanks in advance.

Not being an eBay seller myself I don’t know how much detail you can download from them in CSV format - if you can get something that gives you a line for each sale with the date, amount (gross at least, possibly VAT too) and payment type then you should be able to massage that in Excel or similar into a suitable form for the invoice import tool. This would let you create one invoice in QuickFile per sale on eBay, but it’s probably simplest to keep them all against one dummy client name like “eBay sales” - you can always switch a given invoice to a “real” client name if they (the buyer) were to ask you for proper VAT documentation.

I guess you’d just do this in bulk once a week or so.

1 Like