欧博官网：让AI从电费单、采购订单、物流和供应商数据中整理企业Scope 1、2、3碳账本
欧博官网由上海欧博商业责任公司建设，只讨论一件具体的事：企业的电费单、燃气账单、采购订单、物流记录、机票和供应商文件，怎样经过AI读取、分类、企业边界判断、Scope映射和排放因子匹配，变成每一行都能追溯来源的Scope 1、Scope 2、Scope 3碳账本。欧博碳会计把AI碳会计（Carbon Accounting AI）拆成文档读取、数据整理、质量检查和人工复核几段，而不是写成“一键算碳排”。欧博企业AI与欧博大模型负责理解文件、分类活动和发现问题，确定性的计算引擎负责数字，最终进入清单的每一个结果仍然经过人工审核。 欧博App与欧博app下载说明请见欧博App页面，正式客户端发布后提供安装入口。
碳会计不是“拿企业花了多少钱乘一个碳系数”。欧博碳核算把顺序反过来：先判断什么活动发生了、属于哪个公司和哪个时间段、应该进入哪个Scope、使用什么活动数据和方法，然后才是计算。欧博碳数据平台里每一个数字都沿着下面这条链生成。
欧博AI的价值不是“AI直接算碳排”，而是把碳核算里最耗人力的整理工作拆开：Document Reading → Data Extraction → Normalization → Classification → Scope Mapping → Category Mapping → Emission Factor Candidate → Calculation → Anomaly Detection → Missing Data Detection → Evidence Linking → Human Review。前面十步减少人工翻账单、对单位、找因子和查错的时间；最后一步保留碳会计需要的方法、边界和数据质量判断。
采购了100万元钢材，Spend-based方法可以用金额和支出因子估算一个数量级；如果能拿到实际重量100吨和材料相关的排放因子，就应该采用更活动量导向的数据。两种结果都可以进入欧博碳数据，但必须带着不同的Quality Status。不同数据质量层级不能假装一样精确，这是欧博碳会计全站反复出现的原则。
每一行数据在欧博碳数据平台中都带有单位（kWh、m³、L、kg、t、km、kgCO2e、tCO2e）、期间（Bill Period、Reporting Month、Factor Year）、来源（Invoice、ERP、MES、Supplier、Travel System）、质量状态（Actual、Supplier-specific、Calculated、Estimated、Proxy、Missing、Needs Review）和证据（Bill ID、Supplier Report、Ticket）。
Scope划分决定了一张账单最终落在清单的哪个位置。欧博碳会计按GHG Protocol的组织边界思路把排放分成三类，并在2026年9月重新核查了这些规则的修订状态：现行标准仍然有效，Scope 2与Scope 3的修订草案尚未成为正式标准。
企业拥有或控制的排放源产生的直接温室气体排放。常见来源包括Stationary Combustion（锅炉、窑炉烧燃气或煤）、Mobile Combustion（自有车辆烧柴油汽油）、Process Emissions（工艺过程本身释放）和Fugitive Emissions（制冷剂泄漏等）。不同企业的Scope 1构成完全不同，一家化工厂和一家写字楼的Scope 1不能套同一个模板。
企业购买或取得的Electricity、Steam、Heat、Cooling所对应的间接排放。现行GHG Protocol Scope 2 Guidance要求同时按Location-based和Market-based两种方法核算。2025年10月至2026年1月GHG Protocol就Scope 2修订进行了公开征求意见，涉及小时匹配与可交付性等提案，截至2026年9月核查这些内容仍处于修订流程中，尚未替代现行指南。
企业价值链上下游的其他间接排放，GHG Protocol Scope 3 Standard给出15个类别的知识框架。企业需要根据自己的价值链活动和适用的核算框架识别相关类别，并不是所有企业都必须在15类里都填出数字。2026年3月GHG Protocol发布了Scope 3修订的Phase 1进展更新，提出更高的覆盖要求和数据质量披露，但仍是草案材料。
示意链路：燃气费上涨40%不等于Scope 1上涨40%，AI必须先把账单还原成体积、单位、设施和期间。碳会计功能示意，非真实企业碳排数据。
示意链路：账单里如果有kWh就优先识别用电量，人民币金额不能代替活动数据。碳会计功能示意，非真实企业碳排数据。
示意链路：先判断买了什么，再决定用供应商数据、活动量数据还是支出估算。碳会计功能示意，非真实企业碳排数据。
这8篇是欧博官网最重要的内容。每篇解决一个具体的数据问题，各用一种不同的分析结构，避免把碳核算写成“定义、优势、案例、趋势、总结”的模板。首页给出长摘要，完整文章分别放在对应的欧博碳会计、欧博Scope 3、欧博碳数据AI、欧博碳足迹和欧博制造业碳平台页面。
假设财务部转来一份50页的电费账单PDF，里面覆盖一个园区三栋厂房、七块电表和两个结算周期。Document AI跑完以后，所有的kWh都被整齐地摆进了表格，识别置信度看起来也不错。这个时候最容易犯的错误，就是把这些数字加总，乘一个电网排放因子，然后宣布Scope 2核算完成。欧博碳会计不这样做，原因不在于OCR不够准，而在于OCR回答的问题和碳会计要回答的问题根本不是同一个。
OCR和Document AI解决的是“账单里写了什么”。Carbon Accounting还要解决“这些数据应该怎样进入温室气体清单”。沿着Bill-to-Carbon Pipeline往下走，账单读取只是第一站：PDF / Invoice → Document AI → Facility、Period、kWh → Data Quality → Scope 2 Mapping → Method → Emission Factor → Calculation → Review。每一站都会把一部分“看起来能直接用”的数字拦下来。
第一道拦截是Facility和Boundary。七块电表里可能有一块属于出租给第三方的仓库，按运营控制法它不在清单边界内；也可能有一块表计属于集团另一家子公司，只是账单寄到了同一个地址。AI读出的kWh没有错，错的是它被算进了谁的清单。第二道拦截是Billing Period。账单周期跨了两个月，而企业清单按自然月和自然年报告，125,000 kWh需要按天数或按抄表记录拆分到正确的Reporting Period，否则年度清单的首尾两个月会一多一少。第三道拦截是Estimated Reading。很多账单会在某一页角落用一个“E”标记本期读数为估读，下期再补差。如果把估读数和补差数都当作实际用量，同一段电量会被算两次。
过了数据质量这一关，还要选择Scope 2 Method。现行GHG Protocol Scope 2 Guidance要求同时按Location-based和Market-based两种方法报告，市场法需要Energy Contract、绿电采购或合同凭证等信息，这些通常不在电费单上，而在采购合同和能源结算协议里。排放因子同样要选择来源、年份和适用地区，并把选择理由记录下来。最后所有Needs Review的行进入人工复核队列，由能源管理人员确认设施归属、期间拆分和估读处理。
这篇文章之所以放在欧博官网首页第一位，是因为它划定了AI碳会计的边界：AI读取账单只是碳会计自动化的第一步；真正的Scope 2核算还必须知道这些电属于谁、发生在哪个时期、使用什么方法以及对应的数据证据。50页账单里最难的从来不是数字，而是数字背后的归属、期间和方法。
完整文章按Pipeline的九站逐一展开：账单为什么是一类文件而不是一种文件，抽取字段的置信度怎样决定复核范围，设施映射怎样把租户和另一家子公司的表计拦在边界之外，估读与补差怎样避免重复，市场法所需的合同信息应该从哪里补，以及复核人在最后一站到底确认什么。每一站都给出常见的失败原因和对应的检查。
一家工厂把过去24个月的天然气账单全部导入欧博碳数据平台，AI在月度对比里立刻标出一条：7月燃气费比6月上涨40%。如果管理层据此在月报里写“Scope 1排放环比上升40%”，这份月报大概率是错的。燃气费是金额，Scope 1核算需要的是燃烧了多少燃料。两者之间隔着价格、计费周期、阶梯气价、估读补差和设施归属，任何一个环节都能让金额的变化和使用量的变化脱钩。
欧博碳会计在这里用一个很朴素的检查，叫Cost-to-Activity Check：Invoice Amount → Fuel Type → Quantity → Unit → Facility → Combustion Activity → Scope 1 → GHG Calculation。这条链的意思是，账单金额只是入口，AI必须一路把它还原成“哪种燃料、多少数量、什么单位、在哪个设施、哪个期间燃烧”，才能进入Scope 1。走这条链会发现，40%的费用增长背后可能是气价调整了30%而用量只增长了5%；可能是上个月的估读在这个月一次性补足；也可能是新并入的一台锅炉第一次出现在账单里。
单位是这条链上最常出错的地方。同一家燃气公司在不同地区的账单可能用m³、也可能用Nm³或按热值折算的kWh计费；柴油采购单有的按升、有的按吨、有的只有金额。AI需要识别出Fuel Type、Quantity和Unit三者是否匹配，并在Unrecognized Unit时标记Needs Review，而不是默认按某一种单位处理。没有单位的数量在欧博碳数据平台里不允许进入计算。
设施归属同样关键。Scope 1只包括企业拥有或控制的排放源，一张燃气账单可能覆盖厂区里出租给外部食堂的灶具，也可能包含园区物业代收的公共锅炉份额。AI在读取Facility字段后，需要对照企业边界表判断这部分燃料是否应该进入本公司的Scope 1；不在边界内的燃料不是删除，而是标记为Out of Boundary并保留证据。
财务金额在这条链上并非无用。当燃气公司只提供总额、没有用量明细时，金额是唯一的入口，此时可以用当期单价反推数量，但结果必须标记为Estimated，并记录单价来源和假设。这篇文章的结论很直接：碳会计真正需要的是能够代表实际排放活动的Activity Data，财务金额是非常重要的数据入口，但不应该在有更直接活动数据时被误当成活动本身。
完整文章进一步讨论了燃气之外的其他Scope 1排放源：自有车辆的油卡记录同样需要还原成燃料类型和升数，工艺过程排放需要生产台账而不是燃料账单，制冷剂逸散需要加注记录。不同排放源的活动结构不同，把所有Scope 1都写成“燃料燃烧”会漏掉工艺和逸散两类，把所有燃料都按金额估算会让价格波动进入清单。
Scope 3最折磨人的地方不是公式难，而是采购系统里可能有几十万行没人为了碳核算设计过的数据。假设一家制造企业一年有20万条采购订单，品名字段里既有“冷轧钢卷 1.2mm”，也有“A4复印纸”，还有“年度审计服务费”和一串只有供应商自己能看懂的SKU编码。把这20万行乘同一个支出因子，会得到一个看起来很完整的Category 1数字，但它既不能告诉你哪类采购决定了排放大头，也不能告诉你下一年应该向哪几家供应商要数据。
欧博Scope 3处理采购的方式是一个漏斗，叫Procurement Carbon Funnel：Purchase Orders → Classification → Material / Service Category → Materiality → Data Availability → Supplier-specific / Activity / Spend → Calculation → Priority Improvement。漏斗每往下一层，需要精细处理的订单就少一层，而留下来的正是决定Scope 3结构的那部分。
第一层是Classification。AI首先要回答“到底买了什么”，把订单归入Steel、Aluminum、Plastic、Electronics、Office Supplies、Professional Service这样的材料或服务类别。这一步的难点在于品名不规范：同一种钢材在三个工厂的采购系统里有三种写法，AI需要结合供应商、单价、单位和历史订单做归类，并给出置信度，低置信度的行留给采购人员确认。第二层是Materiality。按类别汇总以后，通常少数几个材料类别占据大部分采购排放，办公用品和差旅服务之类的长尾类别数量多、总量小。第三层是Data Availability：对钢材、铝材这类重点类别，订单里有没有重量和数量？供应商有没有提供产品碳数据？答案决定第四层的方法选择。
方法选择不是全局设定，而是逐类别甚至逐供应商决定的。有重量和材料因子的走Activity-based；有供应商产品碳足迹的走Supplier-specific，但要核对边界和年份；只有金额的长尾类别走Spend-based，并明确标记为Estimated。同一张Scope 3清单里三种方法并存是正常的，不正常的是把三种质量的数字涂成同一种颜色。
漏斗最底部是Priority Improvement：今年用支出法估算的重点类别，明年应该换成活动量或供应商数据。这篇文章的结论是：Scope 3自动化最大的价值不是给20万条采购订单逐条算出一个看起来精确的数字，而是先把采购活动正确分类，再把有限的数据治理精力放到真正重要的类别和供应商上。
完整文章按漏斗的八层逐层展开：入口层怎样保留每一行的来源，分类层怎样处理不规范品名和供应商编码，汇总层和重要性层怎样识别决定总量的少数类别，数据可得性层怎样决定方法，方法层为什么允许三种方法并存但必须分开标记，计算层为什么不需要语言模型，以及底部的改进清单怎样决定明年的数据请求发给谁。
报销系统里有一张上海飞深圳的机票，票价2,380元；物流系统里有一张从苏州仓发往成都客户的运费发票，12,600元。AI把两张单据都读完了，金额、日期、供应商一个不差。问题是，这两个金额对计算碳排几乎没有直接用处。机票价格受出行时间、舱位、需求和税费影响，同一条航线在旺季和淡季可能差三倍，但飞行距离一米都没变。运费受油价、时效、议价和淡旺季影响，而排放主要取决于货物走了多远、用了什么运输方式、载了多重。
欧博Scope 3把这个问题叫Expense-to-Activity Reconstruction，也就是把财务记录还原成现实中发生过的运输活动：Expense / Ticket / Shipment → Origin、Destination、Mode、Weight / Passenger → Distance → Activity → Emission Factor → Scope 3。AI在这条链上真正应该优先提取的字段不是金额，而是Origin和Destination。有了起讫点和运输方式，距离可以通过机场对、路网或航线数据得到；有了距离和重量或人数，就能形成吨公里或人公里这样的活动量，再匹配按运输方式区分的排放因子。
Mode是绕不过去的字段。同样是1000公里，卡车、铁路、海运和航空的排放特征完全不同，物流记录里如果只有“运费”和“公里数”而没有运输方式，距离再准也算不出可信的结果。多式联运的单据还需要拆分成若干段，每段各自有Mode和Distance。差旅同样如此：机票需要知道航段和舱位，火车票需要知道车次类型，酒店住宿需要知道晚数和所在地区，租车需要知道里程或油量。
金额并不是被扔掉，而是退到备选位置。当行程单只有一个总额、没有起讫点时，Spend-based方法可以用金额和差旅或运输的支出因子给出估算，作为Fallback进入清单，并标记为Estimated。欧博碳数据平台会记录这条数据是按哪一级方法得到的，明年差旅系统补齐行程字段以后，同一笔数据可以升级为Distance-based。
常见的失败原因都出在还原这一步：起讫点缺失、往返票被当成单程、运输方式未知、货重按发票数量而不是实际重量估计、同一票货在物流系统和财务系统里各导入一次。这篇文章的结论是：运输和差旅碳排自动化的关键，是把财务记录恢复成现实世界里真正发生的运输活动。
完整文章沿着还原链的六步展开：单据类型识别怎样避免行程单和报销单重复，起讫点、方式、重量四个要素缺哪一个就要降级，距离的计算方法怎样记录以便复核，吨公里与人公里怎样处理装载率和舱位，因子怎样按运输方式和航程区分，以及自有车队燃料为什么属于Scope 1而不是Category 4。金额在链条末端作为Fallback出现，永远不是默认。
供应商问卷发出去两个月，回收率一半。收回来的一半里，有的给了产品级碳足迹报告，有的只给了一句“本公司年度碳排放1000吨”，剩下的一半什么都没有。这时候如果有人问AI“能不能把缺的那一半补出来”，欧博企业AI的回答是：可以推荐估算方法，但不能凭语言模型猜一个看起来合理的数字。这两者的区别，决定了一份Scope 3清单能不能被追溯、被审核、被明年的数据替换。
欧博碳数据平台用一个示意性的Carbon Data Quality Ladder来处理这个问题：Supplier-specific → Primary Activity Data → Secondary Activity Data → Proxy → Spend-based Estimate → Missing。它不是任何标准里的固定等级表，不同核算框架对数据质量的分级各有定义，但它足以说明一件事：不同台阶上的数字不能假装一样可靠。供应商给的产品级数据在最上面，前提是它的边界、年份和产品型号经过核对；自己称过重量再乘材料因子在第二、三层；用相似产品或相似工厂顶替的是Proxy；只有金额的落在Spend-based；什么都没有的就是Missing，必须作为缺口显示出来，而不是被悄悄填平。
“本公司年度碳排放1000吨”这种数字尤其需要小心。它可能是供应商整个集团、所有产品、所有工厂的总排放，与企业真正需要的“我采购的那批产品对应多少排放”之间隔着分摊逻辑、边界差异和年份差异。按采购金额占供应商营收的比例去分摊是一种常见的近似，但它是估算，结果必须标记为Estimated，并记录所用比例和假设。
当供应商数据确实缺失时，正确的动作是选择一个预先批准的估算方法，明确标记Estimated，记录Method、Data Source、Assumption和Quality Status，然后交给人工复核。AI在这里做的是推荐方法、执行方法和写下理由，而不是生成数字。这条规则同样约束欧博大模型：模型可以解释为什么某一种估算更合适，但最终数字来自确定性的计算引擎和明确的数据来源。
结论是：缺失数据不可避免，真正专业的碳数据平台不是假装每个数字都一样可靠，而是让使用者随时知道哪些来自实际活动、哪些来自供应商、哪些仍然只是估算。当一半供应商没有数据时，清单里那一半应该清楚地写着Estimated或Missing，这才是明年能改进的起点。
完整文章把示意梯级的六级逐一解释，说明每一级的数据来自哪里、需要核对什么、对应哪个质量状态标签；给出缺失时的六步动作，从确认缺失到建立替换机制；并讨论清单应当汇总各质量级别的占比，因为这份占比表比总数更能说明清单的可靠程度。
年度清单做完了：Scope 1、Scope 2和主要的Scope 3类别都有数，也过了内部复核。客户这时候发来一份供应商问卷，要求提供某个型号产品的Product Carbon Footprint。最省事的做法是把年度总排放除以当年产量，得到一个“每件多少公斤”的数字填进去。这个数字在欧博碳足迹的框架里是不成立的，原因不是算术，而是核算对象和边界完全不同。
欧博碳足迹用一张Corporate-vs-Product Map来解释两者的区别。左边是企业碳足迹：Entity → Scope 1、Scope 2、Scope 3 → Annual Inventory，回答的是“这个组织在这个报告期内、在这个边界里排放了多少”。右边是产品碳足迹：Raw Material → Manufacturing → Transport → Use → End of Life → Product Footprint，回答的是“一件产品在生命周期相关阶段里对应多少排放”。两边共享原材料、能源、供应商和运输数据，但它们不是同一个问题的两种写法。
直接相除会在三个地方出错。第一是多产品。一家工厂同时生产高能耗的铸件和低能耗的组装件，总电费平均分给每一件产品，会让铸件被低估、组装件被高估，客户拿到的数字和真实的产品结构无关。第二是边界。企业清单里包含员工差旅、总部办公用电和资本品采购，这些和某一件产品的生命周期关系很弱；反过来，产品碳足迹里的使用阶段和报废阶段排放，根本不在企业年度清单里。第三是时间。企业清单按报告年，产品碳足迹按产品的生命周期，一件今年出厂的产品，其使用阶段排放发生在未来若干年。
正确的路径是Allocation：把工厂的能源、材料和运输数据按产线、批次或工序分配到产品上，再把供应商提供的原材料PCF按用量接进来，并按所采用的标准确定Cradle-to-Gate还是Cradle-to-Grave边界。产品碳足迹的具体边界取决于使用的标准和研究目的，不能一概而论。截至2026年9月核查，GHG Protocol Product Standard与ISO 14067都是现行标准，两家机构于2026年4月成立联合工作组推进产品级标准协调，新版尚未发布。
结论是：企业碳足迹回答的是组织在一个时期里的温室气体清单，产品碳足迹回答的是一个产品生命周期相关排放；两者的数据可以互相连接，但核算对象和边界不是一回事。
完整文章沿着地图的两列分别展开，说明相除会在多产品、边界和时间三个地方出错，给出从物料清单到分配规则再到运输衔接的正确路径，解释企业清单与产品足迹之间唯一可以严格对账的关系，并讨论两种核算怎样共用同一层活动数据而不互相推导。
月度碳数据汇总跑完，欧博碳数据AI在某个工厂的8月份标了一条红色记录：碳排放比过去12个月的基线高出80%。群里第一反应通常是“肯定是数据错了，先删掉再说”。这是碳数据治理里最糟糕的一种反应。删掉之后，清单看起来平滑了，但如果那80%里有一半是真实的，企业就在自己的清单里抹掉了一次真实的排放增长；如果它完全是数据错误，删掉也不能告诉你错在哪一步，下个月同样的错误还会再来一次。
欧博碳数据平台把异常处理写成一棵Carbon Anomaly Investigation Tree：Anomaly → Business Change? Data Error? Unit Error? Duplicate? Factor Change? Period Change? → Evidence → Review → Keep / Correct / Recalculate。异常只是一个入口，树上的每一个分支都是一种候选原因，AI的任务是把这些候选原因和对应的证据摆出来，而不是替人做决定。
沿着这棵树往下走，80%的增长可能是Real Change：新产线8月投产，产量确实上来了，此时数据应该Keep，并在备注里记录业务原因。可能是Duplicate Invoice：同一张电费单被财务系统和能源系统各导入一次，需要合并，保留一条。可能是Unit Conversion：某块新表的读数以MWh上报，被当作kWh读入，差了一千倍的反方向也会出现，只是不会被“增长”规则抓到。可能是Meter Change：换表以后新旧表读数在同一期间重叠。可能是Reporting Period：账单周期从30天变成45天。也可能是Emission Factor Update：因子库升级到新年份版本，活动量没变，结果变了，这属于Method Change，需要单独说明，而不是混在排放变化里。
每一个分支都对应一种证据：产量报表、原始账单、电表日志、因子版本记录。人工复核的人拿着这些证据做判断，并把判断结果写回数据：Keep、Correct或Recalculate。被修正的数据必须同时保留Original、Corrected、Reason和Reviewer，形成Audit Trail。AI不能自动删除原始数据，也不能在没有复核的情况下把修正值写进清单。
这篇文章想澄清一个误解：异常检测的价值不在于“把奇怪的数字清理掉”。异常不等于错误，一个从不出现异常的碳数据平台更可能是把检查阈值放得太宽，而不是数据真的干净。结论是：异常检测真正的价值不是替企业把奇怪数字清理掉，而是把值得人工调查的数据优先找出来。
完整文章沿着调查树的六个分支逐一展开，说明每个分支对应什么证据、确认后采取Keep、Correct还是Recalculate；解释为什么因子版本变化必须作为方法变化单独记录；讨论一个从不出现异常的平台为什么反而可疑；并给出异常卡片必须包含的信息，让复核有据可依。
制造企业启动碳数据平台项目，第一次评审会上最常见的画面是一张驾驶舱效果图：总排放、分工厂饼图、月度趋势线，绿色主题。三个月后项目卡住，卡的地方通常和图表无关，而是一个很具体的问题：ERP里的物料编码是MAT-001，MES里的投料记录写的是Steel-A，采购系统里供应商的SKU叫ST-01，能源系统里的电表编号跟任何一个工厂车间都对不上。三套系统各说各话，没有人能把“这批钢材、这条产线、这个月的电、这家供应商”连成一条线，碳平台自然算不出任何一件产品的排放。
欧博制造业碳平台把顺序倒过来，写成Manufacturing Carbon Data Architecture：ERP、MES、Meter、Procurement、WMS、Logistics、Supplier → Master Data → Activity Data Layer → Carbon Calculation Layer → Data Quality → Corporate Inventory、Product Footprint → Dashboard / Reporting。驾驶舱在最后一层，主数据在第一层。
Master Data是整个架构的底座。它要为每一个工厂、产线、产品、物料、供应商和计量表建立唯一标识，并维护跨系统的映射关系：MAT-001等于Steel-A等于ST-01。没有这层映射，AI再擅长读账单也只是把数字堆在一起。Activity Data Layer在主数据之上收集带单位、带期间、带来源的活动量：燃料立方米、电力千瓦时、材料吨数、运输吨公里，按站点和期间组织。Carbon Calculation Layer保存方法版本和因子版本，用确定性引擎计算，并定义产品层面的分配规则。Data Quality层负责完整性、准确性、一致性、及时性、可追溯性和方法质量的检查，并把Needs Review的记录送去复核。
常见的失败原因几乎都在底层：物料映射缺失导致材料流断裂；电表与车间的对应关系过期导致Scope 2分配错误；ERP采购数量和MES投料数量不一致却没有人决定以哪个为准；供应商数据的产品型号对不上自己的物料编码；工厂总电费被平均摊给所有产品。这些问题在驾驶舱上都看不出来，图表只会把错误画得很漂亮。
结论是：制造业碳平台真正的底座不是图表，而是一套把工厂、设备、产品、原材料、能源和供应商数据统一到同一个业务对象上的Carbon Data Model。先把主数据和映射做对，企业清单和产品碳足迹才能共用同一套活动数据，驾驶舱才有资格出现在最后一步。
完整文章按架构的七层逐层说明：七类源系统各自持有什么、为什么命名各不相同，主数据层怎样定义映射粒度，活动数据层怎样做到只收集一次多处使用，计算层怎样保存方法与分配规则版本，质量层检查什么，两种输出怎样从同一层数据出发，以及有根的驾驶舱和效果图的区别在点击之后。
以下8个趋势由欧博官网在2026年9月生成本页时重新核查，优先参考GHG Protocol、ISO、ISSB等机构的公开资料，企业软件厂商内容只作为技术方向参考。所有标准状态均区分“现行”与“修订中”。
过去企业碳核算的典型形态是每年一次向各工厂发Excel模板，人工汇总后交给咨询机构计算。2026年越来越多企业把电费、燃料、采购、物流和供应商数据接入结构化的碳数据平台，按月甚至按周更新，每一行都带单位、期间、来源和质量状态。变化的核心不是算得更快，而是数据从“一年整理一次的表格”变成了持续维护的账本。
早期“AI碳管理”常常指用大模型写报告文本。2026年的实际部署重心转向Document Extraction、Classification、Scope Mapping和Data Quality：读账单和采购订单、把品名归入材料类别、判断设施和Scope归属、发现重复和单位错误。这些工作以前占据碳核算团队大部分时间，也是欧博企业AI的主要投入方向。报告文本生成反而是最后、最不关键的一步。
这一转向的直接结果是，AI项目的验收指标从“报告写得像不像”变成了字段抽取置信度、分类准确率的复核抽样和映射覆盖率。Scope 3的难点不在公式，而在数据分散在采购、供应商、物流和差旅系统里。2026年GHG Protocol发布的Scope 3修订Phase 1进展更新提出更高覆盖要求和更明确的数据质量披露方向，虽仍是草案，但已推动企业提前把采购分类、供应商数据收集和物流活动量还原做成常态流程。AI在这里的价值是分类和还原活动，而不是替供应商生成数字。
企业在等待正式标准的同时，已经开始按草案的方向记录各类别的数据质量占比，以便新规发布时不必从头整理。碳核算标准不是静止的：Scope 2指南、Scope 3标准和企业标准都在修订流程中，排放因子数据库每年更新。2026年一个明显的变化是企业碳系统开始像财务系统记录会计准则版本那样，为每条结果记录Method Version、Factor Version和Standard Version。没有版本信息的碳数据，明年重算时无法解释差异来自排放变化还是方法变化。
版本管理也让基准年重算成为可执行的流程，而不是一次性的手工工作。2026年7月29日，GHG Protocol与ISO宣布将把GHG Protocol的Scope 1、Scope 2、Scope 3及市场工具相关标准与ISO 14064-1整合为一部联合署名的企业碳核算标准，计划2027年第二季度开展整合后的公开征求意见，目标2028年底发布。截至2026年9月核查，这一统一标准尚未发布，现行GHG Protocol企业标准和ISO 14064-1仍然有效，不能说“已全面取代旧标准”。
对企业碳系统来说，这意味着方法版本字段在未来两年内必须同时容纳现行标准和整合后标准两套口径。客户对产品碳足迹的要求越来越具体，企业发现PCF和年度清单如果各做一套，材料、能源、供应商和生产数据会被重复收集且互相矛盾。2026年的做法是让两者共享同一层活动数据，通过分配规则分别得到企业清单和产品足迹。GHG Protocol与ISO于2026年4月成立联合工作组推进产品级标准协调，ISO 14067与GHG Protocol Product Standard目前仍是现行依据。
共享底层数据的另一个收益是可以对账：所有产品生产阶段排放之和应与工厂分配前的Scope 1/2一致。月度变化、单位错误、重复账单、极端值、缺失月份、设施不匹配、供应商离群值、因子变化，这些检查开始由AI自动完成。2026年行业共识逐渐清晰：异常检测的输出是“值得调查的清单”和候选原因，不是自动修正后的数据。任何修正必须保留原始值、修正值、原因和复核人，这也是欧博碳数据AI坚持的Audit Trail规则。
异常处理的产出是一份有优先级的调查清单，而不是一份“干净”的数据。披露要求和客户尽调让企业意识到，一个总数如果说不清来源，在鉴证和审核面前几乎没有价值。2026年企业碳系统的建设重点从总量图表转向Data Lineage：每个结果能回溯到源文件、抽取字段、活动量、Scope分类、因子和计算版本，并附Evidence。可审计性正在成为碳数据平台的基本要求，而不是加分项。
这也改变了AI在碳系统里的角色：它的输出必须自带出处和置信度，否则无法进入可审计的链条。三篇短观察，讨论三个在项目里反复出现、却很少被写进方法学的问题：内部数据接全了为什么还缺Scope 3，数据变准了为什么排放反而“上升”，因子匹配自动化以后为什么还要保存理由。
一个常见的项目里程碑是“能源账单接入率100%”：所有工厂的电费单、燃气单、蒸汽结算单都进了系统，Scope 1和Scope 2每月自动更新。团队据此认为碳数据平台已经建成，直到客户或披露要求问到Scope 3，才发现清单里最大的一块几乎是空的。这不是系统故障，而是Internal Data和Value Chain Data的差别被“接入率”这个指标掩盖了。
企业内部的电和燃料容易拿：账单格式固定、供应方少、金额和用量都在同一张纸上。Scope 3的数据分散在采购、供应商、物流、产品和差旅里：采购订单在ERP，供应商碳数据在邮件附件和问卷里，物流活动在承运商系统，差旅在报销平台，产品使用阶段的数据甚至不在企业自己手里。每一种数据的持有方、格式、更新频率和质量都不同，没有任何一个“接入率”能概括它们。
欧博官网在项目复盘里反复看到同一种结构：内部能源数据完整度很高，但对很多制造和贸易企业来说，采购和物流对应的Scope 3类别在总量里占比更大。只盯内部系统接入率，会让企业在一份看起来完整的清单里错过最重要的排放结构。碳数据平台的完整度应当分开度量：内部活动数据覆盖了多少，价值链类别识别了多少，其中多少来自供应商或活动量，多少仍是支出估算。
一个实用的做法是把完整度拆成两张表：内部活动数据按设施乘期间乘类别统计覆盖率，价值链数据按Scope 3类别乘供应商或承运商统计覆盖率与质量状态。两张表并列，才能看出“100%能源账单接入”在整张清单里到底占多大一块。
结论：碳数据完整度不能只看“接了多少内部系统”，价值链数据覆盖往往决定企业是否真正看见完整排放结构。
去年，某个关键供应商没有提供产品碳数据，企业用行业平均因子估算了这部分Category 1排放。今年供应商完成了自己的产品碳足迹核算，给出了Supplier-specific数据，接入后这部分排放比去年高了不少。管理层看到年度对比时的第一反应是“供应链排放恶化了”，随后开始追问采购部门。这个追问方向是错的。
去年的数字是用平均因子估的，今年的数字是供应商实测的。两个数字的差异首先反映的是Method Improvement和Data Quality的变化，而不一定是真实排放的变化。平均因子可能低估了这家供应商的工艺特点，也可能高估；只有当两年都用同一种方法时，差异才能被解释为排放变化。欧博官网把这类情况归为“核算方法变化”，它需要和“排放变化”分开记录。
正确的处理有两步。第一，在数据上把今年的记录标记为Supplier-specific，去年的记录保持Estimated，并在年度对比里明确标出方法差异。第二，考虑Baseline与Recalculation：现行GHG Protocol企业标准要求企业制定基准年重算政策，当方法改进带来显著影响时，按政策重算基准年，让不同年份在同一方法下可比。是否重算、阈值多少，取决于企业自己的政策和适用框架，欧博碳数据平台的职责是把方法版本记录下来，让这个判断有据可依。
在报告里，这种情况应当写成两句话而不是一句：供应链排放数据质量提升，重点供应商由估算改为实测；以同一方法重算后，供应链排放同比变化为多少。第一句解释数字为什么变了，第二句才是真正的经营信息。
结论：企业必须把“排放变化”和“核算方法变化”分开，否则数据质量提升反而可能被误读成经营恶化。
因子匹配是碳核算里最枯燥的工作之一：一条“天然气 21,000 m³ 华东二厂 2026年7月”的活动记录，要在因子库里找到燃料类型、单位、地区和年份都对得上的那一条。AI把这一步自动化以后，匹配速度从每条几分钟变成每条不到一秒。但欧博官网在审核场景里看到的问题是：系统只留下了一个数字，比如0.581（示意），没有留下它是哪个来源、哪一年、适用哪个地区、按什么单位、哪个版本，以及为什么在几个候选里选了它。
排放因子不是永远正确的常数。电网因子按地区和年份变化，燃料因子随热值假设和数据库版本变化，材料因子随边界定义变化。同一条活动记录在不同因子版本下结果不同，如果系统说不出用了哪个版本，明年重算时就无法解释差异，审核时也无法回答“为什么不是另一个”。这是Emission Factor Governance要解决的问题：每个因子至少保存Source、Year、Region、Fuel / Material、Unit、Version和Reason，因子库升级时保留历史版本。
AI在这里的正确角色是生成候选并做检查：列出几个可能匹配的因子，说明各自的来源和适用范围，标出单位是否需要换算、年份是否过期、地区是否对应，然后由人确认或由预设规则自动选择并记录规则编号。把因子选择变成不可解释的黑箱，会让整个清单的可审计性归零。
因子治理的另一半是升级：因子库更新时新增版本而不覆盖，历史计算记录继续指向旧版本；企业按自己的政策决定是否重算历史年份，重算后的结果标记方法变化。这样年度对比可以区分排放变化与因子变化。
结论：排放因子不是一个永远正确的常数，Carbon Accounting AI真正需要自动化的是候选匹配和检查，而不是把因子选择变成不可解释的黑箱。
下面的工作台展示欧博碳数据AI处理一张电费单的分步过程，以及数据进入Carbon Ledger以后的样子。所有内容都是碳会计功能示意，非真实企业碳排数据；因子数值均为示意因子（Demo），不是官方发布的正式因子。
| Activity | Scope | Quantity | Unit | Period | Source | Factor | Status | Evidence |
|---|---|---|---|---|---|---|---|---|
| 电力 · 华东二厂 M-02 | Scope 2 | 125,000 | kWh | 2026-07 | Utility Bill | 示意因子 · 待确认 | Needs Review | BILL-2607-02 |
| 电力 · 华东二厂 M-01 | Scope 2 | 86,400 | kWh | 2026-07 | Utility Bill | 示意因子 v2026 | Actual | BILL-2607-01 |
| 天然气 · 锅炉2 | Scope 1 | 21,000 | m³ | 2026-07 | Gas Bill | 示意因子 v2026 | Actual | GAS-2607-11 |
| 柴油 · 备用发电机 | Scope 1 | 1,800 | L | 2026-07 | Fuel Invoice | 示意因子 v2026 | Estimated | INV-0722 · 单价反推 |
| 冷轧钢卷 · 供应商A | Scope 3 · Cat.1 | 100 | t | 2026-07 | Supplier PCF | 供应商数据 FY2025 | Supplier-specific | PCF-A-2025 |
| 铝制件 · 供应商B | Scope 3 · Cat.1 | 12.5 | t | 2026-07 | Purchase Order | 行业平均 · 示意 | Estimated | PO-88412 · 方法M-03 |
| 塑料外壳 · 供应商C | Scope 3 · Cat.1 | — | — | 2026-07 | 问卷未回收 | — | Missing | 问卷 Q-2026-07 |
| 公路运输 · 苏州→成都 | Scope 3 · Cat.4 | 38,400 | tkm | 2026-07 | Logistics System | 示意因子 · 卡车 | Actual | SHP-2607-207 |
| 员工差旅 · 上海→深圳 | Scope 3 · Cat.6 | 2,460 | pkm | 2026-07 | Expense Report | 示意因子 · 航空 | Estimated | EXP-0715 · 距离估算 |
| 电力 · 出租仓库 | 边界外 | 9,800 | kWh | 2026-07 | Utility Bill | — | Needs Review | BILL-2607-05 · 租户用电 |
每一行都保留单位、期间、来源、因子版本、质量状态和证据。Estimated和Supplier-specific永远使用不同的视觉状态，Missing作为缺口显示，不会被自动填平。碳会计功能示意，非真实企业碳排数据。
任何Correction都保留Original、Corrected、Reason和Reviewer，形成Audit Trail。AI不能自动删除原始数据。
数据来自ERP、MES、电表、采购和供应商。产品碳足迹和企业清单共享同一层活动数据。
Raw Material → Supplier → Purchase → Factory → Machine / Process → Energy → Product → Warehouse → Logistics → Carbon自有车队进入Scope 1，外包运输进入Scope 3；关键字段是运输方式、距离和载重，而不是运费。
Vehicle → Fuel → Route → Distance → Load → Shipment → Emission办公用电、差旅和外购服务是主要结构；食品和消费品还需要原材料与包装的供应商数据。
Office Electricity → Business Travel → Purchased Service → Employee Commuting → Scope Structure以下每一篇都是完整原创文章，正文放在对应栏目页面。摘要不是导语，而是文章的主要判断。
欧博App碳会计指南的四篇文章同时说明欧博app下载的现状：欧博官网不提供安装包或二维码，正式客户端发布后提供安装入口。
一张电费单上至少有三个数字会被当成“碳核算数据”：本期金额、本期用电量和计费周期。进入Scope 2活动数据的只有用电量，金额只在没有用量时作为估算入口，计费周期决定这笔电量属于哪个报告月。文章拆解三个字段各自的陷阱：金额随电价和力调电费波动、用电量可能是估读或含倍率、计费周期跨月需要拆分，并给出欧博碳会计的字段优先级规则。
文章用一张字段表说明实际读数、估读、金额、计费周期和物业分摊比例各自的用途与质量状态，并列出五种常见失败：读错字段、漏乘倍率、估读与补差重复、按账单日期而非计费周期归属、分摊单分错设施。
账单电子化解决的是“能读”，不是“能算”。同一集团在三个地区的燃气账单分别用m³、Nm³和按热值折算的kWh计费，设施名称在账单上是“3号厂房”，在能源台账里是“华东二厂B栋”。不统一单位，AI会把不同基准的体积直接相加；不统一设施编号，燃料会被分到错误的工厂甚至边界之外。文章说明Scope 1自动化的前置条件是单位字典和设施主数据，而不是更强的OCR。
文章还给出Scope 1自动核算的实际顺序：抽取、单位归一、设施映射、期间归属、排放源类型判断、计算、异常检查，并强调单位换算不允许静默发生，换算参数要有来源和期间。
因子自动匹配把几分钟的查表变成不到一秒，但一个只显示“0.581”的界面在审核时什么也证明不了。文章从三个真实场景出发：电网因子跨年未更新、燃料因子单位与账单单位不一致、材料因子边界与采购品不匹配，说明每个因子必须可查看Source、Year、Region、Unit、Version和选择理由，AI负责候选与检查，选择过程必须可解释。
文章同时讨论因子库的版本治理：升级新增版本而不覆盖，每条计算记录因子版本，重算历史年份时标记方法变化，让年度对比能够区分排放变化与因子变化。
采购金额排名第一的往往是设备或服务供应商，而排放最大的可能是一家钢材或化工原料供应商，金额排在十名以外。支出法会把两者的差异抹平。文章用一个示意采购结构说明：AI必须继续识别材料类别、数量和单位，才能把“花钱最多”和“排放最多”区分开，并据此决定向哪些供应商优先索取产品碳数据。
文章还讨论品名归类的实际做法：结合供应商、单价区间、单位和历史订单给出置信度，低置信度的行交采购人员确认并回写规则，让分类质量逐年提高。
供应商发来一份PCF报告并不意味着可以直接乘采购量。报告可能是Cradle-to-Gate也可能包含使用阶段，可能是2024年数据也可能是2025年，可能对应同系列另一个型号或另一家工厂。文章列出接入供应商PCF前必须核对的六项内容：边界、功能单位、年份、型号、工厂和方法依据，并说明核对不通过时应降级为Proxy并标记。
文章还专门讨论供应商只给公司总排放的情况：按采购比例分摊是估算，必须标记Estimated并记录比例，不能因为数字来自供应商就当成产品级数据。
很多差旅系统只留下报销金额、日期和大致目的地。文章按数据可得性分四级说明AI能做到哪一步：有起讫机场和舱位可按距离核算，只有城市对可估算距离并标记Estimated，只有金额只能走支出法，什么都没有则为Missing。结论是差旅系统最值得补的字段不是更细的费用科目，而是起点、终点和出行方式。
文章用一张四级表说明每一级AI能做什么、用什么方法、对应什么状态，并解释票价为什么不能代替距离：同一航线不同时间购票价格可以差三倍，飞行距离一米不变。
OCR把125,000 kWh读得一字不差，但账单上的“3号厂房”被映射到了另一家子公司的工厂，结果两家公司的Scope 2一多一少，集团合并数虽然正确，分公司报告全错。文章说明设施映射是碳数据里最容易被忽略的主数据问题，并给出欧博碳数据AI的做法：映射置信度、地址与表计编号双重校验、映射变更留痕。
文章还解释映射错误为什么难被发现：它不改变总量，只改变归属，月度变化和极端值规则都抓不到，只有按法人做同比或与财务成本中心对账才会暴露。
缺一个月的电费单，最顺手的做法是用前后月平均值补上。文章讨论这种做法在三类情况下的失真：季节性生产、停产检修月、账单周期错位导致的“假缺失”，并说明缺失数据应先判断是真缺失还是期间错位，再按预设方法估算、标记Estimated并记录假设，等真实账单到达后替换。
文章列出六种预设方法及其适用条件：前后期插值、同期历史、产量比例、分表加总、相似设施代理和不估算，并说明AI推荐方法、引擎执行计算、结果必须可替换。
物流账单经常同时出现在财务系统和运输管理系统里，字段格式不同、金额可能含税与不含税，简单的文件哈希查重抓不到。文章介绍欧博碳数据AI的多字段相似度判重：单据号、承运商、起讫点、日期、重量和金额的组合匹配，疑似重复进入Needs Review而不是自动删除，合并后保留两条来源记录。
文章还梳理其他常见的重复形态：总表与分表同时计入、估读与补差同时计入、差旅系统与报销系统各一条、供应商PCF含运输与Category 4重复，每种都有对应的校验方法。
20种产品里有的经过高温工序，有的只需组装，按件数平均分摊电力会让高能耗产品被系统性低估。文章比较按产量、按工时、按工序能耗和按分表计量四种分配方式的适用条件，说明分配规则必须写进产品碳足迹的方法记录，并且与企业清单的Scope 2总量保持一致。
文章建议先把工厂用电拆到工序，再按工序的物理驱动因素分到产品：熔炼按投料重量，热处理按炉次，装配按工时，公用设施单独列出并说明分摊依据。
供应商PCF是“每公斤”还是“每件”，是Cradle-to-Gate还是含运输到厂，直接决定它能不能与自己的物料用量相乘。文章用一个铝制件的示意案例说明单位换算、边界衔接和运输阶段重复计算的风险，并给出接入供应商PCF的核对清单。
核对清单包括功能单位、系统边界、型号、工厂、年份、方法依据和证据文件七项，通过的标记Supplier-specific，不完全匹配的标记Proxy并记录调整，边界重叠的在自己的运输阶段扣除。
接入以后还要按年份维护有效期，超期记录标记待更新。
企业总排放下降可能来自产量下降、产品结构变化或某条产线停产，而某个产品的单位碳足迹可能因为小批量生产、原材料供应商更换或分摊基数缩小而上升。文章说明企业清单和产品足迹的变化方向可以相反，两者需要分别解释，不能用一个总量趋势代替产品级判断。
文章列出产品PCF上升的五种来源：小批量摊薄效应消失、供应商更换、分配基数变化、方法变化和工艺变化，其中方法变化和数据质量变化必须与真实排放变化分开记录。
ERP记录的是买了多少，MES记录的是用了多少，两者之间隔着库存、损耗和退货。文章说明企业清单的Category 1应以采购活动为准，产品碳足迹应以实际投料为准，两者差异本身就是需要解释的数据，而不是错误；碳平台要做的是同时保留两个数量并记录差异原因。
文章用一张示意对账表说明采购到货、实际投料、年末在库和未解释差异各自的来源与用途，并指出这场争论能发生的前提是ERP编码与MES名称已经完成映射。
分表数据精细到车间和小时，但它与电网结算账单之间通常存在线损、表计覆盖不全、计量误差和期间错位。文章说明年度Scope 2清单应与购电账单对账，分表数据用于内部分配和异常检测，两者对不上时差异要被记录而不是被抹平。
文章列出分表之和与账单不等的五个原因：线损、覆盖不全、计量误差、期间错位和表计变更，并给出把账单电量按分表比例分配、差异按规则归入公用设施的对账机制。
工厂总排放是所有产品的加总，它无法告诉管理者哪种产品每吨排放最高、哪条产线的能耗结构最值得改。文章说明只有把能源和材料数据分配到产线和产品，企业才能在产品结构、工艺路线和供应商选择上做出有依据的决定。
文章用高能耗铸造件与低能耗组装件的示意说明：订单结构变化会让总量下降而工艺没有任何改进，也会让真实的工序改造效果被订单增长淹没，只有分到产品和工序才能分辨。
识别“这是一张柴油发票”对大模型来说不难，难的是判断这批柴油是自有车队用的（Scope 1）、外包物流用的（Scope 3）还是租户用的（边界外）。文章说明Scope映射依赖企业边界表、资产清单和合同关系，这些是企业数据而不是模型知识，欧博企业AI必须把它们作为输入。
文章用同一种柴油发票的四种归属说明识别与映射的区别，并解释映射错误为什么比识别错误更难发现：它不改变数量，只改变归属，总量核对抓不到它。
模型训练语料里的因子可能来自旧年份，标准描述可能混杂了征求意见稿和现行版本。文章说明欧博大模型的架构把因子库、现行标准和企业数据作为外部检索源，通过RAG和工具调用获取，模型只负责理解和推理，因子数值和标准版本永远来自可追溯的外部来源。
文章梳理了2026年9月核查的标准状态，说明这些状态每几个月变一次，任何靠记忆回答“现在的标准是什么”的模型都会在某个时点出错，而检索有出处、可以随检索源更新。
语言模型可以生成一个数量级正确的数字，但它无法说明这个数字的方法、来源和假设，也无法在明年被替换。文章说明欧博模型在缺失场景下的输出是方法推荐、参数建议和理由说明，数字由计算引擎按批准的方法生成并标记Estimated。
文章列出估算必须回答的四个问题：用了什么方法、数据从哪来、做了什么假设、质量状态是什么，并说明方法比数字重要的三个理由：可复现、可替换、可比较。
在欧博App里用手机拍一张电费单，几秒钟后屏幕上出现“125000 kWh”，很多人会以为这一步就完成了碳核算。文章按App的实际流程说明识别之后还要发生什么：确认这张单属于哪个设施和哪个报告期、检查是否估读或重复、判断是否在企业边界内、映射到Scope 2、选择核算方法、匹配带来源和年份的排放因子、由计算引擎生成结果、再进入复核队列。App把每一步的状态都显示出来，识别成功只是Actual状态的开始，而不是Calculated或Reviewed。文章还说明移动端为什么要保留原始照片作为Evidence，以及“本期金额”为什么在App里被灰显而不参与计算。
文章逐步走完识别之后的七步：设施主数据匹配决定归属，计费周期决定报告期，估读标记决定是否复核，边界表决定Scope，现行指南决定位置法与市场法，因子库决定因子及其版本，引擎计算后进入复核队列。每一步在App上都是一个可见的状态，识别成功只是Actual，Reviewed才是终点。
Carbon Overview页面上Scope 3占了六成以上，这是很多制造和贸易企业的常见结构。文章讨论管理者面对这个饼图时应该追问的问题：这六成里有多少来自供应商实测数据，多少来自活动量计算，多少只是支出法估算，多少还是缺口。欧博App在总量旁边并列显示Data Quality构成，就是为了让“占比最高”和“最不确定”这两个事实同时出现。文章的结论是：当一个Scope的估算比例很高时，最有价值的管理动作不是设减排目标，而是先决定向哪些供应商要数据、先补哪些字段，把估算换成实测。
文章用一张示意的Scope 3质量构成表说明各类别里Supplier-specific、Calculated、Estimated和Missing的占比，解释三层下钻的界面设计，并说明为什么在估算值上设目标有两个风险：方向可能错，明年数据变准后分不清是减排了还是算准了。
一个只有“异常 +80%”的红色卡片，对拿着手机的工厂经理来说几乎没有可操作性：不知道是哪张账单、哪块表、哪个期间，也不知道系统怀疑什么。文章说明欧博App异常卡片的四个必要元素：触发规则和基线、候选原因列表、原始账单图像或系统记录的直接入口、以及复核动作按钮。移动端屏幕小，更需要把证据和原因放在第一屏，而不是让人回到电脑前重新查找。文章同时说明App上的复核动作只能是Keep、Correct或Recalculate，没有Delete。
文章用一张示意的异常卡片展示触发规则、三条AI找到的线索（新增产线、疑似重复账单、因子版本更新）、证据入口和复核动作，并描述工厂经理在车间里用手机完成合并重复记录、确认真实增长、触发重算的全过程，说明为什么证据必须在第一屏。
供应商列表里A和B并排显示各自的碳数据，如果两条记录颜色、字号和图标完全一样，管理者会自然地把它们当成同等可靠的数字去比较。文章说明欧博App用不同的颜色、标签和说明文字区分Supplier-specific、Estimated、Proxy和Missing，并在Estimated记录旁显示估算方法和假设。这不是视觉装饰，而是数据质量信息本身：一份供应商排名如果混合了实测和估算却不加区分，会直接误导采购决策。文章最后讨论了状态升级的路径，即Estimated记录在供应商提交数据并通过核对后如何变为Supplier-specific，以及历史版本如何保留。
文章还讨论混合排名的危害：提供实测数据的供应商可能因为数字偏高被排到后面，不提供数据、用行业平均估算的供应商反而排到前面，等于惩罚配合数据工作的一方。欧博App的排名默认按状态分组，跨组比较时提示可靠程度不同，Verified只在第三方核查完成后出现。
关于欧博、AI碳会计、Scope 1/2/3、供应链碳排、产品碳足迹、制造业碳数据平台、欧博大模型和欧博App下载的常见问题。
欧博官网是上海欧博商业责任公司建设的企业碳会计科技网站，域名为oubeofficial.com.cn。网站围绕AI碳会计、Carbon Accounting AI、Scope 1/2/3企业碳核算、AI读取电费燃气采购物流差旅和供应商数据、碳数据质量、产品碳足迹、制造业碳数据平台和欧博App提供原创内容，不是碳交易平台，也不是环保新闻站。
欧博碳会计是欧博对企业温室气体核算方法与AI自动化的整体称呼。它把碳核算拆成业务活动、源文件、数据抽取、实体、期间、边界、活动类别、Scope、活动数据、排放因子、计算、质量检查、证据、复核和清单十五步，强调AI减少整理和查错工作，而方法、边界和人工审核保留在流程里。
AI碳会计指用AI处理企业碳核算中的文档读取、数据抽取、单位归一、活动分类、Scope映射、排放因子候选匹配、异常检测、缺失检测和证据关联，从而减少人工翻账单、对单位、查因子和追数据的时间。它不是“输入公司名一键算碳排”，关键碳清单数字由确定性计算引擎生成，最终仍需人工复核。
Carbon Accounting AI是AI碳会计的英文表述，指服务于温室气体会计的AI能力集合，包括Document AI、Classification、Carbon Mapping、Emission Factor Matching、Anomaly Detection和Missing Data Detection。与普通OCR的区别在于，它输出的不只是字段，还有字段所属的实体、期间、边界、Scope和质量状态，并保留Data Lineage。
它的边界同样明确：关键清单数字由确定性计算引擎生成，模型负责理解、分类、检索和解释，最终结果经过人工审核。
Scope 1是企业拥有或控制的排放源产生的直接温室气体排放，常见来源包括固定燃烧（锅炉、窑炉）、移动燃烧（自有车辆）、工艺过程排放和逸散排放（制冷剂泄漏等）。不同企业的Scope 1构成差别很大，核算时需要识别燃料类型、数量、单位、设施或车辆和期间，而不是只看燃料费用金额。
Scope 2是企业购买或取得的电力、蒸汽、热力和冷量所对应的间接排放。现行GHG Protocol Scope 2 Guidance要求同时按Location-based和Market-based方法核算。核算时优先使用账单上的用电量（kWh）而不是电费金额，并需要确认设施归属、计费周期和是否估读。2026年Scope 2指南的修订仍在进行中，尚未替代现行版本。
Scope 3是企业价值链上下游的其他间接排放，GHG Protocol Scope 3 Standard给出15个类别的框架，包括外购商品和服务、资本品、运输、废弃物、差旅、通勤、租赁资产、售出产品的加工使用和报废、特许经营和投资等。企业根据自身价值链识别相关类别，并不是所有企业都必须在15类里都得出数字。
AI先识别文件类型，再抽取设施、表计、计费周期、用电量和单位，检查是否估读、重复或缺月，然后对照企业边界判断归属并映射到Scope 2，选择核算方法，匹配带来源、年份和地区的排放因子，由计算引擎得出结果，并把Needs Review的记录送入人工复核。读取账单只是第一步，不是核算的全部。
AI先把采购订单、物流单、机票和供应商文件分类到对应的Scope 3类别，识别材料、数量、单位、运输方式、起讫点等活动信息，评估各类别的重要性和数据可得性，再按供应商特定、活动量或支出法逐类别选择方法计算。缺失数据按预设方法估算并标记Estimated，AI不能凭空生成Scope 3数字。
难点不在公式，而在数据：采购记录不是为碳核算设计的，品名不规范；供应商数据回收率低、边界年份不一；物流记录常常只有运费没有运输方式和重量；差旅系统只有金额没有行程。每一类数据都需要先分类、还原活动、核对边界，才能进入计算，而且不同质量的数据必须分开标记。
企业碳足迹回答一个组织在报告期内、在其边界里的Scope 1/2/3排放清单；产品碳足迹回答一件产品在生命周期相关阶段的排放，涉及原材料、生产、运输、使用和报废，具体边界取决于所用标准。两者共享材料、能源和供应商数据，但不能用企业总排放除以产量得到产品碳足迹。
顺序是Master Data → Data Integration → Activity Mapping → Carbon Method → Calculation → Quality → Dashboard。先为工厂、产线、产品、物料、供应商和电表建立唯一标识和跨系统映射，再接入ERP、MES、电表、采购、仓储、物流和供应商数据形成活动数据层，然后定义方法和因子版本进行计算与质量检查，驾驶舱放在最后。
顺序不能倒：没有主数据映射，ERP的物料编码、MES的物料名称和供应商SKU无法连成一条材料流，任何图表都是无根的。
欧博大模型负责理解文件、分类采购、解释异常、检索标准和因子候选、生成复核建议，它连接碳知识、现行标准、企业数据、排放因子库和计算工具，而不是靠模型记忆直接算碳排。关键清单数字由确定性计算引擎生成，模型的输出可解释、可追溯，最终仍经过人工审核。
欧博App规划支持Android、iOS和H5三种形态，功能包括Carbon Overview、Bill Scanner、Scope 1/2/3、Supplier Carbon、Data Quality和欧博AI助手。目前欧博官网不提供安装包、应用商店链接或二维码，正式客户端发布后将在欧博App页面提供安装入口，请以欧博官网oubeofficial.com.cn公布的信息为准。
欧博app下载、欧博Android、欧博iOS与欧博H5的说明均以欧博App页面为准。
任何第三方网站或群聊里出现的“欧博下载”链接都不是欧博发布的，请勿安装。
欧博企业AI是面向企业碳核算场景的AI能力体系，涵盖Document AI、RAG检索现行标准与因子、Scope映射、异常分析、缺失数据方法推荐和Carbon Agent工作流。它的架构是基础模型连接碳知识、现行标准、企业数据、因子库、工具和计算引擎，输出经过数据质量检查并保留人工复核。
平台不承诺每个数字同样可靠，而是让每一行数据都带单位、期间、来源、质量状态和证据。Actual、Supplier-specific、Calculated、Estimated、Proxy、Missing和Needs Review使用不同的状态，任何修正保留原始值和原因。欧博官网上的示例均为功能示意，不是真实企业碳排数据。
AI不能自动删除原始数据，Needs Review的记录必须经人工复核后才能进入清单。
按照温室气体核算标准，把企业活动转化为可追溯排放清单的方法体系，包括边界、期间、活动数据、因子、计算、质量和证据。
以企业或组织为对象，在报告期内按Scope 1/2/3统计温室气体排放并形成清单的过程，是欧博碳核算的基本对象。
企业在报告期内、组织边界内的温室气体排放总清单，通常按Scope 1、Scope 2和相关Scope 3类别分列。
一件产品在生命周期相关阶段（原材料、生产、运输、使用、报废）的温室气体排放，边界取决于所采用的标准与研究目的。
持续收集、整理、计算和追溯企业碳数据的系统，每行数据带单位、期间、来源、质量状态和证据，不只是几张图表。
把活动量换算为温室气体排放的系数，如每kWh电力或每m³燃气的kgCO2e，必须带来源、年份、地区、单位和版本。
代表实际排放活动的量化数据，如用电量kWh、燃气m³、材料吨数、运输吨公里，与财务支出金额不同。
欧博对经AI读取、分类、映射和质量检查后形成的企业碳数据的称呼，核心是每行数据可追溯到源文件。
欧博在碳会计场景中使用的AI能力总称，包含欧博大模型、欧博模型和欧博企业AI的文档理解、分类、检索与异常分析。
欧博企业AI中面向碳核算任务的模型组件，负责理解、分类、检索和推荐方法，不直接替代计算引擎生成清单数字。
由WRI与WBCSD发起的温室气体核算标准体系，其企业标准、Scope 2指南和Scope 3标准是欧博碳会计内容的主要参考框架。
从源文件、抽取字段、归一化活动、Scope分类、因子、计算到结果和报告的完整追溯链，是碳数据可审计的基础。
对边界、Scope映射、排放因子、估算数据、重要供应商数据和重大异常进行的人工检查与确认，是欧博碳会计流程的固定环节。
欧博规划中的移动端碳会计助手，包含账单识别、Scope 1/2/3、供应商碳数据、数据质量、异常复核和欧博AI助手八项功能。
先建立企业边界和设施主数据，再接入账单、订单和系统数据，让AI抽取、分类、映射和检查，最后由人复核Needs Review的记录。
识别燃料类型、数量、单位（m³/Nm³/kWh热值）、设施和期间，核对单位字典与设施编号后进入Scope 1固定燃烧活动。
抽取供应商、品名、材料、数量、单位、金额和交付地点，先分类“买了什么”，再判断适用供应商特定、活动量、混合或支出法。
把燃料账单和加油记录还原为燃料类型与数量，确认设施或车辆在边界内，匹配燃料因子，由计算引擎得出直接排放。
以账单kWh为活动数据，按设施和报告期归属，分别按Location-based和Market-based方法匹配因子并计算，估读和跨期需处理。
优先使用经边界、年份和型号核对的供应商产品碳数据；无数据时用活动量或支出法估算并标记Estimated，记录方法与假设。
从运单还原起讫点、运输方式、距离和重量，形成吨公里活动量，按运输方式匹配因子；只有运费时走支出法并标记。
从机票和差旅记录提取起点、终点、方式和舱位，计算距离和人公里；只有金额时用支出法作为Fallback并标记Estimated。
先做主数据和跨系统映射，再接ERP、MES、电表、采购、仓储、物流和供应商数据，定义方法与因子版本，最后才做驾驶舱。
用Bill Scanner拍账单进入识别流程，在Carbon Overview查看Scope构成和Data Quality，在复核队列处理异常与估算记录。
覆盖Scope 1/2核算方法、账单读取、单位与设施统一、排放因子治理，以及三篇原创方法文章和两篇首页核心文章的完整版。
上海欧博商业责任公司围绕AI碳会计、Carbon Accounting AI、企业温室气体数据、Scope 1/2/3、供应链碳数据、产品碳足迹和制造业Carbon Data Platform建设欧博官网。欧博关注的不是“输入公司名就算出碳排”这类工具，而是企业在真实经营里遇到的碳数据问题：财务部转来的电费单该怎样进入Scope 2，燃气费上涨为什么不等于Scope 1上涨，几十万条采购订单该怎样分类，供应商数据缺失时估算应该怎样标记，工厂总排放为什么不能平均摊给每件产品，以及制造企业的ERP、MES、电表和供应商数据怎样对上。
欧博碳会计是这些内容的方法框架，欧博企业AI、欧博大模型和欧博模型是把文档读取、分类、映射、因子候选、异常检测和缺失检测自动化的技术路径，欧博App是把账单识别、Scope 1/2/3、供应商碳数据、数据质量和复核任务放到移动端的产品规划。 欧博app下载入口将在正式客户端发布后由欧博官网提供。三者共同遵守同一条原则：AI减少整理、分类、映射、查错和追踪数据的人工工作，而碳会计需要的方法、边界、数据质量和人工审核保留在流程之内。
欧博官网上的所有示例数据、排放因子和界面均为碳会计功能示意，不是真实企业碳排数据，也不构成对任何企业的核算结论。欧博与文中提到的标准机构、监管机构、软件厂商、因子数据库和AI企业不存在隶属、授权或合作关系。