Garment ERP Software: What It Costs, and Why Generic ERP Does Not Fit

A garment ERP phase one runs 1,400 hours across seven modules. At $40 per hour that is $56,000, at $100 per hour $140,000, and about $91,000 at a $65 blended rate. The realistic band across the scopes we see is 1,000 to 1,900 hours, because a domestic maker with no export documents and a single job worker sits well below a vertically integrated exporter.

The reason you are reading a garment-specific number rather than an ERP number is that apparel breaks the assumption every general ERP is built on. There is no flat item master in apparel. There are three levels, and a system that stores one of them cannot cost, count or ship correctly.

Most buyers start by asking which ERP to configure. That is the wrong first question. The right one is whether the system you are considering can represent a style, a colourway and a variant as separate things, because retrofitting that later means re-costing history rather than adding a column — and it moves the number more than any feature on any requirements list.

The ordinary failure is not a failed implementation. It is a stock report that says 4,000 units of a shirt are on hand while the order cannot be filled, because the units left are the sizes nobody ordered.

There is no item master. There are three levels.

A style carries the tech pack, bill of materials, cost sheet and season code. Style and colour together — the colourway — is what the trade calls the SKU, and it is what merchandisers plan at. Only style, colour and size physically exists, so it is the only countable level.

A shirt in 12 colours and 7 sizes is 1 style, 12 SKUs and 84 variants. Denim multiplies faster, because size there is waist by inseam rather than a single letter.

Every number in the business lives at one of those three levels, and most of the arguments inside a garment company are really disagreements about which. A cost sheet is a style-level artefact. A purchase order is usually placed at colourway. Physical stock only means anything at variant. When one system flattens all three into an item master, the arithmetic still runs — it just answers a question nobody asked.

This is the line the drivers list calls highest impact, and it is the one to settle before anyone quotes. Retrofitting style, colourway and variant into a system that stored one item master means re-costing history, not adding a column.

Size curves, and stock that reads healthy but cannot ship

Demand across a size run follows a curve, say 1-2-3-3-2-1. Buy against the wrong one and units remain but not in sellable sizes, so stock reads healthy while the order cannot be filled.

Roll that figure up to style level and the problem vanishes from the report entirely, which is exactly why the stock view has to stay at variant level even when every executive dashboard wants a single number. The aggregate is not a summary of the truth. It is a different claim, and it is usually wrong.

Sellable in apparel means a complete size run, not a total. That distinction is worth building into the stock read itself rather than leaving every caller to reconstruct it. On DoraDori we did not, and it is the first thing we would change: the item summary reports what is on hand without saying whether it is sellable, so each consuming system works that out again, slightly differently.

Fabric cost comes off the marker, not the cost sheet

Fabric is the largest line on most cost sheets, and its number does not come from a price list. It comes off the marker — the nesting of pattern pieces across the cuttable width. Consumption is size dependent, so one figure per garment is already wrong before anything is cut.

Then wastage compounds, and it compounds in five distinct ways: end loss, splice loss, relaxation shrinkage, cutting waste and sewing rejects. Each has a different owner and a different fix. Labour costs separately, in standard allowed minutes against a target line efficiency.

This is why garment manufacturing ERP work lives or dies on cut order and marker software. That is where fabric turns into cost, and a system that treats fabric as a countable item with a unit price has already lost the ability to explain its own margin. Fabric behaves like bulk material: rolls in, issued against a marker, remnants back.

Bundles, shade, and what the floor is actually paid on

After cutting, pieces are numbered and bundled. The bundle ticket is what the floor tracks, and often what an operator is paid on. That makes bundle identity a payroll input, not just a production one, which is a different standard of accuracy.

Shade has to survive the cut as well: every panel of one garment must come from the same dyelot, or the finished piece is a reject whatever the ledger says. A fabric store that tracks metres but not dyelot cannot prevent that, and the loss shows up as a quality problem months after the data problem that caused it.

Whether the floor is tracked at bundle level is one of the high-impact drivers on the estimate, and it is a genuine choice rather than a default yes. Bundle-level tracking earns its cost when you pay piece rate or when quality disputes need tracing to an operator and a dyelot. It is expensive theatre when neither is true.

Generic ERP posts one variance. Apparel needs five.

A general ERP posts one material variance against the order. Apparel needs five, because end loss, splice loss, relaxation shrinkage, cutting waste and sewing rejects have different owners and different remedies. A combined figure tells nobody which to work on, which is the practical reason a merchandiser stops trusting the system and goes back to a spreadsheet.

This is the clearest example of why configuring a general platform is not cheaper here. Three levels, a size dimension and yield-driven costing touch the item master, the stock model and the costing engine at once. Bolting them on forces those changes onto a product with no use for them, and you end up patching two codebases instead of one while tenancy, access control and deployment get solved again rather than inherited.

Job work: goods that move without a sale

If you send fabric out to a job worker, your ERP has to issue a document that carries quantity and value but posts no revenue — and most generic systems simply cannot.

Under Section 143 of the CGST Act, a principal sends inputs or capital goods to a job worker without paying tax. They travel on a delivery challan under Rule 45, not an invoice. Returns are declared in ITC-04, half yearly above ₹5 crore aggregate turnover and annually at or below it, and inputs have one year to come back.

The rates carry their own trap. Textile and apparel job work sits at a concessional 5 percent under SAC 9988, while residual job work moved to 18 percent under the two-slab change effective 22 September 2025. Garments are 5 percent up to ₹2,500 per piece and 18 percent above. The threshold is per piece, so one invoice line can cross it while the line beneath it does not, and the rate has to resolve from unit price at posting rather than from a customer or a product group.

E-invoicing applies from ₹5 crore aggregate annual turnover, and since 1 April 2025 taxpayers at ₹10 crore and above have 30 days to report a document to the IRP, after which no IRN is issued. E-way bills are needed above ₹50,000 — including challan-based job work movement, which most generic ERPs never emit.

Number of job work stages and vendors is a high-impact driver for exactly this reason: each stage is a movement that must reconcile, with its own document, its own clock and its own rate resolution.

Phase one, module by module

Here is the whole estimate, with every line inside its own published range so you can move any of them and see the effect.

Module	Worked example	Published range
Style, colourway and variant model	140 h	120 to 260
Costing, BOM and the five variances	260 h	220 to 460
Cut order, lay, marker and bundle identity	240 h	220 to 460
Job work challans and reconciliation	220 h	200 to 420
Fabric store, dyelot, shade and remnants	180 h	160 to 340
Valuation, GST and export documents	180 h	180 to 400
Reporting, admin and integrations	180 h	160 to 360
Total	1,400 h	realistic band 1,000 to 1,900

What moves you between 1,000 and 1,900 hours is rarely the module list. It is the shape of the business underneath it. A domestic maker selling to two buyers, with one job worker and no export paperwork, lands near the bottom: the valuation and export documents module shrinks toward its floor and job work reconciliation stays simple. A vertically integrated exporter shipping to buyers who each impose their own document formats, running six job work stages across three vendors and tracking the floor at bundle level, lands near the top on four modules at once. Ask which of those two you are before reading any total, including this one.

Three things are deliberately outside that number, each its own decision: shop floor terminals and bundle scanning, a channel or B2B selling surface, and any migration of more than one season of history. Recurring rather than build: hosting, and the GSP or accredited provider fees for filing and transmission, which are per document and belong in your operating cost.

What moves the number most

Seven drivers, and the feature list is not among them.

Whether the three-level model already exists is the highest impact, for the reasons above. The number of job work stages and vendors is high, because each is a reconciling movement with its own document and clock. Whether the floor is tracked at bundle level is high and is a real choice. Fabric complexity — dyelot, shade and remnants is high, and is what separates a maker running two fabrics from one running two hundred.

Integration count, and whether Tally is one of them, is medium. Export document formats per buyer is medium, and scales with how many buyers impose their own paperwork rather than with volume. Historic data migration and its unit consistency is variable, and the word doing the work there is consistency: a season of history in mixed units costs more to migrate than three seasons in consistent ones.

Valuation deserves a specific warning, because it is where errors hide. Closing stock has to cover work in progress mid-line with partial labour absorbed, goods sitting at a third party, and fabric in transit. Consumption should post at actual issue against a cut order. Backflushing on finished goods receipt back-calculates from standard and erases every yield variance the season had to teach you — which is to say it destroys the exact data the five variances exist to produce.

Build, buy, or keep your books where they are

The split that works is narrower than most buyers expect, and it is not all-or-nothing.

Keep your accounting where it is. On DoraDori, accounting reconciles against Zoho and commercial records against an internal CRM, so the ERP holds the physical truth and neither of the others has to be rebuilt inside it. Cheersagar runs the same shape: books in Zoho, relationships in an internal CRM, with the layer between them built on FastAPI and PostgreSQL.

Build the apparel layer. The item hierarchy, costing engine, cut order and marker handling, job work reconciliation and fabric valuation are where your business differs from every other manufacturer, and they are exactly what a general platform forces you to approximate.

Decide the boundary once, and write it down. The second thing we would change on DoraDori is the Zoho boundary: it was drawn once early and never revisited, so a handful of figures have two plausible homes and which one is authoritative became convention rather than design. When a figure is disputed the ERP is not automatically the winner, and knowing which system settles which question is part of running it.

If you are a group running several apparel businesses, the tenancy decision arrives early. Stylebank runs four on one Django codebase, each with its own database, S3 bucket and Redis namespace. The cheap option is a tenant column on every table, which holds until one query misses the filter and a company reads a rival's cost sheet. Isolating by database makes it an infrastructure problem instead, and buys per-company restore, retention and job windows.

Where garment ERP builds fail

Not in the modules. In four assumptions made before anyone writes code.

The item master is flat, so every cost and count answers a question nobody asked, and the fix is a re-costing of history rather than a migration. The floor is paid on bundles the system does not track, so payroll and production disagree and the spreadsheet that reconciles them becomes load-bearing. Consumption is backflushed from standard on finished goods receipt, which erases the yield variance that was the entire reason for building a costing engine. And job work is treated as a stock transfer, so the challans, the ITC-04 returns and the e-way bills above ₹50,000 never get emitted and the compliance gap surfaces at an audit.

A fifth one arrives later, and only for groups: history tables grow faster than anyone plans for. A row per style per day per channel per metric compounds quietly and nothing in the application tells you. You find out when a backup stops fitting its window, or when an ALTER becomes an outage rather than a migration. Archiving buys time; the structural fix is to stop mixing an append-only fact stream with operational state.

Every one of those is visible in discovery, which on ERP work is mostly an inventory of what the floor already does and in what units. None of them is visible in a feature list, which is why we do not quote from one.