Receiving Secondary-Sales Data — and Actually Settling Schemes On It
Collecting secondary-sales data from distributors is the easy part. Making it consistent enough to settle a scheme on is the real work — here's what that takes.
In short
Most brands can collect secondary-sales data; fewer can settle schemes on it directly. The gap is consistency — different distributors sending different formats, outlet names that do not match, item codes that change — which forces manual reconciliation before any scheme can be calculated.
Most brands can collect secondary-sales data; fewer can settle schemes on it directly. The gap is consistency — different distributors sending different formats, outlet names that do not match, item codes that change — which forces manual reconciliation before any scheme can be calculated.
This is the brand-side mirror of sharing secondary-sales data with brands. Read together, the two describe both ends of the same exchange.
| Where secondary data breaks | What happens | Effect on settlement |
|---|---|---|
| Format varies by distributor | Each file has different columns and layout | Every file needs re-shaping before it can be processed |
| Outlet identity inconsistent | The same shop appears under different names | Coverage counts are wrong; the same outlet double-counts or drops |
| Item codes not mapped | Distributor codes don't match the brand's SKU master | Product scope misapplied — items in and out of scope both wrong |
| Periods incomplete or overlapping | A week missing, or two files covering the same days | Sales lost or double-counted against the scheme |
| Restated data after submission | Corrected figures arrive after settlement ran | Prior settlement is now wrong, with no rule for handling it |
Collection is not the problem
It is worth being honest about where the difficulty actually lives, because most brand-side effort goes to the wrong place.
Collecting secondary-sales data is largely solved. A distributor management system, a portal, or plain exported files will get data flowing. Visibility tools will show it to you on a dashboard. What none of that guarantees is that the data is clean enough to compute an entitlement from — and that is a different, harder problem.
Settlement has a higher bar than visibility. A dashboard can tolerate a mis-named outlet; a coverage scheme that pays per unique outlet cannot. A trend chart survives a missing week; a scheme calculation double-counts or drops it. The gap between "we have the data" and "we can settle on the data" is exactly the gap this article is about, and it is where most secondary schemes quietly fall back to manual reconciliation.
Setting one format and holding to it
The single highest-leverage thing a brand can do is publish a required file layout and enforce it at intake.
That means a defined column set, mandatory outlet and item codes, a stated unit convention, and a fixed period boundary — published to distributors, not inferred by them. And it means rejecting non-conforming files early, with a clear reason, rather than quietly fixing them in the back office. Silent correction feels helpful and is corrosive: it hides the problem, repeats it every period, and makes the brand's own team the permanent workaround. A clear rejection moves the fix upstream to where the data is produced, which is the only place it gets fixed for good.
The field-and-quality specification both sides can work to is in what good secondary-sales data looks like, and the master-data foundations under it are in master data hygiene.
Reconciling secondary data against the scheme
Once the format holds, settlement is a matching exercise:
- Match to scheme terms — which distributor is enrolled, which products are in scope, which period applies.
- Check period alignment — the file covers the qualifying period completely, with no overlap into an adjacent one.
- Handle restatements by rule — corrected data arriving after settlement needs an agreed treatment (adjust next period, or reopen), decided in advance rather than case by case.
- Treat unmatched rows as exceptions, not noise — an unknown outlet or unmapped item is surfaced for a decision, never silently dropped. Dropping it understates the distributor's genuine achievement and starts a dispute; the exception report is the control that prevents it.
Closing the loop with the distributor
The single biggest reducer of secondary-scheme disputes is also the most often skipped: tell the distributor what was accepted, what was rejected, and why.
A distributor who submits data into silence and later receives a payout they cannot reconcile has every reason to argue. A distributor who gets back a clear statement — these outlets matched and counted, these three items were unmapped, this file overlapped last month's by two days — can fix the input next period and trust the number this period. That feedback turns data quality into a shared, improving process instead of a recurring fight, and it is the same discipline a settlement factsheet brings to the payout itself.
What this makes possible
When secondary data is consistent and the loop is closed, schemes that depend on verified offtake become genuinely fundable — coverage schemes, sell-through incentives, liquidation schemes — because the brand can pay confidently on data it trusts. That is not a promise of a particular result; it is the removal of the blocker that keeps those schemes manual or under-used.
ClaimDS receives secondary-sales data as Excel or CSV, validates it against scheme terms and the outlet and product masters, produces an exception report separating clean rows from those needing a decision, and settles the qualifying portion — with the accepted-and-rejected breakdown available to share back to the distributor. The wider data-movement picture is in connected claims.
To see secondary schemes settle on real distributor data, book a demo.
Note: General information about channel data practice, not tax or legal advice. GST treatment of any settlement is covered in our tax articles and should be confirmed with your adviser.
Frequently asked questions
How do brands collect secondary-sales data from distributors?
Through exported billing files, a distributor management system, or a portal distributors submit to. The collection method is rarely the hard part — most distributors can produce a sales register. The difficulty is receiving it in a form consistent enough to compute a scheme on, which depends on a defined format and stable outlet and item identification rather than on the transport used.
Why is secondary-sales data hard to reconcile?
Because it arrives inconsistently. Each distributor formats differently, the same outlet is named differently across submissions, item codes vary or change, periods overlap or leave gaps, and data is sometimes restated after it was first sent. Every one of those forces a person to reconcile before a scheme can be calculated, which is slow and a frequent source of settlement disputes.
What format should secondary-sales data be in?
One the brand publishes and holds distributors to — a defined layout with mandatory outlet and item codes, a stated unit convention, and a fixed period boundary. Whether it is CSV or Excel matters less than that every distributor sends the same structure every period. A published required format, enforced at intake, is what turns collection into settleable data.
How do you handle distributors who submit inconsistent data?
Reject non-conforming files early rather than fixing them silently, and tell the distributor exactly what failed. Silent correction hides the problem and repeats it every period; a clear rejection with reasons teaches the format and moves the fix upstream. Pair it with a mapping table for outlet and item codes so genuine identity differences are handled systematically, not manually each time.
Can schemes be settled directly on secondary-sales data?
Yes, once the data is consistent enough to compute an entitlement from — matched to scheme terms, with outlets and items identified reliably and periods clean. The blocker is almost never the scheme logic; it is data quality. Brands that publish a format, enforce it at intake and maintain mapping tables settle secondary schemes directly; those that don't reconcile by hand first.
What is an exception report in claim settlement?
An exception report lists the rows that could not be matched or validated — unknown outlets, unmapped items, out-of-period dates, quantities failing a check — separated from the clean rows that settled. It is the core control in data-driven settlement: instead of dropping problem rows silently or holding the whole file, it surfaces exactly what needs a decision while the rest proceeds.
See ClaimDS on your own claims data
A 30-minute walkthrough tailored to how your channel actually settles claims.
Related posts
What Faster Claim Settlement Is Worth: Claims, Cash and Working Capital
An unsettled claim is your money sitting in someone else's system. How settlement speed affects a distributor's working capital, with worked examples in rupees.
Connected Claims: How Invoice and Sales Data Moves Between Your ERP, Your Brands and Your Claims
How invoice and secondary-sales data moves between a distributor's ERP, the brand, and the claim settlement — file upload, direct connection, and what each is good for.
Exporting Sales and Purchase Invoices from Tally for Claim Settlement
How to get invoice data out of Tally in a form a claims workflow can use — what to export, which fields matter, and how to keep the data clean enough to reconcile.