Matching gateway payouts and fees to your books
How a travel agency records Paystack and Flutterwave payouts and the fees taken from them, so each gateway's clearing account reconciles every month.
By Achekam · · 4 min read · For Travel businesses in South Africa, Nigeria, Kenya
Your bank statement shows a deposit from Paystack. It does not match any invoice. It is smaller than the three bookings that were paid online this week added together, and larger than any one of them. Somebody in the office has to work out what it is, and if nobody does, the bank reconciliation carries an unexplained line from one month to the next.
That deposit is a payout: the gateway collected several payments from your clients, took its fees, and paid you the rest in one transfer. It is ordinary, and it is one of the commonest reasons a travel agency's bank and debtors do not agree.
The fix is to let a clearing account sit between your clients and your bank, and to record each payout properly when it lands. Here is how that works in Achekam.
Why a clearing account sits in the middle
When a client pays a booking invoice online, the money does not reach your bank that day. It sits with the gateway until the next payout. A clearing account for each gateway represents that money: paid by the client, held by the gateway, not yet in your bank.
Each gateway has its own clearing account, which matters if you use more than one. Paystack and Flutterwave pay out on their own schedules and charge their own fees. Keeping them apart means each one can be reconciled against that gateway's own reports.
Each verified payment lands in clearing
Achekam records a gateway payment only after checking it with the gateway. A Paystack payment, in naira, shillings, Ghanaian cedi, rand or US dollars, is confirmed with Paystack before it is recorded: notifications are checked by their signature and re-verified with Paystack's verify service, and you paste the webhook address Achekam gives you into your Paystack dashboard. A Flutterwave payment, in the same currencies, is re-verified with Flutterwave before it is recorded.
Once verified, the payment is recorded as a receipt against the client's invoice, debiting that gateway's clearing account and crediting trade receivables. The invoice shows as paid or part-paid. The amount is checked against what the pay link asked for, and a repeated notification never pays twice.
So by the end of a busy week, the Paystack clearing account holds every Paystack payment your clients made, each one tied to its invoice.
A payout leaves clearing with its fees
Payouts from each payment gateway are recorded against that gateway's clearing account, with the gateway's fees.
A worked example in words. Three clients pay their deposits through Paystack during the week. Each payment is recorded against its invoice and adds to the Paystack clearing account. On Monday, Paystack pays the total of the three into your bank, less its fees. You record that payout against the Paystack clearing account with its fees: the clearing account is reduced by the full value of the three payments, the bank receives the net amount, and the fees are recorded as a cost. Nothing is left in clearing for those three payments, and the fees appear in your books instead of disappearing into a smaller deposit.
Using Paystack's and Flutterwave's payout lists
A payout can be recorded by hand, from the gateway's settlement report. For Paystack and Flutterwave there is a quicker route: the payout can be recorded from the gateway's own payout list. That saves retyping amounts and fees, and it means the figures in your books come from the gateway's record of what it paid you. Paystack's help article on getting your money explains how it pays your balance into your payout bank account on its settlement schedule, and how to read its payout reports.
Whichever route you use, keep the payout reference. It is what you will look for when you match the bank line.
Matching the payout in the bank
Bank lines in Achekam are matched by suggestion, and a person accepts each match. Match the payout deposit to the payout you recorded, not to the individual invoices. The invoices were already paid when the gateway confirmed each payment.
This is worth stressing, because the opposite habit causes trouble. Matching a bank receipt to a customer invoice in the bank reconciliation does not record the payment on the invoice. For a gateway payout, the payments are already on the invoices, so matching the deposit to invoices would point the bank line at money that has already been accounted for. The payout record is the right partner for the bank line.
Payments whose notification was missed
Occasionally a gateway's notification never arrives: a network fault, a misconfigured webhook. For M-Pesa, Paystack and Pesapal, Achekam still picks the payment up, because the server asks the provider about open payments on a schedule and while the pay page is open. The client's payment is recorded against the invoice even though the original notice was lost.
For other gateways, compare the gateway's own transaction list with your open invoices at least before each month end. A payment the gateway has but your books do not is the gap to close.
The month-end check
At month end, the balance on each clearing account should equal the payments your clients made that the gateway has not yet paid out. Check it against the gateway's dashboard:
- Matches: done.
- Clearing is higher: a payout has not been recorded, or a refund made in the gateway has not been recorded in your books.
- Clearing is lower: a payment may be missing, or a payout was recorded twice.
Refunds belong in this check too; see refunding a cancelled trip paid online. And if you collect in Kenya, payments through Pesapal adds a third gateway with the same pattern. Let each gateway's clearing account do its job, record every payout with its fees, and the deposit nobody recognised becomes one line nobody has to think about.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.