業財稅一體化是一種將業務流程、財務會計與稅務申報緊密結合的管理模式。通過高度的信息系統整合，實現數據共享和流程優化，從而提升企業的效率和合規性。本文將從業務的角度出發，讓您認清整體系統的本質，以實際的業務訴求切入，一步步的構建出一套完整的B端系統框架。

本章介紹業財稅一體化的本質，主要講解業務，是理解業財稅架構建設的前提，需要大家用心閱讀理解。

一、業財稅由何而來？

業財稅最早是由我國的財政部在推動管理會計發展過程中提出。2016年6月，財政部發布了《管理會計基本指引》，明確提出管理會計應與單位相關領域、層次、環節相結合，實現財務和業務的有機融合。

這一文件為“業財融合”提供了政策支持，并逐漸成為學術界和實務界廣泛接受的理念。隨著實踐的深入，從“業財融合”逐步演化為更加全面的“業財稅一體化”模式，不僅涵蓋業務和財務的整合，還將稅務管理納入其中，實現了企業三大流程——業務流程、財務流程和稅務管理流程的有機結合。

這種模式利用智能化的管理軟件或SAAS系統，確保企業的財稅管理更加標準化和自動化，有助于降低運營成本并提高決策效率

二、業財稅的核心是什么

業財稅一體化的核心在于整合業務、財務和稅務的數據與流程，以實現全面、實時的信息管理。這不僅提高了工作效率，還優化了資源配置，降低了經營風險。例如，在業財稅一體化模式下，當業務發生時，相關的財務和稅務數據能夠即時更新，管理者可以快速獲取關鍵信息，從而做出更準確的決策。

此外，業財稅一體化的實施路徑包括建立統一的信息系統、優化流程和標準化操作。通過這些措施，企業能夠在一個平臺上管理所有相關數據，避免重復操作和數據冗余，從而顯著提高準確性和工作效率。

總的來說，業財稅一體化不僅提升了企業的管理水平，還增強了企業在復雜市場環境中的競爭力。企業應積極探索和實踐這一模式，不斷優化管理體系，以應對市場的多變挑戰。

三、系統的目標用戶

業財稅系統的主要目標用戶包括中大型企業、高新技術企業、跨國企業、代賬行業企業和對合規性要求高的企業。

1. 中大型企業：這類企業通常具有復雜的業務交易和龐大的財務數據量，需要高度自動化和集成化的系統來提高管理效率。業財稅系統可以自動從業務交易中生成財務憑證，確保數據的準確性和及時性，從而提升財務報告的速度和可靠性。
2. 高新技術企業：這些企業常常涉及到研發費用加計扣除等復雜的稅務優惠問題。業財稅系統可以幫助高新技術企業更好地管理稅務優惠申請流程，確保能夠最大化地享受稅收優惠政策。
3. 跨國企業：跨國企業需要處理多幣種、多稅區的復雜稅務和財務問題。業財稅系統提供統一的平臺，簡化了跨國經營管理，支持智能配貨和精準鎖庫功能，優化物流和倉庫管理，提高供應鏈效率。
4. 代賬行業企業：隨著業務的快速發展，這類企業需要靈活和高標準化的財務管理系統支撐其持續成長。且涉及行業多種行業類型，業財稅系統可以提供可擴展的解決方案，能夠滿足企業在成長過程中不斷變化的管理需求。
5. 對合規性要求高的企業：金融、醫藥等行業對合規性的要求尤為嚴格。業財稅系統自動化地保障數據準確性和合規性，確保稅務和財務的嚴格合規，為企業帶來安心。

四、搭建整體架構前

當我們理解了業財稅的核心，以及目標用戶后，便可以開始做搭建前的準備了。

1. 選取目標用戶，市場調研
2. 掌握相關財務知識
3. 組建好團隊
4. 遵從國家相關法律法規

其中第2、3、4點本文不做贅述，以下重點講解第1點的市場調研

以代賬行業企業為例：

我們可以通過用戶訪談、問卷調查等方式可以和目標用戶進行溝通，了解在沒有系統的情況下，用戶（會計們）的日常工作有哪些，涉及哪些第三方關聯系統，工作節點的前后流轉關系等。

可以看出月初的【匯總客戶交易】工作是后續月中、月末工作的來源，故此在設計該模塊的時候，需要注意的事項有：

• 針對于不同地區的客戶，需要獲取的發票及其他交易憑證需要全面、準確、真實。若有缺少則影響后面的記賬和稅務申報工作。若在稅務申報環節錯報，或漏報都會有巨大影響，嚴重時還會使客戶企業信用降級，產生滯納金等。
• 在設計此模塊時，應充分調研這些發票和憑證的來源有哪些，直接從源頭獲取比從客戶企業拿完整的多，例如開票軟件，稅局平臺等，詳細內容可見后續文章《漫談業財稅一體系化建設4 –票據與記賬》。

其次，在整月的工作中，不可或缺且最重要的三個工作是【編制記賬憑證】、【編制財務報表】、【納稅申報（含繳款）】，而這些工作的來源都取決于月初的工作【匯總客戶交易】。所以在設計系統時，針對這幾個重點模塊的注意事項是：

• 關聯性業務流程打通，讓業務自上而下進行流轉，同時考慮用戶逆流程的情況，增加校驗提示或禁止功能
• 編制記賬憑證時，可以將業務進行拆解，將客戶人工填寫的字段抽離出來，設計系統的算法，自動生成憑證。再配套審核機制，大大減少用戶的時間成本。
• 編制財務報表時，可以在報表內增加算法，自動從關聯模塊獲取數據，減少用戶手動填寫的操作，但同時仍要支持用戶可以手動填寫數據并配置校驗規則，這樣當用戶填寫錯誤的情況，可予以報錯提醒和制止。
• 在納稅申報（含繳款）環節，需要和稅局進行交互，將系統內的稅表數據報送至稅局，獲取報送結果回傳至系統，并且在申報和繳款的最終環節都需進行金額的比對校驗，防止錯報和漏報。

上述每一項環節的功能點都可以細細拆解，在后續文章會詳細介紹，此處暫不做贅述

五、搭建整體架構中

好了，接下來可以正式進入搭建整體架構的環節（依舊以代賬行業企業為例）

首先，確認系統的幾大層次，分別是

• 用戶交互層
• 產品應用層
• 數據層
• 基礎服務層

1. 用戶交互層

我們需要考慮最終用戶的操作場景，代賬行業目標用戶大部分都是賬務會計，稅務會計等，協同工具大多為電腦，其次為手機，再加上近年來興起的AI。我們可以設定為3個用戶交互場景

在系統初期，可以只考慮PC端，等系統穩健成熟后，再考慮另兩個端。

2. 產品應用層

2.1 劃分第一層級應用

1）按照用戶實際的工作場景，有先后順序關聯的可以分為

• 先取票據（匯總客戶交易憑證）
• 然后記賬（編制記賬憑證、登記會計賬簿、賬目核對）
• 接著制表（編制財務報表）
• 最后辦稅（納稅申報、客戶報告）

2）按照用戶實際的工作場景，沒有先后順序關聯的可以分為

• 資產（資產管理、折舊與攤銷、明細賬表）
• 薪酬（員工檔案、社保公積金、工資表、個稅）
• 存貨（存貨管理、庫存核算、明細賬表）
• 風控（風險控制）
• 籌劃（預算、稅務籌劃）
• 咨詢（客戶溝通、解答問題、稅務咨詢）
• 增值服務（工商注冊機變更）

如此大致應用已經劃分完成，還需要繼續把每個應用進行拆分業務點。

2.2 劃分第二層級業務點

1）舉例1：【收票】這個應用，是為了從各個來源渠道獲取銷項發票、進項發票、費用發票、其他票據，從而給后續的應用提供全面數據的支撐。所以業務點就要思考用戶對這些發票會有哪些處理呢？

• 用戶需要拿到發票，獲取里面的數據
• 用戶需要拿到銀行的對賬單及其他單據
• 進項發票會有進項稅額轉出的場景
• 進項發票會有勾選抵扣的場景
• 用戶需要有頁面匯總查看某月所有的發票數據
• 用戶需要對這些發票進行分析
• 用戶需要根據發票制成記賬憑證
• 用戶需要……

綜合一下，就可以得出下圖

2）舉例2：【記賬】這個應用，是為了將各個會計業務記錄成記賬憑證，匯總到會計賬簿里。所以業務點就要思考用戶會從哪些業務模塊生成記賬憑證呢？記賬憑證生成后如何匯總到會計賬簿呢？

• 用戶需要獲取歷史的賬務數據
• 用戶需要再各個業務模塊里單獨生成記賬憑證
• 用戶需要制作記賬憑證，記賬憑證包含數據有：日期、字號、摘要、會計科目、幣種、借方金額、貸方金額、合計、制單人、制單時間、審核人、審核時間
• 用戶需要記賬憑證展示每個科目的余額
• 用戶需要每期進行期末結轉，每年進行年度結轉
• 用戶需要將會計憑證登記會計賬簿
• 用戶需要……

綜合一下，就可以得出下圖

3）舉例3：【辦稅】這個應用，是為了每期的稅表報送至稅務局，有稅款時可以進行繳款。所以業務點就要思考用戶每一期需要申報哪些稅表？如何申報？申報錯誤如何處理？

• 用戶需要知道負責的企業每一期需要申報的稅表是哪些
• 用戶需要查看管理這些稅表
• 用戶需要在稅局規定的時間內進行正確申報
• 如果稅表申報錯誤需要立即通知到用戶，并給用戶改正的機制
• 用戶在稅表正確申報后，如有稅額需要進行繳款
• 用戶需要……

綜合一下，就可以得出下圖

4）舉例4：【資產】這個應用，是為了讓用戶可以管理企業的各項固定資產和無形資產。所以業務點就要思考用戶如何管理這些資產？這些資產涉及的賬表會有哪些？

• 用戶需要登記固定資產卡片
• 用戶需要在規定周期內給固定資產進行折舊
• 用戶需要再規定周期內給無形資產進行攤銷
• 用戶在購進/出售資產時進行記賬憑證的記錄
• 用戶需要……

綜合一下，就可以得出下圖

5）各位讀者可以思考一下其他的應用該如何劃分？歡迎聯系我一起探討

3. 數據層

這一層次比較偏技術了，在整個系統的運作過程會產生大量的繁雜的數據，內部人員和外部人員對數據的處理也會有很多，所以在這一層次可以對數據進行大致的分類，針對同類型的數據進行相似的處理或分析

我們按照數據產生的來源可以分為

• 財務數據：來源于財務應用模塊，例如發票、資產、存貨等
• 稅務數據：來源于稅局，和稅務應用模塊，例如稅源信息、申報表內數據、申報檔案等
• 行業數據：來源于稅局，例如企業基本信息、營業信息、行業分類等
• 工商數據：來源與工商信用管理公式系統，例如登記注冊信息、聯系人信息、社保信息等
• 輿情數據：來源與社會輿情，例如國家政策調控，災情相關的減免稅政策等
• 指標數據：來源于相關財政法規規定的各項費用指標、企業經營指標等

4. 基礎服務層

最后一層是基礎服務層，也就是系統最底層的且通用性的服務。我們需要把各個產品應用層里通用型的服務剝離出來，作為公用組件，如此就可以避免重復造輪子的情況。

例如用戶操作所有模塊都需要受到權限的限制，可以操作什么，不可以操作什么?？梢钥吹绞裁磾祿?，不可以看到什么數據。

例如會計科目，像前面提到的【收票】、【記賬】、【報表】、【辦稅】等業務模塊都需要用到會計科目，而會計科目又都是由國家有關部門規定好的準則來執行，所以屬于通用性服務。

例如報表之間的算法，會計日常工作中涉及的賬簿和報表，彼此之間都存在勾稽關系。因此，可以將這些內在的關系抽象成表間算法，作為底層服務給其他模塊予以支撐。

• 《會計報表-資產負債表》的「庫存現金」科目，可以同樣在《會計報表-現金流量表》、《科目余額表》、《總賬》、《明細賬》中列示；
• 《企業所得稅申報表》里的「收入」也可以在《會計報表-利潤表》里列示等等

還有用戶管理、消息管理等等，這些都可以作為通用型的組件，整理完成后就可以得到下圖

如此我們就搭建完4個層次了，這是一套系統的基本構建。如果再考慮更長久一點，我們還可以再繼續橫向擴充，思考一下運營和生態合作的方向

• 思考系統完成后運營的幾個大方向，目前可不用細致規劃，畢竟離系統上線運行還有很長的時間
• 思考系統可以合作的機構，例如代賬行業可以和財會類職業學校合作，好比以前財會類學校會讓學生學習使用金蝶和用友的軟件一樣。目前也可不用細致規劃，需要等系統穩健且在市場具備一定影響力后再開始啟動，切勿操之過急。

如下圖所示

最后的最后，我們就可以得出一張完整的B端業財稅系統架構圖！

六、搭建整體架構后

在整體架構搭建完成之后，作為產品經理還需要對系統的產品應用劃分模塊，劃分產品優先級，確定產品目標及里程碑，確定相關負責人或負責團隊等，所以在這一過程中，不可謂不艱辛！