Duty Free Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the final destination mistake happen so often?

Because the barcode is genuinely useful and it looks complete. The industry standard boarding pass barcode returns a passenger name record, flight number, origin, destination and date in one scan, which removes almost all manual entry at a counter working through a departure bank. A developer reading that field list sees destination and reasonably assumes destination.

It is the next sector. A passenger flying from your terminal to a hub and onward to a third country carries a pass whose destination is the hub. Eligibility, allowances and duty treatment are frequently governed by where they are actually going and sometimes by residency, which the barcode does not carry at all. The gap is invisible in testing because test passes are point to point, and it is invisible in production because nothing fails.

The second half of the same failure is hard coding. Allowances, eligibility by destination pair and what may be sold under which duty status are set by the jurisdictions involved and revised on a political timetable rather than a software release schedule. Any figure written into code was correct once.

The fix is an eligibility engine, not a lookup. The engine takes the scanned pass, resolves the itinerary rather than the sector, applies dated rules per origin and destination pair, and returns a decision per line item with a reason attached. Cashiers see a plain instruction. Supervisors can see why. Rules are dated data edited by someone in head office, so a change that arrives with two weeks of notice is a data update rather than a release. Write the connecting passenger case into the acceptance criteria explicitly, because it is the one scenario that separates a build that will survive an audit from one that will not.

What goes wrong when bonded stock is modelled as ordinary inventory?

Goods under a customs warehouse or duty suspension arrangement are not stock with a flag on it. They are stock the state has a claim on until a taxable event occurs, and every movement has a treatment: receipt into bond, transfer between bonded locations, sale to an eligible passenger, removal to duty paid stock, breakage, sample, theft and destruction.

Retail inventory models think in quantity on hand and cost. They have no native concept of duty status as an attribute of a unit and no reason to keep every movement, because ordinary shrinkage is a margin problem rather than a legal one. So a build that extends a retail stock model produces two predictable failures.

The first is pooling. Where the same store holds bonded and duty paid stock of the same product, which is common, a single quantity field means the till draws from whichever pool the software finds first, or worse, from a notional pool that does not exist physically. Discrepancies then accumulate in both directions and neither is traceable.

The second is editing. Corrections get applied by updating a record, which feels natural to write and destroys the evidence. When a customs officer asks how you arrived at a declared position, an updated record cannot show what it was before and why it moved.

The fix is structural and cheap if it is designed in. Duty status is a first class attribute on the unit, not a report. Movements are recorded in an append only ledger where corrections are reversing entries with a visible reason. Bonded and duty paid pools are separate, and the till is forced to draw from the correct one by the eligibility decision rather than by cashier choice. That single rule removes most of the discrepancies we see.

Why do the point of sale (POS) and customs reporting integrations break after launch?

Both fail in the same way: they were built against the version of the interface that existed on the day, with no reconciliation to detect drift.

On the retail side, most travel retail builds sit alongside an existing enterprise platform rather than replacing it, which is usually the right decision. The risk is that Oracle Retail Xstore and Cegid Retail both go through upgrades, and customisations and extension points do not always survive them unchanged. If your eligibility layer reads transaction lines through an interface that shifts during an upgrade, the symptom is not an error. It is eligibility decisions quietly stopping, or applying to the wrong lines.

On the customs side, declaration formats are set by an authority and revised on the authority's schedule. A build that generates the format by string assembly rather than from a versioned specification will produce a file that is accepted until it is not, and rejections at a period end are the worst possible timing.

Three protections apply to both. Version the interface contract explicitly and test it as part of every platform upgrade, before the upgrade reaches production. Reconcile on a schedule: compare transactions recorded by the retail platform against transactions your layer evaluated, and raise a named alert on any gap rather than a dashboard figure. And keep declaration formats as versioned templates with effective dates, so a revision is a configuration change made in advance rather than an emergency.

What happens when offline trading and concession reporting are underbuilt?

These two get deferred more than anything else, and they are the two with direct commercial consequences.

Terminals lose connectivity. That is not an incident, it is a Tuesday. A till that stops trading during a departure bank is a till that will be worked around, and the workaround is a cashier selling anyway and reconciling later, which means goods leave bonded stock with no eligibility decision and no record. Offline capability here is harder than in ordinary retail because eligibility is a rules lookup, so the device has to carry the current rule set locally and record which version it applied. Retrofitting that into a system that assumes connectivity is close to a rewrite, which is exactly why it must be an architecture decision in week one rather than a later feature.

Concession reporting is the quieter one. Airport and cruise agreements commonly charge a percentage of turnover against a minimum guaranteed amount, often at different rates by product category, with a reporting obligation and audit rights. Most operators assemble that declaration from a period export and a spreadsheet of category mappings maintained by hand. The exposure runs both ways: report high and you overpay rent quietly for years, report low and an audit becomes a dispute with the landlord who controls your presence in the terminal.

Both fixes are modest. Offline transaction capture with deterministic reconciliation on reconnect, and the applied rule set version stored on every transaction. Category mapping held as maintained data with effective dates, the fee calculated as an explicit period object with a trail down to transaction level, and the declaration generated from that object rather than assembled.

Should you build custom or configure what you already own?

For a single small border or ferry shop with a narrow product range and simple eligibility, do not build. A good packaged till plus a disciplined workbook is proportionate, and we would say so before quoting.

More usefully, if you already run Oracle Retail Xstore or Cegid Retail, the first thing to do is not commission a build. It is to ask your platform partner what extension points already exist and what other travel retail operators have configured on the same version. Both are serious platforms with real depth in transaction handling, promotions and store operations, and plenty of operators run them well below their configured capability because the setup was done at go live and never revisited. Replacing a platform to obtain behaviour you had not switched on is an expensive way to learn.

Where configuration genuinely runs out is rate of change and scope, not quality. Ask three practical questions of your partner: how quickly can an extension change when a destination rule shifts on short notice, who is permitted to change it, and what does the next platform upgrade do to that customisation. If the honest answers are months, only a certified partner, and it needs retesting, then the fastest changing part of your operation is sitting in someone else's queue.

Build the regulated layer around the platform you keep when you operate in more than one jurisdiction, when you have had a customs discrepancy you could not explain from system records, when your concession declaration is assembled by hand and your landlord has audit rights, or when you hold bonded and duty paid stock of the same product in the same store.

How do hidden costs get into the quote?

Four items account for most of the overruns in travel retail, and every one is knowable before you sign.

The second jurisdiction priced as configuration. Each country brings its own customs regime, declaration format and allowance structure, and the second one is close to a second project. If your roadmap includes another market, price it now rather than discovering it later.

Building a till instead of a layer. Replacing the point of sale is materially more expensive than surrounding it, and it is rarely the thing that was broken. Be explicit about which you are buying, because proposals blur it.

Offline listed as a feature. Local rule sets, deterministic reconciliation and version stamping on every transaction are architecture. A quote that mentions offline support in a bullet has not priced it.

Hardware and estate rollout. Scanners, sealed bag printers and label printers each carry procurement, certification and installation across terminals with restricted access, and installation windows in an airside area are not ordinary working hours.

What separates a build that works from one that fails here?

Ask how they would handle a passenger connecting through your airport to a third country. If they treat the barcode destination as final, they will authorise sales that should not have happened and the discovery point will be an audit rather than a bug report. It takes thirty seconds to ask and it is the single most diagnostic question in this category.

Ask how corrections work in the bonded ledger. If a movement can be edited, the ledger is not evidence. The right answer is append only with reversing entries and a visible reason on every adjustment.

Ask what happens when the terminal loses connectivity for twenty minutes during a departure bank, including how an eligibility decision is made without a live rules lookup. Anyone who treats airport connectivity as reliable has not worked in a terminal.

Then sequence it to protect yourself: one location and one jurisdiction properly, with the bonded ledger run in parallel with the existing workbook for two full declaration periods before it becomes the source of truth. Settle ownership of the repository and the infrastructure accounts in writing before kickoff, which is how Digital Heroes ships, because customs and allowance rules change with limited notice and sitting in a supplier's release queue turns a configuration change into a compliance exposure.