Odoo for apparel manufacturing: what fits out of the box, and what does not

Two answers get given to “can Odoo run a garment factory”, and both are wrong.

The first is yes, it is a manufacturing ERP, of course it can, which is true right up until the merchandiser asks where the lab dip approval goes. The second is no, apparel is too specialised, which is how factories end up buying a closed vertical system that does the T&A beautifully and hands them back payroll, purchasing and accounts as somebody else’s problem.

The useful answer is a list. Here is what stock Odoo already does for an apparel factory, what it has no concept of at all, and what the difference means for the cost and shape of an implementation.

What Odoo gives you before anyone customises anything

More than people expect. A working apparel installation runs on a wide base of standard applications, all on one database:

The consequence of that list matters more than the list itself. A manufacturing order, the payroll run of the operator who worked it, the purchase order for the fabric that went into it and the customer invoice at the end are the same records in the same database, not five systems reconciled at month end. That is the argument for Odoo in apparel, and it is a strong one. Most dedicated apparel systems stop at production and leave the other four to you.

Specifically, out of the box and with no custom code, Odoo handles:

• Multi-level bills of materials with sub-assemblies, which is how a jacket with a separately-constructed lining is actually built.
• Work orders against work centres, with a shop-floor interface operators can use.
• Product variants on attributes. Colour and size are a native concept, not a workaround.
• Quality control points attached to operations, with checks and failures recorded.
• PLM change orders, meaning engineering change on a BoM with an approval trail.
• Purchasing, receipts and three-way matching against supplier bills.
• Full double-entry accounting, bank reconciliation, tax reporting and aged receivables, posting as transactions happen rather than at month end.
• Payroll and attendance, which in a factory of several hundred operators is not a small module.
• Maintenance scheduled by asset, so a cutting machine is serviced on a plan.

What that looks like in a working installation

Our own apparel reference system is not a slide. It is an Odoo 19 database with 317 modules installed, 33 of them applications, carrying 174 product templates across 278 variants, 72 bills of materials, 291 manufacturing orders, 550 work orders, 362 purchase orders, 727 stock pickings, 213 quality checks, 14 PLM change orders, 41 employees and 610 invoices, plus 12 styles with 223 critical-path tasks and 120 dependencies between them.

The point of quoting those numbers is not the numbers. It is that every one of them lives in the same database. The purchase order for the fabric, the manufacturing order that consumed it, the payslip of the operator who sewed it and the invoice that billed it are joined records, not four exports someone reconciles.

If your requirement stops at “make the garments and account for them”, stock Odoo with a careful configuration will do it, and you should be sceptical of anyone selling you custom modules to achieve it.

What Odoo has no concept of

Now the other list. These are not things Odoo does badly. They are things it does not model at all, because no general manufacturing ERP does.

1. The calendar before the production order

Odoo’s manufacturing world begins at the manufacturing order. A garment order begins sixty to ninety days earlier, at a tech pack, and passes through costing, fabric booking, trims booking, lab dips, lab dip approval, proto sample, fit sample, fit approval, bulk fabric in-house, bulk trims in-house, PP sample and PP approval before cutting is authorised.

That is nineteen steps of a twenty-one-step programme, and Odoo has a place for none of them. Projects and tasks look like a candidate until you need dependency lags, milestone anchoring, working calendars and float. At which point you are writing a critical-path engine, which is what a Time and Action system is, and it is the first of the things an apparel ERP has to cover before it is worth buying.

This is the single largest gap, and it is the one that decides ship dates.

2. Wastage

Fabric wastage is the largest controllable cost in cutting and stock Odoo has no field for it anywhere. A BoM line says thirty metres; the floor consumes 32.4. Without a wastage percentage that recalculates consumption, plus a category maximum and an approval workflow when someone exceeds it, the difference is absorbed as unexplained variance and argued about later.

3. Sourcing at component level

Odoo holds supplier, lead time and price on the product. In apparel the bill of materials is a sourcing document: shell fabric, lining, zipper and main label each come from a different mill or trim house with a different lead time, and a component used in two styles may be sourced two different ways. That information has to sit on the BoM line, and out of the box there is nowhere to put it.

4. Routing, since version 14

Odoo removed the v13 routing concept, so every BoM now owns a private copy of its operations. Three hundred styles that all get cutting, sewing, finishing and packing produce twelve hundred near-identical routing rows, and changing the standard cutting time means editing three hundred records. For a factory with a stable set of operations and a large style catalogue this is a genuine maintenance problem, not a cosmetic one.

5. Split deliveries by line

A garment order rarely ships once. Sizes, colourways and destinations go out on different dates against one buyer PO. Odoo puts the delivery date on the order, not the line, so one order produces one delivery, and the rest gets produced by hand.

6. Costing that locks

Odoo has spreadsheets and it has good ones. What it does not have is a costing sheet that attaches to a style, pulls live BoM and price data, runs through an approval state and then becomes read-only, with edits branching a numbered version rather than overwriting. Without that, the number quoted to a buyer is editable by anyone who can open the file.

7. Codes the system issues

Internal references in Odoo are typed by whoever creates the product. In a factory that wants codes generated from a category prefix, locked once issued and never reused, that is a rule the system has to enforce. Otherwise it is a convention, and conventions decay.

8. Reusable variant matrices

Colour and size attributes are native. What is not native is a reusable matrix: define a size run and colourway set once, then apply it to every style in the season. Without that, rebuilding the matrix by hand per style is the most repetitive job in setting up a season.

How the gap actually gets closed

There are three honest ways to close a gap like that, and they cost very different amounts.

Configuration. Free, fast, and correct wherever it works. A great deal of an apparel implementation is configuration: product categories, attribute sets, work centres modelled as the operators and machines they actually are, quality control points, warehouse routes. Anyone quoting custom development for these is padding.

Studio. Odoo’s low-code layer. Genuinely useful for a field here and a view there, and a liability if it becomes the strategy. Studio changes are hard to review, hard to test, and they are the first thing that breaks on a version upgrade. Use it for the last five per cent.

Custom modules. Proper Odoo modules, in version control, with tests. This is what the eight gaps above actually require. It is the expensive option and it is the right one for anything that has to survive an upgrade, which is everything on that list, because every one of them touches how the business runs rather than how a screen looks.

Our own apparel ERP is nine custom modules on top of Odoo 19 Enterprise: one for the critical path and Time and Action calendar, and eight covering wastage, material codes, BoM-line sourcing, variant templates, per-line delivery dates, costing sheets, sample attributes and a shared standard-operation library. That is the honest size of the gap between “manufacturing ERP” and “apparel ERP”. It is not a configuration exercise, and it is not a rewrite either.

What this means for your project

Three practical consequences.

Do not pay to rebuild what is already there. If a proposal includes custom development for accounting, payroll, purchasing, quality checks or maintenance, ask why. Those are configured, not built.

Do insist that the apparel layer is modules, not Studio. Ask which parts of the solution are custom modules under version control and which are Studio customisations, and ask what happens to each at the next major version. The answer tells you what the second year of ownership will look like.

Community or Enterprise is a real decision. A well-written critical-path module can depend only on base, mail, sale, product and resource, and therefore run on Community. The Gantt view cannot. Gantt is an Enterprise widget, and a Gantt-dependent design forces the Enterprise licence whether or not you wanted it. If licence cost matters, ask specifically which features would disappear on Community, and get the answer in writing.

Three ways implementations go wrong

Buying the vertical and inheriting five systems. A closed apparel package usually does the merchandising calendar well. Then you discover it does not do payroll, or accounts, or purchasing, or maintenance, and you buy four more products and pay somebody to keep them talking. The integration budget is rarely in the original comparison, and it never ends - it belongs in the cost of the implementation from the start.

Buying the ERP and being told the calendar is “phase two”. The pre-production calendar is not a nice-to-have that can wait for a later phase. It is the reason a factory wanted a system in the first place. If it is deferred, merchandisers keep the spreadsheet through go-live, the spreadsheet becomes the real system, and the ERP becomes a data-entry chore performed after the fact. Very few projects recover from that.

Customising by accretion. The most expensive apparel implementations we have seen are not the ones with the most custom code. They are the ones where nobody decided what was custom. A Studio field here, a server action there, an automation nobody documented, and eighteen months later the upgrade to the next major version is quoted as a re-implementation. Decide the boundary early: modules for anything that changes how the business runs, configuration for everything else, Studio for the last five per cent and nothing structural.

If you are still deciding whether Odoo is the right base at all, what Odoo covers as an ERP is the wider picture.

Questions worth asking your Odoo partner

• Which parts of this are configuration, which are custom modules, and which are Studio?
• Are the custom modules in version control, and do they have tests?
• Which of them would break on Community, and which need Enterprise?
• What happens to each customisation at the next major version, and who pays for that?
• Show me the pre-production calendar working, today, in your demo. Not a mock-up.
• What does your team do when a task has been blocked for three days and nobody noticed?

The short version

Odoo covers the factory and the business around it, meaning production, quality, stock, purchasing, accounts, payroll and maintenance, better than most dedicated apparel systems, because those are the things ERPs were built for. It covers merchandising, the pre-production calendar and the apparel-specific economics of fabric not at all, because no general ERP does.

An apparel ERP built on Odoo is that base plus a deliberate, versioned layer over the eight gaps above. Anything less is a manufacturing ERP with a garment logo, and your merchandisers will keep the spreadsheet.