如何使用C#开发定制化Excel转XBRL格式转换程序？

核心实现思路 #

• 优先对齐客户侧的XBRL分类标准（Taxonomy）：首先要把客户对接的监管机构要求的专属分类标准梳理完整，包括元素定义、数据类型约束、上下文（Context）、单位（Unit）的强制填报规则，不要直接套用通用XBRL标准，不同监管主体的扩展规则差异极大，这一步出问题后续基本全是返工。
• 可配置化Excel映射规则：不要把Excel列和XBRL元素的对应关系硬编码到逻辑里，做成可配置的映射表，后续客户调整Excel模板或者报送要求，不需要修改核心转换代码。C#处理Excel可以用EPPlus或者NPOI库，不需要依赖本地安装的Office组件，兼容性更好。
• 分步骤完成转换逻辑：先做Excel数据的前置校验，包括必填项校验、数据类型校验、勾稽关系校验，所有校验通过后再走XBRL生成流程；生成环节先构造上下文、单位节点，再批量写入事实（Fact）值，C#用原生的System.Xml.Linq库就能完成XML结构构造，不需要额外采购商业组件。
• 生成后强制合规校验：XBRL实例文档生成完成后，必须用客户提供的分类标准Schema做合法性校验，确保生成的文件能直接通过监管端的格式校验，避免到报送环节才发现格式错误。

避坑注意事项 #

• 数值精度要提前对齐：金融类报送对小数位数、舍入规则要求非常严格，要提前和客户确认好数值转换的精度规则，避免出现Excel内是1.234，转换后变成1.23或者1.234000这类精度偏差问题。
• 编码规范要符合要求：如果是国内报送场景，一定要确保生成的XML文件是UTF-8无BOM编码，避免监管端解析出现中文乱码。
• 勾稽校验前置：很多XBRL分类标准自带元素间的逻辑校验规则，比如资产=负债+所有者权益这类财务勾稽关系，把这些校验规则放到Excel数据校验环节，不要等生成XBRL后才报错，降低用户排查问题的成本。
• 分类标准做可插拔设计：同一监管机构的XBRL分类标准可能会不定期迭代更新，把分类标准的配置做成可插拔的模块，后续更新标准不需要重构核心转换逻辑。
• 预留差异比对能力：定制场景下客户大概率会有对比两次报送XBRL文件差异的需求，可以提前把这个功能做进去，减少后续需求迭代的工作量。

内容的提问来源于stack exchange，提问作者alok jain