Authorise every refund before it goes out
A role-gated authorisation step that sits between a refund request and the actual refund — so the wrong refund never goes out, and the right one carries an audit trail.
The challenge.
Refunds are easy to get wrong — wrong amount, wrong card, wrong booking, wrong reason. The cost of a bad refund is real money out of the door and an audit trail the auditor cannot rely on.
Accidental refunds happen
Mistyped amounts, refunds against the wrong booking or transaction, refunds on top of refunds — all real, all expensive when they go through unchecked.
Who refunded this?
Without a clear authorisation step, refund decisions blur into the rest of the operations workload — and the audit trail asks who, when and why months later.
Trustees and auditors expect a trail
For ATOL, trust-account and audit reviews, every refund needs to evidence its authorisation as part of the protected-funds picture.
How refund authorisation works.
A refund request becomes an explicit authorisation step that an authorised person — and only an authorised person — can approve or decline. The decision and reason are kept against the booking.
Refund requested
An operations user requests a refund against a transaction.
See refund management for travelAuthorisation or decline
An authorised user reviews and approves — or declines with a reason.
See financial controlProcessed to the original rail
An authorised refund pushes to the original payment rail.
See refund management for travelEvidence kept
Authoriser, time, reason and the original transaction — all kept against the booking.
See protected fundsWhat you get to control.
A clear separation between who can request a refund and who can authorise one — with the workflow and audit trail to defend the decision.
Role-gated approval
Only users with the refund:approve role can authorise or decline a refund.
Decline reasons
Declined refunds carry the reason against the booking — useful for customer-service follow-up and audit.
Authorisation evidence
Authoriser, timestamp and outcome kept on the booking record automatically.
One transaction, one trail
The refund record ties back to the original transaction and the booking that produced it — so reconciliation stays clean.
How felloh helps.
Refund authorisation runs inside the same booking-level ledger as the original payment, so the audit trail, customer evidence and trustee reporting all share one source of truth.
Fewer expensive mistakes
A role-gated step in the middle catches typos, duplicates and wrong-booking refunds before they go out.
Audit-ready by default
Every refund — authorised or declined — leaves the evidence trail trustees and auditors expect.
One ledger for refunds
The refund picture shares the booking, transaction and protected-funds context of the underlying payment.
Refund thinking from the felloh team.
See how this works around your bookings.
Bring one payment, reporting or cash-position problem. We will show how felloh connects the booking-level money trail behind it.
Book a walkthrough