做海外版外卖系统，财务把对账表下载下来，和后台屏幕上的合计对不上，先不要改金额。多数是两边用的条件不一样：一座城还是全部城、含不含试单、含不含未付款、截止到哪一天。条件不同，数字就不会相同。
一、对不上时先对条件，不要先改数
后台屏幕若默认看着「今天全部进行中的单」，下载若默认只给「已经付款的正式单」，两边本来就不是同一笔合计。差额里通常躺着试单、待付款，或另一座城的单。
先把屏幕的筛选改成和下载相同，再比数字。改完仍不一致，才去查有没有单被记了两次。一开始就改某一笔的金额，会把真正的差额掩盖掉，下周更对不上。
客服看到的详情和财务拿到的表，应能用同一个单号对上金额和币种。对不上单号，是取数范围的问题。单号在、金额不同，才是这一笔本身记重或记少。
二、下载和查询要共用同一套条件
下面这段把「屏幕」和「下载」绑在同一组条件上。少写一条，两边就会各算各的。
对账时两边必须相同的条件 哪一座城，不能一边是全部城 试单：正式表默认不要 付款：只要已经付款的 时间：从哪一天到哪一天，含首尾要写明 币种：不同的币不要加在同一个合计里 表上至少这些列 单号 付款时间 金额 币种 所属的城 试单标记 同一单号只出现一行 重复的付款结果不要变成第二行屏幕上能看见的进行中订单，可以继续留在过程查询里，但不要混进这张正式对账表的合计。过程查询和正式表可以同时存在，标题上写清自己是哪一种。
条件宜显示在表的抬头，例如城的名称、起止日期、是否排除试单。没有抬头，财务隔天就忘了这次下载看的是哪一座城。
三、试单和未完成单怎样离开合计
试单即使付过小额，默认也不进正式对账表。它应出现在过程查询，并带着试单标记。财务若把过程查询的笔数拿去和正式表比笔数，一定会少，这是预期的少，不是丢单。
待付款的单还没有钱回来，不能算进已收。商家已接但用户未付的，同样留在过程里。只有付款结果已经写回这一单，才进入正式表。
不要用「大概是试单」在表外口头扣除。扣除必须是表的条件做掉的，这样换一个人下载，得到的还是同一个数。口头扣除无法复查。
四、两座城不要下成一张无法拆开的表
海外两座城的币种可能不同，营业日也可能不同。下载时若不选城，两座城的金额会被加在一起，后台若正停在其中一座城的页面，数字必然对不上。
默认宜先选一座城，再下载。需要全部城时，表内按城分小计，不要只有一个总数。币种不同的小计不要相加。相加之后的数，既不是这座城的营收，也不是那座城的营收。
订单上的城以生成时记下的为准。后来把商家从一座城改到另一座城，旧单仍归下单时的城。否则历史对账表会随着商家搬家而变数。
五、退款和重复结果只能动一次
用户退了一笔，正式表里应能看到这笔退款对着原单号，金额回到未收或单独成一列负数，规则要事先说定，并且屏幕详情用同一说法。不要表上减了、屏幕上还显示原来的已收，也不要反过来。
同一次付款结果若被送了两遍，表上只能留一行。第二遍再插入，下载的合计会比后台多一笔，看起来像多收了钱。处理重复时只追加一条「重复已忽略」的说明，不新增金额。
退款和重复不要写在同一步里互相覆盖。先保证一行只代表一笔付款，再在这一行旁边记退款。盖掉原金额，就失去对账的起点。
六、语言和收款不要改在对账这一层
改菜单语言，不应改已经付款的金额，也不应让对账表少行。对账表读的是订单上的金额、币种和付款时间，不读今天的文案。文案更新后，旧单的金额必须仍能下载到。
各国支付和税务说明不同，按当地需要单独对接，不要在对账表里写死某一套税制。表负责把订单上已经发生的金额列清。票据上如何写税务，由客户按当地要求另定，不在这张表里临时发明一种算法。
收款没回到订单上时，不要为了让表「好看」手工补一行。补行没有单号来源，下次下载又会消失，差额会反复出现。
七、用同一天的数做一次验收
选定一座城、一个日期、排除试单、只要已付款。先在后台用这四个条件看合计和笔数，再下载。笔数相同，合计相同，抽三笔单号的金额和币种也相同，这张表才算和后台对齐。
四个条件改任何一个，都要预期合计会变，并说得出变在哪一类单上。说不出，就还不能把表交给商家对账。光合同城按私有化源码交付，订单和对账取出都在客户自己的机器上。系统侧不抽成客户平台订单，商务结算由客户确定。
