FedEx to Begin Returning IEEPA Tariff Refunds to Customers Starting in August, Prioritizing Data-Sharing Shippers

The Analysis

A refund is not a payment, it is a reconciliation, and reconciliations are won or lost on documents. On June 25 FedEx said it will start returning tariff refunds to eligible customers in August. The money traces back to IEEPA duties that the Supreme Court invalidated, which is what set this large-scale reimbursement in motion. The carrier also said it will give priority to shippers that opt in to sharing shipment and refund data with vendor partners. UPS and DHL had already set out their own approaches earlier in 2026, and the three versions do not read the same.

I read an announcement like that the way I read every announcement: what does the importer have to hand over, and by when. Not what is being promised, what is being asked for. Because every refund I have worked on ends up in the same shape. The party holding the paper gets paid first, and the party reconstructing the paper from memory gets paid somewhere near the end of a very long queue.

My own observation after years of this: the expensive part is rarely the rate being wrong. A rate error gets corrected by arithmetic on somebody else's side of the desk. The expensive part is a row that cannot be matched. An unmatched row does not get argued about, it gets parked, and parked rows are how a refund quietly becomes a fraction of what it should have been.

Start with who holds which piece of paper, because a refund is claimed from records and not from memory. On one IEEPA entry there are usually four holders. The importer of record holds the commercial invoice, the purchase order and the contract clause that says who bears tariff cost. The broker holds the entry summary and the line-level duty calculation. The carrier holds the waybill, the billing record and, in many cases, the proof that duty was advanced on your behalf. Then there is a fourth holder who only exists if you say so: the vendor partners a carrier uses to process refunds, who only see your shipment and refund data if you opt in. Three of those four you already control. The fourth you switch on.

A small discipline that pays for itself at claim time: the commercial invoice, the entry summary and the carrier's billing record have to agree on three numbers before you ask for anything, and those three are the duty amount, the entry reference and the party named as importer of record. The mismatches I meet most often are dull ones. The reference on the invoice is a purchase order number rather than an entry number. The duty figure on the carrier's bill is the total it advanced, which includes charges that are not duty at all. And the importer of record is the trading entity printed on the invoice instead of the entity that actually cleared the goods, which happens every time a group runs several legal entities through one shipping desk. None of those three stop a claim. All of them cost a fortnight while somebody proves what should have been written down at the time.

What I want in front of me before I touch anything is an entry-level list. Not a total, a list. One row per entry: entry number, filing date, the tariff lines on it, the duty amount paid under the authority that was invalidated, the date the duty was paid, who the importer of record was, who actually paid it, and where the status stands now. If your entries only exist inside a broker's monthly summary, this is the week to go and get them. Everything downstream is a lookup against that list, and a list with holes produces a refund with holes.

Which columns go on the list matters nearly as much as having one at all. Beyond the fields I named, I keep five that most people leave out: the date the claim was acknowledged, the reference the other side gave it, the amount they say they hold, the amount they have released, and the reason code whenever part of a claim is rejected. The reason code is the valuable one. Once you have twenty of them you can see which rows of yours are wrong in the same way every time, a tariff line that is always missing or a value basis that never matches, and then you fix the source instead of fighting the symptom a hundred separate times.

Now the change windows, which is where most of the pain sits. An entry that has already been filed is not a document you edit; putting it right runs through whatever formal process applies, and I am not going to tell you what that process is or how long it allows, because that is exactly the kind of thing I am not qualified to state and it varies with the facts of the individual entry. What you still own is the data package you hand over. Before the carrier starts processing, a missing row is a phone call and a corrected spreadsheet. After processing starts, the same missing row is a dispute sitting behind a queue. Same problem, ten times the calendar. Which is why a sentence I repeat all the time applies here as well: this one can still be saved, but it has to be before this afternoon, and this afternoon means before the batch you are sitting in gets calculated.

Here is the time account for a single entry, because the week-by-week picture is what decides whether this hurts. Day one, the row exists on your list with a duty amount attached. Day two to three, the three-way match runs and either agrees or throws a discrepancy. If it agrees, the rest is waiting. If it throws one, you have a window: while the carrier is still assembling its batch, a corrected row is data; once the batch is calculated, the same correction becomes a claim against a settled number. Assume a working week from discrepancy to answer when you hold the documents on the shelf, and assume three weeks or worse when the entry has to be rebuilt from somebody's archive. That gap is the entire difference. Time here is bought with documents you already have, which is why the list is the job.

The opt-in is the decision with the most consequence behind it and usually the least thought. The carrier has said it will prioritise shippers that agree to share shipment and refund data with vendor partners, so the practical reading is that opting in moves you up a queue. The other side of the trade is that you are authorising data to move to parties you did not contract with directly. Before anyone signs, I want one page with five things on it: which fields leave, who receives them, what they may use them for, how long they keep them, and who inside your company can withdraw the authorisation. If your shipment data carries buyer names, supplier names or unit pricing, all of that is in scope, and moving up a refund queue is not a good reason to hand over a customer list by accident.

Then comes the reconciliation, and I treat it as a three-way match. Your list, the broker's entry records, and whatever the carrier tells you it is refunding. Run it weekly rather than monthly, because a mismatch found in week one is a data fix and a mismatch found in month three is an argument. Set the threshold before you start: any entry where the refunded amount differs from your list by more than five per cent or five hundred dollars, whichever is lower, goes onto a dispute list with a date against it. Without a threshold, people spend meetings arguing about whether sixty dollars is worth chasing, and that answer should have been written down before the first refund arrived.

Numbers, with every assumption stated. Assume you have 120 entries that carry IEEPA duty across the affected period. Assume the average duty paid per entry was $2,400, which puts $288,000 at stake. Assume refunds arrive in three waves, forty per cent across August and September, forty per cent across October and November, twenty per cent in December. Assume your cost of capital is eight per cent a year and simplify the timing to an average of three months of money outstanding. The carrying cost of the wait is then about $288,000 times eight per cent times a quarter, roughly $5,760, which is small against the principal and is the wrong thing to optimise.

Now assume fifteen per cent of entries, eighteen of the 120, cannot be matched on the first pass because a tariff line is missing, an amount disagrees, or the importer of record on your list is not the party the duty was billed to. Assume each of those takes two person-days to resolve. That is thirty-six person-days. Put your own day rate against it and the rework costs more than the money did. The lesson is boring and it repeats: the refund is not lost in the rate, it is lost in the rows nobody can match.

So the schedule, with owners. This week, build the list and get it to one hundred per cent of entries with duty paid, even if half the rows are marked unverified; an unverified row you know about is worth far more than a row you never wrote down. Before the end of July, take the data-sharing decision in writing, one page, five questions answered, signed by whoever owns data authorisation in your company, with the date logged. From the first week of August, reconcile receipts against the list every week and raise anything over the threshold within forty-eight hours, recording the timestamp when it went out. Before the end of September, drive the share of entries still unresolved below ten per cent, and escalate to the party that filed it any entry that has had no substantive answer for thirty days. Who owns it: one named person, not a department. A reconciliation owned by a department is owned by nobody, and it will show up in October as a pile.

On the working rhythm, I keep two things fixed: a named owner per carrier and one weekly slot. One person who can say, for any row, where it stands and what is missing, and one hour a week, same day and same time, when the ledger is opened and discrepancies are triaged. A refund process run on spare attention behaves exactly like an inbox, everything urgent gets answered and nothing important gets finished, and the rows that need reconstructing quietly age while everyone is busy. That weekly hour is not a strategy meeting. It is forty minutes of matching numbers and twenty minutes of sending emails with timestamps on them.

Alternatives, and what each one costs. You can decline the data sharing. The sensible reading of the announcement is that you then wait longer, and waiting carries the carrying cost I priced above plus the risk that your rows are still unresolved when attention moves on to something else. That can be the right call if your data sensitivity is high, but make it as a decision rather than by default. You can also have a broker or a third party run the claim for you, and the things to pin down are the scope of the authorisation, who owns the data that gets produced, and the path the money takes. Ask one question before anything else: is the refund coming back to the importer of record, to the party that actually paid the duty, or to whoever happens to be holding the paper? Those can be three different parties, and the difference arrives as a cash surprise in a quarter when you were not expecting one.

The trap that catches well-run companies is the contract. If you sold on delivered terms and carried the tariff cost inside your own margin, the refund probably belongs to you; if the tariff was passed through and borne by a buyer or by a supplier, the answer may sit somewhere else entirely. I am not deciding that and I am not going to tell you what your contracts say. Read them. Pull the clause that allocates duties, note which entries it covers, and put it beside the refund list before a single dollar gets booked as income. The fastest way to turn a refund into a dispute is to spend it before you have checked who it belongs to.

One caution on the money itself. Do not let a reimbursement be treated as cash before it is in the account. I have watched a finance team book an expected refund against a quarter, price a customer on the strength of it, and then spend two months explaining a variance when the third wave slipped. Book it when it lands, keep the expected figure in a memo line, and when somebody needs a number for planning, give them the amount claimed, the amount received and the gap, on the same line, every week. The gap is the only figure in this process that anybody can actually manage.

One more practical point on authorisations, because it is where companies get surprised. If a broker or an agent is going to pursue the claim for you, the authority they hold is whatever the document you signed says it is, and I have seen a general customs authorisation drafted years earlier used to justify rather a lot. Read what you already signed before you sign anything else. If it says nothing about refunds, say so in writing in the new one, and file both in the folder for that entry. I am not advising you on what to sign. I am telling you that the scope of what you signed is the first thing that gets argued about when money arrives and two parties both expect it.

Two more traps. The first is the amount basis. Duty, fees and any charges the carrier advanced are not one number, and a refund that matches your duty line but not your invoice total is not automatically wrong. Write down which figure you are reconciling against, then reconcile to that figure rather than to a feeling. The second is timing limits. There are deadlines attached to entries and to disputes, and I am not going to quote one, because I would be guessing at something with consequences attached and the answer depends on facts I do not have. How the ruling lands on any individual entry, and what limits follow from that, is Dr. Ingrid Voss's ground, not mine. What I can do operationally is sort the list by filing date and work the oldest rows first, because whatever the limit turns out to be, the oldest entries are the closest to it.

One more thing from the same reporting. UPS and DHL set out their own approaches earlier in 2026, and FedEx's version is not their version. Do not take one carrier's timeline, one carrier's data request or one carrier's priority rule and assume it transfers to the others. If you ship on more than one, keep a separate list per carrier with the carrier named on every row, and reconcile each against what that carrier actually told you. Mixing them is how a team loses a month arguing about a figure that was never going to match in the first place.

On records, one folder per entry: the entry summary, the proof of duty payment, the refund notice with its date, every discrepancy raised with the time it went out and the answer when it came back, and a closing reconciliation showing amount claimed, amount received and the difference. Retention follows whatever your compliance function sets, and I am not inventing a number. The folder earns its keep the second time somebody asks why an entry settled for less than was claimed, which, in a process this size, is a question you should expect to be asked.

There are roughly two weeks before August starts, and that is how I would spend them if the ledger were mine. The first week goes to the rows: entries from the broker, duty figures from whoever paid them, and the tariff clauses from whoever owns the commercial terms. The second week goes to the decision and a rehearsal. Sign or decline the data sharing on paper, then take twenty entries and run the three-way match end to end as a dry run. Twenty rows will expose every broken column in your ledger while fixing them is still cheap, and within a day they will tell you whether your rows are shaped the way the carrier expects them to be. A rehearsal is worth more here than any amount of planning.

None of this is glamorous and none of it is a legal position. A court invalidated the duties, carriers are getting money back to the people who paid them, and one carrier has said it will start in August and will move faster for shippers willing to share data. What you control is narrower than all of that: a list of entries that is actually complete, a decision about data sharing that somebody made in writing, a weekly reconciliation with a threshold agreed in advance, and a folder per entry. Do those four and the refund arrives as money. Skip them and it arrives as a series of emails, which is the way refunds usually die.

↑ Back to the key points

— By Derek Xu