Yarn Count Conversion in Odoo: Ne, Nm, Tex and Denier Without Spreadsheets

A 40s cotton yarn is 14.76 tex. Your spinner quotes it in Ne, your European buyer asks for Nm, and the polyester supplier invoices filament in denier. Each one describes the same physical property: how much a fixed length of yarn weighs.

The global textile yarn market was worth USD 117.00 billion in 2025 and is forecast to reach USD 170.32 billion by 2034 (Fortune Business Insights). It still runs on four count systems that don't share a direction. In two of them, a bigger number means a finer yarn. In the other two, a bigger number means a coarser yarn.

So where does the conversion happen in most mills? In a spreadsheet, retyped at every stage. One wrong cell can change a purchase price comparison, a warping BoM and a customer quote at once. This guide gives you the yarn count conversion formula for each system, then shows how to build it into an ERP for the textile industry on Odoo so it runs once, from one stored value.

Key Takeaways

• Every count system converts through tex: Ne = 590.54 ÷ tex, Nm = 1,000 ÷ tex, denier = 9 × tex (
• Odoo's units of measure can't express count, because count is a reciprocal relationship, not a ratio. It needs a custom module.
• Store tex once per yarn product, compute the rest, and keep the supplier's or customer's original wording on the document.
• Compare yarn prices per length, not per kg. The gap between two quotes can shrink by almost half.

What is the yarn count conversion formula for Ne, Nm, Tex and Denier?

All four yarn numbering systems measure linear density, and every one converts through tex. ASTM D2260 sets the factors: cotton count (Ne) = 590.54 ÷ tex, Nm = 1,000 ÷ tex and denier = 9 × tex (ASTM D2260). Its own worked example puts 30 tex at about 19.7 Ne.

Each yarn count formula, ready to use:

• Ne to tex: tex = 590.54 ÷ Ne
• Tex to Ne: Ne = 590.54 ÷ tex
• Tex to denier: denier = tex × 9
• Denier to tex: tex = denier ÷ 9
• Denier to Ne: Ne = 5,314.9 ÷ denier
• Ne to Nm conversion: Nm = 1.6934 × Ne
• Nm to tex: tex = 1,000 ÷ Nm

Direct and indirect yarn count systems

The split that matters is direct versus indirect:

Direct systems measure weight per length. Indirect systems measure length per weight. That's why 40s cotton is finer than 30s, while 20 denier is finer than 70 denier.

Yarn count conversion table

Here are the equivalents for common English cotton counts, calculated with the ASTM constant:

One more catch. "Ne" usually means cotton count, but worsted count uses a different hank. ASTM gives worsted count as 1.5 × cotton count (ASTM D2260), so a 30s worsted and a 30s cotton aren't the same yarn. Your count master has to record which convention a supplier uses.

Why can't Odoo's units of measure handle yarn count?

Odoo converts units through a reference unit and a ratio, and only "if both units belong to the same category" (Odoo documentation). A centimetre is the metre divided by 100. That model works for kg and grams, or metres and yards.

Count breaks it twice. First, count isn't a quantity at all. You never hold "40 Ne" of stock; you hold 500 kg of 40s yarn. Second, Ne and tex are reciprocals. Doubling tex halves Ne, and no fixed ratio can express that. Try to set Ne up as a unit of measure and the maths fails at the first conversion.

In our experience, that's why mills end up creating separate products for "30s", "30 Ne" and "19.7 tex", or putting the count in a variant attribute. Both store the label. Neither stores the relationship, so nothing downstream can calculate with it. We cover the wider yarn-to-fabric picture in our Odoo guide for textile mills; this post zooms in on the count layer underneath it.

How should yarn master data be structured in Odoo?

Store one number, tex, and compute the rest. Because ASTM defines exact factors between the systems (ASTM D2260), a single stored tex value can generate Ne, Nm and denier without drift. If two fields can be edited on their own, they'll disagree eventually.

A yarn product in this design carries:

• linear density in tex (the one stored source value)
• fibre and blend composition, for costing and QC
• the count convention the supplier uses (cotton, worsted)
• computed fields for Ne, Nm and denier

Stock still sits in kg. Count describes the yarn; kg measures how much of it you hold. Keep the two apart and inventory valuation stays clean.

Here's the pattern we use in custom Odoo modules. Field names will change per project, but the structure holds:

from odoo import api, fields, models

# ASTM D2260: cotton count (Ne) = 590.54 / tex
NE_PER_TEX = 590.54


class ProductTemplate(models.Model):
    _inherit = "product.template"

    yarn_tex = fields.Float("Linear density (tex)", digits=(12, 4))
    yarn_ne = fields.Float(
        "Count (Ne)", compute="_compute_yarn_counts",
        inverse="_inverse_yarn_ne", store=True, digits=(12, 2),
    )
    yarn_nm = fields.Float(
        "Count (Nm)", compute="_compute_yarn_counts",
        inverse="_inverse_yarn_nm", store=True, digits=(12, 2),
    )
    yarn_denier = fields.Float(
        "Denier", compute="_compute_yarn_counts",
        inverse="_inverse_yarn_denier", store=True, digits=(12, 1),
    )

    @api.depends("yarn_tex")
    def _compute_yarn_counts(self):
        for product in self:
            tex = product.yarn_tex
            product.yarn_ne = NE_PER_TEX / tex if tex > 0 else 0.0
            product.yarn_nm = 1000.0 / tex if tex > 0 else 0.0
            product.yarn_denier = tex * 9.0

    def _inverse_yarn_ne(self):
        for product in self:
            ne = product.yarn_ne
            product.yarn_tex = NE_PER_TEX / ne if ne > 0 else 0.0

    def _inverse_yarn_nm(self):
        for product in self:
            nm = product.yarn_nm
            product.yarn_tex = 1000.0 / nm if nm > 0 else 0.0

    def _inverse_yarn_denier(self):
        for product in self:
            product.yarn_tex = product.yarn_denier / 9.0

The inverse methods matter more than they look. A purchase user can type "32" into the Ne field, the module writes 18.45 tex underneath, and Nm and denier update. Users work in the system they know; the database keeps one truth. If you're still deciding whether Odoo is the right base for this, we've written about why Odoo ERP fits textile manufacturing.

How does count conversion work on purchase orders?

A supplier quote for "32 Ne cotton at $3.20/kg" should land in Odoo as both 32 Ne and 18.45 tex. That's 590.54 ÷ 32 under the ASTM cotton count factor (ASTM D2260). The supplier sees their own wording on the PO. Planning sees tex.

On the purchase order line, the module should:

1. Capture the supplier's count and convention as quoted (32 Ne, cotton).
2. Compute the equivalent tex (18.45).
3. Check it against the selected yarn product within the agreed tolerance.
4. Keep both values on the PO line for the audit trail.

Why keep both? Because a dispute three months later is about what the supplier promised. If the PO only stores the converted value, nobody can show what was actually quoted.

How do you compare yarn prices quoted in different counts?

Compare cost per length, not cost per kg. Take two quotes: 40 Ne cotton at $3.80/kg and 15 tex at $3.65/kg. Using the ASTM factor, 40 Ne is 14.76 tex (ASTM D2260), so the 15 tex yarn is slightly coarser, and you'll use slightly more kg of it for the same warp.

On a per-kg basis, the 40s quote is 4.1% more expensive. Per 1,000 km of yarn, it costs $56.10 against $54.75, a 2.5% gap. Same quotes, but the real price difference shrinks by almost half once you account for linear density. Mills that buy on per-kg price alone can pick the wrong supplier for exactly this reason.

Count conversion only makes the numbers comparable. It doesn't make the yarns commercially equivalent. Fibre, twist, strength and evenness still have to match before price decides anything. It's one of the record-keeping gaps we describe in ERP for textile manufacturing: mills that outgrow their spreadsheets lose this kind of comparison first.

How does count feed warping BoMs and production?

Yarn mass in kg equals ends × length in metres × tex ÷ 1,000,000. That follows directly from tex being grams per 1,000 m (ASTM D2260). For 3,200 ends of 30 Ne yarn over 100 m: 30 Ne is 19.68 tex, so 3,200 × 100 × 19.68 ÷ 1,000,000 = 6.30 kg.

That's the theoretical figure before crimp, sizing pick-up, setup and process waste. A real warping BoM adds stage-wise wastage on top. It also explains why a standard Odoo BoM can't do this job. A standard BoM consumes a fixed quantity per unit produced, while warp yarn consumption changes with ends, length and count on every beam.

We hit this directly at Rajeshwari Weavetex, a 110-loom weaving mill in Gujarat. Yarn is issued from stores by weight, but beams are planned in ends and length, so the custom BoM layer converts between the two on every warping order. With tex stored on the product, the formula needs no lookup tables.

The production flow then runs:

1. The sales order sets the fabric construction and yarn spec.
2. The custom BoM calculates yarn kg from ends, length and tex.
3. Work orders carry the calculated yarn requirement.
4. Operators report actual consumption against it.
5. The variance between theoretical and actual shows waste per stage.

How do sales quotes handle customer count specs?

Show the customer their own spec and cost it in tex. A buyer asking for fabric in 50 Nm yarn gets "50 Nm" on the quote, while costing runs on 20 tex, since Nm = 1,000 ÷ tex (ASTM D2260). That same yarn is 29.53 Ne if your spinner quotes in cotton count.

The quote workflow:

1. The customer specifies 50 Nm.
2. The module converts it to 20 tex for costing.
3. The BoM and cost roll-up run in tex.
4. The quote and order confirmation print 50 Nm.

Nobody has to explain to a buyer why their spec came back in a unit they didn't ask for. And nobody in production has to convert it again.

How should QC compare lab results against the quoted count?

Measure variance in the system the supplier quoted, against the tolerance in your purchase agreement. If the lab reads 29.8 Ne on a lot bought as 30 Ne, that's a −0.67% count deviation, or 19.82 tex against 19.68 tex using the ASTM factor (ASTM D2260).

The QC workflow:

1. The lab records the measured count, in whatever system the tester reports.
2. The module converts it to the supplier's quoted system.
3. Variance is checked against the agreed tolerance.
4. The lot is accepted, held or rejected, and the result stays on the lot record.

Settle which system the tolerance is written in before the first dispute. A ±2% tolerance on Ne and a ±2% tolerance on tex are almost the same for small deviations, but contracts should name one, not leave it to interpretation.

Once count is stored consistently, stock reporting becomes straightforward. A planner can see available kg by yarn, filtered by tex range or displayed in Ne, without converting anything by hand. If that view needs to sit inside a wider business intelligence dashboard, the clean count master is what makes it possible.

What does a phased rollout look like?

Start with master data, because every later stage reads from it. ASTM's factors are exact when derived from 1 yard = 0.9144 m and 1 lb = 0.45359237 kg (ASTM D2260), so formula errors are rare. Data errors aren't. A yarn product recorded as "30s" without its convention is where conversions go wrong.

1. Count master. Set tex on every yarn product and record each supplier's count convention. Clean up duplicate products created for the same yarn in different counts.
2. Purchase. Add quoted count and convention to PO lines, with tolerance checks.
3. Production. Build the custom warping BoM that calculates kg from ends, length and tex.
4. Sales and QC. Print customer specs on quotes and convert lab results for variance checks.

The risk we plan for most is migration. Opening stock often sits under three product names for one yarn. Merging them before go-live takes a physical count and a few hard decisions, but it's far cheaper than reconciling three sets of stock moves afterwards.

Who builds this?

Count conversion isn't a setting in Odoo. It's a custom module that touches product, purchase, BoM, sales and quality models. Our Odoo team builds it as part of manufacturing ERP implementations, alongside the warping and costing layers that standard Odoo doesn't cover. If you'd rather extend your own team, you can hire Odoo developers with textile experience.