行程完成不等于账目结清：车费、收款与司机费用怎样分开核对

一个已完成，回答不了四个金额问题

机场接送或包车结束后，调度可能已经把任务标记完成，财务却还在等收款凭据和停车费申请。如果整个流程只有一个完成状态，同事容易误以为客户已经付款，或司机款项已经核对，但这两件事其实都还没有得到确认。

至少要分开四个问题：双方约定的车费是多少；实际收到并核实了多少；按约定适用的司机佣金是多少；哪些费用申请已经审核。每项金额应有自己的名称与依据。司机填入一笔费用，不代表公司已经批准，更不代表系统可以直接扣款。

这里讨论的是营运核对记录，不是会计、税务或薪资建议。以下计算刻意简化；实际结算必须考虑合约、谁收款、谁垫付费用，以及企业正式批准的财务流程。

先建立一份小而清楚的核对记录

用一项 RM 680 的虚构任务，保留每个数字的含义

假设约定车费 RM 680，已核实收款 RM 680，示范采用固定司机佣金 RM 162，已批准过路费 RM 38。另有 RM 20 停车费申请仍待审核。本演示显示的核对余额，是收款减佣金，再减获批费用：RM 680 − RM 162 − RM 38 = RM 480。

如果停车费后来获批，示范余额变为 RM 460。重要的不只是数字变了，而是有一次批准决定。实际记录应保留原申请、审核人和获批金额；若只批一部分，也应看得出申请与批准的差别。

现在把已核实收款改成 RM 260，并保持两笔费用已获批，示范余额变为 RM 260 − RM 162 − RM 38 − RM 20 = RM 40。客户尚欠的车费仍是 RM 420。若只给老板看一个净额，却不同时显示未收款，容易让他误解这项任务的真实收款情况。

为什么这个余额不是利润，也不是付款指令

这是帮助理解流程的核对余额，不是利润表。它没有涵盖所有运营成本、分摊、税务处理、退款或调整，也没有说明已经收到的钱由谁保管。司机代收现金，与客户直接付到公司，可能产生不同的公司和司机之间的交收安排。

在实施结算功能前，应先由企业财务负责人把收款与付款规则说清楚。司机持有款、公司持有款、获批报销及建议支付金额，应分别命名。公开演示不能作为扣薪、扣款或支付佣金的依据，不能因为屏幕出现 RM 460 就认定应向某人付款。

谁收了车费，谁先垫付了费用？

公司收到 RM 680，与司机代收 RM 680，虽然客户付款金额相同，但钱所在的位置不同。应把收款人和后续交收分别记清楚。演示中的 RM 460 核对余额，不能决定真实款项该由谁付给谁。

每笔费用申请用独立编号，关联行程、垫付人、付款凭据、审核人和获批金额。关闭事项之前，再核对是否已经报销。这是建议验证的记录管理方法，不是转账指令，也不是公开演示正在执行的付款功能。

改派记录，在行程结束之后仍然重要

最初收到任务的司机可能拒单，后来由另一位司机完成。保留拒绝与替换过程，审核人才能确认实际安排以及为什么发生变化。不能因为第一位司机的名字最早出现在订单里，就自动认定佣金属于他。

费用申请也应对应到相关的人与那次安排。改派前提交的过路费，需要有人判断它代表什么；把任务转给另一位司机，不应该自动把所有费用也转过去。演示保留拒单历史，但没有实现所有合约与费用归属场景，这部分必须在正式项目中单独定义。

结清之前，把剩余动作交给明确的人

第一版真正有用的功能，往往是从任务完成到费用核对之间可靠的交接，而不是自动付款。先把金额定义与审核责任确定，再把系统对接或付款执行作为独立、需要明确授权的范围。

本例来自本站独立接送演示中可核对的计算逻辑，参考既有内部开发项目后改编。所有金额和记录都是虚构示例，不是客户成绩，也不是行业收费标准。

1. 让行程保持已完成，同时保留待审费用，确认两个状态不会互相覆盖。
2. 分别测试全额付款与部分付款，客户尚欠金额必须清楚保留。
3. 正式设计中测试只批准部分费用，并分别保留申请金额与获批金额。
4. 拒单后重新派车，核对实际执行人员，再按已约定的规则处理佣金。
5. 每项未核实收款或费用申请都安排负责人，不为清空仪表板而随手标记结清。