Concession and Shop in Shop Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does sale attribution get scoped as a department mapping so often?

Because it looks like the problem is already solved. The till already reports sales by department, most partners already map to a department, and a specification that says pull sales by partner from the point of sale passes review without anyone arguing. Then settlement runs and the exceptions appear.

The exceptions are specific to concession trading rather than to retail generally, and there are more of them than anyone estimates.

• A partner who was acquired or renamed now exists twice in the hierarchy, with sales split across both.
• Two brands share a department because floor space was reorganised and nobody restructured the till.
• Lines created under the wrong parent during a busy season sit unreconciled until settlement.
• A return processed at a store the item was not bought in, in a period after that settlement was paid.
• An exchange that crosses two partners inside one transaction and gets netted rather than split.
• A gift card sold by the host and redeemed against a partner's goods, where the cash arrived in a different period.
• A loyalty discount funded by the host applied to a partner's product, or the reverse, where the contract says who bears it and the till has a default that disagrees.

The fix is a partner and contract model that sits above the point of sale hierarchy rather than inside it, with mapping rules that carry effective dates so a mid year change cannot corrupt a prior period. Then a transaction classifier handles the awkward types explicitly, including who bears a funded discount, instead of letting a departmental total absorb them silently. This is unglamorous and it is the difference between a statement you can defend line by line and one you cannot.

What goes wrong when you migrate contract terms and historical settlements?

The contract audit is the single most common cause of a slipped go live in this category, and it is not a software problem. Concession terms live as signed PDFs in a folder, several with amendment letters attached that changed the rate mid year, and what finance actually applies in the spreadsheet has drifted from both.

Hosts routinely discover three things. Terms in the signed agreement that nobody has ever applied, usually a marketing levy or card fee recharge quietly dropped. Terms being applied that no document supports, typically a rate agreed verbally in a meeting. And whole partners trading under an expired agreement. None of those can be resolved by a developer, and all need a commercial decision before they become configuration.

The approach that works is to read every live agreement before design finishes, record the term set per partner with the document reference and effective dates attached, and reconcile the last three settlement runs against what the model computes from those terms. Where the model and the spreadsheet disagree, the answer is a commercial conversation, not a code change. Plan for parallel running across two full settlement cycles, and expect the first cycle to surface differences you will be glad you found before a partner did. Historic statements should be attached as immutable records rather than recomputed, because recomputing history under today's terms produces numbers that contradict documents you already issued.

Why do point of sale integrations break after launch?

Settlement needs transaction level detail, and most point of sale integrations are specified against a summary. That mismatch is invisible during a demo, because departmental totals reconcile perfectly against departmental totals. It surfaces the first time a partner queries a specific line.

The recurring breakages follow a pattern. A nightly file that carried line detail for six months starts arriving as tender level summaries after a till upgrade nobody told you about. Return records reference an original transaction identifier that is only unique within a store, so cross store returns cannot be traced. Gift card redemptions post as a tender type rather than a line, so the value is invisible to attribution. And a new store opens whose files parse cleanly but map to the wrong departments.

What protects a build is treating the point of sale feed as untrusted input. Validate control totals per store per day against an independent source, quarantine files that fail rather than partially loading them, alert when the file shape changes, and reconcile transaction counts as well as values. Then hold every settlement's source transactions so a statement can be traced back to individual lines when a brand asks. If your estate is a mixture of a modern platform with a clean transaction interface and older stores sending nightly files, price and plan those as two separate integrations, because they are.

What happens when self billing is not handled as an accounting record?

In most concession arrangements the host raises the invoice on the partner's behalf, because only the host knows what sold. Self billing is a recognised mechanism in many tax jurisdictions and it carries conditions, typically including a written agreement with the supplier, correct treatment of the supplier's tax registration, and specific content and numbering on the document. Confirm the exact requirements with your tax advisers rather than with a developer.

The failure mode is treating the document as a report: a settlement produces a PDF, it gets emailed, and when something is wrong somebody regenerates it. The numbering sequence then develops gaps or duplicates, which is the first thing an auditor tests. A partner holds a document that no longer matches what your system says was issued. And there is no traceable path back to the transactions that produced the figure.

The correct treatment is that a self billed document is immutable once issued, carries its own sequence, is corrected only by credit note, handles tax per partner including partners registered in a different jurisdiction, and posts to your general ledger with the analysis your finance team needs. Hosts operating across several jurisdictions, which is normal in airport and travel retail, need per site tax treatment rather than a global setting. Getting this right removes the annual audit question that most concession operators currently answer with a folder of workbooks.

Should you build custom or configure what you already own?

For a lot of hosts the honest answer is to stay where you are. If you host around a dozen partners on a single flat percentage with no partner owned stock complications, the spreadsheet is cheaper than the build and the risk is contained. Your retail enterprise resource planning (ERP) system and your point of sale platform will hold a supplier, a department and a rate, and large hosts genuinely do run concessions through them with a layer of journals on top.

Be clear about why that layer exists. Retail enterprise systems are built around goods you buy and resell. A concession is the inverse: you never owned the stock, you sold someone else's and retained a share, on terms negotiated brand by brand. Forcing that into departments and journals is exactly why the real calculation ends up in a workbook outside the system.

Build when the shape of your estate has outgrown that. The signals are a partner count high enough that settlement is a multi week finance exercise, contracts using more than two or three commercial structures, routine disputes settled by goodwill because you cannot show a derivation, partner owned stock where shrink is an annual argument, or multi jurisdiction operation with different self billing treatment by site. The clearest tipping point is not partner count at all. It is the moment your commercial team starts declining terms they would like to offer because finance cannot calculate them.

How do hidden costs get into the quote?

The bands for this work are $75,000 to $160,000 over 12 to 18 weeks for a first release covering the partner and contract model, sale attribution, commission calculation and self billed invoice generation with ledger posting, and $180,000 to $450,000 over 8 to 12 months for a full platform. Quotes overrun for reasons you can see in advance.

The largest is contract term variety being priced as partner count. Two hundred partners on four structures is a far smaller build than forty partners on twenty. Sliding scales, minimum guarantee or percentage whichever is greater, category specific rates within one partner, marketing levies, card fee recharges, fit out contributions amortised across a term and seasonal pop up rates are each modelling work, and a quote that says commission calculation without listing the term types is guessing.

The second is point of sale integration quality, covered above. The third is partner owned stock, which is close to a second project rather than a feature. The fourth is multi jurisdiction tax. The fifth is any partner who also trades with you wholesale, since the same brand then needs two commercial models without double counting. The sixth is the contract audit, which is your effort and is almost never in the plan.

What genuinely keeps price down is phasing by commercial model. Settle your standard percentage of turnover partners first and leave minimum guarantee and category rate partners on the existing process until phase two.

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

The builds that hold up produce a settlement a partner can read without calling you. Turnover, deductions with reasons, commission with the tier applied, levies, recharges, adjustments, net payable, each traceable to underlying transactions. They give partners a portal with daily sales by store and line, stock position, the settlement in progress and a dispute mechanism that raises a query against a specific line rather than an email against a total. Query volume drops sharply once partners can see the derivation, and the queries that remain are specific and resolve quickly.

The builds that fail were usually chosen badly. Ask a prospective developer to model a return processed in a different store from the sale, in a period after the original settlement was paid. Anyone who has done settlement work will describe a dated adjustment linked to the original and will ask which contract terms apply, the ones in force at the sale or today. Anyone who has not will treat it as a negative sale and create an unexplained variance every month.

Ask how a self billed invoice is made immutable and how corrections work, because if an issued document can be edited your auditors will find it. Ask which point of sale systems they have taken transaction level data from, including returns, exchanges, gift card redemptions and funded discounts. And settle code ownership in writing before kickoff, because this system encodes your negotiated terms with every brand on your floor.