Cartonization: How Algorithms Pick the Right Box Size

Cartonization is the decision that happens between the pick and the pack: given a set of items on an order, which box do they go in, and do they all go in one. In a low-volume operation a packer makes that call by eye. Above a certain order rate the call gets made by software, item dimensions in and a box identifier out, and the quality of that software becomes a line item on the freight invoice.

The reason it is worth engineering rather than guessing is that carriers do not bill you for what you shipped. They bill you for the larger of the weight and the space, and the space term is a step function of the box you picked.

The three questions a cartonization engine has to answer

• Does it fit - a three-dimensional geometric question about the items, their orientations and the required cushioning, not a comparison of volumes.
• Will it survive - the chosen box has to be one whose compression and drop performance was actually established, at the gross weight the engine just loaded into it.
• What will it cost to move - chargeable weight, which is set by the external dimensions, and the void fill needed to make the pack safe.

Engines that only answer the first question are common, and they are the ones that generate boxes the packer overrides by hand.

Chargeable weight is the term that drives the decision

Parcel carriers compute a dimensional weight from the external dimensions of the shipped box and bill the greater of that and the scale weight. The divisor is contractual - read yours rather than assuming - but the published forms are consistent:

dimensional weight = (L x W x H) / divisor L, W, H measured externally divisor 139 in^3 / lb commonly published for US domestic parcel divisor 5000 cm^3 / kg commonly published for international / metric divisor 6000 cm^3 / kg also in use on some services and contracts chargeable weight = max(scale weight, dimensional weight)

Two consequences follow, and both are easy to miss. First, the dimensions used are external, so board caliper and any bulge count against you. Second, which of the two terms governs depends on the divisor, so the same pack can be billed on its weight under one contract and on its cube under another. Optimising the box without knowing which term is binding is guesswork.

A worked example

Take a three-line order and a box ladder with three sizes in the relevant range. Internal dimensions, single wall board of about 4 mm caliper, so each external dimension is the internal plus roughly 8 mm.

Order item A 300 x 200 x 60 mm 1.2 kg item B 180 x 120 x 90 mm 0.6 kg item C 250 x 150 x 40 mm 0.5 kg item volume 7.04 L item mass 2.3 kg gross with box and void fill, about 2.55 kg Candidate boxes internal fill external cube DIM /5000 M 400 x 300 x 200 29.3 % 408 x 308 x 208 26 138 cm3 5.23 kg S 350 x 250 x 150 53.7 % 358 x 258 x 158 14 594 cm3 2.92 kg XS 320 x 220 x 120 83.4 % 328 x 228 x 128 9 572 cm3 1.91 kg

On volume alone XS looks like the answer. It is not, and this is exactly where a volume-only engine fails. Item A is 300 x 200 and the XS floor is 320 x 220, so A covers the floor and leaves a 20 mm strip that holds nothing. C can lie on top of A at 40 mm, giving 100 mm of the 120 mm height. B needs a further 90 mm in any orientation that fits the footprint. XS is geometrically infeasible even though it has 16 percent of its volume unused.

S works, but only in one arrangement:

Box S, internal 350 x 250 x 150 layer 1 A flat on the floor, 300 x 200 footprint, 60 mm high remaining floor is a 50 mm strip - nothing fits beside A layer 2 90 mm of height remains B upright, footprint 180 x 120, height 90 at x 0..180, y 0..120 C rotated, footprint 150 x 250, height 40 at x 180..330, y 0..250 both inside 350 x 250, both within the 90 mm result single box, chargeable weight = max(2.55, 2.92) = 2.92 kg

Now compare the outcome of picking M instead, which is what an engine does when its fit check is crude and it defaults up a size for safety. The goods are identical. The chargeable weight goes from 2.92 kg to 5.23 kg, because the cube nearly doubled and the cube is the binding term. Under a 6000 divisor the same M box computes to 4.36 kg while S computes to 2.43 kg, at which point S is billed on its 2.55 kg scale weight instead. Same items, same ladder, different governing term.

Fit checking is bin packing, and it has to run in milliseconds

Three-dimensional bin packing is NP-hard, so a production engine does not search exhaustively. It uses a heuristic - extreme-point placement, layer building, or a first-fit-decreasing over sorted item volumes with the six axis-aligned orientations tried per item - and accepts that it may return a feasible answer rather than the optimal one. That trade is correct at pack-station latency. Two properties matter more than optimality:

• Determinism. The same order must return the same box every time. Non-deterministic packing makes damage investigations unresolvable, because you cannot reconstruct what the pack looked like.
• Conservatism. A false positive - the engine says it fits and it does not - costs a repack, an angry packer and, in time, an engine everyone ignores. A false negative costs a slightly larger box. Bias the tolerances accordingly.

The single most effective fix to a fit check that keeps failing at the bench is to stop packing items and start packing protected envelopes. Inflate each item by the cushioning it actually requires per face, then pack the inflated cuboids. An engine that fills a box to 95 percent of its internal volume has produced a pack with no room for cushioning, which is a box that fails a drop test rather than a box that is efficient.

Every box in the library carries its tested limits

Cartonization silently makes an engineering decision, so the library it selects from has to be an engineering artefact. Each entry should carry, as data the engine can read:

• Internal and external dimensions, and the board grade.
• Maximum gross weight, from box compression measured to ASTM D642 on samples conditioned at 23 C / 50% RH, with the derates for humidity, dwell time and stacking pattern already applied.
• The distribution profile it was qualified against - ASTM D4169, or the ISTA profile matching the lane, 3A for parcel and the 6 series for member-specific e-commerce programmes.
• Any handling limits, such as maximum load height or orientation constraints.

Without the weight limit as a field, an engine will cheerfully put 18 kg of goods into a box qualified for 8 kg, because nothing in a pure geometry check knows about compression. That is not an optimisation error. It is an untested pack going out the door under an automated decision, and it is the failure mode most worth designing out.

How many sizes should the ladder have

More sizes fit orders better and cost more everywhere else: another purchased SKU, another warehouse slot, another erector changeover, more inventory tied up, more scope for the wrong box to be presented at the station. The method is to take a representative window of real order lines, run the packing heuristic against candidate ladders, and look at the distribution of wasted cube rather than the average. Averages hide the tail, and the tail is where the oversized shipments live.

Practical constraints that decide this before the mathematics does:

• Erector limits. Your case erector has a minimum and maximum blank size. A size the line cannot run is not a size.
• Ladder spacing. Sizes clustered closer than the cushioning tolerance do not separate any orders - they just add SKUs.
• Marginal capture. A new size earns its place only if enough order volume actually lands on it, and if that volume would otherwise have gone up a size rather than sideways.

The data is usually the problem

Cartonization inherits the quality of the item dimension master. Dimensions entered from a supplier specification sheet, rounded, or copied from a retail carton that has since changed will produce boxes that do not close. Measure items on a dimensioner, record the true bounding box including protrusions, handles and any packaging the item already carries, and re-measure when a supplier changes. Track override rate at the pack station as your data quality signal - when packers routinely reject the engine's choice, the master data is wrong far more often than the algorithm is.

When cartonization does not pay

• Single-SKU orders with a fixed pack. If the item ships in its own qualified carton, or ships in its own container as retail-ready, there is no decision to make and adding one only adds error.
• Fragile items needing a designed fitment. A moulded insert or a specific suspension pack is a pack design, not a box selection. The engine should route these to their pre-assigned pack, not attempt to fit them.
• Palletised freight. Where the shipment is billed by pallet space or by weight break, chargeable weight is not a per-carton function and the optimisation target moves to pallet fit and layer tiling instead.
• Very low or very uniform order volume. If a handful of order shapes cover almost everything, a short published rule and a two-size ladder outperform an engine no one maintains.

What to measure once it is running

Four signals tell you whether the engine is working, and none of them require a projection to interpret:

• Chargeable-to-scale weight ratio per shipment. When this sits above 1, the cube is being billed, and box selection is the lever.
• Cube utilisation distribution, not the mean.
• Share of orders landing in the largest box, which is where oversizing concentrates.
• Packer override rate, split by reason - does not fit, will not close, needs more cushioning. Each reason points at a different defect.

Cartonization is a search problem wrapped around a set of engineering constraints. The search is the easy half and a machine does it faster and more consistently than a person can. The constraints - tested compression limits, real cushioning requirements, honest item dimensions - are the half that determines whether the answer is worth having.