Duty Free and Travel Retail Software: Making Bonded Stock, Boarding Passes and Concession Rent Agree

Why travel retail is a compliance system that happens to sell perfume

It is 6:15am at an airport store. A passenger puts three bottles of spirits and a carton of cigarettes on the counter and hands over a boarding pass. In the next four seconds the till has to answer several questions that an ordinary shop never asks. Is this passenger travelling to a destination where these goods can be sold duty free from this location. Does the quantity exceed the allowance for that destination. Is this a transfer passenger whose liquids must leave in a sealed tamper evident bag. Which duty status applies to each line, since the same shelf may hold bonded and duty paid stock. Which currency is the customer paying in and at what rate. And behind all of it, the store's stock position has to move in a way that will still reconcile to the customs record at the end of the period.

Get any of that wrong and the consequences are not a bad customer experience. They are a customs discrepancy on goods held under duty suspension, and an airport authority that calculates your rent from turnover you reported.

The operating reality in a lot of travel retail is a strong retail point of sale (POS) doing the retail part well, plus a set of spreadsheets doing the regulated part. Bonded stock is tracked in a workbook maintained by one person who understands the warehouse regime. Concession turnover is declared from a monthly export. Boarding pass rules are printed and taped near the till for the cases the system cannot decide. In the travel retail and bonded inventory work we have delivered, the recurring finding is that the retail system is fine and the two things that carry the actual legal and commercial risk are being managed by hand.

Problem 1: the boarding pass is the transaction's authority and it is only partly readable

Boarding pass barcodes follow an IATA standard, which is genuinely helpful: a scan gives you a passenger name record, flight number, origin, destination, and date without asking the customer anything. What the barcode does not give you is the entire answer. It carries the next sector, not the final destination on a connecting itinerary. It does not tell you the passenger's residency, which matters in some jurisdictions. Mobile passes photograph badly, older passes vary, and some markets still see printed passes with poor contrast at 6am under bad lighting.

Then the rules on top of it change. Allowances, eligibility by destination, and what may be sold under which duty status are set by the jurisdictions involved, and they are revised on a political timetable rather than a software one. Any specific allowance figure in a blog post will be stale eventually, so the design principle matters more than the number: never hard code the rules, and confirm current values with your customs advisers before each release.

What a custom build does: an eligibility engine that takes the scanned pass, resolves destination and passenger type, applies dated rules per origin and destination pair, and returns a decision per line item with a reason. Cashiers see a plain instruction, not a rule reference. Supervisors can see why. And when a rule changes, someone in head office edits dated data rather than waiting for a release, which is the whole point when the change arrives with two weeks of notice.

Problem 2: bonded stock has to reconcile to a customs record, unit by unit

Goods held under a customs warehouse or duty suspension arrangement are not simply inventory. They are inventory that the state has a claim on until a taxable event occurs. Every movement matters: receipt into bond, transfer between bonded locations, sale to an eligible passenger, removal to duty paid stock, breakage, sample, theft, and destruction. Each of those has a treatment, and periodic declarations plus spot checks compare your record to the physical position.

Standard retail inventory does not think this way. It thinks in stock on hand and cost. It has no native concept of duty status as an attribute of a unit, no concept of a movement type that changes tax liability, and no reason to keep an immutable record of every movement, because ordinary retail stock loss is a margin problem rather than a legal one.

What a custom build does: duty status as a first class attribute on stock, an append only movement ledger where corrections are new entries rather than edits, and a reconciliation view that compares system position to declared position with the variances itemised by movement type. If the same store holds bonded and duty paid stock of the same product, which is common, the system tracks them as separate pools and forces the till to pick the right one based on the eligibility decision rather than leaving it to a cashier. That single rule removes most of the discrepancies we see.

Problem 3: what Oracle Retail Xstore and Cegid Retail actually cover

Both are serious retail platforms. Oracle Retail Xstore is a mature enterprise point of sale used widely in large chains, with real depth in transaction handling, promotions, and store operations. Cegid Retail is similarly capable and strong in international specialty retail with good localisation. Neither is a bad choice and both appear in travel retail estates.

The honest limits are about fit and rate of change rather than quality. These platforms are built for chain retail, so boarding pass eligibility, bonded stock accounting under a customs regime, and airport concession fee reporting sit outside their core model and get delivered as extensions. That is a legitimate route, and the questions to ask are practical ones. How quickly can an extension be changed when a destination rule shifts with short notice. Who can change it, an internal team or only a certified partner. What does a platform upgrade do to your customisations. And how much of the bonded reconciliation genuinely lives in the platform versus in a workbook next to it.

Many operators end up with a sensible split: keep the enterprise till for what it is good at, and build the regulated layer around it as your own system with a clean integration. That is usually cheaper than trying to make a chain retail platform into a customs system, and it keeps the piece that changes fastest under your control.

Problem 4: your rent is calculated from numbers you report

Airport and cruise concession agreements typically charge a percentage of turnover against a minimum guaranteed amount, frequently with different rates by product category and a reporting obligation to the authority. The concession fee is a large operating cost and the authority has audit rights over the figures behind it.

Most operators produce that declaration from a period export and a spreadsheet with category mappings maintained by hand. The exposure runs both ways. Misreport high and you overpay rent quietly for years. Misreport low and an audit becomes a commercial dispute with the landlord who controls your presence in the terminal.

What a custom build does: category mapping as maintained data with effective dates, concession fee calculation as an explicit period object with a full trail to transaction level, and the declaration generated from that object rather than assembled. Then an audit is a query rather than a project, and your own team can see the fee accruing during the month instead of discovering it afterwards.

Problem 5: the till has to be genuinely multi currency, not currency aware

An airport store takes payment in the local currency, the destination currency, one or two majors, and card. It quotes prices in more than one currency, holds cash floats in several, gives change in a currency that may differ from the tender, applies rounding rules per currency, and reconciles a till at the end of a shift across all of it. Some markets add dynamic currency conversion on card, with its own disclosure requirements.

Retail platforms handle multi currency at the pricing and reporting layer well. The cash handling reality at the drawer, with mixed tender, multiple change currencies, and a rate that was set at the start of the day, is where implementations usually get uncomfortable and where cash office reconciliation quietly becomes manual.

What a custom build does: treat the tender as a set of currency specific movements with the applied rate stored on the transaction, not derived later. Then the shift reconciliation is exact, the FX gain or loss is measurable rather than assumed, and the cash office stops balancing by judgement.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for travel retail. A focused first release covering boarding pass scanning and eligibility rules for your destination set, plus a bonded stock ledger with reconciliation reporting, runs $110,000 to $240,000 and ships in 16 to 24 weeks. A full platform adding multi currency tender and cash office, concession fee calculation and declaration, bonded to duty paid transfers, pre order and collection at gate or store, and loyalty across a travel estate runs $280,000 to $750,000 phased over 10 to 18 months.

What drives price up specifically here: the number of jurisdictions, because each one brings its own customs regime, declaration format, and allowance structure, and the second country is nearly a second project. Whether you are building a till or a layer around an existing enterprise point of sale, since the second is materially cheaper and usually smarter. Hardware, if scanners, sealed bag printers, or label printers are involved. Offline tolerance, which is not optional in a terminal, because a till that stops working when the network drops is a till that will not be used. And cruise or border operations, where connectivity is worse and rules can change by port.

What keeps price down: one location and one jurisdiction first, running the bonded ledger in parallel with the existing workbook for two full declaration periods before it becomes the source of truth.

Build versus buy, and when buying is right

Buy, or extend a packaged platform, if you run one small border or ferry shop with a narrow product range and simple eligibility. The compliance surface is small enough that a good till plus a disciplined workbook is proportionate.

Build the regulated layer when any of these are true. You operate in more than one jurisdiction, so no single packaged configuration covers your rules. You have had a customs discrepancy you could not explain from system records. Your concession fee declaration is assembled by hand and your landlord has audit rights. You hold bonded and duty paid stock of the same product in the same store. Or your allowance rules change faster than your platform partner can deliver a change, which for many operators is the deciding fact rather than any feature gap.

How to choose a developer for duty free and travel retail software

Ask how they would handle a boarding pass for a passenger connecting through your airport to a third country. If they treat the barcode destination as final, they will sell goods that should not have been sold, and the discovery point is an audit rather than a bug report.

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. Offline transaction capture with deterministic reconciliation on reconnect is a design decision made at the start, not a feature added later.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, which matters especially when regulatory change arrives with weeks of notice and you cannot afford to be in a supplier's release queue.