專案開發說明與報價 · MVP 第一階段
差旅報帳與
碳盤查整合系統
一份差旅單據，系統擷取一次、人工確認一次，同時產出會計報帳與碳盤查所需的資料。
- MVP 固定總價
- NT$84,000未稅・報價有效 30 日
- 交付時程
- 6 – 8 週需求與環境確認後起算
- 部署位置
- 客戶自有 Server不要求使用 Azure 主機
- 程式缺陷保固
- 驗收後 30 日含原始碼與文件交付
一
專案背景
目前差旅單據通常需要經過兩次整理：會計人員整理報帳所需的日期、金額、幣別及費用類別；ESG 或永續相關人員再整理交通方式、起訖地點、距離及碳排放相關資料。
同一份單據由不同人員重複處理，不但耗費時間，也容易發生欄位不一致、資料漏填，以及報表數字無法回查原始佐證等問題。
本專案預計開發一套簡單的內部 Web 系統，讓員工上傳差旅單據後，透過 OpenAI API 協助擷取資料，再由內部人員確認，最後產出會計及碳盤查所需的資料。第一階段以完成一個可實際使用的流程為主，不規劃成大型 ERP 或 ESG 平台。
二
專案目標
把重複的整理工作收成一次
- 單據欄位由系統自動帶入，人員只需確認少數標記項目
- 減少會計與 ESG 人員重複整理單據的工作
- 使用公司既有的 Teams 組織帳號登入系統
- 透過 OpenAI API 協助辨識 PDF 或圖片中的單據內容
- 對辨識結果提供人工確認與修正機制
讓每個數字都找得到出處
- 保留原始單據、修改紀錄及正式版本，方便日後查核
- 產出會計報帳及碳盤查使用的資料
- 將系統部署在客戶自有 Server
- 由客戶 IT 接手日常維運
三
使用者操作流程
案件從建立到輸出共經過六個狀態。每一個狀態都有明確的負責角色，而且允許往回走——退回補件與解鎖修改都是流程的一部分，不是例外處理。
登入系統
使用者透過公司既有的 Microsoft Teams 組織帳號登入。實際驗證服務使用 Microsoft Entra ID（原稱 Azure AD）。系統本身不需要部署在 Microsoft Azure，只使用組織帳號進行身分驗證。
建立差旅案件
- 出差人員
- 出差日期
- 出差地點
- 出差事由
- 所屬部門
- 其他雙方確認的必要欄位
上傳單據
可上傳 PDF 或圖片格式的交通票據、住宿單據及其他差旅相關佐證。系統會保存原始檔案，不會用辨識後的資料覆蓋原始單據。
OpenAI 單據辨識
- 單據日期
- 供應商或交通業者
- 金額與幣別
- 交通方式
- 起點與終點
- 艙等或車廂等級
- 單程或來回
- 其他雙方確認的欄位
擷取結果會標示信心水準：判讀明確的欄位直接帶入表單，覆核時確認即可；判讀不明確或缺漏的欄位才會被標記出來，交由人員補正。
辨識結果屬於「待確認資料」，不會直接視為正式資料。單據內容會傳送至 OpenAI API 處理；原始檔案與確認後的資料仍保存於客戶提供的環境，實際傳輸與使用方式應配合客戶資安政策確認。
人工確認
覆核畫面會把被標記的少數欄位排在最前面，其餘已帶入的欄位僅供對照，人員不需重新輸入。
- 查看原始單據
- 確認被標記的欄位
- 修正欄位
- 補齊距離、同行人數等碳排必要欄位
- 退回案件
- 通過案件
- 確認並鎖定正式版本
辨識不確定或缺漏的欄位，必須交由人員確認，不會由系統自行猜測後直接寫入正式報表。
鎖單與資料輸出
審核完成後建立鎖單版本，正式輸出只使用已確認及鎖定的資料：
- 會計報帳 Excel
- ESG 或碳盤查底稿
- 原始單據與佐證資料包
實際欄位及檔案格式，需在需求確認階段由客戶提供範本。
三之一
碳排計算所需資料與待確認事項
商務差旅在 ISO 14064-1:2018 屬於類別 3（運輸產生的間接排放），對應 GHG Protocol 的範疇三類別 6。GHG Protocol 認可三種計算方法，並明確要求：只要取得到距離或燃料資料就必須優先使用，取不到時才退回以金額推算。因此「距離」不是選配欄位，而是碳盤查的主要活動數據。
距離的三種取得方式（待需求確認會議決定）
內建起訖點對照表
建立「起訖點 → 距離」對照表（高鐵站對站、常用機場對機場、客運路線）。辨識出起訖站後自動帶入距離，查不到即標為待確認交人工填寫，與既有規則 R-04 一致。
- 不增加對外相依與防火牆開通
- 係數與距離皆可版本控管
- 需客戶提供常用路線清單
串接距離服務
航空以機場經緯度計算大圓距離並套用短、中、長程修正；陸運串接地圖服務取得路線距離。準確度最高。
- 多一個對外相依與 API 費用
- 客戶防火牆需再放行一個網域
- 須納入客戶資安審查
距離由人工填寫
系統僅提供距離欄位與單位，由覆核人員自行查詢填入。開發成本最低，但 ESG 人員的重複整理工作僅解決一半。
- 本次報價的預設做法
- 不影響時程與金額
- 後續可再升級為方式 A 或 B
需一併確認的其他碳排欄位
下列項目會直接改變計算結果，且多半無法只從單據判讀，需在需求確認階段定義清楚由誰、在哪一步填入：
此外建議：鎖單版本必須連同當時使用的距離、排放係數版本與計算方法一起鎖定。否則係數在次年更新後，去年已出具的報表數字會跟著改變，將牴觸本提案第六章 R-08「報表資料必須能回查至原始單據」的要求。此項已納入下方規則 R-09。
距離自動推算（方式 A 的對照表建置或方式 B 的服務串接）不包含在本次 NT$84,000 的報價範圍內，將於需求確認會議後依所選方式另行評估。
四
第一階段開發範圍
本次報價包含以下六個部分，全數為固定總價內的交付項目。
- Microsoft Entra ID 組織帳號登入
- 基本使用者角色及權限
- 使用者可查看的案件範圍控制
- 建立及編輯差旅案件
- 案件列表與查詢
- 案件狀態管理
- 送審、退回、通過及鎖單流程
- PDF 或圖片上傳
- 原始單據保存
- 單據與差旅案件關聯
- 基本檔案下載及查看
- 串接 OpenAI API
- 擷取雙方確認的單據欄位
- 欄位信心水準判定與自動帶入規則
- 低信心與缺漏欄位的標記機制
- 保存辨識結果並提供待確認狀態
- 辨識失敗或異常處理
- 檢視原始單據及辨識欄位
- 人工修正辨識內容
- 退回及重新確認
- 通過及鎖定正式版本
- 保留基本修改紀錄
- 會計報帳 Excel
- ESG 或碳盤查底稿
- 原始單據與佐證資料包
- 輸出欄位依雙方確認範本製作
- 協助一次正式環境部署
- 提供原始碼
- 提供資料庫建置腳本
- 提供部署及基本操作文件
- 安排一次技術移交說明
五
系統設計原則
系統按照不同工作責任分開設計，每一個區域只負責自己的資料及規則，避免所有功能互相綁在一起。最關鍵的一條界線是：辨識建議與正式資料分屬兩側，只有人工覆核能把資料送過去。
六
系統必須遵守的主要規則
以下九條是系統的驗收基準，也可直接作為合約中的功能約定條款引用。
- R-01
使用者只能查看權限範圍內的案件。
- R-02
原始單據不得被辨識結果覆蓋。
- R-03
OpenAI 辨識結果不得直接視為正式資料。
- R-04
不確定或缺漏欄位必須進入人工確認。
- R-05
案件送審後不得任意抽換附件。
- R-06
案件鎖定後，如需修改，必須留下新的版本或修改紀錄。
- R-07
正式報表只使用已確認及鎖定的資料。
- R-08
報表資料必須能回查至原始單據。
- R-09
鎖單版本須一併鎖定計算當下所使用的距離、排放係數版本及計算方法，使已出具的報表在係數更新後仍可重現。
七
部署方式
系統部署於客戶自有的 Server，不要求使用 Azure 主機。資料庫品牌、版本、Server 作業系統及正式部署方式，於專案開始前由客戶 IT 提供及確認。
八
客戶應提供的環境與資料
下列項目是專案能否如期開始與如期完成的前提。建議在簽約前先確認取得管道與負責窗口。
環境與帳號
- Server 或虛擬機
- 作業系統
- 資料庫及連線資訊
- 單據檔案儲存空間
- 網域或內部網址
- SSL 憑證
- 網路及防火牆設定
- Microsoft Entra ID 應用程式設定
- OpenAI API 帳號及金鑰
- 正式環境的必要權限
- 備份及監控機制
規格與樣本
- 20 至 30 份具代表性的差旅單據
- 正常、模糊、多頁及不同格式的測試文件
- 會計報帳 Excel 範本
- ESG 或碳盤查底稿範本
- 使用者角色及權限需求
- 審核及退回規則
- 需要辨識的欄位
- 距離取得方式的決定（方式 A／B／C）
- 常用路線與距離清單（若採方式 A）
- 排放係數及計算方式
- 艙等政策與輻射強迫效應計入與否
- 正式驗收情境
九
維運責任分工
本案為系統開發專案，不包含客戶環境代管及日常維運服務。三方責任界線如下。
交付與保固
- 依雙方確認的規格進行開發
- 執行開發期間的功能測試
- 提供測試版本
- 修正驗收期間發現的程式問題
- 協助一次正式環境部署
- 提供程式碼、建置腳本及相關文件
- 提供驗收後 30 日程式缺陷保固
環境與營運
- Server、作業系統及資料庫管理
- 網路、防火牆、DNS 及 SSL
- 資料庫與檔案備份
- 系統監控及主機資源管理
- 帳號、API 金鑰及憑證管理
- 作業系統及基礎環境安全更新
- 正式環境部署操作
- 日常服務啟停
- 主機、網路及資料庫事故排查
- 備份還原與災難復原
- OpenAI API 額度及帳務管理
規則與資料
- 使用者及角色名單
- 審核流程及欄位定義
- 會計與 ESG 輸出格式
- 排放係數與計算規則
- 業務資料正確性
- 日常操作及內部教育
- 驗收確認
- 後續需求變更決策
十
驗收方式
驗收將以雙方確認的代表性單據及實際操作情境進行。
- 使用者可透過組織帳號登入。
- 使用者可建立差旅案件並上傳單據。
- 系統可建立辨識結果並保留原始檔案。
- 判讀明確的欄位自動帶入，不確定或缺漏欄位標記為待確認。
- 審核人員可修正、退回及通過案件。
- 系統可建立鎖單版本並保留修改紀錄。
- 系統可輸出雙方確認格式的會計及 ESG 資料。
- 正式輸出可回查至原始單據。
辨識品質與人工介入的比重
台灣企業差旅的單據組成，本身就落在辨識條件最好的一類：高鐵票、電子發票、電子機票行程單、旅館住宿明細，全部是印刷體、格式固定、欄位位置穩定的票據。這類單據的欄位可直接帶入表單，覆核人員確認即可；真正需要人工補正的，集中在手寫與影像品質不佳的少數件。
辨識品質如何驗收
本案不以單一準確率百分比作為驗收標準，而是以第 1–2 週的實測結果作為雙方共同基準——因為準確率高度取決於實際送進來的單據影像品質與版式，事前給定一個數字對雙方都沒有保障。下列情況本來就會落入人工補正，屬於系統的正常運作，而非缺陷：
驗收重點在於流程可控：多數欄位自動帶入、少數標記項目能被發現、修正並留下紀錄。
十一
預計時程
專案預計於需求、測試資料及客戶環境確認後，6 至 8 週完成。
第 1 – 2 週
- 確認使用者角色
- 確認案件狀態
- 確認辨識欄位
- 確認單據樣本
- 代表性單據辨識實測與基準確認
- 確認正式輸出格式
- 確認驗收情境
第 3 – 5 週
- 組織帳號登入
- 差旅案件
- 單據上傳
- OpenAI 辨識
- 人工覆核與鎖單
- 報表匯出
第 6 – 8 週
- 客戶測試
- 驗收問題修正
- 正式環境部署
- 程式碼及文件交付
- 技術移交說明
若客戶環境、測試資料、帳號設定或輸出範本尚未就緒，專案時程將配合順延。
十二
專案報價
MVP 開發固定總價
NT$84,000未稅
報價有效期限為 30 日。
建議付款方式
- 40% 簽約
- 40% 測試版交付
- 20% 正式驗收
十三
未包含於報價的費用
以下項目不包含在 NT$84,000 開發費用內。如需上述服務，將依實際內容另行評估及報價。
- OpenAI API 使用費
- Server、虛擬機或主機費用
- 資料庫授權或雲端費用
- SSL 憑證費用
- Microsoft 或其他第三方授權費
- 網域及網路相關費用
- ERP、會計、HR 或既有 ESG 平台串接
- 距離自動推算（對照表建置或地圖服務串接）
- 客戶正式環境代管
- 日常維運及值班服務
- 資料修復或人工資料整理
- 新增功能及原規格以外的修改
- 系統搬遷或基礎環境更換
- 保固期後的問題處理
- OpenAI 模型或第三方服務異動所需的升級工作
十四
保固範圍
正式驗收後提供 30 日程式缺陷保固。
- 已確認規格內的功能無法正常操作
- 程式邏輯與確認規格不符
- 因本次交付程式造成的錯誤
- 客戶主機、網路、資料庫或 SSL 問題
- 客戶修改程式或資料庫造成的問題
- OpenAI、Microsoft 或第三方服務異常
- API 規格或第三方服務政策變更
- 操作錯誤或資料內容錯誤
- 新增需求或原規格變更
- 系統搬遷及環境升級
- 客戶未依建議執行備份所造成的資料損失
十五
本次暫不開發項目
為控制第一階段預算與時程，本次暫不包含下列項目。如第一階段上線後確定有需要，建議拆成後續小型專案逐項增加。
- ERP 或會計系統 API 串接
- HR 或組織主檔自動同步
- 現有 ESG 平台串接
- 複雜碳排儀表板
- 大量歷史資料批次匯入
- 原生 iOS 或 Android App
- 多公司或多租戶架構
- 完整工作流程引擎
- 客戶環境代管及持續維運
十六
專案下一步
建議先安排一場約 2 小時的需求確認會議
會議中確認以下十二項，即可整理正式需求範圍、排定開發時間並進行簽約。
- 代表性差旅單據
- 需要擷取的欄位
- 使用者角色及權限
- 案件狀態與審核流程
- 會計 Excel 格式
- ESG 底稿及佐證包格式
- 距離取得方式（方式 A／B／C）
- 排放係數及計算方式
- 客戶 Server 與資料庫環境
- Microsoft Entra ID 設定
- OpenAI API 帳號
- 辨識實測基準與完成標準