Sharing Secondary-Sales Data With Brands — and What It Unlocks

A brand can only fund a scheme it can verify. Secondary-sales data — what you sold onward, to whom, in what quantity — is the evidence behind secondary and tertiary schemes. Sharing it in a consistent, agreed format is usually what stands between a distributor and the scheme payouts already on offer.

This is the distributor's practical side of the topic. For the underlying concepts — what counts as primary, secondary and tertiary — see primary, secondary and tertiary sales and sell-in versus sell-through. This article is about the practice of sharing the data to earn payouts.

Scheme type	What the brand needs to see	Where it comes from
Primary / purchase-based	Your purchases from the brand	Your purchase register
Secondary scheme	Your sales onward to retailers	Your secondary-sales (billing) data
Coverage / outlet scheme	Unique outlets billed in the period	Outlet-level secondary data with stable codes
Display / visibility	Proof the activity was executed	Photos, checklists, execution records
Liquidation / stock scheme	Closing stock at period end	Your stock statement

Why do brands ask for secondary-sales data?

Understanding the brand's position makes the whole exchange easier, so it is worth stating plainly and fairly.

A brand runs a scheme to move product through the channel to the market — not to reward a distributor for loading a warehouse. But from its own books, a brand sees only primary sales: what it billed to the distributor. It cannot see what the distributor then sold onward. So a scheme meant to reward genuine offtake is, from the brand's side, a payment made partly on faith.

That leaves the brand two bad options when it can't see secondary data: under-fund sell-through schemes to limit the risk of paying for stock that never moved, or fund them blind and absorb the leakage. Neither serves the distributor who is moving product. Sharing secondary-sales data resolves it — the brand can fund confidently because it can verify, and the distributor who genuinely sells through gets rewarded for it.

Framed that way, the data-sharing ask is not the brand policing you. It is the precondition for the brand funding the schemes that reward your actual work.

What data to share — and what not to

The useful unit is invoice-level onward sales: for each sale to a retailer, the date, the outlet, the item, the quantity and the value. That is enough to compute most secondary and coverage schemes.

But the level of detail is a commercial decision, not a default — and a legitimate one to negotiate. Distributors are often wary of handing over full retailer-level detail, because their retailer relationships are part of what they bring to the channel. That caution is reasonable. The point is to set the level of detail explicitly, in the scheme agreement, rather than have it assumed by whoever designed the file format.

Some schemes need outlet-level granularity to work at all — a coverage scheme paying on unique billed outlets cannot be computed from a summary. Others settle perfectly well on item-and-quantity totals by period. Match the detail you share to what the scheme genuinely requires, agree it up front, and you avoid both over-sharing and the dispute that follows an under-specified file.

Getting the data out of your billing system

You do not need new software to share secondary-sales data — you need a consistent export. Most billing systems can produce a sales register showing outlet, item, quantity, value and date, and that is the raw material.

The export mechanics are the same as for any claim data, and the same discipline applies: consistent columns, item codes rather than descriptions, stable outlet identification, complete periods. The step-by-step for common systems is in exporting invoices from Tally for claims and getting invoice data out of Marg; this article makes no claim about what any particular system does, and exact steps vary by version — follow your own system's export function or ask your accountant.

What good secondary-sales data looks like

Five things separate data a brand can settle a scheme on from data that starts an argument:

• Consistent outlet identification — the same shop recognised across months, which needs a stable code rather than a re-typed name.
• Item codes, not descriptions — so the scheme's product scope applies reliably.
• Complete periods with no gaps — a missing week reads as lost sales and costs you the claim.
• Returns shown — so the base is honest and the brand trusts it.
• Submitted on the agreed cycle — late data settles late, or misses the window.

The full field-and-quality picture is in what good secondary-sales data looks like, and the party and product foundations under it are in master data hygiene.

From data to payout

Shared data becomes a payout in four steps: you submit the secondary-sales file on the agreed cycle; the brand validates it against the scheme terms and its outlet and product masters; exceptions — unmatched outlets, unmapped items — are flagged for correction rather than dropped; and the qualifying portion is settled, usually by credit note. The pattern is the mirror image of the brand-side receiving and settling on secondary-sales data, and it is why loose data costs money: an unmatched outlet is an uncounted sale.

ClaimDS takes secondary-sales data as Excel or CSV, validates it against the scheme's terms and the outlet and product masters, and surfaces exception lines for correction rather than silently dropping them — so a mismatched outlet becomes a fixable flag instead of a lost claim. The wider data-movement picture is in connected claims.

To see your own secondary data turn into settled claims, book a demo.

Note: General information about channel data practice, not tax or legal advice. Where a scheme settles through a GST credit note, the treatment is covered in our tax articles and should be confirmed with your adviser.