內容目錄
顯示
Purchase Order（PO，採購單／採購訂單）是買方向供應商發出的訂購文件，用來確認品項、數量、價格、交期、交貨與付款條件。PO 已寄出，不代表供應商已接受全部內容。
真正容易出錯的，是業務以為訂單已確認，供應商卻仍在議價，財務又拿到舊價格。把「哪個版本、由誰接受、接受哪些條件」記清楚，才能讓備料、出貨與付款使用同一份依據。
以下說明 PO 欄位、回覆與變更管理。特定交易是否成立契約、能否取消及責任歸屬，仍須連同主契約、準據法與實際往來判斷。
Purchase order 是什麼？與其他文件差在哪裡？
PO 的工作角色，是把買方核准的訂購需求轉成可向供應商發出的交易紀錄。它通常列出買賣雙方、品項、規格、數量、價格、日期、交貨、付款與文件要求，也能成為後續收貨和發票核對的基準之一。
但「PO」並不是一個放諸所有國家與交易都相同的法律標籤。依台灣民法第 153 條，契約成立的核心是雙方意思表示一致，可以是明示，也可能是默示。特定 PO 是要約、承諾、既有契約下的叫貨單，還是尚待供應商確認的訂單，必須連同內容、前置文件、主契約、雙方回覆及適用法律一起判斷。
幾種常見文件可先這樣分：
| 文件 | 通常由誰發出 | 核心用途 |
|---|---|---|
| 請購單（Purchase requisition） | 買方內部需求單位 | 提出內部採購需求與核准 |
| RFQ | 買方向供應商 | 邀請供應商報價 |
| 報價單／形式發票（Quotation／Proforma invoice） | 通常由賣方 | 提供交易前價格與商業條件 |
| Purchase order | 買方 | 向供應商提出具體訂購內容 |
| 商業發票（Commercial invoice） | 賣方 | 請款及商業／通關文件 |
實際名稱可能因產業、公司制度與交易安排而異。比起只看標題，更重要的是文件由誰發出、內容是什麼、是否要求接受，以及條款之間如何排序。
一張可執行的 PO，要把哪些欄位寫清楚？
PO 沒有一套適用所有公司的法定版型，但以下九群資料若缺漏，很容易造成報價、交期、交貨或付款爭議。
| 欄位群 | 建議內容 | 常見錯誤 |
|---|---|---|
| 文件識別 | 採購單編號（PO number）、版次（revision）、發行日、狀態、生效條件 | 新版沿用舊檔名，收件人無法辨識版本 |
| 交易雙方 | 買賣方法定名稱、地址、統編／稅籍資訊、聯絡人、供應商編號 | 使用品牌名而非法定主體；帳單對象（Bill-to）、收貨對象（Ship-to） 混淆 |
| 引用文件 | Quotation／PI／主契約號碼與日期 | 引用多份價格不同的報價，未寫優先順序 |
| 品項 | 買賣雙方料號、品名、規格、圖號／版次、品質或驗收要求 | 只寫簡稱，無法判斷實際版本 |
| 數量 | 數量、計量單位（UOM）、允收差異、分批安排 | PCS、SET、KG 等單位不一致 |
| 價格 | 單價、幣別、折扣、稅費、運費、其他費用與總額 | 單價幣別與總額幣別不同；未寫費用是否內含 |
| 交期與交貨 | Ship date 或 arrival／delivery date、交貨地、分批、Incoterms® | 只寫一個日期，不知道是出貨還是到貨；只寫 FOB／CIF 無地點與年份 |
| 包裝與文件 | 包裝、標示、嘜頭（shipping marks）、packing list、invoice、產地或檢驗文件等 | 文件名稱、份數、語言或簽發人不明 |
| 付款、條款與接受 | 付款方法、起算事件、期限、適用條款、優先順序、接受期限與方式 | 只寫 Net 30，未定義從哪一天起算；未指定誰可接受 |
日期不要只寫「交期」
「2026/08/15」可能是工廠出貨日、交給承運人的日期、預計船期，或買方倉庫到貨日。PO 應使用雙方理解一致的名稱，必要時分列：
- Requested ship date：買方要求出貨的日期。
- Promised ship date：供應商承諾出貨的日期。
- Required delivery date：要求抵達指定地點的日期。
若運輸時間不穩定，還要避免把估計到貨日誤當供應商可完全控制的承諾。
Incoterms® 要寫規則、地點與版本
ICC 建議的引用結構是：
[所選 Incoterms® 規則] [指定地點、港口或精確點] Incoterms® 2020
例如：FCA Seller’s Warehouse, 100 Example Road, Taoyuan, Taiwan, Incoterms® 2020。
這只是格式示例，不表示 FCA 適合每筆交易。PO 還是要另列付款、品質、所有權、準據法與爭議處理等事項，因為 Incoterms® 主要分配貨物交付相關的任務、成本與風險，不能替代完整買賣契約。
付款條件要有起算點
只寫 T/T 30 days 或 Net 30，可能不知道從 invoice date、出貨、提單、收貨、驗收，還是完整文件收到後起算。付款欄應把起算事件、期限、幣別、付款方法、費用負擔與所需文件寫在同一邏輯下。
銀行帳戶若有變更，不能只依來信附件更新。應依公司反詐與供應商主檔程序，使用既有可信聯絡方式獨立核實。
PO 發出後，怎麼確認供應商真的接受？
最實用的做法，是把「公司內部已核准」和「供應商已接受」拆成不同狀態。
| 狀態 | 代表意思 | 判讀提醒 |
|---|---|---|
| Draft | PO 正在編製或核對 | 尚未取得內部授權 |
| Internally approved | 買方內部核准完成 | 供應商尚未收到或接受 |
| Issued | 指定版本已正式發送 | 不能自動推定供應商無條件接受 |
| Pending supplier response | 等待供應商回覆 | 不應進入無爭議的執行狀態 |
| Accepted | 供應商依約定方式接受指定版本 | 是否已成約仍須連同適用法及其他文件判斷 |
| Change proposed | 一方對內容提出修改 | 新條件尚待確認，不能直接取代有效版本 |
| Rejected／Cancelled | 訂單遭拒絕或依程序取消 | 不等於所有既有法律責任都自動消失 |
三種供應商回覆要分開處理
第一種是無條件接受。回覆應明示公司名稱、接受人、日期、PO number、revision，以及接受全部或哪些 品項／交貨排程。不要只收到一句沒有上下文的「OK」就結案。
第二種是拒絕。系統應保留拒絕日期、原因與回覆人，避免其他部門仍拿原 PO 安排後續工作。
第三種是附修改的回覆，例如「數量可以，但單價要調高」或「接受訂單，但交期延後兩週」。台灣民法第 160 條的一般原則是，將要約擴張、限制或作其他變更後承諾，視為拒絕原要約並提出新要約。
因此，作業上應把它標成 change proposed／exception，而不是 clean acceptance。
台灣民法第 161 條也指出，在依習慣或事件性質無須通知承諾的特定情況，可能因可認為承諾的事實而成立契約。這不表示「沉默一律等於接受」。為降低爭議，企業仍應約定清楚的 訂單確認（acknowledgment） 方法與期限，並保留供應商實際行為的紀錄，交由法律人員在爭議時判斷。
若主契約或 PO 明定必須簽回、由指定系統接受或完成特定程序，也要遵守雙方約定的方式。不要一方面要求正式接受，另一方面又讓電話口頭同意直接把系統改成 Accepted。
電子 PO 與 Email 回覆，要保留哪些證據？
2024 年修正的台灣《電子簽章法》規定，符合該法的電子文件與電子簽章，在功能上等同實體文件及簽章，不得只因電子形式否定其法律效力。法律也處理了電子文件的保存，以及發文、收文時間。
有相對人時，還要處理電子形式的同意或依法給予反對機會；電子文件內容須能完整呈現，並可日後取出查驗。數位簽章的特定推定效果另有法定條件，不能套用到每一封一般 Email。
不過，「電子形式可以有效」不等於「任何 Email 都已證明公司授權接受」。一封信至少還涉及：
- 寄件帳號是否真由該人控制。
- 該人是否有代表公司接受價格、日期或條款的權限。
- 附件是否為完整且未被替換的指定 revision。
- 文件送進哪個指定系統、何時送達、是否需要另行 acknowledgment。
- 雙方是否同意或依規則採用該電子方式。
建議保留下列稽核資料：
- 原始 PO 檔，不只留列印或截圖。
- PO number、revision、檔案 雜湊值（hash） 或其他完整性識別。
- 發件與收件帳號、完整郵件 標頭（header） 或系統 事件紀錄（event log）。
- 發送、收受與接受的日期、時間、時區。
- 簽署歷程、帳號身分、角色與授權依據。
- 供應商 acknowledgment 原文及所有附件。
- 被取代版本、變更差異與最終有效版本。
PO 要改價、改數量或改交期，怎麼改版？
最危險的做法，是打開已寄出的 PDF 或試算表直接改內容，再用同一個檔名寄出。這會讓買方、供應商、船務與財務各自認為手上的版本才是有效版本。
Oracle Procurement 的 change order 說明提供一個版本控制例子：變更核准與驗證期間仍保留目前核准版本，完成必要程序後才建立新版本。公司採用其他系統時，也應確認哪個版本仍有效、誰可核准變更。
這是平台流程示例，不是法定要求，但「保留原版、變更另行核准、確認後才取代」很適合作為內控原則。
五步變更管理
- 提出差異：記錄變更原因、提出人、時間，以及每個欄位的原值與新值。
- 重新內部核准：價格、數量、預算、交期、交貨或付款改變時，依授權矩陣重跑必要核准。
- 發送新 revision：新版本明示取代哪一版、哪些 line／schedule 受影響，以及何時生效。
- 供應商重新接受：要求供應商回覆精確的 PO number 與 revision；附帶新修改則再回到 change proposed。
- 更新單一有效來源：系統只把雙方確認的新版本標成 current，舊版標記 superseded 並保留；通知需要知道的角色。
一個常見情境
買方發出 PO-2026-017 Rev00，要求 8 月 15 日出貨。供應商回覆：「訂單接受，但最快 8 月 30 日出貨。」
這不應直接把 Rev00 改為 Accepted，因為交期已被修改。較穩健的流程是：
- 將供應商回覆記為 change proposed。
- 買方評估新交期對庫存、客戶與成本的影響。
- 核准後發出
Rev01，清楚列出出貨日由 8 月 15 日改為 8 月 30 日。 - 供應商再確認
PO-2026-017 Rev01。 - Rev01 成為 current，Rev00 留存且標記 superseded。
如果供應商之後又要求改價，就必須再提出新變更，不能在 Rev01 的 Email 對話串裡悄悄取代價格。
如何讓 PO 與後續文件維持一致？
PO 一旦被確認，就應成為後續文件比對的基準之一。Microsoft 的採購系統文件把 invoice matching 說明為比對供應商發票、PO 與收貨資訊；企業可依政策設定可容許的價格或數量差異。
可先建立以下一致性矩陣，讓收貨、船務與財務找到需要比對的欄位：
| 關鍵欄位 | 前置資料 | 已接受 PO／acknowledgment | 後續文件 | 控制重點 |
|---|---|---|---|---|
| PO number／revision | 不一定有 | 必須明確 | Invoice、packing list 等應可追溯 | 不能引用 superseded 版本 |
| 買賣方名稱 | Vendor master、quotation | 應用法定主體 | Invoice、運送文件 | 品牌名、分公司與法定主體不得混用 |
| 品項／規格 | Quotation、圖面 | 鎖定料號與版次 | Packing list、invoice | 變更料號要走 change control |
| 數量／UOM | 需求與報價 | 鎖定訂購量及單位 | 收貨、invoice | PCS／SET／KG 不可只比數字 |
| 價格／幣別 | Quotation／PI | 鎖定單價、費用與總額 | Invoice | 分清單價、行總額、稅費與運費 |
| 日期 | 需求與承諾 | 定義 ship／delivery date | Shipping instruction 等 | 不同日期不能共用「交期」欄 |
| Incoterms® | Quotation | 鎖定規則、精確地點、年份 | Invoice、shipping instruction | 三個元素需一致 |
| 包裝與標示 | 技術／物流要求 | 鎖定包裝、marks | Packing list、實物 | 特殊要求須能驗收 |
| 文件要求 | 客戶／法規／付款需求 | 鎖定名稱、份數、期限 | 實際提交文件 | 避免到出貨前才發現缺件 |
| 付款 | Quotation、主契約 | 鎖定起算點與期限 | Invoice／付款作業 | 依條款優先順序處理差異 |
「一致」不一定代表任何欄位都零差異。企業可以依交易風險設定 允許差異（tolerance），但應先定義哪些欄位不得改、哪些差異須重新核准，以及主契約、PO、供應商 acknowledgment 發生衝突時哪份文件優先。信用狀、稅務或管制文件另有嚴格要求時，也不能只套用一般採購容許值。
Purchase order 發送前 12 點檢查
- PO number、revision、日期與狀態唯一且清楚。
- 買賣方使用正確法定名稱，Bill-to 與 Ship-to 沒有混淆。
- 品項、料號、規格、圖面版次、數量與 UOM 可被供應商執行。
- 單價、幣別、折扣、稅費、運費與總額已重新計算。
- Ship date、delivery date、分批與容許差異定義清楚。
- Incoterms® 已寫規則、精確地點與
Incoterms® 2020。 - 包裝、標示、文件名稱、份數、語言、簽發人與期限已列明。
- 付款方法、起算事件、期限與所需文件一致。
- 主契約、quotation／PI、PO 條款的引用與優先順序明確。
- 買方核准人及供應商接受人都有適當授權。
- 接受期限、正式收件管道、時區及 acknowledgment 方式已約定。
- 銀行資料變更、附件與寄件帳號已走資安及獨立驗證。
把有效版本與接受紀錄一起保存
Purchase order 的價值，不只是把採購內容排成一張表，而是建立一份可追溯的共同版本。買方應先把品項、價格、交期、Incoterms®、付款與文件要求寫清楚，再讓供應商對精確的 PO number 與 revision 做出接受、拒絕或變更回覆。
只要條件有變，就保留原版、建立新版、重新核准與接受。這套紀律能降低「業務以為接受、供應商以為還在議價、財務又拿到舊價格」的落差。若要把本文轉成公司正式 PO 範本，下一步應由採購、業務、船務、財務、內控與法務共同確認授權矩陣、條款優先順序、系統狀態與保存政策。
參考來源
重點整理
PO 寄出就代表訂單成立嗎？
不能只憑寄出判斷。要合併主契約、PO 條款、供應商回覆、實際行為與適用法律確認；作業上應分開記錄已發送與已接受。
供應商回覆接受，但改了交期，怎麼處理？
先記為附條件或變更提案，確認新交期影響並重新核准，再發新版要求供應商確認，避免把原版當成無條件接受。
PO 改版後要刪掉舊版嗎？
不建議刪除。保留被取代版本、變更差異、核准與供應商確認紀錄，並明確標示目前有效版本。
電子 PO 或 Email 可以有效嗎？
電子形式本身不當然使文件無效，但仍須符合適用法規、電子方式的使用條件、文件完整性與代表權要求。一般 Email 也不當然享有特定數位簽章的推定效果。
