One chain from the joining form to the books

Start with the simplest question a member can ask: what do I pay? In the system as it first grew, that answer could come from eight different places — organisation settings, environment configuration, a global pricing catalogue row, a member segment, a trial group, an amount stamped on the subscription when they signed up, an amount stamped on the signup form, and a hardcoded age cutoff that silently decided who counted as a youth member. Each was a plausible answer, so every screen that displayed a price picked a different one.

The same fragmentation runs through the rest. A booking calendar does not know whether the person booking is a paid-up member. Activity income arrives as a line on a bank statement with no link to the activity. The treasurer reconciles by hand, from memory and receipts, and the books are assembled once a year from evidence that was never designed to be assembled.

And the dashboard disagrees with itself. A badge counting one set of pending members while the queue it links to listed a disjoint set meant an admin could be told one person was waiting and land on an empty page — a small thing that teaches people not to trust the system.

The first rule: a member's price lives on their membership plan and nowhere else. The plan is the membership type — Standard, Premium, Ungdom, Æresmedlem, a trial that graduates onto another plan — and the price is not attached somewhere alongside it, it is the plan. All eight competing sources were removed, and a source-level test now fails the build if any of them reappears, which is how this would actually come back: through a merge, quietly, months later.

The second rule: value is granted by an administrator, never taken by a member. A card presented at signup is authorised, not charged. The organisation decides who joins it, so the signup waits in a queue where a board member reviews the applicant and, if they are on the wrong plan, changes it before any money moves. The amount is then resolved from the plan they are on at approval — never from the figure quoted at signup, which is exactly the number that may have just been changed.

That ordering is the whole design. Charge first and adjust afterwards, and you owe a refund and an apology. Charge on approval, and nobody is billed the wrong amount in the first place. It also produces the harder case honestly: someone who picked no plan has no card on file, so when the board places them on a paid plan the system bills them and leaves them inactive until they pay. Activating them anyway would be giving away a paid membership; that is a decision an organisation should make deliberately, not a default the software picks.

Three of them carried most of the weight. The first was collapsing eight price sources to one, which is unglamorous and was the single largest improvement: it turned an unanswerable question into a lookup, and it made every downstream number — a member's bill, an outstanding balance, an income line — derive from the same fact rather than race to define it.

The second was deciding that authorisation and charging are different events, separated by a human decision. That single ordering removes an entire category of remediation work: refunds, apologies, corrected invoices, and the awkward conversation where a volunteer treasurer explains to a member why they were charged the wrong kontingent. It costs one extra step in the flow and a stamp in the database to tell the two orderings apart.

The third was stamping provenance onto payments so that history cannot be rewritten by a present-tense change. A payment that knows only its subscription inherits whatever plan that subscription names today, which means the organisation's record of its own past income is a function of its current configuration. Recording the plan at the moment the money moves makes a plan change mean what people expect it to mean: it decides what a member pays next.

There is a fourth, and it is a refusal. A kontingent buys a membership, not access. What someone paid is deliberately not wired to what they may do in the system, because a lapsed renewal would then silently withdraw permissions — which is a way to lock a board out of its own tools on a failed card. Roles are granted by an administrator, independently of payment. The two are related in the organisation's rules and unrelated in the software, on purpose.

The bookkeeping is a working double-entry ledger — accounts, journal entries and lines, vouchers, VAT codes, fiscal years, bank transactions, an audit log, and services supporting the five-year retention obligation. It is not a registered bookkeeping system. Registration with Erhvervsstyrelsen, along with NemHandel and Peppol e-invoicing and the current SAF-T version, is designed and not shipped, and the plan for it still carries open decisions requiring review by an accountant and a lawyer. An organisation adopting the module today keeps that obligation where it already sits.

Retrieval over an organisation's own content is not built. The platform has a working retrieval feature over referee rulebooks, and an AI writing assistant that rewrites selected text, but the general tenant-content knowledge base described in the internal scope document has no implementing code, and the member-facing AI that would depend on it therefore does not either.

Some module boundaries are still partial in named ways rather than vaguely: recurring booking series are designed while one-off bookings ship; the AI editor assist covers selected text but not block or page generation; notification emails remain English-only despite the scaffolding for per-recipient language. Each of these is tracked as a named gap rather than an implied capability.

One limit is about people rather than code. A trial period is recorded against a person, so cancelling and rejoining cannot produce a second one — but somebody signing up again under a different email address gets a fresh record and therefore a fresh trial. Closing that needs identity matching across name, birthdate or phone, which is a product decision and a GDPR conversation rather than a bug fix. Today the defence is that an administrator sees every signup before approving it, which is a real control and a weaker one than a constraint in the database.

What does this member pay, and since when? Who is waiting on the board, and does the badge that says so agree with the page it links to? What did we earn last year, under which plans, and which voucher supports each entry? Before the consolidation these were reconstructions. They are now lookups, because each is derived from a single recorded fact rather than assembled from several competing ones.

The operating consequence is that the work stops depending on one volunteer's memory. A treasurer who leaves takes no unique knowledge of how the kontingent is computed, because the plan computes it. A board reviewing a joiner sees the trial history and the plan options on the screen where the decision is made. And the points where a person must still decide are explicit and few, rather than scattered through the process as unwritten habit.