Malaysia · POS consolidation
Different POS in every outlet. One set of group numbers.
A Malaysian group with outlets rarely runs one POS. Sites get acquired, franchisees choose their own, and a system that works at one location gets kept for a decade. The result is a dozen exports in a dozen shapes, and a group revenue figure assembled by hand. Replacing every till is the expensive answer and usually the wrong one — the data layer is where this gets fixed.
Before and after
What changes when
the data finally talks.
Today's friction
- Each outlet on a different POS, exporting a differently shaped file
- The same dish named three ways across three outlets, so nothing sums
- Daily sales re-keyed into accounting outlet by outlet
- Consolidated e-invoice submissions prepared as a separate manual scramble
- Delivery-platform orders reconciled apart from dine-in and takeaway
- Group position visible only once the slowest outlet has closed
With Ontilus
- Every outlet keeps its POS; consolidation happens in the data layer
- Item names mapped once to a group catalogue, so outlets are comparable
- Daily sales posted to the accounting system without anyone re-keying
- Invoice data validated before submission rather than after rejection
- Dine-in, takeaway and delivery reconciled into one revenue line
- Group position available any day, not only after close
What we build
Engineered for POS consolidation.
Every system is bespoke to your entity structure. These are the modules this sector almost always needs.
Item normalisation
The unglamorous core of this work. The same item is spelled, abbreviated and mis-typed differently at every outlet, and until those collapse to one catalogue entry no cross-outlet total means anything. Mapped once, then maintained as menus change.
POS ingestion
Read through an interface where the vendor offers one, and through a scheduled export or file drop where it does not. An unsupported POS is a slower integration, not a blocker — which matters, because the older tills are usually in the outlets you least want to disrupt.
E-invoicing in the same flow
Consumer receipts are not submitted one by one; they are grouped and summarised under LHDN's consolidation rules. Because the sales data has already been captured and validated, submission becomes a step in an existing pipeline rather than a month-end scramble against a deadline.
Channel reconciliation
Dine-in, takeaway and the delivery platforms reconciled into one revenue line, with commission and platform fees separated so net and gross are both readable.
Outlet profitability
Once outlets are comparable, per-outlet profitability becomes answerable — and it is three separate questions rather than one, depending on how shared costs are allocated.
Group roll-up
Outlet-level revenue feeding the entity consolidation above it, so the sales layer and the statutory layer agree instead of being argued about at close.
Questions
POS consolidation,
answered.
The questions operators in this sector ask first. If yours isn't here, ask us directly — we answer scoping questions before there's a contract in sight.
Talk to usDo all our outlets need the same POS system?
No, and standardising first is what usually stalls this work. Every outlet keeps what it runs; consolidation happens in the data layer by reading what each system already produces and mapping it to a shared structure. Replacing tills across a group is a capital project with an operational risk at every site, and it is rarely the cheapest route to the number you actually wanted.
Our POS is old and has no API. Is that a blocker?
No. Where there is no interface, a scheduled export or file drop covers it — the same route that middleware uses for e-invoicing when a POS is unsupported. It is a slower integration and it needs a reliable export on a schedule, but it is not a wall. This matters more than it sounds, because the oldest tills are usually in the outlets with the longest trading history and the least appetite for disruption.
How do you handle the same menu item being named differently at each outlet?
By mapping every outlet's item list once to a single group catalogue, then maintaining that mapping as menus change. It is the least impressive part of the work and the part everything else depends on: unnormalised item names make every cross-outlet comparison quietly wrong rather than obviously broken, which is the more dangerous failure. New and unmatched items surface for a person instead of being guessed at.
How does this fit with MyInvois consolidated e-invoicing?
Consumer sales are grouped and summarised rather than submitted receipt by receipt, and the internal records behind them still have to be kept. If sales data is already being captured, normalised and validated for reporting, the submission draws on that same governed data instead of a separate manual extract. Validation belongs before submission, because a rejected submission costs more to fix than a held one. Check the current deadlines and thresholds against LHDN directly — they have moved during the rollout and they will again.
What can we see that we cannot see today?
Comparable outlets. Same-day group revenue instead of a figure that waits for the slowest close, revenue split by channel with platform commission separated, and per-item performance that holds up across sites. What it does not give you is a verdict on which outlet to close — that stays a judgement, because it depends on how you allocate shared costs, and that choice changes the ranking.
How we deploy
Live in 12 weeks.
Proven before it scales.
We pilot on one entity and validate against your own close reports before anything goes group-wide. See the full deployment approach →