Payment account and Billing screens

What it is

The Payments hub carries three money screens, split by the question each answers.

Screen	Answers	Contains
Payment account	Where does the money land?	The payment provider connection and its status, director and owner verification, the route into the provider’s own dashboard, closing the account, and the currency. Set once.
Billing	When does a charge become due?	Auto-finalise, the billing due mode, automatic monthly billing, the manual bill run, and the link to Billing Schemes. Tuned over time.
Direct Debit	Who can we collect from, and when do we take it?	The card-payment delay, the Collect now action, and the register of member mandates. See Direct Debit.

The test for which screen a setting belongs on is whether it means anything to a syndicate that does not use Direct Debit. Auto-finalise, the due mode and the monthly bill day do, so they are on Billing. The card-payment delay does not, so it is on Direct Debit.

Payment account is the only one of the three with a page-level Save button, and it saves the currency, which is the only setting it holds. Everything on Billing and Direct Debit saves the moment you change it.

Unlike the Asset rates screen, nothing on either screen cascades per asset (other than currency, which in practice is always syndicate-level). The fields are syndicate-wide.

Who can use it

Admin (including treasurer admins): view and change all fields; navigate to Billing Schemes.
Members: do not see either screen.

Where to find them

In the app:

Open the syndicate.
Go to the Admin tab.
Tap Payments (under Money), then Payment account or Billing.

Fields / options

Currency (Payment account)

Field	Notes
Currency	ISO 4217 code (e.g. `GBP`, `EUR`, `USD`). Used for every monetary display across the syndicate. Default: `GBP`. Saved by the screen’s Save settings button.

Payment collection (Payment account)

This area is where an admin connects the syndicate to online payments.

Connect the payment account. Until the account is connected, the section shows a status of Not connected and a Connect action. The action opens a wizard that collects the business type and the details the payment provider needs, then hands off to the provider’s hosted pages to finish identity verification. Card and Direct Debit capabilities switch on as the provider clears them, which can happen at different times. The full sequence is in Set up a payment account. A note below the controls states the platform fee (the small percentage Syndik8 takes from the syndicate side of each charge), which defaults to 0.5%.

Set the card-payment delay. Once the account is connected, how long members get to settle by card before Direct Debit takes the money, and the Collect now override, are set on the Direct Debit screen — not here. Collect by Direct Debit walks through both.

Record an external payment. A payment made outside the app (bank transfer, cash, cheque) is recorded by an admin (treasurer counts as admin) from the member’s drilldown, under Balance → Record a payment. It needs no connected payment account, so it works before this section is set up at all. Record a payment from a member walks through it; the mechanics of the resulting transaction are described under the Payment row of Transaction types.

Billing

The Billing screen decides when a charge becomes due, and issues the month’s bill (manually or on a schedule). How the money is then taken is not here: the card-payment delay lives on the Direct Debit screen.

Field	Notes
Auto-finalise bookings	Whether a member’s usage log with a matching start meter finalises the booking once the booking has ended, so their flying becomes a charge with no admin step. A log saved while the booking is still running waits for it to end. Discrepancies still need admin review. Off by default. It sits here because it is the first gate on a charge existing at all; see Enable auto-finalisation.
When charges become due	The syndicate’s billing due mode. At close (the default for a new syndicate): charges accrue quietly through the billing period; making balances due marks the whole outstanding balance due at once. On finalisation: each charge is due the instant it’s raised (pay-as-you-go), so the bill action has nothing left to do for it — combined with auto-finalise on, this is true pay-as-you-go. Saving is immediate and only affects charges created from that point on; nothing already on the ledger is touched. Cash calls are unaffected either way, always carrying their own due date.
Automatic monthly billing	A switch. Off (the default) means an admin bills by hand. On reveals a day of the month (1–31) to bill everyone automatically; a day beyond a shorter month’s length bills on that month’s last day. The day is read in the syndicate owner’s timezone — a syndicate does not carry one of its own — falling back to Europe/London when the owner has not set one. Works best with auto-finalise on; the screen nudges the admin if it isn’t.

Make balances due. A button that previews, then runs, the month’s bill: every charge still accruing is marked due, any member with an active Direct Debit mandate and a due balance is left for the nightly Direct Debit run, which collects once the card-payment delay has passed (counted in working days from the day of the close, since the close is what sets the due date; the confirmation dialog says how many days), a member whose own previous Direct Debit collection has not resolved is counted apart from both — only one collection per member can be outstanding at a time, so nothing further is taken from them until it clears — and everyone else with a due balance is left for the admin to chase directly. The preview also counts any bookings from before now that are still awaiting finalisation, though the bill proceeds regardless (finalising those is a separate, manual step). Running it again is always safe: a charge that’s already due is left alone, and nothing is collected twice. See Close the billing period for the full walkthrough.

When automatic monthly billing is set, the same run happens on the chosen day without an admin present: a day or two ahead the admin is warned of any unfinalised bookings, and at the run everyone ready is billed while anything unfinalised is skipped, rolled forward to the next run, and reported — one stuck booking never holds up the whole syndicate’s billing.

Billing Schemes (Billing)

A card links to the Billing Schemes screen, which lists every scheme defined on the syndicate and lets admins add, edit, delete, or promote a scheme to the default.

Each scheme carries:

Field	Notes
Name	Display label. Examples: Equity member, Renter, Founder. Used on member detail rows, on usage-log estimates, and on statements.
Default	One scheme is marked the syndicate default. New members land on it unless admins reassign them.
Dues amount and dues interval	The periodic charge for members on this scheme. Interval options: day, month, year. Stored in the syndicate’s currency.
Every and Next collection	How many of the interval unit sit between dues charges (at least 1), and the date the next dues post; from then they repeat every interval. Leave the date unset to pause dues.
Rate modifier type	How the scheme adjusts the asset base rate: None (base rate) (base rate unchanged), Fixed offset (adds or subtracts a fixed amount), Percentage (scales by a percentage), Override (replaces the base rate outright).
Rate modifier value	The numeric value applied according to the modifier type.

For the full semantics of how the modifier combines with the asset’s base rate, see Member rates (billing schemes) and Rate resolution chain.

Payment account statuses

Once the connect flow has started, the payment account carries a status. The Payment collection area of the Payment account screen shows the current one as a colour-coded badge, and the transitions that matter also notify every admin. All three payment-account notifications sit in the Critical tier: they are sent immediately rather than digested, and they cannot be switched off on every channel at once. See Notification types.

Status badges

Badge	What it means	What to do
Not connected	No payment account exists yet.	Tap Set Up Payments to start the connect wizard.
Setup incomplete	The wizard was started, but the details have not yet been submitted to the provider.	Tap Continue Setup: the wizard reopens on the first step you have not saved, with your saved answers filled in.
Under review	Details are submitted and the provider is verifying them.	Wait; verification usually takes one to two business days.
Connected	The account is active and charges are enabled. Collection is available.	Nothing; you are done.
Action required	The provider has restricted the account. Collections stop until the issue is resolved. A sign-up that was started and never submitted shows this badge too, because the provider restricts an incomplete account.	Read the reason shown under the badge (see “Restricted accounts” below).
Disconnected	The account has been deauthorised and is no longer linked to the syndicate.	Tap Reconnect Payments to run the connect flow again.
Status unrecognised	An account exists, but its state is one this version of the app does not know how to read, usually because the app is older than the service behind it.	Update the app; if the badge stays, contact support.

Notifications admins receive

Payment verification complete (titled Payment setup ready). Every flagged director and 25%+ shareholder has confirmed their personal details, so setup can be finalised. Sent to every admin, once per syndicate; tapping it opens the payment setup screen.
Payment charges enabled (titled Payments are now live). The account has cleared verification and the syndicate can now collect from members. Sent once per syndicate; it is informational, with no navigation target.
Payment account restricted (titled Payment account needs attention, or Payment account disconnected when the account has been deauthorised). Collections cannot run until the problem is fixed. Tapping it opens the payment setup screen; the badge on this screen explains what is wrong.

Restricted accounts

When the badge reads Action required, a short explanation appears under it, and the control that resolves it sits directly beneath:

You have not finished signing up. The provider’s own pages were opened and left before the details were submitted, so the syndicate cannot collect payments yet. Tap Continue Setup to carry on where you left off. This is the commonest reason for the badge, and it is not a fault. The same explanation appears under a Setup incomplete badge.
The provider needs more information. Outstanding verification steps remain; complete them on the provider’s pages. Tap Continue Setup, which reopens those pages at the first unanswered step.
The provider is checking your documents. No action needed, and no button is offered. The syndicate cannot collect payments until the check finishes, which usually takes one to two business days.
The application was declined. Nothing on the provider’s pages lifts a rejection, so Contact support opens an email to us instead.
Anything else, including a restriction the provider recorded no reason for, shows a generic prompt to check the account with the provider.

A restricted account keeps its data and settings. Once the provider lifts the restriction, the badge returns to Connected.

Payment directors and owners

For a syndicate set up as a company, the payment provider must verify the people behind the business: every company director, and everyone who owns 25% or more of the company. Two per-member flags record who those people are:

Flag	Meaning
Company director	The member is a director of the company.
25%+ shareholder	The member owns 25% or more of the company.

Flagged members confirm their own identity details rather than the admin collecting those details on their behalf: date of birth, home address, job title, and their share of the syndicate. They enter their share themselves; the app does not calculate it from their membership shareholding, which is not the same thing as their stake in the company.

Flagging someone does not prompt them. An admin has to ask, using Ask directors and owners for their details on the Directors and beneficial owners step. That is the opening ask and the only syndicate-wide one: once made, the button is replaced by the date it was asked on, anyone flagged afterwards is prompted automatically, and chasing from then on is done per person from the list beneath it. Until then nobody is contacted, so members are not asked for personal details for a payment account the syndicate may never open. Once requested, each flagged member who has not yet submitted sees a banner on the syndicate dashboard (Payment setup needs your details) with a Complete now action; the banner disappears when they submit. While submissions are outstanding, the Payment collection area shows an Awaiting director verification progress line, and when the last one arrives every admin receives the Payment verification complete notification described above.

Payment setup can be completed at any time, whether or not every flagged member has responded. Their details can only be handed to the payment provider at the moment the account is created; after that the provider owns those records and the app cannot add to them. So finishing while someone is outstanding means that person is asked for their details on the provider’s own pages instead, rather than having them sent ahead. The progress line reports who is outstanding, but it does not hold setup up.

Where to manage the flags

During connect: the wizard’s Directors and beneficial owners step lists the stakeholders who will be sent to the provider. Each row names the person, says whether they are a Company director, a 25%+ shareholder or both, and reads Details confirmed or Details outstanding, under a running Confirmed: X of Y. It asks for nobody’s personal details, because each person submits their own. The one control on a row is Remind, which appears only while that person is outstanding and sends the request to them alone; it never appears on a confirmed row, and a person who has submitted cannot be reminded at all. Repeated presses are spaced a few hours apart, and a press inside that window reports how long is left rather than sending anything. It is also not where the per-member flags are set or cleared and has no unflag control: flagging and unflagging happen on the member detail screen (below), which the step names when nobody is flagged yet.
On an invite: for company syndicates the invite form carries the same two flags, so a member joins already flagged as a director or owner. Flagging via the invite does not prompt them; they are asked only once an admin presses Ask directors and owners for their details. See Invite members.
Ongoing: open the members list, tap the member, and use the two checkboxes on the member detail screen. This is the only place a flag can be cleared. Only admins can open member detail, and the checkboxes only appear when the syndicate’s business type is company.

What changing a flag does

Flagging someone new adds them to the outstanding count. Their verification banner appears once an admin presses Ask directors and owners for their details, not the moment they are flagged, and stays up until they submit. The flags stay live after onboarding, not just during initial setup.
Removing a flag takes the member out of the count and removes their banner. Details they have already submitted are kept.
Neither flag affects the member’s role, billing scheme, or shares. They exist solely so the right people are verified for payments.

The in-app flags drive Syndik8’s own progress tracking and prompts; the provider additionally runs its own identity checks on its hosted pages during connect, and remains the authority on who must be verified. Setup can be finalised whether or not every submission is in. Submitting shows a confirmation dialog that says how many are still outstanding and explains that they will be asked on the provider’s pages instead; the admin can continue past it. The provider may still come back asking for more information.

Managing the account in Stripe, and closing it

Once a connected account exists, Stripe owns its people and details: the app can no longer read or change the directors, owners, the registered representative, team access or bank details. Those are managed in the syndicate’s own Stripe dashboard, reached from the payments section’s Go to Stripe button.

The registered representative is the person Stripe holds responsible for the account. Changing who that is happens in the Stripe dashboard, not in the app. A departing representative is not blocked: when an admin leaves a syndicate that has a payment account, or is removed from one, a non-blocking reminder asks them to make sure the Stripe representative role has been handed to someone else in Stripe. It is a prompt, never a gate, because the app can no longer reliably tell who the Stripe representative is.

To disconnect payments entirely, the payments section has a Close payment account button. Closing permanently closes the syndicate’s Stripe account and cannot be undone; the syndicate must complete payment onboarding again before it can take payments. It is refused while the account still holds a balance, has a payout in flight, or has an active Direct Debit mandate; clear those first (or contact provider support) and try again. A successful close cancels any remaining mandates and deauthorises the account. On an individual / sole trader account, where the representative is the account holder and cannot be reassigned, closing and re-onboarding is the way to change who is responsible.

Closing a whole syndicate also tears the payment account down as part of the close, so an account is never left running with nobody attached. See Close a syndicate.

Behaviour rules

Scheme definitions are syndicate-wide. There is no per-asset scheme definition. The same set of schemes applies across every asset.
Per-asset scheme rates are a separate concept. The actual rate that results from “scheme X × asset Y” is set in the asset’s billing configuration, on the Asset rates screen for single-asset syndicates and on each asset’s own billing screen for multi-asset syndicates. See Default and per-asset settings.
The default scheme cannot be deleted without first promoting another scheme. The syndicate must always have exactly one default scheme. The delete action is disabled on the default row.
Changing the currency does not convert historical amounts. Past transactions keep their original currency; future charges use the new one. For this reason, the currency change confirmation warns admins and is typically set once at syndicate creation and left alone.