Multi-store

Why setting up multi-store from day one saves you hours later

April 23, 2026 · 7 min read

Key takeaways

Going multi-store is easy; retrofitting a single-store setup for a second store is the painful part, because every baked-in assumption becomes a bug.
Designing for multi-store on day one costs nothing extra and saves a weekend of migration plus a permanent tax on every report.
Three day-one decisions cover most of it: add a store/region identifier from the first row, keep currency explicit rather than implied, and separate store identity from workflow.
A second store in another country turns the problem into a multi-region one, with different marketplaces, carriers, and currencies compounding at once.
Fetch Order Tracking is built multi-store from the ground up, running eBay UK, US, and AU stores from one workspace into the same Google Sheet, each row tagged by store.

Almost every seller starts with one store and a spreadsheet built for exactly that — one store. It works beautifully right up until the day you open a second. Then the cracks appear: which row belongs to which store, which currency is this, why is the same tracking sync clobbering two sets of orders, and why does everything take twice as long?

The honest truth is that going multi-store is not the hard part. Retrofitting for multi-store is the hard part. If you design for it on day one — even when you have no intention of opening a second store soon — the second store costs you almost nothing later. If you do not, you pay for it in a painful weekend of migration and a permanent tax on every report you run.

What goes wrong when you bolt it on later

A single-store setup makes silent assumptions everywhere. When the second store arrives, every one of those assumptions becomes a bug:

No store column. Your orders all lived in one tab, so there was nothing to distinguish them. Now you are colour-coding rows by hand or splitting into tabs that drift out of sync.
One currency baked in. Your profit formulas assumed GBP, or USD, or whatever your first store used. A second region quietly corrupts every margin number.
One credentials slot. Your tracking workflow was wired to one eBay account and one set of tokens. Adding another means duplicating the whole machine.
Reports that cannot separate or combine. You can no longer answer "how did store B do this week" without manual filtering, and you cannot see the business as a whole either.

The cost of multi-store is not in running two stores. It is in the day you try to turn a one-store system into a two-store system while orders are still flowing through it.

The day-one design that costs you nothing

You do not need to open a second store to be ready for one. You need a layout and a workflow that would not flinch if you did. Three decisions cover most of it:

Add a store identifier from the first row. Even with one store, give every order a store/region field. It is one column today and the spine of every filter and report forever after.
Keep currency explicit, never implied. Store the currency alongside the amount. Your profit math should read the currency, not assume it. This is the same discipline behind getting your gross profit column right — never let a number's meaning live only in your head.
Separate identity from workflow. Treat "which store" as data attached to each order, not as a hard-coded path through your tools. Then a new store is new rows, not a new machine.

Regions multiply the problem

If your second store is in another country, the multi-store problem becomes a multi-region problem, and the variables compound: different marketplaces, different carriers, different currencies, different buyer expectations. A tracking ID that resolves to Evri in the UK means nothing to a US buyer, and a profit figure mixing GBP and USD is just noise.

A workspace that was designed for one region cannot cleanly absorb a second. One that was designed for many treats region as just another attribute of the order — so UK, US, and AU stores coexist without you maintaining three parallel systems. We go deeper on that in running eBay UK, US, and AU stores from one workspace.

How Fetch Order Tracking makes it a non-event

Fetch Order Tracking is built multi-store from the ground up, which is exactly why adding a store is a non-event rather than a migration. From one workspace you can:

Run eBay UK, US, and AU stores side by side, each keeping its own identity.
Split Amazon, AliExpress, and MH orders by SKU so the right source order maps to the right sale.
Pull true net earnings per store via eBay's Finances API — real payout after fees, in the right currency — instead of guessing from gross prices.
Sync every store into the same Google Sheet you already own, with each row tagged so you can filter to one store or roll them all up.

Because the same batch engine clears every store in one pass, you are not running your tracking routine two or three times a day. You run it once. The auto-chaining that makes that possible is covered in why batch processing beats one-by-one for AE tracking calls.

Whether you have one store today or five, design as if you will have more — because you probably will, and the version of you who opens store number two will be grateful. Try Fetch Order Tracking and start on a foundation that grows with you instead of one you will have to tear up.

Frequently asked questions

I only have one store right now — is it really worth designing for multi-store?

Yes, because the cost is almost nothing today and the saving is large later. Adding a store/region column and keeping currency explicit takes minutes on day one, but converting a one-store sheet into a two-store sheet while orders are flowing through it is a painful migration. You are not building a second store before you need it — you are leaving the door open so opening one is new rows, not a new machine.

What is the single most important thing to set up for multi-store from the start?

A store or region identifier on every order, from the very first row. It is one column when you have one store, and it becomes the spine of every filter, report, and roll-up the moment you add a second. Pair it with storing the currency alongside each amount so your profit math reads the currency instead of assuming it, and most of the multi-store pain disappears.

Can I run eBay stores in different countries from a single workspace?

Yes. A workspace designed for many regions treats region as just another attribute of the order, so UK, US, and AU stores coexist without three parallel systems. Fetch Order Tracking is built this way: it runs each store side by side from one workspace, pulls true net earnings per store via eBay's Finances API in the right currency, and syncs every store into the same Google Sheet with each row tagged so you can filter to one store or combine them all.

Related guides

Try Fetch Order Tracking → More guides