Transaction types
What it is
Section titled “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
Section titled “Who can use it”- Member: reads their own transactions on the member-balance screen.
- Admin (treasurer counts as admin): read any member’s transactions; create manual adjustments, reversals, and recorded payments.
Where to find it
Section titled “Where to find it”- Your balance:
/syndicates/:syndicateId/my-balance - All balances (cross-syndicate): Balances tab on the home shell.
- Asset Utilisation (admin): usage hours per member.
Fields / options
Section titled “Fields / options”Transaction types
Section titled “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 shares. |
| 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 records a payment received outside the app (cash, BACS in, cheque). Members can also pay in-app, by card or by Direct Debit; an in-app payment does not write a paired credit but instead attaches a settlement record to the original debit. 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. |
| Cash call charge | debit | Written when an admin issues a cash call. One charge per equity member, weighted by shares of the total, snapshotted at the moment of issue. |
Link fields
Section titled “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.
- Cash call: set on every cash-call charge, linking it back to the parent call for grouping on the member balance screen.
- Usage date: for monthly statements, this is the date the flight happened, not the date the charge posted.
Behaviour rules
Section titled “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
Section titled “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, Direct Debit collection submitted to the bank). The transaction is claimed by a pending settlement; another payment attempt cannot pick the same charge up until that claim is resolved. |
| 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, waiver, loan offset, or 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, because the audit trail is mandatory when a charge is forgiven.
In-flight lifecycle
Section titled “In-flight lifecycle”The in-flight state has a single deterministic lifecycle. When a payment attempt starts (card checkout, instant bank transfer, Direct Debit collection), the chosen transactions are atomically claimed by a new pending settlement in the same step that creates the settlement record. From there:
- Captured: the provider confirms the money has moved. The settlement is upgraded with the provider’s reference and the underlying transactions flip from in-flight to settled.
- Cancelled: the attempt didn’t go through (the user closed the checkout, the provider rejected the request, the collection was abandoned). The claim is released and the transactions go back to free so the next payment attempt can pick them up.
If neither outcome arrives within twenty-four hours (typically because a webhook was lost), an automatic safety net auto-cancels the stale claim, releases the transactions, and alerts the Syndik8 operations team so they can reconcile against the provider’s dashboard in case real money moved without the system being notified.
A reversal against a captured 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. See reversals for the dispute and recovery flow.
Members discharge their own debits in-app from the balance screen, by card or by Direct Debit; an admin can also record an external payment against a debit as the manual Payment transaction row above.
See also
Section titled “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