A Monthly 3PL-to-ERP Inventory Reconciliation Sequence

It is the second Tuesday of the month. The controller has a spreadsheet open with three tabs: the ERP on-hand export, the 3PL warehouse management system snapshot, and last month’s unreconciled deltas that never got resolved. The ops manager is on Slack with the 3PL asking why 412 units of a core tee show as picked in the WMS but still available in the ERP. A wholesale rep is trying to confirm an allocation for a 900-unit PO shipping Friday. Nobody in the room can answer, with confidence, how many units of that SKU the brand actually owns right now. This is the monthly reconciliation problem, and most apparel brands are losing at it.

What does it mean to reconcile 3PL inventory against ERP?

To reconcile 3PL inventory against ERP is to prove, at a defined cutoff, that three numbers agree per SKU: what the ERP says is on-hand and available, what the 3PL WMS says is physically in the building, and what is legitimately in-transit between the two systems (returns inbound, POs received but not yet posted, transfers between locations, orders picked but not yet shipped). Reconciliation is not a warehouse count. It is a ledger discipline. The count tells you what is there. The reconciliation tells you why the two systems disagree and which one is wrong.

This work maps directly onto BP3 of the 6 Breakpoints of Apparel Operations, the point where inventory truth gets weaker. BP3 does not fail because the 3PL is bad or the ERP is bad. It fails because the handoff between them is unmanaged: no cutoff, no in-transit ledger, no adjustment protocol, no variance threshold. Every month the numbers drift a little further, and by month six the brand is oversold on the SKUs that matter and overstocked on the ones that do not.

Why does 3PL to ERP reconciliation break at $10M to $20M?

When I started Uphance, the pattern I saw repeatedly was a $15M apparel brand where one person, usually in ops or finance, had become the human integration layer between Shopify, the 3PL, and the wholesale channel. Six to nine hours a week reconciling. A 2 to 3 percent oversell rate at peak. One FTE effectively doing data plumbing that a system should do. That person is not incompetent. They are compensating for missing architecture.

Under $10M, a brand can get away with a weekly manual sync because the SKU count is small and the channel mix is simple. Above $20M, the pain is severe enough that the brand has either bought a real system or is bleeding margin visibly enough that the CFO has intervened. The zone from $10M to $20M is where reconciliation breaks silently. The SKU count crosses roughly a thousand active. Wholesale POs start committing inventory 30 to 90 days out. DTC pulls from the same physical pool but through a different order flow. Returns from both channels come back through the 3PL on a lag. Nobody has changed the reconciliation process from what it was at $5M, which was a controller with a spreadsheet on a Friday afternoon.

The monthly sequence below is what a working reconciliation looks like when it is actually designed instead of improvised.

What is a hard cutoff and why does it come first?

Every reconciliation begins with a cutoff. This is a specific timestamp, agreed with the 3PL in writing, at which both systems freeze their view of the world for the purpose of the reconciliation. Without a cutoff you are comparing a moving ERP against a moving WMS, and you will chase phantom deltas forever.

The cutoff should sit at end of day on the last business day of the month, in the 3PL’s local time, not the brand’s. This matters because pick, pack, and ship activity in the WMS is stamped in the warehouse’s time zone. If your brand runs in New York and your 3PL is in Kentucky, using Eastern time for the cutoff means an hour of Kentucky shipping activity gets counted twice. Small brands ignore this. Larger brands stop ignoring it after the first quarter-end audit question they cannot answer.

On the cutoff, three exports get pulled and archived: the ERP on-hand and available by SKU by location, the WMS on-hand by SKU by bin, and the open order book showing everything picked but not shipped, everything shipped but not invoiced, and everything received but not putaway. Those three files are the reconciliation’s source of truth for the month. Do not re-pull them mid-cycle. If a number is wrong in the export, it gets adjusted in the reconciliation, not by rerunning the report.

How do you build the in-transit ledger?

The in-transit ledger is the piece most brands skip, and it is the piece that makes reconciliation actually work. In-transit is everything the ERP thinks is inventory but the 3PL cannot physically show you, plus everything the 3PL is holding that the ERP has not yet accepted.

There are five in-transit buckets to track separately:

• Inbound POs, received at the 3PL but not yet posted to the ERP. Usually a 24 to 72 hour lag. Should be reconciled against the ASN and the receiving report.
• Inbound returns, in the 3PL’s returns queue but not yet inspected, graded, and restocked. This is often the largest and most stale bucket. Returns should post to inventory in days, not weeks, and if your returns bucket has units older than ten business days you have a process failure, not a reconciliation problem.
• Outbound orders, picked but not shipped. These have been decremented from WMS available but not from ERP available. The delta is legitimate but must be tracked.
• Outbound orders, shipped but not invoiced. Rare in DTC, common in wholesale where invoicing lags shipping by a day or two.
• Transfers, between 3PL locations or between the 3PL and a brand-owned warehouse. These live in-transit for whatever the carrier’s transit time is, plus receiving time.

Every unit of variance between the ERP and the WMS must be explainable by one of these five buckets or it goes into the adjustment log. No exceptions. If a variance is unexplained, you do not close the reconciliation with it hidden.

What is the right variance threshold?

Here is where I will take a position most reconciliation guides will not. The right SKU-level variance threshold for an apparel brand between the 3PL WMS and the ERP is 1 percent of on-hand or 5 units, whichever is greater. Anything above that triggers a cycle count on that SKU before the reconciliation closes. Anything below that gets adjusted in the ERP to match the WMS and logged.

The reason for the floor of 5 units is that on low-quantity SKUs, a 1 percent threshold is meaningless. A SKU with 40 units on hand has a threshold of 0.4 units, which forces you to cycle count for every rounding error. The reason for the 1 percent ceiling is that above that level, you are no longer looking at pick errors and system latency, you are looking at real shrink, mispicks that shipped to customers, or receiving errors. Those need eyes on them.

This threshold is not universal. A brand with high unit-value product (outerwear at $400 wholesale) should set a tighter threshold because the margin exposure per unit is larger. A brand with high-volume, low-value product (basics under $10 wholesale) can loosen it. But the discipline of having a written threshold, applied uniformly, is what separates a real reconciliation from a monthly panic.

What does the adjustment protocol look like?

Every adjustment to reconcile the ERP to the WMS should carry four pieces of metadata: the SKU, the unit delta signed positive or negative, the reason code, and the approver. Reason codes should be a fixed short list, not free text. A workable list is: pick error, receiving error, damage, shrink, system latency, returns lag, count error, unknown.

The unknown bucket is important. If more than 10 percent of your monthly adjustments by unit count go to unknown, your reconciliation is not diagnostic, it is cosmetic. You are just making the numbers agree without understanding why they disagreed. Looking at where apparel brands keep buckling at $10M to $20M, the unknown bucket is almost always the largest category, and nobody has looked at the trend over six months. When you do look, patterns emerge: a specific pick zone with a chronic error rate, a specific carrier with a delivery scan lag, a specific product category where returns grading is too slow.

The approver requirement matters because adjustments are the vector for both honest mistakes and dishonest ones. A controller signing off on 4,000 units of shrink adjustments across a quarter should be a moment of institutional attention, not a rubber stamp on a spreadsheet nobody reads.

How does wholesale allocation change the sequence?

A DTC-only brand can reconcile against a single on-hand pool. A brand running wholesale plus DTC cannot, because a large share of the WMS on-hand is committed to wholesale POs that have not yet shipped. The ERP has to distinguish between physical on-hand, available-to-sell for DTC, and available-to-promise for new wholesale orders, and the reconciliation has to prove all three.

The way to do this cleanly is to reconcile physical first and commitments second. Step one: prove that ERP physical on-hand equals WMS on-hand plus in-transit, within threshold. Step two, separately: prove that ERP wholesale-committed units tie to the open wholesale order book at the cutoff. Step three: derive DTC available as physical minus committed minus safety stock, and confirm that the number Shopify or your DTC storefront is pulling matches that derived figure.

This is the workflow where brands running wholesale through Shopify’s native inventory flow get into trouble. Wholesale should not run through Shopify’s native flow. Shopify treats every unit in the pool as available to whoever checks out first, which means a large wholesale PO booked for a September ship date can be silently eroded by August DTC sales, and the brand only finds out when the wholesale allocation cannot be filled and the retailer chargebacks arrive.

What should the closing artifact contain?

The monthly reconciliation should produce a single closing artifact, archived, that any auditor or new hire can open and understand. It should contain: the cutoff timestamp, the three source exports, the in-transit ledger with each bucket totaled, the variance report with every SKU above threshold flagged and either cycle-counted or explained, the adjustment log with reason codes and approvers, and a one-page summary of month-over-month trends in total adjustments, unknown-bucket percentage, and returns-lag aging.

That one page is what the CFO actually needs. Not the raw variance report. The trend on unknown adjustments and returns aging tells the CFO whether the operation is getting more or less trustworthy over time, and it is the single most useful operational metric that most apparel brands do not track.

What this means for an apparel operations team

A reconciliation that takes 6 to 9 hours a week is not a discipline, it is a symptom. The hours are the cost of not having a hard cutoff, an in-transit ledger, a variance threshold, and a written adjustment protocol. When those four pieces exist, the weekly touch drops to a scan for exceptions and the monthly close becomes a review of the closing artifact rather than a rebuild of the reconciliation from scratch.

BP3 of the 6 Breakpoints does not resolve by buying a better warehouse or a better ERP in isolation. It resolves by treating the handoff between them as its own workflow, owned by a named person, with a written cadence and a written protocol. The 2 to 3 percent oversell rate at peak is not a warehouse problem or a Shopify problem. It is the absence of that workflow.

Brands that adopt the monthly sequence described here typically see the unknown-adjustment bucket drop within two cycles, because the act of forcing a reason code surfaces process failures that were previously invisible. That is the point. The reconciliation is not the goal. The goal is the diagnostic feedback loop that the reconciliation produces.