第五讲：期现匹配模式、前提与换仓场景
匹配的三种模式
背景学习材料
期现匹配，说白了就是回答一个问题：这笔期货交易，是为了哪一段现货业务服务的。
不同企业的业务组织方式不同，匹配方式也不同。常见可以分成三种：单单匹配、整体匹配和无合同匹配。
一、单单匹配
单单匹配，是一张现货合同对应一组期货交易。
比如某张采购合同已经定价，需要卖出期货处理风险；或者某张销售合同已经定价，需要买入期货处理风险。期货成交以后，直接匹配到这张合同上。
这种模式的好处是清楚。合同、点价、套保、期货盈亏都能回到同一张单据上，后续看敞口、基差、利润和归档都比较容易。
它适合合同边界清楚、业务流程规范、每笔套保都有明确现货依据的企业。缺点是管理要求高，业务人员和交易员必须把合同、指令、成交、反冲都跟得上。
二、整体匹配
整体匹配，不是把期货逐笔绑到某一张合同，而是放在一个业务整体里管理。
比如企业把所有铜采购和销售放在铜业务方案里，把所有豆油采购和销售放在豆油业务方案里。期货交易先服务这个整体方案，再看整体敞口是否偏多或偏空。
这种模式的好处是灵活。很多贸易企业每天合同很多、数量零散、点价频繁，如果强行逐单匹配，工作量会很大。整体匹配可以先管住品种、方向和净敞口，再在需要时做明细解释。
它适合交易频繁、合同碎片化、企业更关注整体库存和整体风险的场景。缺点是单张合同的期货盈亏归属没有单单匹配那么直观，后续要靠规则、备注和分摊口径说清楚。
三、无合同匹配
无合同匹配，是期货交易发生时，还没有明确的现货合同可以绑定。
这种情况并不少见。比如企业先根据采购计划、销售计划、库存计划做期货；或者交易员先为即将发生的业务锁定价格，合同后面才补齐。也可能是业务本身按客商、业务员或品种池管理，不要求每笔期货一开始就对应具体合同。
无合同匹配的重点，是先把交易事实和业务意图记清楚。至少要知道这笔期货属于哪个方案、哪个品种、哪个方向、为什么做、后续准备匹配到哪里。
等合同形成以后，再把期货和合同补做关联；如果最终没有形成合同，也要说明这笔期货是计划调整、库存管理、反冲处理，还是其他业务原因。
简单说，单单匹配重在精确，整体匹配重在汇总，无合同匹配重在先留住业务事实。企业选择哪种模式，不是看哪种更高级，而是看业务流程能不能支撑这种管理粒度。
重点笔记
- 期现匹配回答：这笔期货为哪一段现货业务服务。
- 单单匹配重精确，整体匹配重汇总，无合同匹配重保留交易事实。
- 没有哪种模式天然高级，关键看业务流程能支撑哪种管理粒度。
理解要点
期现匹配回答的是一句话：这笔期货到底服务哪段现货业务。不同企业回答这个问题的精细程度不一样，所以才会有不同匹配模式。
单单匹配最清楚，一张合同对应一组期货，适合要精确核算单笔合同利润的场景。它的好处是责任清楚，缺点是操作要求高。
整体匹配把同类业务放进一个池子。比如铜业务整体看采购、销售、库存和期货，不强求每一手期货都立刻对应某一张合同。它适合业务频繁、品种相对标准、管理口径比较稳定的企业。
无合同匹配不是没有管理，而是合同还没形成，或者业务先于合同发生。此时期货交易必须先留下交易事实和原因，等合同、订单或业务归属明确后再补匹配。
不要问哪种模式最高级。正确的问题是：企业现在的业务流程、核算要求和人员协作，能支撑哪种粒度。
实现高效期现匹配的前提
背景学习材料
高效匹配，是所有期现管理者共同的愿望。 企业上线期现管理系统，核心诉求往往很朴素：在把期现关系管理得更清楚、更规范的前提下，尽量减少人工工作量。毕竟，没有人希望新系统上线后，反而让业务变得更麻烦。 但要实现这个目标，最大的前提不是系统功能有多复杂，而是业务流程本身是否描述清晰。 换句话说，自动化不是让系统去猜业务，而是让系统执行已经明确的业务流程。流程越清楚，系统越容易自动匹配；流程越依赖口头沟通、事后回忆和人工判断，系统就越难减少工作量。 以下是一些比较典型、也更容易实现高效匹配的业务场景。
- 自动匹配：整体模式 企业内部可以简单划分为铜套保、铝套保等业务类别。 所有铜期货交易，统一与铜套保整体匹配；所有铝期货交易，统一与铝套保整体匹配。只要业务边界清楚，系统就可以自然实现自动匹配，减少人工逐笔选择和确认。
- 自动匹配：单单模式 每次业务都先形成现货合同，再由合同发起套保指令。 交易员按照指令完成交易后，期货成交结果可以自动与对应合同匹配。这个模式的关键在于：合同、指令、成交之间存在清晰的链路，系统可以顺着链路自动完成匹配。
- 后匹配模式 有些业务并不一定先有合同。 在这种情况下，期货交易成功后可以先行搁置，由交易员在委托单或成交记录上填写备注。等后续合同形成后，再通知交易员或相关岗位人员完成匹配。 这种模式虽然不能完全自动化，但只要备注清楚、流程明确，也可以显著降低后续沟通和核对成本。
- 反冲场景 例如某个合同原本已经套保 50 手，后来因业务变动取消了一半。 此时可以针对该合同发起反冲指令，并备注“合同取消”或其他业务原因。交易员按指令完成交易后，系统即可将反冲成交结果自动匹配到原合同上，形成完整的业务闭环。
- 交货换仓场景 例如 A、B 两个合同，B 合同交货时需要平掉 A 合同对应的期货头寸。 这时可以发起交货换仓指令，明确指定期货盈亏的截留方式，将 A 作为换出合同，将 B 作为换入合同，并输入对应数量。交易员按指令完成交易后，成交结果即可自动与相关合同完成匹配。
- 移仓换月场景 当业务需要进行移仓换月时，应通过系统发起移仓换月指令。 交易员按照指令执行后，交易结果可以自动回到对应业务场景中，避免后续人工拆分、追踪和补录。
- 善用委托单备注 如果交易员下单后，并不是由本人完成合同匹配，就应该尽早、准确地填写委托单备注。 清楚的备注可以帮助其他交易员或业务岗位人员理解交易背景，并继续完成后续匹配动作。备注不是额外负担，而是降低协作成本的重要信息入口。
- 客商或业务经理自助点价 如果点价与期货成交强相关，建议使用系统的指令功能。 通过指令发起点价或套保需求，可以在交易完成的同时，自动完成点价记录、合同价格更新以及期现匹配，减少人工传递信息带来的延迟和差错。
总结
实现高效期现匹配的关键，不是把所有复杂情况都交给系统临场判断，而是先把业务流程讲清楚、定清楚、执行清楚。 系统擅长处理明确的关系和稳定的流程。只要合同、指令、成交、备注、点价之间的业务链路足够清晰，期现匹配就可以从大量人工操作，逐步转变为以系统自动处理为主、人工确认为辅的管理模式。
重点笔记
- 高效匹配的前提不是系统猜得准，而是业务流程描述得清楚。
- 合同、指令、成交、备注、点价之间链路越清楚，自动化越容易。
- 特殊场景要靠指令和备注把原因留住。
理解要点
高效匹配不是系统自己猜业务。系统只能沿着已经说清楚的链路，把合同、指令、成交、匹配和归档串起来。
如果合同没有写清业务边界，指令没有写清套保原因，成交没有回到指令，备注也没有说明背景，后面的人就只能靠电话和记忆去补信息。这样的业务很难自动化。
反过来，只要每个环节都说清楚，匹配就会变简单。合同提供业务依据，指令说明为什么做期货，成交记录交易事实，匹配确认归属关系，归档说明风险已经结束。
判断链路是否清楚时，可以站在“下一个接手的人”的角度看：他不问任何人，只看记录，能不能知道这笔期货为什么做、为谁做、做到哪里了。
自动化的前提不是技术复杂，而是业务信息足够完整、方向足够明确、数量和原因都能追得上。
详解单单匹配交叉期货换仓的业务场景
背景学习材料
A 合同原来套 6 月期货，B 合同原来套 9 月期货。后来生产计划变了，B 要提前交货，A 要延期交货。业务上想把套保关系对调：B 接 6 月，A 接 9 月。
这个问题如果直接改匹配关系，很难解释。因为 A 的 6 月期货不是从今天才有的，前面还可能经历过 5 月到 6 月的移仓。B 的 9 月期货也已经跑了一段时间。今天一改挂靠，过去的盈亏就容易被系统“带过去”，后面业务、财务、审计都会问：这笔盈亏为什么归它？
比较干净的办法，是用系统里的“虚拟期货”做一次内部换仓。
虚拟期货不是交易所真实成交，也不进期货公司结算单。它只是系统里的管理记录。关键要求有三个：成对生成、价格相同、数量相同。一边用来对冲旧合同下原来匹配的期货，一边用来作为新合同的起算头寸。两条虚拟记录方向相反、金额相等，系统总敞口不变，但合同之间的责任被切开了。
交换日价格怎么取？
内部换仓，可以用交换日对应月份期货的结算价，也可以用业务规定的任意换仓间隔。这个价格就是虚拟期货的价格，也是新套保关系的起算价。
具体做法可以这样理解。
第一步，处理 A 的 6 月。系统给 A 生成一笔 6 月虚拟反向期货，价格用交换日 6 月结算价，数量等于本次换出的数量，备注写“交叉换仓虚拟，A 转 B”。这笔虚拟期货和 A 原来匹配的 6 月期货对冲，系统自然生成一笔期货平仓盈亏。
这笔盈亏的名目不需要再造一个奇怪科目，就叫期货平仓盈亏；在管理报表上可以归到“换仓前套保盈亏”或“原套保关系累计盈亏”。因为虚拟期货上已经备注了“交叉换仓虚拟，A 转 B”，所以系统不会缺少原因信息。看到这笔平仓盈亏，就能知道它不是普通主动平仓，而是因为 A、B 合同换仓产生的内部截点。
第二步，系统同时生成另一笔成对的 6 月虚拟期货，价格、数量与第一笔完全相同，方向相反，挂到 B 合同上，备注同样写清楚“交叉换仓虚拟，A 转 B”。这笔虚拟期货就是 B 接手 6 月套保关系的起点。以后 B 的 6 月套保盈亏，就从这个虚拟价格开始算。
第三步，用同样方法处理 B 的 9 月。B 原来匹配的 9 月期货，用一笔 9 月虚拟反向期货在交换日结算价上对冲，生成 B 的换仓前期货平仓盈亏；另一笔成对的 9 月虚拟期货挂到 A 合同上，作为 A 接手 9 月套保关系的起点。
这样做以后，问题就清楚了。
过去的盈亏，不靠人工分摊，而是通过“原真实期货 + 虚拟反向期货”的匹配自然结出来。A 原来 5 月到 6 月的历史盈亏仍留在 A；B 原来 9 月的历史盈亏仍留在 B。未来的盈亏，则从交换日虚拟价格往后算。B 接 6 月，就只承担 6 月从交换日之后的涨跌；A 接 9 月，也只承担 9 月从交换日之后的涨跌。
这里没有所谓“生产计划变化带来的期货差额”。生产计划变化只是换仓原因，不会凭空制造期货盈亏。期货盈亏只来自期货价格变动。原始开仓价只影响旧合同截至交换日的平仓盈亏；新合同的起点是交换日虚拟价格，不是原始开仓价。
套期会计也可以顺着这个逻辑解释，但要注意一句话：虚拟期货是系统管理工具，不是真实金融工具，不能把它当作会计上的套期工具入账。会计上真正的套期工具，仍然是真实持有的期货。
对公允价值套期来说，交换日前，A-6 月、B-9 月各自按原套期关系核算。期货公允价值变动进“套期工具”和“套期损益”，现货被套期项目的公允价值变动进“被套期项目”和“套期损益”。到了交换日，系统用虚拟期货把原关系结出一笔管理上的平仓盈亏；会计解释上，就是原套期关系终止或部分终止，并在交换日确认截至该日的套期工具和被套期项目公允价值变动。
如果真实期货没有实际平仓，只是继续被企业持有并转去服务另一张合同，会计上可以把它从旧套期关系明细转到新套期关系明细。审计要求严格时，也可以先从“套期工具-旧关系”转入“衍生工具”，再在新指定文件生效时转入“套期工具-新关系”。这一步是明细重分类，不是因为虚拟期货额外产生一笔损益。损益已经按真实期货的公允价值变动确认。
对现金流量套期来说，交换日前原关系形成的“其他综合收益——套期储备”，仍然跟原来的预期采购或销售走。原预期交易还会发生，就等交易发生时转入存货成本或销售收入；原预期交易不再发生，才转入当期损益。不能因为系统里 B 接了 6 月，就把 A 过去形成的套期储备搬给 B。新关系从交换日重新指定，新的有效套期部分再进入新的“其他综合收益——套期储备”明细。
所以，系统里的虚拟期货解决的是“管理匹配和盈亏归属”的问题；套期会计解决的是“真实期货和被套期项目如何入账”的问题。二者可以对齐，但不能混同。最好的系统记录，是每一笔虚拟期货都能追到一张交叉换仓指令，指令里写清楚：换出合同、换入合同、月份、数量、方向、交换日、交换日结算价、虚拟期货编号、原关系平仓盈亏、新关系起算价、审批人和换仓原因。
一句话：用成对虚拟期货做交叉换仓，既能让旧合同正常结出平仓盈亏，又能让新合同从交换日价格重新起算，还能把“为什么有这笔平仓盈亏”留在系统里。套期会计上，则按旧关系终止或部分终止、新关系重新指定来解释，虚拟期货只做桥，不做真实会计工具。
重点笔记
- 交叉换仓的核心是切开旧盈亏和新起点。
- 成对虚拟期货同价格、同数量、相反方向，只做管理桥梁。
- 会计上看真实期货和套期关系，虚拟期货不能当真实会计工具。
理解要点
交叉期货换仓最容易把人绕晕，因为 A 合同、B 合同、6 月期货、9 月期货、历史移仓盈亏同时出现。先不要看全部细节，只抓一个时间点：交换日。
交换日前的期货盈亏，属于原来的套保关系。A 原来套 6 月，过去的盈亏就留在 A；B 原来套 9 月，过去的盈亏就留在 B。不能因为今天生产计划变化，就把过去已经发生的盈亏搬来搬去。
交换日之后，新的合同要从新的起点重新算。系统用成对虚拟期货做桥，就是为了把旧关系平掉，把新关系从交换日价格接起来。虚拟期货同价格、同数量、相反方向，本身不是为了制造盈亏。
这样处理以后，管理口径就清楚了：旧合同结出截至交换日的平仓盈亏，新合同从交换日虚拟价格开始承担未来涨跌；会计上仍看真实期货和真实套期关系，虚拟期货只做管理桥梁。