Statement format

What it is

On the member-balance screen, your transactions are grouped by calendar month with a per-month subtotal. Each group lists the transactions for that month, newest first, and shows the net change to your balance for that month. The ledger is split into an Outstanding half and a Settled half, and both are grouped this way — see Member balance for what each half counts.

One kind of charge is in neither half. A cash call whose due date has not arrived is held out of the grouped ledger entirely and shown above it, in its own ungrouped Cash calls not due yet card. It has no month heading and does not count towards any monthly net. On its due date it drops into the Outstanding half and is grouped from then on like anything else.

The statement view is the canonical presentation of your ledger. It is what you scroll when you want to answer “what did I pay this syndicate last month?” or “why is my balance what it is?”.

Who can use it

Member reads their own statement.
Admin (treasurer counts as admin) reads their own statement on the same screen.

Where to find it

Member balance: /syndicates/:syndicateId/balance. The transaction list below the headline balance is the statement view.

Fields / options

On screen, each row carries:

Element	What it shows
Icon	The kind of charge the row is mostly made of.
Title	The route for a logged flight (for example, EGKA → EGHR), otherwise the kind of charge.
Description	One-line summary of the largest charge in the row. Usage charges show “X hrs at £Y/hr”; shortfalls show the shortfall hours and rate; event charges show count and name, e.g. “2 × Landing fee”.
Date	When the thing happened: the flight date for a logged session, otherwise the date the charge was posted. A posted date is a moment in time and is shown in your timezone; a flight date is a plain calendar day and reads the same wherever you are.
Amount	Debit or credit, in the syndicate’s currency, on the right. Debits positive; credits negative and shown in the credit colour.

An exported PDF or CSV uses a flat row instead:

Column	What it shows
Date	When the line moved your balance: for a charge, the date it was posted; for a settlement, the date it took effect; for a reversal, the day the money was taken back. Held in UTC, shown in your timezone — the same timezone the period and the month groups are worked out in.
Type	Human-readable label for the transaction type; for a settlement, what actually happened to your money — see the table below; Reversed for a line putting charges back on your account; and Refunded for money sent back to your bank when a charge you had already paid was corrected downwards.
Description	For a charge, a one-line summary: usage charges show “X hrs at £Y/hr”; shortfalls show the shortfall hours and rate; event charges show count and name, e.g. “2 × Landing fee”. For a settlement, how it was made — Card, Direct Debit, Bank transfer, Waived, Offset and so on. For a reversal, the cause — Card chargeback, Direct Debit indemnity claim, and so on. For a refunded correction, Correction refunded to bank.
Amount	In the syndicate’s currency. Charges positive, credits and settlements negative, reversals positive — a reversal puts a charge back, so it raises what you owe. A Refunded row is positive for the same reason: the money is back with you, so it cancels the credit the correction posted beside it.
Flight date	The day the flight actually happened, for a charge that came from a logged session. Blank for everything else — payments, reversals, cash calls, expense credits and manual adjustments are not for a particular day. In a PDF it is a small second line under the description; in a CSV it is a fifth column of its own, after Amount, so a spreadsheet can sort and filter on it.

An export shows the lines that cleared your charges as well as the charges themselves; the on-screen ledger does not, because it shows what clearing a charge leaves behind (the charge moving from Outstanding to Settled) rather than the line that cleared it. Each is one row, negative, sitting in the month it took effect — export only.

Not every one of those lines is a payment, and the Type column says which is which. Two of them, Waived and Offset, take no money off you at all: the charge stops being owed either way, so the arithmetic is the same, but a statement should not tell you that you paid something you did not.

Type	What happened
Payment	You paid. Covers card, Direct Debit, bank transfer and Apple Pay / Google Pay, and also a payment you made outside the app (cash, your own bank transfer) that an admin recorded.
Waived	An admin wrote the charge off. You paid nothing.
Offset	The charge was cancelled against a credit you were already owed — typically an expense you had claimed for the same amount.
Settled	The app does not recognise how this one was made — it can happen briefly after a Syndik8 update, because the server updates before the apps do. All it claims is that the charge is no longer owed. Update the app and export again if you need the detail.

Each month group carries:

Element	What it shows
Month header	The month and year (e.g. “March 2026”), on the left.
Monthly net	Sum of the signed amounts in that month — charges less payments. On screen it carries no label of its own and is signed: a month that netted to a credit shows a negative figure in the credit colour, and a month that netted to a charge is shown in plain text. In an exported PDF or CSV the same figure appears on its own row, labelled Subtotal.

Behaviour rules

An export is worked out entirely in your own timezone — the one on your profile, which you can change in Settings. The period it covers runs from the first moment of your chosen start date to the last moment of your chosen end date in that timezone; the date printed against each line is that line’s date in that timezone; and the month it is grouped under is that line’s month in that timezone. A charge posted at 20:00 on 28 February in New York is dated the 28th, grouped under February, and inside a statement that runs to 28 February — even though the same moment is already 1 March in UTC. This holds on the two days a year the clocks change too: those days are 23 and 25 hours long, and a period ending on one of them ends at that day’s own midnight rather than 24 hours after it began.
The member-balance screen is worked out in the same timezone. Both the posted date on each row and the month heading it sits under use the timezone on your profile, so a charge posted at 20:00 on 28 February in New York is dated the 28th and filed under February on the screen exactly as it is in an export. The two cannot disagree about which month a late-night charge belongs to. A row that leads with its flight date instead is the one exception, and the rule below says why.
A timezone the app does not recognise falls back to UTC. Your profile timezone is an area name (Europe/London, America/New_York). If it ever holds a name the app does not know, the screen and an export both work every date out in UTC rather than failing — they still agree with each other, but the days are not yours. Set your timezone in Settings to get them back.
Transactions are displayed in the order the repository returned them (newest first by default). Within a month, order is preserved. An exported statement is the other way up — oldest first, so it reads top-to-bottom from the opening balance to the closing one.
The monthly net is a simple sum of signed amounts. It is not a running balance; for that, use the Balance headline on the screen.
Flight date vs posted date. A charge that came from a logged session carries both the date it was posted to your ledger and a flight date — the day the flight actually happened. Everything that files a line into a month uses the posted date, on screen and in an export alike, so a flight logged weeks late is billed in the month it was billed. The two surfaces differ in which one they lead with: the balance screen dates the row by the flight, because that is what you check a charge against, while an export dates it by the posting, so every line agrees with the month heading above it and with the period the statement covers. An export then carries the flight date as well, in its own Flight date column, so the two documents can be reconciled line by line without knowing any of this. For a flight logged in the same month it was flown — nearly all of them — the two dates are the same. On the balance screen this is the one case where a row’s date and its month heading name different months, and that is deliberate rather than a fault.
Only a charge that came from a logged session has a flight date. That means the flying time and each event fee, and nothing else. A payment, a cash call and an expense credit have no flight behind them, and neither does a periodic dues charge, a minimum shortfall, or an adjustment an admin has made — a shortfall in particular is worked out across every day a booking spanned, so there is no single day it could name. All of those are dated by their posting on the balance screen, and their Flight date cell in an export is left blank. Blank is deliberate: any date printed there would be a day nobody flew.
A flight date is a plain calendar day and does not move with your timezone. Every other date either surface shows is a moment in time, and which day it falls on depends on the timezone it is read in — which is why they are all read in yours. A flight date is not a moment; it is the day recorded against the flight. It reads as that day wherever you are, on the balance screen and in an export alike, so the row and the document cannot name two different days for one flight.
A reversal appears as its own row, in the month it was posted, not in the month of the transaction it reverses — when it posts a ledger line at all. A goodwill refund posts none: the charges stay settled, nothing further is owed, and the money that moved is on your payment history instead.
One flight is one row on screen, several rows in the export. Billing charges the flying time and each event fee separately. The balance screen shows them as a single row you can expand; a PDF or CSV lists each underlying charge on its own line, so the two agree on the totals but not on the row count.
One payment is one row, however many charges it paid off. A single card payment or Direct Debit usually clears several charges at once and leaves your bank as one debit, so an export shows it as one row matching that debit rather than splitting it back across what it paid for.
It sits in the month it took effect. If a payment in March cleared charges from January and February, it appears in March. That month’s subtotal is therefore the movement in that month, not the cost of it — which is what makes the subtotals add up to the period movement.
A payment is dated by when the money left you. For a card that is effectively the moment you paid. For a Direct Debit it is the day the collection was taken from your bank, not the earlier day it was raised. A line that moved no money — a waiver or an offset — is dated the day it was applied.
The not-yet-due card is a screen grouping only. An export is a record of every transaction in the chosen range, so a cash-call charge whose due date has not arrived appears in a PDF or CSV as an ordinary row in the month it was raised, with nothing to mark it out. The card, and the Not due yet total under the balance figure, exist only on the balance screen.
This on-screen view can also be exported as a PDF or CSV for a chosen date range — see Download or share your statement. The export adds your payments, and an opening and closing balance either side of the monthly groups; there is still no emailed statement.
The closing balance is what you still owe at the end of the range. Every charge up to the end date, less every payment up to the end date, plus anything reversed up to the end date. Cancelled transactions are left out. The opening balance is the same figure as at the day before the range starts, and opening plus movement always equals closing.
Only a payment that has actually gone through counts. A collection still in flight, and one that failed or was cancelled, are left out — nothing has left your account.
A payment that was later taken back keeps its own row, whole. Every payment shows the full amount that left your account, on the day it left, whatever happened to it afterwards. It is what you would check against the debit on your own bank statement, so it has to be that debit.
Money coming back is a row of its own, dated the day it came back. If some or all of a payment stops covering the charges it covered, those charges are owed again, and a Reversed row records it — positive, because your balance goes up. A £100 payment of which £60 was put back shows as two rows: £100 paid in February, £60 reversed in May. Not as a £40 payment, which would be neither the sum your bank shows nor a thing that happened on any one day.
A statement is a record of its own period, and stays one. Because the reversal is dated when it happened, a statement for a period that closed before it is unaffected by it. A February statement downloaded today shows what was true in February, not what has happened since.
Not every refund produces a Reversed row. Only a refund that puts charges back on your ledger does. A refund where the syndicate absorbs the cost leaves the charges settled, so nothing appears and your balance does not move. The two corrections are different again, and neither uses a Reversed row: a correction credited to your account arrives as an ordinary credit line on the day it was credited and brings your balance down like any other credit, and a correction refunded to your bank arrives as a pair — that same credit line, and a Refunded row beside it for the money going back — dated the same day and adding to nothing, because you were charged less and have already had the difference.
A correction refunded to your bank is two rows that cancel. They are written together and always carry the same date, so no statement can ever hold one without the other. Reading them apart is the point of showing both: the credit is the syndicate saying the charge should have been smaller, and the Refunded row is your bank account already having the difference. A £210 charge corrected to £180 shows a £30 credit and a £30 refund; your balance is exactly where the payment left it.
A reversal says what happened to the charges, not where the money went. Reversed covers a bank chargeback, a Direct Debit indemnity claim and an admin putting a charge back on the books. Some of those return money to your account and some do not; what they share is that the charge is owed again, which is what the amount beside it does. The Description column names the cause.
Cash calls not yet due are the one place the closing balance and the screen part company. The closing balance counts a cash call from the day it was raised; the headline balance on the member-balance screen holds it back until its due date. Everything else agrees.