Member rates and billing schemes

The shape of the problem

Most syndicates don’t have one kind of member. A typical group-owned aircraft starts with a handful of partners who bought in and pay a flat monthly subscription to cover fixed costs (insurance, hangarage, annual inspection), plus a lower hourly rate when they actually fly. Over time the same syndicate wants to bring in a second kind of participant — someone who doesn’t want equity but is happy to pay a higher hourly rate with only a token annual fee. The syndicate doesn’t want to run two accounting systems, doesn’t want two calendars, and doesn’t want two sets of rules. They want one aircraft, one schedule, and two ways to be billed for flying it.

Syndik8 models this with billing schemes. A billing scheme is a named package of financial terms — dues amount, dues interval, and a modifier on the asset’s base hourly rate. Every member of the syndicate is assigned to exactly one scheme. The scheme decides what they pay in periodic dues and how their hourly rate is derived from the asset’s base rate. “Renter” is the conventional name for one such scheme. It is a rate label, not a role.

The canonical worked example

Consider a single-aircraft syndicate running a Cessna 172 at a base wet rate of £180+VAT/hr. The syndicate defines two member rates:

Member rate	Dues	Modifier	Effective hourly
Equity member	`£100+VAT/month`	`none`	`£180+VAT/hr`
Renter	`£100+VAT/year`	`override = £220`	`£220+VAT/hr`

Two members join, one on each rate. Both have the member role. Both see the same calendar. Both book the same aircraft. The difference is entirely financial:

The equity member contributes to fixed costs every month through the £100+VAT dues charge and pays the base rate when they fly. They are carrying a share of the hangarage, the insurance, and the annual regardless of whether they fly that month.
The member on the renter rate pays almost nothing when not flying — only an annual £100+VAT token — and pays a higher £220+VAT/hr when they do. Their higher hourly is how the syndicate recovers the fixed costs the equity members are pre-paying through dues.

The syndicate treasurer doesn’t run two accounts. One ledger, two pricing packages. The calendar has no idea who is on which rate. The asset’s base configuration doesn’t change. What changes is the override on the renter rate’s modifier, which is resolved once per usage log at the point it’s saved.

Why not make renter its own syndicate?

You could, in principle, run a second syndicate with the same aircraft and put non-equity participants there. It would fail in practice: two calendars fragment the scheduling picture, the maintenance log is split across two places, and every member would need to see both syndicates to know whether the aircraft is free. Worse, the tax and insurance logic for the aircraft lives on the asset, and two syndicates cannot share one asset. Billing schemes exist because the scheduling, maintenance, and asset data must stay single-syndicate while the pricing needs to be plural.

The why behind dues

Dues are periodic — typically monthly for equity members, annually for the renter rate. The interval and amount are whatever the scheme defines. The distinction isn’t decorative:

Equity members’ dues are a share of fixed costs. The scheme’s monthly dues exist to recover insurance, hangarage, and reserves regardless of flight hours. When no one flies for a month, the equity member still owes. That is the deal equity members signed up for.
Renter-rate dues are closer to a membership fee. The token annual payment exists so the syndicate has a formal accounting relationship with the member — a renewal moment, a re-acceptance of terms, a paper trail — without asking the member to carry fixed costs.

The scheme abstraction does not know or care about the accounting interpretation. Both are just periodic charges to the member’s balance. The interpretation is the syndicate’s.

Modifiers beyond `override`

The override modifier is the cleanest way to express “this rate is a flat number, decoupled from the base”. Three other modifier types give you a rate that tracks the base:

Modifier type	Effective rate	Use when
`none`	base rate	This is the standard equity member scheme.
`fixed`	base rate + value	The premium (or discount) is a flat amount, and should follow the base if the base changes.
`percent`	base rate × (1 + value/100)	The premium (or discount) is proportional — e.g. a 25% instructor discount.
`override`	value	The rate is a fixed number that doesn’t track the base.

A useful secondary example: an instructor scheme with percent = -25 on the same £180+VAT/hr base gives £135+VAT/hr, following the base down if it ever drops. A historical “founder” scheme with fixed = -20 gives £160+VAT/hr — a small fixed discount that tracks the base. Negative modifiers never produce a negative rate; the result is floored at zero.

Per-asset overrides — the second layer

Multi-asset syndicates complicate the picture. Suppose the same syndicate adds a newer SR22 at a base rate of £260+VAT/hr. The scheme’s override = £220 would give the member on the renter rate a charge of £220+VAT/hr on the SR22 — almost certainly not what you want. Two corrections are available:

Switch the renter scheme to fixed = +40. Renter members now pay £220+VAT/hr on the 172 and £300+VAT/hr on the SR22. The £40+VAT premium follows whichever asset they fly.
Keep the renter scheme at override = £220, and add an asset-level override on the SR22 pinning the renter rate to £300+VAT/hr for that aircraft only. The 172 still resolves via the scheme’s override; the SR22 resolves via the per-asset override.

Both work. Which you choose depends on whether “renter premium on the SR22” is a number that should track the base (use the fixed modifier) or is a deliberately-pinned rate that you want to review and edit independently (use the per-asset override). See rate resolution chain for the precise precedence.

Surgical and broad rate changes

The cascade — per-asset override, then scheme modifier, then base rate — is how rate changes stay surgical when they need to be surgical and broad when they need to be broad:

Broad. Edit the asset base rate: every scheme that doesn’t override it shifts. Edit a scheme modifier: every member on that scheme shifts, on every asset without an asset-level override.
Surgical. Edit one asset’s per-asset override for one scheme: only members on that scheme flying that asset are affected.

The snapshot rule makes all of this safe. When a member saves a usage log, the resolved rates at that moment are written onto the log. Finalisation uses the snapshot, not the live values. So you can adjust a scheme’s modifier on Monday without affecting Sunday’s logged flight — past logs keep their snapshotted rates, future logs pick up the new ones. See finalisation rules.