Scheme Settlement and Claim Documentation Under GST: The Ops Playbook

Most trade-scheme audit findings are not about whether the discount was genuine. They are about whether you can prove it — with a dated agreement, a linked credit note, and an approval that lives somewhere retrievable. The scheme was real, the arithmetic was right, and the position still fails because the paper trail has holes. This playbook lays out the end-to-end documentation a scheme claim needs to survive a GST audit, the findings auditors keep raising on trade schemes, and what it looks like when the audit file assembles itself instead of being reconstructed three years later.

This is an operations playbook, not a tax explainer — for the statutory positions themselves, start with Section 15(3)(b) and post-supply discounts.

The seven artifacts every settled claim must carry

Think of each claim as a file that must stand on its own when an auditor pulls it, years after the people who handled it have moved on. Seven artifacts, in lifecycle order:

1. The scheme circular or agreement — dated, versioned, and issued before the scheme window opened. This is your Section 15(3)(b) pre-agreement evidence: a discount is excluded from taxable value only if it was established in an agreement entered into at or before the time of supply and can be linked to specific invoices. A circular dated after the quarter it rewards is the single most expensive gap in this list.
2. The claim submission and its evidence — the distributor's claim with the invoices it references, the secondary-sales data behind sell-through schemes, and proof of performance (display photos, activation reports) where the scheme paid for execution. The computation basis should be reproducible from what is attached, not from someone's memory.
3. The validation record — who checked the claim, against which scheme rule, on what data, with what result. "Verified — OK" in a spreadsheet cell is not a validation record; it names no rule and no dataset.
4. The approval trail — each approval with the approver's role, authority level and timestamp, matched to a delegation-of-authority matrix. This is where approval workflow design pays off: a system-routed approval produces this artifact automatically; a forwarded email does not.
5. The settlement instrument — the credit note, with the tax-versus-commercial classification decided deliberately and the original invoices it adjusts identified on or behind it. A tax credit note reduces GST liability and triggers ITC reversal on the recipient's side; a commercial credit note does neither. The classification decision itself should be recorded, not implied.
6. The GSTR reporting linkage — which return period the credit note was reported in, within the statutory time limit for credit notes. The claim file should point to the return; the return workpapers should point back to the claim.
7. The partner acknowledgement and ledger match — evidence the distributor received and booked the credit note, and that both ledgers agree. Unacknowledged credit notes are where partner disputes and deduction write-offs are born.

The documentation checklist

Artifact	Why the auditor asks for it	Where it should live
Scheme circular / agreement (dated, versioned)	Establishes the pre-supply agreement Section 15(3)(b) demands	Scheme master record, immutable once the window opens
Claim submission + evidence	Proves the claim reflects real, in-window activity	Attached to the claim record, not in email
Validation record	Shows a control operated — rule, data, checker, result	System log on the claim, per rule checked
Approval trail (role, timestamp)	Shows authority was applied at the right level	Workflow history on the claim
Credit note + invoice linkage	Connects the value adjustment to specific original supplies	CN record carrying invoice references both ways
GSTR reporting entry	Ties the books to the return, period by period	Return workpapers cross-referenced to CN IDs
Partner acknowledgement / ledger match	Confirms the counterparty booked the same transaction	Reconciliation record against the partner ledger

If any row lives "in someone's inbox" or "with the sales team," that row is where your next audit finding comes from.

What auditors keep finding on trade schemes

The same findings recur across GST audits of channel-heavy businesses — not because the schemes were dishonest, but because the documentation was assembled backwards:

• Undocumented pre-agreement. The scheme ran on a verbal commitment or a WhatsApp message, and the circular was formalised after the fact. Without dated pre-supply evidence, the taxable-value exclusion position weakens regardless of commercial reality.
• Missing CN-to-invoice linkage. Credit notes issued against "Q3 scheme dues" in aggregate, with no mapping to original invoices. The linkage requirement is explicit, and reconstructing it from twelve months of invoice data mid-audit is brutal.
• ITC-reversal mismatches. Tax credit notes issued, liability reduced — but no evidence the distributor reversed the corresponding credit. The mismatch surfaces in return-to-return comparisons and lands as a demand.
• Orphan credit notes. CNs in the books that trace to no approved claim — usually quarter-end adjustments pushed through to close a negotiation. Every orphan is both an audit question and a revenue-leakage signature.
• Approval holes. Settlements approved over WhatsApp or phone, with nothing in any system. The payment is real, the authority is unprovable — a control failure even when the amount is right, and a textbook manual-processing failure mode.

Documentation debt is a turnaround-time problem too

The audit is the dramatic risk; the everyday cost is speed. Every artifact that has to be chased — the field photo on someone's phone, the approval buried in an inbox, the invoice list nobody mapped — adds days to settlement. Distributors watch those days: a partner whose claims settle in a week extends scheme participation and credit behaviour that a 90-day settler never sees. Teams that measure it find documentation chasing, not validation logic, consumes most of the cycle — which is why documentation completeness shows up so strongly in claims-operations ROI benchmarks. Documentation debt and settlement delay are the same problem wearing two costumes.

What automated scheme settlement under GST looks like

Every artifact above can be produced two ways: reconstructed by people after the fact, or generated by the system as the claim moves. The second way is what scheme-settlement automation actually means:

• Rules-driven validation — each claim checked automatically against the scheme master (window, slabs, caps, eligible SKUs), producing the validation record as a log entry, not a promise.
• Credit-note classification at settlement — the tax-versus-commercial decision made explicitly per settlement, recorded with its rationale, instead of defaulting to whatever the ERP template does.
• Invoice linkage by construction — credit notes born linked to the invoices they adjust, because the claim itself referenced them.
• An immutable audit trail — every submission, validation, approval and settlement event written once and kept, so the seven-artifact file exists the moment settlement completes.
• GSTR-ready exports — CN registers by return period, ready to hand to the tax team or the auditor without a reconstruction project.

This is the category ClaimDS was built for: Indian multi-tier route-to-market, secondary scheme settlement, and GST credit-note flows as first-class citizens rather than afterthoughts — the positioning laid out in why ClaimDS. If your current process would struggle to produce the seven-artifact file for a claim settled eighteen months ago, that is the gap to close — ideally before an auditor asks, and Section 36 of the CGST Act means they can ask for records going back 72 months from the relevant annual-return due date.

Disclaimer: This article is general information for operations teams, not tax or legal advice. GST positions referenced here — including CBIC Circular No. 251/08/2025-GST on post-sale discounts and the Finance Act 2026 amendments to Section 34 of the CGST Act (assented 30 March 2026 but not yet notified into force as of publication) — evolve, and should be re-verified with a qualified professional at the time you rely on them.