Multi-Location POS Reporting: How to Get Every Store Into One Report

Every till in your chain records every sale. The trouble starts when you ask for yesterday's sales across all the stores. Each store's system has its own idea of what a sale is, when a day ends, what the store is called and what each product is called. Add the store reports together and you get a total, but not one you can compare store by store.

So consolidating POS data is mostly agreement, not arithmetic: one definition of a sale, one business day, one code for each store and each product, and a check that every store actually reported. This guide takes them in that order. It applies whether your stores run one POS system or several.

Why adding up the store reports gives the wrong total

Take two stores on different systems. Both close the day and send a report, and the reports look alike:

Each report is right by its own rules. Added together, they mix sales with and without VAT, treat discounts two ways and put part of Friday night into Saturday. Statistics offices that build price indices from retailers' till data meet the same problems at national scale. The UK's Office for National Statistics notes that some retailers send refunds as separate rows, that some give a relaunched product a new code, and that retailers' own product hierarchies do not cleanly map onto its categories¹.

Agree on one definition of a sale

Write down, once, what a sale means in your chain's reports, and convert every store to it. For comparing stores, the usual choice is net sales: after discounts, excluding VAT, with returns subtracted. VAT has to go because rates differ between countries and between product types, so two stores with the same trade can show different gross sales. Two more decisions are worth stating outright:

• Returns: book them on the day they happen, in the store that takes them back, and show them as their own line. A store that takes back what other stores sold should not look like a store that sells less.
• Discounts: keep them visible next to sales, not only taken off. A store whose sales hold up because of discounts looks healthy on net sales alone.

Returns are not a rounding error. US retailers estimated that 15.8% of their 2025 sales would come back, counting online and store sales together². They are also where losses at the till hide. In the US National Retail Security Survey, refund fraud was among the four most reported methods of employee theft, and exception-based reporting and alerts on unusual POS transactions were among the five most used defences³. Neither works unless every store's returns and discounts sit in the same place in the report.

Give every sale one business day and one store

A sale after midnight belongs to the evening that produced it, not to the next day's trading. Set a business day for each store in its own local time, ending after the last possible sale, and date every transaction by it:

Without that rule, a late-closing store looks weak on Fridays and strong on Saturdays, and stores in different time zones never line up.

Stores need one code each, kept in one list that maps every system's store ID to it and says what kind of location each one is: a store, a warehouse, an online shop. GS1, the body behind barcodes, defines the Global Location Number for this job, an identifier for a physical location⁴. You do not need GS1 numbers to run the list, but you do need the list, and a check that tells you when a system reports a store it does not know.

Match the products, not just the stores

Totals per store need only store codes. Once you compare a product or a category across stores, the products need one identity too, and barcodes help less than you might expect. A GTIN, the number behind a barcode, identifies a trade item, and a separate GTIN is required whenever the item changes in any way that matters to trading⁴. A change to the net content printed on the pack, for example, needs a new one⁵. So the same product on the same shelf can carry two codes within a year, and goods weighed or repacked in store often carry the chain's own codes, which differ between systems.

In practice, chains map every product into one shared category tree first, and link individual product codes only where they need product-level comparison. The ONS works the same way with retailers' data: it assigns each product to its own categories with what it calls machine-assisted manual classification, and links relaunched products to the originals¹.

Check that every store reported before you read the numbers

A store whose data did not arrive looks exactly like a store that sold nothing. Before anyone compares stores in the morning, put each store's feed through the same checks:

Late data is normal. A till that lost its connection uploads when it is back, and a POS system can correct a day after it closed. So reload the last several days every night, not only yesterday, and let a corrected day replace the old figures rather than add to them.

Reconcile the report with the money

Till sales are a claim; the bank and the safe are the evidence. Card takings reach the bank in batches, a day or more later, and cash is counted in the store. In the euro area, cash was used in 52% of transactions at the point of sale in 2024, and by value cards carried 45% against cash's 39%⁶. Matching till sales against bank deposits alone leaves a large part of the day unchecked.

Reconcile per store and per day, not for the chain as a whole. A gap that repeats in one store points at a process there; a gap that moves from day to day is usually timing.

What the consolidated report should show

Once every store is on the same definitions, the morning report is the easy part: for each store, net sales, the number of receipts, the average receipt and margin where cost data exists, each next to the same weekday a week earlier. How to compare the stores fairly from there, and how to tell a bad week from a real decline, is the subject of the retail operations dashboard guide.

How marql consolidates POS data

marql reads sales from a chain's POS and ERP systems as they are, without replacing any of them. It checks each connected system every five minutes and re-reads the past week every night, so late uploads and corrected days replace earlier figures instead of adding to them. Each sale is dated by the store's local business date, and each system's store IDs are mapped to one list of the chain's stores.

Products are sorted into one category tree every night, and the ones the classifier is unsure of go to a person to confirm. Discounts and refunds are reported next to revenue, not hidden inside it, and every source shows how fresh its data is: late after six hours, stale after a day. The data flow page shows the path from a till to the morning report, and the integrations page lists the systems marql connects to.