One Inventory System, or Stock Managed Platform by Platform?

A brand selling on Rakuten Ichiba, Amazon Japan and Yahoo! Shopping out of one warehouse has one pool of stock and three storefronts that each believe they control it. There are two ways to live with that. Push a single number out to all three from a central system, or maintain each platform's stock field in its own console and manage the gap by hand.

Almost every article on this compares clicks saved. That is the least interesting variable. The three that decide it are how long your exposure window is, whether any tool you can operate actually connects to Rakuten, and which pricing axis your catalogue is heavy on. Take them in that order.

The Decision Is Not Automation Versus Manual. It Is How Long Your Window Is

Nothing here is real-time. Next Engine, one of the most widely deployed Japanese multi-mall systems, states in its own FAQ that inventory sync runs at five-minute intervals, with exceptions depending on the cart. That is fast, and it is not zero. Two platforms can both sell your last unit inside a five-minute window, and on a Sunday during Rakuten's Super Sale they can.

What centralization actually buys you is a bounded window instead of an open-ended one. The manual path's window is not five minutes; it is however long until a person next opens three consoles and reconciles them. Overnight, that is eight hours. Over a Japanese public holiday, it can be three days.

You can size your own exposure with arithmetic rather than a benchmark, and you should, because nobody else's number describes your catalogue. Take your peak hourly order rate for your fastest SKU across all platforms, multiply by the window length in hours, and that is roughly how many units can be sold against stock that no longer exists. This is arithmetic on your own numbers, not a measured industry figure — we are not going to quote you an overselling loss percentage, because any such number would be invented.

The variable that decides whether the answer is uncomfortable is peak, not average. Japanese marketplace demand is violently event-shaped: Rakuten's Super Sale and お買い物マラソン, Amazon's sale events, Yahoo!'s point campaigns. A catalogue that is perfectly safe with daily manual reconciliation for eleven months can oversell badly in one 48-hour window. Do the arithmetic on your worst historical day, not on a Tuesday.

Check Whether Your Existing Tool Reaches Japan At All — Most Do Not

Brands arriving in Japan usually already run something. The reasonable assumption is that you add Japanese channels to it. That assumption fails more often than it holds.

Shopify's own multichannel connector is the clearest case. Marketplace Connect supports Amazon, Target Plus (United States only), Walmart (United States only) and eBay. Rakuten Ichiba is not on the list. Yahoo! Shopping Japan is not on the list. If your Japanese plan involves a Shopify storefront plus the two largest Japanese malls, Shopify's first-party answer covers one of the three and stops.

The subtler trap is the word "Rakuten" in a Western vendor's channel list. Rakuten operates marketplaces in several countries, and a European integration is a different system from Rakuten Ichiba in Japan. Linnworks, for instance, publishes setup documentation for Rakuten France and Rakuten UK. We looked for a Rakuten Ichiba or Yahoo! Shopping Japan connector in its channel documentation and did not find one — but that page renders client-side and we could not read the complete list, so treat this as we could not confirm rather than as it does not exist.

The instruction that follows is dull and it will save you a procurement cycle: ask the vendor, in writing, whether the connector authenticates against a rakuten.co.jp merchant account through RMS, and against a Yahoo! Shopping store account. Make them answer with the domain, not the brand. If the answer is a sales call rather than a documentation link, you have your answer.

Rakuten Is the Constraint. Yahoo and Amazon Are Not

There is a structural reason the tool market splits along a national border here, and knowing it stops you searching for a product that does not exist.

Yahoo! Shopping publishes its store-operation APIs openly. The Yahoo! Developer Network documents an inventory reference API, an inventory update API and a bulk inventory upload API alongside order, product and category APIs, gated by Yahoo! ID linking, with a usage application required for some of them. Any competent vendor can read that documentation and build against it.

Rakuten works differently. Its public developer portal covers affiliate and search APIs — the ones used to build sites about Rakuten. Merchant-side RMS API access is handled through the RMS Service Square merchant portal, as a partner arrangement rather than open documentation. We tried to read Rakuten's own FAQ page on this and it returned a 403 to our request, so we are reporting the access shape rather than quoting it; verify inside RMS or with Rakuten directly before you build anything on top of it.

The consequence is the practical one: the population of tools that can reliably write stock into a Rakuten store is largely domestic, because those vendors are already inside that arrangement. That is not a quality judgement about Japanese software. It is a market-access fact, and it means your shortlist is going to be in Japanese.

What the Japanese Tools Actually Bill You For

The domestic vendors do not share a pricing shape, which is genuinely useful: the right one for you depends on whether your catalogue is deep or your order book is busy.

Next Engine bills on order volume. Its published pricing is ¥3,000 per month tax-excluded covering up to 200 orders, then tiered per-order fees above that: ¥35 for orders 201–400, ¥30 for 401–1,000, ¥25 for 1,001–3,000, and down to ¥5 beyond 10,000. A ¥15,000 annual maintenance fee applies from the second contract year, and paid apps are charged separately. Its published mall and cart list includes 楽天市場, Amazon.co.jp and Amazon Business, Yahoo!ショッピング, au PAY マーケット, Qoo10 and Shopify, with a note on some entries that automatic linking requires an app.

Running the published rates for a store at 800 orders per month: ¥3,000 base, plus 200 orders at ¥35 (¥7,000), plus 400 orders at ¥30 (¥12,000) — ¥22,000 per month tax-excluded, before apps and before the annual fee. That is our arithmetic on their published tiers, not a quote; confirm your own figure with the vendor.

TEMPOSTAR bills on three axes at once: a base fee (¥1,650 per month tax-included on Starter, from ¥11,000 on Standard), an item-count charge that scales from ¥2,200 at 1–2,000 items through ¥16,500 at 5,001–10,000 to ¥33,000 at 10,001–20,000 and ¥16,500 per additional 10,000 beyond that, and an order-count charge that is either variable (¥27.5 per order down to ¥5.5) or fixed (¥55,000 for up to 3,000 orders, rising in bands).

CROSS MALL goes the other way: a flat monthly fee with no per-order billing at all, prices quoted tax-excluded, with catalogues above 15,000 items routed to a sales conversation. Its published tier figures are rendered as images on the pricing page and we could not extract them mechanically, so the exact monthly numbers need to come from the vendor rather than from us.

The pattern worth carrying away: SKU count and order count are separate axes, and the vendors disagree about which one should drive your bill. A 40-SKU skincare brand shipping 3,000 orders a month and a 12,000-SKU parts distributor shipping 300 will find opposite vendors cheap. Work out which axis you are heavy on before you read a single feature comparison, because it eliminates half the shortlist immediately.

The Cost That Never Appears in the Comparison: the Console Is in Japanese

These products are built for Japanese operators. Next Engine's product pages are Japanese-only, with no English-language support stated, and we found no English admin UI stated among the vendors covered here. That is unsurprising rather than an oversight — the customer base these tools were built for does not need one.

For a foreign brand that is not a cosmetic problem, because it changes who the decision belongs to. A centralized inventory system is not a tool your home-market operations team can drive. Somebody who reads Japanese has to own it — configure the mall connections, interpret the sync error queue, and be the one who notices when a Rakuten connection silently stops updating. That is a staffing or vendor commitment attached to the software, and it is usually larger than the licence fee.

This is the honest reason many overseas brands stay platform-native far longer than a Japanese seller of the same size would. Not because the arithmetic favours it — often it does not — but because nobody in the building can operate the alternative, and buying software that only one contractor can drive creates a dependency of its own.

What Platform-Native Actually Costs, Day to Day

The manual path is usually described as labour: three consoles, three stock fields, someone updating them. The labour is real but it is not the expensive part.

The expensive part is buffer. When one physical pool serves three storefronts and nothing is syncing, the only safe way to avoid overselling is to allocate: Rakuten may sell 30 units, Amazon 30, Yahoo 20, and 20 sit unallocated as a safety margin. Every one of those partitions is stock you own, have paid for, and are deliberately refusing to sell on the channel where demand actually turned up. On a fast SKU during an event, the buffer costs more than any licence fee in this article.

So the real comparison is not "clicks saved versus yen spent". It is the cost of the buffer you are holding versus the cost of the system that would let you release it. Brands with a handful of SKUs and steady demand hold a cheap buffer and should stay manual for a long time. Brands whose bestsellers go out of stock during events are paying for centralization already; they just are not paying it to a vendor.

One complication to price in before you conclude: if your Japanese stock is already split — some units in FBA, some at a 3PL — then you have two physical sources, not one, and any centralization has to reconcile both. That interacts directly with the fulfilment decision we covered in FBA versus a Japanese 3PL, and it is worth settling the warehouse question first, because it changes what "one inventory system" even has to mean.

Where "Our Agency Handles It" Fits

A third option gets offered constantly and deserves to be named accurately: your Japanese partner maintains the stock numbers by hand.

That is not a third path. It is the platform-native path with someone else's hands on it. The lag window does not disappear; it moves to their working hours and their response time. That can be an excellent trade — a Japanese team watching three consoles during an event beats your team watching none — but only if the terms are explicit. Ask what update latency is promised in writing, who absorbs the cost of an oversell, and whether any tool in the arrangement is licensed to you or to them. The last one decides what you can take with you when the relationship ends.

Note also that this is a different question from how you structure your agency relationships in the first place. Whether to appoint one partner across all platforms or specialists per platform is an organisational decision we work through in one agency across all marketplaces or platform specialists. This article is about the system that holds the numbers, and the two decisions can be made independently — a single agency can operate a tool you own, and three specialists can each work inside one.

Our own position is narrow and worth stating so you can discount it correctly. We run Japanese marketplace operations for overseas brands — listings and Japanese copy, order and customer handling, campaign calendars, the day-to-day platform work. Where a brand already runs a centralized system we work inside it. We do not build, resell or take commission on inventory software, and we will not recommend a specific tool against a catalogue we have not seen.

How to Decide, in Order

1. Settle where the stock physically sits first. One warehouse or split across FBA and a 3PL. The answer changes what any system has to reconcile, and deciding the tool before the warehouse means deciding twice.
2. Measure your window, not your average. Peak hourly order rate for your fastest SKU × hours between manual reconciliations = units at risk. Run it against your worst historical event day.
3. Price the buffer you are currently holding. Units allocated per channel and never released are the real cost of staying manual. If that number exceeds the licence fees below, the arithmetic already favours a system.
4. Verify Japanese coverage in writing before shortlisting. Rakuten Ichiba on rakuten.co.jp through RMS, and Yahoo! Shopping store accounts, named as domains. Do not accept "Rakuten" unqualified.
5. Identify your heavy axis before comparing features. Order-volume-heavy and SKU-count-heavy catalogues have different cheap vendors, and knowing which you are removes most of the shortlist without a demo.
6. Name the person who will operate it in Japanese. If you cannot, you are not choosing between two tools; you are choosing between platform-native and hiring. That is a fair decision to make, but make it deliberately.

The version of this decision that goes wrong is the one made from the feature list. Centralization is not automatically the mature choice, and platform-native is not automatically the amateur one — a 30-SKU brand with steady demand and a Japanese-reading partner can run manual for years without losing a yen, while a brand with event spikes and a shared pool is paying for centralization in stockouts whether or not it ever signs a contract.

If you want this checked against your actual catalogue — SKU count, order volume, platform mix, where the stock sits — tell us what you sell and which storefronts are live. Scope and pricing are quoted against the work rather than from a rate card.