Why this is hard
A point-of-sale integration is judged on one thing: whether head office believes the number. Most fail that test not because the connection breaks loudly, but because it succeeds quietly and slightly wrongly.
The failure modes are consistent across vendors. Credentials shared across an estate mean one revocation blinds everything. A sync that reads the first page of orders under-reports exactly the sites that are busiest. A record stamped with retrieval time rather than trading time smears sales across day boundaries. A second terminal at a location overwrites the first instead of adding to it.
Each of these produces output that passes a glance. That is the danger: a report that is obviously broken gets fixed on the first day, and a report that is subtly broken gets used to set targets for a year.
How to connect a POS to head-office reporting: step by step
7 steps, in dependency order. Skipping ahead is usually what causes the rework.
- 1
Choose a connection per location
Authorise each site separately. One credential per location keeps a revoked key from blinding the estate and makes every sync attributable to a specific site.
- 2
Use read-only scope
Reporting needs to read orders and payments. It never needs to write to a till. Request the narrowest scope the vendor offers and document what was granted.
- 3
Sync the complete order history
Follow the vendor's pagination to the end of the range on every run, rather than taking the first page and moving on.
- Backfill a known period first — a full trading month is a good test — so you have something to reconcile against.
- 4
Store sales by trading date and by store
Key each sale to the day it happened at the location and to the location itself. Sum every terminal at that site into the same day.
- 5
Expose a sync status per location
Show when each connection last ran, whether it succeeded, and what it returned. A silent integration is indistinguishable from a closed store.
- Give an operator a manual re-sync so a suspected gap can be tested in seconds rather than escalated.
- 6
Reconcile before you report
Compare three busy days per location against the POS's own daily report. Only after those match should the feed appear on a management dashboard or drive a royalty calculation.
- 7
Rehearse the integration before going near a live till
Exercise the full connect-sync-report path against a simulator or sandbox first, including a location with two terminals. Discovering the multi-till case in production means discovering it as a wrong invoice.
What good looks like
- Every location shows a last-synced time and an outcome.
- A manual re-sync is one click and reports what it found.
- Order counts reconcile with the POS's own daily totals on busy days.
- Revoking one location's credential affects exactly one location.
Mistakes that make the effort worthless
Reporting the connections a store form remembers rather than the connections that exist.
Read integration status from the integration records themselves. A configuration field that was filled in once is a claim, not a status.
Going live on the first successful sync.
A successful sync proves authentication worked. Reconciliation proves the data is right. They are different tests and only the second one matters to finance.
Hiding sync failures behind a zero.
Surface the failure. "No connection" and "no sales" must never render the same way.
How Stores360 does this
The method above works with any tooling. This is how it is handled if you run it on Stores360.
- Point-of-sale connections are configured per store, from the store record, with the status read from the connections that actually exist.
- A POS sync status screen shows each location's last run and outcome, and a Sync now control forces a fresh pull on demand.
- Order history is paged through completely, each run is recorded against the connection that produced it, and sales land on the trading date under the curated sales layer that reports and royalties both read.
- A simulator exercises the whole integration path — including a location answering one till at a time — without a live merchant account.
Frequently asked questions
Which POS systems can be connected?
Any POS that exposes order and payment data through an API can be connected. Toast is supported today; the connection model is per-location, so a mixed estate can be brought on site by site.
Does connecting a POS change anything at the till?
No. The connection is read-only. Staff behaviour at the terminal does not change, and no configuration on the till is altered.
What happens if a POS connection fails?
The location's sync status shows the failure and the reason, rather than reporting an empty day. Re-authorising and running a manual sync backfills the missed range.
Can a location have more than one till?
Yes, and it must be handled deliberately. Each terminal contributes to that location's daily total; a system that lets the second overwrite the first will under-report your busiest sites.
Keep reading
How to track sales across multiple store locations
One comparable number per store per day — including the details that quietly break most multi-site sales reports.
How to calculate and invoice franchise royalties
Turn the monthly royalty spreadsheet into a policy, a billing run and an invoice per location.
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.
Or browse every how-to guide.