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 the unpaid ones, with a single exception: a cash-call charge whose due date has not arrived sits outside it.
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, loans, reversals, and recorded payments.
Where to find it
Section titled “Where to find it”- Your balance:
/syndicates/:syndicateId/balance - All balances (cross-syndicate): Balances tab on the home shell.
- Asset Utilisation (admin): usage hours per member.
- Hand-written entries (admin): Add ledger entry in the top bar of a member’s charges screen,
/syndicates/:syndicateId/members/:membershipId/charges, records a charge, a refund or a loan. The same dialog opens from a finalised booking’s detail screen, where it offers the charge and refund only.
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 | Retired. Previously written when a maintenance booking was finalised, split across equity members proportional to their shares. Finalising a maintenance booking no longer posts a charge — flying to the engineer is met through the monthlies — but rows written before that change still appear on older statements. |
| 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, and refunds the syndicate sends — are tracked separately on first-class reversal records rather than as ledger entries here. Those records re-open the underlying transactions, forgive them, or leave them settled at a corrected figure. |
| 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. |
| Loan | credit | Written when an admin records money a member lent the syndicate — a float for cash flow, or cash fronted before a bill lands. See Record a loan from a member. |
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.
- Flight date: the day the flight actually happened. Only a usage charge and an event charge carry one; every other type leaves it blank, because there is no single flight behind it. It is what the balance screen dates the row by, and it appears in an exported statement in its own Flight date column. It is not what files a charge into a month — that is always the date the charge posted. See statement format.
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. A member’s balance is the sum of their unpaid transactions, apart from the cash calls held back by the rule below. Nothing else is held back: a charge counts from the moment it is posted, whatever date it carries. A positive balance means the member owes the syndicate. A negative balance means the syndicate owes the member.
- A cash call is not owed before its due date. Its charges are on the ledger from the moment the call is issued, but they stay outside the balance, outside Pay All and outside a Direct Debit collection until the due date arrives. Until then they are shown separately as Not due yet, and can be settled early one at a time. No other transaction type is held back this way.
- 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 retired: no new one is ever written. Finalising a maintenance booking posts no charge at all — flying to the engineer is met through the monthlies, not billed per flight — so the type survives only so that a statement from before this change still renders correctly.
- 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.
- A loan is repaid in flying, not in cash. Recording one credits the member’s balance, and their charges consume that credit until it is used up. Syndik8 has no way to record the syndicate paying a member back outside the payment provider, so nothing here schedules or tracks a cash repayment. Keep that record wherever the syndicate reconciles its bank account.
- A loan is not an expense. A member who pays a syndicate bill from their own pocket claims an expense, which posts an expense credit on approval with a receipt and an approval trail behind it. A loan is money lent rather than a cost incurred, and carries neither. Both end as a credit on the same balance; only one of them has evidence attached.
- 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 balance, unless it is a cash-call charge whose due date has not arrived. |
| 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: a payment through the provider, an external/manual payment, an admin waiver, or an offset. |
Settlement records carry the mechanism, the provider session/charge ID where applicable, and (for non-money mechanisms) the admin who recorded it and a free-text reason. Seven mechanisms exist. Four move real money through the payment provider — Card, Bank transfer (instant bank transfer), Direct Debit and Apple Pay / Google Pay — and the other three resolve a charge without any money moving through Syndik8: External payment (cash or a bank transfer the member made themselves, recorded by an admin), Waived, and Offset (a charge cancelled against a credit of the same amount, typically an expense claim). Every one of the three names the admin who recorded it. A waiver additionally 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.
Direct Debit claims are deliberately exempt from that sweep once the collection has been sent, and can stay claimed for much longer than a day without anything being wrong. A collection the bank has already accepted takes several working days to clear, so cancelling the claim at twenty-four hours would release charges the bank is in the middle of collecting. The same applies before the bank has acknowledged it: once a collection has gone to the payment provider, Syndik8 cannot tell from the outside whether money is already moving, so releasing the claim on a timer risks collecting twice. Such a claim is resolved by asking the provider what became of the collection, not by waiting — and only once the provider says it holds nothing are the charges freed.
A reversal against a captured settlement — a chargeback, an indemnity claim, or a refund the syndicate sent — re-opens the underlying transactions for re-collection only when it is recorded as rebill. Recorded as forgive it leaves them settled and the syndicate carries the loss; recorded as a correction it leaves them settled at the corrected figure, with only the difference going back. See reversals for the full rule, and Refund or correct a payment for putting a payment right.
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: which transactions count toward the current balance, and when
- 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
- Record a loan from a member: putting a member’s loan on the ledger