Three Systems. Zero Communication. $1M+ in Wholesale Orders Stuck.

Mar 29, 2026 · Drama · 5 min read

A former client's tech stack looked reasonable on paper. Cin7 for inventory management and accounting. Extensiv for warehouse management at their 3PL, RAD 3PL. CartRover as the middleware connecting their wholesale channels to both.

These are all reputable platforms. Each one does its job. The problem was that nobody had configured the connection between them correctly, and when something breaks at the integration layer, the failure looks like almost anything other than an integration layer failure.

What the symptom looked like

Purchase orders from wholesale channels (UNFI, Jewel Osco, Target) weren't flowing through to RAD 3PL for fulfillment. EDI orders were coming in through the Crystal wholesale system, and they were sitting.

The first working theory was a CartRover configuration issue. Then a Cin7 setup issue. Then a permissions problem. Then a CartRover issue again. This is what integration layer debugging looks like: the failure is in the gap between systems, so each system's support team points at the other one.

For weeks, wholesale orders that should have been flowing automatically were being worked around manually. Someone would identify a stuck order, figure out why it hadn't synced, and push it through by hand. The workaround worked well enough that the root cause stayed hidden. The orders got fulfilled. The system appeared to be functioning. The actual problem, that every PO created when inventory was on backorder was silently failing to sync, wasn't visible until someone asked why the manual interventions kept being necessary.

The actual problem

Deep inside Extensiv's configuration, there's a setting called a lock code. Lock codes determine whether a PO can be released for fulfillment based on inventory status. The specific setting that mattered was the one governing what happens when a PO is created and the ordered quantity isn't fully in stock.

The setting was configured as "Ordered." What it needed to be was "Ordered and Backordered."

That distinction sounds minor. It isn't. With the setting on "Ordered," any PO that was created when inventory was on backorder, meaning the warehouse didn't have enough stock on hand to immediately fulfill it, would fail to sync between Cin7 and Extensiv. The PO would exist in Cin7. It would not appear in Extensiv. CartRover, which was routing orders between the two, had nothing to relay.

For a food brand that regularly runs lean on inventory and expects orders to queue against incoming stock, "Ordered and Backordered" is the correct behavior. The PO should exist in the warehouse management system regardless of current stock levels, waiting for inventory to arrive. The "Ordered" setting effectively said: only sync this PO if we already have the stock. Which meant that every order that required any degree of backorder processing was invisible to the 3PL.

Why this kind of failure is so hard to find

Platform-specific configuration knowledge is not general knowledge. The lock code setting in Extensiv is not something you'd encounter unless you'd worked with Extensiv specifically, at this depth, in a multi-system integration context. Cin7's support team doesn't know Extensiv's lock code behavior. CartRover's support team sees orders passing or not passing and can tell you which, but can't diagnose why the Extensiv side isn't accepting them.

The only way to find this was to sit with an Extensiv support specialist and go through the configuration settings one by one, asking what each one does and what happens in edge cases. That conversation eventually surfaced the lock code issue. Before that conversation, there was no obvious path to the right answer.

From the outside, integration layer failures don't announce themselves as integration problems. They look like fulfillment delays, stuck orders, unexplained manual interventions, sync behavior that comes and goes. The symptoms are diffuse enough that you can burn real time investigating the wrong system.

What the fix enabled

One dropdown change in Extensiv: from "Ordered" to "Ordered and Backordered."

After that, POs started syncing correctly between Cin7 and Extensiv regardless of inventory availability at the time of order creation. The 3PL received the orders, queued them against expected stock, and fulfilled them when inventory arrived. No more manual interventions for the backorder case.

The orders to UNFI, Jewel Osco, and Target that had been stuck or manually worked around were now processing automatically. The volume those accounts represent was significant. This wasn't a minor edge case. These were a former client's major wholesale relationships.

The takeaway isn't "check your lock codes." Most people don't know what lock codes are. It's that integration-layer problems need someone who has built this specific integration before, not someone who knows each platform on its own. General platform expertise doesn't carry over. You want the person who has been inside that exact configuration and knows where the edge cases live.

One dropdown setting held up weeks of orders. That ratio, a single config change unlocking an entire channel's order processing, shows up more often than it should.

Want this run on your catalog?

This is the kind of problem we work every week inside live accounts. Bring your stock report to a 30-minute Fit Call, we’ll tell you which SKUs are at risk in the next 90 days. If we’re not the right fit, we’ll say so.

30 minutes · no deck, no pitch, your numbers