Dealer scheme engine: what it is and what it is not
Most manufacturers already own three systems that touch schemes: an ERP that bills, a DMS that tracks distributor stock and a loyalty platform that pays points. None of them can take this month's scheme circular and tell a dealer, today, what he has earned and what he needs to lift to reach the next slab. That gap is what a scheme engine fills.
A dealer scheme engine is software that holds a manufacturer's trade schemes as configuration, reads dealer invoices from the ERP, decides which dealers and which invoices each scheme covers, calculates what every dealer has earned, shows that working to the dealer and the sales team, and passes approved amounts to finance as a credit-note file or a payout. It replaces the monthly spreadsheet calculation. The test of a real engine is simple: a new scheme circular becomes a live, correctly calculated scheme without a developer writing code.
Why schemes need their own engine
A trade scheme is a small contract issued at short notice. A regional head decides on the 3rd that sales in two districts need a push, a circular goes out on the 5th, and it is effective from the 1st. The circular has a condition (lift 1,000 bags, or grow 10 percent over last year), an incentive (₹6 a bag, or 1.5 percent of value), a list of who is covered and usually a worked example. Thirty or forty such circulars can be live at once across regions, dealer types and product groups.
Billing systems are built for stability. Scheme rules are built to change. When scheme logic is written into the ERP as custom code, every new circular becomes a change request, and the commercial team learns to design only the schemes that IT can deliver in time. When it lives in Excel, the calculation happens once, after the month closes, and the dealer sees nothing while it could still change his behaviour. A scheme engine sits between the two: it takes invoices from the system of record and applies rules that the commercial team controls. The scheme management software guide covers the wider category; this page is about the calculation core.
The six parts of a dealer scheme engine
Scheme kinds as configuration
The engine ships with a library of scheme kinds: quantity slabs, growth over last year, cash discount, milestone blocks, target achievement and so on. A scheme is created by choosing a kind and filling in its parameters: condition on value or quantity, incentive as a percentage, per-unit amount, fixed sum or slab, payout on all units or only on units above the threshold, period, products. If a new circular needs code, the engine has a gap.
Eligibility
Who is in the scheme. Real circulars define this by region, state, district, sales office, dealer type, price cluster or simply an attached list of dealer codes. The engine has to hold all of these, and it has to handle clubbing: a dealer whose firm was reconstituted and who now has an old code and a new code should be calculated as one.
Invoice data feed
The engine does not bill. It receives invoices, returns and credit notes from the ERP through an integration, or from an Excel upload where integration is not ready. Each line needs dealer code, date, product, quantity and value. Everything the engine says is only as good as this feed, so freshness and completeness need to be visible.
Calculation
For every dealer and every scheme: which invoices count, where the dealer stands against the condition, and what has been earned. The engine must handle retroactive and incremental slabs, combo bonuses with minimum thresholds, backdated schemes and recalculation when a return arrives after the period.
Dealer-facing view
The dealer sees progress on each scheme, which schemes he is earning on now and which he has not yet qualified for, the next target and what crossing it is worth, and the list of invoices counted. This is the part that changes behaviour. A calculation the dealer cannot see is only an accounting exercise.
Approvals and payout
Calculated amounts go through an approval chain. Finance can hold a payout, apply a cap or override an amount manually with a reason, and every such action lands in a payout ledger. Approved amounts leave as a credit-note file for the ERP or as a UPI payout.
Scheme engine vs ERP pricing module vs DMS vs loyalty points platform
These four are regularly confused in vendor conversations because each of them does something with the word scheme. They answer different questions.
| Dealer scheme engine | ERP pricing or rebate module | DMS | Loyalty points platform | |
|---|---|---|---|---|
| Question it answers | What has each dealer earned on each live scheme, and what is the next target? | What price and discount go on this invoice? | What did the distributor sell to which retailer, and what stock is left? | How many points does this member have and what can he redeem? |
| Unit of work | A scheme circular applied to a period of invoices | A condition record applied to an order line | A secondary invoice or stock movement | A scan or a purchase converted to points |
| Who changes the rules | Commercial or sales operations team, by configuration | IT or a functional consultant | Brand admin, for secondary schemes only | Program manager, for earn rates |
| Period-based slabs, growth over last year | Core function | Possible through rebate agreements, often with custom development | Limited to secondary schemes | Usually tiers and multipliers, not circular logic |
| Dealer sees working | Yes: progress, invoices counted, next target | No dealer-facing view | Distributor sees own claims | Member sees a points balance |
| Settlement | Credit-note file or payout after approval | Credit note, accrued in the ledger | Claim to the brand | Redemption from a catalogue or cash-out |
None of this makes the other three redundant. The ERP remains the book of record and posts the credit note. The DMS remains the source of secondary sales, and the post on DMS versus loyalty platforms explains that boundary. A points programme for retailers and influencers runs happily beside a scheme engine for dealers. The engine's job is narrow: turn circulars into correct, visible, approved numbers. The ERP integration guide for SAP and Tally describes how invoice data moves between them.
Where scheme engines go wrong
An engine is not a guarantee of correctness. The failure modes are predictable, and a buyer should look for each one.
- The configuration cannot express the circular. The circular says the bonus applies only if the premium grade is at least 30 percent of lifting. The engine has no such parameter, so someone handles it in Excel on the side. Within two quarters half the schemes are on the side.
- The feed is late or partial. Invoices arrive weekly, or returns do not arrive at all. The dealer sees a number on the 28th that is a week old and stops trusting the screen.
- Ambiguous circulars. No software can resolve a circular that does not say whether the slab rate applies to all bags or only the bags above the threshold. The engine forces the question, which is useful, but someone in the business still has to answer it.
- Master data. Dealer codes that do not match between the ERP and the dealer list, old and new codes not clubbed, a dealer mapped to the wrong sales office. Most calculation disputes trace back to master data, not arithmetic.
Questions to ask a scheme engine vendor
- Take three of our past circulars, including the most awkward one. Can you configure them in front of us, without code?
- How do you prove the calculation is right? Will you reproduce the worked examples printed in our circulars as tests?
- How is eligibility defined: geography, dealer type, price cluster, an uploaded dealer-code list? Can old and new dealer codes be clubbed?
- What happens when a scheme is announced on the 10th with effect from the 1st? When a credit note for a return arrives after the period?
- Can we see the projected cost of a draft scheme on our real purchase history before it is saved?
- What exactly does the dealer see, in which languages, and through which channel: your app, WhatsApp, or inside our existing dealer app?
- Who can hold, cap or override a payout, and where is that recorded?
- How does invoice data reach you from SAP or Tally, how often, and what do you do when a day's data is missing?
The second question matters most. A vendor who can reproduce every worked example in your own circulars has shown that the configuration means what your commercial team meant. The scheme calculation software comparison goes deeper into testing, and how to calculate a dealer scheme payout gives rupee examples you can use as test cases.
How Unotag's scheme engine is built
Unotag configures schemes from 16 scheme kinds rather than coding each one. Conditions can be on value or quantity; incentives can be a percentage, a per-unit amount, a fixed sum or slabs; payout can be on all units or only above the threshold; combo bonuses carry minimum thresholds; schemes can be backdated. Eligibility works by region, state, district, sales office, dealer type, price cluster or an uploaded dealer-code list, with clubbing of old and new codes. Invoices arrive through ERP integration with SAP or Tally, or by Excel upload.
A scheme circular can be pasted in as text: AI reads it, structures it into a configuration and shows a preview for a person to check, and the cost is projected on real purchase history before the scheme is saved. A new scheme can go live in minutes. Before go-live, every worked example in the client's circulars is reproduced by the engine as an automated test. The dealer sees progress, schemes he is earning on now and schemes not yet qualified, the next target and the invoices counted, with an AI explanation in eight Indian languages and by voice, and a WhatsApp bot for scheme questions. Sales officers get a focus list that ranks dealers by the volume they can realistically add. It is delivered as Unotag's app, on WhatsApp, or as an SDK inside the brand's existing dealer app. The dealer scheme engine page has the product detail, and dealer incentives shows the dealer-side screens.
Key takeaways
- A dealer scheme engine turns scheme circulars into configured, calculated, visible and approved payouts; it does not bill and it does not replace the ERP.
- Its six parts are scheme kinds as configuration, eligibility, the invoice feed, calculation, the dealer-facing view, and approvals with payout.
- An ERP pricing module prices the invoice, a DMS tracks secondary sales, a loyalty platform runs points. None of them calculates period-based dealer schemes for the dealer to see.
- Judge a vendor by whether your most awkward circular can be configured without code and whether its worked examples are reproduced exactly.
Frequently asked questions
What is a dealer scheme engine?
A dealer scheme engine is software that stores trade schemes as configuration, receives dealer invoices from the ERP, applies eligibility rules, calculates each dealer's earning on each scheme, shows the working to the dealer and routes approved amounts to settlement by credit note or payout.
What is a scheme engine in sales and distribution?
In sales and distribution a scheme engine is the rules layer between billing and settlement. It reads what was billed, applies the conditions and incentives in each live trade scheme, and produces a payout per dealer per scheme with the invoices that support it.
How is a trade scheme engine different from an ERP rebate module?
An ERP rebate or pricing module applies condition records to orders and accrues rebates in the ledger, and changes usually need IT. A trade scheme engine is configured by the commercial team, handles circular logic such as growth over last year and clubbed dealer codes, and shows the dealer his progress.
Is a scheme engine the same as a DMS?
No. A DMS records the distributor's stock and secondary sales to retailers. A scheme engine calculates what dealers have earned on the manufacturer's schemes from primary invoices. Many brands run both, with the DMS feeding secondary data where a scheme needs it.
Can a loyalty points platform run dealer schemes?
A points platform handles earn rates, tiers and redemption well. Dealer schemes are different: period-based slabs, growth over last year, cash discount by days to payment and settlement by credit note. Some platforms include a scheme engine; a points ledger alone is not one.
Does a dealer scheme engine need ERP integration?
It needs invoice data, and integration with the ERP is the dependable way to get it. Where integration is not ready, an engine can start on a daily or weekly Excel upload of invoices and returns. Unotag supports SAP and Tally integration and Excel upload.
How long does it take to launch a new scheme on a scheme engine?
Once invoices are flowing and dealer masters are clean, a scheme that fits an existing scheme kind is a matter of configuration. On Unotag a new scheme can go live in minutes. The first implementation takes longer because data feeds and tests have to be set up.
What does a dealer scheme engine cost?
Pricing models vary by vendor: per dealer, per scheme or by usage. Unotag prices by monthly active users, from ₹30,000 to ₹3 lakh a month. Compare that with the cost of the current process, including overpayment found in audits and the hours spent on disputes.