Where vat integration ecommerce work actually goes wrong

Most vat integration ecommerce projects are specified around the happy path: a domestic consumer order, standard rate, one delivery address, paid in sterling, shipped complete, never returned. That order posts cleanly into Xero or Sage 200 and reconciles against the payout without argument. It is also, in a multi-marketplace business, perhaps sixty to eighty per cent of volume. The remaining orders are where the finance team loses its evenings and where the VAT return quietly stops agreeing with the sales ledger.

The structural problem is that tax determination no longer happens in one place. When you sell through Amazon Seller, eBay and your own Shopify store, three separate engines are deciding whether VAT applies, at what rate, in which jurisdiction, and who is liable to account for it. Each of them reports its decision to you in a different shape, at a different level of granularity, and with a different definition of when the transaction occurred. Your ledger has to hold all three decisions in a form that survives an HMRC enquiry three years later.

A sound integration therefore does not calculate VAT. It records the treatment applied by the channel, maps it onto a tax code your accounting system understands, and refuses to post anything it cannot map. That last part matters more than the mapping itself. The failure mode we see most often is an integration that silently defaults an unrecognised combination to the standard rate, or worse to zero rate, and produces a nine-box return that looks plausible but is wrong.

Deemed supplier rules: when the marketplace, not you, owes the VAT

Since the UK rules changed, marketplaces are liable to account for VAT on certain sales rather than the underlying seller. The common cases are goods located outside the UK at the point of sale with a consignment value of £135 or less delivered to a UK consumer, and goods already in the UK sold by an overseas seller. The EU operates an equivalent set of rules, with import consignments handled through IOSS. In those cases Amazon Seller or eBay collects the VAT from the buyer and remits it, and the seller has made a separate supply to the marketplace that is typically zero-rated or outside the scope.

That single fact produces the most common reconciliation failure in a multi-marketplace ledger. The order confirmation shows a gross price of, say, £60 including £10 of VAT. The settlement shows £50 of seller proceeds before fees. If the integration posts a £60 sale with £10 output VAT, the ledger overstates both turnover and the VAT liability, and the payout will never reconcile. If it posts £50 at zero rate with no supporting evidence of why, the accountant has no defence at audit.

The correct treatment is to post two facts, not one. Record the seller's supply at the value and tax treatment that applies to the seller, and record the marketplace-collected VAT as a distinct, clearly labelled amount that does not enter the output VAT control account. Keep the buyer-facing gross figure as a non-posting reference field on the transaction so that a customer service query and a VAT query can both be answered from the same record. Where the marketplace exposes a flag for this — and both Amazon Seller and eBay do, under varying names in their reporting — store the raw value verbatim alongside your interpreted tax code.

The determination can change mid-life for the same SKU. Move stock from a Great Britain warehouse into an EU fulfilment centre and orders that were domestic supplies become something else. Any integration that hard-codes tax treatment against a product rather than deriving it per order line from ship-from and ship-to will produce a clean period and a broken one, with no obvious trigger for the change.

The edge cases that change the tax code on a single order line

Below the level of who is liable sits a second layer of complexity: what rate applies to what portion of the basket. These are the cases worth enumerating explicitly during discovery, because each one has a definite right answer and an integration that gets it wrong will be consistently wrong at scale.

Not every item on this list will apply to every seller. The point of listing them is to make a deliberate decision, in writing, for each one before the build starts, rather than discovering the gap when the first quarter closes.

  • Mixed-rate baskets and delivery apportionment — An order containing a standard-rated item and a zero-rated item — a book, children's clothing, most food — requires the delivery charge to be apportioned across the two. Shopify and the marketplaces present a single delivery line. Decide the apportionment basis (usually by net value, sometimes by weight) and apply it consistently, because switching basis between periods is visible and hard to explain.
  • Discount and promotion allocation — A basket-level discount must be allocated across lines before VAT is computed, or the VAT on a mixed-rate order is wrong. Marketplace-funded promotions are treated differently from seller-funded ones, and the settlement file is often the only place the distinction appears.
  • Gift cards and vouchers — The sale of a single-purpose voucher and a multi-purpose voucher have different points of taxation. Multi-purpose vouchers are not a taxable supply at issue, only at redemption. An integration that posts the voucher sale as revenue creates output VAT that should not exist and double-counts turnover at redemption.
  • B2B sales and reverse charge — A business buyer with a valid VAT registration number in another member state changes the treatment entirely. Capture the number, capture the validation result and its timestamp, and store both. A VAT number that was valid on the order date and invalid today is defensible; one that was never checked is not.
  • Northern Ireland and the Channel Islands — A BT postcode is not the same as a GB destination for goods, and Jersey and Guernsey are outside the UK VAT territory despite sterling pricing and UK-style addresses. Postcode-based inference is fragile; use the marketplace's country and region fields and treat NI as a distinct jurisdiction in the determination table.
  • Rounding and gross-to-net derivation — Marketplaces price gross; most accounting systems post net plus tax. Deriving net from gross line by line, then summing, will occasionally differ by a penny from the marketplace's own total. Decide whether the ledger follows the marketplace total or its own arithmetic, and put the difference somewhere visible rather than letting it drift into a suspense account.
  • Marketplace fees and reverse charge on services — Commission, advertising and fulfilment fees charged by an overseas marketplace entity typically fall under the reverse charge for the UK seller. These belong in boxes 1 and 4 and in box 6 and 7, and they are frequently omitted entirely when only the net payout is posted.

Refunds, partial refunds and credit notes that cross a period

Refunds are where a ledger that looked healthy at go-live starts to decay. A partial refund of a mixed-rate basket has to unwind VAT in the same proportion it was applied, including on the apportioned delivery charge. A refund of delivery only, a refund where a restocking deduction is retained, and a goodwill credit with no returned goods all have different treatments, and marketplaces represent them with the same transaction type.

The period problem is more consequential. An order placed on 28 March and refunded on 3 April sits in two VAT periods. If the integration posts the credit against the original invoice date, a submitted return is retrospectively altered and the digital record no longer matches what was filed. Credit notes must carry their own tax point and post to the period in which they arise, with a stored link back to the original transaction for traceability rather than a value adjustment to it.

Where the marketplace was the deemed supplier, the refund of marketplace-collected VAT does not touch your output VAT at all — it reverses a balance-sheet amount. Getting that wrong in one direction inflates your reclaim; getting it wrong in the other leaves a growing balance in the clearing account that nobody can explain. Reconcile that clearing account monthly, and set a threshold above which the reconciliation failure raises an alert rather than a report nobody reads.

Reconciling settlement to ledger without losing the tax detail

There is a long-running argument about whether to post marketplace sales at order level or settlement level. Settlement-level posting is simpler, matches the bank, and is perfectly acceptable where the summary carries sufficient VAT analysis. Order-level posting gives you line detail for margin and returns analysis, at the cost of a clearing account that must be reconciled. Both are defensible. What is not defensible is a hybrid where some channels post one way and others post the other without anyone documenting which is which.

Our usual recommendation for a business running Amazon Seller and eBay alongside Shopify is to post order-level detail into a marketplace clearing account per channel, then post the settlement as a set of movements against that clearing account: gross receipts, fees by category, refunds, adjustments, reserves and withheld amounts. The clearing balance at period end should equal orders shipped but not yet settled. If it does not, the difference is a defect, not a rounding artefact, and should be investigated within the period.

Whether the ledger is Xero or Sage 200, the same discipline applies: every posted line carries the channel, the channel's own order or settlement reference, the tax code applied, and a reason code for the determination. Those four fields let a bookkeeper answer almost any VAT question without opening the marketplace portal, and they are what makes the digital link requirements under Making Tax Digital straightforward rather than an afterthought. A spreadsheet that re-keys figures between the integration output and the return is a break in that chain.

Building it: determination tables, evidence, and acceptance tests

The deliverable from discovery on this kind of work should be a determination table, not a diagram. Every combination of ship-from country, ship-to country and region, customer type, consignment value band, product tax class and channel should resolve to exactly one tax code in the target ledger, together with a note on who accounts for the VAT. Where a combination is possible but the treatment is undecided, mark it explicitly as unsupported so the integration can route it to an exception queue rather than guess.

Store evidence, not just outcomes. For each transaction, retain the raw channel payload or the relevant fields from it, the version of the determination table in force at the time, the resolved tax code, and the timestamp of any VAT number validation. Rules change, and when they do you need to be able to say what you did and why, for orders posted under the previous version. A determination table with a version number and an effective date costs very little to implement and saves a great deal at enquiry.

Acceptance testing should be built from the edge cases, not from the happy path. A representative test pack for a multi-marketplace seller runs to perhaps forty scenarios: mixed-rate basket with apportioned delivery, deemed supplier import under £135, EU B2B with a validated VAT number, NI destination, partial refund crossing a period end, goodwill credit, marketplace-funded promotion, reverse-charge fee posting, currency-converted settlement, and so on. Each scenario should specify the expected ledger entries and the expected effect on each VAT return box. Sign that pack off before build starts and the go-live conversation becomes a matter of fact rather than opinion.

Finally, plan for the exception queue to be used. No determination table covers everything, and a new channel, a new fulfilment location or a new product category will produce combinations nobody anticipated. An integration that fails loudly on an unmapped combination, holds the transaction, and tells a named person about it within the hour is worth considerably more than one that never errors because it always defaults to something.

Key points

  • Do not calculate VAT in the integration; record the treatment each channel applied, map it to a ledger tax code, and refuse to post combinations you have not explicitly mapped.
  • Deemed supplier sales, mixed-rate delivery apportionment, vouchers, reverse-charge marketplace fees and period-crossing credit notes account for most multi-marketplace VAT errors, and each needs a written decision before build.
  • A versioned determination table, retained raw payloads and an acceptance pack built from edge cases turn the VAT return from an opinion into something you can evidence line by line.