一条业务链路，完整落账
收银请求、交易结果、账户余额、记账凭证和会计分录在同一事务内完成。任一关键环节不成立，整笔业务失败，不留下半套结果。
订单→收银→分账→凭证
01 / 为什么需要它THE REAL COST
业务增长以后，
账务复杂度会迅速增加。
很多中小平台先解决了交易，却把账留在表格、代码和人工核对里。规模不大时还能维持，规则一多、参与方一多，问题就会集中出现。
01
算得出，解释不清
一个结算数字经过多张表、多人修改，月底只能反复核对，很难回答“这一笔为什么是这个数”。
02
规则一变，就要改代码
渠道费率、收入科目、参与方比例发生变化，业务规则和技术实现绑在一起，调整慢且容易影响历史。
03
业务成功，财务没有同步
收款、成本、余额和凭证分散处理，一段失败就可能出现业务已完成、账务却没有完整落下的情况。
04
系统很重，表格又太轻
传统大型财务系统投入高、接入慢；继续靠表格，却无法提供稳定接口、权限边界和审计链路。
02 / 系统带来的改变FROM TRANSACTION TO EVIDENCE
让资金结果不只“算出来”，
还能够被检查、被解释、被复用。
规则配置化
通过记账模板组织借贷分录。固定规则直接配置，动态账户和金额由受控能力解析，减少为每个场景重复写代码。
结果有来路
交易、流水、分账快照、凭证和分录只追加保存。查询一个结果时，可以继续追到业务请求、模板和计算依据。
先在模拟账套验证
正式接入前，可在独立模拟账套准备账户、检查配置并执行业务场景，不把试验数据混入正式经营统计。
多公司、多账套隔离
服务端校验公司、账套和角色权限。页面是否显示不是安全边界，每一次业务请求都要通过后端归属检查。
为业务系统开放
通过标准 API 接入现有商城、会员、数字服务或内部系统；JWT、权限范围和幂等键共同控制调用边界。
03 / 在线演示TRY THE SETTLEMENT LOGIC
脱敏计算 · 本地运行
输入一笔业务，
当场看清如何分账。
调整业务金额和三方比例。页面会检查比例是否完整，并把每个结果与计算依据放在一起。演示数据只在当前浏览器计算，不会上传或保存。
SETTLEMENT PREVIEW
校验通过本次分账结果
- 门店
- ¥7,975.68
- 服务人员
- ¥3,601.92
- 平台服务
- ¥1,286.40
- 分账合计
- ¥12,864.00
计算依据
¥12,864.00 × 62% / 28% / 10%
金额按分计算，尾差归入最后一方，确保分账合计与业务金额一致。这个演示只呈现核心计算思路。正式接入还会校验账套、账户、规则版本、权限、幂等键与凭证平衡。
预约完整产品演示 →04 / 适合什么业务BUILT FOR RULE-HEAVY BUSINESS
只要一笔收入背后
不止一个参与方，
就值得把账做清楚。
它不替代法定财务报表或专业会计判断，主要解决业务系统与财务记账之间那段容易依赖人工的连接。
平台与数字服务
会员充值、余额消费、平台服务收入、渠道手续费和上游服务成本。
连锁与联营业务
门店、平台、服务人员等多方参与，结算规则需要被配置并保留版本。
AI 服务与API业务
用户收入与模型、云服务等上游成本同步记录，避免收入已经确认、成本留到以后补记。
需要嵌入财务能力的系统
已有订单和用户体系，但缺少账户、余额、凭证、分账及统一查询能力。
05 / 财务系统的底线SAFETY BY DESIGN
涉及钱，快不是第一位。
一致、可查、可恢复才是。
系统从设计阶段就限制高风险捷径：不直接改余额，不删除交易与凭证，不把缺失成本当成零成本，也不让前端隐藏代替后端授权。
- 金额精度使用十进制定点金额，接口金额最多两位有效小数。
- 原子一致收入与成本必须完整解析，并在同一事务中记账。
- 防止重复业务请求使用幂等语义，受控重试不重复生成财务事实。
- 防篡改关键资金字段和整张凭证保留服务端完整性签名。
- 权限隔离公司、账套、角色和API权限由服务端逐层校验。
- 禁止透支余额不足时拒绝业务，不以负余额掩盖问题。
真实边界
已完成什么，
还有什么没有完成。
当前已实现
- 客户、公司与多账套管理
- 账户注册、余额、冻结与扣款语义
- 收银、模板分账、复式记账和凭证
- 通道费率、策略、黑名单与财务分析
- 模拟账套与业务场景验证
- 开放API、认证、权限与审计日志
交付时按场景确认
- 企业角色与权限配置
- 业务系统接口与部署环境
- 行业模板与具体分账规则
- 运行监控、备份和交付检查
当前未开放
- 真实支付发起
- 退款和冲正操作
- 跨账套记账
- 法定报表及税务结论
IS YOUR BUSINESS A FIT?
先拿一条真实业务，
看看这套核心能不能接住。
告诉我参与方、资金路径、分配规则和目前的核对方式。我们从一条业务链路判断是否适合。
交流财务场景 ↗