单据客户识别

要解决什么问题

在「先分析单据、再归档」的流水线里，第三步往往卡在：同一份 PDF 或邮件附件已经结构化，但系统仍不知道它属于哪个客户、是进项还是销项。若在这一步用 SIREN 或模糊匹配「两边一起猜」，很容易把买卖双方的登记号写进同一客户档案——后续对账和分类都会脏数据。

本技能只做一件事：根据已分析结果认出客户，并在目录里附加一块 client 元数据；它不移动文件，也不替会计师拍板。

如何识别客户

输入是包含第二步分析产物的目录，可选带上第一步的邮件头。输出是原目录加上客户识别块。

识别优先级从稳到险：

• 银行流水：账户持有人即客户，视为确定；新客户会以 auto-from-bank-statement 方式写入 clients.json。
• 发票：将开票方、收票方与已知公司名比对（先完全相等，再相似度 ≥ 0.82）。仅一侧命中时，该侧为客户——开票方命中为销售（out），收票方命中为采购（in）。两侧都命中或都未命中时，标记 needs_review，并生成一句给会计师的具体问题，不猜测。
• SIREN：仅用于在已通过名称锁定客户后提高置信度；分析结果里买卖双方 SIREN 常混在一起，本技能不会用 SIREN 自动选边或回填登记号，避免历史里那种「寄生 SIREN」污染。

向会计师汇报时用口语化结论，例如说明这是一笔谁卖给谁；若存在 question 字段，应原样提问并等待答复，再补全客户信息后重跑。

边界与注意点

• 客户一旦确定，归档归类交给后续 classement-document（第四步），本技能不负责落盘路径。
• clients.json 只写入高把握信息（如流水持有人）；邮件域名、SIREN 等扩展字段需经会计师确认后再学，而不是从单张发票推断。
• 单张单据层面不判断重复、是否已付款、是否与银行流水勾对——这些应在客户 dossier 维度处理。