Statement format

What it is

The CSV export opens with accented and non-Latin names intact in Excel, Numbers, Google Sheets and LibreOffice.

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 a Due half and a Settled half, and both are grouped this way — see Member balance for what each half counts.

A cash call whose due date has not arrived is not on your ledger at all: your share of it is shown above the ledger, in its own ungrouped Cash calls not due yet card, with no month heading and no part in any monthly net. On its due date your share is posted to the ledger, joins the Due half under that month, 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 (a treasurer needs the admin role) 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 charge description.
Charge details	Expand a row to see every component and its calculation, including a charge with just one component. Payment details follow when available. Calculations are kept in the expanded panel.
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.

The export screen offers Date format, initially set to your normal date preference. Change it for this PDF or CSV without changing your profile preference. The same choice applies to period bounds, generated dates, transaction dates and flight dates.

Every export opens with a short note saying what the document is: a record of one member’s account with the syndicate, and a source document for the syndicate’s books rather than a substitute for them. Syndik8 keeps members’ accounts, not the syndicate’s own, so a statement is one side of every entry and cannot be reconciled to a syndicate bank account — see How payments work. In a PDF the note sits under the title block, above the opening balance; in a CSV it is a single quoted cell on the fifth line, in the first column, below the generated line and above the blank line that precedes the opening balance. It is prose, so it is translated with the rest of the document; the column headings and the row labels beside a figure are not.

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 cash call, the day your share was posted: its due date, or the day you paid it if you paid early); 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. A refund recorded after its month had closed is the one line whose date can be earlier than the month heading above it — see A statement stays the document it was below.
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; Refunded for money sent back the way you paid (to your card or your bank), either when a charge you had already paid was corrected downwards or as a goodwill refund; and Goodwill credit for the charges a goodwill refund covered, which the syndicate absorbed.
Description	For a charge, a one-line summary: usage charges show “X hrs at £Y/hr” (“1 hr at £Y/hr” for exactly one hour); 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, including the card brand and last four, Apple Pay / Google Pay, or Direct Debit account ending when available; otherwise a generic method label. For a reversal, the cause — Card chargeback, Direct Debit indemnity claim, and so on. For a refunded correction, Correction refunded the way you paid. For a goodwill refund, Refunded the way you paid (ref …) on the refund row and Charges absorbed by the syndicate (ref …) on the row beside it. The two rows carry the same short reference, so you can tell which credit belongs to which refund.
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, or the Goodwill credit row beside a goodwill refund. A Goodwill credit row is negative.
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.
VAT	The VAT in the amount beside it. Only for a syndicate that has said it is registered for VAT — for every other syndicate the column is not there at all. In a PDF it is a column after Amount; in a CSV it is the last column, after Flight date.

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 Due 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. Waived takes no money off you: an admin wrote the charge off. Credit offsets are omitted from exports: the original credit and the charges already account for the balance, so subtracting an offset again would count that credit twice. Undoing an offset reopens the charges and restores the same credit, so it adds no exported movement either. Forgiving a charge paid from credit keeps it settled and restores the credit: that appears as a negative Goodwill credit on the day it was forgiven, with no bank-refund row.

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

VAT

Nothing in this section applies unless your syndicate has said it is registered for VAT. Most syndicates are groups of co-owners sharing costs between themselves and are not, and their statements are exactly as described above.

A registered syndicate’s statement carries its VAT registration number, under the syndicate name in a PDF and below the scope note in a CSV. That, and the VAT column, are what make the statement resemble the invoice your accountant is expecting.
The VAT figure is worked out from the amount beside it, not stored. Charges are VAT-inclusive at the flat UK standard rate, so the VAT in a charge is exactly one sixth of it: a £120 charge carries £20 of VAT. Nothing in the ledger holds a separate VAT amount that could drift away from the money it belongs to.
Only what the syndicate supplied carries VAT. That means the flying time, each event fee, a periodic dues charge, a minimum-usage shortfall and an admin’s adjustment of any of them. A payment settles charges that already carried their VAT when they were posted, so a figure beside the payment would count the same tax twice in the month you paid. Reversals, refunds and goodwill credits are blank for the same reason: they move money or take charges back, they do not supply anything. So are three kinds of charge that do have a ledger line of their own — a cash call, which is a contribution towards the asset you already jointly own rather than something sold to you; a loan you made the syndicate; and an expense credit reimbursing something you bought on its behalf, where the VAT was on the original supplier’s invoice and is the syndicate’s to reclaim, not yours.
A credit carries VAT to reclaim. A correction that reduces a charge is negative, and so is its VAT.
The monthly subtotal and the period total add up the column. Each is the sum of the VAT figures printed above it, not the VAT of the subtotal beside it, so the column foots however the individual pennies rounded.
There is no VAT against the opening or closing balance. Those are what you owe at an instant, not what was supplied over a period.
Switching VAT on or off reaches statements that have already closed. The VAT figure is worked out when you download the statement, not stored when the charge was raised, so it follows whatever the syndicate’s registration says at that moment. Turning registration on puts a VAT column on every past statement; turning it off takes the column and the registration number off them again, so a member holding a VAT-bearing February statement who downloads it a second time gets one with no tax on it. Only change the setting when the syndicate’s actual registration changes.
A statement is not a VAT invoice and does not replace your syndicate’s own books. It is one member’s account, and the source document an accountant works from — see How payments work.

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 puts no charges back, so it has no Reversed row; it appears as a Refunded and Goodwill credit pair instead (see below).
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 — is dated the day it was applied.
A cash call joins an export when your share is posted, dated that day. Until then it is notice of a charge to come rather than a charge: it is not on your ledger, so a PDF or CSV has nothing to show, just as the balance screen keeps it in the Cash calls not due yet card and out of the headline figure. On its due date your share is posted and appears as an ordinary row dated that day and filed under that month. If you pay it early, it is posted on the day you paid, beside the payment that paid it. This holds even for a range that runs past today: a cash call due next month is not on the statement until next month.
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 stays the document it was. A statement for a period that closed is not changed by anything that happens afterwards. A February statement downloaded today shows what February’s statement showed, so the copy you gave your accountant and the copy you download next year are the same document. There are two exceptions. Any charge that is cancelled leaves every statement that carried it, closing months included: that covers cancelling a cash call, and a cash-call share you started paying early whose payment never completed, which is put back to wait for its due date. And switching the syndicate’s VAT registration on or off changes the VAT column on every past statement — see the VAT section above.
A refund recorded late appears on your current statement, dated the day the money moved. A refund made directly with the payment provider reaches your statement only once an admin says what it was for, and that can be after the month the money moved in has closed. Rather than rewriting that closed month, the refund turns up on the statement for the period it was recorded in, still dated the day your bank shows the money, and its description says it is from an earlier month and was recorded since. So a refund that went out on 27 February and was recorded on 4 March appears under March, dated 27 February. Your own bank statement still reconciles against it, and February is untouched.
A refund carried forward moves no balance. A refund always arrives with its counterpart — the credit note of a correction, or the goodwill credit — and the two are equal and opposite. They are carried forward together, so the month it left and the month it arrives in both close on exactly the figures they would have anyway. Only the record of the money moving is carried; nothing you owe changes.
Not every refund produces a Reversed row. Only a refund that puts charges back on your ledger does. A goodwill refund, where the syndicate sends money back and absorbs the cost, leaves the charges settled and your balance where it was, and arrives as a pair: a Refunded row for the money going back to your bank, and a Goodwill credit row for the charges the syndicate absorbed, dated the same day and adding to nothing. 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 always carry the same date, the day the difference left the syndicate for your bank, 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 goodwill refund is two rows that cancel. Both are dated the day the refund went through, when the money left the syndicate for your bank. That is the day your bank shows it, not the day of the charges it covered, so a refund in May of a charge paid in February puts both rows in May. A refund that went through on 31 May but was not recorded until 3 June keeps that 31 May date and appears on the June statement rather than reopening May — see A refund recorded late above. A £222 payment refunded in full shows a £222 Refunded row and a £222 Goodwill credit row beside it; your balance is exactly where the payment left it, and the payment row itself still shows the £222 you paid. Each refund gets its own pair, so a payment refunded in three parts shows three. A refund appears only once your bank has been sent the money: one that is still on its way, or that failed before it was sent, is not on the statement. If a refund that was sent is later returned by your bank, the pair stays and a separate credit row records the money the syndicate now holds for you.
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.
The closing balance agrees with the balance screen. A statement whose range ends today closes on the headline figure the member-balance screen shows, cash calls included: both read the same ledger, and neither counts a cash call until your share has been posted to it.