开源灵工系统

项目背景

灵活用工本质上是税筹的一种落地方式，而企业的税筹规划总是以节税为目的。

一般而言，企业用工形式，大致可以分为以下三类：

• 标准劳动关系，即全日制用工，相关权益受《劳动法》和《劳动合同法》保护；
• 非标准的劳动关系，包括劳务派遣、非全日制用工（小时工等），相关权益受《劳动法》和《劳动合同法》保护；
• 第三类用工则不属于劳动关系，包括劳务关系、业务外包、实习、退休返聘、岗位外包、平台用工等，由《民法通则》和《合同法》予以约束。

系统架构图

灵活用工平台的核心不是单纯“发钱”，而是把企业、自由职业者、结算公司、支付通道、税务能力和风控证据串成一条可追溯的业务闭环。

核心模块分析

1. 租户与企业管理

租户模块负责承载 SaaS 化能力，区分不同用工企业、结算主体、税源地和运营配置。

核心能力：

• 企业入驻：营业执照、法人信息、联系人、开票资料、用工场景说明。
• 租户隔离：企业数据、项目数据、人员数据、账务数据必须按租户隔离。
• 结算主体配置：不同企业可以绑定不同结算公司、税源地、费率策略和开票规则。
• 权限体系：企业管理员、财务、项目负责人、审核员等角色需要区分操作边界。

关键数据：

• 企业主体信息
• 租户配置
• 角色权限
• 服务费率
• 税源地配置
• 开票资料

设计重点：企业侧所有资金、任务、人员、合同、发票都应该带 tenant_id，避免后期做多企业、多结算主体时出现数据串租户问题。

2. 自由职业者实名与签约中心

个人端的核心是建立“人是真实的、协议是有效的、服务关系可解释”的证据基础。

核心能力：

• 实名认证：姓名、身份证、手机号、人脸核验、银行卡四要素。
• 职业者档案：服务类型、地区、收款账户、协议签署状态。
• 电子签约：平台服务协议、自由职业者承诺书、项目服务协议。
• 黑名单校验：身份证、手机号、银行卡、设备、IP 等维度的风险拦截。

关键数据：

• 实名认证记录
• 银行卡绑定记录
• 电子合同
• 用户授权记录
• 风险命中记录

设计重点：实名认证不能只保存“成功/失败”，需要保存认证渠道、认证流水号、认证时间、脱敏后的证件信息和授权记录，方便审计。

3. 项目与任务管理

任务模块用于证明企业向自由职业者采购了真实服务，是后续结算、开票、完税的业务依据。

核心能力：

• 项目创建：用工企业创建服务项目，配置预算、周期、验收方式。
• 任务发布：按人、按件、按单、按天等方式发布任务。
• 接单与交付：自由职业者接单、提交服务结果、上传附件。
• 验收审核：企业确认服务完成，形成可结算金额。
• 批量导入：适配大量人员或大量订单的结算场景。

关键数据：

• 项目
• 任务
• 服务明细
• 验收记录
• 附件材料
• 结算批次

设计重点：任务必须能解释“为什么给这个人发这笔钱”。至少要留下项目、任务、服务内容、验收记录、结算金额和附件证据。

4. 结算中心

结算中心是系统主链路，负责把企业应付、个人应收、平台服务费、税费、支付状态串起来。

核心能力：

• 结算单生成：按任务、项目、人员、批次生成结算明细。
• 费用计算：服务费、税费、实发金额、企业应付金额。
• 多级审核：企业确认、平台复核、财务确认、风控放行。
• 状态流转：待确认、待审核、待打款、打款中、打款成功、打款失败、已冲正。
• 失败重试：银行卡错误、限额、通道失败时支持重试或换卡。

关键数据：

• 结算批次
• 结算明细
• 服务费
• 税费
• 实发金额
• 支付流水
• 审核记录

设计重点：结算金额不要只保存一个总金额，应该拆成 gross_amount、service_fee、tax_amount、net_amount、enterprise_payable_amount，后续对账和报表会简单很多。

5. 支付代发网关

支付模块负责对接银行、支付公司或代发通道，要求幂等、可追踪、可对账。

核心能力：

• 通道配置：不同结算主体可配置不同银行或支付通道。
• 代发请求：按批次或单笔提交打款。
• 回调处理：接收通道结果，更新支付状态。
• 对账下载：按日获取通道账单，与系统支付流水核对。
• 限额控制：单笔限额、单日限额、个人累计限额。

关键数据：

• 通道商户号
• 代发订单号
• 银行流水号
• 回调报文
• 对账文件
• 重试记录

设计重点：支付请求必须做幂等。系统内部结算明细号、通道请求号、银行流水号要分开保存，不要混用。

6. 发票与税务中心

税务模块负责企业开票、个人完税、委托代征材料和税源地规则配置。

核心能力：

• 企业开票：按企业、项目、结算批次生成开票申请。
• 税费计算：根据税源地、行业、核定税率、服务类型计算税费。
• 完税证明：关联个人收入、申报记录和完税凭证。
• 委托代征材料：维护税务机关、代征协议、申报周期。
• 税源地策略：不同地区不同核定率、返税政策、开票类目。

关键数据：

• 开票申请
• 发票抬头
• 税率配置
• 申报批次
• 完税证明
• 委托代征协议

设计重点：税率配置要做版本化。历史结算单必须能按当时的税率规则复算，不能被新配置覆盖。

7. 资金账户与账务

账务模块用于沉淀平台内部的资金流和财务口径，避免只依赖支付通道流水。

核心能力：

• 企业充值或授信额度管理。
• 结算冻结、解冻、扣减。
• 平台服务费入账。
• 税费计提。
• 失败退款、冲正、补发。
• 日终对账和财务报表。

关键数据：

• 企业账户
• 个人收款账户
• 平台收入账户
• 账户流水
• 冻结记录
• 对账差异

设计重点：账务流水只能追加，不能物理修改。任何冲正都应该生成反向流水，保留完整审计链。

8. 风控与合规中心

风控模块负责识别虚假用工、拆单避税、异常收款、批量作弊等风险。

核心能力：

• 规则引擎：金额、频次、地区、设备、IP、银行卡、企业维度规则。
• 任务真实性校验：无项目、无验收、无附件、同质化任务拦截。
• 人员风险：一人多号、多企业异常收款、黑名单命中。
• 企业风险：高频大额结算、行业不匹配、长期无真实交付材料。
• 人工复核：高风险批次进入人工审核。

关键规则示例：

• 单人单日收入超过阈值进入复核。
• 同一银行卡绑定多个实名用户拦截。
• 同一 IP 批量注册和接单进入复核。
• 任务描述高度重复且金额集中进入复核。
• 企业结算金额突然放大进入复核。

设计重点：风控结论必须可解释。每次拦截要保存命中的规则、输入数据、处理人和处理结果。

9. 证据链与审计日志

证据链模块是灵活用工平台的底座，负责把业务真实性材料串起来。

核心能力：

• 合同归档：企业合同、个人协议、项目协议。
• 服务证据：任务内容、交付材料、验收记录。
• 资金证据：结算单、支付流水、回单、对账结果。
• 税务证据：发票、申报记录、完税证明。
• 操作审计：谁在什么时间做了什么操作。

关键数据：

• 证据类型
• 业务单号
• 文件 hash
• 存储地址
• 操作人
• 操作时间

设计重点：重要文件建议保存 hash，并使用对象存储归档。系统内保存文件地址、hash、业务单号和上传来源即可。

10. 运营后台

运营后台用于平台方管理企业、人员、结算、风控、税务和配置。

核心能力：

• 企业管理
• 个人管理
• 项目任务管理
• 结算审核
• 打款监控
• 发票管理
• 税务配置
• 风控复核
• 报表看板
• 系统配置

设计重点：后台操作一定要有权限控制和审计日志。尤其是结算审核、费率修改、税率修改、打款重试、风控放行这类高风险动作。

业务数据流

推荐服务拆分

服务	职责	适合独立拆分的时机
tenant-service	企业、租户、权限、配置	多企业、多结算主体接入后
worker-service	个人实名、银行卡、签约	认证渠道和个人规模增长后
project-service	项目、任务、验收、附件	任务类型变多、交付流程复杂后
settlement-service	结算批次、费用计算、审核流	结算金额变大、财务审核复杂后
payment-service	支付通道、代发、回调、对账	接入多个银行或支付通道后
tax-service	发票、税率、申报、完税证明	多税源地、多开票类目后
risk-service	规则、黑名单、人工复核	风控规则频繁调整后
evidence-service	合同、文件、审计、证据链	合规材料量变大后
report-service	财务报表、运营看板	管理层报表和 BI 需求增加后

早期不建议一开始就拆成大量微服务，可以先用模块化单体，把结算、支付、税务、风控的边界设计清楚；当团队、交易量和通道复杂度上来后再拆分。

最小可用版本

如果要做开源 MVP，建议先做这些能力：

1. 企业入驻和企业后台。
2. 自由职业者实名、银行卡、协议签署。
3. 项目、任务、验收。
4. 结算批次和结算明细。
5. 模拟支付通道和支付回调。
6. 发票申请和税费配置。
7. 风控规则和人工复核。
8. 证据链归档和操作日志。
9. 基础报表：企业应付、个人实发、平台服务费、税费。

技术选型建议

• 前端：React / Vue + Ant Design / Element Plus。
• 后端：Go / Java 都可以，重点是结算链路的事务和幂等设计。
• 数据库：MySQL 存核心业务数据，Redis 做验证码、锁、短期缓存。
• 文件：对象存储保存合同、附件、回单、完税证明。
• 消息队列：处理支付回调、对账、通知、税务申报等异步任务。
• 工作流：结算审核、风控复核、发票审核可以使用轻量状态机，早期不一定需要 BPM。
• 监控：支付失败率、回调延迟、对账差异、结算金额异常必须告警。

合规与风险边界

灵活用工平台最容易出问题的地方，不是技术实现，而是业务真实性和税务合规。

需要特别关注：

• 不要把劳动关系包装成劳务关系。
• 不要没有任务和验收就直接发放费用。
• 不要允许企业把工资拆成灵活用工结算。
• 不要缺少协议、验收、支付、完税等证据。
• 不要忽略地区税务政策变化。
• 不要让低税率配置覆盖历史结算单。

系统设计的目标是让每一笔钱都能回答三个问题：

1. 为什么发？
2. 发给谁？
3. 凭什么证明这是一笔真实服务收入？

灵活用工包含几个基本组成:

1. 用工企业：如上图所示的行业企业，一般存在短期、兼职或者其他形式的用工人员；

2. 结算公司（税源地落户）：异地纳税、委托代征、核定征收，依托地方税务政策存在；

3. 自由职业者：服务于用工企业，但是通过结算公司获取报酬。

灵活用工依据以及风险:

1. 首先需要明确的是，虽然“灵活用工”已被市场广泛应用，但它并非是一个法律概念，没有明确的法律法规来定义并解释这一概念，这也是目前灵活用工市场最大的不确定性所在，当然我们总是能从现行法律法规中找到支点。

2. 《中华人民共和国税收征收管理法实施细则》第四十四条，明确了地方税务机关可以“委托有关单位和人员代征零星分散和异地缴纳的税收并发给委托代征证书”；

3. 《委托代征管理办法》第五条，明确了“税务机关确定的代征人，应当与纳税人有下列关系之一：（二）与纳税人有经济往来关系”，第十条，明确了“税务机关应当与代征人签订《委托代征协议书》，明确委托代征相关事宜”；

4. 《国家税务总局个体工商户个人所得税计税办法》第三条，明确了“所称个体工商户包括：（三）其他从事个体生产、经营的个人”；

5. 《地方国家税务局关于调整个体工商户个人所得税附征率的公告》给出了税费自主调节的依据；

灵活用工从税务上说，本质是将个人视作个体户，通过委托代征、个体户登记、个人临时性经营性所得登记等形式，以核定征收或个体户经营所得纳税取代个税申报的一种节税方式。

因此以委托代征为主要形式的灵活用工结算平台，其所谓的流程合规，一般会包括：

1. 委托代征资质；
2. 个人与结算平台签订用工协议；
3. 依据税收洼地政策，按照0%~1.5%核定征收；
4. 出具税务机关汇总申报的个人完税证明。

灵活用工结算平台如何获利:

1. 企业通过结算平台发生结算时，向平台额外支付6-8%的综合税费+服务费，而平台本身除正常人力支出外，财税成本主要在于开具6%专票费用以及代扣代缴个税的支出。

2. 首先结算平台向企业开具6%的增值税发票后，即需缴纳6%的增值税以及0.72%的各种附加税，在不考虑抵扣自身成本的前提下，税费成本为6.72%。一般而言，增值税中央和地方的留存比例为50:50，而地方税务出具相应的税收优惠政策后，地方留存税费返还比例可达50~90%，以比较常见的70%计算，结算平台的实际开票成本可以做到：6.72%-6%*50%*70%=4.62%，需要注意的是，一般税收洼地的返还政策会在70%左右，部分税源地会给出更高的返税政策来吸引招商入驻，当然也会在税收优惠期结束后作出的调整。

3. 代扣代缴个税方面，在当前核定征收政策下，根据行业不同，地方税务确定的征收税率可以是0%-1.5%。因此当返税比例为地方留存的70%（可能更高），且核定征收税率分别为0%、0.5%、1%、1.5%时，结算平台发生结算的综合成本即为4.62%、5.12%、5.62%以及6.12%。

4. 根据上述计算，可以很显然的看出，地方核定征收及返税政策决定了一家结算平台的固定成本，这也是目前市场上结算平台报价混乱的根本原因，从5.0%~8.0%都有。

5. 值得注意的是，较低的报价可以实现，但这是基于获取高比例地方留存返税以及降低个人核定征收比例实现的，这两者对于地方税务而言是不一定是正常或长久的，会随着地方税务的政策调整而变化，当然结算平台可以通过不断更换税源地来持续跟进更优惠的税收政策。