提示：本篇為針對個別準則的解說與延伸說明。
若想查看本準則的 完整文章清單與簡介，請參考《系列總覽》頁面。
注意（溫馨提示／適用性說明）：本文所有內容均依香港會計準則（HKAS / HKFRS）條文撰寫，並強調其與國際會計準則（IAS / IFRS）高度一致。各位香港、海外會計師及業界人士如採用IAS / IFRS，也可直接參考本文理論及分析進行實務應用。
另外，本文為方便閱讀，盡量用「公司」代表會計準則中的「實體」。
開首情境：為何第一、二步的判斷這麼重要？
在很多香港公司，尤其是建築、系統整合或軟件行業，收入準則真正的難點，往往不是計算公式，而是「一開始就判斷錯了問題是什麼」。
例如：
- 有些客戶「收唔足價」，是純粹信用風險，還是其實一開始就決定給對方折扣？
- 多份看似獨立的合約，是否實際上應視為一份合約？
- 產品＋安裝＋一年技術支援，究竟是三個履約義務，還是一個「交付完整系統」的組合？
這些都是五步模型的「第一關」與「第二關」。如果開首就判錯，後面交易價格、分配、收入確認時點全部會歪，最後變成審計、與管理層的溝通難題。
摘要：讀完你應該可以做到什麼？
- 清楚列出「合約存在」的五項標準，知道什麼情況 HKFRS 15 其實未開始適用。
- 分辨「可收回性問題」與「隱含價格優惠」的邏輯差異。
- 理解何時要把多份合約「組合」處理，以及合約修改的基本方向。
- 掌握履約義務的兩大判斷準則，並能在建築、軟件等常見情景中判斷是否為單一組合項目。
- 避免過度拆分或過度捆綁履約義務，建立一套簡單的自我檢查思路。
一、合約存在的五項標準：準則何時「開門」？
在 HKFRS 15 的五步模型中，第一步是「識別與客戶的合約」。但準則並不是見到任何 報價 (quotation)、採購訂單 (PO) 或口頭承諾，就當作合約已經存在，而是訂出五項條件。只有五項都滿足，收入模型才真正開始運行。
這五項條件大致可以拆解為：
- 雙方已批准合約 可以是書面、口頭，或依慣例行事的方式，但要有合理證據顯示雙方同意受條款約束。例如，某IT 公司一直按客戶電郵指示工作，但正式合約遲遲未簽。若慣常做法是用電郵訂立合約，而且雙方都照此履約，通常可視為已批准。
- 各方的權利可以識別 合約需要清楚說明公司要提供什麼貨品或服務、客戶有什麼權利，例如使用權、退貨權等。如果條款模糊到「交付什麼」都不清楚，準則會認為還未達到合約的標準。
- 付款條款可以識別 不一定要寫得極度詳細，但需有合理基礎知道客戶要怎樣付錢，例如金額、付款時間、計價方式。
- 合約具有商業實質 合約會令公司未來現金流風險、金額或時間分佈發生有意義的變化。若只是「造數」或形式上的安排，沒有實質經濟影響，就不符合這項要求。
- 公司有合理預期可收取對價 重點是「可收回性」，即考慮客戶的信用風險、過往紀錄等，判斷公司是否有合理預期可以收回應收金額中「不受價格折扣影響」的部分。
如果這五項未同時滿足，HKFRS 15 下的收入確認暫時「未開局」。常見的做法包括：先把已收到的款項視為負債（例如「合約負債」或「遞延收入」），直至合約條件達成，才轉入收入模型。
另外，若公司一開始就知道將來必然不能全數收回應收金額，就要小心究竟是合約未滿足可收回性、還是存在隱含價格優惠，這就引出下一節。
二、可收回性 vs 隱含價格優惠：信用風險還是價錢問題？
可收回性（collectability）在 HKFRS 15 中是一條「gating question」——合約是否合資格進入準則範圍的門檻之一。而「隱含價格優惠」（implicit price concession）則是交易價格的一部分，是在合約已存在的前提下，對實際會收多少錢的估計。
兩者的核心分別可以簡單理解為：
- 可收回性： 問的是「公司是否合理預期可以收取不包含折扣部分的對價？」 若公司根本無此預期，則合約未符合第一步的條件。
- 隱含價格優惠： 當公司基於以往經驗或合約談判過程，實際上已「心理預設」會收少一點，例如開價10萬，但知道某類客戶通常只付8萬，這少收的2萬實際上是一種價格折扣，即可變對價的一部分，而不是信用風險純然導致的壞帳。
在常見工作情景中，可以這樣區分：
- 偏向可收回性問題的情況：
- 顧客一向付款守時，但突然出現重大的財務困難，破產風險很高。
- 合約簽訂時，公司沒有打算給折扣，也無經驗顯示該類客戶會經常「討價還價」。
- 偏向隱含價格優惠的情況：
- 公司一向「標價」寫得較高，但行業慣例是大部分客戶都會獲得一定折扣。
- 銷售團隊為達成銷售，實務上習慣性接受顧客延遲付款或部分減價，而管理層亦默許。
實務上，準則期望公司先判斷：
- 若公司根本不預期可收回合約價款中的「非折扣部分」，合約未達成可收回性門檻，暫時不進入 HKFRS 15。
- 若公司合理預期會收回「經折扣後」的金額，則將折扣視作隱含價格優惠，納入交易價格的估計，之後依可變對價的規則處理。
對會計及審計工作來說，關鍵是把這個判斷在工作底稿寫清楚：哪一部分是信用風險（後續用減值準則處理），哪一部分是價錢本身的決策，屬於 HKFRS 15 下的估計。
三、合約組合與合約修改：多份合約是否「其實是一份」？
在很多行業，與同一客戶的交易並不是一次性完成，而是分幾份合約簽。HKFRS 15 要求在某些情況下，把多份合約「組合」起來，視作一個合約處理；同時，合約簽訂後可能出現變更，需要判斷是「合約修改」，還是應當視作新合約。
何時要合約組合？
一般來說，若以下情況出現，準則會傾向把多份合約視為一份：
- 合約在同一時間或短時間內與同一客戶（或關聯客戶）簽訂；
- 合約之間在商業上是一攬子交易，合約的議價是基於整體考慮；
- 合約之間的貨品或服務在實務上是一套綑綁的方案，很難獨立看待。
常見情景：
- 建築公司與同一發展商，就同一個建案簽訂三份合約：地基工程、上蓋工程及外牆工程，價錢談判時一併討論。這種情況往往要考慮視作一份「組合合約」。
- 軟件公司先簽「核心系統」，之後短時間內再簽「重要功能模組」，而整體價錢是在初步談判時已一併考慮折扣。
合約組合的影響，是五步模型之後的所有步驟都要在合併後的合約層面處理，包括履約義務識別、交易價格、收入分配等。
合約修改：新合約還是舊合約延伸？
合約簽好之後，客戶可能增加或刪除某些貨品或服務，或重新談判價格。HKFRS 15 要求判斷這些改動是：
- 視為單獨新合約，還是
- 視為原有合約的一部分（可能是追溯調整，或前後分層處理）。
簡化理解：
- 如果新增的貨品或服務屬於「獨立、可區分」的項目，而且新增部分的價格接近其獨立售價，一般傾向視作新合約。
- 若新增或修改的部分與原有合約高度相關，價格又包含明顯的折扣或追價，通常要視作原合約的修改，要重新計算剩餘對價與履約進度。
簡化例子：
- 建築工程中途加建一層樓，價錢接近「正常造一層樓」的市場價，而且該工作可視為額外獨立範圍——比較偏向新合約。
- 軟件專案中途大改系統規格，原本已完成部分的價值及未來工作範圍都要重新談判——通常要視作原合約的修改，重新衡量剩餘履約義務與收入模式。
實務上，合約修改文件、補充協議、電郵討論內容往往是關鍵證據，會計處理時應整理清楚，避免只把新增金額簡單「加落去」原合約收入，而忽略了控制權轉移模式是否也已經變了。
四、履約義務的基本概念：為何「可區分性」那麼重要？
第二步的核心，是找出合約中的履約義務（performance obligations）。履約義務簡單來說，就是公司承諾轉移給客戶的「一項或多項可區分的貨品或服務」。
為何要那麼在意「拆幾件」？因為：
- 每一個履約義務，都有自己的收入確認模式（在某一時點，或在一段時間內）；
- 交易價格要分配到各個履約義務；
- 披露時也要按履約義務的性質分類。
HKFRS 15 用兩個主要標準去判斷一項貨品或服務是否「可區分」：
- 客戶可以從該項貨品或服務單獨獲益 即使沒有合約中的其他部分，客戶仍然可以直接或連同已持有的其他資源一起使用它。 例如：一個標準軟件授權 (licence)，客戶本身已有 IT 團隊，可以自行安裝及運作，這授權通常就可單獨獲益。
- 在合約背景下該項承諾是可單獨識別 要看公司是否把多項貨品或服務高度整合成一個整體產出；某項是否主要是對另一項的修改、客製化或重大整合；客戶是否期望得到的是「一個整體結果」，而非多項獨立項目。
實務上，第二點往往比較難。很多時候，貨品或服務在技術上可單獨出售，但在特定合約中被高度整合，所以不再視為獨立履約義務。
正確識別履約義務有幾個直接後果：
- 決定收入是分段認列，還是集中在某個時點認列；
- 影響交易價格分配，從而影響利潤的時間分佈；
- 審計時，若履約義務拆分與同行差異太大，容易被挑戰判斷是否合理。
五、可單獨識別判斷：組合產出 vs 投入
要判斷一個合約是包含多個履約義務，還是只有一個「組合項目」，可以用一個實務上常用的思路：客戶買的是「很多投入」，還是「一個整體產出」？
建築合同：通常是一個整體產出
以建築合約為例，工程包括設計、地基、結構、內部裝修等。雖然每個部分技術上可由不同公司承做，但若合約是由同一間承建商總包，承建商負責整體協調、管理風險、提供一個「完工的建築物」作為結果，客戶關心的是「交樓」，而非每一個分段。
在這種情況下：
- 各項工作彼此高度整合，承建商提供的是一個整體產出；
- 個別工序主要是整體產出的投入；
因此，多數情況會視為單一履約義務——即「交付完成的建築物」。收入一般會按履約進度，在合約期內逐步確認。
軟件 + 安裝 + 技術支援：要看誰主導整合
再看一個常見情景：軟件公司向客戶提供：
- 標準軟件授權；
- 安裝服務；
- 一年的技術支援。
可能出現幾種判斷結果：
- 情況一：三個履約義務
- 授權為現成產品，客戶即使沒有安裝服務，也可找其他 IT 供應商安裝；
- 安裝只是「方便」服務，沒有高度客製或整合；
- 技術支援性質接近獨立的售後服務。 在這種情況下，三項通常會被視為三個履約義務，交易價格要分配到三個部分，收入確認時點也可能不同。
- 情況二：一個組合履約義務
- 授權需要大量客製化、安裝工作才能符合客戶特定流程；
- 公司負責系統整合，客戶關心的是「一個可運作的系統」，而非單一授權；
- 技術支援在初期是整體交付的一部分，對於實現預期功能十分關鍵。 在這樣的合約設定下，各項服務高度整合，公司提供的是一個「完整解決方案」，通常會視為單一履約義務，在整個導入期內隨履約進度確認收入。
實務上，判斷時可問幾個問題：
- 如果抽走其中一項（例如安裝），客戶是否仍然能從其他部分中取得大部分經濟利益？
- 公司是否主要在整合多項貨品／服務，變成一個客戶實際想買的「成果」？
- 各項是否主要是對其他項目的重大客製化或修改？
如果多個答案都傾向「整體」、而非「個別」，就要小心是否應視為單一履約義務。
六、常見實務挑戰與考試陷阱：不要過度拆，也不要過度捆綁
在實務和考試題目中，履約義務識別很多時候不是計算題，而是判斷題。常見的誤區包括：
1. 過度拆分
- 以為只要存在多項貨品或服務，就必然是多個履約義務。
- 結果把高度整合的工程或系統項目拆成很多小部分，收入確認變得過於「碎片化」，與實際風險管理和客戶期望不符。
避免方法：
- 冷靜回到兩大標準：客戶能否單獨獲益？在合約背景下是否可單獨識別？
- 若實際上是組合產出，就不應為了「好似細緻一點」而硬拆。
2. 過度捆綁
- 把本來可以獨立出售、且客戶會分別看待的項目強行捆綁為一個履約義務，令收入確認過度延後或過度集中。
- 例如：標準軟件授權（可立即使用）與獨立的後續維護服務捆在一起，全部收入都攤在服務期內，與實際經濟實質不符。
避免方法：
- 檢查公司是否有個別出售其中某項貨品或服務的慣例；
- 留意客戶是否有實際選擇權（例如可唔買維護服務）。
3. 跳過第一步的「合約存在」檢查
- 直接假設所有已開票的交易都符合 HKFRS 15 的五項條件，忽略可收回性、商業實質等。
- 對於高風險客戶或特別條款的合約，這樣做會大幅增加日後減值與收入重述的風險。
可以建立一個簡單自我檢查清單，在準備工作底稿或教學時提醒自己：
- 合約是否已獲雙方批准？
- 權利與付款條款是否清晰？
- 是否具商業實質，而不是形式安排？
- 對價（扣除明顯折扣後）是否有合理預期可收回？
- 履約義務是否按「可獲益」及「在合約背景下可單獨識別」兩大標準判斷，而不是單靠感覺？
結語：之後見到合約，先問這兩條問題
當你下次在工作中打開一份客戶合約，或者在考試中見到一個長長的情景題，可以先停一停，問自己兩個問題：
- 這份合約是否已達到 HKFRS 15 所說的「合約存在」五項標準？ 若未達標，收入模型暫時未啟動，先搞清楚是可收回性問題，還是商業實質不足。
- 合約中有哪些履約義務？是多個可區分項目，還是一個整體產出？ 回到「可獲益」及「在合約背景下可單獨識別」兩大標準，思考客戶真正買的是「很多投入」還是「一個結果」。
只要第一、二步的框架建立得穩，後續關於交易價格、可變對價分配、收入在時間上的確認，就會變得更有條理。日後你可以在工作底稿中多寫幾句解釋這兩步的判斷邏輯，亦可以在閱讀資產負債表與損益及其他全面收益表的附註時，刻意留意：管理層是如何描述合約、履約義務和合約修改的。
下一步，可以考慮進一步學習五步模型中的後三步：交易價格、分配，以及收入何時在資產負債表和現金流量表中體現。當你把整條鏈連起來，HKFRS 15 就不再只是厚厚的一本準則，而是一套可以在日常工作中使用的思考工具。
如果這篇文對你有幫助，歡迎免費訂閱我的 Substack：
– 所有完整文章會先在網站發佈；
– 每完成一個準則系列，我會用一封 email 幫你整理這個系列的文章和結構，方便你一次過重溫，不用自己慢慢找；
– 不定期分享一些會計實務上的小提示；
– 將來如果有新的 PDF 筆記、深入案例或付費內容，email 訂閱者會第一時間收到通知。
想直接問我問題或交流學習心得，可以在 Threads / IG follow 我，DM 我也可以，我會盡量回覆。
如果你覺得這些內容對你有幫助，也可以請我喝杯咖啡，支持我繼續寫下去。
罔相心室: https://chinese.iamdelusionman.com/
Zero-to-Acct Substack: https://zerotoacct.substack.com/
Thread: https://www.threads.com/@yickki_mong
IG: https://www.instagram.com/yickki_mong/
