How Apparel POS and ERP Should Talk to Each Other

It is Saturday afternoon at the flagship store on Abbot Kinney. A customer wants the last navy overshirt in a size medium. The POS shows one in stock. The associate rings it up, the customer leaves happy, and the receipt prints. Ninety minutes later, the same SKU sells on Shopify, and the warehouse picks the order. On Monday morning, a wholesale buyer escalates because their pre-book allocation for that style is now short by one unit. Three systems each thought they owned the same piece of inventory. Nobody lied. The POS and the ERP were never properly introduced.

How should an apparel POS and ERP actually talk to each other?

Most apparel brands answer this question by accident. They buy a POS for the store, they buy an ERP or operations system for the back office, and they bolt the two together with whatever native connector ships in the box. The result usually works for a quarter or two, then quietly degrades. This post is about apparel pos erp integration done deliberately: what data should move, in which direction, on what trigger, and who owns the reconciliation when the two systems disagree.

The shorthand most teams use is wrong. POS and ERP are not peers exchanging updates. One of them has to be the source of truth for inventory and product data, and the other has to be the source of truth for the in-store transaction. If both systems try to own the same field, you get drift. If neither system owns a field, you get blanks. The job of an integration is to draw those lines clearly and enforce them with code, not with a runbook.

What is apparel POS and ERP integration, precisely?

Apparel POS and ERP integration is the data contract between a retail point of sale system and the back-office operations system that governs five flows: product and price data flowing from the back office into the POS, inventory availability syncing in both directions, sales transactions flowing from the POS into the back office as orders and as financial entries, customer records linking across channels, and end-of-day settlement reconciling cash, card, and tender totals against what the back office records as revenue. Each of those flows has a direction, a trigger, a frequency, and a tie-breaker.

Note what is not on that list. Sizing curves, vendor lead times, production status, wholesale terms, and pre-book allocations have no business inside the POS. A POS is a transaction system optimised for a thirty-second checkout. An ERP or apparel operations system is a planning and reporting system optimised for the lifecycle of a style. Confusing the two is how most integrations get over-scoped and under-deliver.

Why does this break in apparel specifically?

Apparel breaks generic POS-to-ERP integrations for three reasons. The first is the SKU explosion. A single style with eight sizes and four colours is thirty-two SKUs before you count fits or wash variants. Most off-the-shelf integrations were designed for a hardware brand selling fifty SKUs, not a contemporary label carrying eight thousand active variants per season. Sync jobs that work fine at small scale start timing out, missing rows, or silently dropping size 2XL because the parent style record was updated mid-job.

The second reason is seasonality. Apparel ranges turn over four to twelve times a year. Every season brings a wave of new styles, new barcodes, new prices, and a long tail of markdowns on prior-season stock. The integration has to handle constant catalogue churn without breaking historical reporting. Generic connectors usually treat the catalogue as static and force someone in operations to babysit the sync every time a new drop ships.

The third reason is the wholesale plus DTC overlap. The same physical unit might be earmarked for a wholesale shipment, available on the website, and sitting on a store shelf, all in the same week. If the POS thinks it owns store inventory in isolation, and the ERP thinks it owns the warehouse, and Shopify thinks it owns the e-commerce buffer, then three systems are each making promises against the same pool. This is the territory of Breakpoint 4 in the 6 Breakpoints of Apparel Operations framework, where order flow becomes harder to trust because no single system can see all the demand against a finite supply.

What data should flow from the back office to the POS?

The back office should be the source of truth for the product catalogue and for retail pricing. That means style, colour, size, barcode, retail price, currency, tax class, and season tag all originate in the operations system and push into the POS on a schedule, ideally near real-time when a style is published or a price is changed. The POS should never be the place where someone hand-types a new SKU on a Friday afternoon because the catalogue was not loaded.

Promotions are the grey area. Some brands manage promotions inside the POS because store managers run flash sales. Others manage them centrally so wholesale, DTC, and retail discounts stay coordinated. Either choice is defensible, but it has to be a choice. If both the POS and the ERP can edit a discount on the same SKU, you will eventually have two different prices ringing up at two different stores on the same Saturday.

What data should flow from the POS to the back office?

Three things, on three different cadences. Sales transactions should flow as soon as the receipt prints, ideally within seconds, so that inventory in the back office reflects what just left the store. Customer records, including new sign-ups and updated contact details, should flow at the end of each transaction so the marketing team can stitch a unified profile across DTC and retail. End-of-day settlement, including cash drawer counts, card processor totals, returns, exchanges, and any voided transactions, should flow as a single batch after the store closes.

The settlement batch is the part that finance cares about most and that integrations most often get wrong. A receipt-level sync gives operations real-time inventory but does not give finance a clean tie-out. Without an end-of-day reconciliation, the controller has to sum up thousands of individual transactions and compare them against the merchant processor settlement file by hand. The integration should produce a single daily journal entry per store, per tender type, that finance can post without a calculator.

How should inventory sync between the two systems?

This is where most apparel integrations either work beautifully or fall apart entirely. There are two viable patterns. In the first pattern, the back office is the master of all inventory across all locations, and the POS receives a feed of available-to-sell quantities at each store. In this model, when a sale rings up, the POS sends the transaction back, and the back office decrements inventory and re-broadcasts the new quantity. The POS holds a cached view but does not own the number.

In the second pattern, the POS owns store inventory locally and reports counts on a schedule. The back office owns warehouse inventory and reconciles the totals. This pattern is simpler to wire up but produces drift. Store associates do receiving, transfers, and damages directly in the POS, and those movements show up in the back office hours or days later. For brands above five million in revenue with active wholesale and DTC, the first pattern is almost always the right answer.

The reason is allocation. If a buyer commits twelve units of a style to a wholesale account, the back office needs to be able to subtract those units from total available before the POS sees them. If the POS has its own ledger and only reports up, you cannot enforce that allocation without a manual hold. Centralised inventory with broadcast availability gives the merchandising team one lever to pull, and it gives the warehouse, the store, and the website the same answer at the same moment.

What about returns, exchanges, and store-to-store transfers?

Returns are the silent killer of POS-to-ERP integrations. A customer returns an item bought online to a physical store. The POS has to recognise the original order, accept the return, refund to the original tender, put the unit back into store inventory, and notify the back office that an e-commerce order has been partially refunded. If any of those five steps fails to sync cleanly, you end up with a unit that exists in two places, a refund that posts twice, or a customer who is told to call the website even though they are standing in the store.

Store-to-store transfers have the same fragility. When a unit moves from the SoHo store to the Melrose store, the POS at origin should decrement, the POS at destination should increment, and the back office should record the transfer with timestamps and a reference number. If the integration only syncs sales, transfers happen invisibly and store-level inventory rots. The contract has to cover non-sale movements explicitly: receipts from the warehouse, transfers between stores, damages, samples, employee purchases, and physical count adjustments.

How should customer records be unified across POS and DTC?

A customer who shops in-store on Saturday and online on Tuesday is the same customer. The integration should make that obvious to every system that needs to know. The practical design is a single customer ID owned by the back office or by a dedicated customer data layer, with the POS and the e-commerce platform both writing into and reading from that ID. Email is the usual matching key, with phone number as a fallback.

The trap is letting each system create its own customer record and trying to merge them later. By the time you get to a million transactions, you have duplicate records, broken loyalty balances, and a CRM that the marketing team has stopped trusting. Push the unification to the front of the integration, not the back end of a quarterly cleanup project.

How does the integration handle financial reconciliation?

Finance needs three things from the POS feed. First, daily revenue by store, by category, and by tender, broken out so it can be posted to the general ledger. Second, the matching settlement amounts from the merchant processor, so card revenue can be tied to bank deposits net of fees. Third, a clean audit trail for every adjustment: returns, voids, manager overrides, and discounts applied at the register.

The integration should produce these as structured outputs, not as PDF reports the controller has to re-key. If the back office can ingest a daily journal file from the POS and post it to the GL with one approval, the month-end close compresses by days. If finance has to download CSVs from three POS terminals and reconcile them against the processor statement by hand, the integration is technically working but operationally failing.

Where do most apparel POS and ERP integrations actually fail?

The failure modes are predictable. The first is silent sync failures, where a job times out, the catalogue update never lands, and nobody notices until a store associate cannot ring up a new style. The second is duplicate-source-of-truth, where the POS and the back office both think they own retail price or inventory, and the most recent edit wins. The third is partial coverage, where the integration handles sales but not returns, or sales and returns but not transfers, leaving operations to manage the gaps in spreadsheets.

The fourth and most damaging failure is the absence of monitoring. A healthy integration emits heartbeat metrics: number of products synced, number of transactions received, number of records that errored out and why, lag time between POS event and back-office record. Without that telemetry, the team finds out about problems from angry customers and confused buyers, not from a dashboard. Treat the integration like infrastructure, not like a one-time project.

What this means for an apparel operations team

If your POS and your back office disagree about inventory more than once a week, that is not a training problem. It is an architecture problem, and it will get worse as you add stores, channels, and SKUs. The fix is to draw the data contract on paper before you wire anything up. Decide which system owns each field. Decide what the trigger and frequency are for each flow. Decide what happens when the two systems disagree, and put that tie-breaker in code.

The brands that get this right tend to run product development, product data, production, inventory, orders, warehouse execution, payments, and reporting in one connected system, and they treat the POS as a specialised front-end that reads and writes against that system through a well-defined contract. The brands that get this wrong tend to have a back office, a POS, an e-commerce platform, a 3PL portal, and a stack of reconciliation spreadsheets, and they wonder why their controller cannot close the books inside ten business days.

The work is not glamorous. It is field-by-field, flow-by-flow, edge-case-by-edge-case. But the payoff is that the navy overshirt scenario from the first paragraph stops happening, finance closes faster, and the merchandising team can actually trust the inventory number on the screen in front of them. That is what apparel pos erp integration is supposed to deliver, and it is what most generic connectors quietly fail to do.