Why this is hard
The reason multi-site sales reporting is hard has almost nothing to do with charts. It is that four unglamorous details go wrong, and each one produces a number that looks plausible and is not.
The first is the date. Many POS APIs stamp a record with when it was retrieved, not when the sale was rung. Report on the retrieval date and every late-night trade lands on the wrong day, which quietly ruins day-of-week analysis and any target built on it.
The second is paging. Order APIs return a page at a time. A report that reads the first page and stops will under-count busy sites specifically — the ones you most need to be right about.
The third is multiple tills. A location with two terminals produces two streams. If the second overwrites the first rather than adding to it, your busiest store looks like your quietest. The fourth is definition drift: one site reports gross, another net of refunds, a third excludes delivery commission. Nobody notices until two people bring different numbers to the same meeting.
How to track sales across multiple store locations: step by step
6 steps, in dependency order. Skipping ahead is usually what causes the rework.
- 1
Inventory what each location actually runs
List every site, its POS product, and whether it has more than one terminal. Acquired sites frequently run something different from the rest of the estate.
- Record how many tills each location has — this is the detail most often missed.
- Note which sites take orders through a channel that bypasses the till entirely, such as a delivery marketplace.
- 2
Connect each location to a read-only data feed
Authorise a connection per location rather than one credential for the estate, so a revoked key takes down one site instead of all of them, and so each sync run is attributable to the connection that produced it.
- Read-only is sufficient. Nothing in reporting needs write access to a till.
- Keep a visible sync status per location so a silently dead connection is obvious rather than presenting as "a quiet week".
- 3
Read the whole order history, not the first page
Follow pagination to the end on every sync. Reconcile the resulting order count against the POS's own daily total for a sample of busy days before you trust it.
- 4
Key everything on trading date and store
Store each sale against the date it was rung at the location, and against the location, so a day means the same thing everywhere. Sum all tills at a site into that day's figure.
- Test explicitly with a late-evening sale and with a two-till site — these are the two cases that break silently.
- 5
Fix one definition of sales and publish it
Decide gross versus net, how refunds and voids are handled, and whether tax is included. Write it down where anyone reading a dashboard can see it.
- 6
Compare over identical windows and rank
Report store against store over the same date range, then rank. Ranking is what converts a report into a decision — it names the site that needs a visit and the site worth copying.
- Roll up by brand and region as well as by store, so an area manager sees their own patch.
- Keep the raw per-store figures reachable from the roll-up, or nobody will believe the roll-up.
What good looks like
- Yesterday's numbers for every location are on one screen, without anyone logging into a till.
- A late-night sale appears on the day it was rung.
- A two-terminal site reports the sum of both terminals.
- A broken connection announces itself as a broken connection, not as a bad week.
- Finance and operations quote the same sales figure without pre-agreeing it.
Mistakes that make the effort worthless
Trusting a first sync because the totals "look about right".
Reconcile against the POS's own daily report for three busy days per site. Paging and till bugs produce numbers that look about right by design.
One shared POS credential for the whole estate.
A connection per location. It contains the blast radius of a revoked key and makes every sync run attributable.
Treating an empty day as an empty day.
Distinguish "this location traded nothing" from "this location did not sync". They look identical on a chart and mean opposite things.
How Stores360 does this
The method above works with any tooling. This is how it is handled if you run it on Stores360.
- Each location gets its own point-of-sale connection with a visible sync status and a Sync now control, so an operator can force a refresh and see the result.
- Order history is read through to the last page on every run, and each run is recorded against the connection that produced it.
- Sales are stored by trading date and by store, with every till at a location adding to that location's day rather than replacing it.
- Reports roll up by store, brand and region over any date range, and Operations ranks locations against each other.
- When a sales query cannot be answered, it says why rather than returning a confident zero.
Frequently asked questions
Can I track sales across locations that use different POS systems?
Yes. The point of a central sales layer is that it normalises different sources into one shape. Mixed estates are the normal case after any acquisition.
Why do my consolidated sales not match my POS report?
In order of likelihood: the report is keyed on upload date rather than trading date, pagination stopped at the first page, a second till at a site is overwriting the first, or the two are using different definitions of sales.
How often should location sales sync?
Daily is enough for management decisions. Near-real-time matters mainly for intraday staffing calls. What matters more than frequency is that failure is visible.
Do I still need my POS reporting?
Yes, as the source of truth for a single site and for reconciliation. Consolidated reporting answers the questions a single POS cannot: which store, versus which other store, over what period.
Keep reading
How to connect a POS to head-office reporting
What a POS integration has to get right before head office should believe a single number it produces.
How to manage multiple store locations
The full method for running a network you can no longer walk around — from one set of numbers to standards that hold.
How to calculate and invoice franchise royalties
Turn the monthly royalty spreadsheet into a policy, a billing run and an invoice per location.
Or browse every how-to guide.