漫談業財稅一體系化建設1 –整體架構

0 評論 3374 瀏覽 29 收藏 20 分鐘

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

六、搭建整體架構后

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

本文由 @尺素 原創發布于人人都是產品經理。未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!