Tariff Relief Supply Chain Software: Model It Now

If you import from China and your margins depend on what happens to roughly $60 billion of goods now under discussion for US-China tariff relief, don't wait for the scope and timing to be defined. Build the scenario model now. Treat the relief as a set of parameters: which tariff lines, which dates, and how much. Run your own order book and cost data through a small piece of software that computes landed cost under each scenario.

That software should do deterministic arithmetic on your real data. It should not be a forecasting engine that guesses what the governments will do. It should run beside your ERP and leave the ERP alone. When the announcement lands, you change the parameters and you have an answer the same day. You don't start a spreadsheet project that week.

The rest of this piece covers what that model needs, where it breaks, and what we'd build versus buy.

What "undefined in scope and timing" means for your cost model

"Undefined" sounds like a reason to wait. For a cost model, it means you have a short list of unknowns, and each one can be named and parameterized:

1. Scope. Which products are covered. Relief on "$60 billion of goods" doesn't tell you whether your SKUs are in it. Scope will arrive as a list of tariff classification lines, and possibly with exclusions and conditions attached.
2. Timing. When relief takes effect, and which event in your shipment's life the effective date attaches to.
3. Magnitude. Full removal, a partial rate cut, or a phased reduction.
4. Your own mapping. Whether your product master maps each SKU to the right classification line. This unknown sits entirely inside your walls, and it's the one that quietly ruins scenario models.

The first three belong to the governments. The fourth belongs to you, and you can close it this week.

A scenario is one combination of values for scope, timing and magnitude. "Lines A through F covered, full removal, effective on a date 60 days out" is a scenario. "Only lines A and B, half-rate reduction, effective immediately" is another. You don't need to know which scenario is true. You need a system that can price any of them against your actual open orders, inventory in transit and forward demand, and can price a new one in minutes when the rumors shift.

The scenario model is deterministic math with uncertain inputs

We prefer code determinism. If a decision can be written as an if-statement, write it as an if-statement. Landed-cost math can be written that way. For each shipment line you know or can derive the unit cost, the quantity, the classification line, the country of origin and the applicable duty rate. The rest is multiplication, addition and a date comparison.

That makes the scenario engine small and testable:

• Inputs you own: open orders, in-transit inventory, forward buy plans, product master with classification lines, freight and brokerage cost assumptions.
• Inputs you parameterize: covered lines, effective date and date basis, rate change per line.
• Output: landed cost per SKU, per order, per customer and per month under each scenario, with the delta against today's baseline.

Every number in the output traces back to a line of input and a rule. When your CFO asks why a scenario says a product family gets cheaper in the third month, you can show the order lines and the date comparison that produced the result. A model that "predicts tariff impact" can't give you that audit trail. A deterministic calculator over uncertain parameters can.

Where does a language model fit? It fits in reading documents. It doesn't fit in doing the math. We come back to that below.

The part that breaks: mapping your SKUs to tariff lines

Scope will be published against classification lines. Your costs live against SKUs. The bridge between them is your product master, and that bridge fails far more often than the arithmetic does.

Here's the failure mode we'd worry about first. A SKU carries a classification that was right when someone set it up, then the product changed, or a variant got cloned from the wrong parent, or someone applied a "close enough" code. Nothing errors. The scenario engine happily computes relief for a SKU that won't get it, or withholds relief from one that will. Your scenario totals look plausible and the error stays hidden.

We've watched this class of error play out in our own extraction work, on a different field but with the same mechanics. A learned override inside our extraction system mapped a generic charge line onto a legitimate product code that didn't belong on those orders. The code itself was real and valid. The mapping was wrong. It survived about ten months and touched 201 distinct orders and 247 charge lines. Of the affected orders, 67 went through human review, and an audit found that none of those 67 still carried the bad line. The reviewers caught it, one order at a time. The other roughly two-thirds never got human eyes at all. Nobody aggregated across orders, so nobody saw a pattern. The whole time, a deterministic downstream check was flagging it by asking one question: is this line actually on the source document?

Carry that lesson into your tariff model:

• Exact identifiers outrank similarity. A SKU's classification comes from an exact, recorded value. It never comes from a model's guess about what the product "looks like." We wrote about the same rule for customer matching in Fuzzy Matching Must Never Book a Customer Order. Fuzzy matching can suggest a classification for a person to confirm. It never assigns one.
• Aggregate the checks. Run a report of every SKU whose classification changed, was cloned, or disagrees with the classification on its most recent commercial documents. One wrong SKU is a line item. The same wrong mapping repeated across a product family is the scenario result.
• Compare against the source. Your customs entries and broker documents record what was actually declared. A deterministic comparison between the product master and what was declared on recent entries catches drift that no reviewer looking at one shipment will see.

Do this cleanup before the relief list publishes. Once the list is out, you'll want to spend your time on decisions, and you won't be able to.

Timing: which date does relief key off?

Timing sounds simple until you ask which date. Your data holds several: the date you placed the order, the date goods left the factory, the vessel departure, the arrival, the customs entry, and the date you expect to ship to your own customer. Which of those the effective date applies to is a question for your customs broker or trade counsel. Nobody should settle it by assumption in a spreadsheet cell. Your software should hold the answer as a parameter, so you can run "relief keys off departure" and "relief keys off entry" side by side until the rule is clear.

Then there's the problem of which dates you can trust. We've measured this on order data for an operations-heavy client. The ERP's estimated ship date gets re-baselined as schedules slip. It almost never matched the customer's requested date, and the misses showed no directional bias. The in-hands date was missing on a large share of open orders. We wrote that up in ERP Ship Date Is a Schedule, Not a Fact.

For tariff scenarios, that has a direct consequence. If your model decides which shipments fall inside the relief window by reading the ERP's current ship estimate, the answer will change every time the schedule moves. Your scenario totals will then drift for reasons that have nothing to do with tariffs. Build the timing logic on the milestone the rule keys off, from the most authoritative source for that milestone. Carrier and broker data beats a re-baselined estimate. When the date is missing, flag it. Don't default it.

The timing question is also where scenarios become decisions. If a relief date looks likely inside the next quarter, you face real choices. You can pull a shipment forward, hold it, or split an order. Those decisions depend on per-shipment dates being right, which is why the date layer deserves more engineering attention than the rate layer.

Model the whole landed-cost chain, not just the duty line

The fastest scenario model multiplies the duty rate change by the declared value and calls the result the impact. It overstates the benefit, and the reason is structural.

Relief on the duty line travels through a chain of downstream steps. Some of that chain is contractual. Customer pricing may be tied to cost with a lag, or promised at a fixed price, or covered by a surcharge you added when tariffs went up and may have to remove. Some of it is operational. Freight, brokerage and holding costs change if you move a shipment to catch the window. Some of it sits in your own policies, such as rules about which inventory gets drawn first.

We learned this lesson on a different kind of estimate. An impact estimate that called a decision function directly overstated the effect, because a later gate in the pipeline reversed some of the outcomes. The corrected harness first reproduced the old number, then ran the full pipeline, and only then did we trust the difference. The write-up is Replay the Pipeline, Not the Function.

The same discipline applies to tariff scenarios:

• Start by reproducing today. Before you run any relief scenario, the model has to reproduce your current landed cost and margin from real data within a tolerance you'd defend. If it can't reproduce today, its view of next quarter is fiction.
• Run the change through every step. Duty change, then surcharge or pass-through rules, then customer contract terms, then any shipment moves the scenario triggers, then margin.
• Report both numbers. Show the gross duty change and the net margin change together. The gap between them is the part of the relief you don't keep. Your sales team needs to see it before customers start asking for price cuts.

Write the prediction down before the relief lands

A scenario model earns trust the same way any model does. You record a prediction before the outcome and compare the two afterward.

We hold our own work to this. Before an address-matching fix in our QC-Check system shipped, we predicted it would flip about 86 percent of a known failure class. In production, the address mismatch rate fell from 34.4 percent to 2.9 percent. The fix mattered, and so did the fact that we wrote the prediction down first. That turned "it seems better" into a measurement.

For tariff relief, do the equivalent:

1. Freeze your scenario set and your baseline data on a specific date.
2. Record each scenario's predicted landed-cost and margin delta per product family.
3. When the actual scope and timing publish, pick the matching scenario, or add the real one.
4. After the first full month under the new rates, compare predicted against actual, line by line.

The misses will point you at the weak inputs. You'll find the SKU with the wrong classification, the customer whose contract passes cost through differently than you assumed, and the lane where the date data was stale. The next policy change will come, and the model will be better for it.

Build or buy: what tariff relief supply chain software should look like

You have three realistic options.

Spreadsheets. They're fast to start and fine for a first look at a handful of SKUs. They break on exactly the parts this piece is about. Nobody can audit a mapping from SKU to classification line that lives in a lookup tab. Date logic spread across formulas re-reads a moving ERP field every time someone refreshes the workbook. Nobody can replay last month's scenario against last month's data. If your exposure fits on one sheet, stay with the sheet. If it spans hundreds of SKUs, several customers with different contract terms, and inventory at several points in transit, the spreadsheet becomes the risk.

ERP planning modules or off-the-shelf trade tools. Buy one if it already models your classification data, your date milestones and your customer pricing rules without customization. Test that claim against your own data before you sign. Where these tools fall short is the chain after the duty line. Your surcharge logic, your contract terms and your allocation rules are specific to your business, and a generic tool will either leave them out or ask you to reshape them to fit its schema.

A focused custom module. This is where we'd go for an importer whose tariff exposure touches pricing and customer commitments. It's one module that reads from your ERP, your broker data and your product master, with read access only. It computes scenarios deterministically and reports gross and net deltas. It changes nothing in the ERP, so it runs in parallel with everything you already have. It's small enough to scope in a single engagement and specific enough to model your actual logic chain. It keeps its value after this round of relief, because the next policy change arrives as a new set of parameters for the same engine.

That last point is the build-vs-buy answer in one line. The uncertainty won't stay confined to this $60 billion package. Tariff scope and timing will keep moving. Software that treats policy as parameters over your own business logic becomes a standing capability. A one-off analysis gets thrown away. If you're weighing that kind of build across the rest of your operation, our page on AI for supply chain operations covers how we scope it.

Where AI belongs in a tariff scenario model

Keep the language model out of the math. Put it to work on the documents.

The scenario engine needs clean inputs, and some of those inputs arrive as documents nobody keyed into structured fields: commercial invoices, packing lists, broker entry summaries, emailed customer contracts with pass-through clauses. A model reads those well and turns them into typed records. Deterministic code then validates each record against your product master, customer list and price data. Anything that fails a check goes to a person along with the source document and the reason it failed. This is the pattern we describe in What Is Semantic EDI?, and it transfers directly.

Two measured results from our own stack shape where we draw the line:

• Model reads, code decides. On a set of hard document decisions, having the model read and code decide scored 59 of 64. Having the model decide scored 54 of 64. A tariff model has far more decision logic than that test, and every rule you can express in code should live in code.
• Confidence scores aren't a gate. QC-Check's overall confidence score measured anti-calibrated. The top confidence buckets needed fixes on 77 to 79 percent of approvals, against 53 to 59 percent in the bottom buckets. If a vendor tells you their tool auto-classifies SKUs "with high confidence," ask how that confidence was calibrated against labeled outcomes. Until you see that measurement, treat every model-suggested classification as a suggestion.

When we build these modules, the reading layer runs on ATLAS, a domain-scoped engine that stays inside the boundaries of the documents and data it's given. For a tariff model, that's the property you want. When a line isn't on the document, the correct answer is "not present," and the engine shouldn't produce a plausible guess to fill the gap.

Where we could be wrong

If the relief lands as a simple, broad, immediate cut with no line-level conditions, a careful spreadsheet may get you most of the answer. In that case the custom module's advantage shrinks to the pricing and contract chain after the duty line. That still matters, but it's less urgent. What would change our answer is a clean, fully specified announcement arriving soon. We wouldn't plan around that. Even in that case, the classification cleanup and the date audit pay for themselves the next time policy moves.

What to do this week

Start with the parts you control. None of it requires knowing what the governments will decide.

1. Audit the SKU-to-classification mapping. Compare the product master against recent customs declarations. Flag every disagreement, clone and recent change.
2. Pick the date basis candidates. Ask your broker which milestones the effective date could plausibly key off. Confirm you have authoritative data for each one, and list the orders where that date is missing.
3. Reproduce today's landed cost. Get a baseline that matches your actual margin within a tolerance you'd defend in front of your CFO.
4. Define three to five scenarios. Cover narrow and broad scope, near and later timing, full and partial magnitude. Freeze them and record the predictions.
5. Decide build or buy against your own data. Bring your product master and one month of shipments to any vendor demo. If the tool can't reproduce your baseline, it can't price your scenarios.

When the scope and timing are published, you'll be picking a scenario and executing it. If you'd like help scoping the scenario module around your own data, book a discovery call. We'll start from your baseline and build the first increment to run in parallel with what you already have.

---