Scheme digitisation: from a circular to the dealer's hand
Every manufacturer's dealer schemes exist today, in a circular drafted in Word, a spreadsheet that someone in commercial maintains, and the memory of the regional sales heads. Digitising them is less a software project than an exercise in writing down, precisely, what the company already does. This guide gives the sequence, who has to be in the room, and where rollouts usually stall.
Scheme digitisation is the work of turning a dealer scheme circular, usually a Word or PDF document, into configuration that a scheme engine calculates from invoices and shows to the dealer. The sequence is: collect the circulars and their worked examples, structure each scheme into configuration, connect the invoice feed, clean the dealer master, reproduce every worked example as a test, set the approval chain and payout rules, then go live with a few functions in a few sales offices before widening. Most of the effort lies in data and in agreeing how each scheme is interpreted, not in software.
What digitisation changes, and what it does not
A digitised scheme is calculated by one set of rules for every dealer, from invoices and not from claims, with the working visible to the dealer during the period and to finance afterwards. That removes the regional variation in how a circular is read, the weeks spent on settlement sheets, and most disputes. It does not design the scheme. A scheme that is too generous, too complex or aimed at the wrong dealers will be calculated accurately and remain a poor scheme. Scheme management software covers what the category does; this page is about getting it live.
Step 1: collect the circulars and their worked examples
Start with paper. Gather every circular in force: the annual policy, quarterly and monthly schemes, special schemes for a region or a product, and the amendments sent by email after the circular went out. For each one, collect the worked examples it contains ("a dealer buying 500 tonnes will receive...") and last period's actual settlement sheet. The settlement sheet often reveals rules that are applied but not written, such as how returns are treated or which invoice date counts. Write these down now. Every unwritten rule found at this stage is a dispute avoided later.
Step 2: structure each scheme into configuration
A circular is prose; an engine needs parameters. Each scheme has to be reduced to: who is eligible, what is counted (quantity, value, growth, product mix), over which period, at what thresholds, at what rates, on what basis (all units or only those within the slab), with what conditions and caps, and paid in what form. This used to be the slowest step. AI-assisted parsing has shortened it: on Unotag, a pasted circular is read and structured into configuration with a live preview, across sixteen configurable scheme kinds.
The parsing is a first draft and not a decision. A circular that says "dealers achieving growth will be eligible" does not say growth over what, and the AI will either ask or assume. The scheme owner must review every line of the structured version and settle each ambiguity explicitly. Before saving, run the cost projection on real purchase history: it shows what the scheme would have cost on last year's purchases and is the quickest way to catch a misplaced slab or a rate applied on the wrong base. The dealer scheme engine page describes the configuration model.
Step 3: connect the invoice feed
The engine calculates from invoices, so invoices have to arrive, complete and on time. There are two routes: integration with the ERP (SAP, Tally or another system), or an Excel upload on a fixed schedule. Starting with an upload is legitimate and often wise, since it proves the calculation before the IT team's time is needed. Decide the fields up front: dealer code, invoice number and date, product code, quantity, value, and returns or credit notes with a reference to the original invoice. Integrating with SAP, Tally or a DMS covers the data flows in detail.
Step 4: map the dealer master and club old and new codes
This is the step that is most often underestimated. The dealer list used by the scheme team rarely matches the customer master in the ERP. Dealers have been re-coded after a change of constitution, a GST registration change or a system migration; one family firm has two codes; a dealer moved from one sales office to another mid-year. If the engine treats an old and a new code as two dealers, purchases are split and neither reaches the slab. Old and new dealer codes need to be clubbed so that one dealer's purchases are counted together, and each dealer needs the attributes that schemes use for eligibility: sales office, state, class and category.
Step 5: reproduce every worked example as a test
This is the acceptance test, and it should not be skipped or sampled. Take every worked example printed in the circular, enter its inputs, and confirm that the engine returns the same payout to the rupee. Where it does not, either the configuration is wrong or the circular's example is, and both happen. Then do the same with a set of real dealers from last period's settlement sheet. At Unotag, before go-live, every worked example in the client's circular is reproduced by the engine as an automated test, so a later change to configuration that breaks an example is caught at once. The value of this step is as much political as technical: when finance and sales have both seen the engine reproduce their own numbers, the argument about whether the system is right is over before launch.
Step 6: set the approval chain and payout rules
Calculation is not payment. Decide who approves a payout run and in what order, the conditions under which a dealer's payout is put on hold (overdue outstanding, a dispute, a pending return), any cap per dealer, and who is allowed to override and with what record. Decide the settlement form: a credit-note file for the ERP, or UPI payout. Every one of these actions should land in a payout ledger so that a figure can be explained a year later. Managing rebate claims covers validation and audit trail in more depth, and scheme audit the checking of past payouts.
Steps 7 to 9: phase one, pilot, then widen
Do not switch everything on for everyone. Choose two or three sales offices with a cooperative regional head and a clean dealer master. Enable a small set of dealer-facing functions: scheme list, progress, next targets and invoices counted. Leave the calculator, ordering and voice for later. On Unotag every dealer-facing function can be switched on or off centrally or per sales office, and there is a phase one preset for exactly this.
Run the pilot through one complete scheme period including settlement, calculating in parallel with the old spreadsheet. Compare line by line. Differences will appear, and each one is either a configuration error to fix or a mistake in the old method that the engine has exposed. Only after one payout cycle has closed without unexplained differences should the rollout widen, first to more sales offices and then to more functions. Pilot design covers how to choose pilot territories, and scheme implementation the support a rollout needs.
Roles and sequence
The table gives a realistic order of work and who owns each stage. Durations are left out on purpose: they depend on the number of schemes, the state of the dealer master and how quickly the invoice data can be obtained. Once the foundations are in place, adding a new scheme is quick, and on Unotag one can go live in minutes. How long a launch takes gives a week-by-week view of a full program.
| Stage | Owner on the brand side | Others involved | Done when |
|---|---|---|---|
| Collect circulars and examples | Scheme or commercial team | Regional sales heads, for unwritten practice | Every scheme in force has a circular, its worked examples and last period's settlement sheet |
| Structure into configuration | Scheme owner | Platform team; finance for payout basis | Each ambiguity is settled in writing and the cost projection looks sensible |
| Invoice feed | IT or ERP team | Commercial team for the upload route | A full period of invoices, with returns, loads without manual correction |
| Dealer master | Sales operations | Regional offices, to confirm clubbing | Every scheme dealer maps to an ERP code; old and new codes are clubbed |
| Worked-example tests | Finance and scheme owner jointly | Platform team | Every circular example and a sample of real settlements match to the rupee |
| Approvals and payout | Finance | Sales head for override policy | Approval chain, hold, cap and settlement form are configured and tried once |
| Phase one and pilot | Regional sales head of the pilot offices | Sales officers, helpdesk | One full period settled with no unexplained difference from the old method |
| Widen | Program owner | All regions | Each new sales office has a clean master and a briefed field team |
Common failure points
The circular is ambiguous and nobody will decide
Two regions read a clause differently and each has paid dealers on its own reading. Digitisation forces one answer. Escalate early; this is a commercial decision, not a configuration question.
The dealer master is dirtier than anyone admitted
Duplicate codes, missing sales offices, dealers who closed. Budget time for it and assign an owner in sales operations.
Invoices arrive late or without returns
Progress shown to the dealer is then wrong in the last week, when it matters most. Fix the schedule of the feed before launch and include credit notes.
Testing is sampled instead of complete
The untested scheme is the one that goes wrong in the first settlement. Reproduce every worked example.
Everything is launched everywhere at once
The helpdesk is swamped, a configuration error reaches every dealer, and the sales team loses faith. Phase by sales office and by function.
The sales team is not briefed
Dealers ask the sales officer, and if he has not seen the app he will tell them to ignore it. Brief the field before the dealers; the scheme communication plan has the order of messages.
The old spreadsheet is never retired
Two sources of truth continue, and the dealer is paid on whichever is lower. Set a date after which the engine's figure is the figure.
Key takeaways
- Scheme digitisation is mostly about data and interpretation: clean invoices, a clean dealer master, and one agreed reading of each circular.
- AI-assisted parsing drafts the configuration from a circular quickly, but the scheme owner must review every line and settle every ambiguity.
- Reproduce every worked example in the circular as a test before go-live; it proves the engine and ends the argument about whether it is right.
- Go live with a few functions in a few sales offices, run one full period through settlement, and only then widen.
Frequently asked questions
What is scheme digitisation?
Scheme digitisation is converting dealer scheme circulars into configuration that a scheme engine calculates automatically from invoices, with progress shown to the dealer during the period and payouts routed through an approval chain. It replaces spreadsheets and claim-based settlement.
How do you digitise dealer schemes?
Collect the circulars and worked examples, structure each scheme into configuration, connect the invoice feed, clean the dealer master, reproduce every worked example as a test, set approval and payout rules, then go live in phases by sales office and by function.
Can AI read a scheme circular and set up the scheme?
AI can read a pasted circular and structure it into a draft configuration with a preview, which removes most of the manual set-up. It cannot resolve clauses the circular leaves ambiguous, so the scheme owner still reviews every line before the scheme is saved.
Do we need ERP integration before we can automate dealer schemes?
No. Invoices can be loaded by Excel upload on a fixed schedule to begin with, and integration with SAP, Tally or another ERP can follow. What matters is that the feed is complete, includes returns and credit notes, and arrives regularly.
How do you test that a digitised scheme calculates correctly?
Enter the inputs of every worked example printed in the circular and confirm the engine returns the same payout, then repeat with real dealers from last period's settlement sheet. Keep the examples as automated tests so that later changes cannot silently break them.
What usually goes wrong in a dealer scheme automation implementation?
Ambiguous circular clauses that nobody will decide, duplicate or outdated dealer codes, invoice feeds that arrive late or without returns, sampled testing, launching every function everywhere at once, an unbriefed sales team, and an old spreadsheet that is never retired.
Why do old and new dealer codes need to be clubbed?
Because a dealer who was re-coded mid-year would otherwise be treated as two dealers, with purchases split between them, and may miss a slab he has in fact reached. Clubbing counts the purchases of both codes together for scheme purposes.
How long does scheme digitisation take?
It depends on the number of schemes, the state of the dealer master and how quickly invoice data can be obtained, more than on the software. Once the invoice feed and master are in place, a new scheme can be configured and made live on Unotag in minutes.