供應商通知更改收款戶口，中小企付款前應如何核實？

為何要先暫停付款

改戶口通知可能夾在一段看似正常的採購對話中：貨確實收到、發票資料與舊紀錄相符、寄件人名稱亦沒有異樣。然而，這些線索只能說明交易背景似乎合理，不能證明新戶口屬於原供應商。香港警方曾說明一種騙案：騙徒掌握商業電郵內容後冒充賣方，要求買方改往另一戶口付款，買方與真正賣方通話後才發現受騙。因此，發票是否應付與收款目的地是否可信，必須分開判斷。

實務上，可規定新增收款人或更改帳號時，所有受影響付款先標記為待核實。即使發票已逾期、經理轉寄來信催促，也應安排盡快核對，而不是跳過程序。原發票仍留在應付帳目清單，註明暫停原因、負責人及到期日，避免真正供應商無故失去款項。若同一供應商有多張待付發票，須逐張標出受影響項目；只暫停最新一張，舊發票仍可能經已被改動的供應商主檔付款。

觸發條件不應只限於「新銀行」。分行、帳號、收款人名稱或付款方式有變，都應列作收款資料變更；聲稱舊戶口暫時不能使用，也是同一類要求。不要叫員工單靠錯字或版面判斷真偽。真正供應商也可能打錯字，騙徒亦可能複製簽名和舊電郵內容。清楚的觸發規則，讓同事按證據處理，不必憑感覺決定哪封信可疑。

用獨立渠道核實

核實的重點是使用變更要求出現前已可信的聯絡資料。可從既有合約、早已核實的供應商通訊錄，或獨立保存的採購紀錄找電話。不要致電來信、附件或該串電郵回覆中提供的新號碼；若電郵被騙徒控制，這些資料可能一樣被改過。警方建議付款前以電話、傳真或其他方式確認對方身份；香港網絡安全事故協調中心亦提醒，騙徒會冒充商業夥伴要求轉帳至新戶口。對小公司而言，致電原有聯絡人並留下紀錄，往往是可行的起點。

致電時，應請原有聯絡人確認是否真的提出更改、由誰授權、完整收款人名稱與帳號，以及適用哪些發票。逐項讀回擬更新資料，比籠統問一句「係咪改戶口」更有用。如原聯絡人無法確認，應從供應商內部另一個獨立來源找授權人，不可讓來信者自行指定唯一核實者。若供應商慣常提供正式通知書，可作輔助證據；但若通知書只附在可能被入侵的電郵串中，仍不能取代獨立查證。記下聯絡資料來源、通話日期、接聽者及結果，同時避免保存不必要個人資料。

人手足夠時，可把收件、核實及批准分給不同同事：一人收集要求，一人沿原有渠道查證，授權主管閱讀紀錄後批准改主檔。小公司未必有三名財務員工，至少應安排第二人核對原要求、獨立聯絡資料來源和完整帳號，才批准付款檔。分工是為了攔截單一人員的誤判或倉促放行。若有緊急例外，應預先寫明誰可決定，以及哪些基本證據仍不可省；沒有紀錄的例外，很容易變成繞過核實的慣常方法。

讓主檔與付款指示一致

一份可追查的變更紀錄，應連結供應商身份、舊與新收款資料、要求來源、相關發票、獨立核實結果、批准者及生效時間。舊戶口應保留於歷史紀錄，不宜被無痕覆蓋。應付帳目畫面要清楚顯示待核實、拒絕或已批准。只有已批准資料才能進入銀行付款檔。放行前，核對付款檔的收款人及帳號是否與批准紀錄相同，而不是只對照發票 PDF。若系統會自動從發票抽取戶口資料，變更關口尤其需要人手覆核；自動化不應把未核實附件直接變成供應商主檔。

例如一間包裝供應商已送貨，財務部收到一張示例金額為港幣四萬八千元的發票；來信稱戶口已改，要求即日付款。財務同事先把該張及同一供應商其他待付發票標記暫停，從最初開戶文件找電話致電原聯絡人。對方說戶口沒有更改。公司便不更新收款人，也不向來信所列戶口付款，並記錄矛盾，再循原渠道處理發票。這個金額純屬示例，並非真實損失或法定核查門檻；較小的轉帳同樣要核實。

再改變情境：原聯絡人確認確有新戶口，但只適用於某日期後開出的發票。這不代表所有未付舊發票都可轉到新戶口。財務部應記下適用範圍，問清既有發票應按哪個戶口付款，並由授權主管批准逐項對應。如戶口持有人名稱、適用日期或發票範圍仍有疑問，就繼續暫停，待供應商解釋後才更新。核實過一次通話，不等於可擴大對方實際確認的內容。

演練流程及處理誤轉

正式依賴流程前，可用無害的測試要求演練。請同事提交一份看似合理但帶新戶口的通知，檢查發票會否暫停、核實者會否選用舊通訊錄、改動後能否查到批准歷史，以及另一張待付發票是否一樣受控。再試一次由電話或訊息程式提出的要求，確保不同渠道適用同一規則。定期翻查已批准與已拒絕變更，尤其是跳過正常次序的個案。演練能驗證流程有否運作，但不應宣稱可識破所有騙案。

如款項已匯往可疑戶口，不可只把主檔改回便當作結案。應帶付款參考資料立即聯絡銀行，查問可採取的措施。香港網絡安全事故協調中心建議涉及財務損失時盡快聯絡銀行，並向警方報案。保留原始電郵、付款指示、核實紀錄及改戶口日誌，循原渠道通知真正供應商，並檢查郵箱或轉寄規則有否遭入侵。確認收款目的地前，暫停進一步付款。把事發時間線寫清楚，才可找出流程缺口；不可假設銀行一定能追回款項。

老闆下一步可先列出供應商戶口資料會從哪些渠道進入公司，為每個活躍供應商指定一個獨立聯絡資料來源，並確保改收款目的地會在付款批准前顯示。然後完整演練一宗由收件至銀行檔放行的個案。技術團隊可協助設定暫停、保留舊值及把批准紀錄連回相關發票；誰有權核實及批准，仍須由管理層決定。最實際的驗收問題是：這筆付款所用的完整收款資料，由誰透過獨立渠道確認過？

還要測試一個邊界：供應商可能確實改了戶口，但公司已有付款批次排隊等候銀行放行。應先決定已批准變更只適用於新批次，還是要撤回待放行批次。付款批准者須同時看到目前獲批主檔版本，以及建立該批次時使用的版本；兩者不同，就先停下，重建批次或向供應商逐項釐清，不能假設最新主檔必然適用於舊發票。採購同事也應看到暫停狀態，避免誤告供應商「已付款」。每週檢查未結案項目，可找出等待核實的真正供應商、過時要求及重複提交；每宗都要以具體原因結案，流程才不會在繁忙付款日變成無人處理的積壓。