The critical decision in multi-store retail
The critical decision is the degree of centralisation: price and campaigns should be managed centrally, but a sale must complete in the store independently of the centre. In a design where the till waits for central approval, a link outage turns directly into lost revenue. We detail this architecture in our [offline POS design guide](/en/blog/retail-pos-guide).
Critical processes
- Offline selling: a local copy of prices and campaigns, a sales queue and conflict-free synchronisation when connectivity returns.
- Central price and campaign management: versioned rule sets and tracking which till runs which version.
- Store-level stock: store inventory, inter-store transfers, transfer approval and goods in transit.
- End-of-day reconciliation: comparing till totals, fiscal device reports, bank POS totals and the physical count.
- Authority matrix: the discount and return limits a store manager can approve.
- Loyalty and customers: point balances working under an offline limit.
Which solution maps to what
Store operations use [retail POS](/en/products/retail-pos), online and marketplace channels use [e-commerce software](/en/products/ecommerce-software), customer and campaign management uses [CRM](/en/products/crm-software), and staff scheduling uses [time and attendance](/en/products/time-attendance). Central inventory, purchasing and costing fall under [ERP consulting](/en/solutions/erp-consulting), while branch connectivity and link redundancy are planned under [enterprise network solutions](/en/solutions/enterprise-network).
Mandatory integrations
Fiscal printers and payment devices, bank POS reconciliation ([bank integration](/en/products/bank-integration)), e-invoicing and e-archive, scales and barcode hardware, marketplace channels, shipping carriers and accounting.
Where we start
In multi-store retail the starting point is usually this: a local till program in every store, a separate stock program at head office, and a daily file transfer between them. Price changes are communicated by hand, and end-of-day differences surface weeks later.
The first exercise produces a map of where each decision is made: price at the centre, discount authority with the store manager, return rules at the centre, stock counting in the store. Neither the till design nor the authority matrix can be built before that map is clear.
What the data model must make explicit
- Receipt line: till identity, cashier, item, quantity, the campaign rule applied and its version.
- Payment line: payment type, device transaction number, instalments and bank reference — as separate lines from the receipt total.
- Return reference: which receipt the return is made against; returns without a reference must be flagged as a distinct transaction type.
- Campaign version: the rule set version number and which version is active on which till.
- Transfer state: dispatch, in-transit and receipt as separate stages; a single-step transfer produces stock differences.
- Count session: counter, date, stock before and after, with the adjustment recorded separately.
Roll-out sequence
1. Single-store pilot: running the till, price, campaign and end-of-day flow end to end in one branch.
2. Head office integration: price and campaign distribution, sales upload, bank POS reconciliation.
3. Multi-store: transfer flow, cross-store stock visibility and the authority matrix.
4. Channel expansion: online channel, marketplaces and publishing store stock.
Choosing the pilot store matters: pick the most complex branch, not the easiest. A design that works in an easy store breaks during roll-out.
What we measure
- End-of-day differences broken down by source (till, bank POS, count)
- Offline running time per till and the number of queued transactions
- Time for a campaign rule version to reach the stores
- Time for inter-store transfers to be accepted, and the value of goods in transit
- Share of returns without a reference
Common mistakes
- Designing the till to depend on the centre. Selling stops when the link drops; that is an architectural choice, not an infrastructure problem.
- Not versioning campaigns. How a past receipt was calculated cannot be verified afterwards.
- Closing transfers in one step. Goods in transit become invisible and count differences blend into transfer differences.
- Publishing store stock online without count accuracy. This is the most common cause of overselling.
Frequently asked questions
Should store stock be exposed to online sales?
You can, but reliable store counting is a precondition. Publishing store stock while count accuracy is low is the most common cause of overselling; see our [e-commerce stock synchronisation guide](/en/blog/ecommerce-software-guide).
At how many stores does a central structure become necessary?
Less about store count than about the need for inter-store transfers and central campaigns. Even between two stores, regular transfers require central stock visibility.
How do you find the source of an end-of-day variance?
Every sale must be stored with its till identifier, cashier, payment type, device transaction number and return reference. If those fields are not designed in from the start, variance analysis becomes manual work.
Do single-store businesses need this structure?
A single store needs no central distribution or transfer flow, but offline selling, end-of-day reconciliation and campaign versioning apply just as much. If growth is planned, designing the till to be store-independent from the start costs less than migrating later.
Can franchise and own stores run on the same system?
They can, provided authority and data visibility are separated: a franchisee sees its own turnover and stock, not other branches. That separation must be built as a data scope definition rather than role-based screen hiding.
How is store staff shift and overtime calculation connected?
The till session and the staff record must match on the same identity, so cashier-level sales analysis and [time and attendance](/en/products/time-attendance) data meet on the same person. With two separate staff lists the matching is manual and degrades over time.