Four POS systems, one set of numbers.

The problem is not integration. It's agreement.

Groups usually describe this as an integration problem: the systems don't talk. That framing leads to buying a connector, discovering the connector works, and still not trusting the total. The harder problem sits underneath — the same real-world thing is recorded differently in each system, so even a perfect pipe produces numbers that don't reconcile.

Three specific disagreements account for most of it:

• Boundaries. One outlet closes its business day at 2am, another at midnight. Sum them by calendar date and every late-night venue is misattributed.
• Definitions. One system reports net of tax and discount, another reports gross. Both call the column "sales".
• Identity. The same ingredient exists as four different item names across four outlets, so nothing can be compared or aggregated.

Step 1 — Ingest without asking anyone to change systems

Any plan that starts with "first, migrate everyone onto one POS" is a plan that will not happen. It stalls on cost, on training, and on the one outlet whose manager will not move. Build over what exists instead.

In practice there are three tiers, and a typical group needs all three:

The third tier is the one that gets skipped in a proposal and then blocks the rollout. Assume at least one outlet is there. A local sync agent that watches an export folder is unglamorous and it is often the difference between a system that covers the whole group and one that covers the easy 70%.

Step 2 — Reconcile against the close report before trusting anything

This is the step that decides whether the group ever uses what you build. Every ingested day must reconcile against that outlet's own end-of-day close report — the number the manager already believes.

Not "roughly matches". Reconciles, to the cent, with any variance explained. Voids, comps, staff meals, tips, rounding and refunds all have to be classified, because each of them is a legitimate reason for a gap and an illegitimate place to hide an error.

If the first number a general manager sees disagrees with their own close report, you have lost them, and no amount of later accuracy wins them back. Slower and reconciled beats fast and disputed, every time.

Step 3 — Normalise item names, or none of it aggregates

This is the least glamorous part of the work and the one that creates most of the value. Across a group, the same ingredient will be entered as BUTTER SALTED 1KG, Butter (salted) 1kg, SALTED BUTTER — 1 KG and btr-salt-1000g. Until those resolve to one entity, you cannot compare what two outlets paid for the same thing, and cross-outlet purchasing intelligence is impossible.

Name matching alone is not enough — fuzzy string distance will happily merge two genuinely different products. What works is matching on several signals together: normalised name, unit and pack size, supplier, and observed price band. Then hold back anything ambiguous for a human decision rather than guessing.

The reward is immediate and concrete. Once names resolve, a question that was previously unanswerable — are two of our outlets paying different prices for the same item from the same supplier? — becomes a report. In our own F&B work, the first run of that report surfaced a real price gap on a single staple between two outlets in the same group.

Step 4 — Report by entity, not just by outlet

Multi-outlet and multi-entity are different problems, and groups that solve only the first hit a wall at the board pack. Outlets roll up to brands; brands roll up to legal entities; entities have different ownership splits and different reporting obligations.

Model that hierarchy in the data layer from day one. Retrofitting it means rebuilding every aggregate you have already shipped, and access control has to follow the same shape — an outlet manager sees their outlet, a brand lead sees their brand, a director sees the entity.

What a realistic timeline looks like

Ontilus deploys this in twelve weeks, and the sequence matters more than the total. Weeks 1–3 are a single pilot entity, all the way through to reconciled numbers. Weeks 4–6 add costing and inventory. Weeks 7–10 roll out to the remaining entities including the legacy ones. Weeks 11–12 turn on group-level reporting and the AI layer above it.

Nothing goes group-wide until the pilot reconciles against the client's own close reports. That looks slower written down, and it is faster in practice, because nobody has to unpick a bad rollout in front of the people who have to use it.