A European or American brand decides to enter APAC. The first wave of stores usually looks like this: three in Hong Kong, two in Singapore, two in Kuala Lumpur, one in Tokyo, Jakarta still under review.
Five markets, eight stores. Whether to extend the retail system headquarters has run for the past decade is raised at the kick-off meeting, and raised again repeatedly over the following six months.
Both answers hold up. Both have people arguing against them.
APAC is not one market. It is a dozen small ones.
When these brands expand across North America and Europe, system selection rests on one assumption: the market is large enough that whichever vendor is chosen, mature products, a mature ecosystem and mature local delivery capacity are all available. That assumption does not hold in APAC.
Hong Kong, Singapore, Malaysia, Indonesia, Japan — each has its own tax regime, its own payment ecosystem, its own language and receipt rules. In any one of them the brand may have two or three stores. The combined store count is not small, but no single country constitutes a market worth a dedicated investment.
That produces a squeeze: project complexity scales with the number of countries, while the store base it can be amortized over is counted per country.
Neither vendor category is built for this. One is the global system vendor headquarters already runs, whose product and delivery model are built for large markets and large networks. The other is the local software house in each country, whose product is built for its own market.
Tier-one global vendors: a delivery model built for 200 home-market stores, applied to eight
Extending the headquarters system is most brands’ first option. It is the cleanest on paper: one set of definitions, consolidated reporting without reconciliation, a vendor headquarters IT already knows, no new supplier to manage. Hesitation usually starts when the quote and the schedule arrive.
The problem is not the vendor’s product. It is how the vendor is organized.
First, the minimum project size is set by the vendor’s cost of delivery, not by store count. Bringing up a new country means running the global template fit-gap, the solution review, the master-data boundary sign-off and the global change process. The same brand runs that process to open 200 stores in Europe and to open two in Malaysia; the steps are identical. Professional services are priced per man-day, and man-days are driven by process steps and country count, not by terminal count. The amount the APAC stores have to absorb therefore differs little from the home market.
Second, localization for a new market has to enter the global product roadmap, and roadmap priority follows market revenue. Whether local acquiring, electronic invoicing and receipt formats make it into the standard product depends on what that market is worth to the vendor overall. A customer with ten stores in Malaysia does not get to the front of the queue. What does not make the standard product is quoted as custom development — which also means the next regulatory change will be quoted again.
Third, the change windows do not line up. Local regulators typically give companies months to prepare; global release cycles run in half-years. A single receipt-field change has to enter a global release window, and the gap between the two rhythms is carried by the brand on a workaround.
Fourth, support hours are misaligned. Store peak falls in the Asian evening; first-line support answers during European or North American business hours, one shift away. A payment failure happens when the store is busiest, and the ticket is picked up the following day. In most contracts this appears as an optional extended support window, priced separately.
Fifth, upgrades make the localization spend happen again. Every major version upgrade requires regression testing of local payment, tax, receipt and language behavior. Doing it once does not mean it stops.
Taken together, these are why most brands abandon this route. The vendor’s product capability is not in question; the delivery model and eight stores are not in the same order of magnitude.
Local vendors: the model stops working at the border
The other route is to source a local vendor in each country: lower quotes, faster schedules, fluent in local rules. The first year usually goes well. The problems appear in year two, and in the third country.
These markets are small, so no large retail software company exists in them. The firms able to take the project on are typically teams of a few dozen people, operating in one country, serving mostly domestic customers.
Interfaces break first. Vendors of this size have rarely integrated with a European or American headquarters ERP, CRM or BI. Interface documentation, field naming and working language often exist only in the local language. Headquarters IT has to get a proposal translated before reviewing it, and nobody is accountable for whether the translated field definitions are accurate. Interface authority therefore falls back to headquarters, which does not hold the local transaction detail.
With no one holding that authority, definitions diverge. Five markets, five POS systems: product classifications differ, membership fields differ, promotions are booked differently, discounts land on the line in one country and on the ticket in another. The five data sets headquarters receives cannot be added together; each consolidation requires a round of manual alignment. By the time the brand wants cross-market customer identification or cross-market product performance analysis, the data has no comparable basis.
Accountability fragments the same way. Five countries, five vendors, five contracts, five legal entities. When a store hits a problem, the payment provider points at the POS, the POS points at the interface, and headquarters IT coordinates across time zones. This cost appears in no quote, and it recurs every month.
By that point switching is no longer cheap. Replacing one country’s vendor means redoing the project in that country, with history, membership and interfaces to migrate.
There is a more fundamental layer. These companies follow local regulation and local customers in their product direction. The capabilities headquarters actually cares about — comparable operating data across markets, a single membership asset, consistent promotion definitions — are not on their roadmaps, and should not be. They have done nothing wrong. Their product is simply not built for a multi-country brand’s headquarters.
The real spend is not the software license. It is payments, tax and exception handling.
One group of costs occurs on either route, and it usually takes a single line on the quote.
Payments. A line reading “supports local payments” states nothing about actual scope. What needs confirming is the full path: the POS issues the payment request, receives success, failure and timeout as three distinct outcomes, and records the channel reference; voids and refunds link back to the original transaction; after day-end close, POS transactions, channel records and bank settlement can be reconciled against each other. Beyond that: test accounts, terminal integration, certification, recovery after a network drop, and duplicate-charge protection.
This work occurs per channel, not per country. Hong Kong alone has three mainstream channels in concurrent use, with different void flows, different cut-off times and different reconciliation file formats; integrating three is three times the work of integrating one. Where the global system already has a connector for a given provider, it still needs checking item by item — connector coverage varies by market and by version.
Tax. Also more than entering a rate. What has to be settled: which products take which tax classification, whether prices are tax-inclusive, how discounts are apportioned, whether rounding happens at line or ticket level, how a return reverses the original tax, and what the receipt must display. Where the market has electronic invoicing or mandatory reporting, add document generation, status write-back, retry on failure, and linkage to the original document.
Malaysia’s electronic invoices are received and validated by the Inland Revenue Board through the MyInvois platform. Japan’s consumption tax runs two rates, 8% and 10%, with defined requirements for what the invoice must record. Singapore has GST, and the InvoiceNow electronic invoicing network is being phased in. These requirements land inside transaction detail, return flows and reconciliation definitions; a toggle on a configuration page is nowhere near sufficient. The rules also keep moving, and a system with thresholds and dates written into code will incur the cost again within two or three years.
Language, testing, training and local support form a third group, and the effort is incurred per market as well: translating and display-checking the interface, prompts, receipts and training material; testing payment timeouts, interface failures and offline recovery; local-language training material and cover for the first store opening; and a response arrangement for local trading hours after go-live.
Most of this occurs per country, not per store. Eight stores and eighty stores require much the same investment, which is why the per-store share is at its highest during the first wave of openings. A full breakdown of these costs and how to split the budget is covered separately in what localization actually costs in a small APAC market.
A third option: headquarters keeps the data standard, a regional system runs the transactions
The third approach is to redraw the system boundary rather than choose between one global system and one system per country.
On the store side, a regional system covering several APAC markets handles sales, payment results, refunds, tax fields, receipts and customer identification. Headquarters ERP, CRM and BI keep the data standard and the consolidation definitions, receiving what the business needs through an interface.
This preserves the three things headquarters genuinely needs — comparable data across markets, one set of membership definitions, a single accountable party — while avoiding deep localization of the global system for a market with eight stores. Interfaces and reconciliation still have to be built, but the nature of the work changes: the interface is defined once, rather than the whole process being repeated in every country.
This only works if the regional system is genuinely running real stores in several markets. The check is direct: ask which markets, and whether the stores are trading or still being built.
Where PEKON operates in APAC, and where the boundary sits
PEKON provides the PEKON Smart Retail System for brand retailers. Its overseas headquarters is in Hong Kong, under PEKON INNOVATION TECHNOLOGY LIMITED, serving customers outside mainland China.
Against the two questions above: stores are trading in Hong Kong, Singapore, Japan and Indonesia, and the Malaysia project is in progress.
Hong Kong runs three payment channels concurrently — BOCHK, Allinpay and KPay. Voids, refund linkage, day-end reconciliation and network-drop recovery have each been built three times over. Brands in service there span skincare and fragrance, trendy toys and luxury leather goods. A traditional Chinese interface is in use.
In Malaysia, store POS connects to MyInvois through EZInvois, a local electronic invoicing service provider, and the integration path is proven.
Implementation and local support across these markets are delivered by PEKON teams together with local partners, with the split set per market and per project.
The back office is standardized in English, so that headquarters and regional IT can read it and take it over directly rather than relying on a local team to relay.
The boundary: the scope covered is store-side transaction execution and membership, plus the interface to the systems headquarters already runs. ERP, CRM and BI that belong at headquarters should stay there. Which capabilities are standard, which are configuration, and which require integration or custom development is confirmed item by item against the target country and project scope.
Eight questions that separate vendors
For global system vendors:
- For this country, are payments and tax inside the standard product, or quoted as custom development?
- When local regulation changes, where does the update come from, how long does it take, and how is it charged?
- After a major version upgrade, who runs regression testing on the localized behavior, and whose budget carries it?
- Is first-line support during local trading hours standard scope, or priced separately?
For local or regional vendors:
- Which markets have real stores trading today? Trading, or still being built?
- Has there been integration with a headquarters ERP, CRM or BI? In what language is the interface documentation?
- Across several markets, how are product, membership and promotion definitions kept comparable?
- Who is the single accountable party when something fails, and which entity holds the contract?
Questions 5 and 8 separate vendors most sharply: one distinguishes having done it from being able to do it, the other distinguishes one vendor from a set of vendors.
FAQ
With only a handful of stores in the first APAC wave, does the system really need deciding now?
Yes. Payments, tax, receipts and interfaces occur per country and are needed the day the first store trades; they cannot be retrofitted. Deciding while the store count is low is when changes cost least.
Headquarters already runs a global retail system. Is extending it not the simplest path?
It depends on two things: whether localization for that country sits inside the vendor’s standard product, and where updates come from when regulation changes. If both answers are “quoted per project”, what is saved is process, not cost.
A local vendor per country really is cheaper in year one. Where is the catch?
In the third country. Definitions that cannot be compared, interfaces nobody has built before, and no single accountable party do not appear in the first-year quote. They appear in the staff cost and the decision lead time of every year after.
With a regional system alongside the global system, will the two data sets diverge?
That depends on when the interface is defined. Settling data definitions, field mapping and reconciliation rules early in the project is one-off work. Adding them after go-live turns into permanent manual alignment.
For compliance requirements like electronic invoicing, what matters on the system side?
The rules keep changing, so thresholds, dates and fields should not be written into code. Only the tax authority’s current guidance counts, confirmed once more by a local tax adviser, and the system has to be able to follow it through configuration.
Closing
What makes APAC difficult for European and American brands is not that any one country is unusually complex. It is that every country has to be done separately, and no country has enough stores to absorb the effort.
Tier-one global vendors deliver in a way designed for a mature home network, which is too heavy for eight stores. Local vendors build for a single country, and five of them together leave headquarters without usable data. Confirm those two points first, then decide how far down global standardization needs to reach.
Brands planning a first wave of APAC stores, or reviewing an existing overseas retail system, can start by splitting the budget by target country, store count, payment channels, tax requirements and headquarters interface scope, then check the system boundary with a PEKON consultant.
Local service providers and implementation partners are equally welcome to get in touch. Every market in APAC needs people who know the local rules and can respond during local trading hours, and that is not something one party does alone.