Reversals

What it is

A reversal is a record of what money flowing back out of a previously captured settlement means to the ledger: a chargeback on a card payment, an indemnity claim against a Direct Debit collection, an admin-issued refund, a partial refund, or a syndicate-side write-off. Reversals are first-class records (they carry their own cause, source, dispute lifecycle, and audit trail) rather than being modelled as a paired credit transaction.

Refunds and reversals are two separate records

A refund records that money moved at the payment provider — how much went back, against which payment, under which provider reference, and whether Syndik8 asked for it or it simply appeared. A reversal records what that movement did to the ledger. They are kept apart because they do not always arrive together:

A refund Syndik8 makes carries its meaning with it. Only the app knows which charges a payment covered, so the charges and the intent are recorded before the provider is called, and the reversal is written as soon as the money settles.
A refund made in the provider’s own dashboard arrives knowing nothing. A £40 refund against a £100 payment covering five charges names none of them, and may have no subset of them summing to £40, so it cannot be expressed as a reversal at all until a person says what it covers. Until then it waits in the admin queue.

Reversals are also distinct from the Reversal transaction type listed under Transaction types. That ledger entry exists for admin corrections to the booking ledger (e.g. an admin cancelling a wrong shortfall). The reversals described on this page apply to in-app payment-provider settlements.

Who can use it

Admin (including treasurer): see every reversal and refund on the syndicate. Send money back to a member (full or partial), and decide what a refund made outside the app meant. Nothing about a payer-bank reversal is theirs to decide: the member’s bank decides a dispute and the payment provider reports the outcome, so the queue shows it and offers no verbs on it.
Member: sees reversals against their own payments via the standard notifications path, plus the resulting balance impact on the member balance screen.
Provider and payer bank: write reversal records via webhook (chargebacks, indemnity claims, AUDDIS, etc.).

Where to find it

Reversals are managed from the Admin tab → Payments → Reversals. The screen has three sections:

Needs attention — one queue over two sources, because both are “money that moved and has not been dealt with”. Unresolved reversals carry no actions at all, because their outcome is the bank’s to decide and the provider’s to report; refunds nobody has interpreted carry a Decide what this means action and a Clear it for good action instead. A refund that cannot bear a ledger reading at all — one the app could not match to a payment, and one the provider later reported failed — carries only Clear it for good, and says which of the two it is. A refund is money the syndicate sent back on purpose, so there is nobody to dispute it with either.

Only reversals a bank or the payment provider raised against the syndicate are listed. A reversal the syndicate wrote itself — recording a refund on the ledger, or correcting a payment on the books — has no counterparty and nothing to decide, so it never enters this queue: it is a record of a decision already taken, and the member and the other admins were told when it was taken.
On its way back — refunds the provider has accepted and not yet settled. Nothing can be done to one; it is shown so that an admin looking for a refund they raised days ago finds it rather than raising a second.
Resolved — a read-only reversal history.

The Raise a reversal button starts the flow for putting one payment right: choose one of the syndicate’s settled payments, tick the charges being put right, and pick what that makes them (reverse the settlement, full refund, or adjust the amount).

That flow has two routes, and the payment decides which. Where the payment provider is holding money — a card, Direct Debit, instant bank transfer or in-app payment that actually captured, carrying a provider reference — the provider is asked to send it back, the confirm button names the amount leaving the account, and a confirmation naming the amount and the member stands between that button and the provider. Where it is not — cash, an external transfer, a waiver, or an offset against a credit — a panel on the form says so, the button reads Correct the books, and confirming adjusts the ledger alone. A card or Direct Debit payment never takes that route: if the provider cannot send the money back, the record itself is wrong, and the form says so and offers nothing rather than letting an admin write off a payment nobody has asked the bank about. Both routes offer the same three meanings and write the same kind of reversal; only whether money moves differs. The one exception is a waiver, which offers only reverse the settlement: nothing was ever taken from the member, so there is nothing to give back, and both of the other two would record money returning that never left.

Members do not get a dedicated reversals screen. They see a reversal against their own payment through the standard notification and the resulting balance impact on the member balance screen.

Concepts

Cause

The cause identifies why the reversal happened. The catalogue is open (new providers and regimes can extend it without a migration), but the active values are:

Cause	Origin
DD failure	DD authorisation declined (insufficient funds, AUDDIS, ARUDD).
DD indemnity	Indemnity claim under the Direct Debit Guarantee.
DD mandate cancelled	Mandate cancelled at the bank (affects future collections, not past ones).
Card chargeback	Cardholder filed a chargeback through their bank.
Section 75 claim	Section 75 Consumer Credit Act claim via card issuer.
Bank recall	Bank recalled the funds (typically fraud).
Provider correction	Payment provider corrected a previous error.
Admin targeted	Admin acts on one specific settlement. Reversing it re-bills the underlying transactions; correcting the amount does not — see the note below.
Admin full refund	Admin gives back the whole of a payment. Used only where the amount returned is all of it.
Admin partial refund	Admin gives back part of a payment — one charge out of several — and the charges stay settled. A corrected amount is Admin targeted, not this.
Syndicate write-off	Syndicate decides not to pursue a debt; money is written off.

A dispute reported by the payment provider currently arrives labelled Card chargeback whatever the payment method, so the cause on the row is not a reliable way to tell a Bacs indemnity claim from a card chargeback. The payment’s own mechanism is: a reversal against a Direct Debit collection is an indemnity claim however the row is labelled, and that — not the cause — is what the member’s own notification is written from.

Source

Many causes share an origin. Source lets you filter by who lodged the reversal: payer bank, admin, provider, or syndicate.

Status (dispute lifecycle)

Status	Meaning
Received	Reversal has landed; no dispute action yet.
Disputed	We are challenging the reversal with the provider or bank.
Final, lost	Dispute concluded against us; the reversal stands.
Final, won	Dispute concluded in our favour; the reversal is overturned.
Expired	A legacy status. Nothing produces it: a lapsed dispute window is closed and reported by the provider like any other outcome.

A Final, won reversal is excluded from the cumulative-cap check on its parent settlement; it has been overturned and no longer counts toward the total reversed amount.

For the same reason, a reversal that records a refund or a fulfilled correction cannot be marked Final, won at all. There is no dispute to conclude, and excluding it from the cap would give the payment back capacity it has already spent — so the same money could be sent to the member a second time. The server refuses it whoever asks.

Transaction handling

Each reversal carries a handling choice that decides what happens to the transactions settled by the original settlement:

Rebill (default): the listed transactions are unsettled; the member owes those amounts again, and they will be picked up by the next billing cycle.
Forgive: leave the transactions settled; the syndicate carries the loss. Used for goodwill refunds, write-offs, corrections, and any case where the syndicate has decided not to re-pursue.

An admin choosing what a refund meant is offered three readings rather than two, because the charge was wrong is a distinct answer even though the ledger records it with forgive handling:

Reading	What it does
They still owe this	The charges reopen. The money is back in the member’s bank and the amount is outstanding again — the case where a payment was taken wrongly and will be collected properly afterwards.
It was a gesture; they owe nothing	The charges stay settled and the syndicate carries the cost.
The charge was wrong	The charges stay settled at the corrected figure, and only the difference goes back.

The readings on offer are constrained by arithmetic: charges summing to exactly the money returned can be either of the first two; charges summing to more than it can only be the third; charges summing to less than it have no reading at all, so none is offered.

Behaviour rules

Nobody declares the outcome. A card dispute is adjudicated by the member’s bank, and Syndik8 is told the result by the payment provider. There is no action anywhere in the app that records how a dispute ended, and the database refuses one: no signed-in session can write a reversal’s status or conclude a dispute, whatever their role. Challenging a chargeback is done with the provider, through their evidence process.
Cumulative cap. The total amount across all non-overturned reversals against a single settlement cannot exceed the settlement’s amount. The server enforces this with a guard, so concurrent admin refunds and inbound chargebacks against the same settlement serialise rather than double-reverse.
The dispute lifecycle moves forwards only. A reversal can go from Received to Disputed (or straight to a final status), and from Disputed to a final status; Final, won, Final, lost, and Expired are permanent. The server rejects any other status change, so a delayed or redelivered provider message arriving after the outcome is recorded cannot overwrite it with a contradictory one. Nobody signed in can write these statuses at all; the provider’s webhook is the only writer.
Subset and amount checks. Each reversal must list a non-empty subset of the parent settlement’s transactions, and the sum of those transactions’ amounts must equal the reversal’s amount. The server only re-validates this when the validated fields change, so dispute-status transitions are not blocked.
A rebill is undone only by winning the dispute. Switching a reversal from forgive to rebill, or extending the transactions it covers, unsettles the affected transactions. Nothing puts them back except a Final, won outcome on that same reversal, which settles them again against the original payment, because winning means the money came back. Four cases are deliberately left alone, each one where putting the payment back would be wrong: a charge cancelled while the dispute ran, one another payment has since settled, one a collection is already claiming, and one whose amount was corrected in the meantime, since the payment cannot cover a figure it was never for. Those stay owed, which is what every rebilled charge does anyway. A forgive reversal marked won restores nothing, having taken nothing back, and recording the same outcome twice is inert.
A charge under an open dispute is owed, but nothing collects it. While a member’s bank is still deciding a dispute, the charges that payment covered are owed again — and no collection touches them: not the nightly Direct Debit run, not the billing close, and not the member paying by hand. Taking them a second time while her bank still holds the first is how she pays twice for one debt and has to chase one back, which is the position disputing was meant to get her out of. This applies only to a dispute a bank drove: a refund the syndicate sent, and an admin undoing a payment on the books, also make charges owed again, and those are collected as normal, because being owed again is the point of both. A dispute the member loses releases the hold — the money is gone for good, so the charge is owed and collectable, and it goes out on the next nightly run. Because every payment route goes through the same check, a member cannot clear a held charge herself either — and her balance screen says so on the row rather than waiting for her to try. The charge carries an Awaiting your bank pill in place of its Pay button and a sentence saying she still owes it but nothing can take it until her bank decides; Pay All leaves it out, with a banner under the balance header and a line under the button both naming the held amount. The weekly balance-due chasing skips it for the same reason. An admin can record a payment against it if she would rather settle directly — deliberately the one route left open. The charge counts towards her balance throughout, and towards what stops her leaving the syndicate: it is a debt, and a dispute does not make it otherwise.
A correction has exactly one fulfilment, and the ledger carries exactly one. Correcting a charge downwards means the member is due the difference, and there are two ways they can receive it. Both post a credit for the difference — that credit is the books recording what the syndicate charged — and they differ in what pays it. Refund to bank — the difference goes back through the payment provider, and the credit is discharged in the same moment by the money leaving, so nothing further is owed and the member’s balance does not move. Credit on account — the difference sits on the member’s balance as an unsettled credit, and that credit is how the member is made whole. Which one you get is decided by whether the payment provider is holding money against that payment, not by a choice you make: for a provider-backed payment the app offers only the first, and for a payment the provider never took (an external transfer, a waived charge, an offset against a credit) only the second. Both are reached from the same Raise a reversal flow, which says which one you are on before you confirm. Doing both would make the member whole twice, invisibly. The reversal records which fulfilment happened alongside the corrected figure and the amount returned.
The platform fee comes back when the money does. A refund returns Syndik8’s own cut in proportion to the amount refunded, and a dispute the syndicate loses returns all of it, because none of that money was ultimately collected. The payment provider’s processing fee on the original payment is not returned, and a disputed payment also carries the provider’s own dispute fee; neither is Syndik8’s to give back. See how payments work.
Correcting a charge upwards is refused. No money moves back to the member, so it is a new charge and belongs on the manual-adjustment path.
A refund made outside the app cannot touch the ledger until somebody interprets it. It sits in Needs attention as money that moved with no meaning attached, and leaves the queue one of two ways: applied under one of the three readings above, or cleared for good as having no ledger effect. Clearing always carries a reason, because the row leaves the queue either way and one with nothing written on it is indistinguishable later from a refund somebody lost track of. A refund the app could not match to one of the syndicate’s own payments can only be cleared — there is nothing on the ledger to apply it to.
Clearing a refund is permanent, and the payment behind it stops being refundable. Clearing records that nobody could say what the money meant, not that it stayed put: it left the account, so it goes on standing against the payment it came off. That payment can never be refunded through Syndik8 again, a later refund arriving on it can never be recorded, and none of it can be undone. The alternative would be worse — a refund made in the provider’s dashboard, cleared because nobody could attribute it, and then the same charge refunded again in the app is the member paid twice for one charge.
A refund that fails after it settled is recorded, not un-recorded. A card refund can fail days after reporting success, and the money returns to the syndicate. The refund keeps saying money left the provider, because it did, and it goes on holding its amount against what the payment can still return; what is added is a separate record that the provider later reported it failed. While that record stands the refund cannot be applied to the ledger at all — the server refuses it, so a redelivered provider message cannot reverse the charges either — and dismissal is the only way it leaves the queue. The queue shows the failure on the row, with the provider’s reason where it gave one, and withholds the decide action, so an admin reads the rule rather than meeting it as a refusal. The hold is deliberately not released: handing the capacity back automatically is how the same money goes out twice, and a hold that stands only costs somebody a look. Platform operators are alerted whenever it happens.
A refund still settling already counts against what can be refunded. A bank refund pends for days, and during that window it holds its amount against the payment’s remaining refundable total. This is what stops two admins each returning the whole of the same payment.
Money never moves without a confirmation. The flow puts an explicit confirmation, naming the amount and the member, between the confirm button and the payment provider. A refund cannot be recalled from the app once the provider has it. The books-only route is confirmed too, in its own words, because it changes what a member owes even though nothing leaves the syndicate.
Which route a payment gets is not an admin’s choice. It follows from the payment: the mechanism it was taken by, whether it actually captured, and whether it carries a provider reference. The screen and the server apply the same rule for the route, so a payment offered the books-only route is one the server would refuse to refund. Being offered the refund route is not a promise the refund will go through: the server still checks the figures against the charges as it holds them, and against what remains refundable, and those refusals arrive as an outcome rather than being pre-empted on the form.
Credit on account is a ledger credit. A correction fulfilled as credit on account posts a single unsettled credit for the difference against the member’s balance, which is netted off what they owe next. A refund that went back to the member’s bank posts none — the money is already theirs.
Notifications fire on payer-bank reversals. A debit failed notification is dispatched on a DD failure; mandate cancelled fires on a DD mandate cancellation. Both deep-link to the related settlement. The reversal received notice to admins carries the payer’s name, the amount, and the payment date, captured at the moment it fires, and cannot be silenced.
What the syndicate did and what somebody else did are announced as different things. Three notification types cover the three cases, and which one fires is decided by what actually happened rather than by who is reading. Reversal received is money taken back by a payer’s bank. Refund sent is money the syndicate returned through the payment provider: the member is told the amount, the payment it came off, that it takes a few days to arrive, and what has happened to the charges. Payment corrected is a correction to a payment with no provider money behind it: the member is told the same things minus the money, and explicitly that none has moved, because the one thing they must not do is wait for a bank credit. For the two the syndicate drives itself, the member hears, every other active admin hears, and whoever pressed the button is told nothing, having just done it. Reversal received has no such actor: every admin is told, and the payer as well unless they are an admin and have already had the admin copy. All three are Critical tier — push can be silenced, email cannot. See Notification types.
A clawed-back Direct Debit tells the member what their bank did. Where the reversal is against a Direct Debit collection and the charges are being re-billed, the member’s notice is headed Direct Debit reversed and names the sum and the collection date: “Your bank reversed £X from YYYY-MM-DD. You now owe £X again.” The wording is fixed and is chosen from the payment’s mechanism, not from the reversal’s cause. A card chargeback, and any reversal the syndicate absorbs rather than re-bills, keep the general wording instead — the sentence ends by saying the money is owed again, and that is untrue of a reversal nobody is re-billing.
A payer who has left, or deleted their account, can still be charged back. Chargebacks and indemnity claims run on the bank’s clock, and there is no deadline Syndik8 controls after which one can no longer arrive, so one can land after the payer has left the syndicate or deleted their account. The reversal is still recorded and admins are still notified; the notice’s snapshot of who, how much, and when is the handle for finding the payment in the provider’s records. Recovering that money happens between the syndicate and the former member directly, outside the app: a departed member has no balance screen to re-bill, and the resurrected debt deliberately does not reopen their exit or block the syndicate from closing.

Reversing a settlement older than ninety days

When an admin raises a reversal against a settlement that captured more than ninety days ago, the confirm step carries an extra warning above the action button. The warning is informational (the reversal can still go ahead), but it makes the indemnity exposure explicit so an admin doesn’t accidentally take a stale collection back without thinking it through.

The warning copy is fixed and reads:

This settlement is over 90 days old. Reversing now still works, but be aware that for Direct Debit specifically, the payer’s bank can claim the money back later under the Direct Debit Guarantee, without giving a reason. That clock belongs to the bank, not to us, so there is no point at which an old collection becomes safe. Confirm this is the right action.

The warning names no time limit, and that is deliberate. Nothing in Syndik8 gates a reversal on age: the ninety-day threshold decides only whether the warning appears, and the action goes ahead either way. How long a payer’s bank will still entertain an indemnity claim is the scheme’s rule and the bank’s decision, so the warning says what can happen rather than for how long. The ninety-day threshold itself is not regulatory; it is the point at which a reversal becomes operationally unusual enough to warrant the second look. Settlements within the threshold suppress the warning entirely.

The warning copy is pre-authored and must not be edited without legal review. In particular, do not put a time limit back into it without a verified source for the figure: stating one the syndicate cannot rely on errs in the syndicate’s favour, which is the dangerous direction.