FMC Spanish Vessel Fees: Re-Map Your Ops Systems Now

The FMC's proposed fees of up to $200,000 per voyage and its proposed import restrictions on Spain-linked goods will reach importers' operations systems before they reach the courts. Our position is simple. Don't wait for the final rule. Build the exposure logic now, as parameterized rules in a module that runs beside your ERP, so that when the rule is final you change a few values instead of rewriting your landed-cost and compliance logic under deadline. The FMC Spanish vessel fees supply chain impact is a data problem first. "Spain-linked" is a property of routing, vessels, and component origin, and your item master probably doesn't record any of those. Fix that now and the rule's final shape barely matters.

One condition applies. If no tier of your supply chain touches Spain, whether through origin, vessel, port call, or component, you can stop reading. Most operators can't confirm that today, and that inability is the actual problem.

What the proposal changes, in operational terms

The policy debate has its own audience. Operationally, the proposal changes three things in your systems.

A cost charged per voyage. Your ERP allocates freight per unit, per line, or per shipment. A fee assessed on a sailing doesn't fit any of those. Someone has to divide it, the carrier will decide how much of it reaches you, and your share depends on what else was on the ship.

A restriction that turns on a link. "Spain-linked" could mean Spanish origin. It could mean a Spanish-flagged or Spanish-operated vessel, a call at a Spanish port, or Spanish-origin inputs inside goods finished somewhere else. Each reading needs different data, and your systems hold almost none of it at the level a regulator would ask about.

A new burden of proof. When a shipment is held, "our supplier is in Portugal" doesn't settle anything. You need the documents that show origin, routing, and vessel. You also need to find them in minutes, without three days of email.

We'll state the limit of our knowledge plainly. This is a proposal. We don't know the final scope, the effective date, how "Spain-linked" will be defined, or how carriers will pass the fee through. That uncertainty is the reason to build the logic as rules you can configure. If you hard-code a guess, you'll rebuild it later.

Why your ERP's landed cost breaks on a per-voyage fee

Standard ERP landed-cost modules handle costs that scale with something you control: weight, value, quantity, cube. You set a freight rate or a percentage, the system spreads it across receipt lines, and inventory valuation picks it up.

A per-voyage fee doesn't scale with anything you control. Here is how it works:

• The fee attaches to the sailing.
• The carrier decides whether and how to pass it through, as a surcharge per box, per bill of lading, or folded into the base rate.
• Your share depends on how many other boxes were on that sailing. A full ship and a half-empty ship produce different numbers.
• At PO time you often don't know the voyage. You know a requested ship window, and that date moves.

That last point matters more than it seems. In our own order-to-release work for an operations-heavy client, the ERP's estimated ship date was re-baselined as schedules slipped, and it almost never matched the customer's requested date. A landed cost calculated at PO time against an assumed voyage is a forecast. If your system treats it as a fact, your margin reports will be wrong precisely on the shipments that carry the exposure.

The fix has three parts.

1. Split landed cost into estimated and actual. Estimate at PO time from scenario assumptions. Recalculate at booking, when the vessel and voyage are known. True up at receipt, when the carrier invoice arrives. Store all three, because the gap between them is how you measure your exposure.
2. Model pass-through as a parameter. Keep a carrier-level setting for how a voyage surcharge reaches you: per container, per bill, percentage of freight, or zero. When the first invoices arrive, set it from the evidence instead of a guess.
3. Carry voyage identity on the shipment record. Vessel and voyage need to be fields your costing logic can read, not text buried in a booking confirmation PDF.

A spreadsheet doesn't do this well, because the spreadsheet lives outside the transaction and never gets the true-up. It also isn't worth replacing an ERP to get. You need a costing layer that reads your ERP's receipts and writes adjusted landed cost back through an interface you control.

"Spain-linked" is a data question your item master can't answer

Ask your team a direct question. For every SKU you import, can the system tell you whether any input, any vessel, or any port call on its typical route touches Spain?

For a typical setup the answer breaks down like this:

• Country of origin sits at the item level, set once at onboarding, often copied from the supplier's first commercial invoice.
• Component origin isn't recorded. If a finished good from a third country contains Spanish-origin inputs, nothing in the ERP knows.
• Routing sits in the forwarder's system, in booking confirmations, and in bill of lading PDFs. The ERP sees a port of entry and an arrival date.
• Vessel identity shows up on documents, never on the item, and rarely on the PO.

So the re-mapping has to cover three layers.

Item layer. Add component-origin attributes where a link through inputs is plausible. Don't do this across the whole catalog on day one. Start with the categories where Spanish inputs show up in your bill of materials or your suppliers' declarations.

Supplier layer. Record each supplier's production sites and their usual export ports and carriers. A supplier with its headquarters in one country and its plant in another is a different exposure from what its address field suggests.

Shipment layer. Capture vessel, voyage, port of lading, transshipment ports, and port of discharge as structured fields on every inbound shipment, extracted from the documents you already receive.

This connects to something we saw directly in order entry automation. When we studied what staff edited after automated extraction, most edits filled in fields the source document never contained, or re-keyed values that had already been captured in the wrong shape. Expect the same here. A large part of the "Spain-linked" work will be gap-filling: data that no document gave you, which someone has to go and get. Plan for supplier questionnaires and declarations, and give your team a place to record the answers as data rather than in an inbox.

Compliance checks belong in deterministic code

When a restriction turns on a link, the screening logic has to be exact and auditable. You must be able to answer "why did this shipment pass?" with a rule and a document, not with a probability.

This is how we'd structure it, and it's the same pattern we use for order intake in what we call semantic EDI.

1. A model reads. Commercial invoices, packing lists, certificates of origin, and bills of lading arrive in every format. A language model, or a deterministic parser first where the layout allows, extracts the business meaning into a typed record: origin per line, vessel, voyage, and every port in the routing.
2. Code decides. Deterministic rules check that record against your configured definition of "Spain-linked." If the definition counts transshipment, the rule checks transshipment ports. If it counts component origin, the rule checks the item's component attributes.
3. Exact identifiers outrank similarity. A port code, a vessel identifier, or an HTS line is matched exactly. Fuzzy matching on names can suggest a link for a person to confirm. It never clears or blocks a shipment on its own. We learned this the hard way in customer matching: the same misroute came back five times in five different forms, and the rule that held up was that exact identifiers outrank similarity.
4. Failures go to a person with the reason attached. A flagged shipment reaches a reviewer with the source document and the specific rule that fired. "Transshipment at a Spanish port on the bill of lading, page 2" is something a person can act on. A confidence score isn't.
5. A separate check compares output to source. After the record is written, a downstream check asks whether each recorded port and origin actually appears on the source document. We run checkers that fail differently from the system that produced the record, because a checker that shares the producer's blind spots catches nothing.

Don't let a model's confidence stand in for the rule. In one of our own pipelines, the overall confidence score turned out to be anti-calibrated. The top confidence buckets needed fixes on 77 to 79 percent of approvals, against 53 to 59 percent in the bottom buckets. A screening system that waves through high-confidence records would have been wrong most often exactly where it trusted itself most.

Re-mapping sourcing: scenarios, not a single forecast

Once origin, routing, and vessel are data, sourcing decisions become something you can compute. Before that, they're opinions in a meeting.

The useful output is a scenario table per lane and per SKU family, with these columns:

• Exposure under each definition. How many open POs and in-transit shipments are Spain-linked if the rule covers origin only, origin plus vessel, origin plus port calls, and the full set including components.
• Landed cost delta under each pass-through assumption. Per container, per bill, and absorbed by the carrier.
• Alternative routings. Which lanes avoid Spanish port calls, at what transit-time cost, and with which carriers. Our port diversification guide covers how to model alternate gateways without rebuilding your network plan in a spreadsheet.
• Alternative suppliers for components. Where a Spanish-origin input is the only link, a component substitution may be cheaper than rerouting the finished good.

Two rules keep this honest. First, the scenario engine reads the same rule definitions as the screening logic. If they drift apart, your sourcing team will plan around one definition while compliance enforces another. Second, every scenario records the assumptions behind it, so that when the final rule is published you can see which plans still hold.

This is where operational software earns its keep. The model of your business logic (which supplier, which plant, which lane, which carrier, which cost basis) already exists in your team's heads and in their spreadsheets. Writing it into software that fits how you source turns a policy shock into a parameter change. That work is the core of our AI for supply chain operations practice: a model reads the documents, and deterministic code decides.

Replay before the rule takes effect

When the final rule is published, you'll want to know the answer to "what would this have flagged last quarter?" before you turn anything on. Replay your history through the new logic.

Do it carefully, because replay is easy to get wrong in two specific ways we've hit ourselves.

Replay the whole pipeline, not the one decision. We once estimated the impact of a change by calling the decision function directly. The estimate overstated the effect, because a later gate in the pipeline reversed some of those outcomes. The corrected harness first had to reproduce the old number before we trusted any new one. The same trap applies here. If your broker review or your forwarder's own screening downstream would have caught a case, a function-level replay will count it twice. We wrote this up in Replay the Pipeline, Not the Function.

Include negative controls. In another case, a cleanup rule passed every check we had, then archived freshly customer-approved orders in production, because its test set had no examples of things it should leave alone. We switched it off by kill switch, fixed it, restored the affected orders the same day, and added negative controls. For a Spain-linked screen, the negative controls are the shipments that look close but aren't in scope: Portuguese origin through a Moroccan port, a Spanish-named supplier with a plant elsewhere, a vessel whose name resembles a flagged one. If your replay set doesn't contain them, a clean replay proves nothing.

Build it beside the ERP, not inside it

The instinct is to open a ticket with your ERP partner and ask for a customization. We'd go the other way, for three reasons.

The rule will move. A proposal becomes a final rule, the final rule gets amended, and enforcement guidance arrives later. ERP customizations are slow and expensive to change, and every change carries upgrade risk. A separate rules module changes on your schedule.

Parallel operation de-risks it. Run the new screening and costing logic in shadow mode next to your current process. It reads the same shipments and documents and produces its own flags and landed costs. Compare its results with what your team does by hand for a few weeks. Turn on enforcement only when the disagreements are understood. If something breaks, your existing process is still running.

Watch the downstream station, not just the gate. When we turned on an automatic release in an order pipeline, it looked clean at the gate. The floor then sent most of those releases back for missing art and shipping instructions. We paused it, added a circuit breaker on the send-back rate with a minimum sample size, and re-enabled it narrowly. For trade screening, the downstream station is your customs broker and your receiving dock. If shipments your screen cleared start getting held, or your broker starts sending back entries for missing origin evidence, the screen is wrong, whatever its pass rate says. Give that signal a threshold that pauses enforcement automatically, and make sure someone actually reads it.

The module boundaries we'd draw:

1. Document extraction for inbound trade documents into typed records.
2. Trade-rule screening with the definition of "Spain-linked" held as configuration.
3. Landed-cost layer with estimated, booked, and actual cost, plus carrier pass-through parameters.
4. Scenario engine that reads the same rule configuration.
5. Evidence store that keeps the documents behind every screening decision, retrievable by shipment.

Each module ships on its own. Extraction and the evidence store pay off even if the proposal dies, because they also answer the questions your broker already asks today. Screening and costing switch on when the rule is final.

We've built this shape before. For High Caliber Line, we built custom extraction plus operations automation across a multi-stage print and manufacturing workflow, where documents arriving in many formats become structured records that downstream steps can trust. Trade documents are a different domain, but the pattern is the same: read with a model, decide with code, check against the source.

What would change our answer

If the final rule turns out narrow and precise, for example origin-only with an official list of covered goods, much of the routing and vessel work becomes optional. You'd still want structured origin data and an evidence store, but the scenario engine shrinks to a cost table.

If the proposal is withdrawn, the routing, vessel, and component-origin fields you've added remain the data that every trade measure of this kind turns on. The next restriction will have a different country attached. Your data model shouldn't care which one.

Either way, the work in the first two modules isn't wasted. That's why we'd start now.

Where to start this week

1. Run the exposure question. Pull your open POs and in-transit shipments. For each one, record whether you can answer yes or no on Spanish origin, Spanish-linked vessel, Spanish port call, and Spanish component origin. Count the unknowns. That count is the size of your data gap.
2. Inventory your documents. List which documents carry vessel, voyage, and routing for each lane, and where they live today: email, forwarder portal, or a shared drive.
3. Ask your carriers how they would pass through a voyage fee. Record the answers as parameters, even when the answer is "we don't know yet."
4. Split landed cost into estimate, booking, and actual in your reporting, even before you automate it.
5. Write down the definition you'll screen against, with every reading of "Spain-linked" listed as a separate switch.
6. Build a replay set with negative controls from last quarter's shipments, so you're ready to test the moment the rule is final.

If you'd like help scoping the extraction, screening, and landed-cost modules so they run in parallel with your current ERP, book a discovery call. We'll start with your exposure count and the documents you already receive, and we'll tell you which module to ship first.

---