Duty Drawback Software: How Importers and Exporters Recover Duty That Currently Expires Unclaimed

The money is already yours, and it expires quietly

Drawback is unusual among trade programmes because it does not reduce a future cost. It returns duty you have already paid, up to 99 percent of it in the United States, when the goods or their substitutable equivalents are exported or destroyed. The claim window is generous by regulatory standards, measured in years from importation, which creates the illusion that there is no hurry.

What actually happens is that the data required to prove a match ages faster than the window. Import entry data sits with a broker. Export documentation sits with a freight forwarder or in a sales system. Manufacturing consumption sits in an enterprise resource planning (ERP) system that overwrote the relevant records during a cycle count. By the time anyone tries to assemble a claim, the transactions are there but the linkage that would prove them is not, so the claim is scoped down to the part that is easy to prove.

That is the real leakage. Not claims denied, claims never made. The company recovers duty on the obvious flows, the clean export of an unchanged imported item, and leaves the manufacturing substitution claims alone because nobody can face reconstructing yields. Every year another tranche of eligible duty quietly ages out.

Why generic trade and finance systems cannot assemble a claim

A drawback claim is a matching argument, and the match is not a join on a common key. Under substitution rules the exported article need not be the imported article, it needs to be eligible under the classification based test, which means the software has to reason about classification rather than about part numbers. Under manufacturing drawback the exported good contains a proportion of the imported input determined by your bill of materials and your actual yield, including waste treatment, and that proportion is the basis of the claim.

No enterprise resource planning system was designed to answer that question. It knows what you consumed in a work order. It does not know which import entry line supplied the material, because materials are fungible in inventory and the system deliberately stopped tracking origin at receipt. Recreating that link means building an allocation model over receipts and consumptions, choosing a defensible convention, and applying it consistently, which is a design decision with a customs consequence rather than a reporting feature.

Then there is proof. A claim is not a number, it is a number plus a file: the entry summary data, the export evidence, the production records, the destruction certification where relevant, and the audit trail showing how the match was made. Customs authorities can review claims after payment, so the file has to remain assembled and consistent for years after the money has been received and spent.

Where ONESOURCE Global Trade and Descartes stop

Both are strong global trade platforms and both handle drawback within a broader trade suite. If your flows are conventional and your data is tidy, they file claims competently and you should evaluate them before commissioning anything.

The constraint is upstream of the filing. These products expect clean, mapped data about imports, exports and consumption. Getting your data into that state is the project, and it is specific to you: your part numbering conventions, your yield calculations, your plant level records, the fact that one business unit reclassified a product family two years ago and nobody restated history. A packaged product will accept an import file in its format. It will not tell you that your export file misses the shipments made through a third party logistics provider under a different consignor name, which happens to be where a large share of your eligible exports went.

This is why specialist filers still do so much of this work manually, and why the firms that build usually build the matching and evidence layer while continuing to file through established channels.

What a custom build has to include

Import data ingestion at line level from entry summary data, with duty, classification, quantity and value preserved per line rather than aggregated per entry. Aggregation at intake is the most common irreversible mistake, because the claim needs the line.

Export and destruction evidence capture from wherever it actually lives. Shipping records, commercial invoices, transport documents, export declaration references and destruction certification, with the identifiers your systems use rather than the identifiers customs uses. Reconciling the two naming worlds is most of the work.

A matching engine that supports the claim types you actually use. Direct identification where the same goods leave. Substitution where classification eligibility governs. Manufacturing drawback where a bill of materials and a yield determine how much imported input is embodied in an exported unit. Each has its own evidentiary needs and the engine should refuse to produce a claim it cannot evidence.

An explicit allocation convention for fungible inventory, documented in the system rather than in someone's head, applied consistently and reproducible on demand. When a reviewer asks why this receipt was matched to that export, the answer must be a rule, not a preference.

A claim file assembler. Every claim produces a package containing the calculation, the supporting lines, the documents and the version of the rules applied, stored immutably with a retention period matching your record keeping obligation. Build this for the reviewer you will meet in three years, not for the analyst filing today.

Opportunity analysis, which is the part that gets the project funded. Given your import and export history, show what is potentially claimable but currently unevidenced, ranked by value and by how close the window is to closing. Most organisations have never seen this number and it is usually larger than expected.

Multi client separation if you are a specialist filer. Data isolation per client, per client matching conventions, and reporting that lets you show a client what you recovered and what you could not, with reasons.

What it costs and how long it takes

A first release covering import line ingestion, export evidence capture, one claim type end to end and the claim file assembler runs $80,000 to $165,000 and ships in 12 to 18 weeks. A full platform adding manufacturing drawback with bill of materials and yield modelling, the allocation engine, opportunity analysis, privileges and accelerated payment tracking, and multi client separation runs $220,000 to $500,000 phased across 6 to 12 months.

What drives cost: the number of source systems, especially where imports come through multiple brokers with different data formats. Manufacturing drawback, which is materially harder than unused merchandise because it requires yield modelling per product family. Historical data quality, since claims often reach back years and the older records are the messier ones. And plant level record availability, which in practice means finding out whether production records were retained at the granularity the claim needs.

What keeps cost down: pick one product family and one claim type and prove the whole chain from import line to filed claim. The recovery from that single family usually funds the rest of the build, which is a much easier internal conversation than a capital request.

When buying or outsourcing is the right call

Outsource if your recoverable duty is modest and your flows are simple. Specialist drawback firms work on contingency, they are good at what they do, and paying a share of a recovery you were not otherwise going to make is a fair trade with no capital at risk.

Buy a packaged trade platform if you already run one for classification and filing, your data is clean, and drawback is a module you can switch on rather than a data reconstruction project.

Build when the constraint is evidence rather than filing. When your matching depends on your own part numbering and yields, when you know eligible exports are being missed because of how third party logistics shipments are recorded, when claims are consistently scoped down to what is easy to prove, or when you are a specialist filer whose margin depends on absorbing messy client data faster than your competitors.

How to choose a developer for duty drawback software

Ask them what they would do about fungible inventory. If they do not immediately raise the allocation convention question, they have not built a claim that survived review.

Ask how they would evidence a manufacturing claim. The answer should involve bill of materials, actual yield, waste treatment and a per unit calculation that can be reproduced from retained records, not a percentage applied to a total.

Ask what the claim file contains and how long it is retained. You want an immutable package including the rules version applied, because the rules and your data will both have changed by the time anyone reviews it.

Ask how they will reconcile export records across your systems and your logistics providers. A developer who has done this will talk about identifier mapping and about shipments made under a different consignor name. One who has not will assume the export file is complete.

Ask who owns the code and settle it before kickoff. You should hold the repository, the cloud accounts and the right to hire any other firm. At Digital Heroes the client owns the code from the first commit, which matters when the system holds the evidence behind claims a customs authority may review years after payment.