只看「今天收了多少钱」，永远查不出问题。钱少了可能是掉单，也可能是有人跳过支付；钱对上了，也可能是两笔错账刚好抵消。真正的对账，是让三个来源的数字互相印证。
这三本账分别来自三个不同的系统，出错的方式也各不相同。三个数一致，说明这一天是干净的；有差异，差异本身就是线索，指向哪一环出了问题。
对账的另一个作用是发现设备异常。出杯数远高于订单数，可能是有一单被重复执行；订单数远高于出杯数，可能是出杯环节卡了。这两类问题在对账表上比在后台日志里更容易被发现。
第一本是设备端交易记录。每一笔下单、支付、出杯都记在设备本地和云端。这本账的特点是「最细」，能看到某一台设备在某一分钟做了什么。
第二本是支付通道的结算单。通道那边只认钱，不认设备。它记录的是「收到多少笔、每笔多少、扣了多少手续费」。这本账的特点是「最准」，因为它直接对应资金。
第三本是银行到账流水。通道结算之后打进账户的钱，会晚一到两个工作日。这本账的特点是「最晚」，但它是唯一能确认钱真的到手的依据。
三本账的关系是：设备端记录应该收多少，通道记录实际扣了多少，银行记录最终到账多少。日常对账主要是前两本的当天比对，第三本按结算周期核对。
掉单。用户付了钱、设备没收到回调，于是没有出杯或者出了杯但订单显示未支付。特征是设备端有这笔、通道也有这笔，但状态不一致。这类问题在弱网点位最常见。
重复扣款。用户点了一次，付了两次。通常是网络重试导致的。特征是同一用户在同一分钟内有两笔金额相同的记录。
超时未支付。用户下了单，一直没付，订单超时关闭。这类属于正常业务，但数量异常偏高时，说明支付入口的引导有问题，比如二维码贴得太远、提示不清楚。
退款失败。退了但没到用户账上。常见于原路退回时对方的支付账户状态异常。特征是退款单状态为失败或处理中，长时间不终结。
日结的关键不是算得多细，是每天都在同一个时点做同一件事。时点建议选在当天营业结束之后、跨零点之前，这样一本账对应一个自然日，不会跨天混在一起。
表格要固定几列：日期、点位、设备号、出杯数、订单数、实收金额、退款金额、异常单数、备注。列不要多，多了没人填。异常单单独列一栏，写明单号和处理结果，比在备注里写一段话有用。
差异处理要有明确的分数线：小额差异当天记下、周结时统一看；大额差异当天查。这条线定得越清楚，执行起来越不容易拖。
退款最容易吵架的地方不是「退不退」，是「谁说了算」。所以要提前把三种情况分开写清楚：设备原因（没出杯、出杯失败、出的是错的）直接退，不需要审批；用户原因（点错了、不想喝了）原则上不退，但可以给一次善意处理；责任不清的，先退再查，把用户体验放在前面。
审批权限也要定：一线可以处理小额，超过一定金额需要主管确认。金额线按点位的日均营业额来定，比拍一个固定数字更合理。
到账时间要提前告诉用户，别让人反复来问。原路退回通常需要一到三个工作日，这个时间差要写在现场的提示牌上，一句「1 到 3 个工作日原路退回」能省掉大部分追问。
一是拿设备端的金额当收入。设备端记的是应收，通道扣了手续费之后才是实收。长期用应收当收入，账面上会一直有一笔对不上的差额。
二是把退款和差错混在一起。退款是主动行为，差错是意外。两者记在同一个科目里，月底根本看不出问题出在哪。
三是只对金额不对笔数。金额对上了就放心，其实可能一笔多收、一笔少收刚好抵消。笔数一定要单独对，笔数对不上就是有问题。
起步阶段的建议：先只做「出杯数、订单数、实收金额」三项日对账，跑顺一个月之后再加入退款和手续费。一上来就做全套表格，往往坚持不过两周。
先按善意处理：当场补一杯或者直接退款，不要让用户等。事后再去后台核这笔单的状态。掉单本身多数是网络回调问题，把用户晾在那里等核实，损失的是口碑，省下的是几块钱。
常见三种：一是掉单之后设备仍然执行了出杯；二是重复回调导致同一单出了两次；三是有人通过维护模式手动出杯但没记单。把这三条按顺序排掉，基本能找到原因。