ERP for the Textile Industry: Shade, Lot, Grey Stock and Job Work Under One Roof

Ask the owner of a textile business in Surat, Ahmedabad or Tirupur a simple question — "how many metres of that particular quality, in that exact shade, do you have ready to dispatch right now?" — and watch what happens. Someone is sent to the godown to physically count rolls. A phone call goes to the dyeing unit to find out how much is still lying there for processing. The stock register says one thing, the floor says another, and the shade on this lot does not quite match the shade on that lot, so half of what the register counted cannot actually go against the order. The answer, when it finally arrives, is an educated guess — and the business runs on educated guesses like this all day.

This is not because textile owners are careless. It is because textiles break almost every assumption that ordinary business software is built on. The same cloth is weighed in kilograms as yarn and measured in metres as fabric. A single quality exists in dozens of shades, and every shade exists in separate dye lots that must never be mixed. Most of the value-adding work — dyeing, printing, embroidery, finishing — happens outside your own walls, at job workers, where the material sits on someone else's floor but still belongs to you. Grey fabric and the same fabric after processing are different things at different values. A generic ERP, built around the idea that a product is one SKU with one unit and one price, simply cannot hold any of this.

This article is about what changes when the ERP is built for textiles instead. It walks through the specific quirks of the industry — shade and lot control, grey versus finished stock, meters-to-kilograms conversion, and dyeing and printing job work under GST — and shows, end to end and with a worked rupee case study, how ApicalERP handles the textile value chain from yarn to finished dispatch as one connected system rather than a pile of registers and WhatsApp messages.

Why Textiles Break Generic ERP

Before looking at what a textile ERP does, it helps to be honest about why so many textile businesses are still run on spreadsheets and ledgers long after their peers in other industries have moved on. It is not reluctance — it is that the ordinary ERP they were shown did not fit, and a tool that does not fit is worse than no tool at all.

One material, many units

In almost every other industry a product has a unit and keeps it. In textiles it does not. Yarn is bought and stocked in kilograms. Woven or knitted fabric is made in metres but often costed and traded in kilograms too, because the weight of the cloth is what drives the yarn consumption and the price. Garments are counted in pieces. The same physical length of cloth might be received in kilograms, produced in metres and billed in metres, and unless the system carries the conversion — based on the fabric's weight per metre, its width and the yarn count — purchase, production and sales each count the same cloth differently and never reconcile. A generic ERP forces one unit per item, and so the moment the cloth changes unit the stock stops being believable.

Shade and lot are part of the identity

In a standard ERP, two units of the same SKU are interchangeable; that is the whole point of a SKU. In textiles they are not. Dyeing is a chemical process, and no two dye lots come out exactly identical — fabric from one processing batch can differ in shade from the next by a degree the human eye catches instantly on a finished product. Cut a single garment order from two different lots and the shade variation shows in the seams, and the lot is rejected. So in textiles the quality, the shade and the lot together form the real identity of a stock item, and the ERP must reserve and issue from a single matching lot, not just from "that quality". No generic SKU model can express this.

Most of the work happens outside your walls

Perhaps the biggest break of all: in textiles, a huge share of the value-adding process is outsourced. A weaver sends grey fabric out to a processing house for dyeing and printing. A garment maker sends cut fabric out for stitching and embroidery. The material leaves your gate, has lakhs of rupees of work done to it on someone else's floor, and comes back a different, more valuable item — and throughout, it still belongs to you and sits on your books. This is subcontracting and job work as the main event, not an occasional exception, and it has to be tracked challan by challan under GST. A generic ERP treats outside processing as an afterthought, if it handles it at all.

The Four Quirks a Textile ERP Must Master

Everything that makes textile ERP different from generic ERP comes down to four things the software has to get right. Miss any one of them and the system will drift out of step with the floor within weeks.

Shade and lot control

The first is treating shade and lot as first-class attributes of stock, not as free-text notes. Every roll of fabric and every lot of yarn carries its quality, its shade and its lot or batch number, and the ERP keeps these separate in stock even when they share a quality name. This is really an industry-specific use of batch tracking: stores can see how much of a quality exists in each shade and lot, reserve an order from a single matching lot, and keep enough of one lot together to complete an order without mixing. When a shade complaint comes back from a customer, the lot number traces it straight to the processing batch it came from, so the problem is contained rather than guessed at.

Grey versus finished stock

The second is understanding that grey fabric and the same fabric after processing are two different items at two different values. A textile ERP keeps the grey item and the finished item distinct, and the act of processing — whether done in-house or at a job worker — converts one into the other, consuming the grey and producing the finished while adding the processing cost. This matters for valuation: grey fabric sitting unprocessed is worth a fraction of what the same cloth is worth dyed, printed and finished, and a system that cannot tell them apart will mis-state the single largest number on the balance sheet. Keeping the two stages distinct also lets the business see exactly how much cloth is stuck as grey, how much is out at processing, and how much is finished and ready to sell.

Dual units and conversion

The third is carrying the unit conversions the industry runs on. A textile ERP holds a primary stock unit for each item and the conversion factors that relate kilograms, metres and pieces — typically derived from fabric weight (GSM), width and count — so it can receive in one unit, produce in another and bill in a third while keeping a single reconciled stock. A yarn purchase in kilograms, a weaving output in metres and a sale in metres all tie back to the same material because the system does the conversion instead of leaving it to a mental sum. This single capability eliminates the most common textile stock error of all: the same cloth counted in different units at every stage, never agreeing with itself.

Job work as the main event

The fourth is treating outside processing as a core, tracked flow rather than an afterthought. A textile ERP raises GST job-work challans that move a specific quality, shade, lot and quantity of fabric to a named processor, keeps that stock on your books as material lying at the job worker, and reconciles what comes back against what went out — capturing finished quantity, process loss, the processor's bill and the return clock that ITC-04 is filed from. Because processing is where most textile value and most textile leakage live, getting this flow right is often the single biggest reason a textile business moves to a purpose-built ERP at all.

How the Textile Flow Works Inside ApicalERP

These capabilities only matter if the thread from yarn to finished dispatch never breaks. In ApicalERP the textile flow runs on one database shared with purchasing, job work, GST and accounts, so each step reads and writes the same live stock and the same ledgers.

Yarn in: procurement by count, blend and lot

It starts at yarn and fibre procurement. Yarn is received and stocked by its count, blend and supplier lot, in kilograms, with the quality and the lot recorded against every bale and cone so that a yarn-shade or strength issue can later be traced to the lot and supplier it came from. Because purchasing is part of the same system, the yarn cost, the supplier bill and the GST input all post together, and the yarn stock that production will consume is the same stock the buyer sees. This is ordinary inventory discipline, but applied with the count-and-lot detail that spinning and weaving actually need.

Grey out: weaving, knitting and the unit switch

Yarn is then consumed against a production order to produce grey fabric. Here the first textile-specific thing happens automatically: the system consumes yarn in kilograms and produces grey fabric in metres, carrying the conversion from the fabric's construction — weight, width and count — so the kilograms that went in and the metres that came out reconcile without anyone reaching for a calculator. The grey fabric is created as its own item, with its quality and a grey lot number, valued at yarn plus conversion cost. Whether the weaving is done on your own looms or sent out to a weaving job worker, the output lands as grey stock the same way, so the business always knows exactly how much grey it holds and of which quality.

Processing: the challan round-trip that keeps the stock yours

Grey fabric now goes out for dyeing, printing or finishing. In ApicalERP this is a job-work dispatch: a GST delivery challan moves a specific quality, grey lot and quantity to a named processor, and the ERP keeps that fabric on your books as stock lying at the job worker — it has left your floor but not your balance sheet. When the processed fabric returns, you record receipt against the same challan: the finished metres, the shade and finished lot it has become, the process loss or shrinkage, and the processor's bill. At that moment the system consumes the grey item and produces the finished item at its new, higher value with the processing cost folded in, and it reconciles the quantity that came back against what went out — flagging any shortfall and keeping the return-period clock that feeds compliance and ITC-04 reporting. Nothing about this material ever has to live in a side register or a WhatsApp thread.

Finished stock, order matching and dispatch

Finished fabric is graded and binned by quality, shade and lot. When a sales order is taken, the ERP reserves fabric from a single matching shade and lot, so the order is never cut or dispatched from mixed shades, and it warns when a lot is short of completing the order so stores can plan rather than discover the gap at packing. On dispatch, the fabric is invoiced in the correct unit with the right GST classification, an e-way bill is raised where required, and the true cost per metre — yarn, conversion and processing — lands against the order so the business can see real margin by quality and by customer in the same reports that run the rest of the company. From yarn to dispatch, the cloth has stayed one connected record.

Across the Textile Value Chain

Textiles are not one business but a chain of them, and each link feels these quirks in its own way. A purpose-built ERP serves all of them because the same underlying logic — quality, shade, lot, dual units and job work — flexes to each stage.

Spinning mills

Spinners track fibre and yarn by count, blend and lot, manage blow-room-to-cone production, and carry heavy power and waste costing where a point of realisation on waste moves the whole P&L. For them the ERP's job is accurate lot-wise yarn stock, blend and count management, and costing that captures power and waste honestly against each lot of yarn produced.

Weaving and knitting units

Weavers and knitters live at the kilograms-to-metres boundary. They need beam, warp and greige management, yarn consumption against each sort or design, and clean conversion so that the yarn issued and the grey produced always agree. Much of their dyeing and processing goes out, so job-work tracking is central from the moment the grey comes off the loom.

Processing houses — dyers, printers, finishers

Processing houses are the mirror image: they run largely on inward job-work fabric that belongs to their customers, so they must track whose fabric is whose, by challan, and manage shade, lot and recipe control as their core discipline. For them the ERP has to handle inward job work, recipe and shade management, and billing for process charges — the same job-work flow seen from the processor's side.

Garment and made-up manufacturers

Garment and home-textile makers add the size-colour matrix, lay and cut planning, and bulk stitching and embroidery job work. They need a style to explode into a size-colour-wise plan, fabric reserved by shade and lot for a cutting lay so the whole order is shade-consistent, and cut fabric tracked out to stitching units and back as finished pieces — job work again, one stage further down the chain.

Benefits of a Textile-Built ERP

Implementation Checklist: Getting a Textile ERP to Stick

A textile ERP earns its keep only if the floor actually runs on it. The businesses that get real value approach the rollout in the same handful of steps rather than switching everything on at once and hoping the godown adapts.

1. Fix your item master around quality, shade and lot first

• Define how an item is identified before anything else — quality plus shade plus lot, with grey and finished as separate items — because this structure decides whether your stock will ever match the floor, and it is painful to change later
• Agree the conversion basis for each quality up front, using real GSM, width and count figures, so kilograms and metres reconcile from day one rather than drifting apart as volume builds

2. Map your job-work network into the system

• List every processor, weaver and stitching unit you send material to, with their GST details, so job-work challans and e-way bills generate cleanly instead of being hand-written and later reconstructed
• Decide the standard process loss or shrinkage you expect by process, so the ERP can flag abnormal shortfalls on return rather than letting quiet leakage pass as normal

3. Start the grey-to-finished flow on one quality

• Pick a single high-volume quality and run its full cycle — yarn in, grey out, processing round-trip, finished back by shade and lot — end to end before rolling out to the rest, so the team learns the flow on familiar ground
• Reconcile that one quality's stock against a physical count early, because the first clean match is what convinces the floor the system can be trusted over the register

4. Make the challan the only way fabric leaves the gate

• Insist that no grey or cut fabric goes out for processing without a job-work challan in the system, so stock-at-processor is always complete and nothing moves on a loose slip that never comes back
• Record every return against its challan with finished quantity and process loss, because the data you capture at receipt is exactly what ITC-04 and your costing are built from

5. Put order-to-lot matching in front of sales

• Make reserving fabric from a single matching shade and lot a normal step when an order is confirmed, so shade consistency is designed in rather than checked for at packing
• Review shade-wise and lot-wise stock regularly so slow-moving odd lots are spotted and cleared before they become dead stock gathering dust in the godown

What a Textile ERP Actually Saves: A Worked View

The value of textile-specific ERP is abstract until it is put in rupees. Consider a weaving-and-processing business running grey through outside dyers and printers. Every lot of fabric that cannot be traced when a shade complaint lands is a lot at risk of full rejection; every order cut from mixed shades is cloth and stitching cost lost; every metre that goes out to a processor and comes back short, unnoticed, is material simply gone. Across a year, even a modest rate of shade rejections, mixed-lot losses and unreconciled processing shortfalls adds up to lakhs of rupees of fabric that was paid for and yarn that was spun but never turned into a sale.

Then add the quieter costs. Stock that no one trusts means over-buying yarn and over-producing grey "to be safe", tying up working capital in cloth that sits. Grey and finished valued as if they were the same thing mis-states profit and confuses every pricing decision. GST and ITC-04 reconstructed by hand at return time costs accountant days and risks input-credit on job work. And because true cost per metre is never known, the business cannot tell its profitable qualities from its loss-makers, and keeps running both. The next section shows how this played out for a real business.

Real-World Success Story

Frequently Asked Questions

What is textile ERP software?

Textile ERP software is an ERP whose inventory, production and costing logic is built around the way textiles are actually made and sold, rather than around generic discrete manufacturing. It understands that the same material is counted in kilograms as yarn and in metres as fabric, that a single quality exists in many shades and lots that must not be mixed, that most processing — dyeing, printing, embroidery, finishing — is sent out to job workers rather than done in-house, and that a roll of grey fabric and the same roll after processing are different items at different values. A general ERP treats a "product" as one SKU with one unit and one price; a textile ERP treats quality, shade, lot, width and process stage as the dimensions that define a stock item, so what the system shows matches what is actually lying in the godown. ApicalERP delivers this on the same platform that runs purchasing, job work, GST and accounts, so the textile-specific detail and the financials stay in one database.

How does textile ERP handle dyeing and printing job work?

In a textile ERP, sending grey fabric out for dyeing, printing or finishing is handled as a subcontracting or job-work transaction, not as a sale. You raise a delivery challan under the GST job-work provisions that moves a specific quality, lot and quantity of grey fabric to a named processor, and the ERP keeps that stock on your books as material lying at the job worker. When the processed fabric comes back, you record receipt against the same challan — capturing the finished metres, the process loss or shrinkage, any shade-wise sorting, and the processor's bill — and the system converts the grey item into the finished item at the right value, adding the processing cost. Because it tracks what went out against what came back per challan, it flags shortfalls, keeps the 180-day/one-year return clock for ITC-04 reporting, and builds the data that return has to be filed from — all without the material ever disappearing into a register.

Why do textile businesses need shade and lot tracking?

Because in textiles two rolls of the same quality and the same nominal colour are not interchangeable. Dye lots vary, so fabric from one processing batch can differ in shade from another by a degree the eye catches instantly on a finished garment or a set of curtains. If an order is cut and stitched from mixed lots, the shade variation shows up in the final product and the whole lot can be rejected. Shade and lot tracking means every roll carries the quality, the shade and the lot or batch it belongs to, so stores can pick and reserve fabric from a single matching lot for an order, keep like with like, and trace any shade complaint back to its processing batch. Without it, shade mixing is discovered only after cutting, when the loss is already made; with it, the ERP reserves a matching lot up front and the problem never reaches the customer.

How does textile ERP manage metres and kilograms together?

Textiles are routinely bought, made and sold in different units at different stages — yarn in kilograms, woven or knitted fabric in metres or in kilograms, garments in pieces — and the same physical material can be measured in more than one of them. A textile ERP holds a primary stock unit for each item plus conversion factors, often based on fabric weight (GSM), width and count, so it can convert between kilograms and metres, maintain stock in both, and value and bill in whichever unit the transaction uses. A yarn purchase in kilograms, a weaving job measured in metres and a sale invoiced in metres all reconcile to the same stock because the ERP carries the conversion rather than leaving it to a mental sum or a spreadsheet. This stops the classic textile stock error where purchase, production and sales each count the same cloth in a different unit and never agree.

Which parts of the textile industry benefit from ERP?

Every stage of the textile value chain benefits, because each has its own version of the same problems. Spinning mills need to track fibre and yarn by count, blend and lot and manage heavy power and waste costing. Weaving and knitting units need beam, warp and greige tracking and conversion between kilograms of yarn and metres of fabric. Processing houses — dyers, printers, finishers — live and die by shade, lot and recipe control and run largely on inward job-work fabric belonging to others. Garment and made-up manufacturers need size-colour matrices, lay and cut planning and bulk job work for stitching and embroidery. Fabric and yarn traders need multi-quality, multi-shade stock and fast order matching. The common thread is that a general ERP, built for one-SKU-one-unit discrete goods, cannot express quality, shade, lot, dual units and heavy outside processing — which is exactly what a textile ERP is built to do.

Conclusion

For most Indian textile businesses, the problem was never a lack of effort — it was a system that did not speak their language. Cloth counted in kilograms in one sheet and metres in another, shade and lot carried in people's heads, lakhs of rupees of fabric sitting on fourteen different processors' floors on hand-written slips, and grey valued as if it were finished: these are not failings of the people running the floor, they are what happens when an industry of quality, shade, lot, dual units and relentless job work is forced onto software built for one-SKU-one-unit goods. The gaps get filled with educated guesses, and the guesses quietly cost shade rejections, lost fabric, trapped working capital and margins no one can actually see.

An ERP built for textiles closes those gaps. It makes quality, shade and lot the real identity of stock, keeps grey and finished distinct at their true values, carries the kilograms-to-metres conversion so stock finally reconciles, and treats dyeing and printing job work as a tracked, GST-clean round-trip rather than an afterthought — so the cloth stays one connected record from yarn to dispatch. Shade mixing is designed out, fabric stops disappearing at the dyer, ITC-04 becomes a report, and true cost per metre tells the profitable qualities from the loss-makers. Alongside disciplined lot traceability and sound job-work control, a textile-built ERP is what lets a mill or a processor run on numbers instead of guesses. ApicalERP delivers this as part of the same system that runs your purchasing, GST and accounts. See the full ApicalERP feature set and the manufacturing solution, then let us show you your own textile flow running end to end.