开曼国别报告（CbCR）XML 申报与更正规则解析

对于需要通过开曼 DITC 门户处理国别报告（Country-by-Country Reporting, CbCR）的跨国企业集团（MNE Group），XML 文件范围、门户状态和更正字段之间存在明确的技术关系。理解这些关系，有助于避免把文件上传、系统校验和后续更正混为同一环节。

本文依据《DITC Portal – User Guide》v.9.6（11/25），重点说明每个 XML 可包含的集团和申报实体范围、Pending／Submitted／Submission failed 状态，以及截止日后采用 CBC402 和 DocTypeIndic 处理更正或删除的路径。

核心结论：每个 CbCR XML 只能包含一个 MNE Group 和一个 Reporting Entity，且每个 CbC report 对应一个税务管辖区。截止日后进行更正或删除时，MessageTypeIndic 应为 CBC402；被更正或删除的元素使用新的唯一 DocRefId，其 CorrDocRefId 指向该记录最近一次提交所使用的 DocRefId。

一、CbCR XML 申报的基础与单一实体原则

在 DITC 门户中，CbCR 申报主要通过上传 XML 文件来完成。与 CRS 或 FATCA 申报不同，CbCR 的数据结构更为复杂，涵盖了跨国企业集团在全球各税收管辖区的收入、利润、税收及业务活动分布情况。

1. 单一实体原则的严格适用

根据 DITC 指南，每个 XML 文件只能包含一个 MNE Group 和一个 Reporting Entity，同时每个 CbC report 必须对应单一税务管辖区1, p. 112。因此，如确有多个 Reporting Entity 需要分别申报，不应把它们合并到同一 XML；具体哪些实体承担报告义务，应另行依据适用规则判断。

在准备 XML 时，应把门户中的 MNE Group、Reporting Entity 和报告年度与源数据进行交叉核对。门户验证期间显示 Pending；无验证错误时显示 Submitted；包含无效数据时显示 Submission failed，用户需查看错误通知、修正并重新提交。指南在本章节没有使用 Rejected 作为该上传流程的状态标签。

2. XML 文件的结构与校验

CbCR XML 文件通常包含三个主要部分：

• MessageSpec：包含消息的元数据，如发送方、接收方、消息类型和时间戳。
• ReportingEntity：定义提交报告的实体信息。
• CbCReports：包含具体的国别报告数据，分为表一（按税收管辖区划分的收入、税收和业务活动分配概览）、表二（跨国企业集团所有组成实体的名单）和表三（附加信息）。

上传后，门户会验证文件中的数据。验证可能需要数分钟，也可能因文件大小和门户流量而延长；期间状态为 Pending。无验证错误时状态为 Submitted，无效数据则显示 Submission failed1, pp. 112–113。

二、CbCR 申报状态监控与异常处理

上传 CbCR XML 文件后，持续监控申报状态有助于减少遗漏后续任务的风险。笛杨咨询建议企业建立专门的状态监控台账，及时查看并处理异常情况。

应按照具体任务解释状态。对本指南所述 CbCR XML 上传而言，技术验证通过后的标签是 Submitted；Processed 在相邻说明中用于 CE 或 MNE Group details 的变更成功通知。内部台账宜同时记录任务类型、状态、时间和门户反馈。

三、使用更正代码进行数据更正与删除

更正路径取决于是否已过申报截止日。截止日前，Submitted 的 CbCR XML 可通过 Delete/Edit 退回为 Incomplete，随后上传其他 XML 或删除该申报；截止日后不能再直接编辑或删除，需提交包含更正或删除的新 XML。

1. 更正代码的分类与应用

CBC401 与 CBC402 是 MessageTypeIndic，不是 DocTypeIndic：

• CBC401：消息包含新信息；
• CBC402：消息包含对先前发送信息的更正或删除。

DocTypeIndic 则使用 OECD 代码：OECD0 表示重发数据，OECD1 表示新数据，OECD2 表示更正数据，OECD3 表示删除数据。指南不存在本文初稿所称的 CBC403。截止日后提交更正或删除消息时，MessageTypeIndic 应设置为 CBC402。

2. 准确引用原申报记录

每个被更正或删除的 CbC report 或 Reporting Entity 元素都要分配一个新的唯一 DocRefId。CorrDocRefId 用于指向被更正或删除记录最近一次提交所使用的 DocRefId；连续更正时，应引用最新版本，而不是始终引用最初版本。

如果 CorrDocRefId 没有指向正确的最新记录，系统将无法按指南预期建立更正链。更正数据使用 OECD2，删除数据使用 OECD3；两者可以出现在同一更正 XML 中，但该 XML 不能同时包含 OECD1 新数据1, pp. 114–116。

3. 截止日前后的更正路径差异

DITC 门户对申报截止日前后的操作路径作了明确区分：

• 截止日前：对状态为 Submitted 的申报点击 Delete/Edit，系统将其退回 Incomplete；随后可以上传不同的 XML，或从 Reporting 页面删除该申报。
• 截止日后：不能再编辑或删除已提交申报。如需变更，或 DITC 要求更正，应上传新的 XML，设置 MessageTypeIndic = CBC402，并用 OECD2／OECD3 及正确的引用链表达更正或删除。

四、企业内部 CbCR 申报治理建议

面对复杂的 CbCR XML 申报与更正规则，跨国企业集团需要建立稳健的内部治理机制，以降低操作风险和合规成本。笛杨咨询基于门户操作风险，提出以下内部管理建议：

1. 建立前置依赖清单：在生成 XML 前，核对 MNE Group、Reporting Entity、报告年度、CE 文件以及实际负责上传的 Primary Contact 或 Additional User。实体是否承担报告义务和税务居民身份属于另行判断事项。
2. 实施严格的文件版本控制：由于更正操作高度依赖 DocRefId，企业必须妥善保存历次提交的 XML 源文件及门户返回的回执，建立清晰的文件命名与版本规则，确保在需要更正时能够迅速找到正确的参考编号。
3. 制定提交前复核清单：在上传 XML 文件前，由独立于编制人员的复核者对文件进行技术和业务双重校验，重点检查单一实体原则的遵循情况及关键数据字段的准确性。

五、常见问题

Q1：我们可以把开曼多个实体的 CbCR 数据合并在一个 XML 文件中提交吗？
每个 XML 只能包含一个 MNE Group 和一个 Reporting Entity。如果确有多个 Reporting Entity 分别承担申报任务，应分别准备 XML；同时，每个 CbC report 只能对应一个税务管辖区。

Q2：如果我们在 XML 文件中填错了金额，可以直接重新上传一份正确的文件吗？
先判断是否已过截止日。截止日前，可将 Submitted 申报通过 Delete/Edit 退回 Incomplete，再上传其他 XML 或删除；截止日后，应提交新的更正 XML，设置 MessageTypeIndic = CBC402，对更正元素使用 OECD2，并让 CorrDocRefId 指向最近一次相关记录的 DocRefId。

Q3：门户显示 Processed，是否意味着 CbCR XML 已经提交？
不应只看状态词。指南在 CbCR 上传章节中以 Submitted 表示 XML 无门户验证错误；Processed 用于 CE 或 MNE Group details 变更成功通知。应先确认当前记录的 Reporting Type，再解释状态并保存对应回执。

Q4：CbCR 门户中的第一联系人和第二联系人，与 CRS 申报中的 AP 和 PPoC 是一回事吗？
不是。CbCR 框架使用的是第一联系人（Primary Contact）、第二联系人（Secondary Contact）和附加用户（Additional User）；而 CRS/FATCA 框架使用的是授权人（AP）、主要联系人（PPoC）和次级用户。不同框架的角色权限和指派逻辑不同，不能混用。

笛杨咨询提示

本文基于 DITC Portal User Guide v.9.6（11/25）整理，聚焦门户技术操作，不构成法律、税务或监管意见；实际适用义务和时间要求应以 DITC 最新正式资料及实体具体情况为准。CbCR 申报涉及复杂的集团数据归集与技术转换，任何 XML 格式错误或更正代码误用都可能导致申报失败。笛杨咨询可协助企业梳理 DITC 门户权限台账、设计标准化的 CbCR 数据归集与 XML 生成流程、建立文件复核与版本控制机制，并协调跨国合规项目，支持合规团队完成内部复核。