Multi-stream revenue verification

confirm: whether this relates to the equestrian-sector work listed for ALE; do not attach ALE's name without confirmation and consent

1. 01Problem

   Revenue came from a fixed fee per participant event and a commission on participant earnings, each split between operating revenue and a participant savings account. A mid-year rate change meant the correct fee depended on the transaction date.

2. 02Scope

   A full financial year; four regional ledger accounts; three revenue streams; several hundred participants whose eligibility changed during the year.

3. 03Monsoon's contribution

   • Parsed ledger descriptions into transaction counts.
   • Recalculated at the rate applicable on each date and computed the revenue/savings split.
   • Matched every entry two ways to an independent third-party transaction dataset.
   • Tested eligibility per participant per date against the register.

   Ledger ⇄ third-party eventsSample data

   Ledger entry	Third-party event	Rate applied	Result
   JN-30412 Region 2	EV-88104	Rate before change	Matched
   JN-30417 Region 2	EV-88131	Old rate after change date	Rate mismatch
   JN-30420 Region 4	No event found	n/a	Unmatched
   No entry found	EV-88177	n/a	Unmatched

4. 04Professional oversight

   The engagement team reviewed the exception list (reversals, off-register entries, activity outside eligibility dates and rate or split mismatches) before reporting to the client.

5. 05Evidenced outcome

   Full-population match across all regions and streams, and an exception list provided to the client. source: exception counts, values, effort, client consent

Client anonymised. Outputs were prepared for professional review and sign-off. confirm: client consent (E1) Related: Core platform.