How Cartonization Works in ShipStation, and Where It Stops

Short answer: ShipStation can now cartonize orders automatically at import, through a rule action. Four mechanisms can put a box on an order: SmartFill, Product Defaults, assumptive automation rules, and Packing Recommendations. Only Packing Recommendations solves for fit, and it is applied by its own rule action, Recommend Package: add the rule and it computes a packing plan at import for the orders it matches and applies it, multi-package configurations included, without anyone opening the order; Rate Shopper then prices the package it chose. It needs dimensions on every product and a maximum weight on every package, and because it works from rectangles, bagged goods and products with room inside them are where its answer needs a second look.

This page is the ShipStation workflow. What cartonization is, why it is computationally hard, and why the box you pick sets the price is the problem itself, independent of any platform, and worth reading first if the term is new.

Dimensions are worth getting right for two reasons. They determine the rate you’re quoted, and they determine whether the carrier agrees with that rate later — bill a box smaller than the one that actually shipped and the dimensional weight adjustment arrives weeks after you thought the order was closed.

That second reason is where the money is. Carriers price on the greater of raw weight or dimensional weight, dimensional weight being length × width × height divided by the carrier’s divisor — 139 across the major carriers since USPS moved off 166 in July 2026. A box two inches larger than it needs to be is priced as though it were heavier, on every label, indefinitely.

What has to be true first

Three of the four mechanisms below read data off your catalogue, and one of them will not run at all without it. This is the part to check before configuring anything, because it decides which of the four are actually available to you.

Per-SKU dimensions. Length, width and height on the product record, as packed rather than as marketed. In the accounts I work in this is the constraint that decides whether cartonization is a short project or a long one, and it is rare to find a catalogue where it is filled in and current. Weight is easier and therefore commoner: a weight is one number, a carrier demanded it, and a scale on the bench produces it. Dimensions are three numbers per SKU, nothing captures them unless you have bought a dimensioner, and no marketplace feed supplies them.

Your packages, with real dimensions and a maximum weight. Custom packages are configured in Settings, and the dimensions you enter there are the ones every mechanism below reasons about. Internal dimensions, not external — the difference is the wall thickness, and it is the difference between a box that closes and one that does not. Internal is what a packing calculation needs, but it is not what the carrier bills, which is the outside of the box. So once orders are packed, bulk-update them to the true exterior dimensions before buying labels. It is a manual step, and it is the one that keeps the dimensional weight on the label matching the parcel that arrives.

The order itself. Which items, in what quantities. That part you already have.

ShipStation gives you two routes for loading the catalogue data. Product records take dimensions individually or through a CSV import on the Products tab, where SKU is the required field and a blank cell writes a null rather than leaving the existing value alone. And on the Premium plan or with the add-on, a Cubiscan dimensioner connected through ShipStation Connect imports weights and dimensions directly, manually or on a barcode scan.

The number you type is not the number you are billed on

There is a step between measuring a box and being charged for it, and ShipStation’s dimension fields do not perform it.

Enter 12.1 as a length, on a shipment or on a custom package, and the field accepts it. Nothing rounds it, nothing flags it, and the order proceeds. The carrier will not bill against 12.1.

ShipStation’s own marketing blog is direct about what to do instead. Worth reading, and worth noting it is the blog rather than the help centre — the claim carries no citation to a carrier tariff:

Universal rounding rule: Always round up to the nearest whole inch… The exact math: For example, if your box measures 12.1″ x 8.2″ x 5.5,” you must enter your dimensions as 13″ x 9″ x 6.” Failing to round up can result in automated carrier adjustments and extra charges on your monthly invoice.

— ShipStation, How to Ship & Measure a Package

That is good advice. How well it is sourced varies by carrier, and the difference is worth knowing before you build a policy on it.

USPS is documented and rounds up. Since 12 July 2026 it rounds length, width and height each up to the nearest whole inch, in its own words “revising the rounding requirement for DIM piece dimensions.” That is part of the July restructure and it is not in dispute.

UPS and FedEx I could not confirm from the carriers themselves. FedEx’s current dimensional weight page says to “round each measurement to the nearest whole inch,” which is not the same instruction as always rounding up — nearest sends 12.1 down to 12. I could not retrieve a current statement from UPS at all. Both carriers publish rate and service guides that supersede their support pages, and rounding rules have moved recently, so the version that binds you is the one in your own current guide rather than anything on this page.

The practical answer does not depend on resolving that, which is the useful part. Rounding up is safe under every version of the rule. Round up and you can never under-declare, so the worst case is that you were slightly conservative on a carrier that would have rounded down for you. Round down, or enter the decimal and let something else decide, and the worst case is an adjustment weeks later with a fee attached.

Why the gap exists

Neither half is wrong on its own, which is why nothing warns you.

A dimension field is a data entry field. Its job is to record what you measured, and a field that silently altered your input would be worse than one that does not. The rounding rule is a carrier billing rule — it differs between carriers, it applies at rating and billing time, and it has changed at least once in the past year. ShipStation would have to encode a per-carrier, per-revision rule into a field that is frequently filled in before any carrier has been chosen.

So the rounding is yours to do, and it is data entry rather than configuration. None of the four mechanisms below rounds anything: SmartFill copies whatever your last labels carried, Product Defaults and Preset Groups write what is on the product record, item-count rules write the number you typed into the rule, and Packing Recommendations reasons about the dimensions it was given. Every one of them faithfully propagates a decimal you entered three months ago.

That puts this at the same layer as the dimensions themselves. Round when you populate the product record and when you create the custom package, because that is the last point where one correction covers every order that follows.

Measure the box you actually ship

One more from the same blog post, and it is operationally useful. Carriers scan parcels with automated dimensioners that measure the widest point, so a box packed tight enough to bulge measures larger than the carton did flat.

Measure after packing and taping rather than from the box specification. This is also the quiet failure mode of any packing calculation, cartonization included: the algorithm solves for the carton you described, and the carrier bills the carton that arrived. If your boxes routinely bulge, the dimensions on your package records are optimistic for every order that uses them.

The four mechanisms, in the order they run

They stack, and later layers overwrite earlier ones. The full order of operations governs all of this, and it is the reason a setting that looks ignored is usually being overwritten rather than failing. The third and fourth share a layer: Packing Recommendations is applied by a rule, so between it and your other package rules, the one lower in the list wins.

1. SmartFill, which is already on

SmartFill runs first and most people have never configured it, because it is enabled by default. As orders import it compares the new order’s items to the two most recent shipments for the exact same combination of items, and if those two shipments have identical weight and dimensions it copies them onto the new order. If they disagree it does nothing.

That makes it a cache rather than a calculation. It does not know the size of anything; it replays the box a packer already chose for this exact basket, twice, consistently. Which is genuinely useful — for a catalogue with repeating order shapes it does the work of a product default with nobody maintaining a product record — and it is also why it cannot help on a combination nobody has shipped before. Where it sits against the other layers, and how to tell when it is the one setting your values covers it in full. ShipStation states it applies after Auto-Split and before all other types of automation, so everything below overwrites it.

2. Product Defaults, for single-item orders

For a product that always ships in the same box, set the dimensions on the product record and ShipStation applies them on import. One limit worth knowing before you rely on it: ShipStation applies Product Defaults only to orders containing a single line item at a quantity of one. One SKU ordered three times does not qualify. Product weight is the exception — that is summed across multi-item orders.

• Go to the product settings in ShipStation.
• Navigate to the “Shipping” section.
• Input the package dimensions.
• Save the updated product data.

This is the highest-return thing on this page. It requires no rules, it never gets out of sequence, and for a catalogue where most orders are one item in a known box it solves the problem outright. It’s also what Rate Shopper depends on — a rate is only as good as the package it was quoted for.

3. Automation rules, by item count or tag

You can also write rules that apply dimensions based on how many items are in a shipment: one item in the small box, five in the large one. Adding custom packages and applying one by rule covers the configuration step by step, including why a named package has to be applied alongside a carrier and service.

This is an approximation, and how good an approximation depends on how similar your SKUs are to each other. A catalogue of near-identical items — one product in three flavours — approximates very well. A catalogue where a five-item order might be five keychains or five kettles approximates poorly, because item count isn’t standing in for volume any more.

Two things to watch when you use these rules:

• Sequence. Dimensions have to be set before anything that consumes them, particularly a Rate Shopper rule. ShipStation’s setup documentation is explicit: “The dimensions rule must come first to ensure that all orders generate the appropriate rate.” If you also use the Recommend Package rule action, the same logic applies to it: it goes above the Rate Shopper rule, and any item-count rule placed below it will replace its plan.
• Drift. The rule encodes an assumption about your catalogue at the time you wrote it. Adding SKUs in new sizes silently degrades it.

4. Packing Recommendations, which actually computes

There is a fourth route, it is newer than most of what is written about this subject, and it is the only one of the four that solves for fit. Packing Recommendations computes a packing plan from your product dimensions, weights and available packages, returns the plan using the fewest packages needed for the order, and applies it — creating the multi-package configuration where the order needs more than one box — on every order matched by the rule that calls it. If the problem below is yours, turn it on. It narrows the gap materially and it deserves more credit than the age of most writing on this subject gives it.

It has three requirements, and the first is the one that stops most accounts:

• Add dimensions and weights to your products.
• Configure your custom packages with dimensions and maximum weight.
• Add an automation rule using the Recommend Package rule action, placed above any Set Rate Shopper rule.

Which is the section above, restated as a prerequisite. A catalogue without per-SKU dimensions does not get a degraded recommendation; it gets nothing to compute from.

Since October 2026 it can run unattended. It is applied by the Recommend Package rule action, so it sits in the rule chain like any other action: the plan is computed and applied at import on the orders the rule matches, multi-package configurations included, and Rate Shopper — whose pricing runs again whenever the rate is asked for and immediately before the label is bought — prices the package it produced. Without the rule, nothing changes from before. It started as a beta in ShipStation Labs and is now on by default in the accounts I work in, so if you can’t find it in yours, check Labs.

Where the four stop

Line them up and the shape is clear. SmartFill replays a decision a person already made. Product Defaults and item-count rules apply a decision you made in advance. Packing Recommendations makes the decision properly, for fit, on every order its rule matches.

The first three all work by deciding the box ahead of time, which is fine when the box is a property of the product or of a stable order shape. They stop being enough when the right box is a property of the particular combination of items in the order — several SKUs of different sizes, ordered in quantities that change which carton actually works. Choosing the smallest box that fits an arbitrary set of items is a computation over the item dimensions, not a rule you can write down ahead of time. That’s cartonization: a three-dimensional bin packing problem, solved per order rather than looked up.

The fourth does that computation, on every order its rule matches, and where it stops is now about the model rather than about when it runs. It works from rectangles, and a rectangle is a fair description of most boxed goods. It is a poor one in two common cases: contents that give, like a bag of coffee beans, which it treats as a rigid block, and contents with usable space inside, like the interior of a bin or the room around a bottle’s neck, which it counts as solid. ShipStation’s product record has nowhere to store either fact, so no plan computed from it can use them. For those products, check its answers against what your packers actually fit.

None of this is ShipStation being deficient. Cartonization is a genuinely hard computational problem, and building it means knowing the dimensions of every SKU in a catalog it doesn’t own. That Packing Recommendations exists at all is more than a horizontal platform is obliged to do.

When none of the four covers an order, the box gets chosen on the floor by whoever is packing it, which is where the two costs show up: packers reach for a box that’s too big because it’s the safe choice, and the label may not match what shipped.

What to do about it

Start with the catalogue, because three of the four mechanisms are gated on it and the fourth will not run at all. Dimensions on your top SKUs by volume first, and your custom packages configured with real internal dimensions and a maximum weight.

Then Product Defaults on everything with stable packaging — for many catalogues that’s most of the volume, and it costs an afternoon. Leave SmartFill on and check a few shipment activity logs to see what it is filling in.

Add item-count rules where your SKUs are similar enough for count to stand in for size, and put a note in your calendar to re-check them when the catalogue changes.

Turn on Packing Recommendations once the dimensions are there, and add its rule above your Rate Shopper rule. If your orders are multi-SKU and the box genuinely varies, it will do the hard part on every order the rule matches, without anyone opening it. Spot-check its plans on anything bagged, soft-sided or hollow, since those are the products a rectangular model describes least well.

If the remainder — products a rectangle does not describe, or orders where the box that fits best is not the one that prices lowest — is a large enough share that packers are still overriding the plan, the decision needs information the product record cannot hold, computed per order and written back before anyone opens it, and priced against live rates rather than after them.

Where String fits

That remainder is what String’s Pro Automation is for. It is pre-built ShipStation automation for cartonization and the decisions around it, which I tune to your SKUs, packaging and carrier contracts, then run and maintain. The box is decided before your team sees the order, nothing is rerouted, and they keep working in ShipStation.

It covers what the four mechanisms above leave open:

• Products with room inside them. The neck of a bottle or the inside of a bin is space another item can use, so the order goes into the box it actually needs rather than the one its outer dimensions suggest.
• Products that give. Pouches, bags and apparel are not packed as rigid blocks, so a soft item doesn’t push the order into the next box size.
• The box and the rate together. The carton is chosen with the rate, not before it, so the result is the cheapest box that fits, including a carrier’s flat-rate box when that ships for less.
• Multi-box splits. When an order won’t fit one box, the split that costs least, not just the one that fits.
• Perishable orders. The forecast at the destination decides whether an order needs an insulated box, more coolant or a faster service.

You can run it free for 30 days on your real orders, and the 30 days do not start until it is right. Whether you need it or the rule is enough is worth checking first.