团队 SaaS 订阅对账中Figma 席位计费是常见的归因难题成员刚加入下一张发票就多了一项席位费用。内部系统如果只记了一条member_added就无法判断这笔钱来自复用已购空席位还是审批时新增了付费席位。本文给出一套 Figma 席位审批、库存观测、发票与付款卡交易分层对账的数据模型和测试用例。说明以下是团队自建订阅台账的设计示例不代表 Figma 或 MPChat 的现网接口。一、为什么成员数推不出费用Figma 的规则是建模起点同类型席位有空余时批准请求可以直接分配现有席位没有空余时才可能需要增加席位。所以“成员 1”和“付费席位 1”是两个独立事实成员、席位库存和发票不能合成一条“加人收费”事件。二、先说清数据从哪来数据可以来自管理员核对、账单导出或团队实际获准使用的集成能力。不要假定每个方案都提供同样的事件接口。模型里把“内部发生了什么”和“在 Figma 后台观测到了什么”分开记录后者统一用 Observation 表示并保留证据引用。三、对象模型对象关键字段记录什么SeatRequestrequest_ref、member_ref、requested_type、requested_at谁申请了什么席位ApprovalDecisiondecision_ref、request_ref、approver_ref、decision、decided_at内部谁在何时批准SeatObservationmember_ref、seat_type、observed_at、evidence_ref后台实际看到此人拿到的席位InventoryObservationseat_type、purchased_count、assigned_count、observed_at某类席位买了多少、分配了多少InvoiceLineinvoice_ref、line_ref、period、description、amount、currency商户发票上的具体条目CardTransactioncard_txn_ref、merchant、amount、currency、card_status、observed_at卡侧交易及其状态发票和卡交易各自保留来源。审批已完成、商户发票还没出来时系统可以如实显示“等待账单”不会提前生成一笔已付款记录。四、审批与归因流程on_seat_request(request): record request once check intended seat type and available inventory send to the teams configured approval path record the decision after_provider_review: observe actual member seat and seat totals if an existing seat was assigned: mark allocation EXISTING_SEAT else if evidence supports an added paid seat: mark allocation ADDED_SEAT else: mark allocation UNDETERMINED after_invoice: link relevant invoice lines for review keep card reconciliation separate审批前的“检查库存”是内部预算控制实际分配结果以 Figma 后台为准。两个管理员在相近时间批准请求时前后两张库存快照未必能把新增席位准确归到某个人。这种情况保留UNDETERMINED交给管理员核对后台记录不要按“时间最近”硬分配费用。幂等方面重复导入同一审批决定时可以用“团队标识 请求引用 决定版本”做幂等键。缺少可靠的来源编号就标记待人工核对不要拿姓名和时间拼出一个看似唯一的事件。五、三条状态线分开走状态线典型状态判定依据席位REQUESTED、APPROVED、EXISTING_SEAT / ADDED_SEAT / UNDETERMINEDFigma 后台观测发票PENDING_INVOICE、INVOICED商户发票卡交易Authorized、SettledMPChat 卡记录这三条线经常不同步席位已经分配新增费用要到后续发票才出现发票已经生成卡侧交易可能还停在Authorized。MPChat 显示Settled只说明卡片侧这笔交易已结算从中读不出 Figma 的member_ref。六、对账关系可能是一对多或多对一Professional 年付方案在订阅期内新增席位可能产生额外的月度订阅账单其他方案的结算节奏不同。一张发票可能同时包含多类费用卡侧也可能只看到一次合并付款。amount merchant date适合用来找候选记录不适合自动判定某位成员造成了扣款。七、上线前的六个测试用例#场景预期结果1同类型空席位可用成员增加购买席位总数不变标记 EXISTING_SEAT2无空席位批准请求购买席位数增加发票稍后出现标记 ADDED_SEAT3两个请求相近时间获批库存快照不足以归因时保持 UNDETERMINED4成员从 Collab 改为 Full旧席位重新可用新席位按实际观测结果核对5成员离开团队席位可再次分配既有账期费用不被系统自动冲回6发票含多条费用卡侧只有一笔交易匹配结果保持可复核不拆分卡交易八、小结这个模型要能回答五个问题谁申请了什么审批了什么Figma 实际增加了什么商户开了什么账卡侧结算到了哪一步。五个问题各有独立的数据来源出了问题就能逐层定位用不着从一条付款通知倒推整条权限链。