ERP 驗收條款怎麼寫才保護得了自己？五個一定要寫進合約的條件

「驗收喔？就等他們系統上線，我們用一用沒問題就簽名啊，這還要寫什麼？」

這句話我在簽約前的會議室裡聽過太多次。老闆講得很自然，因為在他的想像裡，驗收是一個「感覺」——系統跑起來、大家用得下去、沒有人在罵，那就叫驗收通過。

問題是，合約不是靠感覺運作的。當你在合約裡沒有定義「驗收」，真正發生的事情是這樣：三個月後系統上線了，但倉庫的庫存數跟實際差一大截、月結跑不出來、業務還是回頭用 Excel 開單。你說「這樣不算驗收吧」，廠商拿出當初的會議紀錄說「功能都交付了，這些是使用者習慣問題」。你想扣尾款，他說合約寫的是上線後付款，系統已經上線了。

這一刻你才發現，你們兩邊對「驗收」的定義從來沒有對過。而在沒有定義的情況下，誰手上握著系統、握著原始碼、握著你的資料，誰的定義就是對的。

我是熊董，台灣川輝科技。我帶團隊做導入七年，經手 34 個案子、橫跨 12 個產業。這幾年被老闆拉去看合約的次數，幾乎跟被拉去看報價單一樣多——而且通常是在事情已經卡住之後。我要老實講：報價單看錯，你頂多多花錢；驗收條款寫錯，你會卡在一個「錢付了、系統不能用、廠商不理你」的死局裡，而且法律上還站不住腳。

先把結論講在最前面。

ERP 合約裡最值錢的一段不是價格，是驗收條款。而一份能保護你的驗收條款，只要做到五件事：驗收標準綁「真實資料跑完一個完整營運循環」而不是廠商 demo；驗收項目逐條列成可以打勾的清單；寫明驗收失敗的補正期與補正次數上限；付款節點綁驗收結果、不綁時間；保固從驗收通過日起算、不從安裝日或簽約日起算。這五條寫進去，你的風險就少掉一大半。而願意跟你把這五條寫細的廠商，通常就是那個做得起來的廠商。

「驗收」沒定義清楚，等於把主導權整包送給廠商

先講一個觀念問題。很多老闆把驗收想成專案的「最後一關」——東西做完了，我檢查一下，OK 就過。

錯。驗收條款真正的作用不是在最後那一天，而是在整個專案進行中，作為你唯一的談判籌碼。

想想看：專案開始之後，你手上還剩什麼？錢已經付了一大部分——簽約款、規格確認款、開發款，這幾筆加起來通常已經是報價單上的大頭。資料已經給了。人已經投進去了。你的舊系統可能已經停止維護。這個時候如果廠商拖延、品質不好、需求一直被說成「這是客製要另外報價」，你能怎麼辦？

你唯一能做的，就是不驗收。

但如果合約裡的驗收條款寫得很鬆——比如只寫「系統安裝完成並經甲方測試無誤後，視為驗收通過」——那「無誤」是誰認定的？「測試」要測多久？如果甲方一直說有誤，會不會被反過來說是惡意不驗收？

條款寫得越模糊，解釋權就越往握有系統的那一方偏。這不是廠商壞，這是結構。

上線日、驗收日、保固起算日：這三個日期一定要分開寫

這是我看合約時第一個會找的東西，而且大部分我看過的合約都把它們寫得糊在一起。

很多合約只有一個日期概念：「系統上線」。上線之後就開始算保固、就開始付尾款、就開始算年度維護費。這對你極度不利，原因很簡單：上線只代表系統開始跑，不代表系統跑得對。

正確的做法是把它拆成三個獨立的日期，每一個都要有各自的定義與觸發條件：

**第一個是上線日（或稱正式啟用日）。**定義是：系統正式在生產環境開始使用，舊流程停止或平行運作。這一天的意義是「風險開始轉移到真實營運」，不是「工作完成」。

**第二個是驗收日（或稱驗收通過日）。**定義是：上線之後，經過一段約定的驗證期，雙方依照合約附件的驗收清單逐項確認、簽署驗收證明書的那一天。上線日到驗收日中間，一定要有一段時間，我通常建議至少涵蓋一個完整的月結週期。

**第三個是保固起算日。**應該等於驗收日，不是上線日，更不是安裝日或簽約日。

為什麼要分開？舉個很實際的例子：假設合約寫「保固一年，自系統上線日起算」，而你的系統三月上線、六月才真正把月結跑順、驗收簽名。那你等於白白吃掉三個月保固，而且那三個月還是問題最多的三個月——因為它們被歸進「導入期」，廠商修 bug 修得很認真，但保固的時鐘也在跑。等到系統真正穩定下來，保固只剩九個月。

我看過更誇張的寫法：保固自簽約日起算。這種條款如果導入拖了半年，你等於保固還沒開始用就過期一半。看到這種寫法，直接要求改，這沒有什麼好談的。

如果你連專案會拖多久都還沒概念，建議先看一下ERP 導入時程怎麼抓，把時間軸抓出來，你才知道這三個日期各自應該落在哪裡、中間該留多少緩衝。

五個一定要寫進 ERP 合約的驗收條件

好，觀念講完，進入實作。以下五條，是我認為中小企業簽 ERP 合約時最低限度該爭取的東西。不是每一條都能全拿，但每一條你都該提出來——因為對方怎麼回應這五條，本身就是資訊。

一、驗收以「真實資料跑完一個完整營運循環」為準，不是廠商 demo 通過就算

這是五條裡面最重要的一條，如果你只能爭取一條，爭取這條。

廠商的 demo 環境是什麼？是一套資料乾淨、品號規格整齊、客戶只有五個、單據流程走直線的展示資料。在那個環境裡，任何系統都很順。

你的真實環境是什麼？是同一個客戶有三種寫法、品號有全形半形混用、一張訂單改過好幾次、三天兩頭有急單插隊、月底還有一堆退貨與折讓要沖。

這兩件事的難度差距，大概是模擬考跟聯考的差距。

所以驗收條款裡要寫清楚：驗收測試必須使用甲方的真實營運資料，在正式環境或與正式環境同規格的環境中，完整執行一個營運循環。

什麼叫一個完整營運循環？以買賣業來說，大致是：報價、訂單、採購、進貨、入庫、出貨、開立發票、收付款、庫存盤點、月結結帳、產出財務報表。以製造業來說，中間還要加上工單、領料、報工、委外、成本計算。

這一整串走完，數字要對得起來——這才叫系統能用。

我知道有些廠商會抗拒，理由通常是「這樣驗收期太長」「有些流程要看貴公司的作業速度」。這些理由部分合理，可以談的是範圍與時程，但不該談的是原則。你可以退讓成「主要營運循環（雙方於附件列舉）跑完即可，次要流程另列後續改善清單」，但不能退讓成「以廠商測試環境展示通過為準」。

順帶一提，很多導入之所以在最後一哩路翻車，就是因為驗收標準停在 demo 層級，真實資料一進去全部現形。這件事我在ERP 導入為什麼會失敗那篇講得更完整，可以搭配著看。

二、驗收項目要逐條列出可勾選的清單，不能只寫「系統功能正常」

「系統功能正常運作」這七個字，是驗收條款裡最沒有用的一句話。

因為「正常」沒有標準。系統打得開算不算正常？報表跑得出來但數字不對算不算正常？跑一張單要三十秒算不算正常？

你要的是一份可以打勾的清單，而不是一句形容詞。

具體做法：在合約本文寫「驗收標準詳如附件一」，然後把附件一做成一份逐條列舉的表格。每一條至少要有這幾個欄位：

• 項目編號與所屬模組
• 驗收情境：用一句話描述要做什麼，例如「建立一張含三個品項、其中一項為委外加工件的銷貨單，並完成出貨與開票」
• 預期結果：做完之後系統該長什麼樣，例如「庫存扣帳正確、應收帳款產生、發票號碼連號、成本入帳」
• 判定：通過／不通過
• 測試人員與日期

這份清單怎麼生出來？**不是廠商自己寫，也不是你自己寫，是雙方在需求訪談結束後一起確認。**這件事的最佳時機是規格確認階段，不是快要驗收的前一週。

而且我要提醒一件很多老闆會忽略的事：**這份清單裡一定要有「跨模組」的項目。**單一模組的功能通常沒什麼問題，出事的都是接縫——出貨單過帳之後應收有沒有產生、生產領料有沒有正確扣庫存、月結的時候各模組的數字對不對得起來。你的清單如果每一條都只驗一個模組，等於沒驗到最危險的地方。

另外，效能也該入列。寫法可以是「於甲方實際資料量下，主要交易畫面之開啟與存檔應於可接受之反應時間內完成」，然後在附件裡把「可接受」約定成一個雙方都同意的具體秒數。這個秒數我不能幫你定，因為每家的資料量與網路環境差太多，但你要爭取的是「有一個數字」，而不是沒有數字。

三、驗收失敗的補正期與次數上限：沒有這條，你會被無限期拖住

假設驗收沒過，然後呢？

大多數合約寫到這裡就沒了。頂多寫一句「乙方應儘速改善」。「儘速」是多久？沒人知道。

於是實務上會發生的事是：你提了二十個問題，廠商改了十二個，回來說可以複驗了。你再測，發現原本好的地方壞了三個，新的又冒出五個。再改一輪。這樣來回四五次，半年就過去了，而你的公司已經在用這套系統做生意，退不回去。

**驗收失敗的處理程序，一定要寫成一個有終點的迴圈。**至少包含四個要素：

**第一，缺失通知的形式與期限。**甲方應於驗收測試結束後幾個工作日內，以書面或約定的專案管理系統，列出缺失清單。這一條保護的其實是雙方——避免你事後一直加新的問題進來。

**第二，補正期。**乙方應於收到缺失清單後幾個工作日內完成改善並通知複驗。這個天數可以依缺失等級分級，例如把缺失分成「阻斷性」「重大」「一般」三級，阻斷性的補正期最短。

第三，複驗的範圍。這個很多人忘記寫：複驗不是只驗你改的那幾條，而是要回歸測試原本已通過的相關項目。不然你會遇到我上面說的「改 A 壞 B」的無限迴圈。

**第四，也是最關鍵的——補正次數上限，以及超過上限之後的效果。**寫法大致是：同一驗收循環經幾次補正後仍未通過，甲方得選擇（a）要求減價、（b）要求終止合約並返還已付款項之一定比例、（c）另定期限，逾期則如何處理。

注意，這裡我要誠實講：具體要退多少、怎麼計算、終止合約的法律效果如何，這牽涉到契約法上的細節，各家情況也不同，我不是律師，這部分請務必找律師確認。我的建議是，你至少要在合約裡留下一個出口，而不是讓「驗收未通過」變成一個沒有後果的狀態。因為沒有後果的條款，等於沒有條款。

四、付款節點綁驗收，不是綁時間

這條講起來只有一句話，但它是五條裡面實際效果最直接的。

看看你手上那份合約的付款條件，是哪一種寫法：

綁時間的寫法：簽約付百分之幾、一個月後付百分之幾、上線付百分之幾、三個月後付尾款。

綁交付的寫法：簽約付、規格確認書簽署後付、系統安裝完成後付、上線後付。

綁驗收的寫法：簽約付、規格確認書簽署後付、上線後付、驗收通過並簽署驗收證明書後付尾款。

第三種才是你要的。

差別在哪裡？前兩種寫法，時間到了或東西交了，錢就得付，不管東西能不能用。第三種，錢跟「能用」綁在一起。

而且尾款的比例很重要。**如果尾款只剩一個很小的比例，那你的驗收條款其實沒有牙齒。**廠商大可以算一算，這筆錢不要了、人撤走，你也拿他沒辦法。尾款要留到一個「廠商會捨不得」的比例——這個比例要多少我不會給你一個數字，因為那要看整體結構、專案規模與雙方談判籌碼，但原則是：尾款要大到讓廠商願意為它多留兩個月。

另外還有一個很多人漏掉的節點：年度維護費的起算日。有些合約寫「自系統上線日起算一年為保固期，保固期滿後開始收取年度維護費」，但如果保固從上線日算，你等於用保固期在吃導入期的尾巴，然後很快就要開始付維護費。**年度維護費應該接在保固期之後，而保固期應該從驗收日起算。**這一串邏輯要通，你才不會多付一段。

想把整體付款結構跟成本一起算清楚的話，可以參考ERP 導入成本怎麼算，把授權、人天、維護費放在同一張時間軸上看，付款節點該切在哪裡會清楚很多。

五、保固從驗收通過日起算，不是從安裝日或簽約日

前面已經講過為什麼，這裡補充實務上該怎麼寫，以及該一起約定的東西。

除了起算日，保固條款裡至少還要約定三件事：

保固範圍。要寫清楚保固涵蓋什麼：程式錯誤修正一定要有；那如果是你的需求變更呢？那當然是另計，這很合理。但中間有一塊灰色地帶——**「規格書上有寫、但實作出來跟預期不同」的東西，算 bug 還是算需求變更？**這一題如果沒有約定，會變成專案後期最常吵架的地方。建議的處理方式是：以規格確認書與驗收清單為準，凡是清單上有寫的，實作不符即屬保固範圍。

回應與修復時間。分級處理：系統全面無法使用是一級、主要功能無法使用是二級、次要問題是三級，每一級各自約定回應時間與預計修復時間。注意「回應」跟「修復」是兩件事，很多合約只寫回應時間，那等於只保證有人接電話。

保固期滿後的銜接。年度維護費的內容、漲幅上限、以及「如果我不續約，會發生什麼」。最後這一題超級重要：不續維護約，你的系統還能不能跑？資料能不能匯出？這已經進入離場條款的範圍，但它跟驗收與保固是同一串邏輯——你要確保任何一個環節談不攏的時候，你都還有路可以走。

爛寫法與好寫法：一張對照表看完差別

我把最常見的幾種寫法整理成一張表。你可以直接拿去比對手上那份合約。

條款	常見的爛寫法	你該爭取的好寫法
驗收標準	「系統功能正常運作，經甲方測試無誤」	「依附件一驗收項目清單，以甲方真實資料於正式環境完整執行約定之營運循環，逐項判定」
驗收環境	未約定	「正式環境，或與正式環境同等規格之測試環境，並使用甲方實際資料」
驗收期間	「上線後七日」	「上線後至少涵蓋一個完整月結週期，實際天數詳如專案時程表」
驗收失敗	「乙方應儘速改善」	「甲方於幾個工作日內提出書面缺失清單，乙方於幾個工作日內補正並通知複驗，複驗含回歸測試；同一循環補正逾約定次數仍未通過者，甲方得依約定行使權利」
默示驗收	「甲方未於七日內提出異議，視為驗收通過」	「甲方未於約定期間內提出書面異議且乙方已完成書面催告者，就『已完成測試且無異議之項目』視為通過；未及測試之項目不在此限」
付款節點	「上線後三十日內付清尾款」	「驗收通過並經雙方簽署驗收證明書後幾日內付清尾款」
尾款比例	小到廠商放棄也不痛	留到足以支撐驗收談判的比例，並與驗收證明書綁定
保固起算	「自簽約日／安裝日／上線日起算」	「自驗收通過日起算」
保固範圍	「程式錯誤之修正」	「規格確認書與驗收清單所載功能之實作不符，均屬保固範圍；需求變更另行議定」
修復時效	「乙方應於接獲通知後儘速處理」	依缺失等級分別約定「回應時間」與「修復時間」兩個數字

這張表你不用全部拿去談。**挑三到四條你最在意的，其他的就算對方不改，你也知道自己的風險在哪裡。**知道風險在哪，跟不知道，是完全不同的兩件事。

那句最危險的話：「甲方未於七日內提出異議，視為驗收通過」

這種條款叫默示驗收條款，幾乎每一份廠商版的合約裡都有。我先說結論：這一條不是不能接受，但幾乎不能照原樣接受。

先講廠商為什麼要這一條，這很合理：怕遇到不簽名的客戶。有些客戶就是拖著不驗收，東西明明能用，就是不簽、不付尾款。廠商需要一個機制讓專案能結案。從這個角度看，默示驗收條款是保護乙方的正當設計。

問題出在「七日」跟「未提出異議」這兩個部分。

七日的問題：七天能測完一套 ERP 嗎？如果你的驗收標準是「跑完一個完整營運循環」，那七天根本跑不完一次月結。這個天數跟驗收標準本身是矛盾的。

「未提出異議」的問題：異議要用什麼形式提？口頭在會議上講算不算？Line 群組裡回一句「這個怪怪的」算不算？如果沒約定形式，事後雙方會各說各話。

還有一個更隱形的問題：**如果測試根本還沒開始，時鐘就開始跑了怎麼辦？**比如廠商說「系統已於某日交付」，然後七天默默過去，你根本還在忙月底出貨，等你回頭要測，對方說已經視為驗收通過了。

所以這一條該怎麼談？我的建議是三個方向：

**第一，把天數拉長，並且跟驗收標準對齊。**如果驗收要跑完一個月結，那期間就不可能是七天。你可以說：「我不是要拿掉這一條，我是要讓這一條跟前面的驗收標準邏輯一致。」這個說法通常過得去。

**第二，把「起算點」寫清楚。**期間應該從「乙方書面通知驗收測試開始，且甲方確認測試環境與資料已就緒」那一天起算，而不是從交付日或安裝日起算。

**第三，加上「書面催告」與「範圍限縮」。**書面催告的意思是：期間快到之前，乙方要先發一次書面通知提醒；範圍限縮的意思是：視為通過的只限於「已完成測試且未提出異議的項目」，還沒測到的項目不自動通過。

**這裡我要再誠實提醒一次：默示驗收條款在實務上的效力如何、法院怎麼看，這屬於契約法的專業判斷，我不是律師也不會給你法條，這部分請找律師確認。**我能給你的是談判的方向，不是法律意見。

但有一件事我可以肯定：**當你把上面三個方向講出來的時候，對方的反應會告訴你很多事。**願意調整的，通常是有信心自己交得出來的；一句「我們公司的標準合約不能改」就擋回來的，你心裡要有數。

中小企業沒有法務，老闆自己可以做的三件事

我知道看到這裡，很多老闆心裡在想：「講得都對，但我公司連人資都是會計兼的，哪來的法務？」

這是實話，所以我給你三件不需要法務就能做、而且效果最大的事。

第一件：把「規格確認書」跟「驗收清單」變成合約附件

這是我認為投報率最高的一件事，而且完全不需要法律專業。

做法很簡單：在需求訪談跟規格確認的階段，你本來就會產出一堆文件——需求清單、流程圖、報表格式、欄位定義。你要做的只是要求把這些文件掛成合約附件，並在合約本文寫上「驗收標準以附件 X 為準」。

為什麼這件事這麼重要？因為 ERP 專案的爭議，絕大多數不是法律爭議，是**「當初到底講好要做什麼」的事實爭議**。而事實爭議的勝負，取決於誰手上有白紙黑字。

沒有附件的合約，吵起來就是各說各話。有附件的合約，吵起來就是翻頁對照。

順便提醒：如果你的專案有客製化的部分，這件事的重要性再乘以三。客製需求最容易在後期變成「這不在原本範圍內」，而唯一能擋住這句話的就是當初的規格文件。這一塊的坑我在ERP 要不要客製化裡講過，簽約前值得先看一遍。

第二件：自己畫一張時間軸，把三個日期跟付款節點標上去

拿一張 A4 紙，橫著畫一條線。從簽約開始，把這些點標上去：

簽約日 → 規格確認 → 系統建置 → 教育訓練 → 上線日 → 驗證期 → 驗收日 → 保固期 → 保固期滿 → 年度維護費開始

然後在每一個點下面寫：這一天我要付多少錢？這一天有什麼東西該交付？

畫完之後，你會立刻看到問題。最常見的是三種：付款節點全部集中在前半段；驗收日根本沒有出現在時間軸上；保固期的起點畫在上線日而不是驗收日。

**這張圖你自己畫十五分鐘，抵得過看三遍合約。**因為合約是用文字寫的，文字會讓你看不見結構；畫成圖，結構就跑出來了。

畫完之後你還可以拿這張圖去跟廠商對——「我理解的是這樣，你確認一下對不對？」這句話問出去，很多隱藏的假設會當場浮出來。

第三件：把最關鍵的三到五句話，花錢請律師看一次

不需要請律師審整份合約，那個費用對中小企業來說負擔比較重，而且律師不懂 ERP，他看整份合約也未必抓得到重點。

比較有效率的做法是：你自己（或用這篇文章當檢查表）先把合約裡最關鍵的那幾條圈出來——驗收標準、驗收失敗的處理、付款節點、保固起算、默示驗收、離場條款——然後帶著這幾條去問律師。

你問的問題也要具體。不要問「這份合約有沒有問題」，要問「這一條如果將來發生爭議，對我方是有利還是不利？有沒有更安全的寫法？」

這樣做，律師的時間花在刀口上，你的費用也控制得住。**我不是律師，這篇文章給你的是實務上的談判方向與檢查點，真正的法律效果請務必由律師確認。**這件事我要講清楚，不然就變成我在越界。

誠實講一句：願意把驗收條款寫細的廠商，其實是在證明自己不怕被驗

這一段我本來猶豫要不要寫，因為它對我這一行不完全有利。但我還是要寫。

當你把上面五條拿去跟廠商談的時候，你會遇到兩種反應。

第一種反應是防衛。「這樣寫我們風險太大」「我們的標準合約不能改」「沒有客戶這樣要求過」「你這樣寫我們專案永遠結不了案」。

第二種反應是討論。「這一條我理解你的顧慮，但七天太短我同意，我們改成一個月結週期；不過補正次數上限我希望從三次改成四次，因為有些缺失要等你們的資料補齊才能改。」

第二種反應才是你要找的廠商。

原因很簡單：一個真的做得起來的廠商，他心裡對「這個案子會不會過」是有底的。他知道自己的系統能跑、知道自己的顧問有經驗、知道這個規模的專案大概會遇到什麼問題。所以驗收條款寫細，對他來說不是威脅，而是把遊戲規則講清楚——甚至對他有利，因為清楚的規則可以擋掉客戶無限追加需求。

反過來，一個對交付沒把握的廠商，最怕的就是明確的標準。因為明確的標準會讓「差不多可以了吧」這句話失效。

所以我常跟老闆講：**驗收條款不只是保護你的工具，它也是一個篩選器。**你在簽約前把這五條丟出去，對方的反應會比任何一份簡報、任何一場 demo 都更誠實地告訴你，這家廠商到底行不行。

而且我要講一句對自己這行不太有利的話：**如果一家廠商連「用你的真實資料跑完一個營運循環才算驗收」這種要求都不敢答應，那這個案子你不簽也罷。**省下來的不只是錢，是你未來一年的睡眠。

至於怎麼在簽約之前就先分辨廠商的體質，除了看驗收條款的反應，還有幾個更早期的訊號可以觀察，我整理在ERP 廠商怎麼選那篇裡，跟這篇合起來看，你在簽約桌上會踏實很多。

常見問題

ERP 驗收條款一定要請律師寫嗎？自己寫可以嗎？

驗收條款的內容你自己最懂，因為只有你知道你們公司的營運循環長什麼樣、哪些流程不能斷、哪些報表是老闆每天要看的。這部分自己寫、或跟廠商一起列，反而比律師寫得準。

但條款的法律效果——例如驗收未通過時可以主張什麼、終止合約的條件與後果、默示驗收條款的效力——這部分建議請律師確認。比較實際的做法是：你先把驗收標準、驗收清單、失敗處理流程這些「業務內容」寫出來，再把最關鍵的三到五條帶去請律師看，費用可控，效果也最好。不要反過來——律師不熟 ERP，他無法幫你判斷「跑完一個營運循環」在你們公司具體代表什麼。

上線日跟驗收日一定要分開嗎？分開廠商會不會不同意？

一定要分開，而且這件事比你想的好談。上線是系統開始在真實環境運作，驗收是確認它運作得對——這兩件事之間本來就需要一段觀察期，尤其 ERP 的很多問題要等到月結才會現形。

廠商會不會同意？多數會，但他們會關心兩件事：這段期間會不會被無限拉長、以及這段期間的問題算不算保固內。你可以主動處理這兩個疑慮：把驗證期的長度明確寫出來（例如涵蓋一個完整月結週期），並約定驗證期內的缺失依驗收流程處理、不佔用保固期。把話講在前面，對方通常不會為這件事翻臉。

驗收清單應該由誰來寫？廠商給的範本可以直接用嗎？

清單應該由雙方共同確認，但主導權要在你這邊。廠商提供的驗收範本我看過不少，多半的問題不是造假，而是寫得太模組化——一條一條列功能是否可正常操作，卻很少涵蓋跨模組的接縫與月結的整體性驗證，而那才是最容易出事的地方。

比較好的做法是：請廠商先給範本當底稿，然後你找公司裡最熟流程的那幾個人——通常是資深倉管、會計、生管——逐條加上「我們公司真的會遇到的狀況」。例如急單插隊、退貨換貨、跨月調整、多倉調撥。這些情境加進去，這份清單才是為你的公司寫的，而不是為一般公司寫的。

「未於七日內提出異議視為驗收通過」這條可以要求刪掉嗎？

可以要求，但我建議不要以「刪掉」為目標，因為這條對廠商有正當的保護作用，硬要刪很容易讓談判卡住。比較務實的做法是修而不是刪：把天數拉長到跟你的驗收標準一致、把起算點改成「測試環境與資料就緒且乙方書面通知測試開始」之日、加上一道書面催告程序、並且把「視為通過」的範圍限縮在已完成測試而未提出異議的項目。

這樣改完，這條對廠商仍然有防拖延的效果，對你也不再是陷阱。至於這樣的修改在法律上的實際效力如何，建議請律師確認後再定稿。

尾款要留多少才有保障？有沒有一個標準比例？

我不會給你一個比例數字，因為專案規模、模組數量、客製比重、廠商規模都會影響合理的付款結構，任何一個數字丟給你都只會變成錯的錨點。

但判斷原則可以給你：**尾款要大到讓廠商願意為它多留兩個月。**你可以用這個角度反推——如果專案進行到最後，廠商放棄尾款直接撤場，他的損失能不能痛到讓他選擇留下來把問題解決？如果答案是不會，那尾款就太少了。另外提醒一個常被忽略的細節：尾款要綁在「驗收證明書簽署後」，而不是「上線後幾日內」。比例再高，如果綁的是時間而不是驗收，一樣沒有牙齒。

最後：合約簽下去之前，你只有這一次機會

驗收條款有一個很殘酷的特性：它只在簽約前有議價空間，簽下去之後就完全沒有了。

報價可以事後再談折扣，模組可以之後再加購，人天不夠可以追加。只有驗收條款，一旦簽了，你就活在那份文字裡面，直到專案結束。

所以簽名之前，花兩個小時把這五條看過、圈出來、跟廠商談一輪，是我認為整個 ERP 專案裡投報率最高的兩個小時。談成了，你省下的是未來半年的爭執；談不成，至少你在簽名的時候知道自己承擔了什麼。

知情地承擔風險，跟不知情地踩進去，是完全不同的兩件事。

如果你剛好卡在這裡——手上有一份合約、看得懂中文但看不懂哪裡有陷阱、廠商在催你這週要簽——可以先把驗收與付款那幾條抓出來，對照這篇的檢查表跑一遍。真的還是不確定的地方，歡迎把你的情況丟過來，我用帶團隊做過這麼多案子的經驗，幫你看一眼哪幾條非改不可、哪幾條其實可以放。不用你先決定要不要用我們的系統，這件事跟賣不賣東西沒有關係——因為老闆在合約上少踩一個坑，這個產業就少一個「ERP 都是騙人的」的故事。