ERP for Overseas Warehouses: A Chinese E-Commerce Playbook

The short answer

An overseas warehouse exists to shorten delivery time and make local returns practical. It succeeds at both and creates a new problem in exchange: your inventory is now scattered across jurisdictions, your sales data lives in marketplaces you do not control, and the cost of a unit is no longer a single number you can look up.

The ERP requirement is therefore narrower than a full manufacturing implementation and more demanding than an accounting package. What it has to do is hold inventory accurately by location, absorb sales and fee data from marketplace systems, compute landed cost including freight and duty, and produce a per-unit profitability figure that survives contact with reality.

• One or two overseas warehouses: a focused inventory and landed-cost system is enough.
• Multiple countries with marketplace fulfilment alongside own warehouses: location-level inventory plus settlement reconciliation become mandatory.
• Own-brand manufacturing sourced in China: add production and transfer pricing to the above.
• Any configuration fails if landed cost is not computed in the system rather than estimated in a spreadsheet.

Why warehouse inventory breaks Chinese sellers' bookkeeping

A seller who ships from China has a simple inventory story: goods leave a Chinese warehouse, revenue arrives through an export transaction, and the accounting follows the customs and tax documentation. Add an overseas warehouse and that story fragments. Goods are transferred rather than sold, which raises a transfer-pricing question. They sit in a foreign jurisdiction, which raises a stock-and-valuation question. They are sold by a marketplace that deducts fees, holds funds, and reports on its own schedule, which raises a reconciliation question.

The failure pattern is consistent: inventory in the ERP reflects what was shipped from China, marketplace reports reflect what was sold locally, and the two drift because nobody is reconciling them at unit level. By the time the difference is noticed, it is large and its cause is historical.

The fix is structural rather than procedural. Inventory has to be tracked by location and by status — in transit, in warehouse, in marketplace fulfilment, reserved, returned, unsellable — and the system has to move stock between those states through events rather than through manual adjustments. Marketplace settlement data has to be imported on a defined cadence and matched against the inventory movements it implies. Our overview of the multi-platform inventory problem covers the same ground from the marketplace-integration side.

Landed cost is the number that matters

The single most valuable output of a cross-border ERP is a trustworthy landed cost per unit per location. Without it, pricing decisions are made on intuition and profitability analysis is fiction, because the same product can cost materially different amounts to sell in different markets depending on freight rates, duty treatment, last-mile costs, and returns.

Computing it properly means capturing freight and insurance, duty and import charges, the cost of moving stock between warehouses, and the cost of returns. It also means allocating those costs across units in a defensible way — by weight, by volume, or by value, consistently — and it means recalculating when rates change rather than freezing an estimate at the start of the season.

• Freight and insurance per shipment, allocated to units on a stated basis.
• Duty and import charges, which differ by jurisdiction and by product classification.
• Inter-warehouse transfers, which move cost as well as stock.
• Returns handling, which frequently costs more than the original margin.
• Marketplace fees, which vary by category and by programme.

A group that subtracts marketplace fees from revenue without allocating them to units does not know which products are profitable. That is the most common and most expensive blind spot in cross-border e-commerce, and it is a system design question rather than an accounting one.

Marketplace settlement reconciliation

Marketplace settlements are not invoices. They are periodic statements containing sales, refunds, fees, advertising, storage charges, and adjustments, arriving on the marketplace's schedule rather than yours. Reconciling them against your own records is the activity that determines whether your revenue figure is real.

Doing it manually is possible for a small number of stores. Beyond that it becomes a full-time role and an error-prone one, because the differences are individually small and collectively significant. The system requirement is an import of settlement data at a defined frequency, automatic matching against orders and inventory movements, and a variance report that isolates what did not match so a human can investigate only the exceptions.

The variance report is the part that matters. Systems that import settlement data but provide no matching mechanism merely move the manual work, they do not remove it.

Multi-currency and tax treatment

An overseas warehouse operation touches at least two currencies and often three: purchasing in renminbi, holding cost in the warehouse's local currency, and receiving settlement in the marketplace's currency of account. Exchange differences therefore arise on inventory and on receivables, and they have to be treated consistently or the margin analysis becomes unreliable.

There is also a tax-structure question. Selling locally from a local warehouse can create a local tax presence in ways that selling cross-border from China may not, and the treatment differs by jurisdiction and by whether an entity or a third-party logistics provider holds the stock. That is a question for a tax adviser rather than for the ERP vendor, but the answer determines what the ERP has to model — a stock transfer between group entities, a consignment arrangement, or a local sale. Getting the structure clear first avoids configuring the wrong one. Our guide to moving from a China-only accounting system into cross-border operations covers the systems transition this often accompanies.

What to look for in a system

• Inventory by location and by status, with movements recorded as events rather than adjustments.
• Landed cost computed in the system, with a stated allocation basis and recalculation on rate changes.
• Marketplace settlement import with automatic matching and an exceptions report.
• Multi-currency with transaction-level rates and consistent treatment of exchange differences.
• Transfer pricing support for inter-entity stock movements.
• Reporting that shows profitability per product per market, not just per marketplace.

Notice that none of these is exotic. The reason cross-border sellers struggle is not that the requirements are advanced; it is that they are frequently met through a patchwork of spreadsheets and marketplace dashboards that no one reconciles.

Where overseas warehouse setups break

• Inventory is tracked only in aggregate, so location-level differences accumulate unseen.
• Landed cost is an estimate fixed at the beginning of a season.
• Marketplace fees are netted against revenue without allocation to units.
• Settlement data is downloaded but not matched against orders.
• Returns are absorbed as a cost of doing business rather than recorded against products and markets.
• Exchange differences are posted to a general line rather than to the inventory and receivables that produced them.

Verdict

An overseas warehouse is a logistics decision that creates an accounting requirement. The groups that benefit most are the ones that treat landed cost and settlement reconciliation as system functions rather than as analysis performed afterwards, because those two outputs determine whether the operation is genuinely more profitable than shipping from China — or merely faster. For the wider trade-compliance context, see our guide to ERP and customs declaration integration.