痛点：卖了多少是账面，钱在谁手上是另一件事
连锁门店的现金，是零售里最难管的一块。道理也简单：商品进出有进销存单子管着，唯独现金——从顾客递到收银员手里，到最终躺进银行账户，中间要经过好几个人、好几个地点、好几段时间。每一段都可能断线。
常见的断线，通常是这几种样子：
- 交班靠一张小纸条。早班收银员把一沓现金和一张手写纸条交给晚班，"今天大概八千二"。纸条丢了、钱数错了，两个人在收银台后面各说各话。到了周末盘账，才发现某一天的差额已经分不清是谁的班。
- 系统应收对不上实点现金，但没人深究。收银机上显示应收 8234 元，实际点出 8190 元，差 44 元。是谁收错了、找零错了、还是有人拿走了？当天不查，第二天就查不动了。差额被记在一张"待核"的 Excel 里，越攒越多，最后整张表没人敢打开。
- 缴了多少、进没进账，中间没人接。店长说"我周四去存了"，出纳翻银行流水发现金额不对，两边的记录都在，但一个记的是"缴存日期"，一个记的是"到账日期"，谁都没错，可就是核对不上。跨月的差款，到季度末才发现。
- 备用金和零钱箱是笔糊涂账。开业时给店里放了 2000 元零钱，中途换过店长，谁领的、还剩多少、有没有归还，只有当事人记得。年终结账时这笔钱挂在账上，无人认领。
- 差异没人收口。发现了差额，微信群里问一句"这天谁班上的"，被其他消息淹了。没有任何机制要求"差额必须有人解释、必须关掉"。于是同一家门店同样的差额反复出现，总部完全看不出规律。
这些问题的共同点不是人不负责，而是缺少一本按班次、按单据记账的现金流水账：谁在什么时间收了多少钱、点出来多少、钱交给了谁、什么时候进了银行、差的那部分谁解释的。这本账不需要替代财务软件，也不需要对接收银机——它要做的是把"钱在路上的每一段"留下可追的记录。
下面按"先划边界 → 数据怎么建 → 页面怎么用 → 自动化怎么接 → 手机端怎么配合 → 上线前查什么 → 之后怎么延伸 → 不做什么"的顺序讲清楚落地路径。这类台账用 Inkwell AI 构建器搭建，通常就是把表与表的关系、每个状态的含义、哪些数由系统算说清楚，剩下的交给平台生成带权限隔离的数据库结构和管理页面。
先划边界：这本账管现金流转，不管账务处理
任何线上化项目，最先要说的不是"能做什么"，而是"它到哪儿为止"。营业款这件事牵扯收银、店长、出纳、会计四拨人，如果一开始边界含糊，上线一个月就会变成"为什么它不能自动对银行流水"的抱怨。
| 营业款缴存对账（本文范围） | 不在本文范围 | |
|---|---|---|
| 记录对象 | 一次交班、一次缴存、一笔差异、一笔备用金动支 | 会计凭证、总账、报表 |
| 组织方式 | 按门店 + 收银点 + 班次 + 单据 | 按会计科目 |
| 使用者 | 收银员、店长、门店财务/出纳、区域经理、审计 | 会计师、税务申报 |
| 核心动作 | 交接登记、缴款登记、到账核对、差异说明与关闭 | 生成凭证、成本核算、报税 |
| 输出 | 门店交班明细、未缴/未到账清单、差异台账、备用金结余 | 财务报表与纳税申报表 |
还有三件明确不做的事，建议在上线宣导时一字不改地讲给门店听：
第一，不直连收银机（POS）和银行账户。 "系统应收"这个数不是从收银机自动抓过来的，而是人按班结小票/日结报表录入，或者从门店日结表导出后批量导入。银行到账也不自动回传，由出纳按流水登记。原因很实在：现金对账的价值在于"逐段留痕"，而不是"全自动";而每家连锁的收银系统型号、银行通道都不一样，硬做对接反而让项目卡在技术环节上不动。
第二，不做凭证图片的自动识别。 缴款单凭证、银行回执拍照上传后挂在单据上，金额由人填。系统不承诺从照片里读数字。
第三，不替代财务判断。 差额算不算异常、多少额度需要审批、盘亏怎么处理，以企业自己的财务制度为准。系统负责把差额算准、把原因问清、把过程留痕，不替你决定要不要追究。
把这三句放在前头，后面所有设计都会清爽：它是一本可查、可追、对得上的现金流水台账。
数据怎么建：五张底表，先把"一行代表什么"定死
AI 构建器的建模方式是：用业务话把表与表的关系说清，平台据此生成数据库结构与管理页面。这类方案最容易翻车的地方不是字段不够，而是一行的含义没想清——把"一次交班"和"一次缴存"塞进同一张表，或者把系统应收、实点现金、差额并成一个"金额"字段，统计一定重复计数，差额也永远算不清。
推荐五张底表，每张只管一件事。
1. 门店与收银点档案。 一行一个收银点（前台 1 号台、2 号台、后场收银），上级关联门店。字段：门店编码（唯一约束，防止"XX 店"和"XX 门店"建成两个）、门店名称、区域（引用区域表）、收银点编号、是否有独立金库、启用状态。这张表只被引用，不存任何金额——金额一旦落到档案上，就会变成第二本账。
2. 交接班记录（主表，一次交班一行）。 这是整套方案的核心表。字段：门店、收银点、班次（字典：早班/中班/晚班/通班）、班次开始与结束时间、交班人、接班人、系统应收金额、实点现金、差额（由系统算，不手填）、差异原因、班结小票附件、记录状态。
3. 缴款单（一次缴存行为一行）。 字段：门店、缴存日期、缴存方式（字典：现金存银行 / 转账 / 内部上缴总部）、缴款金额、缴款人、银行流水号或凭证号、银行到账日期、凭证照片、关联交接班记录（可多选）、状态（字典：待缴 / 已缴待核 / 已到账 / 差异 / 已关闭）。
4. 差异记录（一条差异一行，只增不改）。 字段：差异类型（字典：交班差额 / 缴存差额 / 到账不符 / 备用金短少）、关联交接班或缴款单、差异金额、发现日期、责任门店与班次、原因说明、处理方式（字典：补缴 / 员工承担 / 找零误差核销 / 待查 / 其他）、复核人、关闭时间。
5. 备用金台账（一次动支一行）。 字段：门店、动支类型（字典：设立 / 追加 / 归还 / 报损）、金额、经办人、审批记录引用、发生日期、余额（由系统按流水汇总得出，不手填）。
表间关系一句话概括：门店向下挂收银点，收银点向下挂交接班记录；缴款单引用一到多条交接班记录；差异记录挂在其发现的那张单上；备用金按门店独立成流水。 档案是档案（只被引用）、交接与缴款是单据（有状态、走审批）、差异与备用金是流水（只增不改）。三类东西的"脾气"完全不同，混在一张表里就等着出错。
关键设计决定：六个必须先想清的取舍
上面五张表看起来平平无奇，真正决定这套账能不能用的，是下面六个取舍。它们都是"上线前想清楚一分钟，上线后省一个月争吵"的类型。
决定一：一次交班一行，绝不按天合计。
很多门店的习惯是"一天记一笔"，一天的钱合在一起交给店主。这样做的后果是：一旦差钱，责任范围是三个班次、五六个收银员，查不出人。所以主表必须细到班次：谁交的、谁接的、从几点到几点。日汇总由系统按门店 + 日期把班次合起来看，不需要手工合计。
决定二：系统应收与实点现金分两列，差额由数据流规则算出来。
绝不能只有一个"金额"字段，也绝不让人手填差额。三列分开：系统应收（按班结小票录入）、实点现金（点钞机或人工点出）、差额（实点 − 应收）。差额不填，由平台的数据流规则在保存时计算；差额不为 0 时，原因字段变为必填，不填不许提交。这一条挡住了"先交上去、事后再说"这条最常见的漏洞。
决定三：交接与缴存拆成两张单，因为它们的时间粒度不一样。
店内交接是每隔几小时发生一次的动作，缴存是按天甚至按几天去银行一趟。硬塞进一张表会出现两个问题：要么金额被重复统计（一次缴存对应三次交班，缴款金额填三遍），要么差额算不清（到底差在哪个环节说不明）。拆开后用"缴款单引用多条交接班记录"来解决，并在页面上直接显示"这笔缴款覆盖了哪几个班次、合计应交多少、实缴多少"。
决定四：差异独立成表，靠"填原因才关闭"收口，不靠状态或备注。
这是整套方案里最容易被简化掉、也最不应该简化的一条。差额发现了就在交接班记录的备注里写一句"差 44 元"，等于没记：三个月后统计"哪家门店差额最多"，答案不存在。把差异立成独立主表后，一条差异有明确的生命周期——发现 → 待说明 → 已说明待复核 → 已关闭，每条都带金额、班次、责任门店；统计时按门店、按区域、按差异类型一筛就有。备注字段只用来写补充说明，不承载流程。
决定五：备用金与营业款分账管理，但余额由系统汇总。
备用金是长期趴在店里的钱，营业款是每天要归集的钱，两者的生命周期完全不同。合在一起记，备用金会被日结金额反复"冲掉"。所以单列流水表：设立、追加、归还、报损各起一行，只增不改，余额由系统按流水累计。换店长时不是改"现有余额"，而是新增一条交接记录。
决定六：状态值一次定死，统一走数据字典。
交班状态、缴款状态、差异状态、差异类型、处理方式，这些选项都进平台的数据字典集中维护，不在字段里散落写死。原因很实际：一旦选项被人随手改成"已核""已确认""已处理完"三种写法，列表筛选就永远筛不干净。数据字典的做法与维护方式见 数据字典：管好下拉选项的统一口径。
页面怎么用：四类角色，四种视角
同一套数据，收银员看到的和区域经理看到的必须是完全不同的东西。按角色切页面，是这类系统能不能被真正用起来的分水岭。
收银员：交班填报（以移动端为主）
核心诉求是"快"，三十秒内能交完班。页面上只有几件事：选门店与收银点（默认带出本人所在店）、选班次、填系统应收（按班结小票上的数字）、填实点现金，附件区拍班结小票。差额由系统算出来显示在下方，如果非 0，弹出原因输入框。
设计上要注意两点：一是默认值尽量替人算好（班次按当前时间预填、门店按账号归属预填），二是上一班未结的提示要显眼——"上一班有 1 条差异未关闭"这种提示放在提交按钮上方，比放在通知里有效得多。
店长：本店当天的事，一屏看完
店长的页面是一张按日期排列的本店工作台：今天几个班次、每班是否已交、合计实点多少、与系统应收差多少、有没有缴款单没开、有没有差异没说明。常用动作三个：审核接班、开缴款单、填差异原因。
开缴款单是店长最高频的动作，所以页面要能"从交班列表直接勾选生成"——勾上今天的三笔交班，系统带出合计应交金额，店长只补填实际缴存金额、缴存方式、凭证照片，减少手抄错误。缴存金额与应交金额不一致时，页面直接提示差额并引导生成差异记录。
门店财务 / 出纳：总部视角的核对与收口
出纳的活是核对与催办，页面按这个逻辑组织：
- 待核缴款清单：状态为"已缴待核"的单子，逐条登记银行到账日期与流水号，到账金额不符可直接生成差异记录。
- 差异台账：全部未关闭的差异，按门店、区域、金额、发现日期排序，默认按"超期天数"倒序，最该催的排最前面。
- 门店对比视图：按区域看各门店的差额发生率、平均差额、未缴存天数，用于判断哪家店需要盯。
- 备用金余额表：每家店当前余额与最近一次动支时间，长期未动的单独列出。
区域经理与审计：不看单据，看规律
区域经理不需要看每一张交班单，他需要的是"哪几家店在反复出问题"。所以给一张按区域汇总的视图：门店数、本月交班笔数、差异笔数与金额、差异处理平均时长、超期未缴笔数。审计角色则要的是可查与可导出：按门店、按日期区间、按差异类型筛出的全量明细，以及每张单据的修改留痕（平台的操作审计日志会自动记录谁在什么时候改了哪条记录）。
权限上，收银员只能看本收银点，店长看本店，出纳看全部但只看现金相关模块，区域经理看本区域。角色与权限的配置方式见 角色与权限配置：从内置角色到自定义授权。
这几套页面之外，如果门店同时还在用门店稽核与进销存，可以互相引：稽核发现的"现金管理不规范"可以直接生成整改单（见 门店督导巡店稽核：检查表、扣分与整改跟踪），而每天的系统应收口径要与门店实际销售对上，这个数来自门店进销存的日报（见 零售门店进销存：从一句话需求到双端上线）。三者分工清晰：进销存管"货"，稽核管"标准执行"，本文这套账管"钱"。
自动化怎么接：四类规则，把"人记得"变成"系统不让忘"
台账类系统上线后最常见的失败形态，是"大家都在录，但录完没人看"。真正让它活起来的，是四类自动化。平台侧对应的是数据流规则、审批流、定时任务与通知四块能力，配置方式可参考 工作流与定时任务：让重复性工作自动跑。
第一类：保存时校验（数据流规则）。 这类规则在单据保存那一刻执行，不合规直接拦下，而不是事后发个提醒。建议至少配这几条：
- 差额 = 实点现金 − 系统应收，由系统计算；差额 ≠ 0 且原因为空时，拒绝提交。
- 缴款金额 ≤ 该缴款单引用的交接班记录合计应交金额；超出时不拦截但要求填写说明（因为确实存在多日合并缴存的情况）。
- 交接班记录未审核通过时，不得被缴款单引用。
- 备用金报损金额不得超过当前余额。
- 门店编码、收银点编号做唯一约束，重复建档直接拒绝。
校验的价值在于"先拦后记"：只在事后发提醒的做法，最终会得到一堆没人处理的提醒，业务方也就不再信任提醒。
第二类：分档审批（审批流）。 不是所有单子都要审批，全量审批会把店长和区域经理都拖死，最后大家学会"闭眼点同意"。建议按风险分档：常规交班由店长审核即可；差额超过企业自定的容忍额度（这个数由财务制度定，系统不设默认值）时才触发区域经理审批；备用金设立与报损单独立审批；差异记录的处理方式选"员工承担"时走一条专门的确认流程。
第三类：定时任务。 定时任务负责的是"每天自动把该提醒的东西摆到人面前"，建议配三类：
- 每日班次结束后生成"未交班/未开缴款单"清单，推给店长与出纳。
- 每周生成差异汇总，按门店排序推给区域经理。
- 每月月末生成对账清单：本月应交合计、已缴合计、在途未到账合计、差异未关闭合计，作为月度盘账的起点。
定时任务只负责生成与推送，不做任何金额改动——这条边界要守住，否则一旦任务配错，历史数据会被批量改写。
第四类：通知。 差异记录生成后通知店长与区域经理；缴款单超过企业设定的在途天数仍未到账，通知出纳与店长；备用金余额低于警戒值，通知门店负责人。通知走站内信为主，重要节点（差异超期、金额较大）可叠加短信，具体通道按企业实际开通情况配置。
移动端怎么配合：店员和店长在店里就能完成
现金相关的动作绝大部分发生在店里、发生在收银台后面，所以移动端不是可选项。落地要点三条：
一是核心录入放手机。 交班填报、差异原因说明、缴款单拍照上传三件事必须在手机上能完成。拍照上传是这里的刚需——凭证照片必须当天拍、当天挂到单据上，隔天补拍就常常拍不到了。
二是门店档案与收银点做默认带出。 收银员的账号绑定门店后，打开页面就看到本店本收银点，不用一层层选。
三是网络不通时先走纸面。 门店网络不稳定是常态。设计上明确一条：网络不可用时按纸质交班单填写、拍照留存，恢复后由店长在 PC 或手机端补录，补录时在备注里写明"补录"。系统不承诺离线填写与自动同步，这一点要在上线宣导时讲清，避免门店以为"断网也能用系统"。移动端的整体使用方式见 移动端使用指南：工作台、模块页与手机上的 AI 构建。
上线前查什么：八条核对清单
系统搭好、页面调通，不等于能上线。下面八条是我们建议在正式启用前逐条过一遍的，每一条都对应一个上线后最常见的返工原因。
- 门店与收银点档案齐不齐、编码唯一不唯一。 先把全部门店按统一编码规则建好（区域 + 序号），并确认没有因简称不同造成的一店两档。
- 状态与类型字典是否一次定死。 交班状态、缴款状态、差异类型、处理方式四组字典，上线前锁版，之后新增值要有人审批。
- 系统应收的取数口径写下来了没有。 到底取班结小票的哪个数（含退款后净额还是毛额）、跨零点的班次算哪天，这两条必须形成书面口径，否则每月对账都要吵一次。
- 差额容忍额度与审批阈值有没有书面依据。 这两个数由企业财务制度定，系统里只做配置，不给默认值。
- 权限矩阵核过一遍。 特别是"收银员能否看到其他收银点的金额""区域经理能否导出明细"这类敏感点，先按最小必要原则配，再按需要放开。
- 历史数据怎么进来。 建议只导入最近一个月的交接与缴款数据用于试算核对，更早的历史留在 Excel 里备查即可，不要把几年的旧账一次性搬进来（旧账口径不一致，搬进来反而污染统计）。平台支持从 Excel 直接生成并导入数据，做法见 用 Excel 一步建模块：从表格到可用的业务系统。
- 选一家门店试跑两周。 选现金量最大、最忙的那家，跑两个完整周，验证交班填报耗时、差额率、出纳核对工作量。试跑期的差异逐条走完整流程，检验"填原因才能关闭"这条规则是否被人绕过。
- 发布前做预检与移动端同步。 菜单挂载、权限生效、移动端页面是否已同步到手机工作台，都在这步核对，具体见 模块的测试与发布：预检、挂载菜单与移动端同步。
之后怎么延伸：三条自然的加挂路径
这套账本身不复杂，它的价值在于"底座对了，后面好多事可以挂上来"。常见的三条延伸方向：
一是门店费用。 交班与缴款解决现金进账，水电、物业、耗材这些支出可以用同一套"门店 + 日期 + 单据"的结构来记，形成门店完整的收支视图。水电费用的建模方式见 能源抄表与用量分摊：把水电汽读数变成可查的账。
二是其他资金类单据。 供应商结算、门店零用金报销、会员储值卡现金归集，都能复用"主表有状态 + 差异独立成行 + 只增不改"的同一套骨架。票据类的做法可参考 开票申请与发票台账：开了哪些、进项有没有到，注意两者的分工：发票台账管票，本文这套管现金。
三是稽核联动。 把"差额发生率""差异关闭时长"变成门店稽核的评分项，让现金管理从"财务一个人盯"变成"区域和督导一起盯"。
不做什么：四条边界，请一并写进制度
为了避免上线后被追问"为什么这个也不行"，把不做的四件事明说：
- 不直连收银系统（POS）与银行账户。 系统应收靠人录或导入，银行到账靠出纳登记，平台不提供与第三方收银软件、银企直连的原生对接。
- 不做凭证识别。 缴款凭证、银行回执、班结小票都是拍照上传留档，金额由人填，系统不从图片里读数字，也不做扫码识别。
- 不管理现金实物与硬件。 点钞机、保险柜、金库门禁这些硬件不在范围内，系统只记录"人报的数"，不验证"箱子里的钱"。
- 不替代会计处理。 不生成记账凭证、不做总账与报表、不判断盘亏怎么入账。应收应付这类账务级的需求，属于另一类台账，见 应收应付：老板最关心的一本账，业务台账怎么建。
守住这四条，这套系统的定位就始终清晰：它让"每天卖了多少钱、谁交的班、钱进没进银行、差的那部分谁解释的"这四句话，随时都能答上来。