會計裡爭論得最多的那一個問題
頂端那句話，你在損益表那級台階上已經知道了：在權責發生制下，[[revenue|收入]]在「賺得」時入帳，而不是在現金到帳時。這一句話把容易的情形都了結了。可現實世界遞上來的，是些更糟心的情形——一家軟體公司把一套程式、一年的更新、外加一條客服熱線，捆成一個 1,200 元的價格賣；一個建築商，正幹到一座兩年工期大橋的半道上；一家電信業者，在一份 24 個月的套餐裡塞進一部「免費」手機。對其中每一個，那同一句鈍問都會回來：「這一期間到底算多少收入，又有多少必須等？」把它答好，正是[[revenue-recognition|收入確認]]這件事的全部，而它是整個財務會計裡爭論最多、被重述最多、打官司最多的一個題目。
為什麼這件事會爭得如此激烈？因為收入是頂端那一行，而它下面幾乎所有東西都要拿它來掂量。把明年的一塊錢收入挪進今年，利潤就鼓起來，股票看著便宜了，獎金指標達成了，貸款契約條件也滿足了。「太早、太急著」確認收入的誘惑大得驚人——這正是為何準則制定者要用一本精確、共用的規則手冊把這個問題圈起來，而不把它交給直覺。把本篇拿下，你就握住了那把鑰匙，足以打開隨後整級「收入與應收款」的台階。
為何「風險與報酬」不再夠用了
幾十年來，老的判定是把[[realization-principle|實現原則]]用某種說法表述出來：當「所有權的風險與報酬」轉移給了買方，就確認收入。對一個隔著櫃檯把一條麵包遞給顧客的麵包師來說，這套話說得漂亮極了——佔有、風險、報酬，全在同一剎那易手。麻煩在於，現代商業賣的遠不止麵包。當一筆買賣把一件產品、一份保固、持續的更新、再加一項退貨權捆在一起時，去問「風險與報酬轉移了嗎？」，等於對一個本質上關乎「好幾個」分別承諾、每個各在自己時點兌現的問題，給出一個霧濛濛的、全有或全無的答案。
更糟的是，「風險與報酬」含糊到可以被鑽空子。處境相同的兩家公司，可以讀出不同的意思，而一家激進的公司，可以主張「貨一發出風險就過去了」——哪怕客戶可以把東西全退回來。美國的舊規則手冊與國際的舊規則手冊也早已彼此走偏，於是同一筆交易，竟可能在一個國家算收入、在另一個國家不算。於是 2014 年，兩家準則制定者——FASB 與 IASB——聯合發布了一套統一趨同的準則：在美國叫 ASC 606，在國際上叫 [[ifrs|IFRS 15]]——用一套有結構的程序，替換掉那句霧濛濛的口號。它把核心問題從「風險是何時過去的？」，挪到了一個更鋒利的問題上：「賣方是在何時，履行了它對客戶所許下的每一個承諾？」
把五步模型，從頭走一遍
這套準則的核心，是[[five-step-revenue-model|五步收入模型]]——一份你對任何金額的每一筆買賣都要跑一遍的清單。別被「模型」這個詞嚇著；對一筆簡單的當面成交，這五步會塌縮成一次心跳，你只有在面對那些複雜的捆綁銷售時，才感覺得到齒輪在轉。下面是整台機器，按順序排好。
- 識別合約。是否存在一份真實的協議——雙方都已認可，載明了各自的權利、付款條款，具有商業實質，而且收款是「很可能」的？一句隨口的「說不定哪天我會買」不是合約；一張簽了字的訂單，或一次點下去的「提交訂單」，才是。
- 識別履約義務。把合約拆成它一個個分開的承諾——每一項客戶能單獨從中獲益的、可區分的貨物或服務。那份軟體捆綁銷售，便拆成三個：那套程式、那一年的更新、那條客服熱線。
- 確定交易價格。算出你預期有權取得的總額——扣掉折扣、預計的退貨、以及任何浮動的部分——並剔除那些你只是替別人代收的金額，比如銷售稅。
- 把價格分攤到各項義務上。按「每一項若單獨出售會賣多少錢」（它的單獨售價）的比例，把那個總額分攤到一個個分開的承諾上。套餐裡那部「免費」手機並不免費——每月話費裡，其實有一部分是在為它付錢。
- 在每項義務被履行時確認收入。在某項承諾被守住的那一刻——或在它延續的整段時間裡——把對應的那一片收入入帳。有些承諾在「某一時點」完成（程式被下載）；有些則是「隨時間」履行（那一年的更新，逐月賺得收入）。
第二步和第五步，是這套準則新的心臟，而把它們連起來的那個念頭，正是你必須從本篇帶走的：一項[[performance-obligation|履約義務]]，是一份合約裡的一個可區分的承諾，而收入是一個承諾一個承諾地賺得的，不是一份合約一份合約地賺得的。正是這一個轉變——把一筆買賣剁成它的一個個承諾、再隨每個承諾被守住而逐一確認——是「風險與報酬」從來無法乾淨俐落地辦到的，也正是為何新模型能用同樣的五步，去對付一份手機套餐，也對付一座大橋。
一個走通的捆綁例子：1,200 元的軟體交易
數字能讓這一切落地。1 月 1 日，一位客戶為一份為期一年的交易預付了 1,200 元現金：一套可下載的程式、十二個月的更新、外加一年的客服熱線。這些若分開來賣，定價會是 700 元、360 元、140 元——合計正好 1,200 元，所以這裡沒有折扣要分攤。真正的活兒，現在落在第五步上。程式在第一天就交付了：這是一項「時點」義務，於是它那 700 元立刻賺得。更新和客服熱線，則各自在這一年裡均勻地提供：這些是「時段」義務，每月分別賺得 360/12 = 30 元、140/12 ≈ 11.67 元。1 月 1 日這天，1,200 元裡只有 700 元是收入。
那麼，你已經握在手裡的另外那 500 元現金，會怎麼樣？它現在還不歸你叫作收入——你還欠著一年的更新和支援。它作為一項叫[[unearned-revenue|預收收入]]（遞延收入）的負債，停在資產負債表上：一項你已收錢、卻尚未交付的未來服務的承諾。一個月一個月地，你守住承諾，那項負債便隨著收入被賺得而縮小——這正是你在上一級台階遇到的「遞延調整分錄」那套機制，如今從收入這一側再看一遍。下面這張草圖，畫出了第一天和一個尋常的月份。
Stand-alone prices -> Program 700 | Updates 360 | Support 140 (= 1,200)
Jan 1 (collect 1,200 cash; deliver program now)
Dr Cash ................. 1,200
Cr Revenue ............... 700 <- program: earned at a point in time
Cr Unearned revenue ..... 500 <- updates+support: still owed
Each month (deliver 1/12 of updates and support)
Dr Unearned revenue ...... 41.67
Cr Revenue ............... 41.67 (= 30 updates + 11.67 support)
After 12 months: unearned revenue 500 -> 0; total revenue = 1,200當付款不是「預付現金」時，什麼會變——什麼不會變
在前一個例子裡，客戶是先付了錢，可這五步對現金的時點毫不在意。把它翻過來：一家諮詢公司在三月完成了一個 9,000 元的專案，並按 30 天帳期向客戶開帳單。履約義務在三月被履行，所以這 9,000 元全是三月的收入——哪怕一分現金都還沒動。那筆分錄的另一邊不是現金，而是[[accounts-receivable|應收帳款]]：一項要求被付款的法律債權，一項資產，在活兒做完的那一刻就記下。預付的現金，把錢停泊在一項你欠著的負債裡；先做完的活兒，把它停泊在一項別人欠你的資產裡。確認追的是「被守住的承諾」，而現金，無論它何時到來，都只是結清帳目而已。
最後再說一句誠實話，因為這塊田裡滿是陷阱。五步模型是一套有紀律的框架，不是一道能把判斷從中抹去的公式。一份合約裡到底含有幾項義務、其中每一項單獨能賣多少、一個跨年專案進展到了幾成、會有多少貨物被退回——這裡頭每一個，都是一項憑良心做出的估計，而每一處，都是一家激進公司可能用力過猛的地方。ASC 606 與 IFRS 15 的用意，並不是要廢掉判斷，而是給判斷套上一個共用的、透明的結構，好讓兩個誠實的會計師得出同一個答案，也讓一個不誠實的會計師少幾個可以藏身的暗影。在這裡所謂精通，與其說是把五步背下來，不如說是看清那些判斷究竟藏在哪裡。