Commission Data Migration During a Broking System Implementation

Broking system implementations are scoped around what a demo shows well: client onboarding, quote comparison, policy issuance, a claims tracker, a dashboard the managing director likes. Commission appears in the plan somewhere in phase two, described as "commission module configuration," estimated at three weeks.

It is the workstream that runs late, for a structural reason. Every other module can start from a clean sheet: a client record created in the new system is simply correct. Commission cannot, because commission is retrospective. To compute what an insurer owes today, the system must know what rate applied to a policy incepted eighteen months ago under a schedule since revised twice, what endorsements moved the premium, whether the placement was co-broked under a split agreed by email, and what has been received. That is not configuration. It is a data migration out of a source never designed to answer those questions.

The scrutiny direction makes this worse to get wrong now. The draft IRDAI (Insurance Intermediaries) (Amendment) Regulations circulated for consultation in June 2026, still only a draft, would put intermediation revenue into a separate audited schedule filed with IRDAI. Reporting rests on the same underlying commission records, and a firm whose migration silently dropped its rate history will discover it at audit rather than at go-live. The adjacent discipline, building commission MIS that reconciles to what you file, assumes the underlying data exists and is right. This post is about the project that makes that true.

Plan the migration from the legacy system's data, not its documentation. Documentation describes what the system was meant to hold. Profiling reveals what fifteen years of users actually put in it. Before any mapping work, run a profiling pass against a fixed question set.

1. Volumes and horizon. How many policy records and commission transactions, over how many years, and where a past system change already broke continuity.
2. Cardinality and integrity. How many commission rows have no matching policy. How many policies carry a rate of zero, or null, or 100. How many carry a co-broker flag with no counterparty populated.
3. Free-text contamination. Which fields that should be coded are actually free text. Insurer name is the classic: a source with 40 insurers routinely holds 300 distinct spellings, and every one must resolve to a single master record before a rate can attach.
4. Date discipline. Are inception, issuance, receipt and statement dates populated and distinct, or has one been overloaded to mean whatever the user meant that day. This decides whether accrual can be recomputed at all.
5. Off-system data. The uncomfortable one. How much commission truth lives outside the system: rate cards on a shared drive, co-broking splits in email, adjustments in a spreadsheet the controller owns. This is never zero, and its size determines the shape of the project.

Legacy broking systems model commission as an attribute of a policy: one policy, one rate, one brokerage amount, computed at issuance and stored. Modern platforms model it as transactions against a policy, each with its own basis, date and status. Mapping an attribute onto a transaction stream is not a transformation, it is an invention, and the project must decide what it is inventing.

The breaks worth anticipating:

• One rate versus a rate per component. A package policy with fire, burglary and machinery breakdown sections may carry different rates by section. If the source stored a blended rate at policy level, section rates cannot be recovered by arithmetic, only from the rate card that applied.
• Amount versus basis. Storing brokerage as an amount loses the reason. Storing it as a rate against a premium base preserves recomputability. Sources holding only the amount cannot be recomputed after an endorsement changes the premium, which is why the endorsement chain problem exists at all.
• Status vocabulary. Legacy status fields tend to be a flat list (booked, received, cancelled) while the target distinguishes accrued, invoiced, received, netted, reversed and written off. Every source row must be assigned a target state by rule rather than by lookup.

A new system is configured with today's rate tables. Someone loads the current schedule per insurer per line, tests a new policy, gets the right brokerage, signs the module off. Then the team migrates three years of history into it, and the system recomputes brokerage on a 2024 policy using 2026 rates. Every historical figure is wrong, in a way that looks plausible.

The requirement is that rate tables be effective-dated and versioned, with every historical version loaded rather than only the current one. A rate record carries an effective-from and effective-to date, and the engine selects the version by the applicable policy date rather than by today.

Two follow-on decisions must be made explicitly:

1. Which date drives selection. Inception date is the usual and defensible answer, and it should match what the insurer agreement says. If the agreement fixes the rate as at inception, the system must select on inception. If the firm's agreements are silent, the migration has just surfaced a contract problem, which is useful to know.
2. What happens when history is unavailable. Firms frequently cannot produce schedules from more than two or three years back, and sometimes the schedule was never a document, just a practice. Where the historical rate cannot be established, migrate the stored brokerage amount as an immutable fact, flagged non-recomputable, rather than let the engine derive a number from a rate that did not apply. That flag prevents a large category of silent error.

A commission migration has no clean cut, because a book of business does not stop. Build the cutover matrix explicitly rather than discovering it on the weekend:

1. Placed, premium not yet received. Migrate as accrued with no receipt. The receipt will land against a policy never placed in the new system, so the record must carry enough identity (insurer reference, policy number, premium) to match.
2. Premium received, brokerage not yet received. The receivable case, and the largest single risk. Covered in the next section.
3. Instalment-paid policies mid-schedule. The hardest category. Some instalments received, some pending, the schedule often not held as data at all. Migrate the contracted schedule, receipts to date and the accrual basis, or the new system misstates both the receivable and the forward pipeline.
4. Policies in endorsement. An endorsement raised in the legacy system and unprocessed at cutover is either abandoned and re-raised, or migrated mid-flight. Pick one per endorsement type; migrating a partially-processed endorsement is rarely worth it.
5. Cancelled with recovery pending. A reversal identified but unsettled must migrate as a liability, not vanish. These are most likely to be dropped, because the legacy system often holds them as a note rather than a row.
6. Expired with adjustment pending. Declaration covers and turnover-adjusted policies whose final adjustment has not run. Migrate as open though the period has ended.

The control is an identity that must hold on cutover day: total brokerage accrued and unreceived per insurer in the legacy system equals the same total in the new system equals the balance in the general ledger. Three numbers, one value. On first pass, no two of them agree.

Work the reconciliation in a fixed order, because differences compound if chased in parallel:

1. Legacy to ledger, before migration. If these do not tie, the migration is not the problem and cannot be the fix. This is a frequent and uncomfortable discovery: firms find here that the receivable they have been reporting was never derived from the policy system. Resolve it before proceeding, or you will spend the project debugging a discrepancy that predates it.
2. Legacy to staging. Extract completeness only. Row counts and control totals by insurer, by year. Nothing transformed yet. Any difference here is an extract defect and should be zero.
3. Staging to target. Transformation correctness. Differences are your rules disagreeing with reality, and each should decompose to a named rule.
4. Target to ledger. The final tie, and the one finance signs.

Set a variance tolerance before you start, as an absolute amount per insurer rather than a percentage of the total. A tolerance of 0.5 percent on a INR 40 crore receivable is INR 20 lakh, which is not a rounding difference but a defect the project has agreed not to look at. Unexplained variances above tolerance are go-live blockers. Explained variances of any size are fine: a reconciling item with an owner and a date is a normal state of affairs.

Parallel running commission is the only test that proves the brokerage engine works, and it is routinely cut when the project is late. Cutting it is how a firm discovers the engine is wrong in month three of live operation. A parallel run is not "both systems are switched on." For a stated period, ideally two full statement cycles, every commission event is processed in both systems and the outputs differenced daily: brokerage per new policy; brokerage recomputed after each endorsement; receipts applied and the resulting receivable; and the revenue posted to the ledger.

Acceptance criteria should be written before the build and should be falsifiable. Criteria reading "commission calculations are accurate" cannot be failed and therefore cannot be passed. Criteria that work look like these:

• For 100 percent of a stratified sample of 500 in-force policies spanning all insurers, all lines and all three migrated financial years, brokerage in the target equals brokerage in the source, or the difference is attributable to a named and approved transformation rule.
• For every policy carrying an endorsement chain of three or more, recomputed brokerage after the final endorsement matches the legacy figure or a documented recomputation.
• Opening receivable by insurer ties to the ledger within the stated absolute tolerance, with every variance above tolerance itemised and owned.
• Every co-broked policy carries a split that sums to 100 percent and matches the underlying arrangement evidence.

Sample selection is where acceptance testing usually fails. A random sample of 500 policies from a book dominated by simple annual motor and fire business contains almost no instalment schedules, almost no co-broking and almost no long endorsement chains, and passes comfortably while every hard case goes untested. Stratify toward the ugly categories: the sample exists to find defects, not to produce a pass rate.

Endorsement chains

A policy incepts at a premium of INR 10 lakh. In month three an addition takes it to INR 14 lakh. In month six a deletion drops it to INR 12 lakh. In month nine a sum insured correction backdated to inception restates it to INR 13 lakh. Brokerage should now reflect a premium history, not a premium. Legacy systems storing one brokerage amount per policy typically hold only the latest figure, having overwritten the rest, so the chain cannot be reconstructed from the source at all.

Co-broked splits

A co-broked placement has a share summing to 100 percent across parties, an agreed lead, and a settlement direction. Legacy systems commonly hold a flag and a percentage against the firm's own share, with the counterparty and the arrangement living in the placement email. Migrating the percentage without the arrangement produces a system that computes the right number for reasons it cannot evidence, which is fine until someone disputes a split. Collect the arrangements as a project workstream, not as a data field, and accept that some will not be found and must be confirmed with counterparties before go-live.

Historical rate changes

Worth repeating because it is the defect that survives longest undetected. A brokerage figure computed from the wrong rate version is not obviously wrong. It is a plausible number in a plausible range on a report nobody re-derives, and it surfaces at audit or when an insurer disputes a statement, by which time the firm has reported on it for a year.

A commission migration is a reconstruction exercise disguised as a data-loading exercise. The engineering is not difficult. What is difficult is establishing what was true, and firms underestimate how much of that truth was never written down. Budget the discovery, not just the build. IRDAI signalled in July 2026 that a consultation paper on distribution remuneration was expected by the end of that month; as at the date of this post it had not been published, and everything reported about its contents remains a proposal. Whatever emerges will be implemented against whatever commission data the firm can stand behind.