> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 清算场景：部分清算、超额清算与多笔清算
> 说明授权金额与最终清算金额不一致时的三类处理方式：部分清算、超额清算和多笔清算。
## 📄 正文
授权通过后，商户并不一定按授权金额一次性扣款。最终清算金额可能小于、等于、大于授权金额，也可能分多笔到账——无论遇到哪种情况，DCS 都会在同一套「授权 → Outstanding → 交易」模型上自动对齐资金，您只需关注每一步收到的 Webhook 与每日对账文件，无需自行做差额修正。
本页聚焦三类最常见、也最容易踩坑的清算偏差场景——**部分清算、超额清算、多笔清算**，并补充与之配套的**少额清算**与**退款**。授权与清算的完整 13 个组合场景见 [授权与清算全场景](./auth-and-settlement)；字段与枚举定义见 [授权](./authorization) 与 [交易流水](./transaction)。
***
## 先理解三个对象
DCS 的资金对账建立在三个对象上，看懂它们，下面所有场景都一目了然：
| 对象 | 作用 | 关键字段 |
| --------------------- | ---------------------- | -------------------------------------------------- |
| **授权（Authorisation）** | 交易发生前的额度占用决策，冻结/解冻资金 | `authId`、`authType`、`direction` |
| **Outstanding** | 未清算余额，跟踪「已冻结 − 已扣款」的差额 | `outsId`、`amount` |
| **交易（Transaction）** | 商户实际清算产生的流水（扣款/退款） | `transactionId`、`authIds`、`outsId`、`multiClearInd` |
* 一笔授权（或多笔共享的授权）会创建/累加一个 Outstanding。
* 每收到一笔清算，Outstanding 的 `amount` 相应**扣减**；归零即代表该笔授权已结清。
* 当清算金额与冻结金额不一致时，DCS 会**自动补建一笔 `FORCE_AUTH` 授权**补足或释放差额，使 Outstanding 始终能归零——这一步对接入机构透明。
> **谁做什么**：授权阶段的 Approve/Decline 由**接入机构**实时决策（见 [授权](./authorization)）；清算阶段的资金对齐、差额补建、Outstanding 维护全部由 **DCS** 自动完成，清算结果通过每日交易对账文件交付。
***
## 场景一：部分清算
**含义**：商户最终只扣取了部分授权金额（如加油站预授权 100、实际清算 80）。这是最常见的偏差，对接入机构而言属正常情况。
**动作时序**（授权 100、实际清算 80）：
| 步骤 | direction | 金额 | authType / 标识 | Outstanding |
| --------- | --------- | --: | ----------------------- | --------------: |
| 1. 授权批准 | OUTGOING | 100 | `authId1` (NORMAL) | `outsId1` = 100 |
| 2. 少额清算补建 | INCOMING | 20 | `authId2` (FORCE\_AUTH) | 100 → 80 |
| 3. 清算扣款 | OUTGOING | 80 | `transactionId1` | 80 → 0 |
**接入机构要做的**：在每日交易对账文件中读到该笔清算后，按 `transactionId` 入账实际扣款金额，并将多冻结的差额解冻还给持卡人。差额的释放由 DCS 通过 `FORCE_AUTH` 自动完成，您据对账文件同步即可。
***
## 场景二：超额清算
**含义**：最终清算金额**大于**授权金额（如餐厅授权 100、加小费后结算 110；或跨币种汇率波动）。卡组织规则允许商户在一定比例内超额清算。
**动作时序**（授权 100、清算 150）：
| 步骤 | direction | 金额 | authType / 标识 | Outstanding |
| -------- | --------- | --: | ----------------------- | --------------: |
| 1. 授权批准 | OUTGOING | 100 | `authId1` (NORMAL) | `outsId1` = 100 |
| 2. 超额补冻结 | OUTGOING | 50 | `authId2` (FORCE\_AUTH) | 100 → 150 |
| 3. 清算扣款 | OUTGOING | 150 | `transactionId1` | 150 → 0 |
第 2、3 步在同一事务内完成：DCS 发现清算金额（150）大于 Outstanding（100），自动补建一笔 OUTGOING `FORCE_AUTH` 补足差额 50，再整笔清算。
> **额度提示**：超额部分会额外消耗接入机构在 DCS 的[企业保证金](../../basic-concepts/fund-model)。`FORCE_AUTH` 补差额时**不再走授权转发决策**——它由清算驱动、自动批准，因此接入机构无法在这一步拒绝。如需控制超额风险，应在**授权决策**环节预留缓冲额度。
***
## 场景三：多笔清算
**含义**：一笔授权对应商户的**多次清算**（如一个订单分批发货，每批单独结算）。多笔清算共享同一个 Outstanding，靠 `multiClearInd` 字段区分进度。
**动作时序**（授权 100，分 60 + 40 两笔清算）：
| 步骤 | direction | 金额 | 标识 | `multiClearInd` | Outstanding |
| --------- | --------- | --: | ------------------ | :-------------: | --------------: |
| 1. 授权批准 | OUTGOING | 100 | `authId1` (NORMAL) | — | `outsId1` = 100 |
| 2. 第一笔清算 | OUTGOING | 60 | `transactionId1` | `P` | 100 → 40 |
| 3. 最后一笔清算 | OUTGOING | 40 | `transactionId2` | `F` | 40 → 0 |
`multiClearInd` 枚举（详见 [交易流水](./transaction)）：
| 值 | 含义 |
| --- | ------------------------------------- |
| `O` | 普通单笔清算（无多笔） |
| `P` | 多笔清算的**非最后一笔**——只扣减 Outstanding，不检查差额 |
| `F` | 多笔清算**完成**——最后一笔，此时才检查并补齐差额 |
**示意：两笔清算落在每日交易对账文件中的样子**（字段取自[交易流水](./transaction)文件 schema；多笔清算共享同一 `authIds` 与 `outsId`，靠 `multiClearInd` 区分 `P`/`F`）：
```json theme={null}
[
{
"transactionId": "1109900000000000001",
"direction": "OUTGOING",
"outsId": "1109800000000000001",
"authIds": "1109700000000000001",
"amount": "60.000000000000000000",
"currency": "840",
"category": "RETAIL",
"multiClearInd": "P"
},
{
"transactionId": "1109900000000000002",
"direction": "OUTGOING",
"outsId": "1109800000000000001",
"authIds": "1109700000000000001",
"amount": "40.000000000000000000",
"currency": "840",
"category": "RETAIL",
"multiClearInd": "F"
}
]
```
> 这是按交易流水文件字段构造的**示意记录**（清算无独立的请求/响应接口，统一通过每日对账文件交付，见[交易流水 · 如何获取](./transaction)），仅展示同一授权下 `P`（非最后一笔）与 `F`（最后一笔）两条流水的关键字段，省略了商户、时间等其余字段。
> **接入机构要做的**：见到 `multiClearInd = P` 不要急于把 Outstanding 视为结清；只有 `F` 才代表本笔授权全部清算到账。若 `F` 之后仍有差额，DCS 会按场景一/二的逻辑自动补建 `FORCE_AUTH`。
***
## 配套场景：退款
**含义**：持卡人退货，资金从商户退回卡片。退款是 INCOMING 方向的入金交易。
* **有原授权**：找到原 `authId` 与 `outsId`，创建一笔 INCOMING 退款交易，关联同一 Outstanding。
* **无原授权**（强制退款 / 离线退款）：DCS 新建一个 Outstanding（`amount = 0`）做数据关联，仅创建退款交易，**不补建授权**。
退款交易在每日交易对账文件中以 `direction = INCOMING`、`category = PAYMENT`（退货/退款）标识。
***
## 资金对账总览
将三类场景放在一起可以看出：**Outstanding 最终都会归零**。
| 场景 | 授权 | 清算 | 差额处理 | Outstanding 最终 |
| --------- | --: | ----------: | --------------------------- | -------------: |
| 部分 / 少额清算 | 100 | 80 | INCOMING `FORCE_AUTH` 解冻 20 | 0 |
| 超额清算 | 100 | 150 | OUTGOING `FORCE_AUTH` 补冻 50 | 0 |
| 多笔清算 | 100 | 60 + 40 | `P` 累计、`F` 收尾 | 0 |
| 退款 | — | INCOMING 入金 | 新建 Outstanding 关联 | 0 |
接入机构对账时的统一做法：**以 `outsId` 串联授权与清算，以 `authIds` 关联交易与授权**（多笔授权时 `authIds` 用逗号分隔，如 `1111,2222`），按 `transactionId` 入账实际资金，最终核对 Outstanding 归零。
***
## 补充说明
* 每日交易文件的 `category` 使用全称（如 `RETAIL` / `CASH` / `CASH_FEES` / `PAYMENT`），完整枚举见[报告字段说明](../reports/field-dictionary)；授权侧 `transactionType=R/C/Q/P` 是另一个字段，请勿混用。
* 超额清算的差额由 DCS 自动补建 `FORCE_AUTH` 对齐；如需控制超额风险，应在**授权决策**环节预留缓冲额度（见场景二的额度提示）。
* 补差额的 `OUTGOING + FORCE_AUTH` 会走授权通知通道，但它是「通知 + 强制入账」，不是再次征询是否同意；接入机构返回拒绝不会取消该笔强制入账。
***
## 下一步
* 想看授权/清算的**全部 13 个组合场景**（含增量、撤销、过期释放、状态差异释放、提现手续费）：[授权与清算全场景](./auth-and-settlement)
* 想核对**字段与枚举**：[授权](./authorization) 与 [交易流水](./transaction)
* 想在沙盒里**模拟这些清算**：[模拟交易](../sandbox/simulating-transactions)