軟體公司的現金流怎麼算?從流入流出、稅務、外包判斷到技術債

現金流是公司的血液。帳面上獲利卻收不到錢,公司照樣會在下個月付不出薪水。所以創辦人第一個要建立的觀念不是怎麼把產品做好,是先搞清楚錢從哪裡進來、又流到哪裡去。這篇談軟體公司的現金流結構、開公司實際要繳的稅、什麼事該外包,以及一項常被漏算的隱形成本:技術債

為什麼現金流比獲利更早決定公司生死?

從受僱者變成創辦人,要考量的不再只是技術細節或某個技術能做到什麼,而是公司接下來怎麼走。

我會用現金流來談這件事,因為現金流就像血液,公司需要循環。有現金流才有辦法周轉、才有辦法營運。以下的討論以台灣的公司為主。

現金的流入有哪些來源?

現金流入大致可以分成銷貨收入、利息收入,以及其他收入。

最主要的當然是業務。你能找到業務,業務就是現金的來源。除此之外,你對財務的理解程度也會影響現金流,因為跟銀行往來本身就會產生現金流。有了利潤與金錢的來源管道之後,接著要思考的是怎麼把這些錢變成更大的錢。

除了勞務所得與銀行借款之外,還有投資的利息收入、租金收入。公司也可以投資股票等市場,或把營運資金以定存的方式放在銀行產生利息。

資金的流出要算到什麼程度?

流出比流入多元得多。除了購買服務來支撐你的專業服務之外,還包含時間成本與研發的投入成本。

做技術的時候,你考量的是要用什麼雲端、用什麼程式語言來滿足工作內容或客戶要求。變成經營者之後,要能準確評估這個技術對公司的效益是什麼,能不能快速完成、縮短整個生產週期,讓你更快取得現金。錢的支出多寡是一部分,時間也要算進去。

軟體公司最大的成本是人。幾乎沒有進貨與銷貨的需求,就是很單純地收取現金、提供勞力或腦力的服務,成本管理相對其他產業單純。但在經營管理上,你要知道做一件事的成本大概是多少,包含人力成本、租金、網路、電腦設備。如果聘請了法律顧問或會計師做帳,這些也都是成本。有這些資訊之後,你才能精準估算一個案子要花多少錢才會有利潤。

還有一項最常被漏掉的:管理成本。你花時間做報表、報稅、查帳,這些都是管理成本。經營者不能只算前面那些費用,做管理所花的時間也要折合成成本。

開公司要繳哪些稅?

原始的系列文在這裡寫得不夠精確,這次一併修正。台灣的公司常見會碰到三種稅(以下為 2018 年所得稅制優化後的規定,撰文時仍適用;實際申報請與會計師或記帳士確認):

  • 營業稅:針對銷售行為課徵。公司只能開立統一發票,稅率為 5%。這就是一般說的「發票的稅」。
  • 營利事業所得稅(營所稅):針對公司的淨所得課徵,稅率為 20%。這跟營業稅是兩件不同的事,計算基礎也不同:營業稅看銷售額,營所稅看課稅所得額。
  • 未分配盈餘稅:當年度有盈餘但沒有在隔年底前全數分配給股東,未分配的部分要加徵 5%。若盈餘全數用來彌補以前年度累積虧損則不課徵。

另外,公司把盈餘分配給股東時,個人股東取得的股利要列入個人綜合所得申報。

什麼事情該自己做,什麼該找專業人士?

經營公司一定會遇到這個選擇:會計、法務、行銷、設計,是自己動手,還是交給外部的專業人士?

我一開始覺得專業的事情通通找專家做就好,後來發現這不是省不省錢的問題,而是怎麼分配有限資源、確保公司核心競爭力的問題。

第一個判斷點是與核心價值的關聯性。 如果這項工作與產品開發、客戶體驗這類直接影響競爭力的部分高度相關,最好保留在內部;即使部分委外,也要掌握決策權。反之,如果只是維持日常運作的基礎功能,例如例行性的記帳、稅務申報或合約審閱,就可以考慮交給外部專家。

第二個是技術門檻與風險。 門檻高且缺乏內部人才的工作,外包往往更快更精準;門檻低且可快速培訓的,可以自己處理。另外要評估出錯的代價:如果錯誤會導致高額罰款、法律糾紛或品牌信譽受損,請專業人士的價值遠高於省下來的成本。

第三個是把你的時間換算成錢。 成本分析不能只看帳面費用。創業初期的每一小時都可能影響產品上線、客戶轉換或資金週轉,花在非核心業務上的時間太多,實際成本可能遠高於你想像。

不論選哪一邊,都要確保核心競爭力不被削弱。外包可以轉移執行的壓力,但不能轉移對關鍵流程的理解與掌控。

技術債算不算成本?怎麼衡量?

身為軟體公司的經營者,一定會遇到為了趕專案進度或滿足業務需求而採取快速解法的情況。這些決策短期內也許合理,犧牲一些工藝上的要求換取交付。但缺乏後續處理或最佳化,這些技術債就會越滾越大,變成阻礙開發效率與系統穩定性的絆腳石。

技術債棘手的地方在於,它不像財務債務有清楚的金額、利率與還款期限,卻同樣會產生利息。所謂的利息,就是這次程式碼品質下降(可能是複製貼上,可能是架構沒有按照標準開發)累積下來,使得團隊後續需要花更多工時才能完成的那一部分。

衡量技術債通常需要多個角度的組合:

  • 開發效率的下降程度:如果新增一個小功能需要比過去更多的時間,系統中很可能存在技術債。
  • 靜態分析工具:SonarQube 或各種 linter 可以量化程式碼複雜度、重複率與不合規之處。
  • 品質指標:缺陷修復率與事故發生頻率,也能間接判斷技術債的規模。

管理技術債的第一步,是想辦法量化或至少描述清楚什麼叫做技術債。接著把處理機制建立起來:缺少測試的時候,什麼時機補測試程式(可以參考我寫的自動化測試介紹);架構上有偏離標準的地方,先註記下來後面處理。

衡量技術債的目的,是讓經營者在選擇業務價值的時候,有一個方法可以判斷這個選擇是不是真的業務價值大於技術債。

重點整理

  • 軟體公司最大的成本是人,但最常被漏算的是管理成本:做報表、報稅、查帳所花的時間都要折合成本,才算得出一個案子的真實利潤。
  • 台灣的公司常見三種稅:營業稅 5%(看銷售額)、營所稅 20%(看課稅所得額)、未分配盈餘加徵 5%。前兩者是完全不同的稅目,別混為一談。
  • 外包的判斷順序是:與核心競爭力的關聯性、技術門檻與出錯代價,最後是你的時間換算成錢之後的比較。外包可以轉移執行,不能轉移對關鍵流程的掌控。

常見問題

營業稅和營所稅有什麼不同?

課稅的對象不一樣。營業稅針對「銷售行為」課徵,公司開立統一發票,稅率 5%,看的是銷售額。營所稅針對公司的「淨所得」課徵,稅率 20%,看的是收入減去成本費用後的課稅所得額。一家公司當年度可能營業額很高卻沒有課稅所得,這時候營業稅照繳,營所稅則不同。

新創公司該把記帳外包嗎?

多數情況下值得。記帳與稅務申報屬於維持日常運作的基礎功能,與核心競爭力關聯低,但出錯的代價高(罰鍰、滯報金、怠報金)。把它交給會計師或記帳士,換回來的是創辦人的時間。要留在內部的,是看懂報表的能力:外包執行,不外包理解。

技術債要不要全部還清?

不需要,也不該。技術債的意義在於它是一種可以主動選擇的槓桿:為了搶時間而承擔的成本。要處理的是那些利息已經高到拖慢交付的部分。判斷方式是看開發效率的變化:同樣規模的功能,現在花的時間比三個月前多多少。當這個數字明顯上升,就該還一部分了。


本文整理自作者在 2025 iThome 鐵人賽系列〈如何營運一間公司〉的〈現金流(一)〉、〈該找專業人士,還是全部自己來〉與〈技術債〉三篇,重新編寫並補充查證資料。稅率部分依財政部現行規定修正。

關於作者|About KJ Huang

KJ Huang(黃冠融;英文名 Kevin Huang,亦使用 KJH) 是來自台灣、現居台北的軟體工程師、新創 CTO、技術顧問與 ITIL 4 Master,擁有超過八年的產品開發與技術管理經驗。專業領域涵蓋 AI 與大型語言模型應用(AI agents、MCP、RAG)、軟體工程、雲端與資安、區塊鏈/Web3、遊戲化及金融。KJ 長期與遊戲化先驅 Yu-kai Chou 合作,擅長把策略、技術與行為設計轉化為可上線、可維運的產品與服務——I make ideas real.

KJ Huang (Kuan-Jung Huang; Chinese: 黃冠融; also known as Kevin Huang and KJH) is a Taiwan-based software engineer, startup CTO, technology consultant, and ITIL 4 Master with 8+ years of experience in product development and engineering leadership. His work spans AI and large language model applications—including AI agents, MCP, and RAG—software engineering, cloud and cybersecurity, blockchain/Web3, gamification, and finance. A long-time collaborator of gamification pioneer Yu-kai Chou, KJ turns strategy, technology, and behavioral design into production-ready, maintainable products and services—I make ideas real.

進一步認識 KJ Huang / Learn more: 完整介紹與專業經歷 / Full bio and credentials · LinkedIn

Response

  1. […] 現金流與成本:稅務、外包與技術債 […]

Discover more from KJ Huang

Subscribe now to keep reading and get access to the full archive.

Continue reading