What Good Secondary-Sales Data Looks Like

Secondary-sales data is usable for scheme settlement when each onward sale is a row with a consistent outlet identity, a mapped item code, a quantity in an agreed unit, a value and a date inside a defined period — and when restatements follow an agreed rule rather than arriving silently.

This is the shared specification both sides work to — the distributor sharing the data and the brand settling schemes on it. It covers onward (secondary) sales; the invoice-file specification for primary claim data is separate, in the invoice upload file, field by field.

The specification

Element	What it must contain	Why settlement needs it	Common failure
Outlet identity	A stable outlet code, unique and unchanging	Coverage schemes count unique outlets; matching needs a fixed identity	Name alone, re-typed differently each period
Outlet attributes	Town, beat or territory where the scheme is geography-based	Geography-scoped schemes need the location	Missing, so regional schemes can't be applied
Item code	The distributor's code, mapped to the brand's SKU master	Product scope is applied by code	Free-text description instead of a code
Quantity and unit	Quantity with an explicit unit of measure	Quantity-based schemes need comparable quantities	Cases and pieces mixed with no unit column
Value	Taxable value of the onward sale	Value-based schemes settle on it	Inclusive/exclusive of tax inconsistently
Document number and date	The reference and date of the onward sale	Places the sale in a period; supports de-duplication	Missing, so period boundaries can't be enforced
Period reference	Which qualifying period the file covers	Prevents gaps and overlaps	Left implicit
Return / credit adjustments	Returns shown so the base can be netted	An honest base the brand can trust	Returns omitted, overstating achievement
Restatement flag	A marker where a row corrects a prior submission	Lets the agreed restatement rule apply	Silent overwrite of earlier data

Outlet identity is the hardest part

If only one element on this list is done well, make it this one.

Secondary schemes live and die on outlet identity because so many of them count outlets: a coverage scheme paying on unique billed shops, a width-of-distribution target, a new-outlet incentive. All of them need to know that the shop billed in April is the same shop billed in May — and a re-typed name cannot guarantee it. "Sri Ganesh Stores", "Sri Ganesh Store" and "S Ganesh Stores" are one shop to the salesman and three to the counting logic.

A stable outlet code solves it: assigned once, carried on every subsequent bill to that outlet, never reused for a different shop. Establishing it is real work — deduplicating an existing outlet list, deciding how to treat an outlet that changes hands — and maintaining it is a standing responsibility. But without it, coverage schemes are uncomputable from the data, and no format discipline downstream can recover what a floating outlet identity loses.

Item mapping between two masters

The distributor codes products one way; the brand's SKU master codes them another. Neither is wrong, and neither will adopt the other's scheme wholesale — so the bridge is a mapping table from the distributor's codes to the brand's, maintained as a shared asset rather than rebuilt each period.

The mapping's weak point is the new SKU launched mid-period. Until it appears in both the product master and the mapping, and its scheme eligibility is decided, it falls into a gap. The fix is a rule — every new SKU gets a scheme-eligibility decision and a mapping entry before it is billed — enforced procedurally. The broader party-and-product foundation is in master data hygiene.

Periods, cut-offs and restatements

Three timing rules keep the data settleable:

The period boundary is fixed and shared. Both sides know the qualifying period's exact start and end, and each file covers one complete period with no overlap into the next.

Late data has a rule. Data arriving after the cut-off either makes the next settlement or is held by an agreed policy — not quietly slipped into a period that has already settled.

Restatements are declared, not silent. When corrected figures replace an earlier submission, the correction is flagged and handled by the agreed rule — adjust next period, or reopen the settled one. A silent overwrite leaves a prior settlement wrong with no trace of why, which is the restatement failure that erodes trust between the two sides.

A quality checklist before submission

1. Outlet codes present and stable — every row carries the fixed code, not just a name.
2. Item codes present and mapped — no free-text-only rows.
3. Units explicit — every quantity has an agreed unit of measure.
4. Period complete and non-overlapping — the file covers exactly one qualifying period.
5. Returns included — the base is net, not gross.
6. Restatements flagged — corrections marked, not silently merged.
7. Totals noted — row count and value total recorded so nothing truncated goes unnoticed.

Why this pays off for both sides

For the distributor, clean data means schemes settle on the first pass instead of bouncing back with queries — faster payouts and fewer disputes over what was counted. For the brand, it means secondary schemes can be funded and settled with confidence rather than reconciled by hand or under-used out of caution. The shared specification is what lets both sides stop arguing about the data and start settling on it.

ClaimDS validates secondary-sales data against exactly these elements on arrival — outlet and item mapping, unit consistency, period boundaries, returns netting — and surfaces anything failing the specification as an exception for correction rather than dropping it. The wider picture is in connected claims.

To agree a specification your distributors can actually meet, book a demo.

Note: General information about data specification, not tax or legal advice. Any scheme's GST treatment is covered in our tax articles and should be confirmed with your adviser.