台灣新創外包海外工程團隊簽約流程教學：7 步驟實作指南

台灣新創外包海外工程團隊的簽約流程，建議依序完成七個步驟：確認需求範圍（SOW）、選定合約架構（MSA + SOW）、鎖定智慧財產權歸屬、設定跨境稅務與付款、對照資料保護法規、完成具法律效力的電子簽署，最後在 72 小時內交接系統權限。

許多台灣新創第一次發包給新加坡、越南或香港的工程團隊時，最常犯的錯誤不是選錯廠商，而是把「報價單」當成「合約」。報價單寫了功能清單與金額，卻沒寫驗收標準、原始碼歸屬、資料處理地點與終止條款——等到專案第三個月出現爭議，才發現沒有任何條文可以依據。

這篇教學按照實際執行順序拆解整個簽約流程，包含可直接複製的條款範本、GitHub 權限設定指令，以及跨境付款與扣繳的實務注意事項。適用對象是 5 到 50 人、準備把部分或全部工程交付委外到亞太市場的台灣新創團隊。

開始前你需要準備哪些文件與資訊？

在聯絡任何外包團隊之前，先把以下資料備齊。缺少任何一項，後面的流程都會卡住或被迫重來。

公司端文件

1. 公司設立登記證明（經濟部商業司公示資料截圖或變更登記表）
2. 負責人身分證明與用印授權文件（若非負責人簽署）
3. 統一編號與公司英文名稱（須與銀行帳戶、國稅局登記一致）
4. 外幣帳戶資訊（跨境付款建議開立美金帳戶，避免每次匯款被雙重換匯）

專案端文件

1. 產品需求文件（PRD）或至少一份功能清單
2. 現有系統架構圖與技術堆疊清單
3. 預算區間與付款節奏偏好（按月、按里程碑或混合）
4. 資料分類清單：哪些資料屬於個資、哪些屬於營業秘密、哪些可以放在境外

法務端準備

依據經濟部商業司公示的公司登記資料，台灣公司對外簽約須確認簽署人具代表權。若由共同創辦人或技術長簽署，務必備妥董事會決議或授權書，否則對方的法務在盡職調查時會退件。

第四項資料分類清單最常被忽略。全國法規資料庫收錄的《個人資料保護法》第 21 條規定，非公務機關國際傳輸個人資料，中央目的事業主管機關在特定情形下得限制之——換句話說，你不能假設所有資料都能自由放到境外伺服器。先分類，後議約。

第一步：先寫 SOW，再談價格

工作說明書（Statement of Work, SOW）是整份合約的技術骨幹。先寫 SOW 的好處是：你在談價格之前就已經定義了「完成」的意思，對方報價會更精準，你也更容易比較三家廠商。

一份可用的 SOW 至少要包含五個區塊。以下是我們建議新創使用的結構，可用 Markdown 或 YAML 版控在內部 repo 裡：

1# sow-v1.yaml — 與合約附件 A 內容一致
2project:
3  name: "B2B 訂單中台 Phase 1"
4  start_date: "2026-03-02"
5  end_date: "2026-06-30"
6
7scope_in:
8  - "訂單 API（建立/查詢/取消）含 OpenAPI 3.1 文件"
9  - "後台管理介面（React 18 + TypeScript）"
10  - "與既有 ERP 的 webhook 整合（限 3 個事件）"
11
12scope_out:
13  - "行動 App"
14  - "ERP 端程式修改"
15  - "上線後的 24/7 維運"
16
17acceptance_criteria:
18  - id: AC-01
19    desc: "所有 API 端點通過 Postman 測試集，成功率 100%"
20  - id: AC-02
21    desc: "單元測試覆蓋率 >= 70%（以 vitest --coverage 報告為準）"
22  - id: AC-03
23    desc: "Lighthouse Performance >= 85（後台首頁，桌機模式）"
24  - id: AC-04
25    desc: "交付 Docker Compose 檔，於乾淨機器可一鍵啟動"
26
27milestones:
28  - name: M1 架構與環境
29    payment_pct: 20
30    deliverable: "CI/CD pipeline 可跑通，staging 可存取"
31  - name: M2 核心 API
32    payment_pct: 40
33  - name: M3 UAT 通過
34    payment_pct: 30
35  - name: M4 保固期滿
36    payment_pct: 10
37    warranty_days: 60

為什麼 scope_out 一定要寫？ 因為爭議幾乎都發生在模糊地帶。明確列出不包含的項目，等於替雙方省下後續每一次「這個應該含在裡面吧」的溝通成本。

驗收標準要可機器驗證。寫「效能良好」無法執行；寫「Lighthouse Performance >= 85」可以在 CI 裡跑。Google 公開的 Lighthouse 文件說明效能分數為加權計算結果，因此務必同時註明測試裝置與網路條件，否則同一份程式碼在不同環境會跑出不同分數。

第二步：選 MSA + SOW 架構，還是單次合約？

單次合約（Fixed-scope Agreement）

適合一次性專案、預算明確、不預期後續合作。所有條款與工作範圍寫在同一份文件。優點是簡單；缺點是每次新專案都要重走一次法務流程。

MSA + SOW 架構

主服務協議（Master Services Agreement）規範長期不變的部分：保密、智財、責任限制、準據法、終止機制。每個專案再簽一份 SOW 作為附件，只寫範圍、時程、金額。

對預期會持續合作 12 個月以上的團隊，MSA + SOW 幾乎永遠是更好的選擇。第二個專案只需要雙方簽一頁 SOW，不必再把律師找回來審一次賠償條款。

準據法與爭議解決怎麼選？ 跨境合約最常見的三種組合：

1. 台灣法 + 台北地方法院：對台灣新創最熟悉，但對方若在越南或印尼，執行判決困難。
2. 新加坡法 + SIAC 仲裁：新加坡國際仲裁中心（SIAC）為亞太跨境商務常見選擇，依據《紐約公約》其仲裁判斷在多數締約國可獲承認與執行。
3. 香港法 + HKIAC 仲裁：香港國際仲裁中心同樣受《紐約公約》保障，對涉及大中華區的合約常見。

實務上，當雙方規模不對等時，較小一方很難堅持自己的主場。折衷做法是約定「被告地原則」——誰提告就去對方所在地，雙方都有提告成本，反而會促成協商解決。

第三步：智慧財產權條款該怎麼寫才站得住腳？

這是整份合約中最不能省的部分。台灣《著作權法》第 12 條規定，出資聘請他人完成之著作，除契約另有約定外，以受聘人為著作人、著作財產權依契約約定；未約定者著作財產權歸受聘人享有——也就是說，不寫清楚，程式碼的著作財產權可能不在你手上。

可直接使用的條款骨架（中英對照建議雙語版本，以英文為準據）：

1第 X 條 智慧財產權
2
3X.1 交付成果之歸屬
4乙方同意，依本合約及各 SOW 所完成之全部交付成果（包含但不限於
5原始碼、設計稿、文件、測試腳本、CI/CD 設定檔，以下合稱「交付
6成果」），其著作財產權、專利申請權及其他一切智慧財產權，自各
7該成果產生時起，即讓與甲方並歸甲方單獨所有。乙方並同意不對甲
8方及甲方之授權人行使著作人格權。
9
10X.2 先存智財（Pre-existing IP）
11乙方於本合約簽訂前已存在或獨立開發之工具、函式庫與框架（下稱
12「先存智財」）仍歸乙方所有。乙方應於附件 B 完整列明先存智財清
13單；凡未列明者，視為 X.1 所定之交付成果。乙方就其嵌入交付成果
14之先存智財，授予甲方不可撤銷、全球性、永久、免權利金、可再授
15權之使用、重製及改作權。
16
17X.3 第三方與開源元件
18乙方應交付完整軟體物料清單（SBOM, CycloneDX 或 SPDX 格式），
19列明所有第三方及開源元件之名稱、版本與授權條款。未經甲方書面
20同意，乙方不得導入 GPL-3.0、AGPL-3.0 或其他具傳染性之授權元件。
21
22X.4 轉包人員之權利拘束
23乙方應確保其員工、承攬人及任何次承攬人均已簽署內容不低於本條
24保護標準之智財讓與文件，並於甲方要求時提出證明。

X.2 的先存智財清單是最常被跳過、也最常出事的一條。外包團隊通常有自己的內部框架或腳手架，如果沒列清單又沒給你授權，等於你的產品裡藏了一段你沒有權利使用的程式碼。

X.4 的轉包拘束同樣關鍵。你簽約的對象是公司，但實際寫程式的是個別工程師；若該公司與員工之間沒有有效的職務著作或讓與約定，X.1 的讓與鏈就會斷掉。

營業秘密的補強：全國法規資料庫收錄的《營業秘密法》第 2 條要求營業秘密須符合秘密性、經濟價值與「所有人已採取合理之保密措施」三要件。這表示光簽 NDA 不夠——你還要能證明有實際管控：權限分級、存取紀錄、離職註銷。這些動作要寫進合約的資安附件，也要真的執行。

第四步：跨境付款與扣繳稅務怎麼設定？

扣繳義務的判斷

台灣公司給付報酬給境外公司時，是否須辦理扣繳，核心在於該筆所得是否屬「中華民國來源所得」。依《所得稅法》第 88 條及第 73 條相關規定，境內無固定營業場所及營業代理人之外國營利事業，其中華民國來源所得由扣繳義務人於給付時依規定扣繳率扣繳——實務上勞務報酬常見扣繳率為 20%。

關鍵在於勞務提供地。若整段開發工作完全在境外完成、未派員來台，依《所得稅法》第 8 條第 3 款關於勞務報酬來源之認定，有機會主張非中華民國來源所得；但實際認定須向國稅局申請核准，不能自行判斷。

實務建議三件事：

1. 在合約中明確記載勞務提供地點與人員所在國家，作為申請佐證。
2. 約定金額是「含稅」還是「稅後淨額」（net of withholding）。這一句沒寫，20% 的差額就會變成爭議。
3. 若對方所在國與台灣簽有租稅協定（台灣已與新加坡、越南、馬來西亞、澳洲、紐西蘭等多個經濟體簽署全面性所得稅協定，清單見財政部稅務入口網），可備妥居住者證明申請較低協定稅率。

合約條文可寫成：

1第 Y 條 稅負
2Y.1 本合約所載金額為未稅金額。依中華民國稅法規定應由甲方扣繳
3    之稅款，由甲方自應付金額中代扣代繳，並於繳納後 30 日內提供
4    扣繳憑單予乙方。
5Y.2 乙方如為租稅協定締約他方之居住者，得於首次請款前提供其稅
6    務機關核發之居住者證明，由甲方協助向主管稽徵機關申請適用
7    協定稅率。
8Y.3 匯款手續費及中間行費用由乙方負擔；匯率差額由乙方承擔。

付款管道的取捨

傳統電匯（SWIFT）：金額大時單位成本較低，但中間行費用不透明，且到帳時間常需 1 到 3 個工作日。適合單筆金額較高的里程碑付款。

Wise Business 等跨境支付平台：費率與到帳時間較透明，Wise 官方說明其採用中間市場匯率並單獨列示手續費。限制是單筆與每月額度、以及部分幣別的支援度，須先確認對方所在地是否可收款。

第三方託管（Escrow）：首次合作且金額較大時值得考慮。資金先存入託管帳戶，驗收通過才放款。成本是額外手續費與流程時間。

不論用哪種，都要在合約裡寫明「付款日自甲方收到符合規定之發票起算 N 日」，而不是「每月 30 日付款」。前者把責任放在對方按時開票，後者讓你在對方晚開票時仍背負遲延責任。

第五步：把資料保護義務寫成可執行的附件

如果你的產品服務歐盟使用者，或客戶名單裡有歐洲企業，外包合約就必須包含資料處理協議（DPA）。歐盟執委會的資料保護頁面說明，GDPR 第 28 條要求控制者與處理者之間須有書面合約，載明處理目的、期間、類型與資料主體類別。

新加坡個人資料保護委員會（PDPC）的 PDPA 架構同樣要求組織對轉移到境外的個資負責。台灣《個人資料保護法》第 27 條則要求非公務機關保有個人資料檔案者，應採行適當之安全措施。

三套法規要求不同，但可以用一份附件同時滿足。建議的資安附件最小內容：

1. 資料地理位置：明確指定資料庫與備份所在區域（例如 ap-southeast-1），禁止未經書面同意變更。
2. 次處理者清單：列出所有雲端與 SaaS 供應商；新增須提前 30 日通知。
3. 存取控制：最小權限原則、MFA 強制、季度權限複核。
4. 事件通報：發現資安事件後 24 小時內通知甲方（比 GDPR 的 72 小時更嚴格，留出你自己通報主管機關的時間）。
5. 資料刪除：合約終止後 30 日內刪除並提出書面證明。
6. 稽核權：甲方得每年要求一次遠端稽核，或接受 ISO/IEC 27001 驗證證書替代。

接受 ISO/IEC 27001 證書替代實地稽核，對雙方都省事。ISO 官方說明 ISO/IEC 27001 為資訊安全管理系統的國際標準，已通過驗證的供應商通常能直接提供適用範圍聲明（Statement of Applicability）。

第六步：用電子簽章完成簽署

台灣《電子簽章法》承認電子文件與電子簽章在當事人同意之情形下具有與書面及簽名同等之效力。跨境簽署時，建議在合約本文加入一條：

1第 Z 條 簽署
2本合約得以電子方式簽署，並得分別簽署於數份副本，各副本均為正
3本，合為同一文件。雙方同意透過電子簽章平台完成之簽署，與紙本
4親簽具同等效力，並同意不以電子形式為由爭執其效力。

實務流程：

1. 以 PDF/A 格式產出最終版合約，附件編號與本文引用一致。
2. 透過 DocuSign、Adobe Acrobat Sign 或同等平台發送，設定簽署順序。
3. 簽署完成後，下載稽核軌跡報告（Certificate of Completion）與簽署檔一併歸檔——發生爭議時，證明簽署人身分的是這份報告，不是 PDF 本身。
4. 歸檔位置建議與合約管理清單綁定，記錄到期日與自動續約通知日。

自動續約條款要特別注意。若 MSA 寫「期滿自動續約一年，除非提前 60 日通知」，就要在行事曆設提醒，否則會被動續約。

第七步：簽約後 72 小時的技術交接清單

合約簽完不代表結束。接下來的三天決定專案能不能順利啟動，也決定你的資安邊界是否成立。

GitHub 組織權限設定

不要把外包團隊加進既有的 owner 群組。建立獨立 team，只給必要 repo 的 write 權限：

1# 建立外包團隊
2gh api -X POST /orgs/YOUR_ORG/teams \
3  -f name='vendor-apac-eng' \
4  -f description='External delivery team - Phase 1' \
5  -f privacy='closed'
6
7# 僅授予特定 repo 的 push 權限
8gh api -X PUT /orgs/YOUR_ORG/teams/vendor-apac-eng/repos/YOUR_ORG/order-service \
9  -f permission='push'
10
11# 檢查目前成員與權限（交接後每月複核一次）
12gh api /orgs/YOUR_ORG/teams/vendor-apac-eng/members --jq '.[].login'

接著設定分支保護與程式碼審查歸屬。GitHub 官方文件說明 CODEOWNERS 檔案可在 pull request 建立時自動指派審查者：

1# .github/CODEOWNERS
2*                       @YOUR_ORG/internal-leads
3/src/payments/          @YOUR_ORG/internal-leads
4/src/features/orders/   @YOUR_ORG/vendor-apac-eng @YOUR_ORG/internal-leads
5/infra/                 @YOUR_ORG/internal-leads

付款與基礎設施目錄永遠保留內部審查。這不是不信任，而是讓責任歸屬在出事時清楚可查。

密鑰與憑證

絕不透過 Slack、Email 或 Notion 傳遞憑證。建立專用的密碼管理 vault，離職或合約終止時整個 vault 註銷即可：

1# 以 1Password CLI 為例
2op vault create "Vendor-APAC-Phase1"
3op item create --category=login --vault="Vendor-APAC-Phase1" \
4  --title="Staging DB" --url="https://staging-db.internal" \
5  username=app_readonly

雲端存取建議走短期憑證而非長期金鑰。AWS 官方文件建議使用 IAM 角色與臨時安全憑證，而非發放長期存取金鑰給外部人員。

啟動日檢查清單

1. SOW 附件版本與合約簽署版一致（版本號寫進 commit message）
2. 專案溝通管道建立，並約定回覆時間窗（含時區）
3. 驗收標準已轉為 CI 檢查項目
4. 首次付款發票規格確認（抬頭、統編、幣別、付款條件）
5. 存取權限清單與到期日記錄在案

一家在台北與新加坡兩地營運的 B2B SaaS 新創，曾在啟動前把上述 AC-01 到 AC-04 直接寫成 GitHub Actions 的 job，讓驗收爭議從「主觀判斷」變成「綠燈或紅燈」。這類做法不需要額外工具成本，但需要在簽約階段就想清楚。

AI 協作時代該補上哪些條款？

外包團隊使用 GitHub Copilot、Claude Code 或 Cursor 已是常態。2024 年 Stack Overflow Developer Survey 顯示，超過六成受訪開發者表示正在使用或計畫使用 AI 開發工具。與其禁止，不如規範。

建議新增三條：

1. 揭露義務：乙方應揭露用於產出交付成果之 AI 編碼輔助工具名稱與版本。
2. 資料邊界：未經甲方書面同意，不得將甲方原始碼、客戶資料或營業秘密輸入未簽署企業版資料處理條款之 AI 服務。企業版方案（如 GitHub Copilot Business）通常提供不以用戶程式碼訓練模型的保證，應以書面確認。
3. 智財保證：乙方保證交付成果不侵害第三人智慧財產權，此保證不因使用 AI 工具而減免。

第二條最實際。免費版 LLM 服務與企業版的資料使用政策差異極大，合約必須把這個差異寫成可稽核的要求，而不是信任承諾。

常見卡關情況與排除方法

對方堅持用自己的合約範本。 可接受，但要求提供 Word 可追蹤修訂版本，並逐條比對你的五個底線：智財歸屬、保密、資料地點、終止權、責任上限。範本是誰的不重要，條文內容才重要。

責任上限談不攏。 多數供應商會要求責任上限等於合約金額。可接受，但要求將「智財侵權」「保密義務違反」「故意或重大過失」排除在上限之外——這是國際商務合約的常見作法。

對方無法提供居住者證明。 代表協定稅率無法適用，須以法定扣繳率計算。這會直接改變實際成本，應在簽約前而非請款時釐清。

驗收標準在執行中被挑戰。 若 SOW 的 AC 寫得夠具體，爭議通常來自測試環境差異。解法是在合約附件固定測試環境規格（硬體、網路、資料量），而不是重新談標準。

終止後交接不順。 終止條款要寫明「過渡協助期」：終止生效後 30 日內，乙方應提供交接文件、環境存取與不少於 N 小時的技術說明，費率依原 SOW 計價。沒有這條，終止日就是斷線日。

把簽約流程變成可重複的內部資產

第一次走完這七步可能需要四到六週，大部分時間花在法務往返。但第二次就不應該再花同樣時間——把 MSA 範本、SOW 範本、資安附件、權限設定腳本都版控起來，新專案只需填 SOW。

對正在跨出台灣市場的新創而言，這套流程的價值不只在於控制風險。當你能在兩週內完成一份跨境工程外包合約，你就能更快測試新市場、更彈性調整團隊組成，並在新加坡、越南、馬來西亞之間依據技能與時區需求調配資源，而不是被綁在單一供應商。

Branch8 總部位於香港，在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，長期協助台灣、歐美企業建立跨境工程與營運合作架構。若你正在規劃第一份海外工程外包合約，或想檢視現有合約的智財與資安缺口，歡迎與我們的團隊聊聊你的專案輪廓。

Sources

• 全國法規資料庫 — 中華民國法規查詢
• 經濟部智慧財產局
• 財政部稅務入口網 — 所得稅協定與扣繳規定
• GitHub Docs — Organizations and teams
• European Commission — Data protection in the EU
• Personal Data Protection Commission Singapore
• ISO — ISO/IEC 27001 Information security management
• Stack Overflow — Developer Survey