The short answer
DutyCalc is long-established, licensed duty drawback software that many brokers and importers still run. Stable is a modern, flat-license drawback platform for the broker channel, with a global-optimization matching engine in place of DutyCalc's first-fit matching, better merchandise processing fee handling, own filing, and a current interface. Both are licensed software you run in-house, so the real question is recovery and workflow, not pricing model, and that is where Stable pulls ahead.
Key takeaways
- Both are licensed software you run in-house, so the comparison is about recovery and workflow, not the pricing model.
- Stable's engine optimizes matching globally across the claim window; DutyCalc uses greedy first-fit, which typically leaves recoverable duty and fees unclaimed.
- Stable captures MPF that first-fit matching tends to over-allocate and strand.
- Stable is a current platform (modern interface, own ABI filing, broker white-label); DutyCalc is legacy software with a dated interface.
Stable vs DutyCalc at a glance
| Feature | Stable | DutyCalc |
|---|---|---|
| Pricing model | Flat license | Flat license (licensed software) |
| Matching engine | Global optimization across the claim window | Greedy first-fit matching |
| MPF handling | Optimized MPF capture | Prone to MPF over-allocation |
| Interface | Modern web platform | Legacy UX |
| Filing | Own ABI filer code, electronic ACE | Software output, filed separately |
| Channel | Broker white-label, under your POA | Licensed tool |
| Deployment | Weeks | Established installs, dated onboarding |
| Best-fit customer | Brokers and importers modernizing drawback | Existing DutyCalc shops |
Choose Stable if
You run drawback in-house and want to recover more per claim through optimized matching and modern tooling, on the same licensed model you already use.
Choose DutyCalc if
You have deeply entrenched DutyCalc processes, are not ready to migrate, and matching efficiency is not currently a priority.
What is the real difference between Stable and DutyCalc?
Both are licensed drawback software you run in-house, so this is not a pricing-model debate the way the contingency startups are. The difference is the engine and the interface. DutyCalc uses greedy first-fit matching and a legacy UX; Stable uses a global-optimization matching engine, captures more MPF, files under its own ABI code, and runs as a modern platform your brokerage white-labels. It is the seat that replaces DutyCalc rather than a different category of tool.
How does the matching engine change recovery?
Drawback is an assignment problem: each import line can back only one export claim, so which pairings you pick decides how much you recover. First-fit matching takes the first eligible pairing and moves on. Stable solves globally across all valid permutations to maximize total recovery within the five-year window and substitution rules. On large datasets that gap compounds; in comparable datasets, optimized matching can recover on the order of 15% more duty and fees than a first-in-first-out default (an illustrative figure pending your own benchmark).
What about the merchandise processing fee?
The merchandise processing fee is capped per entry, so how a claim allocates it across entries determines how much you get back. Greedy first-fit matching tends to over-allocate MPF to the wrong lines and strand recoverable fee, a well-documented weakness of legacy matching. Stable optimizes MPF allocation as part of building the claim, which is often the clearest single place its recovery pulls ahead of DutyCalc.
How do filing and workflow compare?
Stable files under its own ABI filer code directly to ACE, with a modern review queue, audit trail, and accelerated-payment handling. DutyCalc produces claim data you file through a separate path, inside an interface that predates the modern web. For teams processing drawback at volume, the day-to-day workflow difference is as noticeable as the recovery difference.
Should you switch from DutyCalc?
If you run drawback at any real volume, the recovery uplift from optimized matching plus the workflow modernization usually justifies the move, and you keep the same licensed model you already prefer. Migration brings your historical import and export data into Stable, and claims run on the optimized engine going forward. See the DutyCalc alternatives guide for the full field.
Related
Platform modules
Comparisons
Alternatives
Frequently asked questions
It replaces the same seat: licensed drawback software you run in-house. It adds optimized matching, better MPF capture, its own ABI filing, and a modern interface. Migration moves your import and export history over so claims run on the new engine.