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 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

Member: reads their own transactions on the member-balance screen.
Admin (a treasurer needs the admin role): read any member’s transactions; create manual adjustments, loans, reversals, and recorded payments, including on their own balance. When an admin changes their own balance, every other admin of the syndicate is notified: by Admin Changed Own Balance, or by Payment corrected when the change is a correction to their own payment. See Notification types.

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 credit or a loan. For your own balance, Add ledger entry is in the Balance section of your own member page. A finalised booking’s detail screen has its own Add charge or credit, which offers Charge or Credit and no loan.

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	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, on the online payment page, 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 a member’s share of a cash call is posted: on the call’s due date, when the member pays it early, or at once for a call issued due now. Each share is weighted by shares of the total, snapshotted at the moment the call was issued.
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.
Refund not received	credit	Written by Syndik8 when a card refund that was already recorded on the ledger fails at the payment provider, so the money came back to the syndicate instead of reaching the member. It puts the refunded amount back on the member’s account as owed to them, dated the day the provider reported the failure, with the reason in its description. It is held until the member and the syndicate’s admins agree how the member gets it. See Work Refunds & chargebacks.

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, and on the single adjustment Apply the new charge posts on a finalised booking.
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.
Refund: set only on a Refund not received line, linking it to the card refund that failed. It is how the queue and the line find each other.
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

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. Nothing is held back: a charge counts from the moment it is posted. A positive balance means the member owes the syndicate. A negative balance means the syndicate owes the member.
A cash call is not on the ledger before its due date. Issuing a call records each member’s share and writes no transaction; the share becomes a Cash call charge when it is posted, on the due date or when the member pays it early. Until then it is shown separately as Not due yet. No transaction on the ledger is ever due later than the moment it was written.
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, or paid back outside the app. Recording one credits the member’s balance. Like any credit, it is used on their charges when the member chooses it at Pay, when an admin uses it for them, or automatically by Direct Debit. If the syndicate hands the money back instead, an admin records it with Mark as paid out; see Use or pay out a member’s credit.
Credit is used only when somebody chooses to. Nothing sets a credit against a member’s charges by itself, apart from a Direct Debit collection. A credit line can be partly used: what is left on it is what counts towards the member’s balance and every total.
Refund not received is held until a choice is made. It counts in the member’s balance, but nothing spends it: Pay All leaves it out, a Direct Debit does not net it, and a recorded payment cannot include it. An admin then either records the member’s agreement to take it as credit on account, after which it is an ordinary credit, or records a payment made to the member outside the app, which settles it. The line is never edited or voided, and it carries no VAT.
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

Each debit transaction is in one of three states:

State	What it means
Free	Unpaid. Counts toward the member’s balance.
In-flight	Reserved for an in-flight provider call (e.g. a card payment in progress, a bank payment chosen on the online payment page still clearing, a 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. Eight mechanisms exist. Five move real money through the payment provider — Card, Online payment (a payment made on the provider’s online payment page, where the member may choose a card or, where offered, a bank payment such as Bacs), 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 paid from the member’s credit, shown as Paid with credit; the credit may come from more than one credit line, and the last one used may be only partly used). External payments and waivers name the admin who recorded them; an offset records whether the member, an admin or a Direct Debit collection used the credit. 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

The in-flight state has a single deterministic lifecycle. When a payment attempt starts (card payment, online payment page, 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 bank payment chosen on the online payment page is treated the same way once the member has finished on the page: it is in flight while the bank clears it, over a few working days, and is not cancelled on a timer. If the bank returns it, the charges become outstanding again, and the member and the syndicate’s admins are sent a notification saying so. A payment refused while the member is still on the page is not a return: the member sees the refusal there, and the charges are released for another attempt without a notification.

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, on the online payment page, or by Direct Debit; an admin can also record an external payment against a debit as the manual Payment transaction row above.

Transaction types

What it is

Who can use it

Where to find it

Fields / options

Transaction types

Link fields

Behaviour rules

How transactions are settled

In-flight lifecycle

See also