Most product data problems are reported as system problems. The ERP sync failed, or the 3PL rejected a delivery. In most of the cases we’ve traced back this year, the system did what it was told. The break happened earlier, at a handoff between two teams where nobody owned the moment the data changed hands.
The PO keeps changing after it’s sent
A PO goes out from the ERP, then delivery dates and quantities get renegotiated with the supplier over email and logged in a merchandising tracker. A colour code gets corrected, or a barcode is reissued, and the product record updates while the 3PL is still expecting what the original PO told it. Within a few weeks, the ERP and the tracker have drifted apart, the supplier’s confirmation says something else again, and the factory ships against whichever version it has.
We’ve spoken to brands where around one in four POs had a problem by the time the stock reached the warehouse, from wrong barcodes on cartons to stock booked for one market arriving in another. Changes to a PO belong on the PO, checked before release, where the supplier and the warehouse can both see them.
Complete fields can still be wrong
Buying usually enters composition first, from the supplier’s spec. Garment tech then checks it against the test certificates. If the website and the wholesale platform both pull from the PLM before that check happens, the unverified version goes live. We’ve seen the wrong composition published to customers this way.
Most PLMs show a completeness score. It tells you a field has something in it and says nothing about whether it's right. Approval statuses help, but only if the website and wholesale feeds are set up to wait for them, and often they aren't. It's worth checking whether yours can hold a product back until garment tech has signed it off, and whether anyone checks the physical care label against the record on the production sample.
Next season shouldn’t be able to overwrite this one
Carryover styles are where PLM to ERP syncs get risky. A product running into a new season keeps its identity, but its price and status change for that season. If the sync treats the newest record as the truth, a change made for next season can overwrite this season’s RRP while the product is still on sale.
The business has to decide which season is allowed to publish to the ERP, before anyone builds the integration.
Wholesale can’t sell what it can’t see
Wholesale orders are often taken against a preseason forecast that never makes it into the systems. Merchandising buys to cover it, but nothing connects the wholesale order to the supplier PO that’s meant to fill it. When availability is shown to agents and stockists, the only reliable number is what’s already in the warehouse, so lines get dropped from orders after they’ve been taken.
A wholesale catalogue has to be backed by incoming stock and allocation. Listing the products is the easy part.
The integration ran, so everything must be fine
Integration monitoring tends to check whether a feed ran. In one rollout, wholesale orders synced into the ERP as expected, and every one of them arrived in the DTC sellable location. In another, short-shipped lines on partial dispatches stayed open and left availability negative.
The useful check is where the order ended up and what state it’s in once it gets there.
Finding yours
None of these is solved by a new system. Each one comes down to a named owner at the point the data changes hands, and someone checking what arrived on the other side.
Start with the spreadsheets that exist before the PO. Every brand calls them something different, from range master to product master, and one of them usually ends up as the source of truth without anyone deciding it should be. If nobody can find a current process document for a handoff, you’ve probably found one of the weak ones.