Hong Kong Merchant Settlement Reconciliation Guide

Hong Kong merchant settlement reconciliation matches the settlement credits on a bank statement to the underlying EPS, UnionPay, card-acquirer, and Alipay and WeChat Pay settlement reports. The credits arrive net, batched, and lump-sum, so a single deposit rarely maps one-for-one to a day's sales or to one processor report. The method that works is to extract both sides into one consistent spreadsheet and then match in tiers: exact settlement reference first, then same date and amount, then batched deposits, then timing differences, and finally fee, refund, chargeback, and currency variance buckets.

The reason the numbers never tie cleanly is that the bank credit is already net of everything. A card acquirer or wallet settles you the gross sales minus scheme fees, minus refunds, minus chargebacks, and the bank shows only the resulting deposit. Behind that one figure sit several line items in the settlement report, and each rail runs on its own settlement cycle, so the EPS lump sum, the UnionPay batch, and the Alipay payout for the same trading day land on different dates and as different amounts. The job is not to make the bank equal the sales; it is to explain every gap between them.

The settlement volume behind this is substantial. Hong Kong-issued credit cards recorded 393.96 million transactions worth HK$311.6 billion in the fourth quarter of 2025, alongside 53.7 million debit card retail and bill-payment transactions worth HK$69.6 billion, according to the Hong Kong Monetary Authority card payment statistics. For a retail-facing business, that volume becomes a daily stream of settlement credits that someone in finance has to reconcile against acquirer and wallet reports, line by line.

This guide is a workpaper design guide. It sets out the fields to capture from each side, the order to match in, and the Hong Kong-specific settlement mechanics that break a naive same-day, same-amount approach, so you can build a reconciliation that holds up rather than a spreadsheet of unexplained differences.

---

What to Capture From the Bank Statement Side

The bank side of the reconciliation needs a fixed set of columns, captured the same way every month. Pull these fields into the workbook for each settlement credit: transaction date, value date, description, reference, debit or credit, balance, currency, account, source file, and the original bilingual descriptor text wherever it carries meaning.

A few of these earn their place for reasons that are easy to miss. Value date and transaction date are not the same thing, and for settlement credits the difference is routine rather than exceptional: a batch closes on one day and the funds post on a value date a day or more later, so capturing both is what lets you reconcile against a settlement cycle instead of a calendar date. The reference and the description carry the settlement reference or terminal identifier that makes an exact match possible, which is why they cannot be discarded as noise. Currency has to be recorded per row, not assumed for the whole account, because one corporate account routinely receives HKD credits alongside RMB or other foreign-currency settlements, and the currency drives which variance bucket a difference belongs in later.

The bilingual descriptor deserves particular care. Hong Kong corporate statements describe credits in mixed English and Chinese, and the original wording often holds the only reliable link between a deposit and a specific rail or terminal. Preserve that text as it appears rather than translating or normalising it early; once the original descriptor is gone, the cleanest tie between a bank credit and a settlement report can go with it. Normalisation is a later step, after matching, not before.

The practical obstacle is that these statements rarely come out of the banking portal as clean rows. They are multi-page PDFs, sometimes dozens of pages of dense transaction lines, and a copy-paste into Excel mangles the columns. The rows have to be reconstructed from the PDF itself. This is where it helps to convert bank statements and settlement reports into structured spreadsheets rather than retyping them: upload the statement PDF, prompt for exactly the columns above, and the output preserves the original descriptors and per-row currency with a reference back to the source file and page, so any row can be checked against the original document. The same field discipline applies whatever bank issued the statement, whether you are working from a Standard Chartered or HSBC layout, and a worked example of the field choices sits in our guide to convert an HSBC Hong Kong statement to Excel. If you want to reuse the same column set on every run, save it as a bank statement extraction prompt so each month produces an identically shaped file.

What to Capture From EPS, Card, and Wallet Settlement Reports

The operational side has to land in the same shape as the bank side, or there is nothing to match against. For every settlement report, capture: payment rail or acquirer, batch date, clearing date, settlement date, gross sales, refunds, chargebacks, fees, net settlement, terminal or merchant ID, store or branch, currency, and settlement reference.

Net settlement is the figure that should turn up in the bank. Everything else explains how you got there. Gross sales minus refunds, minus chargebacks, minus fees produces the net payout, and a reconciliation that captures only the net has thrown away the columns it needs to explain the gap between sales and deposit. Capture all of them so that when a deposit is HK$2,000 short of the day's takings, you can point to the fee line and the refund line that account for it rather than recording an unexplained difference.

The rails do not present this information the same way. EPS transaction data, UnionPay and card-acquirer settlement reports, and Alipay and WeChat Pay clearing and settlement reports each lay out their batch, settlement, and fee detail in their own format, with their own column names and their own level of granularity. Capturing one common field set is what normalises them: once an EPS lump-sum credit, a UnionPay batch, and a WeChat Pay payout all carry the same thirteen columns, they can be matched against the bank on equal terms instead of being reconciled in three separate, incompatible ways. This is the practical core of UnionPay, Alipay, and WeChat Pay settlement reconciliation in Hong Kong: different reports, one structure.

Two fields do the heavy lifting in the next stage. The settlement reference and the terminal or merchant ID are what allow an exact tie between a settlement report and a bank credit, so treat them as mandatory rather than nice-to-have, and capture them verbatim. Where a report omits a settlement reference entirely, the terminal or merchant ID combined with the settlement date often becomes the fallback key.

These reports share the bank statement's export problem. Many download as PDFs or as exports that don't open as clean tables, so they too have to be turned into rows before any matching can start. Pulling every report into the shared settlement field set, rather than reconciling each one in its native layout, is what keeps both sides of the workbook in one consistent structure.

---

Matching Settlement Reports to the Bank Statement in Tiers

With both sides in consistent rows, the match runs in five tiers, worked in order. The sequence matters: each tier clears the cleanest matches first, so the residual that reaches the next tier is smaller and easier to reason about than if you tried to explain every credit at once.

Tier 1, exact settlement reference. Where the settlement reference appears on both the bank credit and the settlement report, match on it directly. This is the strongest tie because it is unambiguous, and on rails that carry the reference through to the bank descriptor it can clear the bulk of the month in one pass. Clear these first and set them aside.

Tier 2, same date and same amount. For credits where the reference didn't survive into the bank descriptor, match a net settlement figure to a bank credit of the same amount on the same settlement date. This catches the single-batch payouts where one report equals one deposit.

Tier 3, batched deposits. Hong Kong settlement credits are frequently aggregated, so one bank deposit is the sum of several settlement batches, or of a day's takings across more than one rail. Here you match a single credit to a group of settlement rows whose net amounts add up to it. Capturing net settlement per batch in the earlier stage is what makes this tier possible, because you are matching a sum rather than a single line.

Tier 4, timing differences. When a settlement and its bank credit fall on different dates, match on amount and settlement reference across the date gap rather than discarding the pairing. This is where value date versus settlement date does its work: the credit is the right one, it has simply posted on a value date later than the batch closed.

Tier 5, fee, refund, chargeback, and currency variance buckets. Whatever remains is a difference in amount, and a net-basis payout produces those differences predictably. Decompose each residual into named buckets that tie back to a settlement-report column: a fees bucket, a refunds bucket, a chargebacks bucket, and an FX bucket where the settlement currency differs from the deposit currency. A deposit that is short by a known fee amount is reconciled, not unexplained; the goal of this tier is that every remaining cent sits in a named bucket rather than in a catch-all difference line.

Each tier is driven by the fields captured earlier: settlement reference for tier 1, settlement date and net settlement for tiers 2 and 3, value date against settlement date for tier 4, and the fee, refund, chargeback, and currency columns for tier 5. This is the Hong Kong-aware version of the general close; if you want the underlying month-end logic in full, our month-end merchant deposit reconciliation process covers the generic deposit-matching workflow that this tiered method adapts to local rails.

Hong Kong Settlement Timing and Currency Quirks That Break Naive Matching

A same-day, same-amount match fails in Hong Kong for reasons that are specific to the local rails. Each of the mechanics below changes how a credit has to be matched, which is why they belong in a reconciliation method rather than in a list of payment brands.

EPS same-day lump-sum crediting. EPS transactions completed before the working-day cut-off are credited the same day as a single lump sum to the merchant's nominated Hong Kong bank account. That means one bank credit covers many EPS transactions and has to be matched as a batch in tier 3, never one-to-one against individual sales. Transactions after the cut-off roll into the next working day's lump sum, so a late-afternoon sale can settle on a date that looks wrong until you account for the cut-off.

Card-acquirer and UnionPay settlement cycles. Card and UnionPay settlements run on their own cycles, and those cycles are not necessarily the same length, so a single trading day's card takings and UnionPay takings can settle on two different dates and as two separate credits. Hong Kong card settlement cycle reconciliation therefore matches against each report's own settlement date rather than the shared transaction date, which is what keeps the two streams from being collapsed into one mismatched figure.

Alipay and WeChat Pay report timing. These wallets generate a clearing report and a settlement report on different days, with the clearing report typically produced a day ahead of settlement. The amount you reconcile against the bank is the settlement report, not the clearing report; matching the bank credit to the clearing figure will leave the dates and often the amounts out by a day's adjustments.

Public-holiday timing. Hong Kong public holidays push settlement and value dates outward, widening the gap between a sale and its credit. A deposit that appears several days after the trading day is usually a holiday-shifted value date, not a missing settlement, and treating it as a timing variance rather than an exception keeps the reconciliation clean.

HKD versus foreign-currency settlement. Where settlement is in RMB or another currency while the account reports in HKD, the settlement-report amount and the bank credit differ by the conversion. That difference belongs in the FX variance bucket; forcing it into a same-amount match in tier 2 will only produce a false mismatch.

Unattributable credits. When the bilingual descriptor is the only field naming the rail, a credit whose descriptor has been stripped cannot be assigned to any report and drops straight to the unmatched residual. Getting a dense bilingual statement into clean rows with that text intact, as in a Standard Chartered Hong Kong statement conversion, is what keeps those credits matchable in the first place.

Chargeback windows. Chargebacks can post long after the original sale, so a current month's deposit can be reduced by a chargeback relating to a transaction from weeks earlier. Because the reducing entry and the original sale sit in different periods, chargeback variance is its own bucket rather than a timing difference, and the settlement report's chargeback column is what lets you trace it back.

---

Turning the Reconciliation Into an Audit-Ready Workpaper

A reconciliation is only as good as its ability to be checked by someone who wasn't there when it was done. Three things make the workbook audit-ready. Every matched row traces back to a source file and page on both the bank side and the settlement side, so any figure can be followed to the document it came from. Every variance carries a named bucket and a reason, so a difference is an explained fee or chargeback rather than a number nobody can account for. And the unmatched residual is listed explicitly as its own set of rows, never quietly absorbed into a rounding line.

The consistent column structure is what makes this hold up at review. Because both sides share the same fields and the tiered match leaves a clear trail, a reviewer can take any bank credit, follow it to the settlement rows that compose it, and from there to the source file and page behind each figure without the preparer beside them. The reconciliation answers the reviewer's questions before they are asked.

Fixing the field sets and the tiered method also makes the work repeatable. The structure does not change from month to month; only the statement and the settlement reports do. That means the same workpaper runs every period, the matches that cleared cleanly last month clear the same way this month, and the only real work is on the residual variances, which is where a controller's attention should be. For a Hong Kong business, a reconciliation built this way slots directly into the records it already keeps, and it pairs naturally with the broader Hong Kong audit documentation requirements that govern how long and in what form those records are retained.