Double-Entry Accounting for Remittance: Why Every Transfer Should Post Itself

In the early months of a money transfer business, the finance function is often one spreadsheet and one careful person. Deposits come in, payouts go out, fees are added up at the end of the month, and the numbers more or less agree. Then volume grows, a second payout partner arrives, refunds and chargebacks start to appear, and "more or less" stops being good enough.

The fix is not a better spreadsheet. It is a ledger in which every transfer records its own accounting entries as it happens, using double-entry rules, so finance is reviewing a set of books rather than rebuilding one.

This guide walks through a transfer as journal entries, explains why entries are never edited, shows how chargebacks and recalls appear, and ends with a month-end checklist. Along the way we show how RemitSo's accounting engine does this. To set expectations: the platform posts the entries and keeps them traceable; your finance team still owns the chart of accounts, reconciles against bank and partner statements, and signs off the close.

Spreadsheets do not fail suddenly. They fail by accumulation.

• They are built after the fact. Someone exports transactions and rebuilds the position. Anything that happened between exports, such as a late refund or a recall, is missed until the next rebuild.
• They can be edited silently. A corrected cell leaves no trace. When an auditor asks why a balance changed, nobody can say.
• They mix things that should be separate. Bank fees, partner fees and promotional discounts end up netted into one "costs" line, which makes margin by corridor guesswork.
• They do not balance by design. A single-entry list can be internally consistent and still wrong. Nothing forces every movement to have a matching side.

At a few thousand transfers a month, close becomes a week of reconstruction, and "how much do we owe customers right now?" has no quick answer.

Double-entry is simple to state: every movement is recorded twice, as a debit in one account and an equal credit in another. Across the whole ledger, debits always equal credits. If they do not, something is wrong, and you know immediately rather than at month-end.

For a money transfer operator, the useful accounts are usually a small set:

• Bank (collection) — money received from senders.
• Customer funds owed — money you hold on behalf of senders until it is paid out. This is a liability.
• Partner prefunding or payable — what you have placed with, or owe to, each payout partner.
• Fee income and FX income — your revenue, kept separate.
• Bank fees, partner fees and offer discounts — costs, each in its own account.

The figures below are illustrative and simplified. A customer sends GBP 200 to a recipient abroad. You charge a GBP 3.00 fee. Your mid-market cost of the destination currency is such that the customer's rate includes a GBP 2.40 FX margin. The customer pays GBP 203.00 in total. Your bank charges GBP 0.20 to receive the payment, and your payout partner charges GBP 0.80 per payout.

After step 5, customer funds owed for this transfer is zero: 203.00 in, less 3.00, 2.40 and 197.60 out. That is exactly what you want. The customer is no longer owed anything; the partner has been given the value to deliver; your revenue (5.40) and your costs (1.00) each sit in their own accounts.

Now suppose the payout fails and the customer is refunded in full, including the fee, which is your policy for failed delivery. The ledger does not delete steps 3 to 5. It adds new entries that reverse them:

• Partner prefunding debited, customer funds owed credited, 197.60 (value returned from partner).
• Fee income and FX income debited, customer funds owed credited, 3.00 and 2.40.
• Customer funds owed debited, bank credited, 203.00 (refund paid), with the reason recorded.

Both the original entries and the reversals stay visible. Anyone reading the ledger can see that the transfer happened, that it failed, and how it was unwound.

The single most important rule in a transaction ledger is that history is not rewritten. If an entry was wrong, you post a reversing entry and then the correct one. The mistake and its correction both remain visible.

This matters for three reasons:

1. Auditability. An auditor or regulator can see exactly what happened and when it was corrected.
2. Trust between teams. Operations and finance are looking at the same history. Nobody can quietly "fix" a number.
3. Safety. Edits destroy evidence of errors and of misconduct. Reversals preserve it.

In RemitSo, entries are never edited; mistakes are reversed and both stay visible. The same principle runs through the rest of the platform. Refunds are recorded with a reason and history is never edited. Payouts are locked once approved, so what goes out is exactly what was approved, and approved payouts are never edited.

Manual corrections still happen: a bank charge the platform could not know about, a partner fee adjusted after the fact. In RemitSo they are posted as journals, listed newest first alongside the automatic ones, rather than typed over an existing entry. Reading the general ledger and entering a journal by hand are separate permissions, so you can give the whole finance team read access while only a named few can post corrections. That separation is worth more to an auditor than any general claim of control.

A balance you cannot explain is a liability in more than one sense. When a partner prefunding account looks GBP 1,000 lower than expected, finance needs to answer "why?" in minutes, not days.

The test of a good ledger is simple: pick any balance and drill down to the individual entries behind it, and from each entry to the transfer that caused it. If that path exists, investigations are quick. If it does not, every discrepancy becomes a project.

In RemitSo, you select any account in the chart of accounts to read the entries behind its balance. For a finance lead, that turns a question from a partner or auditor into a short look-up rather than an export-and-filter exercise.

Many operators know their revenue per transfer well and their cost per transfer only roughly. That is usually because costs are netted. A partner deducts its fee from the settlement, the bank deducts its charge from the deposit, a promo code reduces the fee, and all three disappear into a smaller number.

Keeping each cost in its own account changes the conversations you can have:

• Bank fees show whether a collection route is worth its cost.
• Partner fees show the true cost of each payout partner, which matters when you are choosing between two partners on the same corridor.
• Offer discounts show what promotions actually cost, rather than appearing as lower fee income.

In RemitSo, bank fees, partner fees and offer discounts each sit in their own account. Fees are set per currency and per payment instrument, with amount slabs and thresholds, and a fee rule is mandatory before a corridor can be activated, even when the fee is zero, so nobody launches a route with pricing nobody decided. Each fee rule carries a "next review due" date; when fees have gone three months without review, the "Pricing review due" alert tells the people subscribed to it. For finance, that means margin is visible from the first transfer on a new route and pricing does not quietly drift away from what the cost accounts show.

These three events cause most of the painful finance work in remittance, because they arrive after the transfer appears finished.

RemitSo flags chargebacks, bank recalls and double payments the moment they happen, as named alerts with their own subscribers: "Chargeback raised on a payment", "Bank took money back" and "Duplicate payment captured", plus "Deposit received but matched nothing" for credits with no transfer to attach to. Deposits are matched to what the customer declared, to the cent; anything unclear is held, and if the amount does not match, the money does not move. That last rule removes a whole class of reconciliation problems before they reach the ledger.

Where your licence allows, a wallet lets customers hold a balance and pay from it. From a finance point of view, a wallet balance is simply a customer liability with a name on it. If that number is calculated separately from the ledger, sooner or later the two will disagree, and the customer will see the wrong one.

The safer design is for wallet balances to be read directly from the ledger. In RemitSo, where wallets (an optional add-on) are licensed, wallet balances come straight from the operator's accounts and cannot go below zero, and funding a wallet requires a verified identity. Customers see the balance update live in the customer app; finance knows that what customers see and what the books say are the same figure.

An automatic ledger does not remove month-end. It changes what month-end is for: confirming and explaining, rather than building. A practical sequence:

1. Confirm the trial balance balances. With double-entry it should; if not, stop and investigate.
2. Reconcile bank accounts against bank statements. Differences should be timing items you can name.
3. Reconcile each partner account against the partner's statement. Click into any difference to find the transfers behind it.
4. Review customer funds owed. It should equal transfers received but not yet paid out, plus wallet balances where offered.
5. Review held items: unmatched deposits, double payments, open chargebacks and recalls. Each needs an owner and a next step.
6. Review reversals posted in the month and their reasons. Patterns here point to process problems.
7. Review cost accounts by partner and route against what you expected.
8. Export for your accounting system and sign off.

• Every payment, payout, refund, fee and FX movement posts automatically as it happens.
• Debits always equal credits, and you would know within the day if they did not.
• Entries are never edited; corrections are reversals with a reason.
• Any balance can be traced to the transactions behind it.
• Bank fees, partner fees and discounts each have their own account.
• Deposits that do not match the declared amount are held, not released.
• Chargebacks, recalls and double payments are flagged on arrival, not at month-end.
• Approved payouts are locked and never edited.
• Wallet balances, where offered, are read from the ledger, not calculated separately.
• Manual corrections are posted as journals by people with permission to do so, and reading the ledger is a separate right from writing to it.

RemitSo's accounting is a double-entry engine built into the admin panel. It posts and protects the entries; your finance team owns the chart of accounts, reconciliations against external statements and the close.

• Every payment, payout, refund, fee and FX movement recorded automatically, so the books are current at any moment and month-end is review, not reconstruction.
• Entries never edited; mistakes reversed with both visible, so auditors and regulators see a complete, honest history.
• Chart of accounts with every balance traceable to its entries, and journals newest first with manual corrections posted there, so partner and auditor questions are answered in minutes.
• Separate permissions to read the general ledger and to post a manual journal, so access to the books does not mean the ability to change them.
• Bank fees, partner fees and offer discounts in their own accounts, plus fee review dates and a "Pricing review due" alert, so you know your real margin by route and partner and keep it current.
• Deposits matched to the cent, with anything unclear held, so mismatched money never moves into a transfer.
• Chargebacks, bank recalls and double payments flagged the moment they happen, so finance hears about them on the day, not on the statement.
• Payouts locked once approved, so what leaves is exactly what was approved.
• Wallets, where your licence allows, read from the operator's accounts and never below zero, so what customers see matches the books.

If you are comparing the cost of building this yourself with a white label platform, the pricing page sets out setup and monthly fees, and teams moving off an existing system can start from the enterprise and migration page. To see the ledger with sample transfers, book a demo.