報價單上的價格不是價格：CRM、報價系統與 ERP，價格主檔該歸誰管？

你有沒有發現，同一筆生意，你們公司報得出三個價？

場景大概是這樣的。

業務接到一張急單，打開報價系統，給了客戶一個「幫你喬到的漂亮價」。客戶下單，訂單轉進 ERP 開單，跑出來的單價卻跟報價系統上那個不一樣。月底財會做毛利分析，從成本回推，又算出第三個數字。

三個系統，三個價格。

然後就是那場你我都很熟的會議：業務說「我明明給客戶的是這個價」，IT 說「系統就是這樣拋過來的」，財務攤開報表說「可是我這邊的毛利對不起來」。講到最後，老闆問了一句最關鍵、也最沒人答得出來的問題：

「那到底哪一個，才是我們真正的售價？」

答案很殘酷：三個都不是。因為在你們公司，「價格」這件事從來沒有人講清楚誰說了算。

承認吧，「CRM 是業務工具，跟內控無關」是個該修的觀念

這是我最常聽到、也最想糾正的一個誤會。

很多老闆和 IT 主管把 CRM、報價系統歸類成「業務前線用的東西」，覺得它跟財務、跟內控是兩個世界。反正業務衝業績嘛，工具好用就好，管那麼多幹嘛。

定價權就是內控。 一個能決定「這筆單最低可以賣多少」的系統，決定的是你公司的毛利底線。它站在內控的第一線——只是這條線，大多數公司從來沒有人被指派去守。

報價系統天生有個傾向：它是為「快速成交」設計的，所以它會讓價格好改、折扣好給、特價好開。這是它的本分，怪它沒有意義。真正的問題出在分工從來沒講清楚——它改完的價，要不要有人回頭驗？開單的時候，擋還是不擋？這兩題沒人回答，你的價格主檔就形同虛設。牌價只是掛在牆上好看的裝飾，真正在決定售價的，是跑最勤的那個業務的手感。

一家公司，只能有一顆大印

讓我用一個最老派、但最精準的東西來比喻整件事：印鑑。

一家公司的大印只有一顆。它鎖在保險箱裡，蓋一次要走用印申請，因為它代表公司對外的最終承諾。你不會讓每個業務口袋裡都揣一顆公司大印到處蓋。

價格主檔，就是你的價格大印。 它是「這個產品、這個客戶、這個條件下，公司認可的價格」的唯一真相來源。理論上，它應該只有一顆，而且改它要有程序。

那報價系統是什麼？

報價系統拿的是「小章」。 為了讓業務在前線能快速回應客戶，你發一顆小章給他——這很合理，總不能每報一個價都回總部用大印。但關鍵在下面這句：

小章能蓋什麼、蓋到多少，要有一張「授權書」寫清楚。

授權書寫「牌價九折以內，業務自己決定」，那業務蓋到九折都算數；寫「低於九折要主管簽」，那小章蓋出來的八五折，沒有主管那顆章就不生效。沒有授權書的小章，就是一顆到處亂蓋、蓋了公司還得認的野章。

很多公司把這件事講成「業務跟財務搶定價權」，講得劍拔弩張。依我看大多數時候根本沒有誰在搶——只是大印、小章、授權書這三樣東西，從來沒有人坐下來分工。這也是我在整個衛星系統系列反覆問的那題「誰說了算」：每一顆掛在 ERP 旁邊的衛星系統，都得先回答主檔歸誰管，價格主檔只是其中最貴的一顆。

於是我們得到這篇文章的那條線：

報價單上的價格不是價格，主檔裡的價格才是——誰能改主檔，誰才真正擁有定價權。

工具一：定價權分層表——把「小章能蓋什麼」寫成一張表

光講「要有授權書」沒用，你得真的把它列出來。價格從來就沒有「一個數字」這麼單純，它是一疊——牌價、合約價、專案折扣、急單特價，每一層的授權對象、存放系統、驗證方式都不一樣。你要做的，是把這疊價格攤開，每一層都回答三個問題：誰有權改？存在哪個系統？ERP 開單時怎麼驗？

這張表真正的作用，是逼你回答一件你可能一直在迴避的事：每一層價格，到底是「小章自己能蓋」，還是「要回大印核准」？ 把界線畫清楚，報價系統就從一個失控的變數，變成一個有授權邊界的工具。

工具二：報價到訂單三對——訂單放行前的驗章關卡

分層表管的是「價格怎麼定」，這張三對表管的是「訂單放行前，怎麼驗」。報價轉訂單，是價格從「業務喊的」變成「公司認的」那一刻——這一刻沒設關卡，前面的授權書全都白寫。放行前，對三件事：

1. 對價格：這張訂單的單價，有沒有低於這個客戶／這個層級的授權底價？低於授權底價又找不到對應的核准軌跡，擋單。這是最基本的一關，卻最常被「業務急、先放過去再補」給破掉。
2. 對條件：價格對了不代表沒事。付款條件從月結 30 天悄悄改成 60 天、交期承諾、隨貨贈品、運費負擔——這些「非價格的讓利」全都是變相降價。很多毛利就是從這裡漏掉的，因為大家只盯著單價。
3. 對信用額度：價格和條件都對，還要問一句——這個客戶的應收帳款，還在額度內嗎？報價系統通常看不到 ERP 的信用狀況，它只想成交。訂單放行前必須回 ERP 對一次信用額度，超額的單要卡在信用關卡。這一關就是銷售收款循環裡的「信用擋單」控制點——我在 IPO 九大循環那篇講過，會計師抽單的時候，這裡是必看的一站。

這三對，你可以理解成訂單進 ERP 前的三道驗章：價格章、條件章、信用章，三章齊了才放行。 缺一關，你放進去的就不是一筆乾淨的訂單，是一顆未來會在毛利表上爆開的地雷。

從一個真實案例看：外掛報價系統該怎麼「回寫」ERP

講點實戰的。我手上有一個客戶的案例，是掛在 Oracle Fusion 外面的一支外掛報價系統——這種「ERP 主體＋外掛報價前端」的架構，在中小企業其實非常常見，因為 ERP 原生的報價功能通常又硬又難用，業務不願意碰。

做這種外掛，最核心、也最容易做錯的一個設計決定是：報價系統跟 ERP 主檔之間，資料是怎麼流的？

憑我做這類介接的經驗，取捨大概是這樣：

• 牌價與合約價，一律從 ERP 主檔「唯讀帶入」，報價系統不准自己維護一份。 這是鐵律。一旦報價系統自己存一份價格表，你就有了兩顆大印——兩顆遲早會不一致，只差在哪一天被發現。報價系統要嘛即時去 ERP 抓、要嘛定時同步一份唯讀快取，但改價的權力永遠留在 ERP 那顆大印手上。
• 折扣與特價，可以在報價系統開，但回寫 ERP 時要帶「核准軌跡」。 業務在前線談折扣是常態，這個彈性要給。但回寫訂單的時候，不能只回一個「最終價格」，要連「這個折扣是誰、依哪一條授權、什麼時候核准的」一起回寫。回寫的不只是數字，是數字背後的授權依據。 少了這個，ERP 收到的就是一個沒有來歷的價格，事後誰也查不出這 15% 的折扣是誰放的。
• 回寫的時點，要卡在訂單成立那一刻做完三對，而不是報價當下就寫進去。 報價階段業務怎麼喬都行，那是談判；但一旦轉訂單、要進 ERP，就得過前面那三道驗章。把驗章關卡設在「回寫的閘門」上，而不是散在報價流程裡，控制點才收得攏。

這個案例真正的啟示無關技術：架構的取捨，會直接決定定價權落在誰手上。 你把價格主檔的維護權留在 ERP、把折扣的核准軌跡強制回寫，定價權就還在公司手上；你圖方便讓報價系統自己存一份價格、回寫時只回數字，定價權就悄悄搬到了報價系統、搬到了業務手上。同一套系統，兩種接法，兩種截然不同的內控結果——而差別，往往只在導入前有沒有人把分工講清楚。

這件事跟我在選 ERP 像選伴侶那篇講的是同一類問題：維護費是相處題，價格主檔歸誰管也是。婚前沒談好誰管錢，婚後每一筆對不起來的帳，都會回來提醒你。

【給決策者的備忘錄】

如果你讀到這裡，心裡浮現的是「我們公司好像就是三個價」，別急著怪 IT，也別急著怪業務。沒有誰把系統裝壞，多半也沒有人真的在搶你的定價權。癥結通常就是一個從來沒有人被指派去回答的問題：我們的價格主檔在哪、誰能改、改了誰來驗。

你要做的第一件事也用不著換系統。拿出那張「定價權分層表」，把公司現在的價格一層一層填進去——很可能你會發現，有好幾層根本沒有明確的授權對象，就是「大家默契上這樣做」。那個「默契」，就是你定價權的破口。

報價系統、CRM 要不要能改價，說到底是一個分工題：公司的價格大印放在哪、小章發給誰、授權書寫到哪一行。方法我在上面講透了，兩張表也給你了。但你們家那顆大印，現在到底被幾個人握著、授權書寫得夠不夠清楚——這個答案，得回到你的實際系統、實際流程裡才盤得出來。

如果你想把這件事盤清楚，把「三個價」收斂回「一個真相」，歡迎與我們聯繫。

（本文的系統設計取捨為顧問經驗性陳述，實際落地方式依各公司 ERP 版本、報價系統與流程現況而定。）

延伸閱讀

• 年報的資安專章怎麼寫？別交一份抄來的健檢報告
• 上市櫃資安合規完全指南：防駭是技術，舉證是內控——從資安長到查核軌跡（2026）
• AI 代理的內控框架：當「不是人」的東西開始做交易，內控該怎麼寫（2026）
• 《資通安全管控指引》落地三段譯：把指引從年度問卷變成內控制度的資安章（2026）
• 老闆一句話，你就兼了資安長：這個位子給你的不是名牌，是一疊卷宗