你们的销售导出显示 $10,000，银行流水却只有 $9,000。你检查了公式，把数字复制到另一张表里，仍然是没法告诉经理钱到底有没有少。
对一家小型电商或服务型企业来说，有用的答案是一段简短说明，并且每一项调整背后都有记录支撑：退款 $500、手续费 $300，还有 $200 仍在等待结算。 这样你就知道了哪些钱已到账、哪些还没到、哪些需要进一步核查。
按照下面的四文件练习包动手做一遍，就能得出这样的说明。你可以在 Excel 中跟着操作，再用同样的规则让匡优数言生成一份可复核的分析。
核心要点：
- 把已付款销售、平台活动、打款和实际银行入账分开。它们记录的是不同的事件。
- 跟着一个完整的 $10,000 → $9,000 案例走一遍，并把每一笔打款与其交易记录和银行回单逐一核对。
- 让待结算资金保持可见。一笔未到的存款并不自动等于手续费或损失。
- 用下载文件、提示词和 $10 失败测试，在信任一份业务报告之前先检验工具的输出。
- 匡优数言可以帮你分析文件并解释结果；匹配规则和未解决的差异仍由你来确认。
为什么销售额与存款金额通常对不上
已付款订单记录的是客户支付了什么。打款是支付平台转出的一笔钱。银行入账记录的是实际记入你账户的款项。退款、处理手续费和转账时间差都会让这些金额彼此不同，而这并不代表有错误。
销售对账就是沿着这些记录一路追查，直到差异得到解释。销售与银行的核对还需要期初和期末余额：有些现金可能来自上个月的销售，而本月的部分现金可能稍后才到账。
Stripe 的打款对账文档介绍了如何将一笔打款与其对应的那批交易（包括付款、退款和手续费）相匹配。文档还指出，其报告是按预计到账日期对打款分组的，而这可能与银行实际入账日期不同。其他平台有不同的导出文件和规则；套用模板之前请先确认自家平台的情况。
本指南核对的是已付款销售与资金流动。 它不判定会计确认收入、税务处理，也不判定财务报表是否正确。
第 1 步：收集四个文件，并明确每一行代表什么
下载包中是一个为 DemoStore 准备的虚构的 2026 年 9 月示例。所有金额均为美元，日期使用 UTC，平台期初余额为零。这些是编造的练习记录，答案独立计算得出，不是客户成果，也不是匡优数言的实际运行记录。
| 文件 | 一行的含义 | 需要检查的字段 |
|---|---|---|
| orders.csv | 一笔已付款订单 | order_id、order_date、paid_sales、currency |
| processor-activity.csv | 一个收款、退款或手续费事件 | event_id、order_id、payout_id、signed_amount |
| payouts.csv | 平台发出的一笔转账 | payout_id、payout_amount、bank_reference |
| bank.csv | 一笔已入账的银行收款 | bank_row_id、posted_date、reference、credit |
原始文件不要改动，用副本操作，并记录每个文件来自哪次导出、哪个账户。在真实的订单行导出中，一笔订单可能对应多行；在统计订单数或匹配付款之前先把这个口径定下来。
本练习中，9 月被设定为完整月份。样本不涉及税、运费、货币换算、争议、准备金、未付款订单或前期调整。真实文件可能需要为每一项单独列示。
第 2 步：先统一期间口径，再匹配金额
把你的报告规则写成一句话：
以美元口径解释 DemoStore 9 月 1 日至 30 日的已付款销售与 9 月银行入账，并单独列示平台期初和期末余额。
不要对所有文件都按 order_date 筛选。一笔订单、它的退款、平台打款和银行入账可能发生在四个不同的日期。
做真实的月末核对时，要取得期初平台余额、期末余额，以及两端已发出但尚未入账的转账。还要检查 9 月发生的、针对 8 月订单的退款。没有这些记录，一份当月的订单导出是解释不了全部资金流动的。
在本练习数据中，期初余额和在途转账均为零。唯一的期末余额是订单 O105：9 月 30 日收款 $200，尚未分配打款。 把这笔金额放进待结算资金表，并与后续打款核对；不要称它为缺失的钱。
第 3 步：用源记录解释清楚 $1,000 的差额
从五笔已付款订单开始：
| 订单 | 已付金额 | 调整或下一步 |
|---|---|---|
| O101 | $3,000 | 包含在打款 P01 中 |
| O102 | $2,500 | 退款 $300；其余活动在 P01 中 |
| O103 | $2,000 | 包含在打款 P02 中 |
| O104 | $2,300 | 退款 $200；其余活动在 P02 中 |
| O105 | $200 | 截至 9 月 30 日仍留在平台上 |
| 合计 | $10,000 | 未扣除退款和平台手续费之前 |
退款事件 E03 和 E07 合计 $500。手续费事件 E04 和 E08 合计 $300。平台期末未结算余额为 E09，$200。
图：根据可下载的虚构记录独立计算得出。这是说明性图表，不是产品截图。
结果如下：
已付款销售 $10,000
减：退款 $500
减：平台手续费 $300
减：期末未结算资金 $200
预计银行入账 $9,000
实际银行入账 $9,000
未解释差异 $0
这个简单的桥接之所以成立，是因为样本的其他资金流动和期初余额均为零。对于真实数据，要把期初资金列为加项、期末资金列为减项，并单独记录其他平台调整和在途转账。绝不要为了凑到零而凭空编造一笔“时间性调整”。
第 4 步：逐笔核对打款，再核对银行
总数表面上对得上，可能掩盖了彼此抵消的错误。所以每一批也要单独核对。
| 打款 | 来源活动 | 净打款额 | 银行凭据 | 差异 |
|---|---|---|---|---|
| P01 | $3,000 + $2,500 − 退款 $300 − 手续费 $120 | $5,080 | B01：9 月 10 日入账 $5,080 | $0 |
| P02 | $2,000 + $2,300 − 退款 $200 − 手续费 $180 | $3,920 | B02：9 月 25 日入账 $3,920 | $0 |
用可靠的打款参考号把转账与银行记录关联起来。如果没有参考号，就用金额、账户、币种和一个有据可查的日期窗口来识别可能的匹配。两笔金额相同的入账在有人确认之前仍然是模糊的。
还有一个电子表格陷阱：一笔订单可能既有收款又有退款。如果你把订单表与每一个事件连接后再对 paid_sales 求和，订单金额就会被重复计算。销售额要从原始订单表汇总；资金活动要从事件表汇总。在正确的层级上比较结果。
在活动文件里，退款和手续费已经是负数。按每个 payout_id 对 signed_amount 求和即可；再减去这些负值会让结果虚增。ZIP 包中包含 expected-payout-matches.csv 和 expected-bridge.csv 作为答案参照。
第 5 步：让匡优数言给出可复核的解释
规则明确之后，匡优数言的数据分析工作流可以帮你检查导出文件、计算汇总，并把结果整理成一份可读的报告。先拿虚构输入试跑，再上传真实业务文件。
只上传那四个输入 CSV，并使用下面这段请求。把答案参照文件排除在这次运行之外，方便你之后对照。
帮我核对 DemoStore 2026 年 9 月 1—30 日的已付款销售与银行入账。
使用附上的四个 CSV。所有金额为美元，日期为 UTC。
保持源数据不变。orders 的每一行是一笔已付款订单；processor 的每一行
是一个事件。退款和手续费已经是负数。
先检查唯一 ID、缺失键、币种和来源覆盖情况。
把每笔订单金额与其收款事件比对，标出不一致之处。
销售额从 orders 汇总，不要从与退款事件连接后的表汇总。
按 payout_id 汇总 processor 的 signed_amount。把 payout_id 为空的事件
保留为未结算活动。将每一批与 payouts.payout_amount 比对，
再把其 bank_reference 与 bank.reference 和 bank.credit 匹配。
不要猜测模糊匹配，也不要把已发出的打款当作已收到的银行入账。
给出销售、退款、手续费、未结算资金、打款匹配项和未匹配项的源 ID。
本次练习中平台期初余额和在途转账为零。不存在其他类型的调整。
输出一张销售到银行的桥接表、一张打款匹配表和一张例外表。
未知原因标为未解决；绝不要添加一笔平衡用的手续费。
最后附一段给经理的简短摘要，以及仍需人工确认的检查项。
预期结果： 已付款销售 $10,000、退款 $500、手续费 $300、未结算 $200、银行入账 $9,000。两笔打款均匹配。O105 是一项已解释的待处理项；未解释差异为零。这些是计算得出的预期值，并不保证任何 AI 工具的输出都是如此。
对于机密财务记录，请先使用匿名化文件，或在上传前了解私有化部署。本指南使用的是导出文件；它不假定存在实时银行连接、自动结算监控，或匡优数言内置的独立校验代理。
第 6 步：在采用月度结果之前先做一次失败测试
复制一份 bank.csv，把 B02 的入账金额从 3,920 改成 3,910，然后用这份副本和另外三个原始输入重跑上面的请求。
银行总额应变为 $8,990，P02 应显示 $10 的缺口。退款、手续费和待结算资金必须保持不变。如果工具悄悄加了一笔 $10 的手续费、改动了 O105，或者宣称全部匹配成功，就要求它给出源行，并让报告停留在草稿状态。
分享之前，请检查：
- 每一笔订单收款都能对应到其来源金额，每一笔银行入账都有且只有一个已批准的匹配。
- 退款和手续费各出现一次，且正负号正确。
- 待结算资金有源 ID 和后续跟进日期。
- 缺失 ID、重复事件和模糊匹配都仍然可见。
- 期初和期末余额、币种、日期规则和完整性都有明确的负责人可以确认。
更全面的 AI 生成报告复核清单涵盖了其他检查项，包括缺乏依据的解释和重复行。
该给经理发什么
对未改动的样本，一段有用的说明是：
9 月已付款销售为 $10,000。扣除 $500 退款、$300 平台手续费后，加上月末仍有 $200 未结算，银行入账为 $9,000。两批打款均与银行入账对应。$200 待结算余额与 O105 有关，需要后续核对打款。在上述样本范围内，不存在未解释差异。
把这段说明与输入文件版本、匹配规则、例外处理决定和复核人批准一起保存。下个月，可以参考周期性 CSV 报告工作流，了解如何在更新文件的同时保留这些规则。
