Subscriptions
Every retainer, its own record
A subscription records what a client pays per period, and for what: a recurring agreement on the client, with a status, a type, included hours and a price that never rewrites itself. The billing cycle runs on without anyone keeping a calendar, and hands you a draft invoice you still get to look at.
Attached to the client, not floating
A subscription hangs off the client, alongside contacts, projects and domains: one panel on the client page shows which recurring agreements are running, with the amount, the interval and the next invoice date. It is a revenue concept (what the client pays per period), separate from a project's hour budget; the two reference each other, they are not the same row. The record carries a name, a type, a status, an amount, an interval (monthly, quarterly or yearly, and every N intervals if you want, or one-off for something sold once, such as a website build: it is billed once, never counts towards MRR and moves to Afgerond (completed) the moment an invoice bills it), start and end dates, a notice period and notes. You record an agreement from the client page itself, in a dialog that already has the client filled in and whose project picker offers only that client's projects; you stay on the client page. A new subscription starts active and derives its next invoice date straight away, always a date still ahead even when the start date lies years back; an imported one stays a draft, so a bulk import never quietly goes live. And a hosting agreement says which website it keeps online: the website page carries an Abonnementen panel where you attach one of that client's running agreements or create a new one with the client and the site already on the form. Which kinds of agreement can attach to a website is set per type with Dekt websites (covers websites).
Types and standard subscriptions you set up yourself
Hosting, maintenance, SEO: the categories are not code. You create them yourself under Abonnementen → Abonnementstypes, with per-language labels, an order and an active flag. A standard subscription like "Hosting Basic, €25 per month, 1 hour included" prefills the create form, so a new agreement stands up in seconds; rename one and the subscriptions still carrying that name come along, with a count of how many did. The other way round, you save an existing subscription as a standard one from the row's ⋯ menu, and it is linked to it there and then. And the first time you set a subscription to active, its type creates the matching onboarding tasks on the client: once, so pausing and resuming never spawns a second onboarding.
- The catalogue sits as a tab above the section itself, not tucked away in Instellingen
- Standard subscriptions prefill the form; they are not a copy that drifts out of step afterwards
- Notes carry variables like {{company_name}} and {{included_hours}}, and can print under every invoice if you want, with the variables filled in at the moment the invoice is made
A price that never rewrites itself
The price lives in append-only history with an effective date. A rate change appends a row and overwrites nothing, so the amount on last year's invoice stays answerable: raise the fee on 1 January and December keeps its old number. A round of increases goes through the Prijsverhoging button: add a percentage, add a fixed amount or set a new amount, with an effective date and a scope of everything, one type, one subscription or one standard subscription. You see the preview with the current and new amount per subscription first, and only then is anything written; the standard subscriptions come along if you tick them. Bulk edit deliberately leaves the price out — it belongs on this path, not on a field that skips the history.
Included hours, measured against real work
A subscription can include hours. Consumption is measured against the time logged on the linked projects: exactly the same total every budget bar and burn colour reads, not a separate counter drifting out of step. Unused hours lapse or carry over by a rollover rule you set yourself, optionally with a number of periods after which they expire anyway. On the project side it works the other way round: link a running retainer with included hours and the project takes its hour budget from the agreement (several agreements sum), the field locks with its source named, and the period becomes monthly. Work a retainer already pays for also starts non-billable, so a time entry against it is never accidentally charged a second time.
From cycle to draft invoice
A daily cron finds which subscriptions are due, advances the next invoice date by one period and hands over the invoice lines at the amount that applied on the invoice date, not at today's price. When the invoice date has already passed, one run catches up every open period rather than doing one a night. The invoicing module turns that into an invoice, with the subscription lines in their own band on the document. Whether an invoice covers the period after or before its invoice date is a property of what you sell: hosting and licences usually go in advance, a retainer once the month has been delivered. You set it on the type, a standard subscription may deviate, and so may one agreement made differently with this client. Flip it and the periods already billed move along, so nothing is offered again. What was already invoiced elsewhere you record with Gefactureerd tot (invoiced until), so moving over never produces a duplicate invoice. How far that runs by itself is a level rather than a switch: off, draft it, draft and issue it, or draft, issue and mail it. You set that agency-wide and override it per subscription, so the fixed hosting retainer runs on its own while the client you renegotiate every month stays manual. What is still coming reads back in Overzicht → Omzet, with MRR, ARR, the number of active subscriptions and the invoices falling due within a month.
- The cycle advances even when the invoice stays a draft, and a backlog is caught up in one run
- The price on the invoice is the price of that invoice date
- In advance or in arrears: per type, per standard subscription or per agreement
- Automatic invoicing per subscription, or "follow the organisation"
The list is a worksheet
Every subscription sits in the same table as the rest of the platform, in sections per standard subscription with the client leading, and a passed invoice date is drawn in red, with a Factuurdatum verstreken (invoice date passed) tile leading to the backlog: sort on every column the list shows (including the amount at today's price and the next invoice date), filter by client, type and status, show or hide columns, and page through properly instead of seeing the first two hundred rows. Ask for checkboxes and they appear; then you switch status, type, client, invoiced-until, in advance or in arrears and the notes on the invoice across a whole selection in one move, or delete the selection. Subscriptions, subscription types and standard subscriptions all three travel as CSV, TSV or Excel, and an import runs the same validation the form does — it is not a back door around the service. Each subscription also carries your own extra fields, optionally only for one type or standard subscription and printed on the invoice line, and a full activity trail of what changed, when and by whom. Subscriptions is an extension module: the core of schakl. is open source (AGPL) and modules like this one run on a licence key entered under Instellingen → Licentie; when it lapses the module goes read-only and your agreements, price history and exports stay readable.
- Filter by client, status and type
- Bulk: status, type, client, invoiced-until, in advance/in arrears and notes on the invoice, or delete the selection
- Four statuses: Draft, Active, Paused, Cancelled
Want to know more?
The documentation describes every module in detail, from installation to permissions.