看到「$1M ARR」，先問那是五個數字裡的哪一個

你在 Threads 或 X 上滑到一則貼文：某個一人開發者說他的產品做到「$1M ARR」，底下一片恭喜。你想知道那是多少錢，但你手上只有那四個字。

今天早上我打開一家我們報導過的公司的營收核實頁——AEO Engine，一家用 Stripe 金鑰直連核實營收的美國代理商。同一張卡片上，我讀到五個數字：近 24 小時 8,244 美元、近 30 天 76,316 美元、近 12 個月 872,728 美元、累計 2,284,795 美元、現行 MRR 80,601 美元。

五個都是「營收」。五個都是同一家公司。而如果我照不同的算法把它們換算成「年收」，會得到三個差很多的答案。

先把兩個詞定死。

MRR（monthly recurring revenue，月經常性收入）是把所有還在生效的訂閱，換算成月費之後加總。Stripe 官方文件把定義寫得很具體：MRR 是 active 與 past_due 兩種狀態訂閱的月度標準化金額總和，排除稅金、免費方案的訂閱者，以及所有按量計費的產品。ARR（annual recurring revenue，年經常性收入）通常就是 MRR 乘以 12——它是一個推算出來的年化速率，不是過去 12 個月實際入帳的錢。

兩個定義裡最容易被跳過的是最後那半句。ARR 是速率，不是歷史。這一個字的差別，就是下面所有口徑打架的源頭。

我用同一張頁面，算出三個不同的年收

拿上面那五個數字，用三種常見算法各跑一次：

算法	得到的「年收」	這個數字是什麼
MRR × 12	967,212 美元	訂閱速率年化，最標準的 ARR
近 30 天 × 12	915,792 美元	把上個月當常態，含一次性收入
實際近 12 個月	872,728 美元	過去一年真的進來的錢

前兩格是我自己乘出來的，不是頁面上的數字；第三格是頁面直接給的。最標準的那個 ARR 比實際收到的錢高出約 94,000 美元、11%——這個差額我自算，非官方數字。

三個都不算造假，三個都可以被寫進貼文。差別在你不知道發文的人用的是哪一個。

而如果用某些貼文真的用過的算法——拿最近某一天的營收乘以 365——同一張頁面會給出 300 萬美元。8,244 乘 365，我按的計算機。這不是這家公司的說法，它從來沒這樣宣稱過；我只是把別人用過的算術套在一組公開數字上，讓你看見這個算法能把同一家公司放大成什麼樣子。這種算法真的有人用：我們寫過一位開發者自己公開說明他的百萬美元年收就是這樣算出來的。

六個口徑，六種不同的錢

第一，MRR 是一個設定，不是一個事實。 Stripe 讓商家自己決定要不要把折扣從 MRR 裡扣掉——經常性折扣、一次性折扣各一個開關。也就是說兩家一模一樣的公司，可以因為後台選項不同而報出不同的 MRR。看到 MRR 別把它當成量出來的東西，它是算出來的，而算法有參數。

第二，按量計費永遠不在 MRR 裡。 Stripe 明文排除 metered（按量）產品。所以一個主要靠用量賺錢的生意，MRR 會系統性地低於它真正的收入。我們寫過的一家 token 轉售閘道就是這個形狀：2026 年 8 月 1 日的核實讀數是近 30 天流水 158,166 美元、MRR 55,984 美元，創辦人自己註明 MRR 只計兩個訂閱產品。三倍的差距不是有人在灌水，是定義本來就這樣。

第三，流水不是收入。 同一個例子的另一半：那 158,166 美元裡有一大塊是要付給模型供應商的成本，平台自己抽的是儲值金額的 5%。gross volume（流水）是經過你的錢，revenue（收入）是留下來的錢。 賣別人的東西的生意——轉售、代購、代投放、代營運——這兩格永遠差很遠。

第四，累計金額的起算點可能是另一家公司。 AEO Engine 頁面上那個 228 萬美元的 all-time，起算自 2018 年——但 AEO Engine 這個品牌 2026 年 1 月才定名，源頭是同一位創辦人 2018 年開的 Amazon 代理商。同一個 Stripe 帳號跨過一次業務轉型，累計數字就會把前世一起算進來。我們寫這家公司的時候，這是最容易寫錯的一格。

第五，合約總額不是實收。 「我還沒開始寫程式就先收到 8,400 美元」聽起來像已入袋，拆開可能是 7 個人各買 3 個月、每月 399 美元，而且附全額退款保證。合約總額、已開發票、已入帳、退款期已過——這是四個時間點，四個數字。

第六，同一張卡上的欄位，硬度不一樣。 這條是我認為最少人注意、但最好用的一條，因為它就印在核實網站自己的頁面上。

「核實」這兩個字，也有它的邊界

TrustMRR 這類營收核實服務，每個公司頁都有一個免登入的純文字端點。我今天讀 AEO Engine 那份，檔頭寫得很清楚：營收相關欄位——revenue、MRR、customers、subscriptions、churn——是用金流商 API 金鑰直接讀出來的；至於「其他所有細節，包括創辦人提供的描述、賣家留言與個人檔案文字，都是使用者產生的內容」。

同一張看起來一體的資料卡，一半是機器讀的，一半是人打的。分不出來的人，會把自填的團隊人數跟核實的訂閱數當成同一種東西。

核實本身還有兩層邊界：

金流商不同，讀到的東西不同。 我今天另外讀了 GoTall 的頁面——那是我們八月寫過的一款 iOS 訂閱 App——它接的不是 Stripe，是 Superwall，也就是 App Store 的訂閱資料。頁面標明來源是哪一家，但沒有說明那個金額是蘋果抽成前還是抽成後，也沒說退款與試用轉換怎麼算。核實告訴你數字從哪裡來，沒告訴你那個數字含不含什麼。

核實會過期。 這些頁面靠 API 金鑰同步，金鑰斷線之後頁面數字會凍結，但看起來仍然像現況。看的時候先找 last updated 那一行。

你可以帶走的三個問題

看到任何一個營收數字，照順序問三句就夠了：

第一，這是速率還是歷史？ MRR 和 ARR 是速率——它們回答「照現在這樣跑一年會是多少」。近 30 天、近 12 個月、all-time 是歷史，回答「已經進來多少」。把速率講成歷史，是這個題目裡最常見的一次滑動。

第二，這是經過的錢還是留下的錢？ 轉售、代操、抽成型的生意，流水和收入可以差三倍以上。問一句「你的 take rate 是多少」，比問營收有用。

第三，這個數字是誰算的、什麼時候算的？ 是金流商 API 讀出來的、還是本人打上去的？最後更新是哪一天？起算點是不是同一家公司？三個問題都問完，你就有辦法自己把一則貼文翻譯成一個範圍。

還有一件事我沒有答案：沒有任何一個口徑是「正確」的那一個。 投資人看 ARR、稅務看實收、經營者看現金，三種人問的是三個不同的問題。所以真正的判準不是「他有沒有灌水」，而是「他有沒有告訴你他用的是哪一格」。願意在貼文裡寫清楚算法的人——就算算法很寬鬆——比只丟一個漂亮數字的人，可信度高得多。

查核備註：MRR 與 ARR 的定義取自 Stripe 官方 Billing 分析文件；ARR 等於 MRR 乘 12 是業界通用寫法，Stripe 該頁本身未定義 ARR。AEO Engine 與 GoTall 的讀數是我 2026 年 8 月 27 日直接讀 TrustMRR 的公開純文字端點所得，兩份頁面標的最後同步時間分別是 8 月 27 日 02:04 與 8 月 26 日 23:51；表格裡的「MRR × 12」「近 30 天 × 12」與 8,244 乘 365 都是我自己按的，不是頁面上的數字，也不是這兩家公司的任何宣稱。Superwall 讀出的金額是否已扣除蘋果抽成，TrustMRR 頁面未說明，我也沒有向任一方求證。本文寫的是讀數字的判準，不是對任何一家公司的指控，也不構成任何投資建議。