ERP to Marketplace Integration: Where It Actually Breaks

An integration is never finished. It is a running agreement between two systems that were designed by people who never spoke to each other. It works until a marketplace changes a field, a catalogue team creates a duplicate, or a sale event triples the update volume. Then the numbers stop matching and everyone looks at the dashboard as if staring will fix it.

What follows is the list of things that actually break, in the order they usually break, and the sequence to work through when the numbers go wrong.

The failure modes worth knowing

Identifier mismatch. This is the root of most integration pain. The ERP holds an internal item code. The marketplace holds its own listing identifier. Somewhere between them sits a GTIN. When a catalogue executive creates a second listing for the same product, or when a combo pack is given the barcode of its component unit, the mapping table now points two channel listings at one ERP item. Stock gets double published. Sales get attributed to the wrong item. Nobody notices until a stock count fails.

Stock sync latency and oversell. Every integration has a lag. The question is how big it is and what happens inside it. A five minute cycle is fine on a normal Tuesday and dangerous during a flash deal, because an item can sell forty units inside one cycle. Oversell is not a software bug. It is a queue design problem. Full inventory pushes take longer than delta pushes and often get throttled at exactly the moment you need them.

Price update race conditions. Two systems both writing price is a guaranteed incident. A repricer, a promotions tool and the ERP each push a value. The last write wins, and last is decided by network timing, not by intent. You end up selling at a promotional price after the promotion ended, or at MRP during your biggest sale day. Pick one authority for price per channel and make every other tool propose to it rather than write directly.

Returns and refunds that never write back. Most integrations are built forward. The order flows out, the invoice flows out, and the reverse leg is handled by a portal export somebody downloads weekly. The result is stock that is physically back in the warehouse but not sellable in any system, and refunds that appear only in the settlement file. Return write back needs three separate events, not one. Return initiated, unit physically received, unit graded and dispositioned.

Tax fields and HSN mapping. HSN codes live in the ERP item master and get copied into channel catalogues at listing time. When a rate changes, or when a product is reclassified, the ERP is updated and the channel copy is not. The invoice generated by the marketplace then carries a different rate from your books. This surfaces at return filing, months later, and it is tedious to unwind. The same applies to state level fields on stock transfers.

Partial cancellations. A three line order where one line is cancelled after allocation is the most common state machine failure. Weak integrations either cancel the whole order internally or keep the full quantity allocated. Both are wrong. The stock for the cancelled line must be released, the invoice must reflect the shipped lines only, and the channel status must be updated for that line alone.

Settlement gaps. The order value you booked is never the amount that arrives. Commission, fulfilment fees, shipping charges, storage, advertising recovery, damage claims, promotional funding and TCS all sit between them. If the integration writes only the order value into the ERP, your receivable will never age correctly and the finance team will build a parallel spreadsheet. That spreadsheet becomes the real system, which is the outcome you were trying to avoid.

A diagnostic order when the numbers stop matching

Work top down. Do not start with the marketplace support ticket. Start with your own data.

1. Fix the window and the unit. One channel, one warehouse, one calendar month, in units before rupees. Mixed windows create phantom variances.
2. Check the mapping table. Count distinct channel listings per ERP item and distinct ERP items per channel listing. Anything that is not one to one is a suspect before you look anywhere else.
3. Reconcile order counts before values. If the count of orders differs, the problem is ingestion. If the count matches and the value differs, the problem is pricing, tax or deductions.
4. Check the integration logs for failed and retried calls in the window. Most platforms expose rejection reasons. Silent failures usually leave a trace in the queue even when the dashboard shows green.
5. Reconcile dispatched units against invoiced units. A gap here is a partial cancellation or a short shipment that was never written back.
6. Reconcile returns in three stages against the physical count. Initiated, received, restocked. The gap between received and restocked is your grading backlog and it is almost always larger than anyone believes.
7. Only then open the settlement file and match line by line against your booked receivable, deduction head by deduction head.
8. Last, check tax. Compare HSN and rate on a sample of marketplace invoices against the ERP master for the same items.

In most investigations the answer appears at step two or step six. Teams jump to step seven because settlement is where the money is, and then spend a week chasing a symptom.

What to build once instead of repeatedly

Three things pay for themselves. A daily mapping integrity check that flags any listing without exactly one ERP item. An exception report of failed and retried API calls with a named owner, reviewed every morning. A monthly reconciliation that is a scheduled job rather than a heroic effort by one analyst.

Also decide, in writing, which system is authoritative for each field. Stock, price, title, images, tax code, MRP. One authority per field per channel. Write it on a single page and keep it where the catalogue team can see it. Most integration incidents are not technical failures. They are two people confidently updating the same field in two different places.