uniprop-manual/prop-acc/scenarios/adhoc/audit-month-end-cash-reconciliation.md

---
title: prop-acc · adhoc · 场景 - 审计 - 月底现金对账
aliases:
  - prop-acc · 场景 - 审计 - 月底现金对账
  - 场景 - 审计 - 月底现金对账
  - 场景-审计-月底现金对账
tags:
  - 场景
  - prop-acc
  - 一次性收费
  - 业务场景
  - 审计对账
audience:
  - 业务人员
status: 已发布
sub_feature: adhoc
last_review: 2026-05-25
code_version: 2026-05-22
---

# 场景:月底现金对账

财务每月月底**核对前台收的现金**与**系统记录**是否一致。也叫"日结" / "月结"。

> [!info] 给谁看
> 主要给**财务人员**。业户不需要懂这部分。

## 典型情境

> [!example] 真实情境
> 5 月 31 日,物业财务王姐准备月度结账。她要核对一次性收费 5 月份**前台收的现金总额**是否等于**收银抽屉的实际现金**。

## 核心问题:三个数要对得上

```mermaid
graph LR
    A[A 系统记录<br/>CollectionOrder 表] --> D{对账}
    B[B 收据汇总<br/>Receipt 表] --> D
    C[C 物理现金<br/>抽屉点数] --> D
    D --> E[✅ 三方一致]
    D --> F[❌ 不一致 → 追查]

    classDef record fill:#dbeafe
    classDef physical fill:#fef3c7
    classDef result fill:#dcfce7
    classDef fail fill:#fee2e2

    class A,B record
    class C physical
    class E result
    class F fail
```

如果三者一致,**通过**。如果不一致,需要逐笔排查。

## 业务人员视角(财务)

### 步骤 1:拉系统数据

在 Filament 后台:

```
路径 1:CollectionOrders 列表
├── 筛选:collection_completed_at 在 2026-05-01 ~ 2026-05-31
├── 筛选:collection_type = AdHoc
├── 筛选:payment_method = "现金"
└── 求和:actual_amount

得到 → A 系统记录(现金部分)
```

或直接走 SQL:

```sql
SELECT
    COUNT(*) AS 订单数,
    SUM(actual_amount) AS 现金总额
FROM acc_collection_orders
WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND collection_type = 'ad_hoc'
  AND payment_method LIKE '%现金%'
  AND status = 'completed';
```

### 步骤 2:对照 Receipt 表(验证内部一致)

```sql
SELECT
    COUNT(r.id) AS 收据数,
    SUM(r.amount) AS 收据总额
FROM acc_receipts r
JOIN acc_collection_orders co ON r.collection_order_id = co.id
WHERE co.collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND co.collection_type = 'ad_hoc'
  AND co.payment_method LIKE '%现金%'
  AND r.status = 'issued';
```

**A 和 B 应该完全相等**(因为每笔订单生成一张收据,金额完全对应)。如果不等 → 数据库不一致问题,**严重**,要技术介入。

### 步骤 3:点物理现金

财务到前台:
1. 打开收银抽屉
2. 数所有钞票 + 硬币
3. 减掉初始备用金(通常 ¥500-1000)
4. 得到 C 现金部分

### 步骤 4:对照 A vs C

| 情况 | 含义 | 处理 |
|---|---|---|
| **A = C** | ✅ 完美对账 | 月底归档,提现到银行 |
| **A > C**(系统多)| 现金少了 | 找差额:可能丢失 / 找零错 / 员工挪用 |
| **A < C**(现金多)| 现金多了 | 找差额:可能少录单 / 找零少给 / 业户给多了没退 |

差额 ≥ ¥10 都要逐笔排查。

### 步骤 5:逐笔排查(差额情况)

```
1. 列出所有现金订单清单(订单号 + 金额 + 时间 + 业户)
2. 对照前台手工日志(如果有)/ 监控录像
3. 找到可疑的几笔:
   ├── 录入时间晚了几小时(可能延后录入)
   ├── 金额特殊(整数 / 没零头)
   └── 业户名字可疑
4. 联系业户 / 当事员工核实
```

## 多渠道场景

实际场景不只有现金。一次性收费可能有 5+ 种支付渠道:

| 渠道 | 对账依据 |
|---|---|
| 现金 | 收银抽屉点数 |
| 微信支付 | 微信商户后台流水 |
| 支付宝 | 支付宝商户后台流水 |
| POS 刷卡 | 银行账单 |
| 银行转账 | 对公账户流水 |

**每种渠道独立对账**:

```sql
SELECT
    payment_method,
    COUNT(*) AS 订单数,
    SUM(actual_amount) AS 总额
FROM acc_collection_orders
WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
  AND collection_type = 'ad_hoc'
  AND status = 'completed'
GROUP BY payment_method;
```

输出例:
```
现金       125 笔  ¥3,820
微信       42 笔   ¥1,260
支付宝     18 笔   ¥540
POS刷卡    8 笔   ¥280
─────────────────────────
合计       193 笔  ¥5,900
```

财务对照每个渠道的外部对账单。

## 系统流程

```mermaid
sequenceDiagram
    participant 财务
    participant Filament/DB
    participant 前台
    participant 微信商户
    participant 支付宝商户
    participant 银行

    财务->>Filament/DB: 月度筛选 + 求和(按支付方式)
    Filament/DB-->>财务: 各渠道金额

    财务->>前台: 点物理现金
    前台-->>财务: 抽屉总额

    财务->>微信商户: 查流水
    微信商户-->>财务: 微信总收款

    财务->>支付宝商户: 查流水
    支付宝商户-->>财务: 支付宝总收款

    财务->>银行: 查对公账单
    银行-->>财务: 转账 + POS 流水

    财务->>财务: 逐渠道对账
    财务->>财务: 不一致逐笔排查
```

## 常见问题

> [!question] 系统多了 ¥30,可能是什么原因?
> - 业户付完拿走货,职员忘了给找零(¥50 收 ¥20 商品,找零给少了)
> - 当天工作交接,前班的现金没全部移交
> - 销售退款没退,系统已记作废但前台没退现金给业户

> [!question] 系统少了 ¥50,可能是什么原因?
> - 漏录单(收了钱忘录系统)
> - 找零给多了
> - 业务人员临时挪用(严重,要核查)

> [!question] 每次差几块钱(< ¥10)能忽略吗?
> **不建议**。差小钱不一定是 bug,但**长期累积** + **不追究** = 内部审计黑洞。建议:
> - 差 < ¥10 也记录追查
> - 差 ≥ ¥100 当周必查清

> [!question] 业务人员能修改历史订单的支付方式吗?
> **不能**(订单 Completed 后不可编辑)。如果发现某笔订单的 payment_method 录错(比如填了"现金"实际是"微信"),走 [[场景-已收款作废]] + 重新录入。

> [!question] 月底前的几小时高峰怎么处理?
> 5 月 31 日 23:59 录入的订单 vs 6 月 1 日 00:01 录入,在 SQL 里**严格按时间戳归属**。建议月底前后 30 分钟**减少操作**,避免跨月归类争议。

## 月度报表的标准格式(建议)

```
=== 一次性收费 2026 年 5 月对账报告 ===

【系统数据】
现金:    ¥3,820  (125 笔)
微信:    ¥1,260  (42 笔)
支付宝:  ¥540    (18 笔)
POS刷卡: ¥280    (8 笔)
─────────────────────
合计:    ¥5,900  (193 笔)

【外部数据】
收银抽屉点数:        ¥3,820  ✅
微信商户后台:        ¥1,260  ✅
支付宝商户后台:      ¥540    ✅
银行 POS 入账:       ¥280    ✅

【差额追查】
无

【作废订单(对照)】
本月作废:   3 笔  ¥150
其中 Pending 作废:  2 笔(超时/撤单)
其中 Completed 作废: 1 笔(已退款 ¥30,银行原路)

【签字】
财务:______ 物业经理:______ 日期:______
```

## 相关概念

- [[概念-CollectionOrder与Receipt]] — 三件套数据是对账的核心
- [[场景-A流-前台购买IC卡]] — 现金交易的入口
- [[场景-B流-小程序下单+微信支付]] — 微信渠道数据来源
- [[场景-B流-小程序下单+支付宝]] — 支付宝渠道数据来源
- [[场景-已收款作废]] — 作废订单对对账的影响