Jantore S.11 min readiiko wins for new restaurants and growing chains that need fast deployment, modern cloud infrastructure, and strong API integrations with delivery aggregators. R-Keeper wins for large established chains that already run on it and need deep customization, complex loyalty programs, and enterprise-grade back-office configuration. The worst outcome is migrating from R-Keeper purely for a modern interface while underestimating the operational disruption, or choosing iiko without confirming it covers your specific kitchen workflow requirements. In practice, though, the more common failure is neither: it is choosing correctly and then never configuring the system, which leaves either platform producing the same thin reporting a cash register would.
| iiko | R-Keeper | |
|---|---|---|
| Cloud architecture | Cloud-native SaaS. All data syncs in real time, accessible from any device with internet. No local server required. | Traditional on-premise architecture with optional cloud add-ons. Local server stores all data, internet outage does not halt operations. |
| Multi-branch management | Centralized cloud dashboard for all locations. Menu changes, pricing, and promotions push to every branch instantly. | Powerful multi-branch tools, but configuration is complex and typically requires a certified dealer for setup and changes. |
| Kitchen & inventory | Built-in ingredient-level inventory tracking, recipe costing, and automated write-offs. Sufficient for most restaurant formats. | StoreHouse module is an industry benchmark for deep inventory control. Handles complex production chains and multi-warehouse logistics. |
| POS usability | Clean, modern interface. New staff typically reach proficiency within one to two shifts. Touchscreen-first design. | Functional but dated interface. Training cycle is longer — typically three to five shifts for full cashier proficiency. |
| API & integrations | Open REST API. Native integrations with Glovo, Wolt, Yandex Food, Kaspi QR, and major delivery aggregators in Kazakhstan. | Proprietary integration framework. Strong ecosystem of dealer-built modules, but custom development costs are higher. |
| Pricing & TCO | Monthly subscription per terminal. Predictable cost that scales with locations. No upfront server investment. | License-based pricing plus dealer service fees. Higher upfront cost, but lower recurring fees for large deployments over time. |
iiko was built cloud-first, meaning all operational data — sales, inventory, staff schedules — lives in a centralized cloud and syncs across devices in real time. This eliminates the need for a local server, reduces IT overhead, and enables remote management. Cloud-based POS systems now represent the majority of new restaurant technology deployments globally, with the cloud POS market expanding at a 22.6% CAGR through 2033 according to MarketDataForecast. R-Keeper runs on a local server architecture refined over 30 years. The operational advantage is resilience: if your internet drops, R-Keeper keeps processing orders. For high-volume venues in areas with unstable connectivity, this matters. R-Keeper now offers R-Keeper Cloud, but the core product remains server-dependent.
This is the part most comparisons cannot write, so the limitation comes first: opengate runs the reporting and inventory layer over iiko at three venues in Almaty and has no first-hand R-Keeper deployment. Everything measured below is iiko. Where R-Keeper appears, it is described from its documentation and its dealer ecosystem, not from operating it.
The finding is not about features. Across all three venues, a meaningful part of the schema is simply empty. At one venue, the table number, order type and service type fields each carried exactly one distinct value across 39 trading days, and that value was blank — not a sync failure, not a licensing limit, just three fields nobody was ever asked to fill. Every report that would have split revenue by dine-in versus takeaway, or by table, was structurally impossible there. No vendor comparison would have predicted it, because iiko supports all three perfectly well.
That reframes the whole exercise. The feature-depth argument between the two platforms is a real argument, but it only begins to matter once a venue populates the fields those features read. A venue that leaves service type blank gets the same analytical value from a system with a deep inventory module as from one without.
The most useful model to come out of running these systems is that data quality is not a property of the POS. It is a property of each individual field, and the fields split along one line: whether the business can trade without them.
Machine-generated fields are close to perfect. At one venue the pre-cheque timestamp was populated on 702 of 703 orders, the shift number on 27 of 27, the cashier on every order, and card totals reconciled against the acquirer's own statement. Those fields exist because the venue cannot take money without them.
Fields that are optional to trading are empty or repurposed. At the same venue the write-off author field was populated on zero rows, ever — while the write-off reason field held staff members' first names, typed by hand, because people had turned a free-text box into the author field the interface never forced them to complete. A dashboard that attributes a write-off to a person using that column would be confidently naming the wrong thing.
So the sharpest question to ask before choosing either platform is not which system has a given field. It is which fields your operation will be forced to populate. Both platforms carry far more fields than any venue fills.
StoreHouse being deeper than iiko's built-in inventory is true, and it is the strongest single argument for R-Keeper. It is also the argument most likely to be irrelevant to a given venue, and there is a cheap way to find out which.
At one venue we compared 30 days of write-offs against 30 days of sales: 1.7 million tenge written off against 16.4 million tenge sold, close to 9.4 percent. Ninety-six percent of that was written off against no account and no person. Separately, inventory surplus exceeded inventory shortage by roughly four to one — a ratio that does not describe theft or spoilage. It describes counts that are not being performed.
What was maintained at that same venue was the accountant's chart of accounts. Non-returnable waste, staff meals, complimentary write-offs, hospitality and kitchen spoilage each had their own account with real figures behind them, because an accountant answers for those numbers every month. The reason codes the floor staff touched were noise; the ledger the accountant kept was clean.
The lesson generalises past both products. Deep inventory capability pays for itself where somebody is professionally accountable for the count. Where nobody is, the deeper module produces more empty fields rather than more control — and StoreHouse's setup cost and dealer dependency then buy nothing at all.
The open-API advantage in the table is real, but "open REST API" understates the situation in a way that matters when scoping an integration.
iiko exposes at least three distinct surfaces: a server API on the venue's own installation, a cloud API, and an OLAP reporting interface. They have different contracts, different authentication and genuinely different coverage. At one venue the server API listed 2,941 products, of which 429 were priced and in the menu, while the cloud nomenclature endpoint returned zero products for the same organisation — with a live terminal group correctly attached. That is a publication flag, not a sync failure, and neither endpoint's response says so.
The gaps are specific rather than general. Payment-type configuration is not readable through the API at all: the endpoint returns an identifier, a code, a name and a deleted flag, and six candidate detail endpoints return 404. The OLAP transaction view carries 121 fields and none of them describe guest loyalty balances, which live on a separate server entirely. One loyalty endpoint capitalises a response key that every neighbouring endpoint leaves lower-case, which is enough to make a correct integration read back as an empty result.
None of this makes iiko the worse choice — it remains materially easier to build against than a proprietary dealer framework. It does mean "we will integrate that later" should be costed against the specific endpoint you need, and verified with one live call, before it goes into a plan.
In Kazakhstan the integration checklist is short, and it is not the one a global comparison would produce.
Across 120 days at one venue, Kaspi accounted for 72.4 percent of revenue — roughly 22.3 million tenge across 4,864 orders — and about 91 percent of everything a guest paid directly. Delivery aggregators accounted for a further 20.4 percent, around 6.3 million tenge over the same period. Cash was 7.3 percent.
Two things follow. A POS that handles Kaspi awkwardly is not a minor inconvenience; it is friction on roughly three quarters of the revenue line. And the aggregator connection is not a growth experiment — at that venue it was already a fifth of turnover, and it is the part of the business that depends on an API rather than on a person at a terminal.
That is the honest form of the integration criterion. Neither platform fails it outright: both support Kaspi QR and both reach the major aggregators. The difference is what it costs to change something afterwards — a cloud admin panel, or a dealer ticket.
iiko uses a SaaS subscription model — monthly fee per terminal with all features included. There is no upfront server purchase, no annual license renewal complexity, and scaling means adding another terminal subscription. For a single-location cafe, iiko typically costs 30 to 50 thousand tenge per month per terminal. R-Keeper uses traditional software licensing with upfront purchase, annual support contracts, and dealer service fees for configuration changes. The initial investment for a single location can reach 500 thousand to 1.5 million tenge including hardware and setup. For large chains operating 20 or more locations over five or more years, R-Keeper's total cost per location can be lower than iiko's cumulative subscription fees.
That is the comparison every vendor conversation runs, and it is the wrong place to spend the negotiation. The write-off figure above — 9.4 percent of 30-day sales at one venue, 96 percent of it unattributed — is larger than the entire licence difference between the two platforms by an order of magnitude. It is also the figure no vendor's pricing page can move and only your own configuration can.
The useful sequence, then, is to decide what your operation will genuinely maintain, choose the platform that fits that, and negotiate last. Choosing on price first optimises the smallest line in the model.
Export a month of order-level data and check which columns are populated, rather than which reports exist. Three checks separate a configured venue from a nominal one: whether service type and order type carry a value on every order, whether write-offs name both an account and a person, and whether the last inventory count produced shortages and surpluses of comparable size. In the venues we have measured, the fields the business cannot trade without are near-perfect while the optional ones are empty — so the answer is usually specific to a handful of fields rather than a verdict on the whole system. That same check is the honest input to a migration decision, because it tells you whether the platform is the constraint or the configuration is.
iiko has an offline mode that allows the POS terminal to continue processing orders during short internet outages. Transactions are cached locally and synced to the cloud once connectivity is restored. However, some management features — real-time multi-branch dashboards, remote menu updates, and cloud-based reporting — require an active connection. For venues in areas with consistently unreliable internet, R-Keeper's fully on-premise architecture provides stronger operational continuity because the entire system runs on a local server by design.
Both iiko and R-Keeper support Kaspi QR integration, which is essential for any restaurant operating in Kazakhstan given the payment method's dominance among consumers. iiko offers a native Kaspi QR integration that is straightforward to configure through its cloud admin panel. R-Keeper integrates Kaspi QR through dealer-configured modules, which work reliably but may require additional setup fees. The functional outcome is similar — the difference is primarily in setup complexity and cost rather than end-user experience.
Migration from R-Keeper to iiko is operationally significant but technically manageable. The main challenges are historical data migration — sales records, inventory balances, and recipe databases — which typically requires manual mapping because the data structures differ fundamentally. Staff retraining is a real cost, though iiko's simpler interface shortens the transition. Most migrations take two to four weeks for a single location including parallel operation. The decision to migrate should be driven by concrete operational pain points with R-Keeper, not just a preference for a modern interface, because the transition cost is non-trivial.
iiko can be deployed at a single location within three to five business days, including menu setup, staff training, and Kaspi QR integration. The cloud architecture eliminates server installation. For a chain rollout, add one to two days per additional location. R-Keeper deployment typically takes two to four weeks for a single location because it involves server hardware installation, network configuration, and dealer-assisted software setup. Complex deployments with StoreHouse inventory and multi-branch hierarchies can extend to six to eight weeks. The deployment speed difference is one of iiko's strongest competitive advantages for new restaurant openings.
Choosing between iiko and R-Keeper is not a software decision — it is an operational architecture decision that affects your kitchen workflows, staff training, financial reporting, and ability to scale. opengate runs the reporting and inventory layer over iiko for restaurants and bars in Kazakhstan, which is where the measurements in this article come from. The cheapest useful step before any migration is a configuration audit: a read of what your current system is actually capturing, which fields are populated, and what your reporting could look like on the data you already hold. It frequently changes the answer. If you are opening a location, planning a chain expansion, or weighing a migration, reach out for a conversation.
Have a project in mind?
