A marketplace integration guide for wholesalers should start with the point at which most operational pressure becomes visible: the order desk. When Amazon, eBay or another marketplace order has to be copied into an ERP system, checked against stock, released to the warehouse and later reconciled for finance, a growing sales channel can quickly create more work than value.
The objective is not simply to connect two systems. It is to create a dependable flow of commercial and operational information between marketplace, ERP, warehouse and courier processes. That means deciding which system owns each piece of data, what should happen when an exception occurs, and how staff can see what has happened without chasing spreadsheets.
Start with the operational process, not the connector
A marketplace may offer an API, and an ERP may have integration options, but that does not make every connection straightforward. The real questions concern process. Which orders should enter the ERP automatically? Are trade and consumer orders treated differently? Does stock availability come from the ERP, a warehouse management system or a calculated allocation rule? Who resolves an address failure or an item that cannot be supplied?
Map the journey of a typical order before selecting technology. Include the marketplace order, customer record, delivery address, payment and tax information, stock allocation, pick release, despatch, courier label, tracking update, invoice and credit process. This quickly exposes the manual interventions that a basic order import might leave behind.
For example, a wholesaler using Sage 200 may receive marketplace orders for items also sold through a trade portal and sales team. If all available stock is published to every channel without considering committed quantities or safety stock, the marketplace can sell stock that has already been promised to an account customer. The integration design needs a clear availability calculation, rather than a simple stock field synchronisation.
Define the system of record for every data type
Duplicate records and contradictory updates are common where systems are connected without ownership rules. A practical marketplace integration gives each key data type a primary source.
In many wholesale operations, the ERP remains the source of truth for products, cost and selling prices, tax treatment, customer accounts, stock and invoices. The marketplace supplies orders, marketplace-specific statuses and, in some cases, customer contact details. A warehouse system may be the authority for pick, pack and despatch activity, while a courier platform provides tracking events.
That model will vary. Marketplace listings may need titles, images, category attributes and promotional prices that are managed outside the ERP. Some businesses deliberately maintain a separate product information process for this reason. What matters is that updates do not travel in both directions without controls. If a price is changed in the marketplace but overwritten by an overnight ERP export, the business needs to know whether that is expected behaviour or a costly mistake.
It is equally useful to agree how customer records will work. Marketplace buyers do not always need to become full credit-account customers in the ERP. Creating a new account for every consumer order can make customer data difficult to manage. Depending on the finance and fulfilment requirements, it may be better to use a controlled cash-sale account while retaining the necessary order and delivery details.
Build a marketplace integration around real order states
Orders are rarely just new or despatched. They may be pending payment, awaiting stock, on hold for an address check, partly allocated, backordered, cancelled, returned or refunded. A useful integration must translate those states in a way that reflects how the business actually works.
Consider an order received through eBay. The integration can validate the SKU, create the sales order in SAP Business One or Sage 200, and pass it into the normal allocation and fulfilment process. Once the warehouse confirms despatch, the courier tracking number and service should be returned to the marketplace where its API supports this. The customer then receives accurate despatch information without someone updating multiple screens.
However, automatic processing should not mean automatic acceptance of bad data. Build clear exception routes for unknown SKUs, invalid postcodes, pricing discrepancies, missing delivery services and orders containing restricted goods. Staff should have a manageable queue of exceptions, with enough context to resolve the problem, rather than receiving a vague integration failure email after the cut-off time.
Test partial fulfilment and cancellations early
Partial fulfilment is one of the areas most likely to reveal gaps in an integration design. A marketplace may permit one order to be shipped in several consignments, while the ERP has its own rules for split deliveries, invoicing and backorders. If the warehouse despatches only part of an order, the integration must not report the whole order as complete by mistake.
Cancellations need the same care. A cancellation before pick release should normally stop the order progressing. A cancellation after despatch becomes a returns or refund process and may require different financial treatment. Agree these rules with operations and finance before implementation, not after the first dispute or marketplace performance issue.
Treat stock synchronisation as a commercial control
Stock updates are often described as real-time, but the right frequency depends on order volume, sales velocity and the systems involved. For fast-moving products sold across several channels, frequent updates may be necessary. For a lower-volume catalogue, scheduled updates may be appropriate and easier to monitor. The critical point is to understand the risk during the gap between changes.
A sensible stock feed normally accounts for physical stock, allocated stock, stock on sales orders, quarantine or damaged stock, replenishment rules and an agreed buffer. It may also need to exclude products that are not suitable for marketplace sale, such as made-to-order items, contract-only lines or products with incomplete listing data.
Price and product changes need similar discipline. If a product is discontinued in the ERP, should its marketplace listing be ended immediately? If a promotional price applies only to a specific customer group, it should not automatically be published to a public channel. These are commercial decisions implemented through integration rules, not merely technical fields.
Connect fulfilment and courier updates without losing visibility
The warehouse should not need to rekey order information into a carrier portal if the required data already exists in the order flow. Courier integration can create consignments, return labels or service selections and feed tracking details back to the ERP and marketplace. It also reduces the chance that a label is created for an incorrect address or delivery service.
There are trade-offs. Courier data may need cleansing where marketplaces combine address lines inconsistently, and not every carrier service or marketplace status maps neatly to another system. Build validation for weight, postcode, country, service code and dangerous goods requirements where relevant. Retain a visible audit trail so that customer service staff can confirm what was sent, when it was despatched and which tracking reference applies.
For businesses using a third-party warehouse, the same principle applies. Establish whether the warehouse receives order data directly, through the ERP or through a warehouse management system. Sending the same order through two routes creates duplicate picks. Sending it through neither route creates a costly manual workaround.
Plan for finance, reconciliation and support
An order integration is incomplete if finance still spends days reconciling marketplace settlements manually. Marketplace fees, refunds, VAT treatment, shipping charges and payment dates can differ from the sales order value. The appropriate accounting process depends on the ERP configuration and the information available from the marketplace, but it should be designed with the finance team from the outset.
Ask what evidence is needed to match marketplace payouts to orders, fees and refunds. Determine whether invoices are raised at order, despatch or settlement stage. Review how credit notes are created and how stock returns are reflected. A process that looks efficient to the warehouse can still create a month-end problem if these decisions are ignored.
Support also deserves proper planning. Integrations require monitoring, alerting and ownership. Someone needs to know when order volumes drop unexpectedly, a marketplace token expires, or a stock export fails. Good support arrangements distinguish between a system outage, a data issue and a process question, so the right team can act quickly.
A practical implementation approach
Start with a focused scope: one marketplace, an agreed product range and a clearly documented order-to-despatch process. Test normal orders alongside edge cases such as discounts, split shipments, cancellations, zero-stock products and refunds. Reconcile the results against the ERP, marketplace and courier records before expanding the scope.
Harmonise Solutions can help businesses assess these processes, design the data flows and implement automation using integration technology such as Codeless Platforms BPA Platform where appropriate. The aim is not to force operations into a generic template, but to make existing controls work reliably across the systems the business already depends on.
If marketplace orders are creating manual work, start by tracing one order from checkout to settlement. The points where people rekey, check, email or reconcile information are usually the clearest place to begin improving the process.