Transaction types

What it is

Every financial event in a syndicate is recorded as a transaction on an append-only ledger. Transactions are never edited or deleted in place; corrections are made by posting a reversal. Your balance is the signed sum of your transactions.

A debit transaction increases what you owe the syndicate. A credit transaction decreases it (or moves the syndicate into owing you money). Sign convention: debits are stored as positive amounts, credits as negative amounts.

Who can use it

• Member — reads their own transactions on the member-balance screen.
• Owner, admin, treasurer — read any member’s transactions; create manual adjustments, reversals, and recorded payments.

Where to find it

• Your balance: /syndicates/:syndicateId/my-balance
• All balances (cross-syndicate): My Balances tab on the home shell.
• Fairness dashboard (admin): usage and charges per member.

Fields / options

Transaction types

Type	Direction	When it is written
Usage charge	debit	Finalisation writes one per usage log: logged usage × resolved rate.
Event charge	debit	Finalisation writes one per counted event (landing, touch-and-go, lock passage) from the log’s event counts and the asset’s event fee rates.
Minimum shortfall	debit	Finalisation writes one if a booking came in below the configured minimum usage for the weekdays/weekends it spanned.
Periodic dues	debit	Written when a member’s billing scheme dues interval comes round (monthly, annual, etc.).
Maintenance expense	debit	Written when a maintenance booking is finalised. The total is split across equity members proportional to their equity share.
Expense credit	credit	Written when an admin approves a submitted expense. The member who paid is credited the approved amount.
Payment	credit	Written when an admin manually records a payment received outside the app (cash, BACS in, cheque). When the in-app payment provider is live, payment is modelled differently — the original debit gets a settlement record rather than a paired credit. See How transactions are settled below.
Reversal	credit or debit	Written when an admin corrects a previous transaction. The sign mirrors and cancels the original. Reversals against in-app payment-provider settlements (chargebacks, indemnity claims) are tracked separately on first-class reversal records that re-open or forgive the underlying transactions, rather than as ledger entries here.
Manual adjustment	either	Written by an admin to correct a balance outside the normal finalisation flow. Sign carried in the amount.

Link fields

Each transaction may carry references to what it relates to:

• Booking — set on usage, event, shortfall, maintenance, and booking-linked reversals.
• Usage log — set on usage and event charges written during finalisation.
• Expense — set on expense credits and expense-linked reversals.
• Usage date — for monthly statements, this is the date the flight happened, not the date the charge posted.

Behaviour rules

• The ledger is append-only. Admins never edit a transaction in place; they post a reversal and, if needed, a new transaction in its place.
• Sign convention: debits are positive, credits are negative. The sum of a member’s transactions is their balance. A positive balance means the member owes the syndicate. A negative balance means the syndicate owes the member.
• Usage charge and event charge always come in per-log pairs — the charge is attached to a specific usage log, not smeared across the booking. This keeps a clean link from ledger → log → photo of the Hobbs.
• Shortfall is booking-level, not log-level. A booking can have many usage logs but at most one shortfall transaction.
• Maintenance expense is the only transaction type that automatically charges people who did not personally log the activity. It splits the cost across equity members.
• Periodic dues are driven by the scheme interval, not the calendar month. A member on a quarterly scheme is charged every three months regardless of the calendar.
• All amounts are stored in the syndicate’s currency. Reporting VAT is out of scope for the transaction ledger itself.

How transactions are settled

Each debit transaction is in one of three states:

State	What it means
Free	Unpaid. Counts toward the member’s outstanding balance.
In-flight	Reserved for an in-flight provider call (e.g. card checkout in progress). Cannot be claimed by another payment attempt until the call completes or times out.
Settled	Linked to a settlement record that captures how the charge was discharged: card payment, instant bank transfer, Direct Debit collection, external/manual payment, admin waiver, or member-fund offset.

Settlement records carry the mechanism (card, instant_bank_transfer, direct_debit, external, waived, loan_offset, credit_offset), the provider session/charge ID where applicable, and — for non-money mechanisms — the admin who recorded it and a free-text reason. A waiver settlement requires a reason of at least ten characters; the audit trail is mandatory when a charge is forgiven.

A reversal against a settlement (chargeback, indemnity claim, admin refund) re-opens the underlying transactions for re-collection unless the reversal is recorded as forgive, in which case the syndicate carries the loss.

Status: backend live, UI dark-launched. The settlement / resolution model and the supporting tables ship in v1.0.16. The in-app provider flows (card checkout, DD setup) are reachable today only via the payment-onboarding entry point on the Payments & Schemes screen and via notifications — they are not yet linked from menus. Until the payment provider is live in production, day-to-day resolution still happens through the manual Payment transaction row above.

See also

• Member balance — how transactions sum into a current balance
• Finalisation rules — the finalisation flow that writes usage, event, and shortfall transactions
• Statement format — how the balance screen groups these into monthly statements
• Member rates (billing schemes) — where periodic dues come from