IEEPA Tariff Refund Process: Reconcile Every Entry Line

If you paid IEEPA tariffs and expect money back, the hard part of the IEEPA tariff refund process isn't the claim. It's proving which dollars belong to which entry line, which receipt, which inventory lot, and which period's cost of goods sold. Customs records duty one entry line at a time. A typical ERP suite folds that duty into a blended landed cost and spreads it across receipts. Once that happens, the trail you need for a clean refund is gone. Our position is to leave the ERP alone and build a thin reconciliation module beside it. That module carries the IEEPA portion of duty as its own cost component, joins records on exact identifiers, and checks every claimed line against the customs record in both directions. That's the module that catches the eligibility gaps a suite misses.

One plain caveat before we start. We aren't trade counsel or a customs broker. The legal status of IEEPA refunds, the filing route, and any deadlines are set by courts and Customs and Border Protection, so confirm them with your broker and counsel. Some things would change how the module is shaped. A route that pays refunds as entry-level lump sums would be one. A route that requires you to originate claims would be another. Neither changes the core requirement. You still need line-level traceability from customs record to inventory to ledger, and that is what this piece covers.

What the IEEPA tariff refund process asks of your records

A refund, or a claim for one, touches three record systems that rarely agree with each other.

The customs record. This is the entry, broken into lines. Each line carries a tariff classification, a value, and the duty assessed. On a single line that duty can stack ordinary duty, IEEPA duty, and any other tariff action in force at the time. The refund concerns the IEEPA portion only. If your records can't separate that portion at the line level, you can't say what you're owed.

The inventory record. This is the receipt, the lot, and the movement history. Goods that came in on one entry may have been received against three purchase orders. They may have been split across two warehouses, and some of them sold months ago. The refund relates to the goods, so you need to know where those goods went.

The accounting record. This is where the duty landed when you paid it. It may sit in inventory value, in cost of goods sold, in a purchase price variance account, or partly in all three. When the refund arrives, the credit has to reverse the original treatment, or your margins and inventory valuation for the affected periods are wrong.

None of these three records was designed to answer the question a refund asks: for this specific dollar of IEEPA duty, where is it sitting in my books right now? Answering it means joining all three, line by line.

Where ERP suites lose the trail

ERP landed-cost features do a reasonable job at the job they were built for. They get a defensible unit cost into inventory at receipt time. Refund reconciliation is a different job, and four design choices work against it.

Allocation flattens the duty program. A landed-cost run takes the duty on a broker invoice or entry summary and allocates it across receipt lines by value, weight, or quantity. The allocated amount usually goes in as one "duty" cost element. Whether a given dollar was ordinary duty or IEEPA duty doesn't survive the allocation. You can reconstruct it later only if you kept the source document and can redo the math.

Entries and purchase orders don't map one to one. One entry can cover goods from several purchase orders. One purchase order can arrive across several entries. Suites tend to attach landed cost at the receipt or purchase-order level, which makes the entry line a second-class citizen. The refund comes back keyed to the entry, and your ERP is keyed to the receipt.

Costing methods blend layers. Under average costing, the IEEPA duty on one shipment melts into the average with every other shipment of that item. After a few receipts, no unit carries an identifiable share of that duty. FIFO keeps layers longer, but those layers are consumed by sales, scrap, and transfers, and the ERP records consumption without remembering which entry fed each layer.

The refund comes in as one credit. The path of least resistance is a single journal entry crediting duty expense or inventory. That is fast, and it's wrong in two ways. It ignores that some of the original duty went to cost of goods sold in prior periods, and it hides any line that shouldn't have been in the refund at all.

We wrote about the planning side of this problem in SMB inventory planning under tariffs. The refund side is the same weakness running in reverse. A system that blended tariffs going in can't unblend them coming out.

The eligibility gaps that hide in blended cost

These are the specific mismatches a reconciliation module has to surface. Each one passes as normal inside a blended landed-cost number.

1. Lines in the right entry that never carried IEEPA duty. One entry can mix goods subject to IEEPA duty with goods that weren't. If the refund or claim is figured at the entry level and spread by your allocation logic, non-dutied lines pick up credit they never paid for.

2. Stacked duty on one line. A line that carried ordinary duty plus IEEPA duty plus another tariff action has three components. Only one of them is in scope. If your ERP stored the total, the split has to be rebuilt from the customs record. It can't come from the ERP.

3. Entries your system never matched. Your broker filed an entry and you paid the broker's invoice. The duty got allocated against the wrong receipt, or it sat unallocated in a clearing account. That entry is invisible to any report that starts from receipts, so it is also invisible to your refund tracking.

4. Entries filed under an identity you didn't expect. If affiliates, a related importer of record, or a broker arrangement put some entries under a different identifier, those entries can fall outside the scope of your query. They can also fall inside someone else's.

5. Credit already received. A partial refund, a broker credit, or any other recovery already applied to the same lines has to be netted out. Otherwise you claim it twice, or you book it twice.

6. Goods already sold. This doesn't affect eligibility. It does affect where the credit lands. Duty on goods still on hand reverses against inventory. Duty on goods already sold reverses against cost of goods sold, possibly in a closed period. An ERP that credits one account for the whole refund gets this wrong by construction.

7. Wrong mappings that look valid. This gap is the most dangerous because nothing about it looks broken.

We've seen how long a wrong mapping can survive, in our own systems. Inside POAPP, our own extraction system, a learned override mapped a generic charge line onto a legitimate product code that didn't belong on those orders. The product code was real and valid. The mapping was wrong. It survived about ten months and touched 201 distinct orders and 247 charge lines. Of those orders, 67 had been through human review, and an audit found that none of the 67 still carried the bad line. The reviewers did catch it, one order at a time. The other roughly two-thirds never had a human look at them. The edit log showed zero logged hand-edits for that code, because the corrections happened at approve time instead of as field edits. Nobody aggregated across orders.

What flagged it the whole time was a deterministic downstream comparison in QC-Check that asked one question: is this line actually on the source document?

Carry that over to tariff refunds. A duty line mapped to the wrong receipt has a valid entry number, a valid item, and a plausible amount. A reviewer looking at one receipt sees nothing wrong. The error only shows up when something compares the mapping against the customs record and adds up the results across entries.

How we'd build the reconciliation module

This is the module we'd put beside your ERP. It doesn't replace the ERP's landed-cost feature. It runs in parallel, reads from your existing systems, and proposes postings for a person to approve.

Treat the customs record as the source of truth

Start from the entry line, not the receipt. Bring in entry data from your broker's reports and documents. Where those documents arrive as PDFs, a deterministic parser reads what it can. A language model reads only the fields the parser can't settle, into a typed record. Deterministic code then validates that record against the numbers that have to agree, such as line duty totals against the entry summary. This is the same shape as our approach to semantic EDI. The model extracts meaning, and code decides whether the result holds together.

Join on exact identifiers. Fuzzy matching only suggests.

Entry number and line number. Purchase order number. Commercial invoice number. Container or bill of lading where you have it. Those are the join keys. An item description that "looks like" the receipt line can be surfaced as a suggestion for a person to confirm. It should never become the join by itself.

We learned this rule the hard way on order work. The same misroute, an order booked to the wrong customer, recurred 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. Every candidate fix repaired some cases and broke others. The rule that held was simple: exact identifiers outrank similarity. We laid out the full case in Fuzzy Matching Must Never Book a Customer Order. A duty refund mapped by similarity fails the same way.

Carry IEEPA duty as its own cost component

Going forward, split duty by program at the entry line and allocate each program as a separate cost element. For history, rebuild the split from the customs record and re-run the allocation outside the ERP, using the ERP's own allocation basis, so that the reconstruction ties back to what was posted. If the reconstruction doesn't tie, that discrepancy is a finding in its own right.

Trace forward through receipts, lots, and consumption

For each entry line, follow the goods to receipts, then to lots or cost layers, then to their current state: on hand, sold, scrapped, or transferred. Under FIFO this is a layer walk. Under average costing you can't recover unit-level traceability, so the module computes the on-hand versus consumed split from quantities and dates. It also flags this as an estimate method for your accountants to approve. Being explicit about that is better than pretending the ERP knows something it doesn't.

Check both directions, deterministically

Two checks, and both have to pass:

• Every line in the claim or refund exists in the customs record with IEEPA duty on it. This catches gaps 1, 2, 5, and 7.
• Every IEEPA-dutied line in the customs record appears in the claim or reconciliation. This catches gaps 3 and 4, the money you're leaving on the table.

These checks are plain code with no model in them. They answer yes or no, they cost nothing per run, and they fail differently from the extraction and matching steps upstream. That last property matters. A checker that shares the producer's blind spots confirms the producer's mistakes.

Replay the whole pipeline before you post anything

Run the full pipeline over your history and see what it would have produced, and include entries you know are out of scope as negative controls. Two lessons from our own work apply here. First, 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 before we trusted the new one. We wrote that up in Replay the Pipeline, Not the Function. Second, a cleanup rule passed every check and then archived freshly customer-approved orders, because its test set had no negative controls. We switched it off with a kill switch, fixed it, restored the affected orders the same day, and added the controls.

For a refund module, the negative controls are entries with no IEEPA duty, entries already credited, and entries under another importer identity. If the replay assigns refund credit to any of them, the module isn't ready.

Write the prediction down before you ship a fix. When we changed address matching in QC-Check, 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 written prediction turns "it seems better" into a test you can fail.

Keep the model and the module away from the ledger

The module proposes journal entries. A person approves them, and your normal posting process writes them. The model never writes to the ERP. On our own operational memory system, FRIDAY, the overnight coding agent reads through a dedicated read-only Postgres role. We smoke-verified that role: reads returned 61 rows and writes were rejected. The restriction is enforced by the database, not by a prompt.

Be careful how you get read-only access to a shared production database. In September 2026, a dry-run script of ours set a read-only session setting over a pooled production connection that a live application also used. For about fifteen minutes, a fraction of that application's writes failed as read-only, and some records and webhook deliveries were lost. We had written down that hazard after an earlier occurrence and didn't consult it. Our fix was a hard rule, a shared pre-flight that forces a direct connection with transaction-scoped read-only, and review checks. If your reconciliation reads from production ERP tables, build that pre-flight in from the first day.

What a human reviewer should see, and what they shouldn't be asked to do

A person belongs in this process, but the review step has to be designed. Two findings from our own measurements shape how we'd design it.

Don't route review by a confidence score until you've checked that the score means something. QC-Check's overall confidence score was measured anti-calibrated. Approvals in the top confidence buckets needed fixes 77 to 79 percent of the time. In the bottom buckets the figure was 53 to 59 percent. Sending only "low confidence" refund matches to review would have sent reviewers to the wrong pile.

Show patterns, not just individual exceptions. The wrong mapping we described earlier was caught every time a person looked at an affected order. It still lived for ten months, because nobody saw it as one problem spread across 201 orders. A refund review screen should group exceptions by cause. Examples would be "14 entry lines from one broker's reports where duty split didn't tie" or "all claims touching item family X allocated against average-cost layers." A reviewer can make one decision on a group. Clicking through records one at a time is how patterns stay hidden.

Give the reviewer the source document and the reason for every flag. Don't give them a dashboard to watch. A screen that only displays numbers adds work without catching anything. Every flag should state what failed and link to the entry line that proves it.

Build or buy for refund reconciliation

Here's the condition that decides it. Check whether your ERP stores duty by program at the entry-line level and keeps cost layers that tie back to entries. If it does, you probably need reports and a careful close process, not new software. Ask your ERP partner to show you that trail on one real entry before you assume it exists.

If it can't show you that trail, build. A refund reconciliation module is a bounded piece of work. It ingests the customs record, joins on exact keys, splits duty by program, traces through inventory, runs two-way checks, and produces proposed postings. It runs beside the ERP, reads without writing, and changes nothing in your existing close until you approve its output. That's modular deployment in its plainest form. You get value from the first entry it reconciles, and you can turn it off without unwinding anything.

It also keeps paying after the refund question is settled. The same line-level duty split and entry-to-lot trace is what you need to model the next tariff change before it hits your margins. We made that argument in Tariff Relief Supply Chain Software: Model It Now. A refund module and a tariff-scenario model share a foundation. Build the foundation once.

Our work for High Caliber Line follows the same pattern: custom extraction plus operations automation across a multi-stage print and manufacturing workflow, fitted to how the operation actually runs. Refund reconciliation is a different domain with the same discipline. The source document is the truth, code decides, people approve, and the existing system keeps running while the new piece proves itself.

Where to start this week

You can test your exposure before writing a line of code:

1. Pull five entries from the IEEPA period, including at least one that mixes dutied and non-dutied lines.
2. For each IEEPA-dutied line, try to trace the duty to the receipt, the lot or cost layer, and its current state.
3. Try the reverse: start from a receipt with duty allocated and find the entry line it came from.
4. Note every point where you had to open a PDF, ask the broker, or guess.

If all five trace cleanly, your records can support the refund. If you hit a guess on even one of them, the refund will expose the same gap across every entry you have.

If you want that trace built as working software, it's the kind of business process automation for operations teams we do. We model your actual landed-cost and inventory logic and deploy it in modules beside the systems you already run. Book a discovery call, bring the five entries, and we'll walk through the trace with you.

---