一、先定边界：移动端该承载流程的哪一段
移动审批最容易走偏的地方，是把「移动端能做」当成「移动端都该做」。手机的价值在于把审批从工位上解放出来——出差、开会、在家，人不在电脑前也能把该签的字签掉；但它的短板同样明确：屏幕小、录入慢、网络不稳定、无法核对大表格。把这两点想清楚，接入形态与功能范围自然就定了。
判断某个操作是否适合放到移动端，有一个简单的检验方法：这个操作需要同时看到多少信息、需要多少字节的输入、出错以后的纠正成本有多高。三项都低的操作适合移动端，只要有一项高，就应该留在桌面端。例如差旅申请、费用报销审批、借款审批属于典型的三低场景；而批量付款复核、科目与辅助核算变更、历史凭证更正，三项都高，放到手机上是在制造风险而不是在提效。
| 接入形态 | 身份与免登录来源 | 适合的场景 | 主要代价 |
|---|---|---|---|
| 原生应用 | 自建账号体系，独立登录 | 高频使用、需要调用摄像头与本地文件、需要离线暂存 | 需要单独运维与分发，用户要额外装一个应用 |
| 小程序 | 与宿主平台账号打通 | 中低频审批、需要快速拉起、希望零安装 | 受宿主平台能力与审核约束，文件处理能力弱于原生应用 |
| 企业微信自建应用 | 企业微信成员身份免登 | 公司已统一使用企业微信、组织架构已在企业微信维护 | 消息推送有平台侧频率上限，通知策略需自行设计 |
| 钉钉内部应用 | 钉钉用户身份免登 | 公司已统一使用钉钉、工作通知体系已在使用 | 同上，且不同平台的能力项与限制项并不一致 |
| 移动网页加短信 | 系统自身账号加短信验证 | 低频、外部人员或临时人员场景 | 体验最弱，无法接收应用内通知，只能靠短信触达 |
选型阶段还有一个常被忽略的判断：公司主用的协同平台是什么，移动审批就应该优先长在那个平台上。财务系统的移动端如果另起一套账号与组织架构，等于全公司要维护两份人员数据，交接、调岗、离职都会变成两个系统的对齐工作，长期维护成本远高于一次接入成本。
二、组织架构同步：同步哪些对象、以谁为准、异常怎么兜底
移动审批的可用性，八成取决于通讯录同步的质量。同步断掉的表现通常不是报错，而是安静地出错：新入职员工的审批人搜不到、调岗后单据还流向原部门、离职人员的在途单据没人能批。因此同步设计要回答三个问题——同步哪些对象、以哪一侧为准、同步失败时怎么兜底。
| 同步对象 | 建议主数据源 | 建议同步频率 | 必须同步的关键字段 | 同步失败时的兜底 |
|---|---|---|---|---|
| 部门与层级 | 人力资源系统或协同平台通讯录 | 每日一次增量，每月一次全量校验 | 部门编码、名称、上级部门、启用停用状态 | 保留上一版本组织快照，审批链路继续按快照流转 |
| 人员与在职状态 | 人力资源系统为唯一权威源 | 每日增量，离职当日触发即时同步 | 工号、姓名、在职状态、所属部门、直接上级 | 同步失败时冻结新单发起，并告警至系统管理员 |
| 岗位与汇报关系 | 人力资源系统 | 组织调整后即时推送 | 岗位序列、汇报线、兼任关系 | 过渡期保留双审批人，避免单据断流 |
| 审批角色与代理人 | 财务系统内维护 | 随单人设置变更即时生效 | 角色编码、人员范围、代理有效期 | 代理到期自动回退到原审批人，不留下无主单据 |
| 账号状态与登录权限 | 协同平台侧 | 实时 | 启用、停用、权限范围 | 停用即回收登录态，同时移交在途单据 |
「以谁为准」这个问题必须在项目启动时就书面确认。常见做法是以人力资源系统为人员与在职状态的唯一权威源，协同平台与财务系统都只做接收方；财务系统只维护与业务相关的补充属性，例如成本中心归属、可审批金额上限。如果两侧都能改，最后一定会出现两套都自称正确的人员数据，而排查成本会随时间累积。
三、消息到达率：平台侧的限制是硬约束，不是调优空间
审批通知发不出去，绝大多数情况不是网络问题，而是触碰了协同平台的推送频率上限。这类问题的隐蔽之处在于：接口返回成功，但消息被丢弃不下发，系统侧如果不主动核对发送结果，就会一直以为通知已经送达。
以企业微信应用消息接口为例，其限制至少有三个层次。应用级总量上，每应用每日发送量不可超过企业账号上限数乘以 200 人次——若企业账号上限为 500 人，则该应用每天可发送 10 万人次的消息，这是一天用不完的量级，通常不会先撞上。真正容易撞上的是单人维度：每应用对同一个成员不可超过 30 次/分钟、1000 次/小时，超过部分会被丢弃且不下发。第三个层次是基础调用频率，即每企业调用单个接口不可超过 1 万次/分钟、15 万次/小时。官方文档还给出了一条经验建议：多数企业应用习惯在整点或半点触发推送，容易造成资源挤占、投递不及时，应尽量避开这两个时间点。
钉钉侧的规则与限度并不相同，配置时不能把两家的数值混用。企业内部应用调用每个接口的频率上限为 40 次/秒或 1500 次/分钟；发送工作通知时，企业内部应用单次最多向 5000 人发送，每分钟最多 5000 人可接收到消息；对同一个员工，一天只能发送一条内容相同的消息通知，且每天给每个员工最多可发送 500 条消息通知。超出这些限制时，接口同样可能返回成功而用户收不到，需要通过查询发送结果的接口逐条核对。
| 平台 | 单次接收人上限 | 单人频率限制 | 应用级频率限制 | 超限后的表现 |
|---|---|---|---|---|
| 企业微信应用消息 | 未单独限定单次人数，受日发送人次总量约束 | 同一成员 30 次/分钟、1000 次/小时 | 每日不超过账号上限数×200 人次；单接口 1 万次/分钟、15 万次/小时 | 单人维度超限部分被丢弃且不下发；总量超限时接口返回失败 |
| 钉钉工作通知 | 企业内部应用单次最多 5000 人，第三方企业应用最多 1000 人 | 同一员工每天最多 500 条，且同内容消息一天只发一条 | 每应用每接口 40 次/秒、1500 次/分钟 | 接口返回成功但用户收不到，需调用发送结果查询接口核对 |
收不到审批通知时的六个排查点
- 可见范围：成员是否在该应用的可见范围内，这是最常见的原因
- 推送范围：推送范围若设置为标签，需确认标签中的成员确实落在发送人的管辖范围内
- 个人开关：成员是否开启了消息免打扰，或关闭了该应用的接收消息开关
- 频率超限：是否在同一分钟内对同一成员重复推送，触发单人频率上限
- 范围失效：定时推送的任务在执行时，原设定的标签或部门是否已被删除或重建
- 同名应用：工作台中是否存在多个同名应用，消息推到了 A 应用而成员在 B 应用里找
从系统设计角度，最有效的做法不是把通知做得更花哨，而是做三件事：一是把「单据状态变化」与「必须触达的人」分开定义，只在状态真正需要某人处理时才推送，避免一次提交触发全链路广播；二是对推送结果做回执核对，把发送失败或超限的记录落到待办列表里，而不是只记一条日志；三是在待办中心提供独立的入口，让审批人不依赖推送消息也能看到待自己处理的单据——通知可以丢，待办表不能丢。
四、移动端能做与不能做：一份可以直接拿去评审的边界清单
边界清单的价值在于把争议前置。等到项目评审时再讨论「批量付款要不要支持手机上复核」，往往已经来不及改设计。下面这张表按操作类型给出建议，企业可以在此基础上按自身风险偏好微调，但涉及资金出账与账务不可逆的操作，建议保持保守。
| 操作类型 | 是否建议放移动端 | 主要原因 | 替代做法 |
|---|---|---|---|
| 差旅与费用申请提交 | 建议 | 信息量小、录入以选择为主、出错可修改 | 直接移动端提交，附件拍照上传 |
| 单笔费用审批 | 建议 | 决策所需信息集中在一张单据上 | 移动端审批，同时展示预算占用与历史同类单据摘要 |
| 借款与还款登记 | 建议 | 流程短、金额与对象明确 | 移动端登记，系统自动汇总个人往来余额 |
| 批量付款复核 | 不建议 | 需要同时核对多笔金额、收款账户与批次合计，误操作后果不可逆 | 桌面端复核，移动端只推送到达提醒 |
| 记账凭证修改与科目调整 | 不建议 | 涉及已记账数据的不可逆变更与连续编号 | 桌面端操作，按不可逆记账要求限制删除与插入 |
| 组织与权限变更 | 不建议 | 权限类变更影响面广，需要双人确认与留痕 | 桌面端由系统管理员操作并留审批记录 |
| 期末结账与报表出具 | 不建议 | 依赖批处理与全量数据校验，且需要长时间在线 | 桌面端执行，移动端仅查看结果 |
| 报表与看板查看 | 建议 | 只读操作，无副作用 | 移动端提供关键指标看板，明细下钻引导至桌面端 |
| 批量导入与主数据维护 | 不建议 | 需要模板校验与错误行定位，移动端无法承载 | 桌面端导入，移动端只做状态查询 |
五、留痕与合规：移动审批要经得起审计倒查
审批搬上手机之后，摆到审计与检查面前的问题会变成：这笔单据在哪台设备上、由谁、在什么时候审批的？审批时看到的附件与现在留存的是否一致？当时的审批规则是什么？这三个问题如果答不上来，系统再流畅也不算合格。
《会计信息化工作规范》（财会〔2024〕11 号，财政部 2024 年 7 月 26 日印发，2025 年 1 月 1 日施行）第十六条要求，会计信息系统应当设定经办、审核、审批等必要的审签程序，系统自动执行的业务流程应当可查询、可校验、可追溯；第十七条进一步要求，系统自动审核的规则应当可查询、可校验、可追溯，其设立与变更应当履行审签程序，严格管理，留档备查。这两条落到移动审批上，意味着审批节点、审批人、审批时间与当时的规则版本都必须可还原，不能只留一个「已审批」的状态值。
另一份配套规范《会计软件基本功能和服务规范》（财会〔2024〕12 号，2025 年 1 月 1 日施行）则从软件能力侧提出要求：软件应当提供用户操作日志，可按操作人员、操作时间、操作内容进行查询；对已记账凭证不得提供删除和插入，连续编号，并限制对日期、币种、汇率、金额、科目、操作人等要素的修改。移动端作为同一套系统的一个入口，必须受同一套约束，而不能因为终端不同就放宽。
移动审批留痕的四条底线
- 审批动作必须绑定唯一身份：免登录场景下，身份来源应为协同平台的成员身份，不得使用共享账号或设备指纹替代
- 每次审批记录终端类型、设备标识、时间戳与当时的规则版本，设备信息作为审计线索而非身份依据
- 附件以只读方式展示：原始票据影像与结构化数据一经上传不可被审批人覆盖，如需更正须走留痕流程
- 代理与委托审批必须留下授权记录与有效期，代理期间的审批行为同时归属于代理人与被代理人
还有一点常被忽略：移动端是终端安全链条上最薄弱的一环。手机丢失、截图外发、第三方输入法留存，都可能造成财务数据泄露。等级保护的基本要求（《信息安全技术 网络安全等级保护基本要求》，GB/T 22239-2019）对三级系统提出了安全审计应覆盖每个用户的重要行为与重要安全事件、审计记录应防止未预期的删除修改覆盖等要求。移动端至少要落实设备绑定、密码或生物识别解锁、会话超时自动退出、敏感信息不落本地明文这几项，否则一台丢失的手机就足以绕过整套审批管控。
六、上线前的六项检查
- 通讯录同步：用一批真实的入职、调岗、离职数据走一遍，确认人员状态、汇报关系与审批人跟随结果符合预期
- 在途单据处理：模拟审批人离职与调岗，确认在途单据能批量移交，不产生无人处理的无主单据
- 通知触达：对全量审批人做一次推送测试，核对发送结果接口返回，统计实际可达比例并记录失败名单
- 频率压测：按年度单据峰值日的提交量估算通知条数，校核是否触及单人与应用级频率上限
- 操作边界：逐条核对移动端暴露的操作是否与边界清单一致，重点确认资金与账务类操作未开放
- 留痕验证：抽取一笔完整单据，从日志中还原发起、审批、退回、再次提交的全过程，确认时间、人员、终端与规则版本齐全
这六项检查不涉及任何新增开发，却决定了上线后第一周的投诉量。把检测结果写成一份带签字的清单留档，也是在项目验收阶段证明「配到了位」的最直接材料。
资料来源：企业微信开发者中心《发送应用消息》接口文档与《访问频率限制》说明；钉钉开放平台《调用频率限制》与《发送工作通知》接口文档；《会计信息化工作规范》（财会〔2024〕11 号，财政部，2024 年 7 月 26 日印发，2025 年 1 月 1 日施行）第十六条、第十七条；《会计软件基本功能和服务规范》（财会〔2024〕12 号，2025 年 1 月 1 日施行）第二十一条、第三十二条；《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019）。