Why Mastering Accounting Architecture Is the Key to Seamless Payment Systems

1. Accounting Implementation Principles

During and after a transaction, accounting work begins; as the foundation of payment, its design philosophy, standards, and principles are crucial. This article covers ten aspects including accounting principles, account subsystems, hot accounts, account merging, accounting day‑cut, marketing accounting, and settlement models.

1.1 Abstracting Ability from Scenarios

Understanding accounting starts from customer needs and scenarios; all system design originates from requirements.

External customer demands shape accounting services, while internal demands (settlement, operations, finance) define internal accounting services.

Based on these demands, a service matrix for core accounting is built.

1.2 Overall Accounting Architecture

The architecture must view the whole system, especially its relationships with external systems such as transaction, payment, and settlement systems.

1.2.1 Accounting Relies on External Drivers

Various systems generate accounting business and call the core accounting service via defined interfaces.

Payment core registers channel clearing accounts;

Transaction core registers merchant pending settlement and marketing entries;

Settlement core registers merchant settled, profit sharing, channel cost, merchant fee accounts;

Payout core registers payouts and refunds;

Reconciliation core registers cleared and settled channel accounts.

1.2.2 Unified Accounting Interface

All business accounting requests can use a unified interface, but different accounting types may need differentiated parameters (e.g., acquisition, payout, settlement, authentication), managed via configurable protocols.

1.2.3 Accounting Voucher Generation

After generating business flow records, the accounting system creates vouchers based on rules. For a 2001 acquisition flow, two voucher rules are applied: one for principal receipt and another for fee transfer.

1.2.4 Real‑Time Fund Processing

Specific voucher lines may require immediate fund handling, updating merchant fee accounts in real time.

1.2.5 Periodic Voucher Summarization

High‑volume e‑commerce receipts need voucher aggregation to keep accounting entries manageable while preserving traceability.

1.2.6 Document Relationships

Business documents, after being submitted to the accounting core, generate internal documents; their relationships are illustrated.

2. Account Subsystem

Accounts reflect accounting subjects and are the foundation of payment transactions, similar to a battery for a phone.

2.1 Account Ecology and Principles

Accounts can be classified by financial perspective (assets, liabilities, equity, profit‑loss, common) or by usage (deposit, intermediate, virtual). Institutional classification includes central bank clearing accounts, bank settlement accounts, payment‑institution accounts, and corporate virtual accounts.

2.1.1 Five Types of Settlement Accounts

Customer accounts, settlement transition accounts, clearing accounts, cleared receivable/payable accounts, and deposit accounts.

2.2 Account System Overview

An account should contain name, date/summary, debit/credit amounts with balances, and voucher number. From a business view, three core pieces of information are needed: balance, transaction flow, and transaction details.

Balance – how much money the account holds.

Flow – detailed inbound/outbound records.

Transaction – how money is deposited or withdrawn.

2.2.1 Account Types

Assets, liabilities, profit‑loss, and common accounts; business‑oriented naming (e.g., merchant settlement account, reserve account) improves recognizability.

2.2.2 Account System Functions

Core modules include account configuration, management, information, permissions, and transaction handling.

Account owner (person, enterprise, internal line);

Account hierarchy tree;

Account type;

Account name;

Balance;

Transaction flow;

Services such as opening, closing, credit, debit, adjustment.

2.2.3 Solution Based on Accounts

Accounts serve as a low‑level service; building various financial solutions (wallets, cashiers, corporate settlement platforms) on top of them enables flexible product development.

3. Accounting as a Breakthrough Point

Payment product managers often encounter new business forms that ultimately touch on funds; solving them at the accounting layer simplifies product design, reduces reliance on finance/legal, and clarifies the entire workflow.

4. Hot Accounts

Hot accounts arise when a single account receives a high volume of concurrent updates, exceeding its processing capacity and causing performance issues.

4.1 Understanding Hot Accounts

When update frequency exceeds ~10 updates per second and latency >1 s, the account is considered hot. Typical scenarios include Double‑11 sales, WeChat red packets, flash sales, etc.

4.2 Hot‑Account Solutions

Limit or throttle concurrency (hot‑valve).

Aggregate detail entries and batch‑update balances.

Queue processing (buffer).

Split into multiple sub‑accounts to distribute load.

Cache intermediate balances and periodically sync to DB.

Pre‑processing layer (front‑end buffer).

Hardware scaling.

5. Account Merging

When multiple business lines require separate guarantee‑deposit accounts, merging them into a unified account reduces user friction and accounting complexity. The process involves consolidating virtual accounts, accounting subjects, and underlying bank accounts.

6. Reverse‑Deduction ("倒扣") Model

Instead of requiring users to pre‑pay a guarantee, the platform deducts the amount from future earnings until the total is covered. Two accounting models are used: settlement‑order based and account‑based.

6.1 Two Accounting Modes

Settlement‑order mode records deductions per settlement order; account mode creates a dedicated “deduction” account for each merchant.

7. Sub‑Account Strategy

Complex business scenarios benefit from splitting a main account into multiple sub‑accounts (e.g., for different transaction types, credit limits, or financial products). This improves scalability and clarity.

8. Day‑Cut (日切) Principle

Day‑cut switches the accounting date, separating data into daily partitions. It enables daily settlement, interest calculation, and batch processing without interrupting 24/7 transaction flow.

8.1 History of Day‑Cut

From manual ledgers to modern systems, day‑cut evolved from heavy, batch‑only processes to lightweight, isolated mechanisms using dual‑balance or shadow‑account techniques.

8.2 Day‑Cut Overview

Day‑cut defines a cut‑off time (often at night) after which new transactions belong to the next accounting day. It supports real‑time trading while allowing batch day‑end processing.

8.3 Day‑Cut Challenges

24/7 transaction continuity.

Coordinating multiple systems (transaction, payment, settlement, accounting).

Ensuring data consistency across cut‑off.

8.4 Dual‑Balance Method

Each account stores a current balance (real‑time) and a previous‑day balance (static). Updates adjust the appropriate balance based on whether the last update date matches the current accounting date.

8.5 Shadow‑Account Parallel Method

During the cut‑off window, a shadow account records new transactions while the main account remains static; after cut‑off, shadow entries are merged back.

9. Marketing‑Related Accounting

Coupons and discounts are treated as marketing expenses. Platform‑issued coupons are recorded as platform marketing costs; merchant‑issued coupons are recorded as merchant liabilities. Accounting entries differ based on who issues the coupon and whether the coupon is purchased.

9.1 Coupon Accounting Basics

When a user applies a coupon, the payment amount to the channel decreases, and the coupon issuer bears the subsidy.

9.2 Coupon Accounting Cases

No coupon: full amount recorded as merchant revenue and platform commission.

Platform coupon: platform marketing expense recorded.

Shared coupon cost: portion allocated to merchant liability.

Merchant coupon: merchant marketing liability recorded.

Purchased coupon: revenue recorded at sale, subsidy recorded at usage; net effect reconciled at period end.

10. Settlement Accounting Implementation

The settlement process involves four data stages (accounting, payment, clearing, settlement) and three reconciliation layers (transaction, fund, accounting). Five core accounts (merchant settlement, merchant clearing, clearing‑in‑transit, cleared bank receivable/payable, bank deposit) enable end‑to‑end clearing.

Key accounting steps include:

Payment transaction recording (debit clearing‑in‑transit, credit merchant pending).

Channel clearing reconciliation (adjust clearing‑in‑transit and bank receivable).

Transaction error handling (platform补单).

Merchant settlement (debit merchant pending, credit merchant settlement).

Fund settlement (debit bank receivable, credit bank deposit).

Short‑fall/long‑fall handling (generate and clear short‑fall vouchers).

Through these accounts and voucher flows, the system achieves accurate, end‑to‑end settlement and clearing.