流程
支付成功后，收单机构在 T+N 日将资金清算至商户账户，手续费另计。对账将渠道对账单与平台订单库比对，处理支付成功但出货失败、重复通知与退款差异。物联网设备订单量大、金额小，更依赖自动化脚本与异常告警。
文件格式
各渠道 CSV/Excel 字段不同，需映射与校验总额。跨日交易以渠道结算日为准。
风控
长短款超阈值需稽核；防止内部篡改订单状态。
物联网海量小单的对账策略
自动售货、共享设备与充电桩等场景订单笔数极高、单笔金额低，人工对账不现实。系统应按渠道、商户与清算日分区加载对账文件，先做总额校验再做明细勾对；对「支付成功未出货」「出货成功未支付」等异常建立独立队列与 SLA。跨日交易以渠道结算日为准时，平台订单时间戳与设备本地时钟可能不一致，需统一时区与夏令时规则。物联网设备离线缓存订单时，还要处理迟到的成功回调与重复通知，避免对账双边重复或漏记。
财务闭环与审计要求
对账结果应生成可导出凭证：渠道流水号、手续费、净额与商户应收，并与 ERP 或财务中台凭证号关联。长短款需区分技术原因、运营原因与欺诈可疑，分别走自动化调账或人工审批。内审与外部审计常抽查抽样方法与例外处理比例，日志需保留操作者与原因说明。涉及分账与多方结算时，还要核对各分润方应收与已开票金额，防止税务与资金风险叠加。
工程实践补充
将「清算与对账」与模组全生命周期结合：EVT 阶段验证参考设计与天线方案；DVT 阶段做传导/辐射摸底与热成像；PVT 阶段固化校准与测试脚本。认证前核对目标国别法规与运营商入库要求，避免频段或 SAR 项缺失。量产线保留金样比对与抽检规则；售后能根据序列号反查软件版本、校准参数与关键器件批次。若客户要求远程运维，需同时设计安全升级、回滚与应急停机策略。
清算日切与设备本地日切
清算是资金在渠道、机构和商户之间按结算周期划转，对账是在划转之前或同时，用渠道明细把每一笔平台订单找出来。对得上的进入净额，对不上的成为长款或短款。长款是渠道有钱、平台没有对应订单，短款是平台认为成功、渠道没有这笔。物联网设备的订单多、金额小，日终文件必须先对总金额和笔数，再对明细，否则一条解析错误会把全天标成差异。设备本地时钟、平台接收时间和渠道结算日是三个时间。跨日交易以渠道文件里的结算日为准，不能以模组上报时刻为准。
使用条件是每个渠道的字段映射固定，订单号在终端出账时就唯一，退款和正向支付能互相指向。离线终端恢复后补传的订单要标成「迟到」，进入下一轮或指定结算日，而不是改写已经封账的那一天。手续费和净额要分列，不能只比对用户支付金额。
迟到回调造成的双边记账
最常见的错是成功回调到了两次，第一次已出货入账，第二次又被当成新单。幂等键若用模组的重传次数而不是渠道流水号，补传必然重复。另一类是支付成功、出货失败，钱在渠道、货没出，对账程序只看支付状态就视为平账，短款留在客诉里。第三是退款按当天订单去冲，原交易在前一个结算日，回冲找不到原分录，变成永久长款。内部人员能改订单状态又没有原因和操作者记录时，外部文件对得平，账仍然不可信。
多方分润要在勾对之后再拆，不能用终端自己算的比例代替渠道实分，见 支付分账。码和银行卡混在一个结果位里时，渠道文件对不上本地订单，受理差异见 扫码支付。
日终任务要先锁住结算日，再接受迟到数据。锁住之后到来的成功回调进入下一日或挂起队列，并保留原渠道流水，不能改写已经出具的净额。总金额不符时先停止明细自动勾对，避免在错误的解析结果上生成几千条假差异。支付成功未出货、出货成功未见渠道记录、重复通知，应分成三个队列，处理时限和责任人不同。退款要指向原结算日的原分录，找不到原分录就作为例外而不是强行记一笔负向收入。操作者修改订单状态时必须留下原因，否则外部文件对平了，内部仍可能被改过。把渠道文件版本、解析规则版本和封账时间存在同一条记录里，次月复盘才知道差异来自规则变更还是来自设备补传。