Sales claim programs: how they work and how to digitise them
In most Indian trade schemes the brand does not know what it owes until the partner tells it. The partner's claim, a spreadsheet of invoices and a covering note, is the scheme's only ledger. This post explains the claim model, where it leaks, and how to keep the model while removing the paper.
A sales claim program is a trade scheme in which the channel partner, a distributor, dealer or retailer, claims the scheme benefit after the period by submitting proof such as invoices, DMS extracts or scan records, and the brand validates the claim before settling it by credit note or payout. It differs from an auto-accrual scheme, where the brand calculates the benefit itself from data it already holds. Claim programs are used where the brand cannot see the qualifying transaction, typically secondary sales, and they leak through late, duplicate and inflated claims. Digitising the claim on WhatsApp or a portal with automated validation keeps the model and removes most of the leakage.
Claim-based vs auto-accrual schemes
| Sales claim program | Auto-accrual scheme | |
|---|---|---|
| Who calculates the benefit | The partner, then the brand checks | The brand, from its own data |
| Data source | Partner-submitted invoices, DMS extract, scan records | Brand ERP, DMS sync, platform scans |
| Suits | Secondary and tertiary sales the brand cannot see; distributor-run schemes | Primary sales; scan-based programs |
| Partner effort | Compile and submit a claim | None; the balance appears |
| Main leakage | Late, duplicate and inflated claims | Rule errors and gaming at thresholds |
| Settlement timing | After claim, validation and dispute | Automatically at period end |
The two are not rivals. A brand usually runs auto-accrual for the tier it can see and a claim program for the tier it cannot, and the goal of digitisation is to make the claim program feel like auto-accrual to the partner. The scan vs invoice post explains which evidence each tier can produce.
What a claim contains
- Claim statement. Scheme name, period, partner code, claimed quantity or value, claimed benefit.
- Proof of sale. Invoices from the partner to its customers (for a distributor claiming on secondary), or invoices to the partner (for a retailer claiming on purchases), or scan records.
- Adjustments. Returns and credit notes within the period.
- Declaration. That the invoices are genuine and not claimed elsewhere.
Validation and timelines
Validation checks that each invoice exists, falls in the period, covers eligible SKUs, has not been claimed before under any scheme, is net of returns, and belongs to an outlet that is not a related party of another claimant. On paper this is sampled; digitally it is done on every line. Timelines matter as much as rules. A claim window that closes 15 days after the period, a validation SLA of 7 days, a dispute window of 7 days and settlement within 5 days of approval gives a total of under five weeks from period end to payment. Most paper programs take three months, and the delay is where trust and leakage both come from.
Why claims leak
Late claims
Filed months after the period, when the brand has closed its books and the distributor's own records have moved on. Late claims are approved on faith or rejected on principle; neither is right.
Duplicate claims
The same invoice under two schemes, two periods or two partners. Without a central invoice register nobody can see it.
Inflated claims
Quantities rounded up, invoices to related outlets, returns omitted. Each is small; together they are the 3 to 8 percent of claimed value that line-level validation removes across programs Unotag runs.
Manual settlement errors
Credit notes keyed by hand, applied to the wrong account, or issued twice after a dispute.
A digital claim flow
The flow that works for Indian partners runs on WhatsApp for retailers and small dealers and on a portal for distributors, both on one ledger:
- Period ends; the platform sends each partner a pre-filled claim from any data it already holds (DMS sync, scans, earlier uploads).
- The partner confirms or attaches missing invoices as photos on WhatsApp, or uploads a DMS extract on the portal.
- Optical reading extracts invoice number, date, customer, lines and value; the partner corrects anything misread.
- Validation runs every line against the rules and the central invoice register; passed lines are approved, failed lines are listed with reasons.
- The partner responds to failed lines within the dispute window; an escalation owner decides the rest.
- Settlement runs as a credit note file to the ERP or a UPI payout, with Section 194R aggregation, and the partner receives a statement.
The scheme implementation page describes how this is configured for a specific scheme, and the scheme audit page covers the validation rule set and the audit trail. The WhatsApp portal is the partner-side channel for retailers.
The pre-filled claim is the step that partners notice. A distributor who has spent two days each month compiling a claim receives one already populated from its own DMS export and only has to confirm or correct it. A retailer who never filed a claim because the paperwork was not worth the benefit now files one by replying to a WhatsApp message with two photos. Participation in claim programs typically rises by a third or more once the claim arrives pre-filled, which matters because a scheme that only the largest partners bother to claim is a scheme that only rewards the largest partners.
SLA table for a digital claim program
| Stage | Owner | Target | Paper equivalent observed |
|---|---|---|---|
| Pre-filled claim sent | Platform | Day 1 after period end | Not available |
| Claim window closes | Partner | Day 15 | Day 30 to 90 |
| Validation complete | Platform, with exception queue | Day 22 | Day 45 to 120 |
| Dispute window closes | Partner and escalation owner | Day 29 | Open-ended |
| Settlement | Finance via ERP or platform payout | Day 34 | Day 60 to 150 |
| Statement to partner | Platform | Day 34 | Rare |
Distributor claims on secondary sales: the hardest case
The most common sales claim program in India is a distributor claiming a scheme benefit on what it sold to retailers. The brand did not raise those invoices and often cannot see them, so the claim rests on the distributor's own billing. Three controls make this workable. First, take the distributor's DMS or billing export directly rather than a spreadsheet prepared from it, so the invoice numbers, dates and retailer names are the system's own. Second, verify a sample of retailer invoices against the retailer: a WhatsApp message to the retailer's registered number asking them to confirm a purchase takes seconds and catches invoices raised to outlets that never received stock. Third, where retailers are enrolled in the brand's program, match the distributor's claimed invoices against the retailer's own uploads or scans; an invoice claimed by the distributor and never seen by the retailer is the clearest signal available. Programs that add the retailer-side match typically find the discrepancy concentrated in a small number of distributors, which makes the conversation manageable.
Keeping the claim model honest
Two design choices reduce leakage more than any validation rule. First, show the partner their accrual during the period from whatever data you have, so the claim is anchored to a number they have already seen. Second, publish the claim window and stick to it; a claim program that accepts late claims trains the channel to file late. Where the transaction can be proven by a scan rather than an invoice, move that tier to auto-accrual and keep the claim program for the rest. The rebate claims process applies the same discipline to rebates.
Key takeaways
- A sales claim program pays after the partner claims with proof; use it for tiers whose transactions you cannot see, and auto-accrual for the rest.
- Claims leak through late, duplicate and inflated submissions; line-level validation against a central invoice register removes 3 to 8 percent of claimed value.
- A digital flow on WhatsApp or portal takes a claim from period end to settlement in about five weeks against three months on paper.
- Show accruals during the period and enforce the claim window; both do more than any single validation rule.
Frequently asked questions
What is a sales claim program?
A trade scheme in which the channel partner claims the scheme benefit after the period by submitting proof such as invoices, DMS extracts or scan records, and the brand validates the claim before settling by credit note or payout. It is used where the brand cannot see the qualifying transaction directly.
How is a claim program different from an auto-accrual scheme?
In a claim program the partner calculates and submits the claim and the brand checks it; in an auto-accrual scheme the brand calculates the benefit from data it already holds and the balance simply appears. Most brands run both, one per tier.
What documents are needed for a sales claim?
A claim statement with scheme, period, partner and claimed amount; invoices or a DMS extract proving the qualifying sales or purchases; returns and credit notes for the period; and a declaration that the invoices are genuine and not claimed elsewhere.
How long should a sales claim take to settle?
About five weeks from period end with a digital flow: claim window closing at day 15, validation by day 22, disputes by day 29 and settlement by day 34. Paper programs commonly take two to five months.
Why do sales claim programs leak money?
Late claims approved on faith, the same invoice claimed under two schemes or periods, inflated quantities and omitted returns, and manual credit notes applied twice or to the wrong account. Line-level validation against a central register catches most of it.
Can dealers submit scheme claims on WhatsApp?
Yes. The partner receives a pre-filled claim, attaches invoice photos, the platform reads them, validates each line and lists any rejections with reasons, all inside a WhatsApp conversation in the partner's language.
Should a brand replace claim programs with scan-based schemes?
Where the transaction can be proven by a serialised QR scan, yes, because auto-accrual removes the claim entirely. Keep the claim program for tiers and transactions that cannot be scanned, and digitise it.