财税代账小程序：客户提交资料、进度查询系统设计

核心摘要

• 资料提交模块的成败，取决于"清单能不能跟着客户身份和申报周期自动变化"，而不是上传入口做得多好看。
• 进度查询要把代账公司的内部流程翻译成客户看得懂的状态，节点数量控制在客户一眼能扫完的范围。
• 权限分级与操作留痕，直接决定这套小程序能否替代微信群里的催单与口头确认。
• 申报政策、资料要求会变，字段和流程需要后台可配置，否则每次调整都得重新走一遍开发排期。
• 做过客户数据平台、预约与上报类小程序的团队，在"提交—审核—状态回流"这条链路上有可复用的经验。

资料还在微信群里传，问题就不在公司有没有小程序

代账业务的资料收集有几个固定的麻烦：客户把发票、银行回单、工资表分散发在微信、邮箱、甚至拍照发到会计个人号；会计每月重复问同样几句话；客户不知道自己到底缺哪一份；申报期临近，双方都在赶时间。很多代账公司上过网盘、上过共享表格，最后又退回微信群，原因往往不是工具不好用，而是工具没有承接业务的真实结构——资料是按客户类型、纳税身份、申报周期变化的，一个静态的文件夹结构撑不住。

小程序的价值在于它天然长在客户的手机里：不用装 App，扫码即用，消息触达有订阅消息和公众号两条通道。但要把这个入口用好，需要在提交和查询两端都做设计。

资料提交：先把清单定义清楚，上传只是最后一公里

设计资料提交模块时，建议先回答一个问题：同一家客户，1 月和 4 月要交的东西一样吗？答案通常是否定的。小规模纳税人与一般纳税人、月报与季报、是否代缴社保公积金、是否涉及出口退税或股权变更，对应的清单都不同。所以数据模型上应当是"清单模板 + 客户标签 + 申报期间"三者组合生成当期任务，而不是给每个客户挂一个固定文件夹。

具体到交互，几个细节影响实际使用率：

• 客户侧只看到"本期要交什么"，每一项标注是否必填、有无样例文件，避免让客户面对一长串会计术语。
• 支持拍照、相册、文件多种方式上传，多张票据自动合并成一册，文件名按规则生成，减少会计后期整理。
• 上传即校验：金额字段、发票号格式、文件类型做基础检查，明显不合规的当场退回，而不是等会计人工发现。
• 允许"暂时没有"标记，客户可以先提交已有部分，会计端能看到缺口，双方对同一份清单有共识。

清单生成之后，会计端需要的是一块工作台：按客户、按期间、按缺口筛选，一眼看出谁还没交、谁交了一半。这块工作台做得越顺，客户侧收到的催办消息就越少。

进度查询：状态机怎么定，比页面怎么画更重要

客户问得最多的一句话是"我这个月报了吗"。如果系统只能回答"处理中"，那它就没解决问题。进度查询的核心是把内部工序映射成有限个客户能理解的状态。

一种可行做法是把状态收敛在七个以内，例如：待提交资料、已提交待初审、需要补充、记账处理中、申报处理中、已完成、已出具回执。每个状态必须绑定三个要素：当前责任人是谁、客户此时需要做什么、下一个状态大概什么时候到来。缺了后两项，状态就只是内部视角的自我展示。

配套的几个设计点：

• 时间轴视图比进度条更有用，客户能看到每一步发生的时间，而不是一个抽象的百分比。
• 状态变更自动触发通知，订阅消息负责即时要紧的（如"需要补充资料"），公众号或企微负责周期性的（如"本月已完成申报"）。
• 回执与完税凭证归档到同一客户档案下，客户随时自助下载，减少"帮我发一份上季度的申报表"这类请求。
• 会计端在时间轴上叠加超期提醒，把"哪个客户卡在哪一步"变成可管理的列表。

权限、留痕与数据边界

代账场景的数据敏感度不低：营业执照、银行账号、身份证、工资明细都在里面。权限至少要分三层——客户只能看到自己及名下关联企业的资料与进度；会计按分配的客户组访问；管理员拥有全局视图但每一次查看、下载、导出都留操作日志。

同时要明确系统之间的边界。小程序适合承担"前台收单 + 状态同步"，真正的账务处理、凭证生成仍在专业代账软件里完成。两边通过接口或定时同步交换状态，而不是试图让小程序替代记账系统。这样做还有一个好处：安全合规的改造范围更清晰，需要等保相关咨询与整改时，边界明确反而省事——这类合规工作在实际项目中往往和业务功能同步推进。

从工业客户数据平台到代账场景的迁移

"客户自助提交—后台审核—状态回查"这条链路并非代账独有。特蓝在为布勒（无锡）搭建客户数据平台时，处理的正是类似结构：客户资料归集、预约参观工厂、展会现场人员查询，以及上线之后持续的功能增补。这个项目从 2020 年起跨度数年，说明了一件事：这类系统的第一次交付只是起点，真正决定使用寿命的是后续能不能快速加字段、加流程、加角色。

代账业务对"可配置"的要求只会更高——税率、申报期、资料清单几乎每年都有调整。因此在小程序立项阶段就应把清单模板、状态节点、通知文案做成后台可维护的配置项，而不是写死在代码里。会计主管自己就能调整清单，比每次找开发改代码要现实得多。

落地前值得先想清楚的几个边界

• 老客户的历史资料不必强制全量上传，先跑新周期，避免上线即劝退。
• 一定保留人工代传和线下收件的通道，客户群体里总有一部分人不习惯自助操作。
• 电子档案的保存期限、销毁规则需要提前和客户约定清楚，避免后期争议。
• 不要在客户界面做"保证不漏报""保证按时完成"这类承诺性表述，系统能承诺的是流程可见与提醒及时，申报结果仍取决于资料质量与政策判断。
• 上线节奏建议先在几个配合度高的客户中试跑一个申报周期，把清单和状态节点磨顺，再全量推开。

常见问题

客户提交的资料，会被其他客户或外部人员看到吗？ 取决于权限设计。客户账号只应关联到自己的企业档案，会计按客户组划分访问范围，所有下载与导出行为留日志。这一点在方案阶段就要和代账公司的内控要求对齐，而不是上线后再补。

小程序能替代现有的代账软件吗？ 不建议这样定位。小程序解决的是客户协同与流程透明，记账、报税、凭证生成仍由专业系统承担，两者通过接口交换状态即可。

进度状态设几个比较合适？ 以客户是否能一眼看完为标准。节点过多会让客户困惑，过少则无法反映实际等待点。通常控制在七个以内，并确保每个状态都对应一个明确的下一步动作。

客户坚持用微信发资料怎么办？ 保留人工代传入口，由会计代客户录入系统，状态仍然继续流转。系统要能容纳不规范的操作习惯，而不是要求所有人改变习惯之后才可用。