Concession and Shop in Shop Software: Why Partner Commission Settlement Eats Your Month End

Why concessions are a settlement business wearing a retail costume

A department store or airport retailer with a large concession estate is running two businesses at once. The first is retail, which everyone understands. The second is a settlement operation: hundreds of independent brands trade inside your floor space, their sales go through your tills, the stock belongs to them, and every month you owe each one a number that both sides have to accept.

The month end looks the same almost everywhere. A finance analyst exports sales by department and partner from the till. Some partners map cleanly to a department, others share one, and a few sell items that were set up under a host department by mistake in March. She applies commission rates from a folder of signed contracts, most as PDFs, several with an amendment letter attached that changed the rate mid year. She subtracts a marketing levy for some partners and not others, recharges card fees to those whose contracts allow it, handles a return processed at a store the item was not bought in, allocates a gift card redemption spanning three partners, and produces 180 statements. It takes eight to eleven working days. Then the queries start.

The queries are the real cost. A concession partner is a commercial relationship, not a supplier line, and every disputed statement is a conversation with a brand you want to keep on the floor. In the concession and settlement work we have delivered, the pattern is that the underlying commission is usually right and the derivation is unpresentable, so disputes get settled by goodwill rather than by evidence. That is expensive in both directions.

Problem 1: attributing the sale correctly is harder than it looks

Everything downstream depends on knowing which partner owns which sale line, and the till is not designed to care. Partner identity usually rides on a department or supplier code set up years ago by someone who has left. A partner who changed name or was acquired now appears twice. New lines get created under the wrong parent in a busy season and nobody reconciles it until settlement.

Then there are the transaction types that break simple attribution. A return processed at a different store from the sale. An exchange that crosses two partners in one transaction. 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. Every one of those has a right answer in the contract and a default answer in the till, and they are frequently different.

What a custom build does: a partner and contract model that sits above the point of sale (POS) hierarchy rather than inside it, with mapping rules that carry effective dates so a mid year change does not corrupt prior periods. Then a transaction classifier that handles the awkward types explicitly, including who bears a funded discount, rather than letting a departmental total absorb them silently. This is not glamorous work. It is the difference between a statement you can defend and one you cannot.

Problem 2: every contract is negotiated and none of them are the same

Concession commercial terms are individually negotiated and they use a wide vocabulary. A flat percentage of turnover. A sliding scale where the rate steps down as monthly turnover rises. A minimum guaranteed amount or a percentage, whichever is greater, which is common in airport and mall settings. A rate that differs by product category within the same partner. A marketing levy. A recharge of card processing fees. A fit out contribution amortised across the term. A seasonal rate for a pop up.

None of this is exotic to your commercial team and all of it is fatal to a generic report. Retail ERP (Enterprise Resource Planning) and point of sale platforms model a supplier and a purchase price, because they were built for goods you buy and resell. A concession is the inverse arrangement: you never bought the goods, you sold someone else's and kept a share. The systems can be forced to represent that with journal entries, and they usually are, which is why the actual calculation ends up outside the system in a workbook.

What a custom build does: model the contract as a set of dated, typed terms rather than as a rate field, then compute the settlement as an explicit chain that a partner can read. Turnover, deductions with their reasons, commission with the tier applied, levies, recharges, adjustments, net payable. If your commercial team can invent a term, the model should be able to express it without a developer.

Problem 3: the stock is theirs, the shrink is arguable, and nobody has the numbers

In a true concession the partner owns the inventory until it sells. That single fact creates a set of obligations most host systems have no vocabulary for. The partner needs to know what sold and what is left in your store. Deliveries into your building are theirs, not receipts into your inventory. Stock counts are performed by your staff on someone else's assets. When a count comes up short, the contract says who carries it, and that clause is negotiated differently with every partner.

Because the host system treats none of this as inventory, the practical answer is that the partner sends a rep to count their own bay, or trusts the host's word, and shrink becomes a periodic argument rather than a measured number.

What a custom build does: hold partner owned stock as a separate ownership class with its own movements, receipts, transfers between stores, returns to the partner, and counts. Then shrink is calculated per partner per period and allocated by the rule in that partner's contract. The commercial value is that a shrink conversation becomes a data conversation, and the operational value is that partners can plan replenishment instead of guessing.

Problem 4: self billing has to satisfy a tax authority, not just the partner

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 comes with 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. The exact requirements depend on your jurisdiction and on the partner's status, and you should confirm them with your tax advisers rather than with a developer.

What matters for the build is that a self billed document is an accounting record with legal weight and it cannot be a PDF assembled from a spreadsheet. It needs its own sequence, immutability once issued, credit notes rather than edits when something is wrong, correct tax handling per partner including partners registered in a different jurisdiction, and a retrievable audit trail from the document back to the individual transactions that produced it.

What a custom build does: generate the self billed document from the settlement object, keep it immutable, correct only by credit note, and post the resulting entries to your general ledger with the analysis your finance team actually needs. Getting this right removes the annual audit question that most concession operators currently answer with a folder of workbooks.

Problem 5: partners are running blind between statements

A concession partner is making buying and staffing decisions about your floor with a monthly PDF as their only information. They will ask your team for a weekly sales figure, and someone pulls it by hand, which is a hidden cost across a large estate.

What a custom build does: a partner portal with daily sales by store and by line, stock position, the current settlement in progress, historic statements, and a dispute mechanism that raises a query against a specific line rather than an email against a total. Two things happen. The queries drop sharply because partners can see the derivation, and the ones that remain are specific and quickly resolved. It also becomes a genuine commercial asset, since brands notice which hosts make it easy to trade with them.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release covering the partner and contract model, sales attribution including returns and the awkward transaction types, commission calculation, and self billed invoice generation with ledger posting runs $75,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding partner owned stock with shrink allocation, a partner portal with dispute workflow, levies and recharges, fit out amortisation, and multi entity or multi currency handling runs $180,000 to $450,000 phased over 8 to 12 months.

What drives price up specifically in concessions: the variety of contract term types rather than the number of partners, since 200 partners on four structures is far easier than 40 partners on 20. Point of sale integration quality, because a modern platform with a clean transaction API is a different project from an older estate where you receive a nightly flat file with limited line detail. Multi jurisdiction operation, common in airport and travel retail, which brings separate tax treatment per location. Partner owned stock, which is close to a second project on its own. And any requirement to handle partners who also trade with you on a wholesale basis, since the same brand then appears under two commercial models.

What keeps price down: settling one commercial model first, typically your standard percentage of turnover partners, and leaving minimum guarantee and category rate partners for phase two while they stay on the existing process.

Build versus buy, and when buying is right

This category has no obvious packaged answer, which is unusual and worth saying plainly. Retail ERP and point of sale platforms will hold a supplier, a department, and a rate, and large hosts do run concessions through them with a heavy layer of spreadsheets and journals on top. That is a legitimate choice at small scale.

Stay manual if you host a dozen partners on a single flat rate with no partner owned stock complications. The spreadsheet is cheaper than the build and the risk is contained.

Build when your partner count is high enough that settlement is a multi week finance exercise, when your contracts use more than two or three commercial structures, when partners routinely dispute statements and you settle by goodwill, when you carry partner owned stock and shrink is an annual argument, or when you operate across jurisdictions and self billing tax treatment differs by site. The tipping point is not partner count on its own. It is the moment your commercial team starts declining terms they would like to offer because finance cannot calculate them.

How to choose a developer for concession settlement software

Ask them to model a return processed in a different store from the sale, in a period after the original settlement was paid. A developer who has done settlement work will describe an adjustment against the current period with a link to the original, and will ask whose contract terms apply. One who has not will treat it as a negative sale and quietly create an unexplained variance.

Ask how they will make a self billed invoice immutable and how corrections work. If the answer allows editing an issued document, that is an accounting problem and your auditors will find it.

Ask what point of sale systems they have actually taken transaction level data from, including returns, exchanges, gift card redemptions, and funded discounts. Department totals are easy and will not settle a concession estate.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, and any developer who hedges on that is building a dependency rather than a system.