Casino Platform Reporting: Can Finance Explain the Number?

Here is the question that separates a real reporting evaluation from a vendor theatre: a finance user points at any number on the screen and asks, "show me the records behind that." In weak platforms the demonstrator opens another screen with another aggregated number. In strong ones, someone drills from the total to the transaction list, from the transaction to the external identifier, and from the identifier to the provider's matching record. Until you have watched that drill-down happen with your own example, the dashboard is decoration.

A casino platform report becomes useful when the team can explain how its numbers were produced. Start with a business question, then trace the records and definitions behind the answer. Choose one reporting period and one defined question for the evaluation — for instance: can your team account for the relevant transactions in a given week, and identify everything still unresolved at the agreed cut-off? That question is small enough to test completely and large enough to expose how the reporting model actually works.

Pick the question with finance in the room, and agree it before the first demonstration session. A defined question keeps the session from drifting into a tour of totals, and gives your CFO something written to accept or reject at the end of the round.

Define the time boundary first

Most reconciliation differences are born before a single record is compared — they come from mismatched definitions of "when." Ask which time zone the report uses and which timestamp determines inclusion. Creation, processing, and settlement are three different moments, and different providers pick different ones. A platform counting a deposit at creation will not match a provider statement that counts it at settlement; both are correct, and the difference still lands on the finance team's desk.

Document the agreed convention for every external feed: which timestamp, which zone, which cut-off. This is a definitions exercise, not a technical one, and it belongs in writing. The operational team should not have to reconstruct the convention from memory each time a report is challenged — and reports get challenged precisely when the convention was never written down. This is one of the first items on our casino platform demo checklist for exactly that reason.

The same boundary problem shows up inside the platform itself, before any external comparison. A bonus liability report run at one cut-off will disagree with a run at another if active bonuses were claimed in between. A wallet ledger extract whose generation time is not recorded becomes impossible to interpret a week later. Push the demonstrator to show each report's generation details — and note it if those details are not displayed, because finance inherits that ambiguity every close.

Follow one record across systems

Now test the trace itself. Prepare synthetic examples — clearly marked test data — that include a normal outcome and at least one exception: a completed deposit sequence, and a withdrawal that reversed, or a bonus that was granted and then voided. Ask which identifiers connect the platform record with the relevant external service. Can an authorised user find the corresponding evidence from both sides, without sending three teams an unstructured screenshot and a plea for help?

Watch who does the tracing. If only the vendor's demonstrator can navigate the chain, the process dies the day after onboarding. Finish by having your own finance user work the example independently, hands on the keyboard. That is the real acceptance test — the evaluation is not whether the feature exists, it is whether your team can operate it.

While hands are on the keyboard, test permissions too. Can an auditor read without writing? Can a finance user export without touching configuration? Access to financial records is a control item, and the export rights model matters almost as much as the fields themselves. A platform where every report is exportable only by an administrator creates a queue finance cannot afford at close.

A worked example: the week finance could not close

Consider a hypothetical operator — illustrative, not a client story — running casino and sportsbook on a shared wallet. The weekly GGR reconciliation shows a difference between the platform's settled-transaction total and the payment provider's statement. The finance user drills in and finds, expectably, two causes: withdrawals created before the cut-off but settled after it, and one reversed bonus that the platform counted on the grant date while the provider never moved the funds at all.

In a strong reporting model, this ends well: the pending withdrawals appear as a distinct unresolved set with identifiers, the bonus reversal carries its own correction record, and the finance user exports the reconciling items, attaches them to the close file, and moves on. In a weak model, pending items are invisible in the report, the reversal is netted silently into a later total, and the difference becomes a monthly ritual of spreadsheets and apologies. The buying question is not whether differences exist — they always exist. It is whether the platform hands finance a consistent, explainable set of records for resolving them. If shared wallet flows are part of your requirement set, our article on casino-sportsbook shared wallets goes deeper on the ledger behaviour to test.

Run this scenario as a live evaluation step, not as a ticket after the demo: deposit, withdrawal, reversal — trace each one with the supplier in the room. Ordered deliberately, it is under an hour of work and it predicts your entire first quarter of closes.

Back to the illustrative operator from earlier: its finance team now runs the same evaluation against every shortlisted platform, and the same two reconciling causes surface in each — pending withdrawals and the reversed bonus. The platforms differ sharply in what a finance user receives. One exports a reconciling-items file with identifiers in minutes. Another buries pending items until they settle, so the weekly close always includes a manual adjustment spreadsheet maintained by whoever has been longest on the team. The comparison is not close, but it is only visible if finance runs the actual export during evaluation. Screens lie; files do not.

Build the reconciliation field list

For every report finance cares about — GGR reconciliation, the bonus liability report, the wallet ledger extract, provider settlement matching — define the fields that make it reconcilable. Use a table like this during evaluation and make the vendor walk through each row against exported data, not a screen:

Field	Why finance needs it	Evaluation test
Stable transaction identifier	Connects the platform record to the provider's record in both directions	Trace one export row to the provider statement and back
Status with full lifecycle	Pending, settled, reversed, and corrected items must each be visible	Run the synthetic exception; watch every state appear
Timestamps with defined meaning	Creation, processing, settlement — labelled, not merged	Ask which timestamp drives the report cut-off
Bonus grant and reversal records	Bonus liability must reconcile; reversals cannot vanish into netting	Grant then void a bonus in test data; export both records
Correction audit trail	Historical changes need an author, a reason, and a re-viewable history	Ask to see the history of one corrected record
Drill-down from totals	Every aggregate should decompose into the records behind it	Pick a dashboard total; reach its transaction list unassisted

Have finance review the exported fields as well as the interface. A report that looks complete on screen regularly fails the export test, and the export is what your reconciliation process actually consumes.

Keep unresolved states visible

Ask directly how pending items, reversals, and corrections appear in the proposed reporting model — and listen for the difference between "shown" and "netted." The correct accounting treatment of those states is a policy question for your finance advisers, not for the platform. What belongs to the platform is the record: consistent, explainable, and never silently absorbed. Be careful about letting a dashboard label define accounting policy by accident; once a vendor's ambiguous label enters your close process, unwinding it takes quarters.

Push the same test on corrections. When a transaction is amended with appropriate authorisation, does the record show the original values, the amendment, the reason, and the actor? Finance teams find it hard to defend a re-run total without that audit trail, and auditors find it harder still. Test it during evaluation with a synthetic correction — most "oops" cases in live finance pass through this one badly.

Agree ownership of discrepancies

Every reconciliation depends on another party's data, which means every discrepancy needs an owner before it happens. Establish who investigates differences between the platform and each external provider, and what evidence each side must supply. Record how corrections are authorised and how historical changes can be reviewed later — by you, by an auditor, by a successor finance team that inherits your conventions.

A defensible workflow puts investigation assignments in writing before the first incident: this provider reports to us daily, differences are logged in a shared tracker, and after agreed working days the dispute escalates through a named route. Vague commitments like "we'll coordinate with our partners" are exactly how a five-line difference becomes a two-week email chain.

And if the evaluation involves sensitive support or escalation routes for disputed records, our article on iGaming platform support SLAs covers how those commitments should read. End every evaluation the same way it started: one finance user, one reporting period, one defined question — answered with records, not dashboards, and signed off in the file.

Close the evaluation the way it opened: have the finance user confirm the closing condition in writing — who reviewed the example, in which environment, and which records were handed over. File that note with the evaluation. When the same question resurfaces at audit or a live close, your team has a documented route, a named role, and evidence — not a memory of a convincing demo.

This guide describes reporting requirements to evaluate; it does not assert specific ScaleBets reporting functions. ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately. Bring your reporting requirements to a working session and put them through the evaluation above — the operator scorecard has a reporting section to help you structure it.