Apparel ERP in Sri Lanka: what it has to cover before it is worth buying

Ask a general-purpose ERP where a garment order begins and it will tell you: at the production order.

Ask a merchandiser and you get a different answer. By the time a production order exists, the order is two months old. The fabric was booked seven weeks ago. Three samples have gone to the buyer and come back. The one question anyone still cares about, which is whether this ships on the vessel it was sold against, was settled weeks earlier by a chain of events the ERP never saw.

That gap is what this article is about. An apparel ERP is not a manufacturing ERP with garment words on the buttons. It is a system that can hold the sixty to ninety days between a tech pack landing in an inbox and a container leaving the yard, and tell you today whether that date is still real. Whether it is sold to you as garment ERP software, apparel management software or an ERP for garment manufacturing, that is the test.

If you are buying one in Sri Lanka, there is a second half to the requirement that almost nobody writes about, and it has nothing to do with sewing. We will get to it.

Why Sri Lankan garment factories are shopping for ERP in 2026

Some context, because it changes what you should be shopping for.

2025 was a record year. Apparel exports crossed five billion dollars for the first time, finishing at $5.30 billion. That is 40.68% of the country’s entire export revenue, across roughly 350,000 direct jobs.

2026 has been harder. Exports for January to April fell 7.47% to $1.53 billion. The UK was down almost 17%, the EU nearly 9%. And the US tariff position moved twice in fifteen months: a 44% rate under the IEEPA measures from April 2025, then a 10% rate applied from July 2026. The US takes something close to 40% of what this country ships.

Nobody buys an ERP because of a tariff. But the second-order effects are exactly the things software either helps with or doesn’t. Buyers hedging between Colombo, Ho Chi Minh City and Tiruppur place shorter orders and ask for shorter lead times. Margins that survived a comfortable year do not survive a thin one. And when a costing is wrong by four per cent, you find out at the end rather than the beginning.

Compressed lead times make float valuable. Thin margins make costing and wastage valuable. That is not a sales pitch, it is just what happens to the arithmetic.

Trade figures, tariff rates and GSP+ terms in this article are current as of September 2026, and every one is linked to its source. They move. Check the source before you put a number in a board paper.

What an apparel ERP has to cover: the calendar before production

Nineteen steps happen before a machine turns on. Take the shortest real programme in the trade: a standard T-shirt on a sixty-day lead time. Twenty-one steps. Nineteen of them happen before the first machine turns on.

A jacket on ninety days is the same shape with ten days of lab testing wedged into the middle, because water resistance and insulation values have to be certified before bulk is authorised.

Look at where the time actually goes. Cutting, sewing and finishing take the last eighteen days, and that is the part a manufacturing ERP models beautifully. Everything before them is sourcing, sampling, and waiting for somebody in another country to answer an email.

That is where orders are lost. And most ERPs cannot see any of it.

So the first test is blunt. Can the system hold a plan that starts sixty days before a production order exists, and does anything useful with it? That question applies equally to a dedicated garment ERP and to an apparel layer built on a general platform such as Odoo.

Time and Action planning: float and the critical path

Float, not a red cell. Every factory here already has a Time and Action calendar. Usually a spreadsheet, one tab per style, kept by a merchandiser who is also chasing four other things. It works, in the sense that it records what should have happened and turns a cell red when it didn’t.

A red cell tells you a step is late. It does not tell you whether this late step will cost you the vessel. Those are different questions, and the distance between them is called float.

Float is how many working days a step can slip before something downstream slips. Two kinds are worth having. Total float is how many days it can slip before the delivery date moves. Free float is how many before the next step moves.

A lab dip approval running three days late with eleven days of total float is an annoyance. The same three days on a step with zero float has already moved your ship date, and nobody will find out for a month. In the spreadsheet, both cells are the same shade of red.

Getting float requires a genuine critical-path calculation: a forward pass for the earliest each step can happen, a backward pass for the latest it can happen without moving delivery, and the chain of zero-float steps between them. It also needs the four dependency types the trade actually uses: finish-to-start, start-to-start, finish-to-finish and start-to-finish, each with a lag in days. “Trims sourcing starts when fabric sourcing starts” and “bulk trims must land before bulk fabric finishes” are both real constraints, and neither is a plain finish-to-start.

And it has to run on working days. A plan that schedules a five-day lab dip submission across the Sinhala and Tamil New Year is not a plan. More on the calendar below.

Worth separating two things that get conflated in demos. The T&A calendar answers whether a style can make its date. Sequencing styles across sewing lines against real capacity is a different problem, and the one apparel production planning solves. A system that does the first well and not the second is still worth having. One that claims both and does neither is not.

Ask the vendor to show you a style where the ex-factory milestone carries negative float, and ask what the system did about it. A tool that can only report a task as overdue will have nothing to say. One that has calculated the path will tell you this style ships four working days after the date it was sold against, and show you the chain of steps that caused it.

Fabric wastage management in an apparel ERP

Wastage has to be a number the system knows. Fabric is the largest controllable cost in a garment factory. Standard ERP has no concept of wastage at all.

A bill of materials says thirty metres. The floor consumes 32.4. The difference is real money, it is different for every fabric and every marker, and in most factories it lives in the cutting manager’s head.

Wastage has to be a real field, and it has to be hierarchical, because that is how factories govern it:

• a category maximum, so nothing under “knit fabric” exceeds it without approval
• a product percentage, flagged automatically when it goes over the category maximum
• a BoM line percentage that recalculates what gets consumed, where consumption = base quantity × (1 + wastage % ÷ 100), so thirty metres at 8% becomes 32.40
• a manufacturing order that inherits those percentages and scales them properly when the batch is doubled or halved
• a purchase order line percentage, with the option to block confirmation when it exceeds the product maximum

Plus an approval workflow around the override. The point of a maximum is that exceeding it is a decision somebody makes and signs for, not something that happens quietly on a Tuesday.

In the demo, change a wastage percentage on one BoM line and watch the consumption quantity on the manufacturing order. If wastage is a text note, a column in a report, or “something we can add in Studio”, it is not modelled.

Hold on to this one. It comes back in the customs section, where it stops being an accounting nicety and starts being a compliance document.

Garment costing and costing version control

A costing has to survive being agreed. Garment costing lives in spreadsheets and probably always will, because a costing sheet is genuinely the right tool for the job. The spreadsheet is not the problem. The problem is that it sits on somebody’s laptop, quotes fabric prices that were true in March, and can be edited after the number has gone to the buyer.

The fix is to move the spreadsheet inside the ERP rather than replace it. That buys three things a loose file cannot:

Live data. Fabric prices, BoM consumption after wastage, labour minutes and on-time performance pull from the database and refresh, instead of being pasted in and quietly ageing.

A sheet attached to what it costs. Not Style 4471 costing final v3 (2).xlsx in a shared drive, but a sheet hanging off the style, visible to exactly the people who can see that style.

Approval that locks. Draft to approved; an approved sheet is read-only, and editing it branches a numbered version rather than overwriting the old one.

That last one has become considerably more interesting in the last eighteen months. Consider what the tariff swing did to the arithmetic. An order costed under a 44% duty assumption and one costed under 10% are different businesses. If a buyer comes back in November and asks why the price moved, you want to open the sheet as it stood when you quoted it, with the assumptions it carried, rather than reconstruct the argument from memory.

So the question for the vendor is not “do you have costing”. It is: what happens when someone edits an approved costing? If the answer is “it saves”, that is a file store, not a costing system.

Costing is also where a merchandising team spends judgement rather than time, which is why it is the first place AI merchandising earns anything. The sequence matters though: govern the sheet first, automate on top of it second.

Sourcing, split deliveries and the modules that decide adoption

None of these unglamorous things win a tender. All of them are why a system either gets adopted or gets worked around inside a month.

Sourcing on the BoM line, not the product. Shell fabric, lining, zipper and main label come from four suppliers with four lead times, and the longest of those is what decides whether the calendar is achievable. Standard ERP holds supplier data on the product, so a component used in two styles cannot carry two sourcing plans. It has to live on the line.

Per-line delivery dates. A garment order rarely ships in one go. Sizes, colourways and destinations go out on different dates against one buyer PO. If the system produces one delivery per order, somebody will produce the rest by hand.

A shared operations library. Odoo dropped the old routing concept in version 14, so every BoM now owns a private copy of its operations. Three hundred styles that all get cutting, sewing, finishing and packing become twelve hundred near-identical rows, and changing the standard cutting time means editing three hundred records.

Codes the system issues. Every fabric, trim and finished good needs a code. In most factories it is invented by whoever creates the product. Generate it from a category prefix, lock it once issued, and never reuse it, so a deleted variant’s code does not resurface six months later on a different garment.

What makes an apparel ERP in Sri Lanka different

Everything above is true of apparel anywhere: Dhaka, Tiruppur, Ho Chi Minh City. This section is not. These four are specific to running a factory here, and in our experience they are the requirements that get discovered late, after the software has been chosen.

Export material reconciliation under inward processing

Your duty-free fabric is a reconciliation, and it lands on the ERP. If you import fabric and trims under inward processing, relief from duty is conditional. The materials came in without fiscal levies on the basis that they leave again as garments. Proving it is the exporter’s job. A direct exporter closes the loop with export declarations, shipping documents, evidence of inward remittance, and a Material Utilization Declaration. An indirect exporter works through certified goods received notes from the enterprise that took delivery.

Read that as a software requirement and it says something specific: the system has to be able to state, per export shipment, how much of which imported material went into it, wastage included.

That last clause is where it gets awkward, and it is why the wastage section above matters more here than it would elsewhere. If your BoM says thirty metres and the floor consumed 32.4, the declaration has to reflect what was consumed, not what was planned. A system that models consumption as a flat BoM quantity cannot produce that number.

What happens next is entirely predictable. Somebody rebuilds the reconciliation in Excel every month, pulling numbers out of the ERP and adjusting them by hand. And that spreadsheet, not the ERP, becomes the document Customs is looking at.

Ask a vendor to show you material consumption by export shipment, with wastage included. It is a boring question and it separates the field fast.

GSP+ rules of origin and component-level traceability

Rules of origin are a data problem before they are a policy problem. Sri Lanka has GSP+ access to the EU. It uses somewhere between 49% and 59% of it.

The reason is well known in the trade: the EU’s rules of origin want the garment made from the yarn stage domestically, and the local fabric base cannot supply that, so a large share of orders run on imported fabric that does not qualify. Solving that properly means investment in the yarn and fabric base, or regional cumulation, or a negotiation. It is not something anyone buys software to fix.

But there is a narrower question that is a software question. Do you know, at the point of costing, which orders qualify?

That requires origin to be carried at component level, on the BoM line alongside the supplier and the lead time, and carried through to the finished style. Most factories can answer it eventually, with effort, for one order. Far fewer can answer it across a season while quoting.

Worth knowing that the goalposts are moving. The EU adopted new GSP+ rules in May 2026, with tighter obligations from 2027, a review cycle stretched from two years to three, and an urgent withdrawal mechanism for non-compliance. Current preferences run to the end of 2028. None of that is settled, which is an argument for holding the data properly rather than assuming the present arrangement is permanent.

EPF, ETF and the Sri Lankan working calendar

Two things a system configured for a European factory gets wrong: payroll, and the calendar the scheduler runs on.

The payroll side is straightforward but non-negotiable: EPF at 12% employer and 8% employee, ETF at 3% employer, the Factories Ordinance limit of eight hours a day and forty-five a week, overtime at a premium, and a private-sector minimum wage that moved to Rs 30,000 a month from January 2026. On a floor of several hundred operators, payroll is not a small module bolted on at the end. It is one of the two systems people notice immediately if it is wrong, and it is why we treat HR and payroll as part of an apparel ERP rather than a separate purchase.

The calendar side is subtler and does more damage. Weekends, poya days every month, both new years, and your own shutdown. A critical-path engine that schedules on a Monday-to-Friday Western calendar will hand you dates you cannot hit, and it will do it confidently. Ask specifically how the working calendar is defined and whether the scheduler actually uses it, because the answer is often “there’s a holiday calendar in the system”, which is not the same thing.

Delay tracking: twenty reasons a garment order goes late

Four of them weigh more here than elsewhere. Any system worth having lets you tag a delayed step with a reason, because “we were late” is not a finding. Grouped, the honest list runs to about twenty:

Four of those carry more weight here than they do in the buyer’s country: material held at customs, LC and payment delays, power outages, and holiday closures. If the system cannot tag a delay with a reason, it cannot tell you at season end that you lost thirty days to fabric delivery and twenty to waiting for buyer approval. Without that number, every post-mortem is a meeting where departments blame each other.

What an apparel ERP will not fix

Worth saying plainly, because you will hear the opposite from people selling one.

Software will not move a tariff. It will not build a domestic yarn base, or get you GSP+ qualification on an order that is made from Chinese fabric. It will not make a buyer approve a lab dip faster, and it will not stop them changing a colourway in week six.

It will not fix a capacity problem either. If you have committed more minutes than your lines can produce, a planning system tells you that sooner and in more detail, which is genuinely useful. But the overcommitment is still there in the morning.

And it will not survive a factory where nobody enters data. Every one of these systems is a bargain: the floor and the merchandising team put information in, and in exchange the business gets to see itself. Factories that skip the first half get an expensive filing cabinet, which is why how an implementation is actually run matters more than whose logo is on the software.

What it does do is smaller and more specific. It tells you a ship date is at risk while there is still time to act. It makes wastage a governed number instead of an argument. It keeps the costing you quoted. And it can produce the consumption figures the customs reconciliation needs without a month-end spreadsheet exercise.

That is a narrower claim than most brochures make. It is also the one we can stand behind.

How to evaluate an apparel ERP vendor: ten demo tests

Bring these to every vendor on your shortlist, ours included.

1. Show me a style plan that starts at tech pack, not at the production order.
2. Show me the float on the ex-factory milestone, and what happens when a step slips.
3. Change a wastage percentage in front of me and show me the consumption change.
4. Edit an approved costing sheet and show me what the system does.
5. Show me material consumption by export shipment, with wastage included.
6. Show me where component origin lives, and how I would find the qualifying orders.
7. Show me a component with two different suppliers on two different styles.
8. Show me one order shipping on three dates.
9. Show me the working calendar the scheduler is using, with poya days in it.
10. Show me where the twenty days we lost to buyer approvals last season would appear.

Number ten is the real one. Anything can record a date. The question is whether the system will tell you, without being asked, that a style is going to be late, and whether afterwards you can prove whether you planned badly or executed badly. Those are different problems with different fixes, and most factories cannot tell them apart.

If the answer to half of these is “we can customise that”, you are not being sold an apparel ERP. You are being sold a manufacturing ERP and a project to turn it into one, and you should price it that way.

Evaluating an apparel ERP in Sri Lanka?

Take the ten tests above to whoever is on your shortlist. If you would like to run them against ours, book a demo and we will work through them on a real garment workflow rather than a slide deck: a style plan from tech pack to ex-factory, float on the milestone, a wastage change flowing into consumption, and material consumption per export shipment.

Beaver Hub is a Sri Lankan software company and an Odoo implementation partner. We build Sewdoo, an apparel ERP that is Odoo Enterprise with a purpose-built garment layer on top: nine custom modules covering the critical-path engine, fabric wastage, material codes, component-level sourcing, per-line delivery dates and costing sheets. Everything in this article is a requirement we have had to meet, not a feature list we admire.