一、四种移动端形态的实际差别
移动报销在技术上通常有四种形态可选：独立原生 App、微信小程序、企业微信或钉钉内嵌的 H5 应用、以及企业自建 App 内嵌的报销模块。四者在功能上都能实现填报与审批，差别集中在安装成本、系统能力调用、消息触达与身份认证四方面。
| 形态 | 安装与推广 | 可调用的系统能力 | 消息触达方式 | 身份认证 |
|---|---|---|---|---|
| 独立原生 App | 需要员工主动安装，推广成本最高 | 最完整，相机、定位、本地存储、后台任务均可用 | 自有推送通道，需自行维护到达率 | 独立账号体系，需与内部身份打通 |
| 微信小程序 | 扫码或搜索即用，无需安装 | 受限，部分本地存储与后台能力需授权 | 依赖微信服务通知与订阅消息，需用户授权 | 微信登录，可与企业账号绑定 |
| 企业微信／钉钉内嵌 | 随办公平台使用，几乎零安装成本 | 受宿主容器限制，能力取决于宿主开放接口 | 复用办公平台的应用消息通道 | 直接复用办公平台身份，无需二次登录 |
| 企业自建 App 内嵌模块 | 由企业统一分发，覆盖可控 | 取决于自建 App 已获得的权限 | 复用自建 App 的推送通道 | 与自建 App 的登录态共用 |
从这张表能看出一个容易忽略的结论：企业微信与钉钉内嵌形态的最大优势不是功能，而是零安装成本加上现成的身份体系。对需要全员使用的报销场景来说，这两个优势的价值通常大于功能上的那点损失。反过来，如果一家企业本身有成熟的自建 App（例如已在用的办公门户），把报销做成其中的一个模块，往往比再推一个独立 App 更现实。
二、六个能力维度逐项对比
把上面的形态差异落到实际使用上，需要再看六个具体维度。这六项里，前四项决定「好不好用」，后两项决定「能不能长期用」。
| 能力维度 | 原生 App | 小程序 | 企业微信／钉钉内嵌 |
|---|---|---|---|
| 票据拍照与识别 | 可调用相机全能力，支持多张连拍与本地预处理 | 可用，连续拍照体验受容器限制 | 可用，但与宿主相册权限策略相关 |
| 离线填报 | 本地数据库与文件系统完整，离线体验最好 | 本地存储受限，离线时长与容量都有上限 | 最弱，通常依赖宿主缓存，长时间离线易丢数据 |
| 消息到达率 | 取决于自有推送通道与厂商通道配额 | 取决于服务通知授权状态，用户未授权即收不到 | 取决于办公平台频率限制，超限会被静默丢弃 |
| 登录与身份 | 需自建账号体系，或做单点登录对接 | 微信登录需绑定企业账号 | 直接复用办公平台身份，最省事 |
| 权限与数据边界 | 完全自主可控 | 数据需经第三方平台策略约束 | 受宿主的可见范围与权限模型约束 |
| 长期维护成本 | 需维护 iOS 与安卓两套客户端与发版节奏 | 由平台统一维护，但受平台规则变化影响 | 由办公平台维护，成本最低 |
离线填报一栏值得单独说明。很多报销场景恰恰发生在网络不稳定的地方：出差途中、供应商现场、境外漫游。如果移动端只能在线填报，用户会拍照留存、回公司再补录，OCR 的准确性优势就浪费了，单据积压也会集中到月末。离线能力因此不是加分项，而是差旅场景的必要项。
三、被低估的风险：消息超限会被静默丢弃
选择企业微信或钉钉内嵌形态时，最需要提前确认的是推送通道的频率限制。这一项的风险特征是：超限之后调用方往往收不到明确错误，消息却不会送达。
以企业微信为例，其开发者文档列明：发送应用消息时，每应用不可超过账号上限数乘以 200 人次／天（若一次调用发给 1000 人，按 1000 人次计算）；每应用对同一个成员不可超过 30 次／分钟、1000 次／小时，超过部分会被丢弃不下发。基础调用频率方面，每企业调用单个接口不可超过 1 万次／分、15 万次／小时。官方同时提示，大部分企业应用容易在每小时的 0 分或 30 分触发推送，容易造成资源挤占，导致投递不够及时，建议尽量避开这两个时间点。
推送通道的三条设计纪律
- 不把推送当作审批到账的唯一通知，重要待办须在应用内有独立角标或待办列表
- 批量通知错峰发送，避开整点与半点，避免与全公司的定时任务撞车
- 对批量发送的返回结果做校验，把无效接收人（不在可见范围、无接口权限）单独记录并跟进
第三点尤其重要。企业微信的发送接口在部分接收人无效时仍会返回成功，同时在返回体中列出无效的用户或部门标识，常见原因是接收人不在应用的可见范围内。这意味着如果实施方只看接口调用的成功与否，就会漏掉一批长期收不到消息的人，而这类问题往往要到有人投诉才会被发现。
另一个常被误解的点是「成员收不到消息」的排查路径。除了超限之外，还包括：成员不在应用可见范围、推送范围设置为标签但成员不在该管理员的管辖范围、成员开启了消息免打扰、成员关闭了该应用的接收消息开关，以及存在多个同名应用导致在 A 应用推送、成员在 B 应用查看。把这几种原因与超限放在同一张排查表里，比逐个试错有效得多。
四、离线填报怎么设计才不会出乱子
离线能力不是「能不能在没网的时候填」，而是填完之后怎么把数据安全地送回来。以下是几条实践中比较关键的设计要点。
- 客户端本地暂存须有独立标识，建议在填写开始时即生成全局唯一的单据号，上传时以该标识作为幂等键，避免重复提交产生两笔报销单
- 本地暂存的位置要明确：小程序与企业微信内嵌的缓存可能被系统回收，重要的草稿不应只依赖缓存，须落盘到可持久化的存储
- 上传采用先票据后表单的顺序，先确保影像文件完整到达，再提交表单引用这些文件，避免出现「有单无票」
- 冲突处理要预设：同一张单据在离线端与在线端同时被修改时，需要有明确的合并或覆盖规则，并留痕
- 离线期间的操作日志同样要记录，不能因为离线就缺失操作轨迹
第三条与第五条涉及规范层面的要求。《会计软件基本功能和服务规范》（财会〔2024〕12 号，财政部 2024 年 7 月 29 日印发，2025 年 1 月 1 日施行）规定，会计软件的输入方式包括网络报文传输、文件导入与手工录入等，并应对输入数据进行校验；该规范还要求软件能够按操作人员、操作时间、操作内容查询用户操作日志。放到移动端，这意味着无论形态如何，录入通道都只是输入方式之一，校验规则与操作日志要求并不因为「在手机上填的」而降低。
移动端录入仍须满足的三项要求
- 输入校验不能因移动端省略，金额、日期、必填项的校验规则应与桌面端一致
- 操作日志须记录到人、到时、到内容，离线操作在补传时不得丢失时间戳
- 身份与权限以登录态为准，不得以「手机在本机」为由跳过权限校验
五、按人群组合形态的判断建议
多数企业的合理答案不是三选一，而是按人群组合。判断维度用两个就够：使用频率与网络环境。
| 人群 | 使用频率 | 网络环境 | 建议形态 |
|---|---|---|---|
| 高频差旅人员 | 高，每周多次 | 不稳定，含境外 | 原生 App 或企业自建 App 模块，优先保证离线能力 |
| 普通员工日常报销 | 中低，每月数次 | 稳定 | 企业微信／钉钉内嵌，零安装、身份现成 |
| 管理层审批 | 中，集中在月末 | 稳定 | 企业微信／钉钉内嵌，优先保证消息触达与一键审批 |
| 外部协作人员或临时人员 | 低，偶发 | 不确定 | 小程序，扫码即用，无需纳入内部账号体系 |
组合方案要解决的一个技术问题是身份与数据的统一：不同形态填报的数据必须汇入同一套单据与审批体系，不能出现「App 里的单子在内嵌端看不到」这种情况。这要求后端的接口层统一，前端形态只是入口不同。
选型阶段建议做五项验证：用一台真实手机在弱网环境下走完一次完整的填报与上传，记录数据是否丢失、重复或错序；在企业微信或钉钉中给同一成员连续发送多条测试通知，观察是否存在被丢弃的情况；检查批量推送的返回结果是否被完整记录；确认离线草稿的存储位置与回收策略；以及核对移动端提交的数据在服务端是否与桌面端走同一套校验与日志。
资料来源：企业微信开发者中心《访问频率限制》《发送应用消息》与企业微信帮助中心「如何发送应用消息」；《会计软件基本功能和服务规范》（财会〔2024〕12 号，财政部 2024 年 7 月 29 日印发，2025 年 1 月 1 日施行）。