簽一份軟體開發合約，多數企業主最先看的是總價與交期，卻常常忽略智財歸屬、原始碼交付、驗收標準與維護條款這些細節——而這些條款往往要等到專案卡關或雙方產生糾紛時，代價才會真正顯現。本文整理 2026 年台灣客製化軟體開發合約中最關鍵的 15 項條款，逐項說明為什麼重要、建議怎麼寫，並附上付款里程碑範例，幫助您在簽約前先把功課做好。
提醒：本文為一般性資訊整理，非法律意見；簽約前請務必請律師審閱合約內容。
軟體開發合約 15 項條款檢核表
不同專案規模與產業別的合約內容會有差異，但以下 15 項條款，是多數客製化軟體開發合約都應該涵蓋的基本盤。建議收到合約草稿後，逐條對照確認廠商是否已經寫清楚，而不是只看合約最後一頁的總價。
| # | 條款 | 為什麼重要 | 建議寫法 |
|---|---|---|---|
| 1 | 智慧財產權／著作權歸屬 | 未約定時，程式碼著作財產權可能仍歸開發商所有，委託方只拿到使用權 | 明訂「本專案開發之程式碼、文件、UI 設計著作財產權，於驗收合格並付清尾款後歸委託方所有」 |
| 2 | 原始碼交付與託管 | 只在專案結束才拿到原始碼，過程中毫無保障；廠商中途歇業更求助無門 | 約定原始碼隨每個里程碑交付，或版本控制系統帳號直接設於委託方名下 |
| 3 | 驗收標準定義 | 沒有具體標準，雙方對「完成」的認知落差會拖延付款與上線時程 | 以書面列出每項功能的測試案例與通過條件，並約定驗收期限（例如 10 個工作天） |
| 4 | 里程碑付款排程 | 全額後付讓廠商承擔過高墊款風險、全額預付則委託方承擔多數風險 | 依簽約、設計確認、MVP 交付、UAT 驗收、最終交付分 4-5 期付款 |
| 5 | 保固期 | 沒有保固期，上線後第一週出現的 bug 可能被當成新需求另外計費 | 明訂保固期（如驗收後 60 天），期間內因廠商疏失造成的錯誤免費修復 |
| 6 | 上線後維護 SLA | 沒有 SLA，故障回應時間完全取決於廠商當下人力調度 | 約定嚴重程度分級（如 P1/P2/P3）與對應的回應、修復時限 |
| 7 | 變更需求計價方式 | 沒有計價機制，範圍蔓延（scope creep）會無上限吃掉預算與工期 | 約定變更需求需經書面確認，並依工時或固定費率另計 |
| 8 | 終止條款 | 沒有終止機制，任一方想中止合作時容易陷入僵局 | 約定可終止事由、通知期限（如 30 天）與終止後的交付與退款規則 |
| 9 | 保密協議／NDA | 開發過程會接觸營運數據與商業邏輯，外流風險高 | 明訂保密義務範圍、期限（如合約終止後 2-3 年）與違約賠償金額 |
| 10 | 資料所有權 | 系統產生與蒐集的資料所有權若未載明，容易與程式碼著作權混為一談 | 明訂「系統運行所產生之使用者資料與營運數據歸委託方所有」 |
| 11 | 第三方授權揭露 | 使用未妥善授權的開源套件或 API，日後可能面臨授權糾紛或強制停用風險 | 要求廠商列出使用的第三方套件清單、授權條款與潛在限制 |
| 12 | 責任上限 | 沒有上限，任一方的求償金額理論上可以無限擴張，反而讓合約難以簽署 | 約定各方賠償責任上限（常見做法是已付總價款的一定倍數） |
| 13 | 分包權利 | 廠商私下外包給不知名團隊，品質與保密程度都失去控制 | 約定分包需經委託方書面同意，且廠商須對分包商的行為負連帶責任 |
| 14 | 爭議解決與準據法 | 沒有約定，跨國專案發生糾紛時，連該去哪個法院都要先爭執一輪 | 明訂準據法（如中華民國法律）與管轄法院或仲裁機構 |
| 15 | 交付物格式 | 「交付」定義不清，可能只拿到執行檔而非可維護的完整專案 | 列出交付清單：原始碼、資料庫結構、部署文件、操作手冊等 |
這份表格裡的「建議寫法」欄位不是法律條文範本，而是提醒您議約時該把哪些變數談清楚——多數合約糾紛的起點往往不是完全沒寫某個條款，而是條款寫得太模糊，雙方各自解讀成對自己有利的版本。以一家 20 人規模的 B2B SaaS 新創為例（此為綜合多個接案經驗整理之範例，非特定客戶），該公司最初收到的合約草稿只寫「驗收後付清尾款」，沒有列出驗收標準與時間點；重新議約後，加入了本表第 3、4 項的具體驗收條件與 4 期付款排程，雙方才能在每個里程碑各自確認進度，而不是等到專案尾聲才發現彼此對「完成」的認知早已落差一大截。建議您每拿到一份合約草稿，就直接把這 15 項當成逐條確認的對照清單，而不是只看合約最後一頁的總價與交期兩個數字。
智財歸屬與原始碼交付：兩個最容易吃虧的條款
智慧財產權歸屬之所以排在檢核表第一位，是因為多數委託方誤以為「我付錢了，程式碼自然是我的」。根據著作權筆記針對委託開發程式著作權疑義的整理，台灣著作權法對「出資聘人完成之著作」設有專門規定：若契約沒有另行約定，著作財產權可能仍歸實際完成創作的受聘方（開發商）享有，委託方即使付清全部費用，也可能只取得利用該著作的權利，而非完整的著作財產權。這也代表如果合約沒寫清楚，未來想把系統轉交給其他廠商維護、想修改原始碼，或想把系統包裝成產品對外銷售，都可能面臨法律上的模糊地帶。
原始碼交付是另一個常被忽略的環節。很多委託方以為「反正驗收完會拿到原始碼」，但如果合約沒有明訂交付時機與方式，廠商很可能只在專案結束、甚至只有在委託方主動要求時才交付，而且格式可能只有編譯後的執行檔。比較嚴謹的做法，是把版本控制系統（例如 GitHub、GitLab）的 repository 直接建在委託方的帳號底下，開發商以協作者身份取得存取權限，這樣即使中途更換廠商或發生糾紛，委託方手上永遠有最新版本的程式碼。預算較高、系統關鍵度也較高的專案，也可以考慮加上原始碼託管（source code escrow）機制，由第三方保管原始碼，只在開發商違約或無法履約時才釋出。
驗收標準怎麼寫，才不會各說各話
驗收爭議多半不是因為系統「做得不好」，而是雙方對「完成」的定義從一開始就不一致。負責任的合約會把每項主要功能拆解成具體的測試案例，並寫明通過條件是什麼——例如「訂單結帳流程需支援信用卡與 ATM 轉帳兩種付款方式，且成功交易需正確寫入訂單資料庫」，而不是籠統地寫「完成電商系統」。
建議合約同時載明驗收流程的時間限制，例如委託方應於收到交付通知後 10 個工作天內完成測試並回覆驗收結果，逾期未回覆視為驗收通過；若驗收發現問題，也應約定嚴重程度分級與對應的修復期限，避免小 bug 拖延成整個專案卡關。Sprintlaw 針對軟體開發合約重點條款的整理也建議驗收條件要具體到可測量，例如「登入功能須通過使用者測試且無重大缺陷才算驗收通過」，而不是用「符合客戶滿意」這種主觀標準。
付款里程碑範例：從簽約到驗收怎麼分期
付款排程直接反映雙方的風險分攤方式。全額後付會讓開發商承擔過高的墊款壓力，可能影響交付品質；全額預付則讓委託方幾乎沒有談判籌碼。比較平衡的做法，是把總價拆成 4-5 期，對應專案的關鍵里程碑：
| 里程碑 | 建議佔比 | 說明 |
|---|---|---|
| 簽約 | 20%-30% | 專案啟動費用，涵蓋需求訪談與架構設計初期投入 |
| 設計／規格確認 | 20% | 完成介面設計稿與系統規格書並經委託方書面確認後支付 |
| MVP 交付 | 20%-30% | 核心功能可運作版本交付，供委託方實際操作測試 |
| UAT／驗收通過 | 20% | 使用者驗收測試（UAT）完成且無重大缺陷後支付 |
| 最終交付／上線 | 10%-20% | 系統正式上線、完成教育訓練與文件交付後支付尾款 |
依諾訊科技 2026 年的接案觀察，中小型客製化軟體專案採用上述 4-5 期付款結構相當常見，尾款保留 10%-20% 可以讓開發商有持續配合上線後修正的誘因，而不是拿到大部分款項就降低服務優先度。
這些百分比區間是怎麼決定的，又該怎麼解讀？比例反映的是雙方在議約當下的風險分攤與信任基礎，不是隨意喊價的數字。簽約金若壓在 20% 甚至更低，通常代表委託方與廠商還在建立第一次合作的信任（例如過去沒有合作紀錄），廠商也會相對願意配合較低的前期保障；簽約金拉高到 30%，則多半是因為廠商前期投入的架構設計與需求盤點工時已經很高，或是委託方過去已有多次合作、彼此信任基礎較穩固。同樣地，尾款保留 10% 還是 20%，取決於系統上線後的營運風險高低——涉及金流、會員個資或對外服務的系統，建議談到接近 20% 的上限，確保廠商在上線初期仍有配合修正的誘因；內部工具或風險較低的系統，10% 通常已足夠。換句話說，看到這些區間時，應該問的是「我們這個專案落在區間的哪一端、為什麼」，而不是直接套用區間中位數。
保固期與維護 SLA 怎麼談
保固期與上線後維護，是報價單上經常被簡化成一句「售後服務」的部分，但兩者其實是不同的東西。保固期通常涵蓋因開發商程式疏失造成的錯誤修復，期限沒有統一標準，但業界常見做法多落在驗收後 30 到 90 天之間；保固期一過，任何錯誤修復或功能調整原則上都要另外計費。
維護 SLA（服務等級協議）則是保固期之後的長期合作機制，建議至少約定三件事：故障嚴重程度分級（例如影響全系統的 P1、影響部分功能的 P2、介面小瑕疵的 P3）、對應的回應與修復時限（P1 可能要求 4 小時內回應、24 小時內修復），以及維護費用的計算方式（依月費或依流量計算）。依諾訊科技的接案經驗，年度維護費用大約落在原始開發費用的 15%-20%，實際比例仍會依系統複雜度與 SLA 等級調整。
以一家 50 人規模的零售業客戶為例（此為綜合多個接案經驗整理之範例，非特定客戶），該公司上線後第二週發現訂單通知信偶爾漏發；由於合約明訂保固期為驗收後 60 天，且涵蓋此類既有功能的異常修復，開發商在保固範圍內無償排查並修正。同一時間，客戶另外提出「希望新增簡訊通知」的需求，則因為超出原始驗收範圍，被歸類為新功能，依變更需求計價方式另外報價計時計費。這個案例說明保固與維護的界線，關鍵不在於問題大小，而在於它是「原有功能沒做對」還是「想要新增功能」——合約條款寫清楚，雙方在爭執發生時才有依據可循，而不是臨時各自解讀。
常見錯誤與紅旗
以下是中小企業在簽署軟體開發合約時，最常見的疏漏與應該提高警覺的紅旗：
- 只談總價、不談分項：合約只寫一個總金額，沒有拆解功能模組與對應費用，日後很難判斷加減需求該怎麼計價。
- 驗收條件寫「符合客戶需求」：這種主觀敘述在爭議發生時毫無約束力，務必換成具體、可測試的驗收標準。
- 原始碼交付時間點模糊：合約沒寫「何時」交付原始碼，等於默認只在專案結束、甚至只在委託方主動索取時才交付。
- 保固期與維護混為一談：把保固期當成終身免費維護，簽約時沒問清楚保固期之外的收費方式。
- 責任上限條款缺席：完全沒有責任上限，看似對委託方有利，實際上反而讓廠商不願意簽署，或在條款中另外埋入對己方有利的但書。
- 分包未經同意：合約沒有約定分包需經委託方同意，導致實際開發團隊與簽約對象不一致，品質與保密都難以追蹤。
- 準據法與管轄法院空白：尤其是與海外團隊合作時，沒有約定準據法，一旦發生糾紛，光是確認要在哪裡打官司就會耗費大量時間與成本。
這些紅旗多數不需要法律背景就能自己先篩一輪——收到合約草稿後，先用上述清單快速掃過一次，把「寫得模糊」或「完全沒提到」的條款標記起來，再拿著這份標記清單去請廠商逐條補充說明或請律師協助審閱，會比整份合約從頭讀到尾更有效率，也更容易聚焦在真正有爭議風險的地方。
下一步
合約條款清不清楚，往往決定一個軟體專案是順利上線還是中途卡關。如果您正在準備發包或即將簽署軟體開發合約，建議先用上述 15 項檢核表逐條對照廠商提供的草稿，再交由律師做最後把關。諾訊科技提供從需求訪談、合約範圍確認、架構設計到上線維護的完整客製化軟體開發服務，歡迎參考 客製化軟體開發服務 了解我們如何界定範圍與交付物；若想進一步了解合作流程與各階段費用區間，也可參考 合作流程與費用 頁面。