碳費看排放總量，CBAM 看出口貨品的內含碳排，永續報告看 GRI 揭露項目。三種口徑，同一份底稿。
依 ISO 14064-1:2018 建立盤查邊界，GWP 採 IPCC AR6，Scope 2 同時給位置基準與市場基準。
國內碳費試算與繳納追蹤，歐盟碳邊境調整機制申報所需的內含碳排一起算完，不必兩套系統。
Scope 3 最難的是拿到上游數字。系統發出填報邀請、追蹤回覆狀態，不必用試算表來回寄信。
整套以容器部署在你的機房，排放數據與供應商資料不必交給第三方雲端平台。
盤查標準、GWP 基準、組織邊界與各範疇排放量列在同一頁，位置基準與市場基準並陳。
依 ISO 14064-1 建立盤查清冊，範疇一、二、三分別計算，內建排放係數庫可自行維護。
ISO 14064-1依環境部碳費制度試算應繳金額，追蹤申報期程與繳納狀態，減量額度一併納入計算。
環境部制度出口貨品的內含碳排計算與申報資料整理，符合碳邊境調整機制要求的格式。
出口必備發出填報邀請、追蹤每一家的回覆狀態，Scope 3 的上游數字不必靠人工催收。
Scope 3 關鍵碳信用額度的取得、持有與抵換記錄，可用量與已使用量隨時查得到。
額度追蹤依 GRI 準則整理揭露項目，逐項標示完成度，報告草稿直接從系統資料產生。
GRI 準則內建法規目錄含教育機構專區，可直接就法規內容提問，回答標明依據的條文出處。
附出處獨立的全螢幕戰情室，資料即時取自系統資料庫。排放趨勢與預測、範疇占比、GRI 完成度、供應商填報與報告任務狀態同時在畫面上，適合放在會議室或大廳輪播。
系統依照下列標準與制度實作，每一份盤查都記錄採用的版本與基準，日後查核可回溯。
Scope 2 依規定同時提供位置基準與市場基準兩組數字，避免因電力來源認定不同而需要重算。
CBAM 申報要提出貨品內含碳排，沒有系統性的盤查資料就交不出來。
碳費依排放量計算，盤查數字直接連動應繳金額，算錯就是真金白銀。
大廠向上游要 Scope 3 資料，回覆得快又有依據，是接單的條件之一。
依 GRI 準則揭露，資料散在各部門的試算表裡，每年重做一次很痛苦。
教育機構有自己的盤查邊界與法規要求，系統內建教育機構法規專區。
戰情室大屏放在會議室或大廳，訪客與稽核單位一眼看完全年進度。
微服務架構，認證、系統管理、ESG 與 CBAM 各自獨立，可依實際用量單獨擴充。
Vue 3 與 TypeScript，介面元件統一，支援多組織切換與角色分權。
Spring Cloud Gateway 統一認證過濾、路由轉發與流量限制。
Java 17 與 Spring Boot 3，認證、系統、ESG、CBAM 四組服務各自獨立。
MySQL 存業務資料，Redis 快取，MinIO 存放佐證文件與報告檔案。
可以。系統會帶著建立盤查邊界、選定標準版本與 GWP 基準，再逐項登錄排放源。排放係數庫已內建，也可以維護自己的係數。第一年建好之後，往後每年是複製上一年的架構再更新數字，不必重來。
系統發出填報邀請給供應商，對方在自己的介面填報，你這邊看得到每一家的狀態是已發送、已開啟、填報中、已提交還是已過期。不必用試算表來回寄信，也不會有版本錯亂。
不用。兩者的基礎都是同一份盤查資料，系統各自依照制度要求的口徑產生數字。台灣碳費看的是排放總量與適用費率，CBAM 看的是出口貨品的內含碳排，來源相同但輸出不同。
可以。整套以容器方式部署，可以放在自己的機房，也可以放在指定的雲端環境。排放數據、佐證文件與供應商資料都存在你自己的資料庫與檔案儲存體。
系統依 GRI 準則整理揭露項目並產生報告草稿，內容來自系統裡已登錄的資料。最終的敘事、設計排版與董事會核可仍需由貴單位完成，系統負責把數字與揭露項目備齊，不必再從各部門的檔案裡東拼西湊。
