From Proof of Concept to Go-Live: Running a Rebate Software Project

A rebate or claims software project runs in four stages. Prove it on your own data, prepare the data and scheme terms, go live on a narrow scope alongside the existing process, and measure what changed against a baseline. The most common failure is skipping the first stage, because a demo on the vendor's data proves nothing about your schemes.

This is a vendor-neutral project guide — it should be equally useful whoever you buy from. Throughout, claims means distributor and channel claims, not insurance claims; rebate means a trade or channel rebate, not an income-tax rebate; and a trade deduction means an amount a customer withholds from an invoice payment, not a tax-deductible business expense. Where this article names no figures, that is deliberate.

This article covers how to run the project. Two neighbours cover the questions on either side of it: how to choose between options is the evaluation question, and what makes implementation hard in India specifically is the context question. Read them as a sequence. If you sell into organised retail as well as general trade, the retail-specific evaluation covers what differs.

One scoping decision belongs before any of this: whether the system sits alongside your existing stack or replaces part of it. Claims management alongside your accounting system and alongside a DMS cover the two common shapes, and the answer changes what stage two has to prepare.

Stage one: the proof of concept

A demo and a proof of concept are not the same exercise, and conflating them is the single most expensive mistake available at this stage.

A demo is a vendor showing capability on data they chose. It is genuinely useful — it tells you whether a product is in the right category, whether the interface is tolerable, whether the team knows the domain. What it cannot tell you is whether the system handles your schemes, because the schemes in a demo were selected precisely because they demonstrate well.

A proof of concept inverts that. You choose the scheme, and you choose the ugliest one you have.

The test is not "can it calculate a rebate". Almost anything can calculate a rebate. The test is whether it can calculate the scheme your team dreads at month-end — the one with a mixed basket, a qualifier gate, a mid-period rate revision, and an exception someone negotiated verbally two years ago.

What to test

What to test	Why it matters	What a pass looks like
Model your most complicated live scheme	If your hardest scheme cannot be modelled, nothing else on this list matters	The scheme is configured without a workaround, and the configuration is readable by your own team
Load one period of your real invoice data, exported from your own system	Sample data hides every problem that lives in your data	The export loads without manual repair, or the repairs needed are documented — check it against the fields a claim actually needs
Calculate entitlement for ten real partners and reconcile against your existing calculation	This is the only test that produces a number you can check	Differences are all explained — and each traced to either data or configuration, not "the system rounds differently"
Produce a settlement document for one claim end to end	Calculation is half the job; settlement is where most tools thin out	A document is produced with a reference back to the claim it settles
Handle one deliberate exception	Exceptions are the normal case, not the edge case	A partner failing a gate, or a return after settlement, is handled as a defined path rather than a manual override
Change a scheme term mid-test and re-run	Your scheme calendar will demand this repeatedly	Your own team makes the change, without a vendor ticket, and the old period still calculates on the old terms
Show the audit trail for one settlement	You will be asked to explain a number months later	Who changed what and when is visible, including the scheme version in force — see maker-checker on imported claim data

Two notes on running this well.

Use your own export, not a cleaned file. The temptation is to tidy the data before loading it, because a failed load feels like a failed test. It is the opposite: a load that fails on your real export has told you something true and cheap, months before it would have told you the same thing expensively.

Reconcile against your existing number, and expect to be wrong sometimes. When the proof of concept and your spreadsheet disagree, the spreadsheet is not automatically right. Several of these exercises end with a team discovering their existing calculation had a defect. That is a good outcome, found at the safest possible moment — but only if the reconciliation is done line by line rather than on totals.

A proof of concept run on the vendor's sample data has tested the vendor's sample data.

Stage two: what to prepare before go-live

Data preparation is usually the longest stage of the project, and it is almost always the stage that was underestimated. It is also mostly your work rather than the vendor's, which is why it slips: it competes with month-end.

The single most useful reframe is that this stage is not "data cleanup" as a chore. Every item below is a thing that, left undone, produces wrong numbers silently rather than an error message.

The go-live checklist

Item	Who owns it	Why go-live fails without it
Party master reconciled and coded	Commercial + finance	Partners matched by name silently drop rows; a trailing space is a different partner. Use a stable code, anchored on GSTIN where available
Item or SKU master mapped between systems	Product / supply chain	Scheme scope is defined on products; unmapped items fall outside every calculation without complaint
Scheme terms documented for every live scheme, with versions and effective dates	Scheme owner	Without effective dates, a claim for an old period is validated against today's terms — arithmetic that works, against the wrong rules
Export format agreed and tested for at least two consecutive periods	IT	A format that worked once is not a format. The second period is what proves it repeats. Where you have e-invoice data, decide whether it is the source
Opening position agreed — which claims are in flight and how they are handled	Finance	Undefined, in-flight claims get processed twice or not at all, and the gap surfaces as a partner dispute. Reconciling opening claim balances is its own exercise
Approval thresholds and who approves what	Finance	Configured late, approvals get switched off "temporarily" to hit a deadline and stay off. Decide the approval workflow before go-live, not after
The parallel-run period defined, with a date	Project owner	Without a date, the parallel run becomes indefinite and the switch never happens
A named owner for the workflow	Sponsor	Shared ownership means unresolved exceptions have no home and simply age
What history is being loaded, and for reference or recalculation	Finance + IT	Loading history for reference is cheap; loading it for recalculation means it must be as clean as current data

Two of these deserve more than a row.

Master data is the whole game. Master-data hygiene determines whether stage four is arithmetic or archaeology. Partner and item records that match on codes reconcile; records that match on names do not, and the failure is invisible — you get a smaller number, not an error. If you do one thing before go-live, do this.

Scheme terms have to exist as records, not correspondence. Most companies discover at this point that their scheme terms live in circulars, emails and one person's memory. Writing them into structured agreement terms with versions and effective dates is real work, and it is the work that makes everything afterwards checkable. It is also the part no software can do for you.

The history decision is worth thinking about carefully rather than defaulting to "load everything". History loaded for reference lets someone look up what happened. History loaded for recalculation becomes part of your live data and must meet the same standard. The second is far more expensive, and is only occasionally what anyone actually needs.

Stage three: going live without breaking the current cycle

Claims settlement does not pause for an implementation. Partners keep transacting, claims keep arriving, and month-end keeps happening — so go-live has to happen inside a running process rather than during a gap in it.

The phasing that works, in order:

1. Start at a period boundary, not mid-scheme. A scheme half-measured in one system and half in another cannot be reconciled to anything. Wait for the boundary; it is never as far away as the pressure to start suggests.

2. Go live on one scheme type and one partner group. Not the easiest — one that is representative. An implementation proven on your simplest scheme has proven very little, and widening will then surface every problem at once, at scale.

3. Run the old and new processes in parallel for one full cycle. Both calculating, both settling on the old process's numbers. This is the expensive-feeling step that everything else depends on: it is the only point at which you have two independently produced numbers on the same real data.

4. Reconcile every difference before switching — and classify each one. Every difference is either a data problem or a configuration problem. Resist the third explanation, that one system is simply "wrong", because it stops the investigation before the cause is found. A difference you cannot classify is a difference you have not understood, and it will recur.

5. Widen only after a clean cycle. One cycle where the two processes agree, or disagree only in ways you have explained and accepted. Then add the next scheme type or partner group.

Trying to migrate everything at once is the most common cause of a stalled project. It fails in a specific way: many small problems surface simultaneously, none individually serious, and the team cannot tell which are real defects and which are data artefacts. Confidence drains, the old process quietly continues as the real one, and the new system becomes a parallel record nobody trusts. The point of narrow scope is not caution — it is diagnosability.

Moving off spreadsheets covers the transition itself in more detail, and who needs to be on the project covers the team shape this phasing assumes.

Stage four: what to measure in the first ninety days

Measurement is where projects lose the argument they had already won. The work improved something, nobody recorded what it was like before, and the improvement becomes a matter of opinion.

Measure your baseline before go-live if you possibly can. The pre-go-live numbers are the only ones that become impossible to reconstruct afterwards — once the old process stops, the evidence of how it performed stops with it. Even rough figures, written down with their method, are worth far more than precise figures computed later from memory.

The ninety-day measures

Measure	How to calculate it	What it tells you
First-time-right claim rate	Claims settled with no query, as a share of claims received in the period	The quality of what arrives, and of your submission guidance — usually the highest-leverage number on this list
Median days from claim submission to settlement	Median, not mean — a few very old claims will distort an average	The partner's actual experience, and your working-capital position
Open claim ageing	Value and count by age band, at period end	Whether the backlog is clearing or just moving; a falling count with rising value means the hard ones are being deferred
Accrual accuracy	Accrued versus actual settled, for one scheme that has fully closed	Whether your provisions can be relied on — only meaningful on a closed scheme. See rebate accrual management for the method
Exceptions per period	Count, and the trend across periods	Whether exceptions are being resolved or accumulating. The trend matters more than the level
Schemes fully configured in the system	Count, against schemes still handled outside it	Real adoption. A system holding half your schemes has not replaced anything
Disputes raised per period	Count and value, by cause where you can attribute it	Whether validation is catching problems earlier

Two disciplines make these numbers mean something.

The first measurement is a baseline, not a result. Nothing can be claimed as an improvement until there are two comparable periods, measured the same way. A single period tells you where you are, which is valuable and different.

Your own baseline is the only meaningful comparison. This article quotes no benchmark for any of these measures, deliberately. Published figures in this area vary so widely by company size, channel structure, scheme complexity and data quality that a comparison against them is noise. A company whose first-time-right rate is poor by some external standard but improving every period is winning; one that matches an industry figure and is flat is not.

Track the count of schemes configured in the system especially closely. It is the measure most likely to reveal that adoption stalled, and the one least likely to be reported voluntarily.

What usually goes wrong

Six causes, in rough order of frequency. None of them is software capability.

Data readiness underestimated. Covered above, and worth repeating because it is the leading cause by a wide margin. The estimate is made by people looking at a system, and the work is in the masters.

Scope taken too wide. Everything at once, for good reasons — a fiscal-year boundary, a retiring system, a sponsor wanting visible progress. It produces the undiagnosable-difference problem described in stage three.

The scheme owner not involved. Implementations get staffed with finance and IT, because they look like a finance-and-IT project. But the person who decides what a scheme means, and who negotiated the exceptions, is usually in commercial. Without them, configuration encodes what the terms appear to say rather than what the business actually does. Getting the roles clear matters as much as getting the software right.

No parallel run. Usually cut for time, late in the project, when the parallel period is the only remaining slack. It removes the only evidence that the new numbers are right.

No baseline measured. The project delivers and cannot demonstrate it. This is a reporting failure with real consequences, because the next phase of investment depends on the previous one being visibly worth it.

Configuration handed entirely to the vendor. This one deserves emphasis, because it looks like good delegation and is a structural trap. If changing a slab, a threshold or a date requires raising a ticket, then your system's responsiveness is bounded by someone else's queue — and your scheme calendar does not care. Teams in that position do the sensible local thing: they work out the change in a spreadsheet to hit the deadline, and post the result. Within a few quarters the spreadsheet is the real system again and the software is a record of it. Insist that your own team can configure a scheme change during the project, and prove it in the proof of concept.

A realistic timeline

Ask what the sequence is, not how long it takes.

The dependencies are firm even though the durations are not. The proof of concept comes first, because its outcome can change the decision entirely. Data preparation follows, and is usually the longest stage — it is also the one that can start before a vendor is even selected, because reconciling your party master and documenting your scheme terms are useful whatever you buy. A parallel cycle follows, and its length is set by your own settlement cycle rather than by anything negotiable. Widening follows a clean cycle.

What determines the calendar is data readiness, not software or vendor capacity. Two companies buying the same product in the same month can go live many months apart for reasons entirely internal to them.

So treat any duration quoted before someone has seen your master data and your scheme documentation as what it is: a guess offered to answer a reasonable question. The honest version of that answer is a sequence plus a dependency, which is what this section is.

Where RebateLedger fits

RebateLedger is a claims, rebate and trade-scheme settlement system built for the Indian channel, and this article is deliberately written to be useful whoever you buy from — the project discipline above is the same either way.

Two points are relevant to the stages above. Scheme terms are held with versions and effective dates, so a claim for a past period is validated against the terms in force on the transaction dates. And scheme configuration is intended to be done by your own team rather than through a vendor request, which is the dependency that stage-three phasing and the last failure mode both turn on.

If you want to run the proof of concept described above on your own schemes and your own data, book a demo and bring your most difficult scheme.

General information. This article describes project practice for claims and rebate software implementations. It quotes no timelines and no benchmark figures, because both depend heavily on your own data and scheme complexity — your own baseline is the only meaningful comparison. Nothing here is tax, accounting or legal advice.

Read next

• Distributor claims software: buyer's guide — how to choose, before you get to a proof of concept.
• The real challenges of implementing rebate software in India — the context this project sits inside.
• Migrating rebate claims off spreadsheets — the transition in more detail.
• Master-data hygiene for claims reconciliation — the stage-two work that determines everything after it.
• The claim lifecycle end to end — the process the system has to support.
• Who belongs on the implementation team — the staffing this phasing assumes.
• Claims management ROI benchmarks — how to think about the business case behind the project.
• Distributor claims management — the wider discipline the system serves.