Full-Population Revenue Verification Across Multi-Region, Multi-Stream Income

Sector:

South African specialised training and development entity operating in a regulated sporting environment.

Key outtakes: A full two-way match of an entire year’s revenue across four regional accounts and three separate general ledger streams — every entry parsed from free text, recomputed at the date-applicable rate across a mid-year rate change, split into its components, matched at the underlying participant and event level, and tested for eligibility against a status-changing register.

The Challenge 

The client’s revenue model is built on a fixed fee per participant event plus a percentage-based commission on each participant’s earnings, with each revenue stream split across an operating revenue account and a participant savings account on a fixed percentage basis. Revenue is accumulated across four regional general ledger accounts, settled at the underlying participant level, and governed by a register that determines participant eligibility, indenture commencement dates, and status changes during the year.

A mid-year rate change applied to the fixed fee component, meaning the correct amount per transaction was date-dependent.

The client needed an independent recalculation and matching exercise that would give them confidence revenue was being recognised completely and accurately across all four regions, that the correct rates had been applied across the rate change cut-over, that the operating revenue and savings splits had been recorded correctly, and that no transactions had been recognised against participants who were not eligible at the date of the activity.

Why Conventional Methods Fell Short

At root, the procedure is a two-way match between the client’s general ledger entries and an independently sourced third-party transaction dataset, applied across a full financial year, four regional accounts, three separate general ledger streams (operating revenue, participant earnings commission, participant savings) and several hundred eligible participants whose status changed over the course of the year.

Every entry in the client’s general ledger had to be parsed from a free-text description into the underlying transaction count, recomputed at the rate applicable to the transaction date, split into its operating-revenue and participant-savings components, then matched against the corresponding event in the independent third-party record. Every participant referenced in the general ledger had to be confirmed against the register, with eligibility tested as at the actual transaction date rather than at year-end. Reversals, off-register entries, post-termination activity, and pre-indenture activity all had to be flagged as exceptions.

Manually, this scales linearly with transaction volume in the worst possible way. A sample-based approach would have left the bulk of the population uncovered, defeating the purpose of the engagement — the value the client wanted was completeness over the full year, not directional comfort on a sample. Manually parsing free-text descriptions, applying date-dependent rates, computing percentage splits, matching against an independent data source, and cross-referencing against a status-changing register, line by line across the full population, is not a procedure that can be delivered to deadline by hand without a much larger team than the engagement could realistically support.

Our Approach with Monsoon

We loaded the four regional general ledger files, the participant earnings general ledger, the participant savings general ledger, the participant register, and the independently sourced third-party transaction data into Monsoon.

The platform then:

• Parsed each general ledger entry into its underlying transaction count.
• Applied the correct date-dependent rate against the rate change cut-over.
• Computed the operating-revenue and savings splits per entry.
• Matched each entry to the corresponding event in the independent third-party record.
• Tested eligibility per participant per transaction date against the register.
• Surfaced reversals, off-register entries, post-termination activity, pre-indenture activity, and rate or split mismatches as flagged exceptions for our review.

Outcomes for the Client

• Full-population two-way matching of revenue across four regions, three general ledger streams and a full financial year — rather than a sample-based view.
• Every transaction independently recomputed against the date-applicable rate, with the rate change cut-over handled cleanly across the population.
• Eligibility verified per participant per transaction date against the register, including the more nuanced cases — post-termination activity, pre-indenture activity, off-register names, and status changes during the year.
• An actionable exception list rather than a directional summary, putting the client in a position to act on specific items.

What This Meant for RAiN

A procedure that, on a manual basis, would have either consumed the engagement margin or forced a sampling compromise was delivered at full-population coverage by a small team within the engagement’s fee envelope. The structured methodology — parse, recompute, split, match, flag — is reusable on any engagement with a similar revenue-against-independent-record structure, making the work re-deployable on the next engagement of this type with minimal reconfiguration.