Accepting Fees in scoreio: Entry Payments and Payment Types Inside the Platform

A team's registration and its payment are essentially one event torn into two halves. The registration lives in the platform, while the competition entry payment sits somewhere alongside it: in a bank statement, in a separate tracking spreadsheet, in the treasurer's head. Reconciling them by hand is slow and error-prone: who paid, who didn't, how much exactly and in what currency. We joined the two halves. Fee tracking is now built right into scoreio — with several payment types, amounts, currency and a check order.
How it used to be
The financial side of a competition traditionally lived apart from registrations. A team registered in the system, while the fee was tracked in parallel — at the bank, in Excel, in the records of whoever was responsible for the money. To find out whether a specific registration was paid, you had to cross-reference two independent sources.
This spawned a whole class of routine problems. A payment arrives, but it's not immediately clear which registration it belongs to. A competition has several fee categories — per team, per athlete, per division — and each was counted by hand. Events in different countries meant different currencies, and no unified picture formed. And before registration closed, someone sat down to reconcile the list of payers against the list of registrants, line by line.
The root of the problem was the same as with the schedule: money was disconnected from the registration data. The system knew about a team but knew nothing about its payment.
What changed

We moved fee tracking inside the platform. Now the financial side is a property of the competition and the registration, not a separate universe.
Payment as part of the competition
A competition gained payment parameters: the fact that participation is paid, the fee currency and the payment type. The organizer sets the financial rules right when configuring the event — and they become part of its logic rather than an external attachment.
Several fee types
The platform supports different payment types for a single competition. Each type has its own amount, currency and check order. This means a complex financial model — several fee categories with different amounts — is described inside the system rather than kept in someone's memory.
Check order
Payment types have a check order — the sequence in which the organizer processes payments. This brings order to financial work: it's clear what to confirm and in what sequence, and the process doesn't turn into a chaotic reconciliation.
Currency per region
Because currency is set explicitly, competitions in different countries are run correctly. A fee amount is always tied to its currency, and there's no confusion when working with an international calendar.
What this gives you
- Finances and registrations in one place. Payment stops being a separate spreadsheet — it's tied to the registration inside the platform.
- Transparency. You can see which fee types are set, with what amounts and in what currency. Less manual reconciliation before registration closes.
- A flexible fee model. You can describe several payment types with different amounts — per team, athlete, division or any scheme of yours.
- Correct multi-currency support. Events in different countries are each run in their own currency, with no eyeballed conversions.
- Ordered processing. The check order sets a clear sequence for working with payments.
Scenarios where this solves the problem
Several fee categories at one tournament. An event has a team fee and a separate one per athlete. Before, this was counted by hand in a spreadsheet. Now both payment types are described in the system with their own amounts — and the tournament's financial model is visible as a whole, without a separate calculator.
An international series in different currencies. Stages take place in several countries, and the fees in each are in their own currency. Because currency is set at the competition level, the committee runs the whole series in one space, without confusing amounts or converting them by hand.
Reconciliation before registration closes. When payment is tied to the registration, the "who paid" picture is assembled inside the system. Instead of line-by-line matching of two lists, the organizer works with finances in the same place as the registrations themselves.
Frequently asked questions
Where are fees tracked now? Inside the platform. A competition has payment parameters — the fact of paid participation, currency and payment type — and fee types are stored with their own amounts and check order.
Can I set several fee types? Yes. A single competition supports different payment types, each with its own amount, currency and check order.
What about different currencies? Currency is set explicitly at the competition level, so an international calendar is run correctly — each event in its own currency.
Why is a check order needed? It sets the sequence of processing payments, so financial work is ordered rather than a chaotic reconciliation.
Does this replace accounting? This is about tracking fees inside the registration process: which amounts are set, in what currency and in what order they're checked. The event's financial picture is assembled right next to the registrations themselves.
How to get started
Tracking payments inside the platform is about finances no longer being a parallel universe. Fees are tied to the competition and registration, described with amounts, currency and check order. The committee sees the event's financial model in the same place it runs registration, and spends less time on manual reconciliation.
A natural continuation of fee tracking is flexible pricing by date: we added early bird registration to encourage teams to register in advance. And to keep every change to a registration transparent, the registration status history comes in handy.
Want to manage fees and payment types inside the platform? Request a demo or a pilot run of scoreio — we'll show you how to describe a competition's financial model and gather payments right alongside the registrations.