7 Policies to Set Before Building an AI Settlement System

Settlement is not a simple subtraction function. It is a ledger system that determines the rights and obligations for each order, separates funds that the platform must hold or pay out, and tracks refunds, disputes, taxes, and transfer failures.

Generative AI can help write code and tests, but it cannot be the party responsible for settlement policies. If policies are undefined, AI may create plausible defaults or omit exceptions, potentially resulting in overpayments, duplicate payments, tax errors, or liquidity incidents.

Principles Confirmed by the 2024 TMON and WeMakePrice Crisis

The large-scale non-payment of sales proceeds by TMON and WeMakePrice in 2024 demonstrated how severely delayed settlements can cause cascading harm to sellers and consumers. However, the cause of the crisis should not be attributed solely to long settlement cycles. Multiple factors must be considered together, including fund management, liquidity, governance, and internal controls.

The key lessons for operators are clear.

• Do not treat unpaid sales proceeds as company cash that can be used freely.
• The longer the settlement cycle, the greater the unpaid balance exposed to a single disruption or liquidity shortage.
• Reconcile sales proceeds balances with funds actually held on a daily basis.
• Disclose settlement terms and reasons for delays transparently to sellers.
• Review the relevant laws, contractual structure, and scope of PG services separately.

The legal ownership and protection of sales proceeds may vary depending on the transaction structure. Therefore, while maintaining day-to-day vigilance that these are “other people’s money,” actual accounting and legal treatment must be determined according to contracts and current laws.

7 Settlement Policies to Define Before Implementation

1. Settlement Eligibility Date and Payment Cycle

First, define when an order becomes eligible for settlement. If only the order date or payment date is used, amounts that may be canceled or returned before delivery could be included in payouts.

For typical product transactions, the following flow can be designed.

1. Payment authorization
2. Delivery completion
3. Purchase confirmation or automatic confirmation after the agreed period
4. Check for returns, disputes, or anomalous transactions
5. Finalize settlement eligibility
6. Include in payout batch
7. Complete transfer and reconciliation

The following items must be determined.

• The event that establishes settlement eligibility for each transaction type, such as products, digital content, and services
• The period until automatic purchase confirmation and when that period begins
• Daily, weekly, or monthly payout cycles
• How weekends and public holidays are handled
• The settlement cutoff time and the batch to which transactions after the cutoff belong
• Minimum payout amount and whether small balances are carried forward
• Whether different cycles are permitted by seller tier
• A procedure for confirming that statutory or contractual payment deadlines are not exceeded

The settlement eligibility date and the actual payment date must be distinguished. For example, eligible_at is the time when the payment conditions are satisfied, scheduled_payout_at is the time when the payment is included in a payout batch, and paid_at is the time when a successful transfer is confirmed.

2. Fee Calculation and Settlement Statements

If sellers are shown only the final payout amount, verification is difficult and inquiries and disputes increase. Both order-level details and period-based totals are required.

The fee policy must also specify the calculation basis. It must determine whether the basis is the pre-discount sales price or post-discount payment amount, whether shipping fees and VAT are included, and how fees are reversed for partial refunds.

It is safer not to calculate monetary amounts using floating-point data types. For currencies such as the Korean won, whose smallest currency unit is an integer, store amounts as integers. When foreign currencies or decimal calculations are required, use fixed-point data types and currency-specific rounding rules.

3. Refunds and Negative Settlements

An order that has already been paid out to a seller may later be refunded. In that case, the refund amount and refundable fees must be recorded in the adjustment ledger and deducted from the next payout.

For example, if the scheduled settlement amount for the current period is KRW 300,000 and the refund-related deduction for a previous order is KRW 400,000, it can be handled as follows.

• Current payout amount: KRW 0
• Unrecovered balance: negative KRW 100,000
• Amount carried forward to the next settlement: KRW 100,000 deduction

The policy must include the following items.

• How the product price, shipping fees, and fees are allocated for partial refunds
• The carry-forward period and offsetting order for negative balances
• How to recover funds from sellers with no sales for an extended period
• Contractual grounds for requiring a deposit or reserve
• A procedure for checking outstanding obligations before seller withdrawal
• How to make reversing entries when a refund is canceled or a dispute outcome changes

Do not overwrite existing transaction records; link the original transaction to the adjustment transaction. This makes it possible to reconstruct which settlement was changed by each refund.

4. Payout Holds and Releases

Rather than unconditionally suspending payouts for an entire seller account, the system should support holds by order, amount, or reason. Common reasons for holds include the following.

• Consumer disputes or returns in progress
• Suspected wash trading, account takeover, or abnormal payments
• Failure to verify the seller’s identity, business, or bank account
• Lawful requests from courts, investigative agencies, or relevant authorities
• Failure to submit settlement documents required by contract

Each hold record must store the affected amount, reason code, supporting materials, start time, review deadline, responsible person, and release conditions. Within the scope that may be disclosed, the seller interface should display the held amount, reason, required actions, and inquiry channel.

To prevent operators from repeatedly imposing holds at their discretion, it is advisable to separate the authority to create and release holds and apply dual approval to the release of large holds.

5. Segregation of Sales Proceeds and PG/Escrow Structure

If unpaid sales proceeds and company operating funds are managed as if they were the same available cash, a liquidity shortage can immediately lead to unsettled payments. At a minimum, funds related to sales proceeds and operating funds must be clearly distinguished in internal ledgers and account operations, with balances reconciled daily.

However, simply creating a separate account does not automatically establish legal bankruptcy remoteness or complete protection of funds. The effectiveness and obligations of protection methods such as trusts, deposits, and payment guarantees must be reviewed under the applicable laws and contractual structure.

Depending on the platform’s role in the payment and payout process, registration issues may arise under the Electronic Financial Transactions Act, including registration as an electronic payment gateway business. Not every platform is subject to the same PG registration requirements, nor does merely calculating settlement data always require registration. The determination must be based on how funds are actually received, held, and transferred, as well as the contractual relationships.

An early-stage platform may consider payment, escrow, or seller-specific split-settlement services provided by a registered PG. However, using a PG does not eliminate the following responsibilities.

• Determining which orders to submit for payout and when
• Calculating fees and adjustments
• Managing refunds and negative balance carry-forwards
• Verifying seller information and bank accounts
• Reconciling PG results with the internal ledger
• Responding to disruptions and payout failures

Escrow obligations and exceptions also vary by transaction type and payment method, so the Electronic Commerce Act and its subordinate regulations must be reviewed.

6. Withholding Tax, VAT, and Supporting Documents

The rule that “individual sellers are always subject to a 3.3% deduction” is inaccurate. The term 3.3% generally refers to the combination of 3% income tax on business income and 0.3% individual local income tax. Whether withholding actually applies depends not only on whether the seller has a business registration, but also on the nature of the income, contractual relationship, payment category, and exception rules.

The following information must be collected during registration and contracting.

• Seller type, such as individual, sole proprietor, or corporation
• Whether the seller is a domestic or foreign resident or corporation
• Tax status, such as taxable, tax-exempt, or simplified taxation
• Information required for statutory reporting, such as a business registration number and resident registration number
• Nature of the income and reason for payment
• Required supporting documents, such as tax invoices, invoices, or withholding tax receipts

It is also incorrect to generalize that business sellers are “always paid 100% without any tax deductions.” If the contract provides for platform fees to be deducted, the gross transaction amount, fees, VAT, and actual transfer amount must be distinguished. The party responsible for issuing a tax invoice for fees on brokerage services provided by the platform, as well as the timing of issuance, must be determined according to the contractual and tax-law supply relationship.

Withholding taxes are generally subject to a structure requiring filing and payment by the 10th day of the month following the month containing the payment date. However, because exceptions or deadline changes may apply, the rules in effect at the time of filing must be checked. Rather than hard-coding tax rules, it is safer to manage them as versioned policies with effective start and end dates.

7. Payout Failures, Settlement Admin, and Audit Logs

Even properly created payouts may fail due to account errors, account holder mismatches, transaction restrictions, bank maintenance, or PG outages. Rather than simply marking a failure as “unpaid,” define detailed statuses and reprocessing rules.

Recommended status examples include the following.

• scheduled: Payout scheduled
• submitted: Request sent to bank or PG
• processing: Being processed by an external institution
• paid: Success confirmed
• failed_retryable: Retryable failure
• failed_final: Final failure requiring information correction or other action
• reversed: Canceled or returned after success

Retries must use an idempotency key that identifies the same payout. Because mistaking a delayed response for a failure and transferring the funds again can result in a duplicate payment, first check the external transaction number to confirm the result of the existing request.

The audit log must record the following.

• The actor and operator account used
• Security information such as execution time and access location
• Values before and after the change
• Reasons for holds, releases, and manual adjustments
• Approver and executor
• Related orders, settlement batches, and external transaction numbers
• Failure codes and retry history

Audit logs must be protected so that ordinary operators cannot modify or delete them. Policies for data minimization, access control, encryption, and retention periods must be applied to personal and financial information.

Minimum Components of a Settlement Data Model

Rather than having AI build the interface first, it is better to define the following ledgers in advance.

Each ledger must include the currency, policy version, creation time, and a linkage key to the original transaction. Changing an order status alone must not silently alter historical settlement amounts.

Control Rules That Must Be Maintained

The settlement system must automatically verify the following invariants.

• Each settlement item is linked to exactly one seller and one original transaction.
• Funds are not transferred twice using the same payout key.
• The sum of completed payouts, unpaid amounts, held amounts, and adjustments matches the ledger.
• Every manual adjustment has a reason and an approver.
• Closed settlements are not modified; they are corrected through reversing entries and new adjustments.
• Differences between internal sales-proceeds-related balances and PG or bank balances are investigated daily.
• The applied policy version is recorded for tax and fee calculations.

Example Policy Specification to Provide to AI

Structuring requirements as follows can reduce omissions.

Design the order status and settlement status separately. Implement purchase confirmation conditions by transaction type, a payout batch every Wednesday, holiday handling, the fee basis, partial refund allocation, negative balance carry-forwards, per-transaction payout holds, withholding tax policy versions, payout idempotency keys, and immutable audit logs. Process amounts as integers or fixed-point values. Every manual adjustment requires dual approval and a reason. Before implementation, present a list of questions regarding undefined policies such as the minimum payout amount, automatic purchase confirmation period, long-term negative balance recovery, hold deadlines, and number of retries.

Do not ask AI only for code; also request the following deliverables.

• State transition diagrams and exception lists
• Database schema and constraints
• Permission and approval structure
• Tests for normal cases, boundary values, failures, and duplicate requests
• Daily reconciliation report format
• Disaster recovery and manual processing procedures
• Personal and financial information protection checklist

Pre-Launch Checklist

• Settlement eligibility dates are documented for each transaction type.
• Sellers can verify settlement statements at the order level.
• Partial refund and negative balance carry-forward tests have passed.
• Hold reasons, deadlines, and release authority are defined.
• Management standards distinguish funds related to sales proceeds from operating funds.
• PG, escrow, and electronic financial business applicability has been reviewed with experts.
• Tax treatment has been reviewed by seller and income type.
• Duplicate payment prevention and failure retry tests have been completed.
• Daily reconciliation among bank, PG, and internal ledgers is possible.
• Manual changes by operators are recorded in the audit log.
• Procedures exist for notifying sellers and responding to inquiries during settlement disruptions.

Conclusion

The foundation of a safe settlement system is not an AI prompt, but explicit policies and segregated ledgers. AI should be used as a tool to translate finalized rules into code, tests, and documentation, while fund custody structures and electronic finance and tax determinations must be validated with PG providers, accounting and tax professionals, and legal experts.