周五晚上，三家门店，满座。POS 显示全集团卖了 412,000 港元。然后钱开始陆续到账，却没有一笔看起来像 412,000 港元。

KeeTa 扣除佣金后净额结算；foodpanda 按另一套佣金、另一个周期轧差。八达通整批到账，扣掉手续费。AlipayHK 每天以一笔整数入账，费用和退款已经预先扣除。WeChat Pay HK 则按你签约的收单机构或聚合商的周期到账。银行卡收单方把 Visa 和 Mastercard 打包结算，扣除商户折扣率。现金就是保险柜里实际收到的那些。到了周一，财务面对十几笔加起来对不上 POS 数字的入账，总有人要打开一张表格来查原因。

麻烦……就是从这里开始的。不是因为做表的人粗心，而是因为对账的方向反了：把入账倒推回销售，而不是先入账销售、再用入账核销。

双寡头按自己的规则结算

香港外卖市场同时变得更简单、也更难了。Deliveroo 于 2025 年 4 月退出香港，结束九年经营，离场时把部分资产卖给了 foodpanda。

剩下的，算得上是一个双寡头格局。

美团旗下的 KeeTa 在上线十个月内夺得订单量第一，如今被普遍视为市场领导者；foodpanda 退居第二，但仍摆在每家餐厅的收银台上。在香港开餐厅，你往往两个平台都要上。遗憾的是，目前没有第三个有量的选择。地平线上最近的变数来自企业层面：Uber 在 2026 年 7 月同意收购 foodpanda 的母公司 Delivery Hero，交易预计在 2027 年下半年完成。

两个平台付钱的方式一样：订单总额，减去佣金，减去退款和调整，等于打款金额。你的收入是总额那个数，你的到账是净额那个数。两者之间的差额是实实在在的销售成本，应该作为一个看得见的行项目出现在损益表里。

不少经营者图快，直接把到账金额记作收入。账是平的，但有两件事悄悄出了问题：报表上的销售额低估了厨房实际的产出；而平台佣金——这门生意里最大、变动最快的成本之一——消失在一笔无人复核的轧差分录里。当佣金条款变了，或者某个平台的退款率悄悄上升，损益表里没有任何一行会动。你要到年底才发现。前提是你能发现。

再乘上电子钱包这一摞

外卖只是两个交易对手。堂食的支付方式组合更糟。

一家典型的香港餐厅接受的支付方式包括：八达通、AlipayHK、WeChat Pay HK、经收单机构的银行卡、FPS 转数快，以及现金。每种方式都有自己的到账节奏和费用机制：八达通商户按批次结算并支付手续费，AlipayHK 在每日整笔到账前先扣除费用和退款，银行卡收单对账单则把所有卡组织捆成一笔商户折扣扣款。FPS 是相反的问题：不分批、不轧差，只有几十笔没有批次号的实时入账。六种支付方式，意味着对“钱什么时候到、到多少？”这个问题有六种不同的答案。

Six tenders. Six arrival times.

When a Friday-night sale actually reaches the bank, by tender type. Same moment of sale — different arrival times, different shapes, different amounts.

Same Friday-night sale: FPS is in the account before the customer leaves. Cards and Octopus wait out the weekend and pile up Monday. Delivery money arrives weeks later — net of everything. That’s why the POS total never matches the bank.

Sources: HKICL (FPS), Octopus merchant FAQ, AlipayHK merchant FAQ, BOCHK acquiring schedules, Hang Seng merchant services, foodpanda partner terms. Card and WeChat Pay timing vary by acquirer; Octopus T+1 runs from transaction-data upload; delivery payout cycles per platform agreement. Delivery commissions reported at 28–35% (The Collective HK; Unwire, Mar 2025); KeeTa cadence not published.

再乘上门店数。一个经营八家餐厅的集团——往往还是八个独立法人——要把六种支付方式乘八家门店，对到可能开在不止一家银行的账户上。这才是问题的真实形状：不是一道很难的对账题，而是四十八道小题，每天都要做，永远做不完。

理想状态长什么样

行之有效的结构有点老派、毫不花哨：清算账户，每种支付方式一个、每家门店一套。

POS 每天按总额过一笔销售日记账：按门店和品类记销售，当天的营业款进入按支付方式细分的清算账户——KeeTa 一个余额、八达通一个、AlipayHK 一个，依此类推。结算款到账时，与对应余额核销；佣金和费用在同一时刻作为独立的费用行入账。没核销掉的部分留在清算账户里，清清楚楚——这正是你想要的：WeChat Pay 清算账户里 3,000 港元的未匹配余额，是周二就有人能回答的一个问题，而不是埋在净收入数字里、到审计时才被挖出来的谜。

在 NetSuite 里，这套流程的运转方式是：导入银行对账单，与清算账户匹配，对账规则完成大部分匹配工作。清算账户结构属于实施设计的一部分；它是我们在项目中搭建出来的，不是拨一个开关就有。对香港有一个诚实的提醒：NetSuite 的实时银行直连目前不覆盖香港的银行，对账单以文件形式进来——HSBCnet 及同类渠道的 MT940 或 camt.053——按计划导入，而不是实时流入。实际操作上就是每天跑一次导入。真正省下工作量的，是匹配、清算结构和可见性。

效果在月结时叠加显现。当每种支付方式全月都核销干净，月结就不再是一场重建。销售本来就是总额，佣金本来就看得见，差异账户已经告诉你漏洞在哪里，一家门店一家门店地列出来。

从哪里开始

如果你的集团回答“上周卖了多少”仍然需要一张表格和某个人的半天时间，问题就出在工作的方向上：入账被人手倒推回销售，而本该先把销售入账、再用入账去核销。

我们分别写过 NetSuite 如何处理各种结算格式：八达通、AlipayHK、WeChat Pay，以及汇丰对账单的往返流程。我们的 NetSuite 实施页面介绍了项目如何启动，包括动工之前的需求调研阶段；而调研的第一件事，就是梳理你的支付方式组合。

平台不会为你简化结算，钱包也不会。你唯一能控制的变量是：让你的账簿在设计上吸收这种复杂性，还是让某个人每周一在表格里重建它。