先讲结论： homestay 打款对帐，就是拿 OTA 的打款结算单，把每一行用订单确认码对回订单，检查所有行加起来等于银行实际收到的数，最后才入帐。纯手工做又慢又容易错。我们的 PMS（AntlerHub）负责比对，入帐前留一个人按的确认。
讲这个题目的文章，大多是写给用 QuickBooks 的美国短租经营者。这篇是写给马来西亚经营者的：你有 Airbnb、Agoda、Booking.com，银行户口里只看到一行「AIRBNB PAYMENTS」，没有任何说明。下面讲我们自己的系统怎么处理，包括不那么漂亮的部分。
为什么 Airbnb 一笔打款这么难对？
因为银行只看到一个数，OTA 看到的却是好几张订单。一般来说，Airbnb 大约在入住时间之后 24 小时放款（住宿不满 28 晚），银行再过几天才显示（见 Pass the Keys）。做物业管理软件的公司也讲过同样的难处：几张订单被捆成一笔入帐、手续费和调整在放款前就扣掉、某张订单的扣款还可能从另一笔打款里扣（见 VRPlatform）。
下面是一个虚构的例子，数字不是真的，只是示范问题长什么样：
| 订单（确认码） | 你实收 |
|---|---|
| 订单 A | RM 1,240.50 |
| 订单 B | RM 862.00 |
| 订单 C | RM 1,455.90 |
| 订单 D | RM 304.00 |
| 银行入帐 | RM 3,862.40 |
银行显示 RM 3,862.40。你的订单表有四张订单，每张有毛价，抽佣要自己算。如果讲不出是哪四张订单凑成这个数，你就没办法确定有没有少收钱。
打款结算单里面到底有什么？
每家 OTA 不一样，这是第二个麻烦。
- Airbnb 导出的档案，是一行「打款」后面跟着它覆盖的订单行。分组靠位置：打款行后面的订单行，就属于那一笔打款。
- Agoda、Booking.com、Expedia、携程／Trip.com 给的是平铺的清单，而且每次导出栏位名称可能改。Booking.com 的打款结算单和 Expedia 的汇款通知还是 PDF。
- 日期是个陷阱。07/08/2026 在一个平台是 8 月 7 日，在另一个平台是 7 月 8 日。
我们的读取程序能读 CSV、Excel 和 PDF。它按栏位标题找栏位，不靠第几栏；遇到有歧义的日期，先按 Airbnb、Expedia、Agoda 导出的习惯读，再标出来，不会默默选一个。读取程序自己不做任何决定：它只报告「我觉得这个档案写的是什么」加上警告，最后由人确认。
一行结算单，怎么对回订单？
先用确认码，因为这是两边唯一都有的编号。系统拿确认码去对已经从渠道管理系统拉进来的订单。
有些结算单没有印确认码。这时候的备用办法是客人姓名加入住日期，而且两样都要吻合。如果有两张订单同名又同一天入住，系统不会乱猜，而是标成「对不上」，提示你手动连结，因为连错了会悄悄把钱记到错的订单上。
对不上的行不会卡住整批。银行那笔钱是真的，不管你讲不讲得出背后每张订单。所以这行照样导入、加旗标、留着能找到；你想排除，也可以把勾拿掉。
同一份结算单、或同一张订单出现两次怎么办？
这比想象中常见：你导出的日期范围有重叠，或者 OTA 用新的编号重发一笔更正过的打款。有两层保护。
- 打款本身不能重复。 一笔打款由经营者、平台和 OTA 的打款编号决定。同一份结算单再导一次，还没入帐的会更新，已经入帐的不会去碰。档案没有编号的（Trip.com 就没有），系统用平台、日期和金额自己做一个编号，并检查同一笔钱是不是已经在帐上了。
- 每张订单记得是哪一笔打款结清的。 如果一行对应的订单，早先的打款已经付过了，会在草稿上贴标签，让你在确认之前就看到。
有一个老实话要讲：Airbnb 有时把长住订单分两次打款。这是正常的，所以第二期照样计入，但会标成「早前已付过」，让你分得出是分期还是重复。Airbnb 也可能在同一笔打款里，把房费和代收的税分成两行，所以系统先按订单把几行加起来，再记录这张订单。
哪些订单在范围内？
只有你叫系统从哪天开始的订单。每个经营者有一个上线的入住日期，入住日期等于或晚于这一天的订单会被对帐、上锁，并算进「OTA 还欠你的钱」。入住日期早于它的订单，仍会显示和记录，但不连订单、不上锁。
原因是边界问题。跨过上线日期的住宿，一半是旧帐、一半是新帐，这样切开来怎么记帐没有共识。我们选择不连结，也不自己发明规则。新开的工作区预设是它开始的那一天，你可以在结算页面改。
入帐的是什么？
实际到手的钱。分录是：借银行，贷平台代收款户口。如果结算单另外写了 OTA 的佣金，佣金就记成开支，银行那一行是净额。
对会计师重要的一点：订单成立时，我们不会为每张订单开一张「Airbnb 欠我们 RM X」的应收款。OTA 是向客人收钱、扣掉自己的佣金再净额打给你，所以不用编造数字就能说得出的，只有实际到手的那个数。如果你的会计师想要每张订单一张毛额发票，那是跟我们不一样的设计。
两个实际的点：
- 入帐是进 Bukku，所以必须接好 Bukku 账号，并设好银行户口对应。没有的话，这笔打款会停在待处理，附上看得懂的错误讯息。
- 每笔入帐都带 OTA 标签，还附一份它所覆盖订单的表格，一年后「Airbnb 进了 RM 3,862.40」还是答得出「是哪几晚」。
Agoda 还有一个限制：Agoda 一份打款档案里，Agoda Homes 和 Agoda YCS 的订单混在一起，档案里没有东西能分开，所以结算时当成一个「Agoda」。Trip.com 和携程同样算一组。
为什么要有「草稿＋确认」，不是全自动？
因为结算单是人拿来的档案。人会拖错工作表、拖错月份，或把同一个档案拖两次。所以解析之后得出的是一个草稿批次，由你看、你确认。只有按了确认，才会写入打款和分录。
按确认后会马上返回，由后台作业去入帐，每笔打款一次会计系统来回。一份结算单可能有几百笔，不应该让浏览器分页决定你的帐完不完整。如果服务器中途重启，没入帐的打款只会留在待处理，有个重试作业会把待处理或失败的捡起来。
还有什么会出错？
- 档案格式变了。 OTA 会改栏位名称。读取程序能应付同义词，但真的全新的版面，就会有警告，需要手动修。
- 缺打款日期，多半出在 PDF。要先填钱到帐的日期才能入帐。
- 银行入帐跟结算单对不上。 这正是对帐要找出来的，但也表示得有人去跟 OTA 追差额。
- 系统里没有价格的订单，算不进「还欠你的钱」。它们会在另一个数字里列出，让你去补。
一个实际可行的做法
- 每星期，或每次大笔打款之后，从每家 OTA 下载一份结算单。
- 上传后先看草稿：先看对不上的行，再看标了「早前已付过」或「范围外」的。
- 把草稿总额跟银行入帐比一比。
- 按确认。几天后看一下待结算概览，就知道每家 OTA 还欠多少。
如果你有 10 间以上还在用表格做这件事，可以看我们的 PMS 对 Excel 比较；钱对好之后的事，看每月屋主月结单怎么出。想在自己的单位上跑这套，AntlerHub 和价格在 /antlerhub。
这篇文章讲的是我们的软件怎么记录数字，不是会计或税务意见；公司怎么记 OTA 收入和佣金，请跟你自己的会计师确认。