Setting Up NMFC Density-Based Rating in Your TMS

Why your rating engine is probably still wrong

If nobody has touched your LTL rating configuration since before July 2025, you are almost certainly quoting and paying wrong classes right now. On July 19, 2025, the freight classifications outlined in Docket 2025-1 transitioned from commodity-based to density-based. A revised 13-subprovision density scale replaced the current 11-tier system, allowing for more precise classification of freight based on density, and this adjustment introduced class 50 and 55 to the NMFC density scale. That's not a cosmetic update. It's a structural change to how the class field gets populated on every bill of lading you cut.

Then came round two. On February 6, 2026, the NMFTA released Docket 2026-1, which continued the consolidation by canceling additional legacy commodity items and tightening classification rules. One industry estimate puts the combined effect of the two dockets at approximately 30% of all LTL freight classifications being touched in some way. If your TMS product master still auto-fills NMFC codes from historical shipment records, you have a silent config failure sitting in your system right now: shippers whose ERP or TMS systems auto-populate NMFC codes from historical records should verify those codes against the current tariff, because a code that was valid in 2024 may have been consolidated into a broader category in 2025 or canceled entirely in Docket 2026-1.

The fix isn't a new TMS. It's rebuilding the density logic inside the one you already run. Below is the config sequence I use, field by field.

What you need before you touch the rating engine

Get these four things lined up before you open the rate table editor. Skipping any one of them turns this into a two-week fire drill instead of a one-afternoon config job.

• Admin-level access to your TMS rate tables and the item/product master, not just read access. You'll be editing formulas, not just viewing them.
• A current NMFC data source. That means either a live ClassIT+ subscription or a data feed your TMS vendor keeps synced, since ClassIT+ is the official digital version of the NMFC, offering real-time updates, modern search functionality, and intuitive navigation for classification professionals.
• Clean dimensional data captured at the point of packing or BOL creation, in inches for length/width/height and pounds for weight. Product-catalog defaults will not work here, and the failure mode section below explains why.
• A pulled sample of your last 90 days of BOLs, ideally 100+ shipments, to use as your parallel-test dataset before go-live.

Rebuilding density-based rating, step by step

This is the actual sequence. Do it in order, because steps 3 and 4 depend on step 2, and step 6 is worthless without steps 1 through 5 done correctly.

1. Export your current NMFC-to-item mapping from the TMS product master. Flag every code that hasn't been touched since before July 2025. That timestamp is your risk list.
2. Add or verify the density input fields on the shipment/BOL entry screen: length, width, height in inches, and weight in pounds. Make them required fields, not optional ones. If a planner can submit a BOL without dimensions, they will.
3. Configure the cubic-foot and density formulas in the rating engine. Cubic feet equals length times width times height, divided by 1,728. Density equals total weight divided by total cubic feet. This multiplies the greatest straight-line dimensions of length, width, and height, including all projections, as tendered to the carrier for shipment, and divides the total by 1,728 cubic inches, with density calculated by dividing the weight of the handling unit by that result.
4. Load the 13-tier density-to-class table into your rate tables, including the new bands at the bottom of the scale. This is the part most admins get wrong because they patch the old 11-tier table instead of replacing it.
5. Add override flags for handling, stowability, and liability so density doesn't blindly overwrite fixed NMFC items. NMFTA's own guidance is blunt about this: density is now the primary factor when evaluating freight, but it's still important to have the correct item number since items that have handling, stowability, or liability concerns will not be full density.
6. Run a parallel test. Rate 25 to 50 recent shipments (more if you can pull 100) through the rebuilt engine and compare the output against the class the carrier actually billed at delivery.
7. Route mismatches into an exception queue. Anything off by more than one class level goes to manual review before you flip the config live for production traffic.
8. Publish the config as a versioned SOP with a named owner. NMFTA isn't done issuing dockets, and the next person who touches this table needs to know what changed and why.

The table below covers the three subprovisions that actually changed. Subs 1 through 10 kept their existing density breaks; this is the part of the scale you need to re-map.

Sub 11 applies to densities ranging from 30 but less than 35 pcf and is assigned class 60, Sub 12 applies on densities ranging from 35 but less than 50 pcf and is assigned class 55, and Sub 13 applies on densities of 50 pcf or greater and is assigned class 50. If your rate table still stops at class 60 for dense freight, you're overcharging your own shipments on every dense pallet that qualifies for 55 or 50.

How you know it worked

Two numbers tell you whether the rebuild is holding: your reclassification fee rate and your class-match rate against carrier terminal audits. Track both weekly for the first month, then monthly after that.

Set your baseline expectation with real numbers, not guesswork. Misclassification triggers reclassification fees of $75 to $150 per shipment plus retroactive rate adjustments, and a 15% upward misclassification on 100 shipments per month adds $3,000 to $5,000 annually in unnecessary freight charges. If your monthly reclass fee count isn't trending toward zero within 60 days of go-live, your override flags from step 5 are probably too loose, or too tight, and letting density steamroll items that actually carry handling or liability exceptions.

Failure mode: the density formula pulls from the wrong dimension source

The most common break I see after a "successful" config rollout: the TMS calculates density off the product master's per-unit dimensions instead of the actual palletized handling-unit measurement. That understates cube every time, and it's invisible until the carrier's dock dimensioner catches it. Shippers who calculate density based on the product dimensions rather than the shipping dimensions will under-classify their freight and face reclassification charges when the carrier's dimensioner captures the actual pallet measurements.

The fix is a validation rule, not a retraining session. Require a fresh handling-unit measurement at BOL creation for any load that isn't a standard, pre-measured SKU configuration, and block submission if that field is blank. Don't let the system fall back to a SKU-level default when the actual pallet build changes, which it does constantly on mixed loads and promotional packaging runs.

Where this fits in your TMS stack

None of this requires custom development on most platforms. Whether you're running MercuryGate, Descartes, Oracle Transportation Management, SAP TM, 3Gtms, Blue Yonder, or a multi-carrier connectivity layer like Cargoson, the density fields and rate-table structure already exist. What's missing is almost always the mapping work above: fresh dimension capture, the 13-tier table, and override flags that respect handling and liability exceptions instead of letting density run unchecked.

Start with the export in step 1 this week. Even a rough flag on "codes untouched since before July 2025" will tell you how much exposure you're carrying into your next carrier audit.