企業送禮計畫一旦同時涉及多個活動、供應商、倉庫、幣別與分批到貨，發票總額看似合理，也可能藏著明細重複、尚未驗收便請款、單價超出採購單，或後續折讓尚未扣抵等問題。這份範本把風險轉成逐筆可追蹤的待辦，供應付帳款、採購、倉儲、財務與送禮計畫負責人共同覆核。它是營運控制工具，不是總帳、稅務引擎，也不會自動授權付款。
下載 2026-09-17-v1 版本：企業送禮發票核對試算表 · 萬國碼逗號分隔示例檔。試算表包含七個工作表、公式、選單驗證與九個測試案例；逗號分隔檔只是差異清單示例，公式與跨表控制僅存在於試算表。
範本能處理什麼，以及刻意不處理什麼
工作簿把訂單、收貨、發票與折讓分開保存，再計算差異。這個結構很重要：同一筆採購明細可能有兩次收貨，一張發票也可能有多筆運費或折讓。如果先把所有紀錄攤平成一張表，一對多的關係容易把數量與金額重複相乘，最後得到看似精準、其實錯誤的總額。範本用不可變更的訂單明細鍵連接商業承諾，用發票鍵連接請款與折讓；收貨依訂單明細鍵累計，折讓依發票鍵累計，最後才在差異表整合受控的結果。
這個設計支援三項實際判斷。第一，辨識開票數量是否高於累計驗收數量。第二，計算開票單價相對於議定單價的延伸差額。第三，在商品金額、已覆核運費、已覆核稅額與已連結折讓分開呈現的前提下，計算淨開票額。即使商業數字一致，只要證據參照缺漏、幣別不符、開票數量為零，或發票鍵出現兩次，該列仍會維持待審或阻擋。
範本不會判斷收入或費用應在哪一期認列、稅額能否扣抵、是否需要扣繳、資本化方式或實際付款日期。這些問題取決於合約、當地規定、公司政策與正式會計系統。Oracle 的官方發票配對文件說明發票明細可能依採購排程或收貨紀錄進行配對；本範本則保持系統中立，不假裝取代企業資源規劃系統。它的角色是在具權限的人員於正式系統執行前，提供透明、可重現的暫存控制層。
正確的發票總額仍不足以證明可付款。真正的證據必須落在訂單條件、驗收數量、請款、折讓、幣別與文件可以逐筆對上的那一列。
當組織需要便攜的覆核層、試行控制或跨團隊共用的差異語言時，可以使用這份檔案。如果正式會計系統已經強制執行配對，就只把本表用於補充證據、跨供應商欄位標準化，或調查系統無法解釋的例外，不要藉此繞過既有控制。
先建立可靠識別鍵，再比較金額
最重要的欄位不是金額，而是能證明紀錄關係的識別鍵。實用的訂單明細鍵至少包含法人、供應商、採購單、訂單與明細識別碼；實用的發票鍵至少包含法人、供應商、發票號碼與發票明細。範本同時顯示兩種鍵，讓覆核人員能從任何計算結果回到原始資料。
法人必須納入鍵值，因為不同子公司可能遇到相同供應商與相同發票號碼。供應商識別碼應來自核准的供應商主檔，而不是會因標點、縮寫或語言改變的顯示名稱。採購單、訂單與明細識別碼要保留前導零，不應從商品描述重新拼湊。發票號碼若需要統一空格、標點或大小寫，規則應在來源匯出階段明確記錄，不可在覆核檔內悄悄改寫。
以下公開欄位模型是可使用的最低範圍。團隊可以增加活動、成本中心、收件批次、倉庫、追蹤或商品識別碼，但新增欄位不能取代不可變更的關係鍵。
圖表說明：逐筆核對企業送禮發票所需的最低資料字典。
| 欄位群組 | 必要欄位 | 控制目的 | 失敗時的處理 |
|---|---|---|---|
| 身分關係 | 法人、供應商、採購單、訂單、明細 | 建立穩定的訂單明細鍵 | 由來源負責人修復前維持待審 |
| 收貨 | 收貨識別碼、日期、驗收數量 | 區分已出貨與已驗收 | 請倉儲補上驗收證據 |
| 發票 | 發票號碼、明細、日期、幣別、數量、單價 | 定義請款義務與重複鍵 | 阻擋重複鍵並保留兩筆來源 |
| 附加費用 | 稅額與運費分列 | 避免不明費用藏在商品金額 | 分派給對應權責人覆核 |
| 折讓 | 折讓識別碼、連結發票鍵、正數金額 | 對原發票明細只扣除一次 | 未連結折讓不得進入可付款計算 |
| 證據 | 參照或長效連結、負責人、處置 | 解釋該列為何放行或阻擋 | 公式結果不能取代核准證據 |
證據參照可以指向收貨紀錄、交付證明、核准報價、發票影像、折讓單，或受控資料庫中的案件。避免使用會過期的個人連結。若隱私政策禁止在財務檔案放入收件人資料，只保留能定位授權紀錄的營運參照；姓名、住址、私人留言與非必要的追蹤細節不會改善發票配對，反而擴大風險。
載入當期資料前，先檢查識別欄位：統計空白、不同值與重複值；確認日期、數量與金額使用一致的資料型態；把法人與幣別對照核准清單。匯入成功不代表筆數很多，而是所有不確定性都有明確狀態。如果來源程序把空白數量自動轉成零，應先修正，因為「未知」與「沒有」需要不同的處置。
看懂公式、幣別邊界與狀態規則
數量差異等於開票數量減去累計驗收數量。正數表示請款走在驗收之前；負數可能代表漏掉發票明細、超額收貨，或兩個系統的時間點不同。正負方向都不會自動授權付款，覆核人員仍需依配送、驗收與合約證據判讀。
價格差異等於「開票單價減議定單價」乘以開票數量。公式只處理商品價格，不把稅額或運費混入單價。淨開票額等於開票數量乘以開票單價，再加上已覆核稅額、已覆核運費，最後減去連結到該發票明細的核准折讓。折讓表一律輸入正數，再由差異公式扣除一次；如果在來源先填負數，公式又執行減法，會反向增加應付金額。
下列邏輯刻意保守：必要識別碼、證據缺漏、開票數量為零或幣別不符，一律待審；發票鍵重複則阻擋；只有資料完整、未重複、幣別一致，且四捨五入後數量與價格差異皆為零的明細，才顯示可付款。
必要識別碼缺漏、證據缺漏或開票數量為零：待審
訂單幣別與發票幣別不同：待審
發票鍵出現超過一次：阻擋
數量差異或價格差異不為零：待審
其餘完整情況：可付款
幣別是分組邊界，不只是標籤。範本遇到幣別不符就待審，不會自行換算。如果合約允許跨幣別結算，組織應另外記錄核准匯率來源、匯率日期、精度、實現差額處理與核准人，並在正式系統執行會計處理。不要只因為試算表可以相加，就把美元、歐元、日圓或韓圜合併成一個營運總額。
四捨五入也要有明確規則。內建測試用議定單價 12.345、開票單價 12.346、數量三件，未四捨五入的延伸差額為 0.003；工作簿把價格差異取到小數點後兩位，因此顯示為零。這只是測試，不是普遍適用的重要性政策。財務應依幣別精度、合約、交易量與累計風險設定門檻；若加入門檻，必須同時顯示原始差異與套用門檻，才能保留可稽核性。
公式檢查必要但不足。本版本包含完全相符、分批到貨、兩筆重複、已連結折讓、數量為零、明細鍵缺漏、幣別不符與四捨五入等九個案例。所有案例重新計算後都符合預期狀態，且公式掃描沒有發現錯誤值。日後只要改動欄位或公式，就應重跑測試；每次在正式資料發現缺陷，也要新增一個回歸案例。
從來源匯出到簽核處置的完整流程
在匯入資料前先分工。採購負責商業條件與供應商主檔；倉儲或收貨團隊負責驗收證據；應付帳款負責發票身分、重複檢查與付款排程；計畫營運負責活動背景與履約差異；財務負責政策、門檻與最終付款動作。小型團隊可以由同一人兼任，但紀錄仍應說明當下履行的是哪一項責任。
-
鎖定覆核期間並記錄來源系統匯出時間。
-
匯出訂單、已驗收收貨、發票與折讓，不能刪除來源列。
-
依書面規則統一識別碼與日期；需要修復時保留原值。
-
將各來源載入獨立工作表，並把筆數與匯出檔核對。
-
重新計算工作簿、確認所有測試通過並掃描公式錯誤。
-
將每一筆非可付款差異分派給明確角色與期限。
-
附上長效證據參照，記錄處置，不覆蓋原始金額。
-
依法人與幣別把可付款金額與正式付款佇列核對。
-
依保存政策封存簽核版本、來源匯出與變更紀錄。
先檢查完整性。比較來源筆數、訂購總數、驗收總數、發票明細數與折讓數。這些總量不能取代逐筆配對，但能找出漏檔與壞掉的匯出。接著檢查唯一性。重複發票鍵可能是檔案重複匯入，也可能是折讓被錯當發票，或兩個法人在匯出時遺失法人欄位。在來源負責人解釋前，要保留兩筆紀錄。
差異的老化時間要與金額差異分開。某一列今天剛完成驗收，數量差異為零，但發票可能已經逾期三十日；另一張新發票也可能有重大數量差異。若需要管理服務時限，可以增加驗收日、發票日、到期日與差異開啟日。付款條件仍以合約與正式系統為準，不能在工作簿內自行改寫。
連接營運證據時，不要匯入不必要的收件人個資。活動識別碼、配送批次、倉庫收貨或受控證據代碼通常已足夠。管理庫存時，可參考企業禮品庫存再訂購點計算器理解預期補貨數量；驗收成套商品時，可搭配禮品組裝與品質控制指南建立證據。這些內容協助營運，但不會取代採購單或發票。
簽核時，依法人與幣別篩選。確認每筆可付款明細都有完整識別鍵、證據、負責人與最終處置；商品、稅額、運費、折讓與淨開票額分開加總；再與具權限的付款佇列比較，而非只看供應商對帳單總額。記錄覆核人與核准人。若公司要求職務分離，不應讓同一人修復來源後又在沒有獨立檢查的情況下核准付款。
推演案例一：只驗收六十件，卻收到一百件請款
假設一張採購單訂購一百個無品牌馬克杯，每個十二美元。收貨紀錄顯示六十個已通過檢查，供應商卻依一百個開票，商品單價正確，另列稅額與運費。此時數量差異為四十，尚未有驗收證據支持的商品金額為四百八十美元；稅額與運費仍需分開覆核。
可能原因很多：四十個仍在運送途中；商品已到貨但倉儲尚未入帳；商品未通過檢查；合約允許在實體驗收前依里程碑請款；或供應商誤開全額。範本不會替人選擇原因，因此保持待審，並把責任指向收貨與合約證據。
不理想的作法是因採購單總額一致就支付全額，讓之後追討完全依賴折讓；另一個錯誤作法是把驗收數量從六十改成一百，只為讓公式變綠，這會破壞收貨紀錄。較可靠的處理是保留發票、保留六十件驗收、分派四十件差異，向倉儲與供應商取得證據。
如果其餘四十件後來到貨並通過檢查，就以相同訂單明細鍵新增收貨列。累計驗收成為一百，數量差異歸零；但原先差異的處理歷程仍應保留。如果商品未到，就由商業負責人要求更正發票或折讓。不要創造一筆不存在的收貨來關閉案件。
運費可能在第一批出貨時一次請款，也可能要依批次分攤；稅務處理則可能因地區、商品、目的地與憑證形式而異。範本只呈現金額，不提供法律或稅務判斷。覆核人應連結實際合約與發票，再交由具權限的財務或稅務人員決定。
這個案例的驗收證據包括原採購單、完成分批時的兩筆收貨、檢查或驗收確認、供應商發票，以及支持更正金額的往來。只有在數量依真實合約解決、幣別一致、發票鍵唯一、證據完整，且核准人記錄處置後，該列才可進入付款程序。
推演案例二：折讓已到，但發票明細重複
再看一個假設案例：發票包含一千兩百美元商品、九十六美元稅額與三十美元運費；之後收到一百二十美元折讓，並清楚指向原發票明細。同時，匯入程序把同一份供應商檔案載入兩次，造成相同發票鍵出現兩列。這是兩個不同控制：折讓降低淨開票額，重複則阻擋兩列付款。
正確的折讓流程是在折讓表輸入正數一百二十，並連結原發票鍵。差異公式只扣除一次，淨開票額為一千二百零六美元。如果把折讓先填成負一百二十，再由公式扣除，就會反向增加成一千四百四十六美元。若折讓只連到供應商而沒有發票明細，還可能扣到錯誤義務，必須先修復連結。
重複次數依法人、供應商、發票號碼與明細計算。當次數大於一，兩列都顯示阻擋。覆核人不應立即刪掉其中一列，而要比較來源檔名、匯入時間、文件影像、正式系統識別碼與付款狀態。如果確定是同一來源載入兩次，要標記為匯入重複並修復流程；如果供應商真的用同一號碼開了兩份文件，應要求更正文檔，或從正式系統取得受控的區分識別碼。
只保留證據較完整的一列、刪掉另一列，雖然能讓總額好看，卻抹掉控制失敗的證據。較好的恢復方式是在封存來源中保留兩列，記錄重複判斷，再重新建立乾淨匯入。簽核版最後應只剩一筆有效發票、一筆連結折讓、重複次數為一，處置欄並引用修復案件。
這個案例說明折讓與重複不能合併成一個「淨差異」。數字可能偶然抵銷，但紀錄仍不安全。覆核人需要分開看到商品、稅額、運費、折讓、重複次數、證據與處置。能說明的明細，比單一綠色總額更有價值。
月結控制、故障分流與恢復方法
月結要區分資料故障與商業差異。資料故障是匯出不完整、識別鍵缺漏、公式損壞或格式改變；商業差異則是有效資料顯示未驗收數量、未核准運費等實際不一致。先修復資料故障，再處理商業差異，不能用受污染的資料去和供應商談判。
控制紀錄至少應包含來源系統、匯出時間、筆數、可取得時的雜湊、工作簿版本與覆核人。供應商若換發發票，要保留舊文件並連結新文件。折讓若在關帳後才到，應在下一個受控版本加入，並記錄財務是否需要做應計或其他會計處理；本文不替財務作決定。
發票先到、收貨後到，該怎麼辦？
在合約與證據尚未支持付款前，保持待審。後續收貨用相同訂單明細鍵新增，重新計算累計驗收，並保留早期差異歷程。如果政策允許先付款，應把政策與核准文件列為證據，而不是修改收貨數量。
訂單與發票使用不同幣別，該怎麼辦？
不要悄悄換算。先確認合約允許跨幣別結算，記錄核准匯率來源與日期，再於正式系統完成會計處理。基本範本刻意顯示待審，避免匯率風險被公式藏起來。
一張發票涵蓋多個活動或倉庫，該怎麼辦？
把發票拆成穩定明細，增加活動或倉庫參照，逐列連接對應訂單與驗收。共同運費只能依書面規則分攤，且原始運費必須保留，讓分攤總額可以回到發票。
持續觀察重複原因。供應商若常漏填採購單號，就修正導入與請款指示；分批收貨若經常延遲入帳，就改善倉儲作業；重複匯入若反覆發生，就建立防重與來源檔控制；稅額或運費若長期占多數差異，就釐清採購單欄位與合約。核對檔應推動上游改善，不應永久成為人工補洞工具。
依版本封存。本版是 2026-09-17-v1。公式或欄位模型若有重大變更，應建立新版本、重跑測試、保存新雜湊與變更說明，不可覆蓋已簽核檔。至少每季檢查一次；確認公式缺陷、來源系統移轉、幣別規則或付款流程改變時，立即更新。
可接受的完成證據很具體：所有預期來源都在、筆數核對、必要鍵與幣別完整、公式沒有錯誤值、測試通過、每個差異都有負責人、每個可付款列都有證據與最終處置、總額依法人與幣別覆核，且付款在受權程序完成。少一項都只能算進度，不能算完成。
建立欄位對應表，避免來源變更破壞控制
每個來源系統都可能用不同名稱表達相同概念，例如採購單號、外部訂單號、供應商訂單號或活動訂單號。導入時應建立一份受控的欄位對應表，逐一記錄來源欄位、目標欄位、資料型態、是否必要、清理規則與負責人。對應表本身也要有版本；來源系統改版後，先用小批資料驗證，不要直接把整月資料灌入舊公式。
識別碼要當文字處理，避免試算表把前導零刪除、把長數字轉成科學記號，或把看似日期的字串自動改成日期。日期則要記錄時區與截止原則；若倉庫在當地午夜後入帳，但財務以總部時區關帳，兩邊可能把同一收貨放在不同期間。範本不替公司選擇時區，但要求把選擇寫清楚，才能解釋期間差異。
數量欄位也需要單位。供應商可能以箱請款，採購單卻以件計價；禮盒可能包含多個組件，而收貨只記完整套數。未先統一單位就比較數字，會產生大量假差異。應在來源清理階段保留原單位、換算因子與換算後數量，並要求採購確認換算依據。換算因子空白時維持待審，不能預設一箱等於一件。
設計可執行的審查節奏
日常審查可以先處理高風險例外，再處理一般時間差。優先順序可考慮重複發票鍵、幣別不符、缺少法人、金額超過核准門檻、折讓未連結、數量差異，以及單純等待後續收貨。這個順序不是付款決定，而是讓有限人力先處理最可能造成重複付款或錯誤法人付款的項目。每項例外都要有明確到期日與升級路徑，不能只寫「待確認」。
週期結束前，應付帳款可以與採購、倉儲和計畫營運進行短時間的例外會議。會議不是逐列重新計算，而是確認資料故障是否修復、商業差異由誰取得證據、哪些項目需要供應商更正，以及哪些決定必須交給財務或法務。會後更新處置與證據參照，不要把討論內容藏在私人訊息中。
管理報表應分開呈現「待審列數」、「阻擋列數」、「涉及金額」、「最久未解天數」與「重複原因」。單看總金額可能忽略大量小額重複，單看列數則可能忽略一筆重大錯誤。依法人、供應商、差異類型與負責人切分，才能知道問題發生在哪個流程，而不是只知道月底還有多少工作。
用失敗案例驗證恢復能力
除了正常資料，還應定期故意放入缺少明細鍵、幣別不符、重複發票、零數量、未連結折讓與公式遭改動等案例，確認工作簿不會把它們誤判為可付款。若新增欄位或調整欄順序，測試頁仍必須全部通過。測試失敗時要停止使用該版本，保存錯誤畫面與受影響範圍，修復後建立新版本，再用原案例與新增回歸案例驗證。
如果已經用錯誤版本完成付款，不應只修正試算表。應先識別受影響期間與供應商，重新執行核對，確認是否出現重複付款、漏扣折讓或幣別錯置，再依公司的事故與追回流程處理。技術修復、財務修正與供應商溝通是三條不同工作線，都要留下責任人與完成證據。
最後要驗證封存是否真的可用。從封存位置抽取一個已完成月份，確認來源檔、工作簿、證據參照、核准紀錄與變更說明都能由未參與原作業的人重新開啟。若連結已失效、權限只屬於離職人員，或處置只寫在聊天訊息中，當期即使完成付款，也不能算具備可靠稽核軌跡。修復方式是把證據移入受控儲存位置、更新權限與保存期限，並在封存索引記錄新的長效參照；不可改寫原始金額或刪除早期版本來掩蓋缺口。
抽查時還應重新計算一筆可付款、一筆待審與一筆阻擋案例，核對當時版本的公式、輸入與處置是否一致。這項動作能及早發現檔案損壞、公式被覆寫或保存規則失效，也讓新進人員理解控制不是只看顏色，而是依證據作出可重現的判斷。
把核對變成可持續的營運控制
好的發票核對不以「每一列都變綠」為目標，而是讓不確定性清楚可見、交給正確負責人，並保留足以讓另一位覆核者重現判斷的證據。來源表分離可避免一對多關係灌大總額；穩定識別鍵讓重複與連結檢查可行；保守公式則把空白、零數量、幣別不符與未解差異排除在可付款範圍之外。
可以分階段導入。先選一個供應商與一個月份，將範本產生的差異與既有應付帳款流程比較，找出誤報與缺少的控制。接著確立角色、證據標準、四捨五入與重要性政策。只有在人工邏輯被理解後，才自動化來源匯出。最後觀察重複差異的原因，修復上游流程。
成效不在於公式數量或清單清得多快，而在於組織能否解釋每個可付款明細、避免重複付款、保留有效折讓、尊重幣別邊界，並證明誰看過證據。工作簿提供共用且可檢查的起點，正式會計系統與具權限的人員仍負責真正的會計與付款決策。
若組織透過 Giftpack執行全球送禮、品牌商品、獎勵與履約，這套核對模型可作為下游財務營運控制：匯出穩定的營運參照，與採購及驗收證據對齊，並在付款前分流差異。Giftpack 是執行層，不會取代採購、會計、稅務、法務或雇主判斷。