Matching Deposits to the Cent: Stopping Wrong Amounts Before Money Moves

Every transfer starts with a promise and a payment. The customer declares how much they are sending; then money arrives in your account. Most of the time the two agree. When they do not, and the transfer goes ahead anyway, a money transfer operator can end up paying out money it never received, or moving money it cannot explain. Both are expensive, and the second is a compliance problem as well as a financial one.

This guide is for finance and compliance teams at money transfer operators.

RemitSo is one way to put these controls in place. Its admin panel matches deposits to what the customer declared, to the cent; anything unclear is held, and if the amount does not match, the money does not move. Chargebacks, bank recalls and double payments are flagged the moment they happen, and every movement lands in a double-entry ledger. The platform does not decide each case: your people still review held deposits, contact customers, decide on refunds and own the policy. This guide sets out how to make those decisions consistently.

It is tempting to think of deposit mismatches as a reconciliation chore for the end of the month. They are better understood as a control that has to work before any money leaves.

The loss case

If a customer declares 500.00 but only 450.00 arrives, and the platform pays out on the basis of the declaration, the operator has funded the 50.00 gap from its own money. Recovering it from the customer afterwards is slow and often unsuccessful. Repeated across a busy corridor, small gaps become a real cost.

The anti-money laundering case

Overpayments are the subtler risk. A customer who declares 500.00 and sends 5,000.00, then asks for the difference to be refunded or sent onwards, is following a pattern regulators and compliance teams recognise. Money comes in through one route and leaves through another, with the operator's account in the middle. Even when the explanation is innocent, the operator needs to see it, record it and decide on it deliberately.

The limits case

Limits and risk checks are usually evaluated against the declared amount. If a much larger sum arrives than was declared and checked, the controls have effectively been bypassed. The transfer that passed screening was not the transfer that was funded.

Matching is a comparison of two records: the customer's declaration in the app, and the credit that appears in your bank account. A robust match considers more than the number.

• Amount, to the cent. Not "close enough". A tolerance, however small, creates a gap that someone will eventually find.
• Currency. A credit in the wrong currency is not a match, even if the converted value looks similar.
• Reference. The payment reference the customer was told to use, which ties the credit to a specific transfer.
• Payer. Whether the money came from an account in the customer's name, where your policy requires it.
• Timing. Whether the credit arrived within the window you expect for that payment method.

When all of these line up, the transfer can move on automatically. When any of them does not, the right default is to hold, not to guess. A held deposit costs some time. A wrongly matched deposit can cost the full amount, and an explanation to a regulator.

In RemitSo, this is how deposit matching works in the admin panel: deposits are matched to what the customer declared, to the cent, and anything unclear is held. For finance teams, the benefit is that the platform never pays out on a promise; for compliance teams, it means a mismatch always reaches a person.

The figures below are illustrative. Three customers each declare a transfer of 500.00 in their app. Here is what arrives, and what should happen next.

Case A: exact match

The 500.00 arrives with the right reference, from the customer's own account, in the expected currency. The transfer proceeds under your rules. Nobody needs to look at it, which keeps the team's attention for cases that need it.

Case B: 5,000.00 arrives against a declaration of 500.00

Almost certainly an extra zero, but possibly something else. The platform should not pay out 500.00 and leave 4,500.00 unexplained, nor pay out 5,000.00 that was never declared or checked.

The deposit is held. A compliance reviewer looks at the customer's history and usual pattern, and someone contacts the customer. If it is a simple mistake and the profile supports it, the outcome under your policy is either a full refund with a recorded reason and a request to send the correct amount, or a refund of the excess with the 500.00 proceeding. If the explanation is unconvincing, or the customer wants the excess sent to a third party, it becomes a compliance case.

Case C: 50.00 arrives against a declaration of 500.00

The opposite error: a missing zero, or a partial payment. The platform holds the deposit and nothing moves. The team contacts the customer. If they intend to send the remaining 450.00, you may allow a short window; many operators find it cleaner to refund the 50.00 with a reason and ask for a new transfer. What should never happen is a payout of 500.00 funded by 50.00.

Matching protects the moment money arrives. Some problems appear afterwards, when money that looked settled is pulled back or turns up twice.

Chargebacks

Where customers pay by card, a chargeback can reverse the payment weeks later. If the payout has been made, the operator carries the loss unless it can recover the funds. Knowing immediately lets the team respond to the dispute, review the customer's other transfers and decide whether to restrict the account.

Bank recalls

A sending bank may ask for funds back, for example over suspected fraud on the payer's account. That is a strong signal about the source of funds, and it needs a compliance view as well as a finance one.

Double payments

Customers sometimes pay twice for one transfer, for instance retrying a payment that actually went through. The second payment should not fund a second payout automatically. It should be flagged and refunded with a reason, or applied to a new transfer only with the customer's agreement.

Money that matches nothing, or arrives too late

Two quieter cases deserve the same treatment. A credit can arrive with no usable reference and match no transfer at all; left alone, it sits in your account as customer money nobody is tracking. And a customer can pay after the transfer attempt has been cancelled or has expired, so the money arrives for something that no longer exists. Both need an owner, a decision (match it to the right transfer, or refund it with a reason) and a time limit.

RemitSo raises each of these as a named alert, sent to the people subscribed to it: "Deposit received but matched nothing", "Duplicate payment captured", "Payment received on closed attempt", "Bank took money back" and "Chargeback raised on a payment". The benefit is time and clarity: the alert says what happened in plain language, so finance and compliance know which of these cases they are looking at before they open the record, and the earlier they know, the more options they have.

Refunds are where history is most often lost. A refund made without a reason looks, a year later, exactly like a refund made to move money out. Auditors, examiners and your own compliance team need to be able to tell them apart.

Every refund should record:

• The original deposit it relates to.
• The amount refunded, and whether it is the full deposit or part of it.
• The reason, in words, such as "overpayment, customer confirmed typing error" or "double payment, second credit refunded".
• Who made the decision, and when.
• Where the money went, which should normally be back to the account it came from.

In RemitSo, refunds are recorded with a reason and history is never edited, and the matching ledger entries sit in the accounting journals, newest first. That gives compliance teams a refund record that stands up to review without reconstruction.

Deposit matching makes sure the right amount came in. The other half of the control is making sure the right amount goes out. If a payout can be edited after approval, all the checks before it, from matching and screening to risk rules and approval, can be undone with a single change to the amount or the recipient.

The safer rule is simple: once approved, a payout is locked. What goes out is exactly what was approved. If something needs to change, the partner is asked to stop or return the payout where they can, and once it is cancelled or returned a new one goes through approval. RemitSo works this way: approved payouts are never edited. For finance, it means the amount paid out always ties back to an approved instruction. For compliance, it removes a route by which a payout could be redirected after the checks were done.

A good ledger tells the story of every deposit without anyone having to piece it together from emails and spreadsheets. Using the scenario above, here is what finance should be able to see.

• Case A: the customer's payment received, the fee recognised, the FX movement and the payout, each as its own entry, all balancing.
• Case B: the 5,000.00 received and held, then either a full refund of 5,000.00 with its reason, or a refund of 4,500.00 and the 500.00 proceeding. Both the receipt and the refund remain visible.
• Case C: the 50.00 received and held, then refunded with its reason. No payout entry exists, because no payout was made.
• A chargeback after payout: the original entries stay as they were; the chargeback is recorded as a new reversing entry, so the loss is visible and traceable to the transfer.

RemitSo's accounting is a double-entry engine. Every payment, payout, refund, fee and FX movement is recorded automatically. Entries are never edited; mistakes are reversed, and both the original and the reversal stay visible. Finance can select any account in the chart of accounts to read the entries behind its balance, manual corrections are posted as journals rather than edits, and bank fees, partner fees and offer discounts each sit in their own account. The benefit is that month-end becomes a review rather than a reconstruction, and an auditor's question about a specific deposit can be answered from the ledger directly.

1. Does the amount received match the declared amount to the cent?
2. Is it in the expected currency, with the expected reference?
3. Did it come from an account in the customer's name, where your policy requires that?
4. Is anything unclear? If so, is it held rather than guessed?
5. For overpayments: has compliance looked at the customer and the explanation?
6. For underpayments: is there a written policy on waiting versus refunding?
7. Are chargebacks, recalls, double payments, unmatched credits and payments on closed attempts reaching the right people immediately?
8. Does every refund record a reason, the decision-maker and the destination?
9. Is every approved payout locked, so that a change means a new payout through approval rather than an edit?
10. Can every case be traced in the ledger without editing any entry?

RemitSo puts these controls into the platform, so finance and compliance teams spend their time on the exceptions rather than on finding them. Your team still reviews held deposits, speaks to customers and decides on refunds and escalations.

• Deposits matched to the cent: money in is matched to what the customer declared, and anything unclear is held, so a wrong amount never funds a payout. See the admin features.
• Named deposit alerts: "Deposit received but matched nothing", "Duplicate payment captured", "Payment received on closed attempt", "Bank took money back" and "Chargeback raised on a payment" each go to their own subscribers, so the right person knows the moment it happens.
• Refunds with a reason: every refund is recorded with why it was made, and history is never edited, so refund decisions stand up to audit.
• Payouts locked once approved: what goes out is exactly what was approved, and approved payouts are never edited, so checks cannot be undone after sign-off.
• Double-entry accounting: every movement is recorded automatically, mistakes are reversed rather than edited, and any balance can be clicked through to its transactions, so finance can explain any number.
• Customer clarity: before paying, customers see the rate, the fee and exactly what arrives, which reduces the confusion behind many wrong amounts in the first place. See the customer app features.
• Limits and risk indicators: AML rules set how much a customer may send in each period and which documents they must provide as totals grow, and 46 ready-made risk indicators, including card checks such as address and CVC verification, chargeback history and fraud-related declines, give compliance the context to judge an unusual deposit.

For timelines and costs, see getting started and white label pricing, or book a demo.