Payment System Reconciliation Process and Functionality Overview

1. Settlement Reconciliation System

All financial services offered by a payment company are built on the banking fund system; each account in the company's accounting system corresponds one‑to‑one with a deposit in the bank. To ensure accurate conversion between real and virtual accounts, the payment company must promptly reconcile funds with the bank, and all fund matching relies on the bank's system.

1.1 Fund Inflow Reconciliation with the Bank

Funds flowing into the payment company are controlled by the bank, which notifies the company of recharge instructions in real time. Each night the bank aggregates the day's transactions and credits the payment company's collection account, providing a settlement file that the company uses to match against its business data.

If the reconciliation results match, there is no issue. If they do not match, two possible situations arise: (1) the bank reports more recharge details than the payment company, leading to temporary pending entries; (2) the bank reports fewer recharge details than the payment company, potentially causing a loss that also requires temporary pending entries.

1.2 Fund Outflow Reconciliation with the Bank

When a customer requests a withdrawal, the payment company initiates a batch withdrawal request to the bank, which deducts the amount from the company's bank deposit account. The bank later provides a settlement file indicating success or failure.

For failed withdrawals, the payment company directly refunds the customer’s account without involving the reconciliation center.

2. What Is Reconciliation?

In accounting, reconciliation ensures that ledger records are correct by verifying that the books, vouchers, and accounts are consistent. In a payment institution, reconciliation matches the system‑saved accounting entries with the bank‑provided settlement flows and files to ensure consistency between the system’s data and the bank’s actual settlement results.

2.1 Definition of Fund Reconciliation

It is the process of verifying that each order’s bank‑processed result aligns with the system’s business processing result, ensuring correctness, authenticity, and consistency of the accounts.

2.2 Role of the Reconciliation Center

The reconciliation center is the main module handling settlement reconciliation. It receives data from the accounting system and the settlement system, matches bank settlement flows with internal entry flows, and checks that the balance changes in the bank’s actual account and the payment system’s internal account are balanced.

Matched and verified flows are stored in historical bank‑flow and historical entry‑flow repositories.

3. Reconciliation Content and Data Sources

Step 1: Verify entry flows against settlement flows to ensure each order’s bank result matches the system’s business result. Step 2: Compare the reconciliation summary with the bank’s statement to confirm that all business‑related bank results align with the actual funds received.

3.1 Reconciliation Business Process

See the accompanying flowchart images for a visual representation of the reconciliation workflow.

3.2 Main Functions of the Reconciliation Center

The center handles various fund‑change types such as recharge, withdrawal, failed withdrawal, charge‑back, ticket refund, foreign exchange purchase, loan disbursement, loan repayment, and failed repayment. All these flows are sent to the reconciliation center after being recorded in the accounting core.

Key capabilities include:

(1) Full‑day settlement support: bank settlement flow → flow reconciliation → flow classification → summary confirmation → automatic pending entry → settlement confirmation → operator balancing → daily closing and bank balance registration. (2) Comprehensive reporting: reports by entry date, bank date, settlement date, bank account balance, and unreceived funds. (3) Daily cut‑off service: after confirmation, data moves to historical tables for easy aggregation. (4) Peripheral business support: bank account management, internal‑account mapping, financial system interaction, and error‑account verification.

3.3 Reconciliation Logic

(1) One‑to‑One Reconciliation

Each entry flow and bank flow has a single record. This applies to B2C/B2B online banking recharge, VISA, normal withdrawal, certified withdrawal, corporate‑bank interconnection withdrawal, etc.

Standard: (settlement channel + order number + amount) OR (bank name + business code + order number + amount).

(2) Many‑to‑Many Reconciliation

Multiple entry flows with the same order number, channel, and amount are matched against multiple bank flows on a first‑come‑first‑served basis. This applies to charge‑backs.

(3) One‑to‑Many Reconciliation

Multiple entry flows are matched against a single bank flow, e.g., foreign acquisition transactions.

3.4 Reconciliation Functions

(1) Internal Flow Matching

For withdrawals, the system generates both a debit flow and a corresponding credit flow; these are matched internally without involving the bank reconciliation center.

(2) Reconciliation Summary Confirmation

Successful reconciliations move flows to historical tables; mismatched amounts are manually corrected or deleted and re‑reconciled.

(3) Flow Classification and Pending Entry Aggregation

Multi‑account flows can be classified and aggregated for pending entry processing, with specific business codes allowed for pending entries.

(4) Settlement/Entry/Historical Flow Management

Settlement flow management allows query, modification, deletion, and addition of flows. Entry flow management permits query and download but prohibits modification or deletion to prevent tampering. Historical flows are read‑only for query and download.

(5) Bank Balance Entry

Operators can record actual bank balances for each account, which are later verified and used for balance matching.

(6) Internal Account Ledger

Non‑bank pending internal accounts (e.g., settlement funds, interest, fees) can be recorded without generating downstream vouchers.

(7) Pending Income Posting

Bank pending income is posted with a voucher that serves as the source for subsequent settlement actions.

(8) Pending Income Confirmation

Pending income vouchers can be settled, with automatic handling of any residual amounts.

(9) Pending Expense Posting

Bank pending expenses are posted similarly, with strict validation rules.

(10) Pending Expense Confirmation

Pending expense vouchers are settled, with automatic reposting of any shortfalls.

4. Unexpected Data Recovery Logic

4.1 Recovery Scenarios

Three main cases are considered: (1) duplicate payments for the same internal order; (2) payment failure with amount mismatch; (3) successful payment with amount mismatch due to delayed bank notifications.

4.2 Reconciliation and Exception Recovery

(1) Use Merchant‑Successful Orders as Reference

If the merchant shows a successful order while the backend is initial or failed, update the backend to successful; otherwise, leave unchanged.

(2) Avoid Duplicate Recovery

Recover T‑day orders on T+1 day and do not re‑download them thereafter.

(3) Time‑Based Differences

Bank cut‑off times differ, leading to three situations: merchant has data but backend does not, backend has data but merchant does not, and both have data. The first two are considered time‑based differences.

--- END ---