Payment Types

payment types define the categories of charges your club collects they control how invoices are named, when they are generated, how often they recur, and whether they are created automatically or manually go to settings → payment types to manage them ⚙️ what a payment type controls field description name label shown on invoices and in the payments list (e g "monthly fee", "registration fee") description optional internal note, or a template for the line item description on invoices — see placeholders below default amount default charge — can be overridden per payment recurring whether this fee repeats on a schedule recurrence interval how often it recurs — weekly, monthly, quarterly, or annual auto generate on enrollment automatically create an invoice when a student is enrolled in a class fee amount scope global (same amount for all classes) or per class (set amount in each class) generate early for recurring types — generate invoices x days before the billing period starts active inactive types are hidden when adding payments manually description placeholders the description field accepts placeholders that are filled in when invoices are generated — useful for showing class context on every invoice line placeholder replaced with {class} the class name (e g "yoga 101") {day} the class day (e g "monday") {time} the class time range (e g "8 00 am – 10 00 am") {location} the location name (e g "main studio") {frequency} how often the student attends (e g "2x/week") — pulled from the enrolment's sessions per week {period} the billing period (e g "may 2026") {tier} the frequency tier label (e g "beginner") example template {class} · {day} {time} @ {location} — {frequency} rendered yoga 101 · monday 8 00 am – 10 00 am @ main studio — 2x/week a live preview appears below the description field as you type 🔁 recurring payment types enable recurring payment to have invoices generated automatically on a schedule interval when invoices are generated weekly every sunday (or x days before, if generate early is on) monthly 1st of each month (or x days before) quarterly 1st of each quarter — jan, apr, jul, oct annual once per year — on the configured billing month and day for annual payment types, you have two modes annual mode when invoices are generated specific date a fixed month + day each year (e g 1 january, 1 june) the same date applies to every student based on range generates on the end date of each invoice's billing period — so each student can be on their own annual cycle set the period start/end when adding the payment based on range is ideal when students join on different dates within a year (e g enrolment cohorts) and each needs an annual fee that runs from their own start date for 12 months the billing period range you enter when adding the payment defines the invoice's period and the auto end date is calculated for you generate early turn on generate early and set a number of days to send invoices in advance of the billing date useful so members have time to pay before the period starts example monthly fee with "generate early 5 days" → invoice sent on the 26th or 27th of the previous month, due on the 1st auto generate vs manual each recurring payment type has a separate auto generate toggle on (default for recurring types) — remmu's cron creates invoices automatically on the schedule off (manual) — invoices are not auto generated the type still appears in bulk generate so admins can produce invoices on demand for the month they want in the payment types list, types with auto generate off show manual below the recurrence interval — a clear signal that nothing will happen until you trigger bulk generate this is useful for fees you want to control timing of manually (e g an annual fee that some students pay early and others pay later) 📋 auto generate on enrollment when enabled, an invoice is automatically created when a student is enrolled in a class — no manual step needed global vs per class amount when auto generate on enrollment is on, you choose how the amount is set option how it works global one default amount applies to all classes per class each class has its own amount — set it in the class settings (add/edit class dialog) use per class when different classes have different registration or deposit fees 🧾 enrollment invoices when a student is enrolled, if multiple payment types have auto generate on enrollment enabled, remmu bundles them into a single enrollment invoice with line items — one invoice listing all one time fees instead of separate invoices per fee type the enrollment invoice pdf shows a breakdown of each fee with its name and amount 💰 deposit (system type) a payment type can be marked as deposit — used to track refundable deposits collected from students deposit payments appear with a "deposit" badge in the payments list and are treated separately from regular fees for reporting the built in deposit payment type is seeded automatically for all clubs you can rename it or adjust the default amount 📅 invoice & receipt numbering each payment type has its own invoice number sequence — prefix, starting number, padding, and separate receipt numbering configure these per payment type under settings → payment types setting description prefix e g inv , rec , dep — letters, numbers, , / , supported use {year} or {month} for dynamic values starting number e g start from 1001 number padding zero pad to a fixed length — e g padding 4 gives 0001 , 0010 , 1000 invoice and receipt numbers have separate padding settings example prefix with variables {year}/{month} → generates 2026/03 0001 , 2026/03 0002 🏷️ system payment types some payment types are created automatically by remmu and cannot be deleted type purpose deposit refundable deposit tracking package purchase created when a member purchases a session package system types can be renamed and have their default amount adjusted, but their core behaviour (recurring, enrollment trigger) is fixed ➕ adding a payment type go to settings → payment types click add type fill in the name, amount, and options click save the new type is immediately available when adding payments manually or enrolling students