Updated
Short answer: ShipStation does not cartonize in the rules engine, and does compute a packing plan elsewhere. Four separate mechanisms can put a box on an order before anyone touches it — SmartFill, Product Defaults, automation rules, and Packing Recommendations — and only the last of those actually solves for fit, at the cost of a person opening the order to apply it.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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, a beta feature in ShipStation Labs, computes a packing plan from your product dimensions, weights and available packages, returns the plan using the fewest packages needed for the order, and will create the recommended multi-package configuration in a single click. 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.
ShipStation documents three requirements, and the second is the one that stops most accounts:
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.
What it does not do is run unattended. You go to the Orders tab, select an order, click Package Recommendations in the order details and apply the plan — rather than having it applied to every order at import. So it does not sit in the rule chain, and because the plan is applied by hand after import, the packing result is not available to whatever selected the rate. Being a Labs beta, its availability may change.
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, and needs a person to ask it.
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, and the boundary is where it runs rather than what it can work out. Applied per order by a person, it cannot inform the rate — and since the box determines the dimensional weight and the cubic tier, packing and rating are one decision being taken as two.
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.
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. If your orders are multi-SKU and the box genuinely varies, it will do the hard part, and the remaining question is only whether someone has time to open each order.
If the remainder is a large enough share that packers are making the call regularly, or the orders that need it are the ones going out fastest, the decision needs the actual item dimensions and the actual quantities computed per order and written back before anyone opens it — and priced against live rates rather than after them. That’s the logic we build alongside ShipStation.
There is a self-assessment that runs on two standard ShipStation exports and tells you where your own orders are costing more than they need to — oversized boxes, services picked by habit, shipments the rules engine could not handle. It runs in your browser and nothing is uploaded.
Most of what it finds is fixable inside ShipStation. Where it is not, that is the point at which logic above the platform starts to be worth it — usually past 6,000 orders a month with a dedicated fulfillment team.
