Selling through a marketplace adds another source of orders. If staff must open the marketplace dashboard, copy the sale into the store and enter it again in the ERP, the main workload is still there. The order has arrived, but someone must manually move it through the operation.
A useful integration follows the order from identification through processing and later updates. That means deciding which data should move, who is allowed to change it and how to spot an unfinished step. The aim is to let people handle exceptions instead of reconstructing every sale by hand.
Map the journey the order needs to take
Before choosing software, describe how your business actually works. Where does the sale first appear? Which system does the warehouse team use? Who controls available inventory? Where does the information for invoicing come from? Which system records dispatch?
Different answers lead to different designs. An ERP might own inventory and invoicing, while another business uses its e-commerce platform to manage stock and passes data downstream. Either arrangement needs an explicit owner for each type of information.
Include events outside the happy path. An order may be cancelled, its payment state may change later or an item may have no match in the internal catalog. Leaving these cases out of the plan produces an integration that only works for the easiest sale.
Identify orders and products without relying on their names
The marketplace order number and the internal order number may differ. Keep the link between them, together with the source account. A later update can then reach the right sale, even if your business operates multiple accounts or channels.
Similar descriptions are not reliable product keys. A listing may use a different title, and size or color variants must map to the exact item that will be picked. A SKU or another consistent identifier can provide that link, provided the catalog and mappings are checked.
For example, a blue shirt in medium and the same shirt in large may share a listing but have separate inventory balances. Mapping only the parent product could reduce the wrong variant's stock. A test needs to verify the variant link, quantity and data received by each system. This is an illustrative scenario, not a result from a particular retailer.
Decide who owns inventory, prices and payment states
If several systems overwrite inventory without coordination, an older update can replace a newer balance. Naming the stock authority and defining when reservations or deductions happen helps prevent that conflict.
Choosing an owner is only the first step. Document how reservations, sales, cancellations and returns affect the balance. Specify what gets sent to each channel, too: physical stock and the quantity available to sell may differ. A safety stock rule may be appropriate, but it needs to be understood and tested.
An imported order should preserve the amounts agreed in the original transaction, including discounts and shipping. It should not be recalculated using today's catalog prices. Payment handling also needs to distinguish an order being received from the state that permits processing. That rule depends on the channel and the business workflow; a generic label is not enough.
Keep order receipt separate from invoicing
Importing a sale does not establish that every field needed for invoicing is correct. Missing customer information, commercial rules or channel-specific data may need attention before the next step.
Decide which checks are automatic and which issues stop processing. Staff should be able to see why an order is waiting, which system is involved and what needs to happen. An “integration complete” message has little value if the ERP still requires a correction.
Apply the same discipline to dispatch and tracking. Establish where the shipping confirmation comes from and which update must return to the marketplace, according to the supported capabilities. Moving an order into picking is not grounds for telling the customer it has shipped.
Make repeat delivery safe
Communication can fail after the destination has already stored the order. When the integration retries, it needs to recognize that sale and finish processing without creating a second copy.
This property is commonly called idempotency: repeating the same operation should not duplicate its effect. In practice, the integration must connect the source order to its internal record and check the existing state before repeating actions such as order creation or inventory deduction.
Some errors also need human intervention. An exception queue should identify the affected order, its latest processing attempt and the missing correction. Reprocessing should be a controlled action that retains the history, rather than an attempt to erase evidence and start over.
Test the cases your staff actually deal with
A small pilot makes it easier to compare expected behavior with the actual result. Choose cases that represent your operation, including orders with multiple steps or different processing conditions.
- A simple order and orders with several units or variants.
- Discounts and shipping amounts preserved across the workflow.
- Later payment updates and cancellations, where the channel supports them.
- Unmapped products and incomplete customer records.
- A communication failure followed by a retry without duplication.
- Dispatch confirmation and the correct order-status update.
For each case, inspect the records in the systems involved and the effect on inventory. Seeing an order in the ERP is one part of validation; the operational outcome must also be correct.
Review exceptions and choose the first improvement
After the pilot, monitor orders processed without intervention, orders that need correction and the time between the sale and its availability for fulfillment. These are ways to structure a review, not a promise of performance.
Start with the step that consumes the most time or repeatedly causes errors. That might be order import, product matching or dispatch updates. Each change needs an owner, acceptance criteria and a recovery path when something fails.
AGTI develops integrations and systems around business workflows. If your team still copies orders between dashboards, describe your channels, the systems involved and the step where work is repeated. That gives a technical review a concrete scope. Learn about AGTI's approach at https://www.agti.eng.br/.