# BC-08｜财务核算（finance）

> 状态：working-draft；本次边界建议，未批准为完整新基线。\
> Design=draft；Contract=not-defined-here；Implementation=not-assessed；Verification=document-review-only。\
> 上游：[SD-07](../06-subdomain/sd-07-finance.md)（仍为候选占位）\
> 输入：既有模块设计（历史材料保留在 `docs_bak/`）\
> 编写责任：主会话；业务决策 / 长期维护责任人：待指定。日期：2026-09-18。

## 1. 需要什么，它是什么

把可追溯经济来源按明确规则转成可核对账务，不混同收款与收入。

统一语言：Journal 是会计分录；Ledger 是账务汇总；AccountingPeriod 是期间；PostingRule 是来源到分录的规则。会计 account 与登录 Account 语义不同。

## 2. 拥有与不拥有

**拥有：** 核算主体与账簿、科目与过账规则版本、期间、过账接收和执行记录、不可变分录、收入确认、冲销调整、期初与核算对账。

**不拥有：** 订单、真实支付退款及渠道结算源事实、履约事实；分析指标不是会计来源。

这里列出事实族和职责，不直接定义数据库表、聚合事务范围或最终接口名称；详细模型须在下一层继续验证。

## 3. 谁参与，怎样使用

财务人员通过后台配置和核对；受限 Worker 消费经济事件；管理人员及 Analytics 读取允许的账务结果。

典型场景：接收来源事件 → 检查来源、规则、科目、期间 → 幂等生成平衡分录 → 汇总或收入确认 → 输出可追溯结果；差异回来源 Owner 或本域调整流程。

## 4. 如何与其他上下文协作

消费 Commerce 已验证资金和交易事实；供给、履约和渠道提供被明确启用的成本/费用等来源。外部账单观察不能未经相应验证就视为已结算资金。

调用方向、信息方向、流程协调者和失败责任统一见 [CONTEXT-MAP](CONTEXT-MAP.md)；事实边界及混淆项见 [OWNERSHIP](OWNERSHIP.md)。不使用共享可变实体或跨 Owner 写表。

## 5. 不变量、权限与一致性

已过账分录不可直接修改；缺规则或来源不猜测；关闭期间不普通入账；同一经济效果不能因规则改版被再次记账。

所有入口遵循 [统一授权接缝](CONTEXT-MAP.md#2-统一授权与允许动作的接缝)。本上下文负责自己的资源关系和业务动作条件，不能仅凭客户端提交的角色或对象归属放行。

## 6. 失败、并发与恢复

事件去重之外还需经济来源唯一性和修正规则；期间关闭与过账竞争由本域控制；重建验证后切换；退款事实不能因过账失败回滚。

部署和数据库共用不构成跨上下文原子性承诺。需要立即成立的约束在对应事实 Owner 内执行；跨域步骤记录意图、版本、结果与恢复进度。

## 7. 边界取舍与可能推翻结论的证据

与 Commerce 分离：资金发生和会计解释有不同语言、职责及时间边界。放入 Analytics 会丢失分录写入责任，故不采用。

反证检查：验证重复及新版规则重放不重复入账、关账竞态、退款已成但财务缺配置、原始结算观察和已确认结算不重复计入。

上述是设计反例清单，尚未执行产品测试。拆合讨论及重开条件见 [BOUNDARY-DECISIONS](BOUNDARY-DECISIONS.md)。

## 8. 未决事项与后续交付

会计政策、经济来源映射、去重与重述语义、职责分离、实际财务维护人和迁移规则待明确；本页不规定会计合规结论。

先核对本页业务范围及上下文边界，再细化模型、不变量、状态、命令/查询/事件和授权契约；最后派生完整业务增量 REQ。不得据本稿直接锁定开发接口。当前未决项统一归入[DECISIONS](../DECISIONS.md)对应D项；[REVIEW](REVIEW.md)仅保留历史审查及Q项来源，不另作活动决策台账。