Settlement and Reconciliation: The Bookkeeping Side of Cross-Border Payments

Accepting Chinese payments is a solved problem, and we've written about how to accept them and how to price in RMB. What those posts don't cover is what happens a month later, when somebody sits down with the bank statement and the booking list and tries to make them agree. That is where the real friction lives, and almost nobody is warned about it before their first busy season.

The short version: cross-border payouts arrive batched, with fees already deducted, converted at a rate struck at a moment you didn't choose, and refunds often come out of a later batch. So the number in your bank account matches no single order, and it never will. Reconciliation works at the payout level rather than the order level, and it is only possible if you captured a few identifiers at the moment of sale. Four fields, recorded at booking, remove most of the pain later.

Four reasons the numbers never match

Batching. One deposit in your account covers many orders. The bank line says one figure; your booking list says forty.

Netting. Fees are taken before the money is sent, so what you receive is already a net figure. If your records only ever store what landed, you have quietly lost the gross number and the cost of collection along with it.

Conversion. The amount charged in RMB and the amount that reaches your account in your own currency are two different figures, struck at two different moments. Neither is wrong; they just don't equal each other, and the difference is not a rounding error.

Timing and reversals. A booking taken at the end of one month can settle in the next. A refund issued today may be deducted from a payout weeks away. Both mean that the period a transaction belongs to depends on which question you're asking.

Reconcile the payout, not the order

The instinct is to match each booking to a bank line. That approach fails immediately and people usually conclude something is broken.

Work at the payout level instead. One payout equals a set of transactions, minus fees, plus or minus adjustments. Your provider's statement holds that breakdown; your side needs something that joins to it. Once the payout balances, the individual orders inside it take care of themselves.

What to capture at the moment of sale

Almost every reconciliation problem is really a missing-identifier problem, and identifiers can only be captured while the transaction is happening.

• The provider's transaction ID, stored on your own booking record. This is the join key between two systems that otherwise share nothing. Capturing it costs one field and saves hours.
• The amount charged, in the currency it was charged in. Not the converted figure, and not the figure that later arrived.
• The fee as its own number. If it only exists as the difference between two other numbers, it isn't in your books, and you cannot see what collection is costing you.
• The payout reference, added once the money arrives, so a booking can be traced to the deposit it was paid in.

Two dates, and they are not interchangeable

A booking has a transaction date and a settlement date, and in a busy month they land on either side of a month boundary often enough to matter.

Which one governs depends on the question. Bank reconciliation follows settlement, because that's when money moved. Revenue and tax treatment follow rules that are not yours to invent. Decide once how you're handling it, write it down, and stop re-deciding every quarter.

Refunds are where it gets untidy

A refund is rarely a clean reversal. It may be deducted from a future payout rather than returned separately, the conversion may differ from the original, and fees may or may not come back.

The habit that keeps this manageable is recording every refund against the original transaction ID rather than as a standalone negative amount. A refunded booking then has a complete history in one place instead of two unrelated entries that happen to be similar sizes. The policy side of refunds is a different question, and we covered it in refunds, deposits and no-shows.

What to ask your provider for, once

Before your first busy period, not during it:

• A downloadable statement with a per-transaction breakdown.
• The fee shown per transaction, not only as a monthly total.
• The rate applied and when it was struck.
• A payout reference that also appears on the bank line, so the two can be matched without guessing from amounts and dates.

If a provider cannot supply those, that's worth knowing before you build a season's bookkeeping on top of them.

The boundary of this post

These are record-keeping habits, not accounting or tax advice. How foreign-exchange differences are treated, how cross-border income is reported, and what your VAT or GST obligations are all depend on where you are registered, and those questions belong with your accountant.

What you can do is make their job possible. An accountant given per-transaction records with a join key will sort out the treatment. An accountant given a bank statement and a booking list with nothing connecting them will bill you for the archaeology.

Where CN1X fits

Setting up WeChat Pay and Alipay with cross-border settlement is part of what we do, so this is our problem as much as yours: if the payout statement that reaches you is not joinable, we have handed you the archaeology this post describes. Availability, pricing and confirmation stay with you, as they do in everything else we build.

Where you already have a provider, we test the path end to end rather than replace it. Where you do not, we set it up and hand over the statement format alongside it.

What we can do is make sure the record that reaches you is joinable: the enquiry or booking arriving in your inbox with the product, the date, the party size and a source reference already on it, so that when the payout lands there is something on your side to match it against. If you want to talk through what your booking record should carry before the season starts, tell us how you take payment now and we'll say what we'd add.