How to Reconcile Opening Claim Balances When Switching Claims Platforms

Moving claims to software is covered end to end in migrating rebate claims off spreadsheets. This article goes deep on the step that decides whether the new system starts trusted or disputed: opening claim balances.

The method: freeze a cut-off date, extract the open-claim register as of that date, get distributor sign-off on the balances (the step everyone skips), load them as opening balances, and settle legacy claims from the old register while new claims flow through the platform.

Why opening balances are the migration's real risk

The scheme masters and sales registers you migrate are your data — if they're wrong, you find out and fix them. An opening claim balance is a shared number: the distributor carries the mirror entry in their books. Migrate a number they disagree with and you haven't migrated a balance, you've migrated a dispute — one that surfaces at the worst time, months later, pointed at the new system.

Step 1 — Freeze a cut-off date

Pick a date with a natural break: a month end, ideally a quarter end, after a settlement run. Communicate it to distributors in advance: claims submitted up to the cut-off settle from the old process; claims after it go through the new platform. Resist a mid-cycle cut-off — a scheme window straddling the cut-off means computing one scheme in two systems.

Step 2 — Extract the open-claim register

As of the cut-off, extract every unsettled position, in three buckets:

Bucket	What it is	Typical source
Submitted, unvalidated	Claims received but not yet checked	Claim tracker / inbox / Excel
Approved, unsettled	Validated claims awaiting credit note or payment	Claim tracker + accounts
Accrued, unclaimed	Scheme amounts earned but not yet claimed	Scheme workings / provision sheet

Carry the ageing with each line — a claim open 400 days is a different object from one open 40 days, and the new platform should show that from day one. If your provision sheet and claim tracker disagree about bucket three, reconcile them before migrating; the method is in rebate accrual management.

Step 3 — Get distributor sign-off (the step everyone skips)

Send each distributor a one-page balance confirmation: the open claims you have on record for them, by bucket, with amounts and the cut-off date — and ask them to confirm or annotate within a stated window. It feels like slow bureaucracy. It is the opposite: every signature converts your number into an agreed number, and every annotation surfaces a dispute now, while the old records and the people who know them are still at hand.

A workable confirmation letter needs only: the cut-off date, the line-level open claims with amounts, a "confirmed / disagree because…" tick, and a sign-and-return deadline with the default stated (unanswered = follow-up call, not assumed agreement).

Step 4 — Load agreed balances; park disputes explicitly

Load the agreed balances as opening entries against each distributor. The disputed remainder goes on an exceptions list — distributor, amount, their stated reason, your evidence — worked as its own small project. The two rules that keep this honest: never load a disputed number as agreed, and never drop it silently; a dropped claim reads as acceptance to whoever benefits from the silence.

Step 5 — Settle legacy from the old register; run new claims through the platform

Legacy claims (pre-cut-off) settle from the old register so the old process finishes its own work — don't re-key history into the new system just to close it there. New claims flow through the platform from day one. The overlap period is short and defined, unlike a parallel run, which serves a different purpose — proving the new system's computations match before you rely on them.

The GST angle: the Section 34(2) clock is running

Legacy claims often settle by credit note against old invoices — and Section 34(2) of the CGST Act allows a credit note with tax adjustment only up to 30 November following the financial year of the underlying supply (or the annual-return date, if earlier). A migration that drifts past that window quietly converts what could have been a GST credit note into a commercial credit note — a different document with a different tax result. Age your legacy claims against their invoice FY at cut-off, and prioritise the ones the calendar is about to reclassify. The commercial-versus-GST decision itself is covered in financial vs tax credit notes under GST.

This is general information, not tax advice — confirm the treatment of your legacy settlements with your CA.

The checklist

1. Cut-off date chosen at a period break and announced.
2. Open-claim register extracted in three buckets, with ageing.
3. Provision sheet and claim tracker reconciled to each other.
4. Balance-confirmation letters sent; responses tracked to a deadline.
5. Agreed balances loaded; disputes parked on a named exceptions list.
6. Legacy claims aged against the Section 34(2) window and prioritised.
7. Old register frozen for new entries after cut-off.

If you're planning the wider move, start with what the whole migration involves, decide who needs to be on the team, and set how long to run both systems in parallel.