支付报告核对：先确认覆盖范围，再比较总额

合成网站集成练习，未访问商家账号或财务导出。这是报告范围核对，不是会计、税务或漏款判断。

相加之前，先问报告覆盖什么

采购网店集成或报表功能时，先约定所填报告代表哪个处理商、结算币种、期间及完整截止日。两份总额不同，可能是输入口径不同。网站供应商应显示这些缺口，而不是悄悄合成一个号称覆盖全部支付的结果。

一位商家在2023年9月19日的Shopify问题中描述销售与银行到账差异。原帖只是历史问题来源，页面AI摘要和后续回复不诊断当前商店；这里不拿原帖金额冒充新客户案例。

一份已填写的覆盖矩阵

虚构需求为AUD、2026年10月1–7日，两条处理路线已分别确认：Shopify Payments与外部处理商。外部路线是本练习假设，不表示某个支付品牌在所有配置里都独立于Shopify Payments。报告标签与完整截止日均为合成观察。

补的是对应证据，不是猜一笔费用强行凑数。完整截止日仍是输入，程序不认证来源；覆盖期间也不证明活动已经形成银行到账。

运行有限范围检查

下载校验器、不完整示例与范围补齐示例，放在一起，用Node 22.13或更新版本运行：

node payment-scope-check.mjs --test
node payment-scope-check.mjs broken.json
node payment-scope-check.mjs corrected.json

8项测试覆盖缺处理商、错币种、期间不足、截止缺口、缺证据及畸形范围。BLOCKED代表需求范围缺失或无效；INCOMPLETE代表所填报告未覆盖；SUPPLIED_SCOPE_COMPLETE不判断金额、汇率、收入或税务。命令行打印状态，不是生产CI门禁或财务对账引擎。

官方报告边界

2026年10月15日核验的Shopify活动报告文档说明，它记录Shopify Payments余额活动，不是会计收入；结算币种分开，排除Shopify Payments以外的处理，并有三天数据延迟。所选期间、报告活动与银行到账时间不必相同。

不能仅凭结账Logo推断处理商，要核真实配置与报告路线。双处理商映射、截止日和JSON规则属于原创教学设计。机械用今天减三天不等于已认证的完整截止日，本例也不判断会计口径或商家应收到多少钱。

准备集成验收需求

1. 约定处理商、币种、期间及谁有权提供记录。
2. 所选日期、完整截止观察及证据引用分开，缺项保留未知。
3. 要求集成显示范围不完整，不输出自信的合并总额。
4. 范围确定后，单批结算与银行凭证核对是另一项任务，可参考到账差额算例。

讨论网站报表时，先提供脱敏字段字典和虚构测试记录。真实财务导出只走会计或商家批准的安全流程。本公开教学资源不需要银行账号、支付密钥或客户交易文件。