Carriers bill for space in the truck, not for kilograms on the scale. A box of pillows weighs 15 kg and gets invoiced as 115 — and most teams discover that from the invoice rather than while quoting the deal. Here is how to keep package dimensions in a Bitrix24 (Alaio) CRM card, why volumetric weight differs from chargeable weight, which divisor belongs in your calculation, and how to catch an oversize shipment before it leaves the warehouse.

Where do you store package dimensions in Bitrix24?

Bitrix24 has no native field type for dimensions. You get numbers, strings, lists and money — and "three sides plus weight" is not among them. That leaves two common workarounds, both awkward.

Four numeric fields — length, width, height, weight. This works: values are filterable, reportable and readable by automation. Two problems, though. Four fields eat half the card and get lost among the other twenty. And the unit lives nowhere: one rep enters centimetres, another millimetres, and nothing in the card tells them apart until somebody ships a box the size of a bus.

A single text line like "120x80x60" is compact and human-readable, but it is just text. You cannot compute a volume from it, compare two shipments, or filter for "anything longer than a metre".

The third option is a custom field type from an app: the type stores the value itself and renders its own widget inside the card. One line for four numbers, and the arithmetic is done by the field rather than by the rep.

What is volumetric weight, and how is it calculated?

Every shipment has two weights. Actual weight is what the scale shows. Volumetric weight — also called dimensional or DIM weight — is how much room the package takes, expressed in kilograms.

The formula is one line: multiply the three sides in centimetres and divide by your carrier's divisor.

A 120 × 80 × 60 cm box gives 576,000 cubic centimetres. Divided by 5000, that is 115.2 kg of volumetric weight — against an actual 15.5.

The carrier then takes the greater of the two weights. That one is the chargeable weight, and it is what lands on the invoice. So a light bulky shipment is billed by volume, while a heavy compact one is billed by the scale: a 30 × 20 × 20 cm crate of fasteners weighs 40 kg against 2.5 kg volumetric, and you pay for 40.

The rule fits on one line: chargeable weight = max(actual, volumetric). Everything else is a detail of the divisor.

Which DIM divisor does your carrier use?

The divisor is not universal — it is written into your contract. The common ones:

| Divisor | Who uses it | |---|---| | 5000 | DHL, UPS, FedEx — express and air | | 6000 | ground tariffs, classic IATA air cargo | | 4000 | consolidated freight: a 250 kg/m³ density rule is the same as a 4000 divisor |

The gap between 5000 and 4000 is a quarter of the cost on the same shipment. That is why "we used a formula from the internet" is the most common reason a quote and an invoice disagree.

If you ship in imperial units, note that the same carriers use a divisor of 139 for inches and pounds. Converted to centimetres and kilograms that works out to roughly 5022 — the same 5000, within half a percent. No separate coefficient needed.

One more thing teams learn late: measure the box, not the product. What counts is what actually travels — packaging, padding, corner protectors, pallet. Ten centimetres per side add up quietly, and the volume ends up somewhere else entirely.

How do you spot an oversize package?

Beyond weight, carriers cap dimensions — and they measure them in two different ways.

Longest side. The simplest limit, and a single comparison to check.

Length plus girth. This is the measure that matters for parcels: length plus twice the width plus twice the height, where length is the longest side. USPS caps combined length and girth at 108 inches for most services and 130 for Ground Advantage; UPS and FedEx go up to 165 inches, with a separate cap on length alone.

The two measures diverge sharply. A 180 × 90 × 70 cm box sums to 340 cm across three sides, but 500 cm as length plus girth. A package that clears one limit can fail the other by a wide margin.

Oversize rarely means "we will not carry it". It means "we will carry it on a different tariff, with a surcharge". The problem is not the surcharge — it is learning about it from the invoice.

How do dimensions work in automation rules?

While dimensions sit in the card as text, automation cannot see them. To let a condition compare anything, the string has to be parsed into numbers.

Parsing yields the whole set at once: three sides, weight, volume, volumetric weight, chargeable weight, plus the longest side, the sum of sides and that length-plus-girth figure. From there they are ordinary numbers that work with standard automation rules and workflow variables.

Typical uses:

  • filter out oversize before it reaches logistics — compare length plus girth against your carrier's cap and route those deals to a dedicated manager;
  • feed a shipping API request — most carrier APIs expect centimetres and grams, and parsing returns them in the units you ask for;
  • price the shipment inside the process — multiply chargeable weight by your rate;
  • populate numeric card fields from a single text one, so filters and reports start working.

The honest limit: parsing reads what is there. If a rep typed the dimensions wrong, automation will be wrong in exactly the same way.

Frequently asked questions

How is volumetric weight different from chargeable weight? Volumetric comes from the dimensions; chargeable is the greater of volumetric and actual. The invoice uses chargeable.

Which units should we store? Whatever your warehouse works in, as long as everyone uses the same one. The volumetric formula is classically computed in centimetres — if you store millimetres, remember the conversion or you will be off by a factor of a thousand.

Do we need a separate volume field? Usually not: volume follows from the three sides. It earns its place only if you track volume as an independent figure, for example with non-standard containers.

What about multi-box shipments? Several boxes on one deal are billed as the sum of their chargeable weights, not as one combined outer dimension. A single field will not cover that — you need line items or a smart process per package.

Does this work in tasks? Custom fields exist in tasks too, but logistics scenarios almost always live on the deal or a smart process, alongside the other deal fields.

Where to go from here

Dimensions in a CRM are not three numbers — they are the chargeable weight you will be invoiced for. It comes from the sides and your carrier's divisor, competes with the actual weight, and is checked against two different oversize measures. You can assemble all of that from four numeric fields plus a formula field — workable, but bulky.

A dedicated field type is tighter: Package dimensions keeps length, width, height and weight in one line and shows volume, volumetric and chargeable weight right in the card, flagging oversize when your own limits are exceeded. To turn that line back into numbers for a process, use the Parse package dimensions rule. The full field type catalogue installs in two clicks.

Cannot find the field or the automation rule you need? Describe the task — we build it for free and add it to the shared library.