Franchise Royalties: Why Sales and Deposits Must Be Managed Apart

Here is how to check your royalty calculation basis by reviewing contracts and sales data side by side.

Gross sales, settlement amounts and deposits are tallied at different stages, so confirm your royalty basis first

CORE SUMMARY

✔ Royalties are calculated on the base amount defined in the franchise agreement, which does not automatically equal what gets deposited

✔ Discounts, cancellations, fees, VAT and the month sales are booked to are the five main points where sales and royalty results diverge

✔ As your store count grows, you need a system that lets you match contract terms against sales data store by store

✔ Settlement evidence must be on record so HQ and store owners can discuss the same data

Franchise royalty calculation is the process of multiplying the royalty base defined in the franchise agreement by the agreed rate to arrive at the amount HQ bills each store. The problem is that this "royalty base" may not exactly match POS sales, delivery app settlements or the amount actually deposited in the bank.

When you have few stores, it is not a big problem for a staffer to remember each store's contract terms and reconcile them by hand. But as stores multiply and delivery channels diversify, the same reconciliation work starts delaying HQ's entire settlement process. When settlement runs late, invoices to store owners go out late too, and when owners ask about the amounts billed, it becomes hard for staff to show the basis right away.

In this article, we look at the structural reasons sales and deposits diverge in royalty calculations, walk through a hypothetical case in which the results actually differ to see how the basis matters, and then cover how HQ should manage its settlement standards to prepare for a growing store count.

Why does every HQ come up with different royalty numbers?

The root reason royalty amounts come out differently each time is that the word "sales" is used at several levels in practice. The gross sales recorded at the POS, the settlement amount a delivery platform reports after deducting its fees, and the deposit that actually lands in the account are each tallied at different times on different bases. Even for orders placed on the same day, it is more accurate to treat these three numbers as separate data with different names.

The calculation for a percentage-based royalty is simple: royalty base × agreed rate. In practice, the hard part is not the rate but the definition of the royalty base. If the contract only says "a certain percentage of monthly sales" without separately defining which items those sales include, each settlement staffer risks calculating from different data. That risk grows when staff change. If there is no record of which data the predecessor used, the successor has to make a fresh judgment every time, and if that judgment differs from before, it can look to the store owner as if the calculation method has changed.

This problem shows up far more when you process data for many stores at once than when you look at a single store. Each store signed its contract at a different time, has a different mix of delivery channels, and staff organize data in slightly different ways. In the end, the accuracy of royalty calculation depends less on what rate you set than on how you define the royalty base and apply that definition consistently across stores.

The definition of the royalty base, more than the rate, determines the royalty result

Where gross sales, settlements and deposits diverge

Most of the differences among the three amounts can be explained by the five items below.

Five points that throw calculation results off

Discounts and coupons — The starting point is that the pre-discount order amount, the amount the customer actually paid, and any subsidy covered by the platform or HQ are separate items. If you do not distinguish who bears the discount, the same order can be calculated two different ways. Discounts are especially large during promotions, so if you do not reconcile that period's sales data on the same basis as other months, the royalty amount may not match the store's actual situation.

Cancellations and refunds — The month an order is placed and the month its refund is processed often differ. Without a rule for which period absorbs the adjustment, a refund already reflected can be deducted again the following month. Once this kind of error occurs, it takes time to discover, and even after it is found, more time goes into deciding how many months back to correct.

Delivery fees — Just because a platform deducts its fees before depositing does not mean those fees are automatically deducted from the royalty base. Whether fees are reflected must always be checked against the calculation terms in the contract. With multiple delivery channels at different fee rates, calculations easily get mixed up unless you record the fee treatment for each channel separately.

VAT — Whether sales reports include VAT may differ from the contract's basis, so check the nature of the transaction and how the data is structured first. As sales volume grows, the gap between VAT-inclusive and VAT-exclusive amounts also widens into a gap in royalty amounts.

Revenue month — This is when the time of sale and the time of deposit differ, as when an order on the last day of the month is deposited the following month. Decide in advance whether to reconcile by order date, revenue recognition date or settlement date; if this basis differs from store to store, comparing royalties across stores even for the same month can become meaningless.

Five checkpoints that determine royalty calculation results

A hypothetical case: how the basis changes the result

The following is a hypothetical case to illustrate the calculation structure; it does not represent any actual brand's contract terms or a recommended rate.

Assume the candidate sales base is KRW 50 million, and the settlement after deducting KRW 5 million in delivery platform fees is KRW 45 million. We use an agreed rate of 2% as an example.

Even with the same transactions and the same rate, there is a KRW 100,000 difference depending on which amount the contract defines as the royalty base. For a single store that may not be much, but if the same difference repeats across dozens of stores, it has a cumulative effect on both HQ's total royalty income and the amount billed to each owner. The point is not that one method is right, but to confirm which basis your brand's contracts specify and whether that basis is accurately applied in the actual calculation.

Even with identical sales, the royalty amount can differ depending on the basis

Why settlement gets harder as stores multiply

A settlement error at one store is resolved when a staffer reopens the data. But when stores grow into the dozens, the situation changes. Each store has its own contract date, rate and delivery channel mix, and when staff change, it takes time to dig up the previous calculation basis. Moreover, as new stores keep opening, staff have to enter and verify each new store's contract terms from scratch while also managing the settlement standards for existing stores.

A common problem at this point is that only the results remain, while the source data and reasoning behind the calculation disappear. When a store owner asks, "Why is this month's royalty different from last month's?" and staff can answer only by reconciling the contract terms and sales data all over again, settlement becomes a job rebuilt from scratch each time. If this keeps happening, it can affect trust between HQ and store owners, because from the owner's perspective, the basis for the billed amount remains hard to accept.

What HQ needs in this situation is a system that manages each store's contract terms and sales data in a standardized format and keeps the calculation basis alongside the store information. This does not mean unifying every store's contract terms; it means having a structure in which even differing terms can be looked up and reconciled without gaps. Different contract terms are not the problem, but managing those differences from staff members' memories becomes a risk factor as the store count grows.

As the store count grows, so does the burden of reconciling contract terms with sales data

How HQ standardizes the settlement basis in its operations

The practical way to reduce settlement errors is not to change the formula but to standardize the data and evidence that go into the calculation. When store information, contract terms and sales data are organized on the same basis, staff can reconcile in the same way even after a handover, and can check the supporting data right away when an owner asks.

POINT

FDAM, the HQ operations ERP for franchises from MS Benter, supports this flow within the HQ's workflow. The Operations module standardizes each store's information to HQ standards and, through POS sales aggregation, lets you view each store's sales data in an organized form. Instead of hunting through Excel files and messenger chats scattered by store, staff can reconcile organized sales data and store information on the same screen.

For franchise agreements, FDAM's Sales module lets you sign and manage electronic franchise agreements, so each store's rate and contract terms are recorded in the system from the moment of signing. Stores approaching contract expiry trigger automatic alerts, reducing cases where the renewal date is missed and the old rate keeps being applied. Rather than automating the royalty calculation itself, this is closer to keeping the source data and contract basis needed for the calculation from getting scattered.

For HQs that open stores often, the Opening module keeps each new store's documents and training history organized, so there is less need to dig up contract and document information separately when a new store joins the settlement cycle. FDAM was developed by MS Benter, which has focused on franchise IT for about 25 years, drawing on its experience building systems for more than 500 brands, and it holds GS (Good Software) certification.

Managing each store's contract terms and sales data on the same basis cuts the time spent hunting for settlement evidence

Checklist for HQ before royalty settlement

✔ Are each store's applicable contract and rate up to date?

✔ Do the query periods for POS and delivery channel data match?

✔ Are the party bearing each discount or coupon and any reimbursements identified?

✔ Have cancellations and refunds already reflected in the data been deducted a second time?

✔ Has the treatment of fees and VAT been checked against the contract terms?

✔ Have carryovers from last month and this month's outstanding deposits been checked?

✔ Are the contract terms of newly opened stores accurately reflected in the settlement?

✔ Can you immediately show the basis for a billed amount when an owner asks?

Checking these items by hand every month is feasible when you have few stores, but as the store count grows it piles up as a recurring burden on HQ staff. More important than the checklist itself is standardizing your data in advance so you do not have to redo these checks from scratch every month.

Frequently asked questions

Q. Should royalties be calculated on POS sales or on bank deposits?

A. The basis is the definition of the royalty base stated in the contract. Deposits do not become the royalty basis simply because they are the money actually received; compare the items included in the sales report against the contract terms.

Q. Are delivery sales calculated before or after platform fees?

A. Each brand's contract specifies its own method. Some use the amount before fees and others the amount after fees, so check the calculation terms in the contract first.

Q. How should we manage settlement when contract terms differ by store?

A. Rather than unifying the terms, record each store's contract terms and monthly sales data in the same format so anyone can reconcile them.

Q. Do we have to dig up the calculation basis again when the settlement staffer changes?

A. If each store's contract terms and sales data are recorded in a standardized format, the existing calculation basis can be picked up and checked as is, even after a staff change.

Most royalty calculation errors arise not from the formula but from mismatched standards in the data used for the calculation. Putting a system in place to manage each store's contract terms and sales data in a standardized way before your store count grows is a practical way to lighten HQ's operational load.

Want to get your store settlements and operations management in order?

FDAM helps you manage each store's contract terms and sales data in one place.

Chat with us on KakaoTalk

Franchise royalty calculation, royalty basis, percentage royalty, franchise store settlement, delivery sales settlement, POS sales aggregation, store information management, franchisor HQ operations, franchise agreement management, franchise ERP, MS Benter, FDAM