VTEX, ERP and marketplaces: which flows to integrate to run catalogue, stock and orders without friction

VTEX solves the commerce layer very well: catalogue, checkout, shopping experience and connection with several marketplaces. What VTEX does not solve on its own is how that data syncs with the ERP that manages costs, real stock and invoicing, or how the operation is coordinated when, on top of the own store, you sell in two or three different marketplaces.

This article reviews which flows are worth integrating between VTEX, the ERP and the marketplaces so that catalogue, stock and orders are handled from a centralised operation, instead of multiplying the work for every channel.

Quick summary

• Every marketplace you add does not add one integration: it adds one integration per flow (catalogue, stock, pricing, orders, returns).
• Overselling between channels is avoided with a single stock authority, not with safety margins per channel.
• Format translation, categories, attributes, units, has to live in the integration layer, not inside VTEX or the ERP.
• A marketplace order has to reach the ERP with the same structure as one from the own store. Otherwise the operation forks.

Why adding marketplaces multiplies complexity

Every marketplace has its own catalogue format, its own stock rules, its sync timings, its return policies and its commission scheme. If VTEX connects with the ERP on one side and each marketplace is integrated separately, the company ends up maintaining as many integrations as it has channels, each with its own logic and its own set of errors.

The cost does not grow linearly with the number of channels, but with the number of channels multiplied by the number of flows. Adding a third marketplace does not mean one more piece of work: it means catalogue, stock, pricing, orders and returns, five new flows to maintain and monitor.

Which flows are worth integrating

Flow	Source of truth	Destination	Critical consideration
Catalogue	ERP or PIM	VTEX and marketplaces	Translation of categories and attributes per channel
Stock	ERP or WMS	VTEX and marketplaces	Single authority to avoid double commitment
Pricing	ERP	VTEX and marketplaces	Adjustment for each channel’s commission and policy
Orders	Originating channel	ERP	Normalised data structure
Fulfilment	OMS or central rules	WMS, branches	Same rules for every channel
Returns	Originating channel	ERP and stock	Marketplace policy vs. own policy
Reconciliation	Marketplace	ERP	Commissions, withholdings and settlements

The last flow, reconciliation, is the most underestimated. Every marketplace settles on its own calendar, deducts commissions on its own criteria and applies different withholdings. Without integration, that reconciliation ends up being manual finance work that grows with every channel.

Risks of integrating each marketplace separately

• Overselling when two channels commit the same stock almost simultaneously, with no central layer to arbitrate.
• Different pricing and commission rules in each integration, hard to audit when a margin does not add up.
• Uneven sync timings between marketplaces, which generates temporary availability inconsistencies.
• Growing maintenance cost every time a marketplace changes its API or its publishing rules.
• Impossible diagnosis. When an order does not arrive, you have to check the channel, the specific integration and the ERP, with no common view.

How to resolve stock between the own store and the marketplaces

This is the point that decides whether the operation scales. There are three approaches and only one works well in the medium term:

Fixed allocation per channel. A share of the stock is assigned to each channel. It is simple, it avoids overselling and it wastes inventory: a product can be sold out in one channel while there are units reserved and unsold in another.

Full publication with a safety margin. Every channel sees the full stock minus a buffer. It uses inventory better but does not eliminate overselling; it only makes it less frequent, and it still holds back unsold units.

Single stock authority with real-time reservation. Every channel queries and commits against the same source. When a sale is confirmed in any channel, the unit is immediately reserved for all the others. It is the only approach that allows publishing the full inventory without overselling, and it requires an integration layer capable of responding with low latency.

The choice between these approaches is not technical: it is a decision about how much inventory the operation is willing to immobilise. It is the same problem solved by a centralised architecture between POS, ecommerce and ERP, extended to third-party channels.

A common integration layer for VTEX and the marketplaces

The most scalable approach is for VTEX, the ERP and each marketplace not to connect directly with each other, but through a common layer that centralises stock, pricing and order rules.

Specifically, that layer takes care of:

1. Normalising the order from any origin into a single structure before sending it to the ERP.
2. Translating the catalogue into each channel’s format: proprietary categories, mandatory attributes, image requirements, character limits.
3. Arbitrating stock with a single authority and immediate reservation.
4. Applying per-channel pricing rules, including commissions and adjustments.
5. Recording and monitoring every transaction, with retries when marketplace APIs fail, which happens often.

That way, adding a new marketplace means configuring an additional channel on top of an existing foundation, not building five new integrations from scratch. That principle is the same one behind a composable VTEX and ERP architecture in LATAM retail.

Frequently asked questions

Doesn’t VTEX already include a connection with marketplaces? VTEX offers native connectors with several marketplaces, which handle publishing and order intake well. What still has to be solved is the relationship with the ERP: how the order reaches accounting, how the warehouse’s real stock is synced and how commissions and settlements are reconciled.

Who should be the source of truth for the catalogue, VTEX or the ERP? The ERP or a PIM should be, for product master data and prices. VTEX is one more sales channel, even if it is the main one. When VTEX is used as the catalogue’s source of truth, adding a marketplace forces you to extract data from a commerce platform, which is not designed for that role.

How do you avoid overselling in high-demand campaigns? With stock reservation at the moment the sale is confirmed, not when it is prepared, and with a single inventory authority. Safety margins per channel reduce the frequency of the problem but do not eliminate it, and they cost sales.

Should marketplace returns be handled differently? The internal process should be the same: same unique identifier, same stock re-entry, same credit note. What changes are the deadlines and conditions each marketplace imposes, and that is solved with rules in the integration layer, not with a parallel process.

How long does it take to add a new marketplace with this architecture? The work concentrates on mapping the new channel’s taxonomy and mandatory attributes. The stock, order and return flows already exist and are reused, which is exactly why the common layer is worth it.

Checklist to integrate VTEX with ERP and marketplaces

• Is stock managed from a single source of truth for every channel?
• Does inventory reservation happen at the moment the sale is confirmed?
• Is the catalogue translated automatically into each marketplace’s format?
• Does an order from any marketplace reach the ERP with the same data structure?
• Are each marketplace’s commissions and settlements reconciled automatically?
• Do marketplace returns follow the same process as the own store’s?
• Does adding a new marketplace reuse the existing integration with the ERP?

You may also be interested in reading:

• “Omnichannel returns: how to integrate physical store, ecommerce and ERP to close the loop without errors” Weavee centralises VTEX integration with your ERP and marketplaces, with a single stock authority and normalised orders, so adding a sales channel is a configuration and not a project.