---
title: "7 Policies to Set Before Building an AI Settlement System"
locale: en
category: how_to
category_name: "How-to"
translation_status: reviewed
license: cc_by
author: "Injoys Editorial Team"
source_url: https://injoys.com/en/articles/seven-policies-before-building-ai-settlement-system
published_at: 2026-07-27T00:58:06+09:00
---

# 7 Policies to Set Before Building an AI Settlement System

> Settlement is not merely a calculation that subtracts fees from sales. It is a financial operations framework that controls the allocation of sales proceeds, payment conditions, refunds, taxes, and failure handling. Before entrusting implementation to AI, people must first finalize seven policies, from settlement cutoff dates to audit logs.

## Key Points

- Sales proceeds should not be managed as unrestricted operating funds of the platform, but as restricted funds linked to obligations to pay sellers and other parties.
- Order status and settlement status should be kept separate, with purchase confirmation, refunds, disputes, and payment failures each recorded in the ledger.
- It is not always appropriate to withhold 3.3% from individual sellers; the decision should depend on the legal nature of the income and the seller's status.
- Even when using PG or escrow, the platform must determine settlement cycles, fees, holds, negative balance carryovers, and tax policies.
- Settlement code generated by AI should be put into operation only after accounting ledger reconciliation, duplicate payment prevention, access controls, and expert review.

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.

| Statement Item | Description |
|---|---|
| Gross transaction amount | Contractual components of the sales amount, such as product price, option price, and shipping fees |
| Discount share | Discounts borne by the platform, seller, and partner, respectively |
| Cancellations and refunds | Full and partial refunds and shipping fee adjustments |
| Platform fee | Fee rate, fixed fees, and whether they are taxable |
| Payment-related costs | Indicates whether PG costs are deducted separately or included in the fee |
| Tax adjustments | Applicable items such as VAT and withholding tax |
| Other adjustments | Contractually supported adjustments such as compensation, advertising fees, and penalties |
| Final payout amount | Scheduled transfer amount after all additions and deductions |

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.

| Data Object | Role |
|---|---|
| Order ledger | Records order, payment, delivery, and purchase confirmation statuses |
| Settlement item | Records the gross amount, fees, taxes, adjustments, and assigned seller for each order |
| Adjustment ledger | Records refunds, compensation, penalties, and manual adjustments |
| Hold ledger | Records held amounts, reasons, deadlines, and release history |
| Settlement batch | Groups payouts for a specific period and seller |
| Payout ledger | Records transfer requests, successes, failures, and external transaction numbers |
| Tax ledger | Records withholding tax and the issuance and filing status of supporting documents |
| Audit log | Records all significant changes made by operators and the system |

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.

## FAQ

### Is settlement simply a feature that deducts fees from the sales amount?
No. Settlement includes purchase confirmation, partial refunds, payment holds, negative balance carryforwards, taxes, failed transfers, duplicate payment prevention, and ledger reconciliation. It requires not only formulas but also state transitions and fund controls.

### Must the settlement reference date always be the purchase confirmation date?
A single standard cannot be applied uniformly to all transactions. Purchase confirmation or automatic confirmation may be used for physical products, but services, digital content, and reservation-based products have different fulfillment completion conditions. The reference event for each transaction type must be determined together with the statutory and contractual payment deadlines.

### Is a shorter settlement cycle always better?
A shorter cycle reduces unpaid balances and sellers' cash flow burden, but returns, suspicious transactions, and operating costs must also be considered. Rather than unnecessarily extending the cycle due to risk, it is important to establish the minimum verification period appropriate to the transaction's characteristics and a predictable payment date.

### If a platform uses a PG, does it not need to create a settlement policy?
No. A PG may provide payment processing, fund transfers, escrow, or split payment features, but the platform's policy determines which orders are paid and when, how fees and refund amounts are calculated, and whose payments are held.

### Must 3.3% be withheld from all individual sellers?
No. 3.3% commonly refers to the combined withholding of business income tax and local income tax for individuals. Whether withholding applies and the applicable rate must be determined based not only on the seller's registration status but also on the nature of the income, the contractual relationship, residency status, and exceptions.

### Is it completely safe to hold sales proceeds in a separate account?
A separate account is a basic control for segregating operating funds from sales proceeds, but it does not by itself guarantee bankruptcy remoteness or legal protection. The necessary protection method, such as a trust, deposit, or payment guarantee, and the legal nature of the account must be verified in accordance with the contract and current laws and regulations.

### How should a negative settlement be recorded?
Record the refund amount for an order that has already been paid out as a separate adjustment transaction and deduct it from the next payment. If the deduction exceeds the amount scheduled for payment, set the payment amount to KRW 0 and carry the remaining balance forward to the next settlement. Do not delete the original transaction or overwrite a previous settlement statement.

### If there is no response to a transfer request, can it be retried immediately?
No. The first request may have actually succeeded even if only the response was lost. To prevent duplicate payments, use an idempotency key and an external transaction number for the same payment, check the existing processing result with the PG or bank, and then retry.

### Can AI-generated settlement code be deployed to production immediately?
It is not recommended. State transitions, ledger consistency, concurrency, duplicate requests, partial refunds, failure recovery, and access controls must be tested. Electronic financial transactions and tax matters should also be reviewed by experts based on the actual business structure.

## Sources

- [Electronic Financial Transactions Act](https://www.law.go.kr/법령/전자금융거래법)
- [Act on Consumer Protection in Electronic Commerce, etc.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Income Tax Act](https://www.law.go.kr/법령/소득세법)
- [Local Tax Act](https://www.law.go.kr/법령/지방세법)
- [Value-Added Tax Act](https://www.law.go.kr/법령/부가가치세법)

## Images

![AI automation workflow linking online stores with settlement, security, and verification](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp)
![AI settlement system linking security shields, policy steps, money vaults, a bank, and servers](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp)