USTR China Ship Fees: Model Landed Cost Impact Now

USTR's China-linked ship fees are suspended, and a suspended fee belongs in your landed-cost model as a live scenario with a switch on it. Leaving it out because it reads as zero is the mistake. Our position is to build the fee into your operations software now as an effective-dated, parameterized surcharge tied to vessel and carrier attributes. Then run reinstatement scenarios against your real bookings before anyone in Washington decides anything. If your ERP's freight module can't hold a cost that depends on which ship carries the container, that module will fail you on the day the suspension ends. The fix is a small module that runs beside the ERP, and you don't need a new ERP to get it.

The rest of this piece covers how the USTR China ship fees landed cost impact moves through your numbers, the data you need to capture at booking, the scenarios worth running, and where packaged freight modules stop being enough.

A Suspended Fee Is an Open Position on Your Cost

A suspension is a pause with a lever still attached. The policy exists, the mechanism exists, and someone can reactivate it on a timeline you don't control. On your books, that's an open position on your cost of goods that you can't see yet.

When the fee was active or announced, carriers and forwarders had to decide how to price it. Some absorb a cost, some pass it through as a line-item surcharge, and some move tonnage around so their ships avoid the fee. When the fee comes back, the same decisions get made again, quickly. The importer whose system already knows which open bookings sit on exposed vessels can reprice, reroute, or pull forward orders that week. The importer who has to reconstruct that exposure from booking confirmations in a shared inbox loses the week to research.

So the question for your ops team is narrower than "will the fees return?" It's this: if they return on a given date, which of our in-transit and booked shipments carry the exposure, how much lands on each SKU, and what does each alternate routing cost us in money and days? You can answer that today without knowing the outcome. You just need the model to treat the outcome as an input.

One caution before going further. Rates, the criteria for which vessels count as China-linked, and the exemptions should all come from the current published notice. Don't type them into your software from memory or from a news summary. Store them as data your team can update, with the source and effective date recorded next to each value.

Where a Ship Fee Enters Landed Cost

A port fee is levied on a vessel call. You don't pay it directly. It reaches your landed cost through a chain, and every link in that chain is a place where your software has to make a decision.

1. The vessel call. The fee attaches to a ship arriving at a US port, based on attributes of that ship and its operator.
2. The carrier's pricing decision. The carrier decides whether to pass the cost through, and how: a flat per-container surcharge, a rate increase on the lane, or something folded into a general rate adjustment.
3. Your freight invoice. The cost shows up as a surcharge line, a higher base rate, or nothing visible at all if the carrier absorbed it or rerouted.
4. Allocation to receipts. Your system spreads the container's freight across the purchase lines inside it, by weight, volume, value, or quantity, depending on how you've configured landed cost.
5. SKU cost and margin. The allocated amount rolls into unit cost, then into inventory valuation, then into margin on every sale of that stock.

Two things follow from this chain. First, the exposure is decided at link one, by the vessel, long before the invoice arrives at link three. If your system only learns about freight cost when the invoice posts, it learns about the fee weeks after the decision that caused it. Second, the allocation method at link four changes which products absorb the hit. A per-container surcharge allocated by value lands differently on a container of low-value bulk components than on a container of finished goods. Run the scenario through your actual allocation rule, the one your ERP applies, or the SKU-level numbers will be wrong.

The Data Model You Need Before the Decision Lands

Most of the work here is capture. You can't model vessel-level exposure if your system doesn't record the vessel. Here's the minimum we'd put in place.

At booking, per shipment:

• The vessel's IMO number. The name alone won't do, and the next section explains why.
• Carrier, service or loop identifier, and voyage number
• Port of loading, port of discharge, and any transshipment port
• Container count and type
• The purchase order lines assigned to each container

In a fee parameters table, per rule:

• Rule identifier and a plain-language description
• The vessel or operator attributes that trigger it
• Charge basis (per call, per container, per tonnage, whatever the notice specifies)
• Rate, as a value your team enters from the published source
• Status: proposed, active, suspended, or withdrawn
• Effective-from and effective-to dates
• Source reference and who entered it

In a vessel reference table:

• IMO number as the key
• Operator, owner, and build attributes relevant to the triggering rules
• The date each attribute was last verified

Effective dating is the piece that matters most. A suspended rule stays in the table with status "suspended" and an open end date, which lets you write a scenario that says "assume this rule reactivates on date X" without editing the rule itself. Your actuals keep reading the real status. Your scenarios read an override. Nobody ever has to delete a rule and retype it later from a press release.

We handled the same structure when vessel-fee policy shifted on a different trade lane. The re-mapping pattern is in our piece on FMC Spanish vessel fees. Different regulator, different trigger attributes, same data shape. A fee keyed on vessel attributes needs vessel attributes in your system.

Match Vessels on Exact Identifiers, Never on Names

Ship names repeat, change, and get abbreviated differently on every booking confirmation. A forwarder writes the name one way, the carrier's schedule another, and the bill of lading a third. If your exposure model joins bookings to vessel attributes by fuzzy-matching names, it'll attach the wrong operator to a shipment sooner or later. Then your exposure report is confidently wrong.

We've learned this one the expensive way in a different domain. In order-to-release automation we built for an operations-heavy client, the same misroute (an order booked to the wrong customer) came back five times in five different forms. The causes were a shared portal domain, a shared network domain, an affiliate email, a semantic embedding match, and a brand token sitting inside another company's name. One of them stayed dormant until a data backfill activated the code path. Replays showed that each candidate fix repaired some cases and broke others. The rule we wrote at the end applies directly to vessels: exact identifiers outrank similarity, and fuzzy matching only suggests. We wrote that rule up in Fuzzy Matching Must Never Book a Customer Order.

For ship fees, the IMO number is the exact identifier. If a booking arrives without one, the system can propose a match from name and voyage, but a person confirms it before that shipment counts toward exposure. That's one review step per unmatched booking, and it buys you an exposure report you can defend to your CFO.

Three Scenarios Worth Running Now

Here's what we'd set up, with the condition that should drive your attention to each.

Scenario A: the suspension holds. The fee stays at zero through your planning horizon. Run it as the baseline, so every other scenario shows a delta against current actuals. If your bookings mostly sit on carriers and vessels the triggering criteria don't reach, this baseline barely moves in the other scenarios either, and you've learned your exposure is small. That's a useful answer in its own right.

Scenario B: reinstatement, full pass-through. The rule reactivates on a date you choose, and carriers pass the cost through to you as a surcharge on exposed vessels. Apply the published rate to every in-transit and booked shipment on an exposed vessel that arrives after the date, then allocate through your real landed-cost rule. The output is a list of SKUs whose unit cost rises, ranked by margin impact. This is the scenario that tells pricing and sales what to expect.

Scenario C: reinstatement with carrier rerouting. Carriers move unexposed tonnage onto US lanes and push exposed vessels elsewhere. Your direct fee exposure falls, but schedules shift. Expect changed services, possible blank sailings, different transshipment points, and longer or less reliable transit. The cost here shows up as days, and days turn into safety stock, expediting, and missed in-hands dates. Model it as a transit-time distribution per lane instead of a single number.

Scenario C is the one we'd weight most heavily if your inventory runs lean or your customers buy against firm delivery dates. A fee you pay is visible and bounded. A schedule that slips by a week on a component feeding a production line is neither.

Be careful which date you treat as the truth when you model schedule slip. In the order-to-release work, the ERP's estimated ship date was re-baselined each time a schedule slipped, and it almost never matched the customer's requested date. A model that measures slip against a date that keeps moving will tell you nothing slipped.

Where Off-the-Shelf ERP Freight Modules Fall Short

Packaged ERP landed-cost and freight modules are built to allocate freight that already happened. That's the right design for closing a month. It's the wrong design for this question. Here's specifically where they break.

They learn the cost at receipt, not at booking. If landed cost posts when the freight invoice is matched or when goods are received, the module has no record of exposure for anything still on the water. By the time a reinstated fee hits a posted invoice, the routing decisions that could have avoided it are gone.

They don't carry vessel attributes. The freight cost element usually knows the carrier and maybe the shipment. It rarely knows the IMO number, the operator, or the build attributes a ship-fee rule keys on. Without those fields, there's nothing for a fee rule to evaluate.

Fixed cost elements can't express a conditional surcharge. A landed-cost setup that adds a percentage or a flat amount per receipt can't say "add this only when the vessel matches these attributes and arrives after this date." You end up approximating with a blanket uplift, which overstates cost on unexposed shipments and understates it on exposed ones.

Scenarios contaminate actuals. If the only way to see the reinstatement case is to enter the surcharge in the live module, you've written a hypothetical cost into the inventory valuation. Then someone has to remember to take it back out. A scenario needs its own space, reading the same bookings and allocation rules without touching what posted.

Routing comparison lives outside the system. Comparing alternate carriers or ports on combined fee exposure plus transit days usually means a spreadsheet export, which goes stale the moment a booking changes.

The condition that changes this answer is simple. If your ERP's freight module supports custom fields on the shipment, conditional cost rules with effective dates, and a simulation mode that doesn't post, configure it and don't build anything. Check those three things first. If any one is missing, you're looking at a small custom module, not a re-implementation.

Prove the Model Before Anyone Trusts the Number

An exposure model your finance team acts on needs a track record before they rely on it. Here's how we earn one.

Replay real bookings through the whole pipeline. Calling your fee function on a list of shipments gives you a fee per shipment. That's not the same as the landed cost a SKU ends up carrying, because allocation, currency, and any downstream adjustment all sit between the two. We learned this when an impact estimate that called a decision function directly overstated the effect, because a later gate in the pipeline reversed some outcomes. The corrected harness had to reproduce the old number first, so we knew the comparison was fair. The full lesson is in Replay the Pipeline, Not the Function. For ship fees, replay last quarter's bookings through booking capture, vessel matching, fee evaluation, and your real allocation rule, then compare against what actually posted with the fee forced to zero. If the zero-fee replay doesn't match your actuals, fix the model before you trust any scenario.

Include negative controls. Seed the replay with shipments you know are unexposed, such as carriers and vessels outside the triggering criteria. If any of them pick up a fee, a rule is wider than it should be. We once had a cleanup rule pass every check and then archive freshly customer-approved orders, because its test corpus contained no negative controls. It went off by kill switch, we restored the affected orders the same day, and we added negative controls. A fee model without negative controls can fail the same way, quietly overcharging shipments that should carry nothing.

Write the prediction down before the outcome. When the fee status changes, you'll get a real test of the model. Before it happens, record what the model says Scenario B will add to freight cost on a named set of shipments, and check it against the posted invoices afterward. We hold ourselves to this. When we shipped an address-matching fix in a quality-check system, we predicted beforehand that it would flip about 86 percent of a known failure class. In production, the address mismatch rate went from 34.4 percent to 2.9 percent. A prediction recorded before the event is the only kind that tells you whether the model works.

Deploy It Beside the ERP

You don't need to replace your ERP to answer this question, and we'd argue against it. The ERP stays the system of record for receipts, invoices, and inventory valuation. The ship-fee module sits alongside it.

• It reads bookings and purchase order lines from the ERP or from booking confirmations as they arrive.
• It holds the vessel reference table and the fee parameters table.
• It runs scenarios in its own space and writes nothing to the ERP's valuation.
• It publishes an exposure view per shipment and per SKU, with each figure traceable to the booking, the vessel record, and the fee rule that produced it.
• If you decide to post an actual surcharge, that goes through your normal freight invoice process, so the ERP stays the only place cost is booked.

This is the modular path. It runs in parallel with what you have, so nothing about your month-end close changes on day one. If the fee never comes back, you've added vessel capture to your bookings, a routing comparison, and a replay harness you'll use on the next freight surcharge, whatever its source. If the fee does come back, you flip one status and the exposure report is already there. Either way the cost of being wrong is small, and that's the point of building in increments.

Treat capture as the first increment. Get IMO numbers onto bookings and confirm matches by hand where the identifier is missing. Add the fee parameters table second, then the scenarios, then the routing comparison. Each step stands on its own and pays back before the next one starts.

Where We Could Be Wrong

If reinstatement would hit only a thin slice of your shipments, because your carriers and lanes sit outside whatever criteria the final rule uses, then the capture work is the main payoff and the scenario engine is optional. A quick exposure check on last quarter's bookings will tell you which side of that line you're on. Run that check before you build anything past capture. If the slice is thin, stop at capture and the parameters table. If it's thick, build the scenarios now, because the week after a reinstatement announcement is the worst time to start.

Start With Your Bookings

The fastest way to size your USTR China ship fees landed cost impact is to pull one quarter of bookings, attach vessel identifiers, and see how many sit on vessels a reinstated rule would reach. If you'd like help scoping that check and the module behind it, our ai consulting services start with your real booking data and your actual allocation rules, not a generic template.

Book a discovery call, and bring a quarter of bookings. We'll show you what the exposure looks like before the decision lands.