Published
ShipStation validates the delivery address on every order shipping to a supported country, and for US addresses it classifies each one as residential or commercial. That classification is available to automation rules as a criterion, and ShipStation documents the specific rules that use it to avoid FedEx’s surcharges in both directions.
If you are not routing on it, that is the largest easy saving in this article, and the rest is about how much confidence the flag deserves.
The result is marked with an icon in the Orders grid, and there are six of them: validated domestic, validated residential, validated international, not verified, warning, and error.
Two criteria in the criteria and actions reference expose the result to rules. Residential / Commercial matches on how the address was verified. Address Verified matches the processing status — Verified, Warning or Error — and ShipStation notes you cannot select multiple values on one criteria line, so catching both Warning and Error takes two rules.
That second one is underused. A rule keyed on Address Verified can tag and alert on the addresses that came back doubtful, which turns a per-order discovery at the print step into a list somebody clears before the batch runs.
Validation itself is automatic and needs no configuration. There are separate icons for a validated domestic address, a validated residential address, a validated international address, an unverified address, a warning and an error.
Two properties of that list matter.
Residential classification is US only. ShipStation’s address validation documentation states plainly that it cannot verify addresses as residential for non-US countries. Everywhere else, an address is either validated or it is not.
For US accounts, “validated domestic” means commercial. Not “unknown” — the absence of a residential mark is itself the commercial determination. That is a reasonable default and it is not the same thing as evidence.
Validation is run against the USPS address database for US orders and the Melissa database for the other supported countries: Australia, Canada, France, Germany, Great Britain, Israel, Italy, Norway, Spain, Sweden and the United States.
Buried in a rate-troubleshooting article rather than in the address documentation, ShipStation says this:
The residential/commercial marker is determined by either the Stamps.com or Melissa address database and may not reflect the same determination made by UPS or FedEx.
That is the whole problem in one line.
You are routing on one classification. The carrier bills on another. They agree most of the time and there is no mechanism that makes them agree always, because they are separate databases maintained by separate organisations for separate purposes. No shipping platform can resolve that — the only party who knows how UPS will classify an address is UPS, and they answer at billing time rather than at rating time.
When they disagree, the sequence is: ShipStation marks the address commercial, your rule picks FedEx Ground, the label prints at the commercial rate, FedEx delivers to what its own data says is a house, and a residential surcharge appears on the invoice two weeks later. Nothing in ShipStation is wrong. Nothing in ShipStation tells you either.
This belongs in the same category as the rest of what gets added after the label is bought — a charge you cannot see at the moment of the decision.
None of that is an argument for ignoring the field. Being right most of the time beats being right never, and the surcharge you avoid on the majority is real money.
ShipStation documents the pattern and it is worth copying:
FedEx will charge an additional surcharge for FedEx Ground® shipments that are delivered to a residential address, or FedEx Home Delivery® shipments that are delivered to a commercial address.
Two rules cover it. One takes orders where the carrier is FedEx and the Residential/Commercial indicator is Residential, and sets the service to FedEx Home Delivery. The other takes orders verified as Commercial where the mapped requested service is FedEx Home Delivery, and sets them to FedEx Ground.
The second rule uses the Requested Service (Mapped) criterion, which means it depends on Service Mapping being configured for the store. ShipStation’s reason for building it that way is good: keying on the mapped requested service makes the rule skip orders where the customer asked for an expedited service, which you do not want silently downgraded to Ground.
If you use FedEx’s expedited services as well, both rules need extra criteria so they only touch the ground tier. A rule that matches on carrier alone will happily rewrite a Priority Overnight order.
Rules are the right tool if you are hard-selecting a service. If you are rate shopping, the distinction is handled differently and better.
Put both FedEx Ground and FedEx Home Delivery in the service collection and let Rate Shopper compare them. The rates it gets back are quoted for the address as classified, so the service that is actually eligible wins on price without you writing a rule about it. A collection containing only Ground will win a house on price and cost you the surcharge afterwards.
The alternative is a separate configuration per address type, routed on the Residential/Commercial criterion. Both work. Including both services in one collection is less to maintain.
Either way the underlying disagreement between databases remains. You have removed the case where your own configuration was wrong, which is the part you control.
There is a third state, and it has a setting.
When an order imports without a defined residential or commercial indicator, ShipStation lets you set the store’s default. The options are Residential, Commercial, or Marketplace — the last meaning take whatever the selling channel said.
If you sell to consumers, defaulting undefined addresses to Residential is the safer choice, because the cost of being wrong is asymmetric. A residential parcel sent on a commercial service earns a surcharge. A commercial parcel sent on a residential service is usually fine and occasionally slower. If you sell B2B the reverse applies.
Check what yours is set to. It is per store, and the default is not necessarily the one that suits your mix.
Worth knowing because it changes what you do about them.
ShipStation draws the line between warnings and errors in general, and it is worth having straight. In their words, warnings “don’t stop you from creating shipping labels” — they “exist to bring something to your attention that might influence your shipping decision” — whereas an error “blocks you from creating a shipping label and requires you to make some kind of change”.
Address verification sits on the permissive side of that line. An address verification warning and an address verification error both will not prevent you from attempting to create a label. A warning means the core components verified but there is extra or missing detail — an unverifiable apartment number in address line 2 is the usual case. An error means something in the city, state or postal code combination failed outright. Neither stops you printing; the postage provider may still reject the label afterwards.
In both cases you can buy the label. If the postage provider then rejects it, you get a second error and have to fix the address anyway, having spent the time.
So the warning icons are advisory and worth clearing before a big batch rather than after. Sorting by validation status and fixing the handful that are flagged is quicker than discovering them one at a time at the print step.
ShipStation can standardise and correct addresses as well as validate them. It is on by default and toggled per store, under the store’s details, separately for domestic and international.
ShipStation’s own caveat is the one to weigh: when correcting, “there is a chance the closest matching address in either the USPS database or Melissa database will not match the intended delivery address.” Standardisation is a match to the nearest known address, and the nearest known address is not always the right one.
For most consumer volume, correction fixes more than it breaks and should stay on. If you ship to addresses that are genuinely unusual — new developments, rural routes, sites the databases have not caught up with — it is worth knowing the toggle exists.
Turning correction off does not turn validation off. ShipStation still validates and still shows the icons.
Take a month of FedEx ground-tier shipments and cross-reference the service used against the residential surcharges on the invoice. If surcharges are appearing on shipments sent as Ground, count them. That number is the size of the disagreement between the two databases on your own address mix, and it is the only way to measure it.
If it is small, the routing rules are doing their job and you are done. If it is large, your mix is skewed toward addresses the USPS database and the carrier classify differently, and the answer is to include both services in a rate comparison rather than to keep tuning the rules.
The surcharge itself is not negotiable at the order level. It is in your carrier agreement, and if it is a large enough line on your invoice it is a contract conversation rather than a configuration one.
And the classification disagreement will not go away. Two organisations maintain two datasets about what kind of building sits at an address, and they will diverge at the edges permanently. The goal is to be wrong on the small fraction rather than the large one.
Knowing how a carrier prices a package is useful. The harder problem is making the right packing and rate decision on every order, when the correct answer changes with the contents, the destination and the rate card.
String builds and maintains that logic inside existing ShipStation accounts, for operations shipping roughly 6,000 orders a month or more. Below that, ShipStation's native automation and accurate product dimensions will get you most of the way there.
Eight patterns that show up when an operation needs custom shipping logic
