Trade Scheme & Rebates Ledger in Tally: Which Group, and Why

Most Indian businesses create a "Trade Scheme & Rebates" ledger under Indirect Expenses in Tally, and if you need an answer in one line, that is it. But it is not always the right answer, and the reason it is not is the whole point of this page — the group you pick silently decides what gross margin you report.

This page is general guidance on accounting practice, not accounting advice. Confirm the classification with your auditor, and verify group names against your Tally Prime release.

The real question underneath

Before choosing a group, answer the question the group choice is really about: is trade scheme spend an expense, or a reduction of revenue?

Take a business with ₹10 crore of sales in a year, ₹8 crore of cost of goods sold, and ₹60 lakh of scheme payouts to distributors.

Booked under Indirect Expenses:

Line	₹
Sales	10,00,00,000
Cost of goods sold	(8,00,00,000)
Gross profit	2,00,00,000
Gross margin	20.0%
Trade scheme & rebates	(60,00,000)
Net profit	1,40,00,000

Booked as a deduction from revenue:

Line	₹
Sales (net of schemes)	9,40,00,000
Cost of goods sold	(8,00,00,000)
Gross profit	1,40,00,000
Gross margin	14.9%
Trade scheme & rebates	—
Net profit	1,40,00,000

Net profit is ₹1.4 crore either way. Gross margin is 20.0% under one treatment and 14.9% under the other — a gap of 5.1 percentage points on identical trading.

That gap propagates. Distributor ROI models, product and customer profitability, pricing floors, category reviews and sales incentive calculations all run on gross margin. Under the expense treatment every one of them is optimistic, and unevenly so: the distortion is largest for exactly those customers who take the most scheme support, which are usually the ones the business believes are its best.

The recommendation. Where a scheme is economically a discount — a QPS payout, a slab incentive, a rate difference, anything whose size is a function of what the partner bought or sold — treat it as a reduction of revenue. Where it genuinely funds a distinct promotional activity you would otherwise have paid a third party for, such as a display programme or co-branded advertising, an expense treatment is defensible.

Practice varies, and plenty of auditors are comfortable with Indirect Expenses across the board because it is simpler and net profit is unaffected. That is a reasonable position; it is just not a costless one, and it should be a decision rather than a default.

Setting up the ledger in Tally

Which group

Create Trade Scheme & Rebates under Indirect Expenses if you are following the expense treatment. If you are following the revenue-deduction treatment, create it under Sales Accounts (or a "Sales — Deductions" sub-group) so it nets against turnover in the Profit & Loss rather than sitting below gross profit.

A word of caution on the second option: a scheme ledger grouped under Sales Accounts affects how your turnover reads, and turnover is a figure other filings and thresholds refer to. That is precisely why this is an auditor conversation and not a Tally configuration choice.

Sub-ledgers by scheme type

Whichever group you choose, do not create one ledger. Create a group with sub-ledgers:

• Trade Scheme & Rebates — QPS / quantity purchase schemes
• Trade Scheme & Rebates — Secondary sales schemes
• Trade Scheme & Rebates — Target & slab incentives
• Trade Scheme & Rebates — Damage, breakage & expiry
• Trade Scheme & Rebates — Price protection & rate difference
• Trade Scheme & Rebates — Display & promotional support
• Trade Scheme & Rebates — Freight support (scheme-linked)

This is the single highest-return five minutes in the whole setup. A blended figure cannot be analysed, cannot be defended line by line at audit, and cannot be tied back to the agreements that created it. When someone asks in March why scheme spend is up 30%, a single ledger can only tell you that it is. Splitting costs nothing on day one and is expensive and approximate to reconstruct later, because the underlying vouchers rarely carry enough narration to re-sort them.

The list above also maps onto how trade schemes in India are actually structured, so each sub-ledger has a real agreement type behind it.

Naming that survives an audit

Use a consistent prefix so the ledgers group visually, name the scheme type rather than the partner, and never encode the financial year in the ledger name — you will end up with parallel ledgers and split balances. Put the scheme reference in the voucher narration, not the ledger name.

How scheme credit notes post

Most scheme settlement in Indian channels happens by credit note rather than payment. The entry, for a ₹1,00,000 scheme settlement to a distributor under the expense treatment:

Particulars	Dr	Cr
Trade Scheme & Rebates — QPS	1,00,000
Distributor A/c		1,00,000

Where the settlement is made through a GST credit note rather than a financial one, the taxable value and the tax are both reduced, so the entry splits — the scheme ledger takes the taxable value and the output tax accounts take the tax component. Which instrument is appropriate depends on whether the discount was established before or at the time of supply and on the agreement terms.

That distinction is not a formality: it determines whether the recipient has to reverse input tax credit. See financial vs tax credit notes under GST and, for post-sale discounts specifically, GST credit notes for rebates under Rule 53(1A). Put the choice to your tax advisor for your own scheme structures.

Reading rebates on a ledger statement

A related question worth answering, because it comes up constantly when a distributor and a company compare books: what does a rebate line on a party ledger statement actually represent?

On the company's books, a rebate or scheme entry in the distributor's ledger is almost always a credit to the party — it reduces what the distributor owes. On the distributor's own books the mirror entry is a debit to the company's account. When the two statements are compared, rebate lines are one of the three usual causes of disagreement, alongside goods in transit and payments in clearing.

Three things make a rebate line on a ledger statement readable, and their absence is why so many are not: the scheme reference it settles, the period it relates to, and the claim number it discharges. None of these are ledger fields — all three live in the voucher narration, which is why narration discipline matters more here than almost anywhere else in the books.

Reconciling at period end

The scheme ledger balance almost never equals what partners actually earned, and the difference is usually a combination of four things:

1. Claims raised but not settled. The partner has earned and claimed; you have not yet issued the credit note. The obligation exists and the ledger does not show it.
2. Entitlements earned but never claimed. The partner qualified and has not got around to claiming. Invisible everywhere in the accounting system.
3. Credit notes issued in the wrong period. A March entitlement settled by an April credit note lands in the wrong year.
4. Settlements posted to the wrong sub-ledger. A price-protection credit posted against QPS. The total is right; every line is wrong.

A short monthly procedure that catches most of it:

• Pull the scheme ledger movement for the month, by sub-ledger.
• Pull the claim register for the same month: claims received, approved, settled, rejected and pending.
• Tie settled claims to credit notes one-for-one, and investigate anything in the ledger without a matching claim.
• List approved-but-unsettled claims — this is your unbooked liability.
• Estimate earned-but-unclaimed entitlement from agreements and actual offtake, and carry it as an accrual.
• Confirm each credit note was posted to the sub-ledger matching its scheme type.

Steps four and five are the ones usually skipped, and they are the ones that produce year-end surprises. Distributor ledger reconciliation with claims and credit notes goes deeper on the partner-facing side of the same exercise.

Where the ledger stops being enough

This is worth stating plainly rather than as a sales point, because the limit is structural and no amount of Tally configuration removes it.

A ledger records what was paid. It cannot record what was earned but not yet claimed, and it cannot validate a claim against an agreement.

Both follow from the same fact: Tally holds transactions, not agreements. The scheme terms — the slabs, the qualifying SKUs, the period, the rate that applies once a threshold is crossed — exist in a signed document and in the memory of whoever negotiated it. Tally has no representation of them, so it cannot compute an entitlement from offtake, cannot tell you a claim is 12% higher than the agreement supports, and cannot age what you owe but have not been asked for.

That is a reasonable division of labour, and it is not a criticism of Tally, which is doing exactly what an accounting system should. It just means the accrual and validation layer has to live somewhere else and post the results into Tally — which is what rebate accrual management covers, and what rebate scheme claims for Tally users works through for teams keeping Tally as their book of record. Getting the transaction data out cleanly is its own step: see exporting invoices from Tally for claims.