Records that hold up to review — invoices, receivables, reports
This page exists so the chair can forward it before the board votes. Every row below is a mechanism — written the way it works in the product — not an intention. Where a mechanism does not exist yet, it says so in the same row, not in a footnote.
The page is print-ready: ⌘/Ctrl + P prints it without navigation and without buttons, so it can go into the meeting pack.
Sequential numbers without gaps, assigned at issue
A draft has no number. The document receives it at the moment of issue, inside the same transaction, on a locked counter row — so two simultaneous issuers cannot get the same number and none can be skipped.
-
Draft
No number. Edited freely and deletable. It never enters the book of issued invoices.
-
Issue
The series counter increments in the same transaction as the document’s issue. The sequence is continuous within the club and within the tax period.
-
A series per type and per year
Invoices, stornos and credit notes each have their own series, and the series carries the year. Each runs its own sequence, printed in the form
RAC-2026-000123. -
Un-issuing
Possible only for the last number in the series, and only while the document has not been sent and no payment has been recorded. The counter steps back, so no gap forms.
| Series | Type | Last issued | Next |
|---|---|---|---|
| RAC-2026 | Invoice | RAC-2026-000141 | 000142 |
| STO-2026 | Storno | STO-2026-000004 | 000005 |
| DOB-2026 | Credit note | DOB-2026-000002 | 000003 |
Sample view. Storno and credit note run their own sequences, so a correction never punches a gap into the invoice sequence.
sample view · demo club
An issued invoice is neither edited nor deleted
What was issued stays in the book exactly as issued. A correction is always a new document. Deletion exists only for a draft, which has no number yet.
What freezes at issue
- A snapshot of the issuer — name, address, IBAN, as they were that day.
- A snapshot of the payer — name, address, e-mail.
- Items, amounts, discounts and the VAT rate.
- The SI12 reference and the UPN QR data.
- The issue date and the due date.
Changing the club’s address or IBAN half a year later does not change an invoice issued before.
What is still possible after issue
- Recording a payment, including partial, allocated across documents.
- Sending the document to the payer and sending a reminder.
- Issuing a storno — cancelling the whole document.
- Issuing a credit note — correcting part of the amount.
- Un-issuing under the conditions of the previous section.
None of these actions changes the issued document; each creates its own entry.
A correction is a document, not a delete key
A storno cancels the whole document; a credit note corrects part of the amount. Both are standalone documents with their own number and a reference to the original, so the path from mistake to correction is visible in the book both ways.
Correcting the whole document
- RAC-2026-000118
Issued 1 Jul 2026 · 78.00 € · wrong group.
- STO-2026-000004
A storno of the whole document, 3 Jul 2026, referencing the original.
- RAC-2026-000141
The corrected document, issued 3 Jul 2026 · 60.00 €.
Correcting part of the amount
- RAC-2026-000126
Issued 1 Jul 2026 · 92.00 €.
- DOB-2026-000002
A credit note of −18.00 €, 3 Jul 2026, referencing the original.
- Remaining due:
74.00 € — the original invoice does not change.
On storno, the billing key is released back into the records. The key is the triple member · fee plan · period. Once released, the next billing run may bill the same period again — and until it is released, it cannot, so there is no double charge. The issued line does not change; the release is recorded next to it.
| Entry | When it occurs | Who triggers it |
|---|---|---|
| created | A draft is created. | A user or the billing run |
| updated | The draft is edited. | A user |
| issued | The document is issued and receives a number. | A user or the billing run |
| un_issued | The issue is revoked under the conditions of section 01. | A user |
| sent | The document is sent to the payer by e-mail. | A user or the billing run |
| send_failed | Sending failed. | The system |
| reminder_sent | A reminder is sent. | A user |
| payment_recorded | A payment is recorded. | A user or a card payment |
| storno | A storno is issued. | A user |
| credited | A credit note is issued. | A user |
There are no other entry types. Entries are append-only — a row is never amended or deleted. Each records who triggered it and when; where the automatic billing run acted, there is no person, because there was none.
One document per payer and period
The billing run consolidates by payer, not by child and not by group: all their children, all their groups and all one-off charges of the same period land on one document with one reference.
-
Consolidation by payer
Two children in three groups mean one invoice, not five. The payer gets one pay slip and one set of questions about it.
-
Sibling discount
It computes itself, as a percentage of the fee. A euro discount — say “−10.00 € for the second child” — the billing run does not know.
-
One-off charges
A camp, a trip or gear lands on the same document as the fee, naming the child it concerns.
-
A member in several groups
Counts once. The line is created per fee plan and period, not per group, so there are no duplicate fees.
| Item | Member | Amount |
|---|---|---|
| Monthly fee · U11 · Jul 2026 | Nik Zupan | 32.00 € |
| Monthly fee · U9 · Jul 2026 | Ela Zupan | 28.00 € |
| Sibling discount · 10 % | Ela Zupan | −6.00 € |
| Winter camp Pokljuka · one-off | Ela Zupan | 45.00 € |
| Total due | payer A. Zupan | 99.00 € |
Sample view. The SI12 reference and the UPN QR are on the document; the payer can pay by scanning in their bank or by card.
You set the payer per child.
The club chooses who pays for a child, so separated parents each pay their own invoice. The payer can also be someone who is not the child’s guardian — an employer, a municipality, a sponsor — and one payer carries any number of children on a single consolidated invoice. An issued invoice holds a frozen payer snapshot, so a change going forward does not rewrite what was already issued.
Receivables by age, by payer, with contact
Open amounts are sorted into four age bands and grouped by payer, together with their e-mail and phone and the number of reminders each invoice has already received. The board sees who owes, for how long, and how many times they have been reminded.
| Payer | Contact | 0–30 | 31–60 | 61–90 | 90+ | Total | Reminders |
|---|---|---|---|---|---|---|---|
| A. Novak | a.novak@primer.si | 60.00 € | — | — | — | 60.00 € | 1× |
| M. Zupan | m.zupan@primer.si | — | 99.00 € | — | — | 99.00 € | 2× |
| T. Hribar | t.hribar@primer.si | — | — | 28.00 € | 56.00 € | 84.00 € | 3× |
| Total | 3 payers | 60.00 € | 99.00 € | 28.00 € | 56.00 € | 243.00 € | — |
Sample view. The same view backs sending reminders: pick a band, review the list, send.
Trigger reminders yourself — or leave them to the system.
By hand the action is bulk, one click, filtered by “at least this many days past due” (default 3 days), and goes out by e-mail. Automatic dunning is off by default: when you switch it on you set the interval between reminders, how many there may be at most, and the hour they go out — they are only sent on working days. Before switching it on you see how many invoices would qualify today. Every sent reminder increments the counter on the invoice, and the document records whether a person or the system triggered it.
Reports for the board, the federation and the municipality
Six reports over any period. Each returns the numbers a club counts by hand in a spreadsheet — and the basis they are computed from.
| Report | What it returns | Who typically needs it |
|---|---|---|
| Overview | Active members, arrivals and departures in the period, held and cancelled sessions, unmarked sessions, attendance rate; billed, received and open receivables. | The board |
| Attendance | Attendance by group and by session for the chosen period. | Coaches, the federation |
| Membership | Members by group, by age band (U9–U19 and seniors) with sex, arrivals and departures by month. | The municipality, the federation |
| Finance | Receivables by age and the mix of payment methods. | The board, accounting |
| Volunteers | Hours worked per family against the season goal. | The board |
| At risk | Members with three consecutive absences or attendance sharply below their own average. | Coaches, the board |
There is no ready-made form for the Sports Institute or the Sports Foundation.
in the works
Reports give the numbers and their basis; you fill in the grant form yourself. Financial fields are visible only to those with the finance grant — a coach does not see them.
Two journals as CSV — and what this is not
For accounting, two journals export today, each with a fixed header, for any period. They are also the only exports the club triggers itself.
The book of issued invoices
One row per issued document, including stornos and credit notes.
Stevilka;Datum izdaje;Vrsta;Status;Placnik;Osnova (EUR);DDV (EUR);Znesek (EUR);Sklic;Obdobje od;Obdobje do
The payment journal
One row per money received, with its allocation across documents.
Datum;Placnik;Znesek (EUR);Nacin;Referenca;Opomba;Storno placila z dne;Vezano na racune
-
No direct integration
The product does not connect to Minimax, Vasco or any other accounting software. The file goes to the accountant the way the spreadsheet does today.
Five roles, permissions closed by default
Access is denied until explicitly granted — not the other way round. Every screen, every call and every deep link requires its own grant.
| Role | What it sees | Money |
|---|---|---|
| Club adminclub_admin · chair, secretary | Everything. | Issuing invoices, payments, reminders, financial reports, club settings. |
| The treasurertreasurer · whoever keeps the books | The lists of members and groups, so they know who to bill — not health data. | Fee plans, invoice issuing, payments, arrears and financial reports. |
| Coachcoach | The members of their own divisions and their attendance, the club schedule (for clash detection), announcements, volunteers, and reports without financial fields. | No. |
| Parentparent | Their own family, their children’s schedule, announcements, RSVPs, volunteer shifts. | Only their own invoices and payments. |
| Membermember · 15 and over | Same as a parent, for themselves. | Only their own invoices and payments. |
The treasurer is a role of its own.
A treasurer sees invoices, payments, receivables and the roster they bill — they do not see health data, and cannot change members, staff or club settings. So nobody needs full access just to keep the books. Roles are additive, so a treasurer can also be a parent or a coach.
A coach sees the members of their own divisions — and only those: personal and health data, attendance and by-name reports for the divisions they are assigned to. A refused attempt to read health data is recorded. A coach with no division assigned sees no members at all.
What we promise — and where to verify it
Values listed in a page footer are verified by no one. So our commitments are written as a register: what they concretely mean, what state they are in, and where you verify them. A row without the last column does not belong in this register.
| Commitment | What it concretely means | Status | Where to verify |
|---|---|---|---|
| No lock-in | The subscription runs by season (September–August). There is no multi-year obligation and no notice period beyond the season term. | in force | Terms of use → |
| No exit fee | Leaving costs nothing. The last billing run is the last billing run; there are no exit costs. | in force | Terms of use → |
| The club is the data controller | The club decides the purposes of processing. youthstack is the processor and processes on the club’s instructions; we sign the data-processing agreement before anything is uploaded. | in force | Security & GDPR → |
| No ads | The parent app has no ads and no advertising trackers. A child is not an advertising segment. | in force | Security & GDPR → |
| No selling of data | The club’s data is not a product. The only recipients are the subprocessors needed to run the service; they are named in the data-processing agreement. | in force | Security & GDPR → |
| A published price | The whole scale is public and computable in advance: 19 € a month with the first 50 active members included, then graduated per member. There is no “price on request” and no feature is tied to a tier. | in force | Pricing → |
| Issued invoices are immutable | A correction is a new document with its own number and a reference to the original. The number sequence stays gapless. | in force | Section 02 → |
| Export on leaving | A one-action full club export (a ZIP of CSVs), plus the invoice journal and the payment journal separately. Any time, without asking and without a fee. | in force | Section 07 → |
All eight rows are in force today. When one is not, it stays written down in the register as unfulfilled — because any serious review would find it anyway, and because a register you would quietly remove it from is just an advert.
A demo for the board — 30 minutes, on your club
Not a slideshow. We open your groups, your fee plans and your payers, and show what the book of issued invoices and the receivables view look like with your names in them. We migrate your existing member list.
The call takes 30 minutes · we do the data migration · setup takes ≈ 75 minutes of your time, spread over four days · the setup plan →