For Australian fashion, apparel and footwear businesses

Apparel and Footwear ERP Integration

Most integration projects assume a product is a thing with a price and a quantity. Fashion is not built that way. A style exists in several colourways, each colourway exists across a size run, the run sells unevenly, the season has a start and an end, and a third of what ships may come back. Generic connectors meet that structure and quietly flatten it.

This page is about keeping the structure intact across systems: mapping a style, colour and size matrix onto online variants without losing the grid, holding size runs together for allocation and replenishment, carrying seasons and markdowns properly, and dealing with the return rates that make apparel a different business from selling hardware.

Book an Apparel Systems Call (03) 9003 0111

The Shape of the Problem

3 levels

Style, colourway, size

Collapse any one of them and merchandising, buying or the website breaks

One style, dozens of codes

A modest range becomes a large catalogue

Six colours across eight sizes is forty eight sellable lines from one design

Highest returns

Of any mainstream retail category

Fit driven, so the integration has to treat returns as normal traffic, not exceptions

Seasons, not months

The planning unit that matters

Drop dates, cancellation dates and markdown timing all hang off it

Four Structural Problems Unique to Fashion

These are not edge cases. They are the shape of the category, and an integration that does not answer them will need rebuilding within a season or two.

The matrix has to survive the trip

An apparel system thinks in a grid: this style, in these colours, across this size run. Most online platforms think in a flat list of variants with option values attached. Translating one into the other is straightforward until you need the grid back, which you do the moment anyone wants to see which sizes are broken, allocate a run to a shop or reorder a colourway. The integration has to carry the parent style relationship and the size ordering as real data, not reconstruct them later from naming conventions.

Sizes are not a text field

Sizes sort by scale, not alphabetically, and a customer who sees XL listed before S loses confidence in the site immediately. Australian womenswear, menswear, kidswear, and footwear in Australian, United States and European scales all order differently, and footwear brings half sizes and width fittings on top. Every size value needs a sort position and a scale it belongs to, defined once in the owning system and carried through, or every channel will guess differently.

Colour naming decides whether anything matches

The buying team calls it Midnight, the supplier ships it as NVY, the website says Navy and the marketplace feed demands a standard colour family. Without a mapping table that resolves all of those to one internal value, images attach to the wrong colourway, filters return nonsense and marketplace listings get rejected. This is dull work that pays for itself in the first season, and it belongs in the integration layer where every channel can share it.

Seasons make products temporary

A fashion range has a launch date, a delivery window, a cancellation date and an end. Products need to appear online at the right moment, move through planned markdowns, and be retired without leaving dead pages and orphaned stock behind. An integration that treats every product as permanent leaves last winter on the site in October and forces someone to tidy up manually every few months, which is exactly the manual work you were trying to remove.

Six Flows a Fashion Business Actually Needs

Retail, wholesale or both, these are the connections that carry the weight in an apparel stack.

Grid intact

Style and variant creation

New styles created once in the owning system flow out as a parent product with correctly ordered variants, the right barcode on every size and colour combination, images attached at colourway level rather than repeated per size, and swatches mapped to the shared colour list. Done well, a buyer sets up a range once and it appears correctly everywhere, including on the marketplaces that insist on their own attribute names.

Honest sizes

Size run availability

Availability published per size, per location, adjusted for what is committed and for any buffer, so the site never offers a size that sold in a shop an hour ago. It also means the site can say what is genuinely coming back into stock, which for a fit driven category is worth more than a generic notify me on a style that will never return in that size.

Runs balanced

Allocation and replenishment

Moving stock to where the sizes are actually selling, using size curves rather than even splits, and identifying broken runs before a shop is left with only the extremes. This is where multi site apparel retailers either make or lose their margin, and it depends entirely on the integration carrying size level data rather than style level totals.

Prices aligned

Markdown and promotion

Planned markdowns applied on the date they are meant to start, across the website, the tills and the feeds at the same time, with the previous price recorded so was and now claims can be substantiated. Australian Consumer Law takes a dim view of a reference price that was never genuinely charged, and price history is the evidence that keeps you comfortable.

Orders flowing

Wholesale and indent orders

For brands selling into other retailers: order forms by size run, delivery windows and cancellation dates respected, part shipments handled without confusing the buyer, and rep entered orders landing in the ERP without rekeying. Wholesale terms are different enough from retail that this rarely works as a bolt on to a consumer store.

Stock back fast

Returns and exchanges

Returns received, graded and either returned to sellable stock quickly or routed to seconds, with the refund or exchange matched against the original order and the size level data updated. In a category where fit driven returns are constant, days of delay in putting a size back on the shelf is real lost revenue, not an administrative detail.

Fashion Specific Tasks, Before and After

Task	Traditional	Built for Fashion	Notes
Launching a new style	Entered per channel by hand	Created once, syndicated	Colour and size mappings do the translation so each channel gets attributes in its own vocabulary.
Size ordering on the site	Alphabetical and confusing	Sorted by scale	Sort position belongs to the size value itself, defined once and carried everywhere.
Last one in a shop sells	Still for sale online for hours	Availability updated per size	The oversell that hurts most, because the customer already chose their size.
Broken size runs	Noticed at stocktake	Flagged as they appear	A run missing its middle sizes is effectively unsellable at full price.
End of season markdown	Repriced channel by channel	Applied on the date, everywhere	Price history retained so was and now claims can be evidenced if anyone asks.
Wholesale order from a rep	Emailed spreadsheet, rekeyed	Entered once into the ERP	Delivery windows and cancellation dates travel with the order rather than living in the rep’s head.
A return arriving	Processed in a weekly batch	Graded and resold quickly	In fit driven categories, the same size often has a queue of customers waiting.
Product content for marketplaces	Reformatted per channel	Mapped from one record	Composition, care and country of origin are required almost everywhere and change rarely, so they should be entered once.

Where Apparel Integrations Fall Over

Variant limits and catalogue bloat

A broad matrix multiplies quickly. Six colourways across a ten size footwear run with two width fittings is a hundred and twenty sellable lines from a single design, and platforms have limits on variants per product, images per record and the volume of updates you can push in a given window. Model the numbers before you build. Sometimes the answer is splitting colourways into separate products, and it is far cheaper to make that decision at design time than after the catalogue is live and indexed.

Images attached at the wrong level

Photography belongs to a colourway, not to a size, and not to the style as a whole. Get this wrong and either every size carries a duplicate image set, which slows the site and inflates storage, or the whole style shows one colour and customers order the wrong thing. The mapping needs to be explicit, and it needs a rule for what happens when a colourway has no photography yet, because that will happen in every drop.

Treating returns as an exception path

In fashion, returns are ordinary traffic. An integration that handles them as an afterthought creates stock that is physically in the building but invisible to the website for days, refunds that do not reconcile, and exchange orders that reserve stock twice. Design the returns flow at the same time as the outbound flow, decide who grades and how fast, and measure the time from receipt to resellable, because that number is money in this category.

Markdown timing and was and now claims

Under Australian Consumer Law a comparison price must be genuine, which in practice means you need to be able to show the item actually sold at the higher price for a reasonable period. If markdowns are applied by hand at different times across the website, the shops and the feeds, you have both a customer trust problem and an evidence problem. Effective dating and retained price history solve it, and they cost nothing extra if they are designed in.

Season carryover done manually

When a range ends, someone has to decide what happens to remaining stock, what comes off the site, what moves to outlet pricing and what merges into a continuity line. Left manual, that decision is made late every single season, and the site accumulates dead pages that dilute search performance. Build the season lifecycle into the integration with clear states and dates, and the tidy up becomes a review rather than a project.

Compliance data treated as marketing copy

Fibre composition, care instructions and country of origin are not optional decoration. Care labelling obligations under Australian Consumer Law, country of origin claims and, for larger businesses, modern slavery reporting all depend on this data being accurate and traceable to a source. Hold it as structured fields in the owning system, syndicate it rather than retyping it per channel, and keep the audit trail of what was published and when.

How Yes AI Approaches Fashion Integration

We start with your range plan

Not the API documentation. How many styles, how many colourways, which size scales, how seasons work in your business and where the buying decisions are made. The data model follows from that, and getting it right first time avoids a rebuild in season two.

Honest about off the shelf options

If you run a common apparel platform against a common store and your matrix is modest, an existing connector may cover you and we will say so. The build case appears when size scales, allocation, wholesale terms or marketplace attribute rules exceed what a packaged product will bend to.

Built, hosted and monitored by us

The integration runs on a managed cloud automation layer we operate, with record level logging and same day alerting. Peak trading in this category is unforgiving, so we load test before the season rather than during it.

Documented mappings you own

Colour tables, size scales, attribute mappings and season rules are written down and handed over. When your merchandising team changes or you add a marketplace, the reference material exists rather than living in one developer’s memory.

From Flattened Catalogue to a Working Matrix

Five steps. A first channel with correct variants and availability is usually live in five to eight weeks.

Model the range

Style, colourway and size structure, size scales and sort orders, colour mapping table, season definitions and the identifier that ties everything together. This is the foundation and it is worth the time.

Agree ownership and lifecycle

Which system owns product, price and stock, when a style becomes visible, how markdowns are scheduled and what happens at season end. Written and signed off before build.

Map channel by channel

Each destination gets its attribute mapping, image rules and validation. Marketplaces are done last because their rules are the most rigid and the least negotiable.

Build and pilot on one range

One category or one brand, live on real trade with the old process available. We watch the first drop closely, especially the sizes that sell out first.

Extend, then prepare for peak

Remaining categories, then allocation, wholesale and returns. Load testing and a peak readiness review well before the trading period rather than in the middle of it.

FAQ

Why do generic ecommerce connectors struggle with apparel?

Because they model a product as a single sellable thing and fashion is a grid. When the grid is flattened into a list of variants, three pieces of information get lost: which variants belong to the same colourway, how sizes should be ordered, and which style they all descend from. Everything downstream depends on those relationships. Allocation needs size level detail, merchandising needs the style, photography attaches to the colourway, and reordering needs all three. A connector that cannot carry the structure will work for a season and then need replacing when someone asks a question it cannot answer.

How should we handle multiple size scales, including footwear?

Treat a size as a value with a scale and a sort position rather than as free text. Australian womenswear numeric sizing, alpha sizing, menswear, kidswear by age, and footwear in Australian, United States and European scales each need their own ordered list, and footwear usually needs half sizes and sometimes width fittings on top. Define the lists once in the system that owns product, and have every channel receive both the label to display and the position to sort by. Conversion charts for customers are a separate concern and belong in content, not in the size value itself.

Can the website show which sizes are coming back into stock?

Yes, if the integration carries incoming purchase order or production data at size level, which most apparel systems hold. Expected quantities and dates per size can be published as an expected date rather than an open ended notify me, which converts considerably better for a customer who knows their size. Two cautions. Only publish dates you are prepared to be judged on, since a promised date that slips is worse than no date, and make sure the figure respects units already promised to backorders rather than showing the whole inbound quantity as available.

We sell retail and wholesale. Can one integration cover both?

One integration layer, yes. One set of rules, no. Wholesale trades on order forms by size run, delivery windows, cancellation dates, part shipments, account terms and customer specific pricing, while retail trades on immediate availability and consumer pricing. They share the product data, the stock pool and often the warehouse, so it makes sense to build them on the same foundation with the same colour and size mappings. What differs is the order behaviour and the pricing logic, and trying to force those into a single set of rules is where hybrid businesses usually come unstuck.

How do we keep marketplaces happy with our product data?

By mapping rather than retyping. Each marketplace insists on its own category taxonomy, its own colour families and its own required attributes, and rejections are usually caused by a missing attribute or a colour value outside their accepted list. Hold your data once in structured fields, maintain a mapping per channel in the integration layer, and validate before you send so the rejection is caught by your process rather than theirs. When a marketplace changes its requirements, and they do, you update one mapping instead of reworking a catalogue.

What does the returns side need to do differently in fashion?

It needs to be fast and it needs to be size aware. The economics of the category mean a returned item is often wanted by another customer within days, so the time between the parcel arriving and that size being sellable again is a revenue number rather than a warehouse statistic. Practically that means scanning returns in against the original order, grading on receipt rather than in a weekly batch, putting sellable stock back immediately, routing anything marked or worn to a seconds channel, and making sure exchanges do not reserve the replacement twice. Under Australian Consumer Law, remember that a faulty item is a different conversation from a change of mind, and the system should support both without staff having to interpret policy on the spot.

How long does an apparel integration take and what does it cost to run?

Modelling the range properly takes longer than a generic project, so expect five to eight weeks to a first live channel with correct variants, availability and images, then further channels in stages. Ongoing cost matters as much as build in this category because seasons keep changing the data. Budget for hosting, monitoring, same day response when a channel changes its rules, and a review before each peak trading period. Across integration work of this kind ongoing support tends to run roughly twenty to forty percent of the initial build over time. We quote a fixed build price plus a flat monthly managed fee.

Keep the Grid Intact Across Every Channel

Book a call. We will look at your range structure, tell you what a generic connector would break, and give you a priced plan for doing it properly.