Why unify Shopify and Amazon into the same VAT workflow
More and more sellers work in a multichannel setup: their own Shopify store plus one or more marketplaces (Amazon, eBay, etc.) to capture existing demand. From a VAT perspective, though, each channel produces different reports, with inconsistent logic and fields; if you handle them separately, you risk losing consistency on the OSS threshold, rates and cross-checks.
A single VAT workflow for Shopify and Amazon lets you:
- have a consolidated view by country of consumption, regardless of channel;
- understand when you cross the EU OSS threshold accounting for all channels, not just Amazon;
- avoid double declarations on sales already covered by the marketplace’s “deemed reseller” regime;
- hand your accountant a single set of structured reports.
The goal isn’t to lose the per-channel detail, but to start from homogeneous data and only have separate views where needed (e.g. margin checks per marketplace).
Structural differences between Shopify and Amazon reports
Shopify and Amazon represent sales very differently:
- Shopify typically exports order and payment reports with columns like
Order ID,Customer country,Tax lines,Gateway fees; - Amazon uses the VAT Transaction Report, with columns like
TRANSACTION_TYPE,SALE_DEPARTURE_COUNTRY,SALE_ARRIVAL_COUNTRY,TAXABLE_AMOUNT,TAX_RATE,VAT_CALCULATION_SERVICE.
To build a unified workflow you need:
- A common period key: the month or quarter the data belongs to, not just the file generation date.
- A unified “country of consumption” field: for Shopify it’s the customer’s shipping country, for Amazon it’s
SALE_ARRIVAL_COUNTRY. - A clear B2C/B2B distinction: in Shopify you can use customer tags or a VAT ID; in Amazon the
BUYER_VAT_NUMBERcolumn often indicates B2B sales. - A standard column for the VAT rate applied: on Shopify you derive it from the tax lines, on Amazon from
TAX_RATE.
Only after this normalisation does it make sense to talk about a unified VAT workflow.
OSS, domestic sales and local registrations
When you sell in multiple EU countries, you need to distinguish three fronts:
-
Domestic sales: from your country of establishment to customers in the same country (e.g. IT → IT). These go into the domestic VAT return, not the OSS scheme.
-
Intra-EU cross-border B2C sales: from your country to other EU countries (IT → DE, FR, ES, etc.). If you exceed the overall EU threshold of €10,000, they fall under the OSS scheme.
-
Sales from local stock in other EU countries: if you have Amazon warehouses in Germany, France, Poland, sales from those warehouses to customers in the same country are local domestic sales and require local VAT returns.
The unified VAT workflow must separate these three blocks, but consistently across Shopify and Amazon:
- a Shopify order shipped from your Italian warehouse to a German customer is a potential OSS sale;
- an Amazon sale from a German warehouse to a German customer is a domestic DE sale, outside OSS;
- an Amazon sale from an Italian warehouse to a French customer instead falls under cross-border sales (and therefore OSS).
How to map Shopify and Amazon into the same data schema
A robust approach is to define a “pivot” data schema with minimal but well-defined fields, for example:
source(SHOPIFY / AMAZON);order_id/transaction_id;activity_period(YYYY-MM or quarter);country_of_destination(country of consumption);country_of_dispatch(country of origin);b2b_flag(TRUE/FALSE);taxable_amount(in original currency and in EUR);vat_amount;vat_rate;vat_regime(DOMESTIC, INTRA-EU-OSS, NON-EU, IOSS, out of scope).
For Shopify you need to do some work on the orders:
- normalise countries with ISO codes (DE, FR, ES…);
- consolidate the tax lines of each order to get the taxable amount and total VAT;
- apply rules to distinguish B2C from B2B (e.g. presence of a VAT ID or customer type).
For Amazon, on the other hand, you use the VAT Transaction Report fields directly and map them into the pivot schema.
Risks of managing channels separately
Treating Shopify and Amazon as “separate worlds” carries some recurring risks:
- OSS threshold calculated on Amazon only: if Shopify grows, you could cross the threshold without noticing, continuing to apply Italian VAT where you should have applied foreign rates.
- Double-counting sales handled as deemed reseller: some marketplace sales are the marketplace’s tax responsibility; if you add them “by hand” to your OSS flows you create a double declaration.
- Reports that don’t reconcile: presenting inconsistent reports to your accountant (one for Shopify, one for Amazon) increases the risk of errors and review time.
- Difficulty in case of an audit: tax authorities look at the overall picture; if the logic across channels isn’t aligned, explaining numbers and differences becomes complex.
Example of a unified operational workflow
A “typical” VAT workflow for a seller using Shopify + Amazon can be:
- Monthly export from Shopify (orders + payments) and from Amazon (VAT Transaction Report).
- Normalisation:
- currency conversion to EUR at the ECB rate for the relevant month;
- country and ISO code mapping;
- B2B/B2C classification.
- Enrichment: attaching the correct VAT regime to each row (domestic, OSS, non-EU, IOSS).
- Aggregation by country: calculating taxable amount, VAT and rates used for each country of consumption.
- Splitting for returns:
- a data block for the domestic VAT return;
- a data block for the OSS return;
- any blocks for local returns in countries with an Amazon warehouse.
- Consistency checks: verifying that total revenue (Shopify + Amazon) reconciles with the general ledger.
How VATManager helps with multichannel
VATManager was built specifically to handle multichannel scenarios:
- imports the Amazon VAT Transaction Report and Shopify reports;
- normalises currencies, countries and B2B/B2C status;
- applies the VAT rate matrix by country and product category;
- automatically separates OSS sales, domestic sales and non-EU sales;
- produces a single report by country and VAT regime, with drill-down by channel.
This way, Amazon and Shopify stop being “silos” and simply become two data sources feeding a single, coherent tax pipeline.