一文搞懂會計科目設計原理及運維要點
在企業(yè)的財務管理中,會計科目的設計和維護是核心環(huán)節(jié),它不僅關系到財務數(shù)據的準確性,還直接影響到企業(yè)的決策和合規(guī)性。這篇文章,我們一起來學習一下相關知識。
會計科目是業(yè)務事項按會計準則要求的一種歸納或分類,是在會計要素基礎上的一種細分,包括科目編碼和科目名稱;在高級的ERP中,科目名稱支持多種語言,可靈活切換,如中文、英語、維吾爾語等。
會計科目的內容反映科目之間的橫向聯(lián)系,會計科目的級次(層級)是以會計科目編碼為載體,反映科目內部的縱向關系。比如1002是“銀行存款”科目,100201 “工行”是銀行存款下的明細(二級)科目,全稱為“銀行存款_工行”,他倆為父子關系。
一、會計科目編碼要點
會計科目編碼由數(shù)字構成,國內ERP的科目編碼有層級關系,如一級、二級、三級,國外ERP如SAP也有層級,但Oracle則用彈性域實現(xiàn)的(類似字段),國內外ERP的對比后續(xù)單獨寫一篇介紹,本文如無特例說明均指國內ERP。
一級科目編碼一般為4位,也有3位,第一位為賬戶性質,就好像我們名字的姓一樣,是一種分類,表示其是屬于資產類還是負債類,開頭1是資產、2是負債、3是共同類、4為權益類、5為成本類、6為損益類。
二、會計科目級次(層級)關系
會計科目的級次主要為方便不同的使用者,如管理層和外部信息使用者(如審計)只需關心一級科目,了解粗略數(shù)據,如應收賬款多少、應付賬款多少;而具體財務人員則需要根據明細科目進行具體分析,檢視經營成果。
企業(yè)可靈活設立多個層級,如二級、三級及至五級、六級,從使用角度與便利性考量,一般不超五級。
會計科目級次模式:
a、422式,科目編碼級次為4-2-2-2:即除一級科目由四位數(shù)字組成外,其他各級的編碼均為兩位數(shù)字,科目全稱用下劃線將多級連接起來,如100102 銀行存款_建行。這種設置清晰、一目了然。
b、423式,即一級科目編碼是4位數(shù)字,二級編碼是2位數(shù)字、三級編碼是3位數(shù)字,如還有四級則是4位數(shù)字,依此類推,這種從科目編碼看有層次感。
c、322式,一級科目的編碼是3位數(shù)字,二級科目的編碼是2位數(shù)字,以此類推。
總之,會計科目的編碼級次是根據會計管理的需要和科目分類的邏輯來設計的。不同的編碼級次適用于不同的管理需求和科目細分要求,確保了會計信息的準確性和可追溯性,在賬套開啟時設定后不允許修改。在我國一般為422式。
三、總賬科目(統(tǒng)馭科目)與明細科目
1、總賬科目
在SAP也稱統(tǒng)馭科目,指一級科目,是財政部制定的,實質是會計要素(資產、負債、所有者權益、成本、損益)的反映,企業(yè)可以根據業(yè)務所需靈活設定。
總賬科目主要是用于生成法定財務報表,它們與法定財務報表的每一行有映射關系,但可能是多對一,即幾個一級會計科目對應著報表的一項;
總賬科目在系統(tǒng)實現(xiàn)層面就是一張總賬匯總表。
以最新會計準則為例,總賬科目主要有以下幾種:
2、明細科目
一級以下的科目為明細類科目,只需滿足會計要素在交易層面最細的分類要求,即每筆會計憑證上出現(xiàn)的最細的科目,可以由企業(yè)自行設置。明細科目只允許末級科目可以在分錄中記賬,中間的科目僅做分類、匯總使用,如下圖:
四、科目設置與管理
1、集團統(tǒng)籌下的多公司主體科目管理
企業(yè)出于稅務籌劃或戰(zhàn)略發(fā)展要求,會設立多個公司主體,比如美團以美團科技有限公司為核心企業(yè)之一,設立幾十家公司主體,如江蘇三快在線科技有限公司、深圳三快信息科技有限公司、湖南三快在線科技有限公司等等;這么多公司對科目管理提出較高要求,在迅速支撐會計核算的同時,確??颇縿?chuàng)建的科學性、可持續(xù),避免同一科目出現(xiàn)多個編碼或名稱,否則給報表編制、合并報表等工作帶來不小的麻煩。
對于集團下多公司主體時,一般每個主體會單獨設立賬套。每個賬套的會計科目,無論編碼還是名稱,均要求三“統(tǒng)一”:統(tǒng)一創(chuàng)建、統(tǒng)一分配、統(tǒng)一回收;
2、科目管理規(guī)則與職責要求
科目管理,應由專人審核專人在集團層面創(chuàng)建,再分配給所需的賬套;三級及以上科目禁止從各主體賬套自行創(chuàng)建。同時負責審核科目的崗位應是中、高階財務崗,具有全局視角與管理會計思維。
比如管理費用下設二級科目“水電氣暖費”,然后在下面又設了幾個三級科目:水費、電費、燃氣費、供暖費。這樣設三級科目,不如取消“水電氣暖費”二級科目,直接把水費、電費、燃氣費、供暖費都設為管理費用下的二級科目。
是否需要設“水電氣暖費”這個二級科目,要考慮它有什么用,是否只起到加總四個三級科目發(fā)生額直接取數(shù)的作用?其實多數(shù)公司設這種僅起匯總作用的二級科目,只是因為最初管理需求不需要單獨看水、電、氣、暖的費用,所以覺得既然它們都屬于辦公室里發(fā)生的公用事業(yè)支出,就設一個科目即可,但沒想到后來需要單獨看了,所以就只好在它下面新加幾個三級科目。
出現(xiàn)這種情況,一是因為設會計科目時并未深入洞察管理需求;二是因為公司由于業(yè)務規(guī)模和復雜度發(fā)展所以管理精細度在不斷提升,造成以前的科目設置粗放而無法滿足取數(shù)的要求。這些都對維護人員提出較高要求,要有一定經驗與前瞻性。
3、科目級次與核算維度
前面我們知道明細科目是一級科目的細分,在核算中還有一個概念,核算維度(也稱輔助項目、核算項目)。維度是財務管理中一個關鍵概念,它指的是對財務數(shù)據進行分析和報告時使用的一個或多個分類標準。它允許企業(yè)從不同的角度切入,對財務數(shù)據進行多維度的分析和解讀。通過維度,企業(yè)可以更深入地理解財務數(shù)據背后的業(yè)務活動,支持更復雜的決策需求。
科目與維度構成了財務報告和分析的基礎,確保了財務信息的準確性和完整性,幫助企業(yè)進行詳細的財務分析和報告。會計科目的層級和維度的合理設置對于企業(yè)的財務管理至關重要,有助于準確記錄每一筆經濟業(yè)務的發(fā)生,為管理層提供決策支持,并加強內部控制。
實務中,核算是用明細科目還核算維度,考驗其財務經驗與產品功底。比如“銀行存款”一級科目,共有4個明細:工行、建行、中行、農行,各有100元,用明細科目如下:
如果以核算維度記賬,則是下圖這樣的,帶核算維度的一級科目竟然有多筆:
由上看出,用明細科目更清爽、明白、易統(tǒng)計。那何時用明細科目、什么場景用核算維度呢?老曾總結幾點:
- 要素法:核算對象屬于會計要素的,則設立明細科目,否則用核算維度;比如:電話費,屬于費用,會計要素之一,應用明細科目核算;而“供應商”、“部門”,與會計要素無關,屬于業(yè)務屬性的一種表現(xiàn),可用核算維度表示。這種分類需要扎實的會計專業(yè)知識,熟悉業(yè)務。
- 套娃法(推薦):類別如果可能有子類、孫類時,那應使用明細科目,這樣能完美體現(xiàn)父、子、孫這種層級關系,比如【應交稅費】,下面有【應交增值稅】、【應交消費稅】、【應交所得稅】等子類,【應交增值稅】下面還有【進項稅】、【銷項稅】、【進項稅轉出】等孫類;如果場景只是一層同級關系,且不會向下衍生子、孫關系時,則用核算維度。比如供應商,所有供應商都是一類,不會有子供應商了。
c.枚舉法:比較適合維度的有以下幾個經典場景,如部門、項目、地區(qū)、產品線、供應商、客戶、費用類型、員工等;
當遇到交叉屬性時,則要通過核算維度+主數(shù)據實現(xiàn),比如核算收入時,掛了【客戶】維度,同時想分析客戶所在區(qū)域(華南、華北等)、規(guī)模、性質(直營、加盟)等,后面這些都是基于客戶衍生出來的維度或特征,且經常會變,放在會計分錄的維度不合適,可以在客戶主數(shù)據維度這些需要的特征,在統(tǒng)計時關聯(lián)此特征進行分析。
會計科目到底設幾級合適?如果能做到在深入理解公司業(yè)務模式后用系統(tǒng)性思維搭建會計主數(shù)據結構(會計主數(shù)據結構=賬套+會計科目+核算維度),會計科目設2-3級就夠了。級次設得多,通常都是因為沒全面或沒及時理解公司業(yè)務模式,或者沒有統(tǒng)籌思維,想到哪加到哪。
另外,明細科目的層級與核算維度的取舍會隨著企業(yè)發(fā)展、管理的精細化而演進,并不是一成不變的。按上述幾點要求基本能比較好的判斷是用明細科目還是核算維度。
如果硬把核算維度設成子級科目,就意味著它只能有一個上級科目,如果想掛多個科目,就要在每個科目下都設一個相同的子級科目,本來科目與核算維度是加的關系,這樣反而變成乘的關系!比如部門這個核算維度如果設成會計科目,假設一共10個部門,管理費用有5個二級科目,就會變成每個二級科目下都要設10個三級科目。于是,管理費用下就有5 x 10共50個三級科目,想想科目表得有多長!如果是多個核算維度,那更沒法玩,想想就恐怖!
五、系統(tǒng)設計
1. 會計科目在系統(tǒng)實現(xiàn)層面上,由一張主表+多張關聯(lián)表實現(xiàn),主表為科目表,關聯(lián)表有科目類別表、核算維度(組)表、現(xiàn)金流量表等。
2. 具體結構設計如下圖:
作者:業(yè)財老曾,公眾號:業(yè)財老曾談,專注財務信息化20年
本文由 @業(yè)財老曾 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發(fā)揮!