> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 结算批次与日历

> 交易如何被分组为结算条目和批次、标识符是什么意思、结算记录的状态时间线显示什么、Balance History 记录什么以及如何筛选和导出，还有如何解读结算日历的国家维度和假期详情。

[结算周期与日历](/docs/zh/support/settlement-cycle-faq) 解释你的钱**在哪一天**到账。本页解释
**交易如何被分组进那笔付款**、产生的记录和标识符是什么意思，以及如何解读围绕它们的账本
和日历。报告文件内容见
[结算文件规范](/docs/zh/support/settlement-file-specification-faq)。

## 我的交易是如何被分组为一笔结算付款的？

三个分组层级，其中你只会看到外面两层：

| 层级 | 分组依据 | 你能看到吗？ |
| - | - | - |
| **Pack** | 商户 + 交易成功日 + 支付方式 + 订单币种 + 结算币种 | **不能。** 仅为内部准备单元 |
| **Settlement Entry** | 商户 + 订单币种 + 结算币种 | 能——批次内的会计单元 |
| **Settlement Batch** | 商户 + 结算币种 + 签约主体 + 清算类型 | 能——一次结算事件：付给你的钱加上它的报告 |

向上读：交易首先按支付方式和交易日打包，这些包再按订单币种合并，然后按结算币种合并为一个批次。

批次键中有两个维度容易被忽略，而两者都意味着你可能**在同一日期、同一币种收到不止一笔结算**：

* **签约主体。** 如果你的交易在不止一个 Waffo 签约主体下收单，每个主体在自己的批次中结算。
* **清算类型。** 由退款备用金安排出资的退款结算是一条独立的清算流，**永远不会与普通结算
  共享批次**——它也忽略假期日历。见
  [结算周期与日历](/docs/zh/support/settlement-cycle-faq)。

这就是为什么一个批次有意跨越支付方式、国家和订单币种。这也是为什么**一个结算日期、两种
结算币种会给你两个批次**，各有自己的文件——见 [结算报告与导出](/docs/zh/support/settlement-reports-faq)。

Pack 层对你只作为解释有意义：因为打包按支付方式和交易日进行，一个批次可以合理地覆盖
**不止一个交易日**。不要假设结算与交易日之间是一一对应关系。

## 结算标识符是什么意思？

| 标识符 | 形态 | 含义 |
| - | - | - |
| Settlement Entry Id | `E` + 商户 id + `yyyyMMdd` + 序号 | 批次内的一个订单币种会计单元 |
| Settlement Batch Id | `S` + 商户 id + `yyyyMMdd` + 序号 | 一次结算事件，也是你结算文件名中的值 |

标识符中的日期是其生成日期，不一定是资金划转的日期——后者请使用记录自身的日期字段。
`S…` 值是要向客服引用的：它是解析一笔结算、其文件和其账本条目的键。

## 结算记录的状态和时间线告诉我什么？

结算记录带有一个状态，其详情页带有**完整的执行时间线**——这很重要，因为一笔结算可能被
尝试不止一次：

| 状态 | 含义 |
| - | - |
| `Created` | 结算指令已生成 |
| `Unsettled` | 一次尝试未能完成，正在等待重试 |
| `Succeeded` | 已入账 |
| `Failed` | 未入账即终止 |

时间线以各自的时间戳记录每个事件——生成、每次不成功的尝试，以及最终结果——所以一条运行、
失败、之后成功的记录会显示全部三项，而不只是最后一项。仍处于初始状态的记录不会列出。

结算记录默认为**最近 90 天**（UTC+8）。一条记录可以合理地显示早于今天的结算日期而仍处于
开放状态；产生这种情况的重试顺序在
[结算周期与日历](/docs/zh/support/settlement-cycle-faq) 中描述。

## Settlement Original Amount 和 Settlement Target Amount 是什么？

| 字段 | 含义 |
| - | - |
| `Settlement Original Amount` | **以订单币种**汇总的净结算金额 |
| `Settlement Target Amount` | 同一笔钱**换算**为结算币种之后的金额 |

当你的结算协议把订单币种结算为其自身时，两者相同。涉及换算时两者不同——并且
`Settlement Target Amount` 在**换算完成之前为空**，这是一个阶段，不是数据缺失。如果你在
对账时目标金额为空，说明结算已准备但尚未换算。

## Balance History 记录什么？我可以按哪些业务类型筛选？

Balance History 是你**结算账户**的账本，涵盖你结算到的每一种结算币种。六种业务类型可筛选：

| Business Type | 覆盖什么 |
| - | - |
| `SETTLEMENT` | 来自结算的资金到账 |
| `WITHDRAWAL` | 提现动账，包括提现被撤回 |
| `ADJUSTMENT` | 手动调整 |
| `RESERVE_WITHHOLDING` | 被扣留到保证金的金额 |
| `RESERVE_RELEASING` | 保证金扣留被释放 |
| `RESERVE_ADJUSTMENT` | 从你的结算账户补足被扣减保证金的补充 |

让人意外的两点：

* **较早的行可能带有不再产生的类型。** 换算移到提现之前以前的 FX `Conversion` 行仍以自己的
  标签显示。筛选是一种便利，不是某种行类型从未存在过的证明。
* **Portal 页面显示的是结算账户。** 记在保证金账户本身上的动账位于单独的 **Reserve Account**
  页面，那里有自己的扣留与释放 Tab 以及调整 Tab；API 端点 `/api/v1/account/history/inquiry`
  在一次调用中返回两个账户——见 [结算账户结构](/docs/zh/support/settlement-account-structure-faq)。
  如果你的账户有退款备用金，它也有自己的历史 Tab。

## 为什么我在 Balance History 中再也看不到 FX 换算条目了？

因为换算现在发生在资金到达你的结算账户**之前**，而不是提现时。后果如下，全部是有意为之：

| 以前 | 现在 |
| - | - |
| 余额按交易币种显示，换算前 | 余额**按结算币种**显示 |
| 换算在账本中作为独立动账出现 | 结算到账时已换算，所以没有单独的东西需要记录 |
| 换算在你提现时发生 | 换算在你提现之前已完成 |
| 每个订单币种多个批次，有些没有汇率 | **每个结算币种一个批次**，按交易显示外汇汇率 |
| 仅有交易报告 | 结算汇总**和**结算明细报告 |

如果你在与历史记录比对，这就是为什么旧行显示换算动账而新行不显示。

## Balance History 有哪些列？如何导出？

| 列 | 含义 |
| - | - |
| `Account No` | 该动账记入的账户 |
| `Account Type` | 是哪个账户 |
| `Business Id` | **导致该动账的事物的标识符**——结算对应结算批次 id，提现对应提现订单 id |
| `Business Type` | 类别，如上 |
| `Direction` | `CREDIT`（入）或 `DEBIT`（出） |
| `Amount` / `Currency` | 动账 |
| `Balance` | 该动账**之后紧接着**的余额 |
| `Datetime` | UTC+8 |
| `Description` | 发生了什么，例如 `Withdrawal Submission`、`Withdrawal Fee`、`Withdrawal Cancelled` |

`Business Id` 是关联回 Portal 其余部分的连接键——拿结算批次 id 去 Settlement Batch，
拿提现订单 id 去 Withdrawal History。

| 导出 | 规则 |
| - | - |
| 文件名 | `account_history_{merchant id}_{from}_{to}.csv` |
| 文件名中的时间戳 | `YYYYMMDDHHMMSS`，UTC+8 |
| 最大跨度 | **31 天**——在 Portal 中强制，服务端再次强制 |

导出携带与屏幕表格相同的列，所以同一个数字在两者之间永远不会改变含义。

## 默认日期窗口是什么？

| 视图 | 默认 | 排序 |
| - | - | - |
| Balance History | 最近 **30 天** | 最新优先；同一时间戳的行按币种 A–Z |
| 结算记录 | 最近 **90 天** | 最近的结算优先 |
| Settlement Batch | 最近 **30 天** | 按实际结算日期，最近优先 |

所有窗口均为 UTC+8。如果你要对账更早的记录，请显式放宽筛选。

## 为什么结算日历按国家而不是按币种组织？

因为假期是国家的属性，不是币种的属性。日历的主维度是 **Country/Region**，以 ISO 3166-1
alpha-3 代码列出你生效合约覆盖的国家，默认选中第一个。页面上的一切都跟随这一个选择：

* **Regions of Holidays** 只显示所选国家/地区的相关国家，不能独立更改。
* 交易日和结算日期（包括延期）只针对该国家/地区推导。
* 导出只包含所选国家/地区。

**最常被查阅的地区固定在列表最前面**，位于字母顺序之前。

| 字段 | 是什么 |
| - | - |
| `Transaction Period` | 一笔结算覆盖的交易日 |
| `Scheduled Settlement Date` | 交易打包时计算出的日期 |
| `Scheduled Settlement Date (Deferred)` | 该日期此后移动到的位置——假期日历变更，或负周期向前滚动 |
| `Actual Settlement Date` | 实际结算的时间 |

行按周期的第一个交易日排序，然后按最后一个。导出产生
`settlement_calendar_[Region]_[YYYYMM].xlsx`，所选国家/地区以表头行注明。日历上没有按日期的
文件下载——对账报告属于结算批次。

## 为什么某个特定日期不是结算日？

点击它。日历会以 **Related Holidays** 的形式逐条列出原因，形式为*国家：假期名称*——
每个当天休市的相关国家一行。这取代了单纯的"Non-settlement Day"标签，所以你能看到究竟是
哪个国家休市以及为什么。

只显示**已确认**的假期。仍在核实中的候选假期不会延后你的结算，也不会出现。

工作日计算使用你在该签约国家的收单合约上**所有相关国家合并去重后的假期日历**。
只要其中任何一个休市，该日期就不是结算日。

## 哪些国家的假期会影响我？可以更改吗？

两条规则支配它：

1. **一致性。** 对同一商户和同一签约国家，**所有支付方式必须携带相同的相关国家集合。**
   在同一签约国家内，你不会出现一个支付方式在某个假期延后而另一个不延后的情况。这正是让
   单一合并日历有意义的原因。
2. **可配置性。** 考虑哪些国家的假期**按商户配置**。对某个市场没有敞口的商户没有理由在
   该市场的假期延后，而某条结算路径可能需要一个你并不销售的市场。如果你的延期与你的业务
   不匹配，请向你的客户经理提出——这是合约配置，不是固定规则。

日历始终反映实际对你生效的配置，所以它显示的合并假期就是会移动你日期的那些。

***

把某个批次与你自己的记录比对，发现有对不上的地方？
请附上结算批次 id [联系客服](mailto:support@waffo.com)——它能解析该笔结算、其条目、
其文件和其账本条目。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.