销售业绩排名总是不可信？绩效复盘前先处理重复订单

教程定位

这篇教程解决什么问题

销售绩效复盘最怕的不是数据晚一点出来，而是排名出来以后没人敢信。一个常见原因是重复订单：同一笔交易在 CRM 订单导出里有一行，在收款流水里又有一行，在开票明细里还有一行；有时 CRM 里因为续约、转介绍、销售交接或补录，又多出一条看起来很像的新订单。到了复盘当天，销售额透视表一汇总，某个销售的业绩被算了两次，另一个销售的协作订单被完全漏掉，管理层开始质疑整张排名表。

这篇教程解决的就是这个具体问题：绩效复盘前，先把重复订单处理成一张可信的业绩统计底表。你要拿到 CRM 订单导出、收款流水、开票明细和销售归属规则，让 AI 帮你识别疑似重复、整理冲突、草拟保留规则，再由销售管理者或运营负责人确认最终口径。最后产物不是一段漂亮分析，而是三份能直接用于复盘的材料：重复订单判断规则、冲突处理表、业绩底表口径。

这里的重点不是客户去重，也不是预测回款，更不是判断哪个销售“应该”拿业绩。本文只处理重复交易：同一笔商业交易在多个系统、多个表、多个记录里被重复出现，导致业绩统计被放大。AI 可以帮你把订单号、客户、金额、合同、收款、开票和销售归属线索放在一起看，但不能自行决定业绩归属。尤其是多人协作、销售交接、渠道分成、补录订单、跨月收款和部分开票这些场景，归属规则必须来自公司制度和人工复核。

如果你是销售负责人、销售运营、财务 BP 或负责业绩复盘的数据同事，可以把本文当成一套复盘前的数据排雷流程。它不会替你做绩效判断，但会帮你减少一个很尴尬的问题：复盘会开到一半，才发现第一名的销售额里有 38 万是重复计算的。

使用场景

什么情况下最适合用这一套

你是销售管理者，月底要开绩效复盘会。销售运营从 CRM 导出本月订单，财务发来收款流水，财务助理又补了一份开票明细。你把三张表合在一起，按销售姓名透视，初看结果很振奋：华东一区本月完成 326 万，比目标高 18%。但仔细看明细，问题来了。

江苏云帆科技这笔 128000 元订单，在 CRM 里有两个订单号：`SO-2026-0618-0098` 和 `SO-2026-0618-0098-R1`。前者销售归属是李明，后者销售归属是张予，备注写着“续费补录”。收款流水里只有一笔 `PAY-20260620-7712`，金额也是 128000 元。开票表里有两张发票，一张 80000 元，一张 48000 元，发票备注都写着同一份合同 `HT-2026-YF-0618`。如果直接把三张表按客户和金额合并，很容易出现 128000 元被算两次，甚至被拆成 256000 元的假业绩。

类似问题不止一条。北京辰河制造有一笔 68000 元订单，CRM 里订单金额 68000 元，收款表里出现两笔：预付款 34000 元和尾款 34000 元。开票表只有一张 68000 元发票。如果没有区分“交易金额”和“收款明细”，AI 或透视表可能把两笔收款当成两笔订单。

广州悦行教育有一笔 96000 元订单，CRM 订单号是 `SO-2026-0622-0150`，收款流水是 96000 元，开票明细却是 72000 元，因为剩余 24000 元约定下月开票。有人看到金额不一致，就把它标成异常并从业绩里排除了。结果不是重复计算，而是把真实订单漏算了。

更麻烦的是销售归属。上海岭舟咨询的 210000 元订单，CRM 里有两条记录：一条归属原销售周岚，一条归属接手销售陈卓。收款流水只认合同号，不认销售。开票表只认客户抬头，不认销售。AI 如果只看“谁的记录更晚”或“谁的金额更完整”，就可能错误判断业绩归属。销售交接和协作分成不是数据相似度问题，而是管理规则问题，必须人工按制度确认。

这篇文章适合你在复盘前两三天使用。不要等到会议当天才处理重复订单。重复订单一旦进入排名、奖金测算和团队通报，再修正就会牵动信任成本。更好的做法是先做一张“业绩统计底表”，把每一笔交易是否计入、计入多少、归属谁、依据什么写清楚。排名表只从底表汇总，不直接从 CRM、收款表和开票表混算。

材料准备

开始前先把材料和边界备齐

先准备四类材料。材料不一定完美，但字段要尽量完整，文件名要清楚。真实使用时，请先脱敏客户联系人、手机号、邮箱、身份证、银行卡、合同扫描件链接等敏感信息。订单号、合同号、发票号也可以保留内部格式，但对外演示或给第三方模型时建议替换为虚构编号。

第一类是 CRM 订单导出。至少包含订单号、客户名称、合同号、订单金额、订单状态、签约日期、创建日期、销售负责人、协作销售、销售部门、订单类型、备注。CRM 表是业绩复盘的主要业务来源，但它也最容易出现补录、拆单、误建、重复机会转订单、销售交接后重建记录等问题。

第二类是收款流水。至少包含收款流水号、到账日期、客户名称、合同号或订单号、收款金额、收款类型、是否退款、收款备注、财务确认状态。收款表用于验证交易是否真实发生，但收款流水不是订单表。一笔订单可以分多次收款，多笔订单也可能合并打一笔款。绩效口径如果按签约额统计，不能把每条收款流水都当成新订单。

第三类是开票明细。至少包含发票号、开票日期、客户抬头、合同号或订单号、开票金额、发票状态、红冲标记、发票备注。开票表可以帮助校验客户和合同，但开票金额不一定等于当月业绩金额。有些客户先收款后分期开票，有些先开票后回款，有些会红冲重开。不要让 AI 把“发票条数”当成“订单条数”。

第四类是销售归属规则。它可以是正式制度，也可以是管理层确认过的一页口径说明。至少要回答这些问题：业绩按签约日期还是收款日期统计？协作销售是否分成？销售交接按哪个时间点归属？续费归属原销售还是客户成功？渠道订单归属渠道还是跟进销售？补录订单如何认定？没有这份规则，AI 只能帮你发现冲突，不能帮你裁决归属。

开始前还要先约定三个底层概念。

第一，什么叫“同一笔交易”。建议用“同一客户、同一合同或订单关系、同一商业承诺、金额可解释一致”来判断，而不是只看客户名称相同。客户名称相同但合同不同，可能是两笔真实订单；订单号不同但合同号、客户、金额和签约日期高度一致，可能是重复录入。

第二，什么叫“重复订单”。本文中的重复订单是“同一笔交易被多条订单级记录重复计入业绩”。它不包括客户去重，比如“江苏云帆科技有限公司”和“云帆科技”是不是同一客户；也不包括回款预测，比如这笔订单尾款什么时候到账。

第三，什么叫“业绩底表”。它是一张一行代表一笔可统计交易的表，每行都有唯一交易键、保留金额、销售归属、证据来源、冲突状态和人工复核结论。复盘排名从这张底表汇总，而不是直接把 CRM、收款和开票三张表相加。

实操流程

按这套步骤把工作跑起来

第一步，先确定业绩统计粒度。最容易出错的做法是把 CRM 订单、收款流水和开票明细都堆到一个表里，然后按销售汇总金额。这样会把“订单”“收款”“发票”三个不同粒度混在一起。正确做法是先确定底表一行代表什么。对绩效复盘来说，建议一行代表一笔可统计交易，也就是一个经过确认的 `performance_order_key`。

这个 `performance_order_key` 可以优先使用合同号。如果合同号缺失，可以用 CRM 订单号。如果 CRM 订单号不可靠，可以用客户名称标准化值、金额、签约日期、产品线组合生成临时键。临时键不能直接用于最终归属，只能用于发现疑似重复。比如 `江苏云帆科技|128000|2026-06-18|企业版年费` 可以帮助识别重复，但最终底表里仍要补上人工确认的合同号或保留说明。

第二步，让 AI 先做字段理解，不要直接让它给排名。把三张表的字段名和 20 到 50 行脱敏样例给 AI，让它输出字段解释和风险提示。你要特别关注金额字段：CRM 的订单金额、收款表的到账金额、开票表的开票金额不是同一个东西。CRM 金额通常用于签约额或订单额，收款金额用于到账验证，开票金额用于发票进度。三者可以互相校验，但不能随便相加。

第三步，列出重复来源。重复订单通常来自六类场景。

第一类是 CRM 重复录入。同一客户、同一合同、同一金额，被不同销售或同一销售录入多次。原因可能是机会转订单失败后手工补录，也可能是销售交接后新销售又建了一条订单。

第二类是续费或升级补录。原订单和续费订单金额接近，备注写得模糊。需要判断它们是两笔不同交易，还是同一笔续费被重复补录。

第三类是收款分期。收款表里一笔订单有预付款、尾款、补款。它们是同一笔交易的收款明细，不应被当作多笔订单。

第四类是开票拆分。发票按月份、产品线或税率拆成多张。它们是同一笔交易的开票明细，不应重复计入销售额。

第五类是红冲重开。开票表里出现原发票和红冲发票，再出现重开发票。AI 要标出红冲链路，不能把原票和重开票都当成真实收入证据。

第六类是销售归属冲突。同一笔交易在不同来源里显示不同销售，或 CRM 中出现主销售、协作销售、客户成功、渠道经理多个角色。这不是简单去重问题，要进入人工复核。

第四步，设定重复判断规则。建议把判断规则分成“强重复”“疑似重复”“非重复但需关联”三层。

强重复可以这样定义：合同号相同，客户名称相同或可确认同一主体，订单金额相同，签约日期相差不超过 3 天，且没有明确的升级、增购或追加服务说明。强重复一般只保留一条订单级记录，其余标记为重复来源。

疑似重复可以这样定义：合同号缺失或不一致，但客户名称高度相似、金额相同或差异小于 1%、签约日期接近、产品线相同，备注出现“补录”“重建”“转移”“续费录入”等词。疑似重复不能直接删除，要进入冲突处理表。

非重复但需关联可以这样定义：同一合同下有多条收款或多张发票，金额合计等于或可解释为 CRM 订单金额。它们不应变成多条业绩订单，但要作为收款或开票证据挂到同一笔底表记录上。

第五步，写清楚保留规则。保留规则不要只写“保留最新记录”。销售绩效场景里，最新记录不一定最准确。建议按证据优先级处理：已确认合同号优先于系统生成临时号；正式 CRM 订单优先于备注补录；财务确认收款可以作为真实性证据，但不改变订单金额口径；开票可以作为合同履行证据，但不自动决定业绩金额；销售归属以公司规则为准，不以字段谁更完整为准。

一套可执行的保留规则可以这样写：

第六步，让 AI 生成冲突处理表。冲突处理表不是最终底表，而是给人看的复核清单。每一行是一组疑似重复或冲突记录，至少包括：冲突组 ID、涉及订单号、客户、合同号、CRM 金额、收款金额、开票金额、涉及销售、冲突类型、AI 建议、需要人工判断的问题、最终处理结论。

这里要特别提醒 AI：建议只能写成“疑似同一交易，建议人工确认保留 `SO-2026-0618-0098`，将 `SO-2026-0618-0098-R1` 标记为补录重复”，不能写成“业绩归李明”。归属归谁必须引用公司规则和复核人结论。

第七步，人工复核冲突组。复核时不要逐行盯所有数据，而是按风险排序。优先看金额大的、涉及多人归属的、合同号缺失的、收款开票金额不一致的、备注含补录或转移的订单。每个冲突组只需要给出一个结论：保留哪条主记录、哪些记录作为证据关联、哪些记录排除、业绩归属如何按制度填写、是否需要销售或财务补充说明。

第八步，生成业绩底表。底表要能支撑排名，也要能追溯。建议字段包括：

| 字段名 | 含义 | 示例 | 谁确认 | | --- | --- | --- | --- | | performance_order_key | 绩效统计唯一键 | `HT-2026-YF-0618` | 销售运营 | | retained_crm_order_id | 保留的 CRM 订单号 | `SO-2026-0618-0098` | 销售运营 | | duplicate_source_ids | 被标记为重复的记录 | `SO-2026-0618-0098-R1` | 销售运营 | | customer_name_clean | 标准客户名 | 江苏云帆科技有限公司 | 销售运营 | | contract_id | 合同号 | `HT-2026-YF-0618` | 销售/财务 | | performance_amount | 计入业绩金额 | 128000 | 规则确认人 | | amount_basis | 金额依据 | CRM 已签约订单金额，收款已到账 | 财务 BP | | payment_evidence | 收款证据 | `PAY-20260620-7712` | 财务 | | invoice_evidence | 开票证据 | `INV-20260621-381; INV-20260628-406` | 财务 | | owner_sales | 业绩归属销售 | 李明 | 人工按制度确认 | | co_sales | 协作销售 | 张予 | 人工按制度确认 | | ownership_basis | 归属依据 | 6 月 18 日签约前主跟进人为李明；张予为交接协作 | 销售负责人 | | conflict_status | 冲突状态 | 已复核 | 销售运营 | | review_note | 复核说明 | R1 为续费补录重复，不计入第二笔业绩 | 复核人 |

第九步，用底表汇总排名。排名表只从 `performance_amount` 汇总，不再从 CRM 原始金额、收款金额和开票金额分别汇总。收款和开票只作为证据字段或补充指标。如果你还需要看回款率、开票率，可以从底表和明细表关联计算，但不要让回款明细改变订单条数。

第十步，留下口径说明。绩效复盘会之前，把重复订单处理口径写成一页说明，附在排名表后面。至少说明本次排除了多少条重复 CRM 记录，合并了多少组分期收款，关联了多少组拆分开票，多少组销售归属冲突经过人工复核。这样排名被质疑时，你不是临场解释，而是拿得出证据链。

1. 如果多条 CRM 订单合同号相同、金额相同、客户相同，只保留状态为“已签约/已生效”的订单作为业绩主记录。
2. 如果一条是正式订单，一条备注包含“补录”“重建”“迁移”，优先保留正式订单；补录记录作为重复来源留痕。
3. 如果 CRM 订单金额与收款合计一致，但收款拆成多笔，业绩金额仍取 CRM 确认订单金额，不按收款笔数拆成多笔业绩。
4. 如果开票拆成多张，开票金额合计用于校验，不增加业绩订单条数。
5. 如果金额不一致但可解释，例如部分开票、分期收款、税率调整，标记为“金额差异可解释”，不自动排除订单。
6. 如果销售归属冲突，AI 只输出冲突事实和候选依据，最终归属字段留给人工按销售归属规则填写。
7. 如果无法判断是否同一交易，先进入“待复核”，不要为了让排名表变整齐而强行合并。

输入示例

可以直接参考的输入材料

下面是一组虚构样例，用来演示你可以怎样把材料交给 AI。真实使用时，请替换成你们的脱敏数据，并把销售归属规则单独贴出来。注意，样例里的“李明、张予、周岚、陈卓”等均为虚构姓名。

这段输入有一个关键点：它把“销售归属规则”放进去了，而且明确禁止 AI 自行决定 `owner_sales`。如果没有这条限制，AI 可能会根据字段完整性、创建时间或备注语气推断归属，看起来很合理，但在绩效场景里是危险的。

【任务背景】
我是销售管理者，要在月度绩效复盘前处理重复订单。请基于 CRM 订单导出、收款流水、开票明细和销售归属规则，识别疑似重复订单，输出重复判断规则、冲突处理表和业绩底表口径。不要自行决定业绩归属；遇到销售归属冲突时，只能标出冲突事实、候选依据和需要人工确认的问题。

【CRM 订单导出】
crm_order_id,customer_name,contract_id,order_amount,order_status,signed_at,created_at,owner_sales,co_sales,order_type,remark
SO-2026-0618-0098,江苏云帆科技有限公司,HT-2026-YF-0618,128000,已签约,2026-06-18,2026-06-18,李明,,续费,企业版年费
SO-2026-0618-0098-R1,江苏云帆科技,HT-2026-YF-0618,128000,已签约,2026-06-18,2026-06-20,张予,李明,续费,续费补录，交接后重建
SO-2026-0620-0112,北京辰河制造有限公司,HT-2026-CH-0620,68000,已签约,2026-06-20,2026-06-20,王珂,,新购,标准版
SO-2026-0622-0150,广州悦行教育科技,HT-2026-YX-0622,96000,已签约,2026-06-22,2026-06-22,林岚,,新购,企业版，剩余 24000 下月开票
SO-2026-0624-0188,上海岭舟咨询有限公司,HT-2026-LZ-0624,210000,已签约,2026-06-24,2026-06-24,周岚,陈卓,新购,原销售签约
SO-2026-0624-0188-H,上海岭舟咨询,HT-2026-LZ-0624,210000,已签约,2026-06-24,2026-06-25,陈卓,周岚,新购,交接后补录

【收款流水】
payment_id,received_at,customer_name,contract_id,payment_amount,payment_type,finance_status,remark
PAY-20260620-7712,2026-06-20,江苏云帆科技有限公司,HT-2026-YF-0618,128000,一次性收款,已确认,银行到账
PAY-20260621-8820,2026-06-21,北京辰河制造有限公司,HT-2026-CH-0620,34000,预付款,已确认,首款
PAY-20260628-9041,2026-06-28,北京辰河制造有限公司,HT-2026-CH-0620,34000,尾款,已确认,尾款
PAY-20260624-3321,2026-06-24,广州悦行教育科技,HT-2026-YX-0622,96000,一次性收款,已确认,到账
PAY-20260627-1180,2026-06-27,上海岭舟咨询有限公司,HT-2026-LZ-0624,210000,一次性收款,已确认,到账

【开票明细】
invoice_id,invoiced_at,buyer_name,contract_id,invoice_amount,invoice_status,red_letter_flag,remark
INV-20260621-381,2026-06-21,江苏云帆科技有限公司,HT-2026-YF-0618,80000,已开票,否,拆分开票 1
INV-20260628-406,2026-06-28,江苏云帆科技有限公司,HT-2026-YF-0618,48000,已开票,否,拆分开票 2
INV-20260625-221,2026-06-25,北京辰河制造有限公司,HT-2026-CH-0620,68000,已开票,否,全额开票
INV-20260626-118,2026-06-26,广州悦行教育科技,HT-2026-YX-0622,72000,已开票,否,剩余下月开票
INV-20260629-517,2026-06-29,上海岭舟咨询有限公司,HT-2026-LZ-0624,210000,已开票,否,全额开票

【销售归属规则】
1. 月度签约业绩以已签约 CRM 订单金额为主，收款和开票作为真实性和履约证据。
2. 同一合同号只允许形成一条业绩主记录，分期收款和拆分开票不得增加订单条数。
3. 销售交接订单：以签约日前主跟进销售为主归属；交接后补录记录不得改变归属，除非销售负责人在复核表中明确调整。
4. 协作销售可以记录在 co_sales，但是否分成必须人工确认。
5. AI 不允许自行决定 owner_sales，只能输出冲突和待确认问题。

【输出要求】
1. 输出重复订单判断规则。
2. 输出冲突处理表，标出订单号、客户、金额、收款、开票、销售归属冲突和建议处理动作。
3. 输出业绩底表字段口径，说明每个字段从哪里取数。
4. 对无法判断的记录标记为待人工复核，不要强行合并或强行归属。

提示词

可复制使用的提示词

你可以直接复制下面这段提示词，把其中的数据样例替换成自己的表头和脱敏样例。建议先用 20 到 50 行样本跑通，再处理全量数据。

如果你有全量 CSV，不建议一次性把所有数据都复制进对话窗口。更稳的做法是先让 AI 根据字段和样例生成规则，再在表格工具、SQL 或脚本里按规则跑全量，最后把异常组抽样给 AI 辅助解释。AI 适合参与“规则形成、冲突解释、复核清单”，不适合在没有可追溯流程的情况下直接改全量业绩数据。

你是一名销售运营数据分析助手。我要在月度绩效复盘前处理重复订单，避免同一笔交易在 CRM、收款流水和开票明细中被重复计入销售业绩。

请注意：
1. 你的任务是识别疑似重复交易、整理冲突、草拟规则和生成底表口径。
2. 你不能自行决定销售业绩归属。凡是 owner_sales、co_sales、销售交接、协作分成、渠道归属存在冲突，都必须标记为“待人工复核”，并写出需要复核的问题。
3. 不要把收款流水条数当成订单条数。一笔订单可以有多次收款。
4. 不要把开票明细条数当成订单条数。一笔订单可以拆成多张发票，也可能部分开票。
5. 不要处理客户去重或回款预测。本任务只处理重复交易导致的业绩重复计算。

我会提供四类材料：
- CRM 订单导出：包含订单号、客户、合同号、金额、状态、签约日期、销售负责人、协作销售、备注。
- 收款流水：包含流水号、到账日期、客户、合同号、收款金额、收款类型、财务状态、备注。
- 开票明细：包含发票号、开票日期、客户抬头、合同号、开票金额、发票状态、红冲标记、备注。
- 销售归属规则：包含业绩统计日期、金额口径、交接归属、协作分成、渠道归属等规则。

请按以下步骤输出：

第一部分：字段理解和风险提示
- 分别解释 CRM、收款、开票里的关键字段。
- 标出哪些字段可用于识别同一交易，哪些字段只能用于校验，哪些字段不能直接加总。

第二部分：重复订单判断规则
- 把规则分为“强重复”“疑似重复”“非重复但需关联”。
- 每条规则包含：判断条件、处理动作、需要人工确认的点。

第三部分：冲突处理表
- 每一行代表一个冲突组。
- 字段包括：conflict_group_id、涉及 CRM 订单号、客户、合同号、CRM 金额、收款证据、开票证据、涉及销售、冲突类型、AI 建议动作、需要人工确认的问题。
- 如果销售归属冲突，不要填写最终归属，只写“待人工复核”。

第四部分：业绩底表口径
- 输出一张字段口径表，说明 performance_order_key、performance_amount、owner_sales、payment_evidence、invoice_evidence、conflict_status、review_note 等字段如何取数。
- 明确 ranking 只能从 performance_amount 汇总。

第五部分：人工检查清单
- 列出复盘前必须由销售管理者、销售运营或财务 BP 检查的事项。
- 特别检查大额订单、多人归属、补录订单、金额不一致、红冲重开、合同号缺失。

下面是我的材料：
【在这里粘贴 CRM 订单导出字段和样例】
【在这里粘贴收款流水字段和样例】
【在这里粘贴开票明细字段和样例】
【在这里粘贴销售归属规则】

输出样例

AI 应该输出到什么程度

下面是基于前面虚构数据的一段输出样例。你可以用它校验 AI 的回答是否达标：它应该能识别重复来源，也应该明确哪些问题必须人工处理。

【1. 重复订单判断规则样例】

| 规则编号 | 重复类型 | 判断条件 | 处理动作 | 人工确认点 | | --- | --- | --- | --- | --- | | R01 | CRM 强重复 | 合同号相同、客户相同或明显同一主体、CRM 金额相同、签约日期相同，且其中一条备注含“补录/重建/迁移” | 保留正式订单作为业绩主记录，补录记录写入 `duplicate_source_ids` | 确认补录记录是否确实不是新增交易 | | R02 | 收款分期关联 | 同一合同号下多条收款，收款金额合计等于 CRM 订单金额 | 收款明细作为 `payment_evidence`，不增加业绩订单条数 | 确认是否存在多笔不同订单合并收款 | | R03 | 开票拆分关联 | 同一合同号下多张发票，发票合计等于 CRM 订单金额 | 发票明细作为 `invoice_evidence`，不增加业绩订单条数 | 检查红冲、作废和重开状态 | | R04 | 部分开票差异 | 开票金额小于订单金额，但备注或制度说明为分期开票 | 标记为“金额差异可解释”，业绩金额仍按规则取 CRM 订单金额 | 财务确认剩余开票安排 | | R05 | 销售归属冲突 | 同一合同号对应多条 CRM 记录，owner_sales 不一致 | 标记“归属待人工复核”，不得由 AI 填写最终归属 | 销售负责人按交接和协作规则确认 |

【2. 冲突处理表样例】

| conflict_group_id | 涉及记录 | 客户 | 合同号 | 金额冲突 | 收款证据 | 开票证据 | 涉及销售 | 冲突类型 | AI 建议动作 | 需要人工确认的问题 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | CG-001 | `SO-2026-0618-0098`; `SO-2026-0618-0098-R1` | 江苏云帆科技有限公司 | `HT-2026-YF-0618` | 两条 CRM 均为 128000；收款合计 128000；开票合计 128000 | `PAY-20260620-7712` | `INV-20260621-381`; `INV-20260628-406` | 李明；张予 | CRM 补录重复 + 销售归属冲突 | 疑似同一交易。建议保留正式订单 `SO-2026-0618-0098`，将 R1 写入重复来源。归属不得自动判断。 | R1 是否只是交接补录？本单主归属按签约前主跟进人还是交接后负责人？ | | CG-002 | `SO-2026-0620-0112` + 两笔收款 | 北京辰河制造有限公司 | `HT-2026-CH-0620` | CRM 68000；两笔收款各 34000，合计 68000；开票 68000 | `PAY-20260621-8820`; `PAY-20260628-9041` | `INV-20260625-221` | 王珂 | 分期收款，不是重复订单 | 保留一条业绩主记录，收款流水作为证据关联 | 是否按签约额一次计入，还是按到账月确认？需按绩效制度确认 | | CG-003 | `SO-2026-0622-0150` | 广州悦行教育科技 | `HT-2026-YX-0622` | CRM 96000；收款 96000；开票 72000 | `PAY-20260624-3321` | `INV-20260626-118` | 林岚 | 部分开票差异 | 不应因开票金额不足而排除订单。标记为部分开票，保留业绩金额待规则确认 | 剩余 24000 是否确认为下月开票？是否影响本月绩效口径？ | | CG-004 | `SO-2026-0624-0188`; `SO-2026-0624-0188-H` | 上海岭舟咨询有限公司 | `HT-2026-LZ-0624` | 两条 CRM 均为 210000；收款 210000；开票 210000 | `PAY-20260627-1180` | `INV-20260629-517` | 周岚；陈卓 | CRM 交接补录 + 销售归属冲突 | 疑似同一交易，只保留一笔业绩。归属必须人工确认 | 签约前主跟进人是谁？交接是否有书面确认？协作分成比例是否适用？ |

【3. 业绩底表样例】

| performance_order_key | retained_crm_order_id | duplicate_source_ids | customer_name_clean | contract_id | performance_amount | amount_basis | payment_evidence | invoice_evidence | owner_sales | co_sales | conflict_status | review_note | | --- | --- | --- | --- | --- | ---: | --- | --- | --- | --- | --- | --- | --- | | `HT-2026-YF-0618` | `SO-2026-0618-0098` | `SO-2026-0618-0098-R1` | 江苏云帆科技有限公司 | `HT-2026-YF-0618` | 128000 | CRM 已签约订单金额；收款和开票均可校验 | `PAY-20260620-7712` | `INV-20260621-381`; `INV-20260628-406` | 待人工复核 | 待人工复核 | 归属待复核 | R1 疑似交接补录，不形成第二笔业绩 | | `HT-2026-CH-0620` | `SO-2026-0620-0112` | | 北京辰河制造有限公司 | `HT-2026-CH-0620` | 68000 | CRM 已签约订单金额；两笔收款合计一致 | `PAY-20260621-8820`; `PAY-20260628-9041` | `INV-20260625-221` | 王珂 | | 已复核 | 分期收款，不重复计入 | | `HT-2026-YX-0622` | `SO-2026-0622-0150` | | 广州悦行教育科技 | `HT-2026-YX-0622` | 96000 | CRM 已签约订单金额；收款已到账，开票部分完成 | `PAY-20260624-3321` | `INV-20260626-118` | 林岚 | | 金额差异可解释 | 剩余 24000 下月开票，不影响订单条数 | | `HT-2026-LZ-0624` | `SO-2026-0624-0188` | `SO-2026-0624-0188-H` | 上海岭舟咨询有限公司 | `HT-2026-LZ-0624` | 210000 | CRM 已签约订单金额；收款和开票均可校验 | `PAY-20260627-1180` | `INV-20260629-517` | 待人工复核 | 待人工复核 | 归属待复核 | 交接补录，不形成第二笔业绩 |

这个输出样例里有两个值得保留的做法。第一，它没有把收款和开票直接加到业绩金额里，而是把它们放在证据字段。第二，它在销售归属冲突处写的是“待人工复核”，没有让 AI 自行决定李明、张予、周岚、陈卓谁拿业绩。销售管理场景里，这一点比模型回答是否流畅更重要。

人工验收

人要怎么检查和改到可用

AI 输出初稿后，人工检查至少要做七件事。

第一，检查金额口径。确认 `performance_amount` 到底取 CRM 签约金额、合同金额、含税金额、不含税金额，还是当月确认金额。不要让同一张底表里有的订单用含税金额，有的订单用不含税金额。收款金额和开票金额可以校验，但不能悄悄替换绩效金额。

第二，检查订单粒度。看底表是否做到“一笔交易一行”。如果北京辰河制造因为两笔收款生成了两行业绩，说明 AI 或处理流程把收款流水误当成订单。如果江苏云帆科技因为两张发票生成了两行业绩，说明开票明细被误当成订单。

第三，检查合同号缺失的记录。合同号是最强的关联字段之一，但不是所有 CRM 都填得完整。合同号缺失时，AI 可能用客户名称和金额猜测重复。猜测只能进入“疑似重复”，不能直接合并。金额越大，越要找销售或财务补合同号。

第四，检查销售归属冲突。凡是同一交易涉及两个以上销售，都要看制度，而不是看 AI 推理。比如“创建时间更晚的一条归新销售”“备注里写交接所以归接手人”“协作销售字段不为空所以平分”这些都是不可靠推断。归属必须由销售负责人确认，并在 `ownership_basis` 或 `review_note` 里写清依据。

第五，检查红冲、退款和作废。开票表里如果有红冲发票，必须确认原票是否已被冲销，重开发票是否替代原票。收款表里如果有退款或冲正，也要确认是否影响业绩金额。不要只看金额绝对值相同就认为可以抵消。

第六，检查部分开票和分期收款。金额不一致不一定代表错误。广州悦行教育的 96000 元订单只开了 72000 元发票，如果制度按签约额统计，就不应因为开票不足而排除；如果制度按回款或开票确认，则要按制度处理。AI 可以标记差异，但不能决定绩效口径。

第七，检查复盘可解释性。最后的排名表里，每个大额订单都应该能追溯到底表，底表能追溯到 CRM、收款和开票证据。销售问“为什么我的 128000 只算了一次”，你能指向冲突组；财务问“为什么这笔开票只有 72000 还计入 96000”，你能指向绩效制度；销售负责人问“为什么归属待复核”，你能指向交接规则缺失。

修改 AI 输出时，建议保留三类状态：`已复核`、`待人工复核`、`不计入业绩`。不要把所有异常都改成“已处理”。状态越模糊，复盘时越难解释。对于待复核记录，可以先从排名表里单独列出“暂缓计入金额”，等负责人确认后再进入正式排名。

还有一个很实用的小动作：对排名影响大的冲突组单独做“影响金额”列。比如江苏云帆科技重复计入会多出 128000 元，上海岭舟咨询重复计入会多出 210000 元。这样销售管理者能优先处理影响排名的冲突，而不是平均用力检查所有小额订单。

失败反例

这些失败反例要提前避开

反例 1：把 CRM、收款和开票三张表直接纵向合并，然后按金额求和。

这种做法看起来省事，实际会把不同业务对象混在一起。CRM 订单金额代表签约或订单，收款流水代表到账，开票明细代表发票。江苏云帆科技 128000 元，如果 CRM 一条、收款一条、发票两条都进入同一个金额列，最后可能变成 128000 + 128000 + 80000 + 48000 = 384000。复盘时看起来业绩暴涨，其实只是证据被当成收入重复相加。

正确做法是让业绩底表只保留一条主交易记录，收款和开票作为证据关联。排名只汇总 `performance_amount`，不汇总所有来源金额。

反例 2：看到客户名称和金额相同，就让 AI 自动删除较晚的一条。

客户名称和金额相同不一定是重复。一个大客户可能在同一天买了两条不同产品线，也可能追加采购相同金额的服务包。反过来，订单号不同、客户名称略有差异，也可能确实是同一笔交易被补录。只靠相似度自动删除，会把真实新增订单误删，也会漏掉名称不完全一致的重复记录。

正确做法是分层判断。合同号相同、金额相同、签约日期相同、备注含补录，才更接近强重复；合同号缺失但客户、金额、日期相似，只能进入疑似重复；不同产品线、不同合同范围、不同商务承诺，要保留为可能的独立交易，等待人工确认。

反例 3：让 AI 根据备注判断业绩归属。

例如上海岭舟咨询的两条 CRM 记录，一条写“原销售签约”，一条写“交接后补录”。AI 可能会说“建议归属周岚，因为原销售签约”，也可能说“建议归属陈卓，因为交接后补录记录更新”。这两种回答都可能违反公司制度。销售归属不是文本分类题，而是管理规则题，涉及奖金、团队公平和历史承诺。

正确做法是让 AI 输出“归属冲突事实”：同一合同对应周岚和陈卓两条记录，签约日期为 2026-06-24，补录记录创建于 2026-06-25，规则说明交接订单以签约日前主跟进销售为主归属，但仍需销售负责人确认。最终 `owner_sales` 由人工填写，并留下 `ownership_basis`。

反例 4：把开票不足当成订单无效。

广州悦行教育 96000 元订单，当月只开票 72000 元。AI 如果按“CRM 金额与开票金额不一致”直接标为异常排除，就会漏算真实业绩。很多 B2B 订单都有分期开票、跨月开票、按验收节点开票，开票不足只能说明履约进度或财务节奏，不一定说明订单不存在。

正确做法是把它标记为“金额差异可解释”或“部分开票待确认”，再根据绩效制度判断是否计入。如果制度按签约额统计，收款已到账且 CRM 已签约，这笔订单可以进入业绩底表；如果制度按开票确认，则要按开票口径处理，但这仍然是人工制度问题。

反例 5：为了让排名表整齐，把所有待复核记录强行归类。

有些团队会要求“不要留空”。于是 AI 被迫把每条记录都归入已复核、已排除或已归属。短期看表格好看，长期会让排名失真。待复核是一种有效状态，尤其是大额订单、多人归属、合同号缺失、红冲重开等情况。没有证据时，宁可把金额暂缓计入，也不要用模型猜测填满表格。

正确做法是保留 `conflict_status=待人工复核`，并在排名页单独展示“待确认金额”。复盘会可以先确认无争议排名，再处理待复核金额对排名的影响。

主题边界

它和相邻主题的区别

这篇教程只处理“重复交易导致的业绩重复计算”。它和几个相邻主题容易混在一起，但处理方法不同。

第一，它不是客户去重。客户去重要解决的是“江苏云帆科技有限公司”“江苏云帆科技”“云帆科技集团”是不是同一客户主体，通常涉及客户主数据、工商主体、联系人、地址和客户层级。本文只在重复订单判断中使用客户名称作为线索，不建立客户主数据，也不决定客户合并。

第二，它不是回款预测。回款预测要判断尾款什么时候到账、逾期风险有多高、销售或财务要做什么催收动作。本文只把收款流水作为交易真实性和金额校验的证据，不预测未来回款，也不评价客户付款风险。

第三，它不是开票进度管理。开票管理关注哪些合同未开票、哪些发票要红冲、哪些客户抬头错误、哪些开票跨月。本文只把开票明细用于识别拆分开票、部分开票和红冲重开，避免开票条数被当成订单条数。

第四，它不是销售奖金制度设计。奖金制度要决定签约额、回款额、毛利、续费、协作、渠道、跨区、交接、退款等如何影响奖金。本文不设计制度，只要求你把已有制度写进输入材料，让 AI 不越界裁决。

第五，它不是销售漏斗分析。漏斗分析关注线索、商机、报价、签约、回款各阶段转化率。本文只处理已经进入订单或合同阶段的交易记录，目标是让绩效底表可信。

最简单的判断方法是问一句：这个问题是否会导致同一笔交易在业绩排名里被算多次？如果是，就属于本文范围。比如同一合同在 CRM 被补录两次、同一订单被两张发票拆开后重复计入、同一笔订单的预付款和尾款被当成两笔销售，都属于本文。客户名称标准化、预测尾款到账时间、制定协作分成比例、催客户开票资料，则属于其他主题。

绩效复盘里的数据可信度，往往不是靠最后一张图表提升的，而是靠底表里一条条“为什么保留、为什么排除、为什么待复核”的说明建立的。AI 可以把这些说明整理得更快、更完整，但边界要守住：重复订单可以让 AI 帮你识别，业绩归属不能让 AI 替你决定。