我們怎麼核實飯店企業碼

本站每一組企業碼都由同一條規則決定——至少要有兩個獨立的公開來源一致確認。這一頁把這條規則完整寫出來：我們讀什麼、丟掉什麼，以及讓我們把門檻定在這個高度的那些具體案例。

The measurements behind this rule are published. Eight dated captures of the same Hilton corporate code search — every domain in the top ten, on 2, 3, 13, 14, 17, 19, 21 and 23 October 2026 — are on the SERP notes page, with the raw table and a chart. The data is CC BY 4.0, so it can be reused with attribution.

規則

全站有 206 組企業碼通過了同一道門檻。這道門檻只有三種結果，沒有例外：

兩個以上獨立來源一致——公司與數字都對得上，這組碼進入主表，並標明背後有幾個來源。
只有一個來源記載——放進待核實表，而且無論看起來多合理，都不會稱它為已驗證。
來源自己把該列標為未驗證，或回報該碼已失效——即使其他來源還在刊載，這組碼也要退出主表。

第一行真正在做事的詞是獨立，而這一頁大半篇幅都在講它在實務上是什麼意思。

有兩件事我們不做，先把話說在前頭，因為它們界定了這裡每一句說法的邊界：我們不在真實訂房引擎上測試企業碼，也沒有私下管道或內部名單。本站所有內容都來自公開來源，再由我們互相交叉查核。這代表：我們能告訴你某組碼有充分佐證；我們不能告訴你它在你的日期上一定訂得到價。

流程圖：一組企業碼在三個獨立來源之間交叉查核，去掉前導零正規化後，分別被送往主表、待核實表，或在來源互相矛盾時被標記 — 一組碼要怎麼在主表掙到一列：至少兩個獨立來源必須一致，並去掉前導零、保留 NC / CR 前綴。只有一個來源，或被標為未驗證、已失效，就降到待核實表。整個來源若資料列看起來是機器產生的，就整站作廢。我們寧可少刊幾組碼，也不刊一組自己不敢背書的。

206 列背後，究竟各有幾份清單

我們在 2026 年 11 月 1 日把十個品牌頁與集團頁的已佐證表逐頁數過一遍，直接讀已發布的表格：一共 206 列，以及那一欄記錄著每列有幾份獨立清單彼此一致。這個分布對我們自己的規則並不客氣。206 列裡有 107 列 — 超過一半 — 剛好只靠兩份清單，那是門檻，不是典型值。58 列靠三份、30 列靠四份，只有十一列靠五份或更多（五份 7 列、六份 3 列、七份 1 列）。

兩個看起來最像的頁面，形狀其實完全不同。Hilton 是全站唯一一頁沒有任何一列低於三份清單的頁面 — 它那 41 列已佐證分別靠 12 份（三份）、18 份（四份）、7 份（五份）、3 份（六份）、1 份（七份）；最後那一列 — AT&T，七份獨立清單 — 是全站佐證最強的一列。Marriott 在另一端：65 列已佐證，其中 49 列正好只靠兩份清單。同一條規則、同一道門檻，卻是兩種完全不同的形狀。Best Western 一列已佐證都沒有 — 那也是一種形狀：規則允許什麼都不產出。

長條圖：十個品牌頁與集團頁的 206 列已佐證之中，107 列正好靠兩份獨立清單，58 列靠三份，30 列靠四份，7 列靠五份，3 列靠六份，1 列靠七份 — 本站 206 列已佐證之中，107 列正好靠兩份獨立清單 — 那是我們設的門檻，不是典型值。2026 年 11 月 1 日依已發布的表格清點；沒有任何碼被新增或刪除。

So read the 確認來源數 column as a floor, not as a score. Two listings is the number we insist on before a row is allowed to carry the word confirmed, and the 107 rows sitting on it are not better corroborated than the 30 sitting on four. What the column does tell you is how far a row can be checked by someone who does not trust us: a row backed by seven independent listings is one you can test against six other places, and a row backed by two is one where a single wrong listing is enough to break it. We do not test codes at a live booking engine, so this number is the closest thing we have to a quality measure — and it is the only column in any of our tables that varies.

Source counts checked 1 November 2026 against the published tables on all ten brand and group pages.

什麼算一個來源

我們會讀四類來源，依價值由高到低：

協會或折扣網絡自己的頁面。ABN（Allied Business Network）公布自家的 ABN 企業碼——那是組織自己的文件，不是別人替它做的整理。
願意交代來源的哩程文章。milepro 與 goingawesomeplaces 的價值與其說在表格，不如說在它們會說明某一列從哪來。
大型聚合表。corporate-codes.com 是其中最大的，也是被抄最多的。
組織為自家成員寫的福利頁。mybetterbenefits 收錄的雇主專屬企業碼，別處找不到。

後兩類有用，但單獨永遠不夠。聚合表通常是從別的來源彙整來的，所以兩個聚合表互相一致，往往只是同一個來源在自我確認。整套方法就是為了避開這個陷阱。

所以我們對一個來源的檢驗標準，不是它看起來專不專業，而是它有沒有交代資料列從哪來，或者只是印了一張表。沒有出處的表格也可能是對的——但你無法從中分辨哪一列是對的、哪一列是抄來的。

會讓一個來源整站作廢的三種模式

很多來源會被丟掉，下面這三種模式，每一種都是本站遇過的真實案例，不是假設：

衍生副本。hotelcorporatecodes.com 列了 11 組 Best Western 企業碼，11 組全都在 corporate-codes.com 的清單裡，順序也一樣。那是一份來源被算了兩次，不是兩份來源互相一致。
機器產生的資料列。codescorporate.com 把 Best Western 企業碼 0000000 掛在 Apple 名下，還排出一串以等距遞增的美國州別代碼。看到這種形狀，我們直接作廢整個來源，而不是刪掉明顯假的幾列、然後相信剩下的。
空殼與優惠券頁。hotel-corporate-code.com 的 Comfort Inn 頁回傳 200，內文卻寫著 "品牌 Not Found"。優惠券頁賣的是季節性促銷，跟議定好的企業價是完全不同的產品。

整站作廢而不只是刪掉壞列，是刻意的。如果一個來源分不清佔位符號和企業碼，那它湊巧對的那幾列也不算證據——你無從知道是哪幾列。

結論一句話。這裡的短表和別處的長表，量的不是同一件事。我們寧可刊兩組已確認的企業碼，也不刊三十列沒有人交叉查核過的資料。

為什麼「十個來源都有」不算證據

這是這個領域最常見的錯誤，值得慢慢拆開來看。企業碼頁面互相引用得非常頻繁。某份清單在一個網站上出現，被第二個網站摘要，再被第三個聚合站整列照抄，然後一篇論壇貼文引用第三個。現在搜這組碼會出現十筆結果。沒有任何東西被核實過十次，只有一個說法被重複了十次。

有兩個跡象會洩漏抄襲鏈，而且從外部就看得出來：

順序相同、缺漏相同。上面那 11 組 Best Western 企業碼，在兩份清單裡以相同順序出現，漏掉的公司也一樣。獨立作業不會排出同樣的順序、留下同樣的缺口。
同一組錯碼、同一家公司。當兩個來源把同一組錯號碼給同一家公司，而沒有別人給這家公司任何號碼時，第二個就是第一個的下游。

實務上的結論：在我們這裡，一組碼不會因為被廣泛轉載而升級。它升級，是因為記載它的來源能追溯到不同的出處。一份被三份副本轉載的清單，仍然只算一個來源。

我們真正遇過的矛盾

這是最多企業碼頁面直接略過的部分。公開來源一天到晚互相矛盾——數字對不上、同一組碼被歸給不同公司、折扣幅度說法不一。以下是我們在建立各品牌頁時實際遇到的七個案例：

Florida International University——一個來源給的 Choice ID 是 LFIU，另一個給的是 803291。兩者都放在待核實表，都不算已確認。
AkzoNobel 與 ABN（Allied Business Network）——四個來源把 Wyndham 企業碼 8000000066 歸給 ABN，一個來源把同一組號碼歸給 AkzoNobel。
Business Advantage Plus——在 Wyndham 這邊同時以 1000007964 和 1000008537 流傳，而有一個來源把 1000008537 給了 S&T Bank。
General Electric——市面上有兩組不同的 Best Western 企業碼，322510 與 01648620，而記載後者的來源自己把它標為未驗證。
Apple——在某份 Best Western 清單裡以 0000000 出現，那是佔位符號，卻被當成企業碼刊出。
University of Washington——Q61N 是單一飯店（西雅圖 Hotel Nexus）的房價代碼，不是全連鎖通用的 Best Western 企業碼，卻被照樣抄進全連鎖清單。
Century 21——號碼 803277 在 Choice 的清單裡歸在 "Century 21 Business" 底下，在另一份清單裡則歸在 Wyndham 的 "Century 21 System" 底下。

由此得到兩個教訓，而它們正是本站長成現在這樣的原因。第一，一組碼出現在幾個來源裡不是證據：當來源互相抄襲，十個來源也只算一個。第二，一組碼可能完全真實，但對你來說形狀不對。

真實的企業碼，也可能形狀不對

不是每個矛盾都是錯誤，也不是每一組真實的碼都能當成全連鎖通用的碼來用。以下是品牌頁上的四個例子：

單一飯店的房價代碼。University of Washington 的 Q61N 是西雅圖 Hotel Nexus 的房價代碼，不是 Best Western 企業碼，在其他 Best Western 訂不出東西——但它照樣被抄進全連鎖清單。
佔位符號。Apple 的 0000000 是有人當成企業碼刊出的填充值。
會掩蓋錯誤的格式。Marriott 用字母計價，不是數字——Accenture 是 ACC、Deloitte 是 DTC、American Express 是 AMX。字母碼打錯一個字，看起來跟正確的一樣合理，這就是為什麼 Marriott 頁上全部十二個矛盾都是字母碼：Pfizer PFE 對 PFZ、Shell SHL 對 SHE。
同一組號碼被歸給多個擁有者。在 IHG 頁上，109193 分別被三個來源歸給 EY、Exterran 和 Facebook。在那裡撞號不一定就是錯，所以這些都必須一案一案讀。

把它們列出來是有目的的：「已驗證」和「對你有用」是兩種不同的說法，而只有前者是我們能講的。

為什麼日期比企業碼更重要

企業碼是一組掛在公司議定合約上的號碼。合約會重新議定、公司會被併購、差旅主管會換掉企業碼，舊的那組就再也訂不出價——而且通常沒有人會公告這件事。

沒有日期的清單看起來很完整，卻會無聲地過期。本站存在的目的就是補上這個缺口，這也是為什麼這裡每一張表都標示最後查核的月份，以及為什麼被標為已失效的企業碼會被移出主表，而不是留在裡面。

我們不做的事

我們不訂房、不實測，也不打電話給飯店查核企業碼。
我們不知道你是否符合某個房價的資格。那是你和持有該企業碼的公司之間的事。
我們不保證任何企業碼在任何日期都訂得到價。
我們不接受付費置入。部分對外連結是聯盟連結，這一點在每一頁都有揭露。

某組企業碼出現在這裡，不代表你有權使用，也不代表該房價一定訂得到。如果飯店認定你不符合資格，它可以重新計價。

這套方法在各品牌頁上哪裡看得到

每個品牌頁都帶著自己版本的這段說明，因為各集團的問題並不一樣：

Marriott——全站最大的兩張表（65 組已確認、60 組待核實），也是企業碼格式讓查核最困難的最典型案例。
Hilton——本站唯一幾乎沒有佐證問題的集團，因為兩份錨定文件是原始文件而不是聚合來源。
IHG——30 組已確認對上 36 組待核實，而且有一長串號碼被歸給一個以上的公司。
Hyatt——27 組已確認對上 59 組待核實；幾乎每一個矛盾都是同一組號碼被歸給好幾家公司。
Holiday Inn——22 組已確認、16 組待核實，而且待核實的每一筆都只有單一來源。
Hampton Inn——全站最小的已確認表：兩組號碼，對上 33 筆待核實資料，而它們全部來自同一份清單。
Wyndham 與 Choice Hotels——13 組與 2 組已確認，對上 38 組與 33 組待核實；在那裡，待核實表就是誠實的答案。
Best Western 與 Comfort Inn——這兩頁直接說出：目前還沒有任何企業碼被兩個獨立來源確認，並改為請你使用會員價。

如果你想抓我們的錯，最快的方式就在這些頁面上：找一組我們標為已確認的企業碼，再找出一個和它矛盾的來源。那樣的來信值得寄——聯絡頁說明了什麼樣的來信我們能處理。

最後更新：2026 年 10 月。