在做對賬系統之前，需要掌握一定的財務知識。對賬系統很難做，網絡上基本沒有手把手教怎么做對賬系統的。本文作者結合自身所經歷的對賬系統項目進行自我梳理整合輸出，希望能夠對你有所幫助。

導讀

本篇文章基于我本身所經歷的對賬系統項目進行自我梳理整合輸出。

雖然我盡可能往通用性去編寫，但它還是不一定適合所有系統及業態，而我本人也是在不斷的學習自我提升中，或許文章內容有些錯誤或描述不嚴謹的地方，懂行的老師辛苦幫忙指出來，我會修改優化。

所以，這篇文章我僅提供參考。

在做對賬系統之前，系統的學習財務基礎知識是有必要的，要不然你在需求溝通時，或許連需求方（財務人員）的話都聽不懂。

財務人員，有一套專業的財務語言！很有意思的，大家可以去了解一下！

一、前言

互聯網的迅猛發展，帶動了各行各業的數字化轉型，數字化的轉型又免不了要從2C，2B兩個大方向上下功夫。

前幾年，大家忙于搭建屬于自己的業務及管理系統，通過中臺集群或SaaS或PaaS模式，讓自己進入互聯網時代的賽道，時至今日，隨便去哪個地方，都可以小程序、APP、三方平臺進行購物點餐預約等。

在面向消費者的方向，2C的業務遍地開花；而在后方，2B能力也在不斷的提升，2C與2B的融合也為各行業品牌帶來了一個較大的痛點：

對賬難。

為什么會對賬難呢？

數據種類多、來源多、樣式多、完整性參差不齊、準確性參差不齊、各系統或三方提供數據時間節點一致性弱、對賬功能靠后前端感受不到；

對賬系統介于業務與財務系統之間，市場沒有通用能力強的對賬系統。

它所在位置如下圖：

從上圖可以看到，他的上游有訂單和支付（賬單），下游有財務（用友、金蝶等），還有各類的財務能力工具，如發票管理等。

在寫這篇文章之前，我有在網絡上、書籍中去學習了解行業中對賬系統的做法，總的來說，因行業問題和專業性問題，各有優劣，同時，我自己也主導過多次對賬系統從0-1的建設，有相對簡單一點的，也有復雜一點的，其中涉及的難點巨多。

復雜一點的，當時系統評審會就連續開了十個工作日以上，平均每天不低于6小時的會議時間。而且，對賬系統介于業務與財務系統之間，單純的了解業務是不可行的，必踩坑，所以同步需要了解財務的相關知識，具體的后文會講解一部分。

在這幾年對賬系統的建設過程中，從十位以上財務從業人員、財務專家那里學習到很多財務對賬相關的知識。

有些知識在對賬系統中的運用很重要，但在前面所了解學習的對賬相關文章或教程中都沒有看到過，而本人也覺的這部分內容在對賬系統中作用性很大，在后續的篇幅中也會進行講述。

對賬系統很難做，網絡上基本上沒有手把手教做對賬系統的，很多的內容似是而非，前后翻閱能把人看懵。

想著既然要寫這篇文章，不如就干脆寫的細一點。

因為會寫的比較細，所以對賬相關的文章肯定不是短時間能寫完，畢竟不是一兩篇的篇幅就能講清楚的。

會分成多次更新，更新頻率“隨緣”，但肯定會更新完。

第一篇會為大家普及一些財務知識，以方便大家迅速進入有效的財務基礎理解階段。

同時，在第一篇中先預設一個對賬系統建設的需求場景，把需求進行羅列，作為后續詳細拆的來源。

二、財務基礎

2.1 對賬的基本概念

對賬，就是核對賬目，是指在會計核算中，為保證賬簿記錄正確可靠，對賬簿中的有關數據進行檢查和核對的工作。

對即是核對，賬即賬目。

在互聯網產品中，檢查指的是對需要對賬的數據進行查驗，保證數據的完整性與準確性，一般會在不變動數據的情況下，對該部分數據進行有效獲取、校驗、標準化（統一格式）。

核對指的是一對一的核實對比，比如訂單與賬單對比，訂單指的是電子或紙質合同，賬單指的是資金記錄（支付寶賬單、銀行賬單等）。

對賬就是將需要對比的數據，經過校驗及標準化后，進行一對一的對比，以保證數據記錄的可靠，同時找出雙方的差異，并支持對差異數據進行溯源處理。

2.2 本方與對方的概念

對賬是指將需要核對的數據（一般為訂單及賬單）進行一對一的對比，在對比前，需預設本方與對方。

本方指的是可靠性較高（主觀判斷）的一方數據，或需主要對比的一方數據。

對方指的是被對比的一方數據。

在訂單和賬單兩種數據類型上，理論上任何一方都可以被定義為本方，一類數據僅能被定義為某一方，不可同時將某數據既定義為本方又定義為對方。

2.3 原始憑證

會計憑證按照編制的程序和用途不同，分為原始憑證和記賬憑證。

原始憑證是在經濟業務發生時取得或填制的，用以記錄和證明經濟業務發生或完成情況的憑證。

我們在購買商品或服務時，所獲得的原始票據，即為原始憑證，如：

去餐廳點餐時，點餐完成服務員提供的點餐單（有的有價格有的沒有價格），付款時手機付款記錄；

去超市購買商品時，付款完成，超市所提供的交易清單及付款記錄；

通過互聯網購物，產生的訂單，訂單對應的支付記錄（支付寶、微信等）均屬于原始憑證。

因此，原始憑證的種類很多，如發貨單、收貨單、領料單、銀行結算憑證、各種報銷單據等在業務發生過程中產生的依據都算作原始憑證。

從對賬業務來說，涉及的憑證偏向于訂單、賬單、支付單等原始憑證。

2.4 記賬憑證

記賬憑證，會計專業術語，是財會部門根據原始憑證填制，記載經濟業務簡要內容，確定會計分錄，作為記賬依據的會計憑證。記賬憑證亦稱分錄憑證，又稱記賬憑單，按照登記賬簿的要求、確定賬戶名稱、記賬方向（借貸方向）和金額的一種記錄，是登記明細分類賬和總分類賬的依據。

那會計分錄又是什么？

我們日常如果有記賬的習慣的話，一般會這么記：

• 購買商品：電腦，單價8000元，數量1臺
• 支付總額：8000元
• 支付方式：支付寶（招商銀行卡）

而，財務側在對原始憑證確認后，記賬的方法叫做復式記賬法（借貸記賬法），其所記錄的內容，叫做會計分錄，會計分錄基于復式記賬法有標準的格式。如：

• 借：庫存商品-電腦 8000元
• 貸：銀行存款-招行 8000元

基于借貸邏輯（參考資產負債表），我們可看出，庫存商品-電腦屬于資產類科目，在本分錄中屬于借方，代表資產增加，銀行存款-招行屬于資產類科目，在本分錄中屬于貸方，代表資產減少。

即，在我所有的資產中，庫存商品增加了一臺電腦，但銀行存款減少了8000元。

如果購買商品時，商戶開具了發票，在借方的分錄應該是庫存商品-電腦不含稅價與稅金兩條記錄，這里就不細寫了。

因此，記賬憑證其實就是會計分錄，會計分錄就是財務人員的標準記賬方法。

記賬憑證是由會計人員對審核無誤的原始憑證或匯總原始憑證，按其經濟業務的內容加以歸類整理，作為登記賬簿依據的會計憑證。會計人員填制記賬憑證要嚴格按照規定的格式和內容進行。

專用記賬憑證，是指分類反映經濟業務的記賬憑證。這種記賬憑證按其反映經濟業務的內容不同，又可以分為收款憑證、付款憑證和轉賬憑證。

在對賬系統中，對賬的整體動作，其實相當于財務人員對原始憑證的對比與審查，審查完成的記錄成會計分錄，最終生成明細賬（有多少訂單就有多少條明細）及匯總賬（無論多少條，只要在我計算的歸屬范圍內的，統一匯總成一條）。

因此，對賬系統完成對賬后，會根據用戶實際訴求，生成明細賬及總分類賬，即記賬憑證。

2.5 單邊

在一對一對賬完成之后，發現某一條數據對應的另一方無數據，一般稱為單邊。

比如有訂單信息，但無與訂單對應的賬單數據，那么本次對賬差異稱為訂單單邊。

比如有賬單信息，但無與賬單對應的訂單數據，那么本次對賬差異稱為賬單單邊。

舉例以訂單為本方，某訂單金額為300元，但對賬時未找到賬單，則對賬差異為300元，差異類型為訂單單邊。

其公式為：本方金額-對方金額（雙方均可以是合并金額）

公式金額等于0為平賬，金額等于本方金額為本方單邊，金額等于對方金額為對方單邊，金額大于零且小于本方金額或金額為負責默認為金額不一致，屬于長短款，需溯源查詢差異原因。

2.6 長短款

財務側的現金長短款是指在盤點和核對庫存現金時，發現除挪用現金、白條頂庫、超限額留存現金等情況以外原因的現金日記賬余額與庫存現金數額不符。在對賬系統中，一般代表應收與實收不符（非單邊）。

對賬時，除了會發生2.5項所述單邊現象，也會存在長短款現象。

• 長款：應收100元，實收120元，計算后，出現了20元的額外收益，這部分即為長款。
• 短款：應收120元，實收100元，計算后，少收20元，這部分即為短款。

2.7 軋（gá）差

軋差是指利用抵銷、合同更新等法律制度，最終取得一方對另一方的一個數額的凈債權或 凈債務，如市場交易者之間，可能互有內容相同，方向相反的多筆交易，在結算或結束交易時，可以將各方債權在相等數額內抵銷，僅支付余額。

上述為財務側軋差的概念，或許難以理解，但舉個例子就明白了：

預設A和B都很講信用，A欠B10萬元，B欠A4萬元，沒有軋差的情況下，B需要向A支付4萬元，而A需向B支付10萬元；軋差后，則A對B的凈欠額為6萬元，A只需向B直接支付6萬元。

在對賬系統中，軋差一般指的是兩兩之間金額匯總之后的總差額。

2.8 平賬與差異（差錯）

這里的平賬是指對賬系統的對賬結果：對賬對平，而不是財務管理所說的讓各個分類賬戶的金額與其匯總賬戶的金額互相核算相等，達成會計中的所說的“賬賬相符”。

差異（差錯）指的是未對平的數據。一般差異包括單邊、長短款等。

差異的原因一般包括：

• 單邊，即本方或對方無數據；
• 長短款，即本方與對方有數據，但對賬金額不一致。

單邊及長短款可以依靠系統進行初始預判斷，再人工復核；但長短款的原因一般需要人工判斷及確認。

2.9 財年財月

財年指財務年度，財月指財務月。

一般來說，我國的財年指的是自然年，財月指的是自然月。

國外的財年和財月有遵循自然年自然月的，也有跳出自然年與自然月單獨設定的，比如美國部分州，會將企業成立當年的10月份定義為下一年的財年初始，10月份為下一財年第一個財月，且其財月并非自然月，而是以445標準執行，即第一季度第一個財月是從10月1日起的四周，第二個財月為后續四周，第三個財月為再后續五周，所以每個財月都跨自然月。

一般我國國內系統對應的財年財月以自然年自然月為準。

2.10 其他

只要涉及與財務相關的系統，絕對不允許對源數據（原始憑證）進行任何修改。

除了最終匯總金額小數位控制，其他任何階段，在計算過程中，不可進行四舍五入、小數位限制等操作。

本章2.3-2.8僅作基于對賬系統的簡單描述，其在財務中所代表的含義相對較為復雜，個人建議應該從財務的角度去豐富相關的知識。

同時，沒有財務基礎想走對賬或需要走對賬發展路線的，建議先惡補復式記賬法、資產負債表等；若有財務基礎的，忽略本篇財務基礎部分，當然，若發現我有描述不當的，還請不吝指出，我將請教確認后進行修改更新。

三、需求場景

某零售品牌2C業務擴展迅速，對賬系統老舊，且人工干涉較多，原對賬中心已經跟不上業務發展，需建設最新對賬中心。

3.1 現狀

• 法人A：負責自有渠道，包括APP、微信小程序、支付寶小程序；
• 法人B：負責三方渠道，包括京東、天貓、美團、抖音；
• 支付方式：APP對接微信、支付寶、云閃付，以直連模式接入；
• 儲值卡：APP支持儲值卡支付，支持儲值卡+三方組合支付；
• 儲值卡賬戶：合規的單用途預付費卡，消費者儲值統一存入法人A管理賬戶，消費者使用儲值消費時，從法人A管理賬戶支付至門店/渠道賬戶；

3.2 建設目標

搭建對賬系統，以三方賬單為本方，實現最小周期T+1的對賬，每財月月結輸出明細賬、匯總賬，匯總賬支持按法人、渠道維度進行查詢，支持輸出匯總憑證，輸出月結報表；

• 當業務渠道新增時，支持靈活配置化補充渠道信息，迅速接入對賬系統；
• 當支付渠道新增時，支持靈活配置化補充渠道信息，迅速接入對賬系統；
• 支持訂單以文件形式導入；
• 支持賬單以文件形式導入；
• 支持賬務審核流程；
• 支持用戶權限管理及數據權限管理；
• 支持人工平賬。

3.3 數據關系

APP、微信小程序、支付寶小程序、京東、天貓、美團、抖音各渠道統一通過訂單中心向對賬中心輸出訂單，其周期為D+1，即每日0點獲取前一日全部訂單，以接口形式獲??；

各支付渠道支付賬單需從各渠道下載導入對賬系統，其可支持下載周期為T+1。

3.4 其他說明

以上為基礎需求描述，在后續講解中若發現有遺漏的，在實際設計篇幅中進行補充，同時會對本篇進行優化更新。

四、需求梳理

學習做產品時，總有人在你耳邊說，要想把產品做好，需要有自己的產品方法論。

什么是產品方法論？以需求梳理階段舉例，其實就是你去獲取、拆解、梳理、規整需求的方法、使用的工具或者步驟等。

我所常用的方法是從上往下看，通過總-分模式，先從大框架上了解整體業務目標，再基于組成大框架的一個個小模塊，去分別拆解、梳理細節內容。

這也就是人們常說的，框架思維。

以當前需求為例，首先確認清楚，我們要做什么？

做什么：做一套財務人員所需要的基于業務訂單與支付賬單的對賬系統，對賬完成后輸出財務人員所需的憑證及報表。

使用者、輸入、輸出、核心能力已經很明確了。

• 使用者：財務人員；
• 輸入：業務訂單與支付賬單；
• 輸出：憑證及報表；
• 核心能力：基于訂單與賬單的對賬。

框架方向了解后，我們應該怎么去梳理細節內容呢？

從整個產品的維度思考，我們的用戶是財務人員，系統的屬性也是偏向于財務的，那么整體來說，我們系統中將包含很多的財務底層規則。

因此，如果在看同學沒有財務基礎的，或財務基礎很薄弱的，建議先閱讀第一篇。而財務知識很豐富的同學可以接著往下看。

我們已經對框架熟悉了，也知道需要考慮財務規范，那么我們在需求的拆解與梳理過程中，每一個步驟應該把模塊功能和財務規范做有效的結合。

4.1 業務輸入

從第一篇模擬的業務需求來看，我們可以對獲得的信息進行拆解：

法人： 是具有民事權利能力和民事行為能力，依法獨立享有民事權利和承擔民事義務的組織，是企業、公司的另一種稱呼。在本需求中，某集團下有兩個分公司（法人），分別負責自有渠道（自行建設）和三方平臺渠道（外部合作渠道）的業務管理。

補充閱讀：一個公司就是一個法人，我們看到公司營業執照中有法人代表，一般該法人代表就是公司老板，法人代表的含義是，他代表這個公司，是該公司（法人）的代言人。

所以在上游原始數據可能存在多個歸屬時，應著重考慮輸入的原始數據歸類問題。同時，在我們拿到這部分信息時，應該意識到我們所設計的表結構中，一定要有數據歸屬字段，如所屬法人、所屬渠道等。

從上表，我們已知需要從哪些法人及渠道獲取訂單數據，同時我們還應該從需求方獲取相關的信息，包括但不限于：數據提供方式、提供周期、是否有統一訂單中心進行處理等。

如果需求方當前系統比較簡單，沒有統一的訂單中心負責接入全部訂單信息，我們需要直接從三方拉取訂單，那么需要額外準備與三方支持溝通的方式（釘釘群、微信群、企微群等），以便在需求梳理、數據傳輸確認過程中及時溝通了解一些不清楚的地方。

一般來說，三方平臺都會有指定的支付方式，比如京東自有的京東支付、天貓的支付寶支付、抖音自有的抖音支付或微信/支付寶支付等；所以法人B負責的三方渠道部分我們不考慮支付功能接入。

而法人A所負責的自有渠道，可能會對接多種支付方式，以上需求描述也明確的給出了對接的三方支付。

同時，明確了接入模式為直連。

直連指的是APP直接與三方支付（如微信）對接，不通過聚合支付統一處理。而通過三方聚合支付（如隨心付、掃唄等）對接的一般屬于間連。

直連與間連各有優劣，本文不涉及支付具體細節就不細講了，有想了解的朋友可以自行去了解一下支付相關的知識。

回歸需求拆解，我們還需要明確：對接的支付渠道通過何種方式提供賬單數據、提供賬單的周期等；三方平臺如何提供賬單數據、提供賬單的周期等。

儲值第一要素是合規，除了企業自身需要去申請單用途預付費卡資質之外，同步需要與銀行簽訂監管協議，儲值金額統一存入企業在該銀行的監管賬戶中。

單用途預付費卡主要分兩種，記名卡與不記名卡。兩者可儲值額度不同、有效期限制也不同，可以單獨去了解一下。

要點：所有人都應該重視的是，消費者儲值資金雖然在監管銀行所設立的企業賬戶中，但這筆錢的所有權仍是消費者，對于企業來說，這不是收入，而是負債，在資產負債表中屬于右側，在憑證中所體現的科目主要是預付費或遞延收益。

這部分資金，只有消費者在使用儲值消費后，才能基于訂單支付信息從監管賬戶劃入收入賬戶。

在本示例需求中，用戶使用儲值卡金額支付時，其訂單來源是法人A所屬業務渠道APP，賬單來源是法人A監管銀行。

我們在進入4.1之前有講，必須考慮財務屬性，因此，除以上信息外，我們還需要補充財務相關信息，包括但不限于：

財年財月、稅金管理、會計科目等。

同時，輸入給系統的全部數據，需要區分主數據與業務數據。

主數據指的是能夠輔助系統功能的數據類型，包括法人、渠道門店、支付渠道、商品類型、活動營銷、財年財月、稅率管理、會計科目等，后續在產品設計過程中，配置的各種屬性如對賬規則、憑證規則等都算主數據范疇。

業務數據指的是需基于系統規則進行對賬處理的數據，在本系統中，業務數據為訂單數據及賬單數據。

對賬完成輸出的會計憑證及報表數據，也屬于業務數據。

• 主數據的來源一般分為兩種，從上游系統同步或在自有系統創建。
• 業務數據來源一般也分兩種，從上游系統推送或通過文檔導入。

本小節拆解梳理完成后，可以形成如下導圖：

注：是否有OC或OMS提供訂單數據統一功能，應根據實際項目情況進行確認。本文案例默認有訂單中心統一管理兩個法人下全部渠道訂單數據。

從系統關系來思考，可以形成如下框圖：

在實際項目中，如果甲方（需求方）已有訂單與賬單中心可以統一管理并提供業務數據，那么直接與其對接獲取即可，若數據不能滿足對賬中心需求（缺核心字段、缺狀態等），則應向對賬中心上游（訂單與賬單中心）提出需求即可。

特殊情況下，可能需要配合上游與上上游進行少量溝通（以實際情況為準）。

4.2 成果輸出

輸出的要求：以三方賬單為本方，實現最小周期T+1的對賬，每財月月結輸出明細賬、匯總賬，匯總賬支持按法人、渠道維度進行查詢，支持輸出匯總憑證，輸出月結報表。

前文有講本方與對方的關系，在本示例需求里，要求本方為三方賬單，三方賬單即微信、支付寶、銀聯、京東、抖音等提供的支付記錄明細。從此需求也可以看出，用戶對市場上較大平臺的信任度較高（或許是目前自研系統財務訴求的一個常態）。

本條不算輸出需求，但屬于輸出成果時，重要的規則依據。

在很多的術語中，我們常見的有T+1、D+1、W+1、M+1，或者不僅僅是+1，而是+N。

+1指在當天基礎上加一天，隔日的意思；+N指延長的天數不確定，一般來說有這種需求的項目，N是支持可配置的，比如T+1、T+3等。

• T是Time，業務中表示工作日；
• D是Day，業務中表示自然日；
• W是Week，業務中表示一周；
• M是Month，業務中表示一個月，財務上用來表示財務月；

如需求所述，最小對賬周期顆粒度支持到T+1，也就是工作日對賬，比如：

本周一的數據，本周二對賬；本周五的數據下周一對賬；本周六和本周日的數據也是下周一對賬。

本條不算輸出需求，而是屬于對賬周期，也是輸出成果的周期。

與上兩項不同，該3條輸出要求均屬于成果類輸出要求。

需要按指定維度輸出明細結果、月結總賬以及會計憑證。

需要按照法人、渠道兩個層級維度查詢階段明細數據，并支持基于該兩層維度生成月結總報表及會計憑證。

如，渠道維度：

• 明細賬：法人A所屬APP渠道，2022年9月1日明細記錄共計1000條，其中對平980條，差異20條；該兩類數據分別在平賬明細與差異明細中查詢。
• 匯總賬：法人A所屬APP渠道對平明細980條，合計收入總額3萬元；差異中包含應收未收、應付未付，匯總軋差后，應收未收200元。
• 月結匯總報表：法人A所屬APP渠道，2022年9月份對平共30000條，差異1200條。合計收入總額9萬元，應收未收3800元，應付未付1000元（其中商品退款500元，用戶補償500元）。

憑證信息（例）：

會計憑證1：

• 借：銀行存款-招行 90000元
• 貸：主營業務收入-APP 79646.08元
• 貸：應交稅費-應交增值稅-銷項稅 10353.92元

會計憑證2：

• 借：應收賬款-APP 3800元
• 貸：主營業務收入-APP 3362.93元
• 貸：應交稅費-應交增值稅-銷項稅 437.17元

會計憑證4：（退款500元）

• 借：商品庫存-APP 500元
• 貸：銀行存款-招行 500元

會計憑證5：（用戶補償500元）

• 借：營業外支出-APP 500元
• 貸：銀行存款-APP 500元

示例中同步體現了稅金與不含稅金額的分錄，默認以商品銷售稅率13%為基準進行演示計算。

4.3 系統功能

輸入清晰、輸出明了。

那么，在功能設計上，也應該著重從這三點考慮，分別對應輸入、對賬、輸出。

4.3.1 輸入相關

與上游系統對接，包括主數據、業務數據系統，在對賬系統規劃導入數據規范、數據處理邏輯。

接收上游系統提供的主數據，包括渠道門店、商品分類、營銷活動等，支持渠道門店在系統中自行創建。

接收上游訂單中心推送的訂單、接收上游賬單中心推送的賬單、接收手動導入的訂單及賬單。

對主數據日常/更新推送至系統的進行完整性校驗，考慮主數據的變更、重復、缺失字段等處理手段。

對訂單進行完整性校驗，包括去重、非空、狀態篩選、數據歸屬判斷及補充。

對賬單進行完整性校驗，包括去重、非空、數據歸屬判斷及補充。

對通過校驗的訂單及賬單進行字段結構的格式統一，以便于后續對賬階段有效拉取相應對賬數據。

對未通過校驗的訂單、賬單、主數據進行獨立展示、標簽，建立處理規則。

4.3.2 對賬相關

在需求梳理過程中，很多的功能需求方是無法提出來的，如本示例需求，輸入和輸出說的很清晰明了，但功能其實基本略過，只有核心的對賬及基于對賬結果的處理。

那么，我們可以從事務處理的維度去思考功能的規劃設計，事前、事中、事后。

事前：事前主要分兩部分，第一部分為輸入對接，第二部分為輸入處理，這兩點在4.3.1已梳理。

在對賬模塊中，事前還包括從規范后的數據表中拉取對賬數據；

事中：指的是對賬過程中對賬的功能及邏輯，這里是整個對賬模塊最復雜的部分，會涉及到對賬任務、對賬組別、對賬批次、對賬類型、多次對賬、差異對賬，甚至是對賬回退等；

事后：指對賬完成后的處理，包括差異分析、差異處理，輸出最終結果等。

在事后階段輸出最終報表成果時，表中展示含稅總價、未稅總價、稅金總額，其中稅金相關計算公式如下：

含稅單價＝未稅單價＊稅率（1+13%）

未稅單價＝含稅單價／稅率（1+13%）

稅金=未稅單價＊稅率（13%）

4.3.3 輸出相關

對賬完成后，依據財務側需求，需要輸出對賬結果，包括明細表單、匯總表單、會計憑證。

4.2部分示例描述了輸出成果內容，本節主要講述通過何種邏輯規則輸出所需成果內容。

從需求描述來說，可分兩個階段的輸出，分別是日常對賬階段與月結階段。

日常對賬階段，需要輸出對賬結果、差異分析。

對賬結果邏輯在對賬規則中體現，差異分析邏輯在差異分析規則中體現。同時，差異分析因為涉及到系統與人工處理的雙重邏輯，所以需要有獨立的差異處理邏輯。以上兩點，均需要支持將成果導出文檔，一般是Excel格式，這部分需要預設表格字段規則。

月結階段成果包含月結明細報表、匯總報表、會計憑證。

明細報表來源于日常對賬明細一致，其取值邏輯與導出表格規則一致即可；

匯總報表應基于財務需求，預設多報表字段及計算規則，如基于法人的匯總、基于渠道的匯總、基于商品類型的匯總等；

會計憑證需要根據財務側需求，支持可配置憑證格式，配置憑證內容取值，需要有借貸平衡相關的財務校驗邏輯等。

五、方案設計

無論什么行業，嘗試總分模式/先框架后細節的結構化做事方法其實是很多人形成自我方法論雛形的過程。除了需求階段我們使用總-分模式進行梳理之外，在方案設計階段，這種方法依舊好用。

1. 總：考慮清楚整體的業務結構（或功能結構），理清楚需要哪些大模塊來組成目標系統。
2. 分：在各個模塊中填入子模塊及關鍵能力。

最終的結果需要達到：大能統察全局、合規合法、業務正確、冗余有度，小能功能具象、細節合理、流程清晰、落地可行。

這樣輸出的內容，在項目團隊中，即可向上戰略，又可平行溝通，還可向下賦能。

因此，在本次的第五大部分，我們從兩個維度進行闡述：

1. 總：系統框架設計
2. 分：系統各功能模塊設計

5.1 系統框架

5.1.1 系統主要組成部分

系統的框架不是憑空而來，而是基于對需求的透徹理解，對所設計出來的各個功能組件的有效融合，整個系統中，各功能組件都有各自不可或缺的作用，且盡可能保持功能的獨立性（涉及解耦的不在這里講）。

就如一張桌子，至少需要有桌面、桌腿兩個大模塊組成，其都有各自的作用，各自作用由獨立不重合。

基于此，我們從業務維度考慮，可以進行如下設計參考（包括但不限于）：

• 對接外部輸入，以有效接收主數據與業務數據，暫定為數據獲取模塊；
• 數據獲取后，進行有效的歸類、驗證、格式統一，以支持對賬處理，暫定為數據準備模塊；
• 數據準備完畢后，基于各種規則進行對賬，需要獨立的對賬引擎模塊；
• 對賬完成后，結果輸出，除了對平部分結果，差異需要分析及人工判斷，需要差異處理模塊；
• 差異處理后匯總對賬結果，需要輸出憑證及報表，需要憑證規則模塊、報表邏輯模塊；
• 憑證與報表需要審核驗證流程，需要業務審核模塊；
• 憑證與報表展示需要憑證管理與報表管理模塊；
• 系統需要進行用戶管理、主數據管理、規則管理、權限管理等系統配置模塊。

5.1.1.1 數據獲取

數據獲取模塊分別對接外部業務數據系統、主數據系統，獲得外部系統推送的相關數據，同時為了提高對賬系統的數據獲取的靈活性，增加文檔導入功能。

5.1.1.2 數據準備

數據準備階段，需要對業務數據進行歸類、校驗，補充主要字段，如財月信息等，訂單數據需篩選出可用來對賬的狀態。

無論是訂單或賬單數據，無論其來源屬性，最終字段格式會在本流程模塊中進行最終統一，以便于對賬引擎面對的永遠是“標準”且統一的數據格式。

5.1.1.3 對賬引擎

對賬引擎作為對賬系統最核心的模塊能力，其在設計時需要考慮數據拉取、規則匹配、對賬取值、批次分配、差異對賬、結果輸出等正向流程之外，同時需要考慮特殊場景產生的逆向流程，如任務撤銷引起的對賬回退，已對賬數據的歷史版本恢復等。

5.1.1.4 差異處理

對賬結果一般分別對平與差異（差錯）兩種，簡單的差異可以通過系統預設邏輯進行預判斷（如單邊），人工二次驗證確認即可，該做法可有效減少財務人員工作量，提高效率，而特殊差異，如金額不一致的，無法預判斷的，則需要人工判斷差異并確認。

人工判斷處理流程中，應包含人工平賬規則。

5.1.1.5 憑證處理

基于指定周期的對平數據、處理完成的差異數據（最新），拉取憑證生成規則生成所需的財務憑證。

憑證生成完畢應由財務人員基于審核流程進行審核。

5.1.1.6 報表輸出

報表與憑證的設計邏輯相對一致，均是從對賬結果獲取數據后依據模塊規則生成結果。

報表在系統中有兩個流程位置的可能，第一種與憑證平行，雙方取值來源一致，分別生成憑證與報表，且可基于勾稽關系互相可以驗證數據的準確性；第二種則是基于對賬結果先生成報表，再直接從報表中取值生成憑證。

此兩種做法應以實際業務需求為準。

5.1.1.7 系統配置

本次系統設計中，法人、業務渠道、支付渠道、財務主數據、對賬規則等都歸屬于系統配置模塊，但因其在整個系統主線流程中各有交叉，在前幾項中也有所展示，故本項圖片中僅展示非業務配置項。

5.1.2 系統框架

在實際設計產品時，總有人會說，什么總-分模式都是扯淡，當沒有能力將需求轉換為功能的時，很難去規劃出產品的【總】。

說的對。

所以，5.1.1其實就是在將需求轉換為功能模塊，在補充規劃【總】之前的積累。

題外話：為什么說方法論是學不到，而是需要自我的經驗、學習、踩坑等各種經歷積累梳理后的成果？

你沒有從微小到大框架循序漸進思考、成長的過程，又如何能夠迅速形成自我思維模式，再反向從框架到細節去剖析？

那么，方法論的成熟到底怎么來？

積累、學習、提升，從細小功能到子模塊到主模塊到系統到產品戰略，當你在摸爬滾打N久后，自我梳理后，你面對新的需求、新的挑戰時，你的腦子里瞬間閃過了無數的畫面及可能，思考1秒或者2秒，你大方向的解決方案其實就出來了，再仔細思考一番后，核心流程也能梳理出來，這個時候，你會一點點去跟對方（需求方）確認這是否就是對方所要達成的目標。

在5.1.2，我們將進入真正的【總】，這需要你對前文充分閱讀。

5.1.2.1 系統總框圖

總框圖體現的是業務結構，包含了需要設計的系統組件結構與外部輸入或輸出的關聯關系。

在整個系統設計中，總框圖是劃定主線、刻畫核心能力、體現模塊依賴關系的重要藍圖。所以，總框圖的繪制要點是模塊獨立、相互依賴、全而不細、路徑準確、組成清晰。

總框圖從下往上，灰色部分為外部系統，灰色箭頭代表對賬系統與外部其他系統的交互，支持接收外部數據（業務數據及部分主數據），支持推送成果至外部系統，如審核通過后的憑證推送至用友、金蝶或SAP等系統。

橙色框線內，除系統設置外，主要區分了量大模塊組合，分別為數據處理相關與對賬處理相關。數據處理業務流程基于橙色箭頭所示，從獲取到處理屬于單向業務流；對賬處理中，對賬引擎為處理主模塊，基于結果分別輸出憑證與報表。

紅色箭頭的定義：對賬中心可以拆分為兩個系統，分別為對賬處理系統（紅色箭頭上方部分）與數據處理系統（紅色箭頭下方部分），部分公司因業務因素，需要獨立處理大量數據，包括訂單、賬單、活動、營銷等，其已有或計劃或正在實施數據中臺，對賬處理系統所需的可對賬數據，將由該數據中臺統一處理（處理后的數據除了推送對賬，也會推送至BI或成本核算等系統）。

也有部分公司，處于財務獨立性的考慮，會將數據處理與對賬處理合并為一套整系統進行規劃。

在實際產品規劃過程中，應著重考慮以上因素。

5.1.2.2 對賬主流程

流程圖中，體現了幾個重要的節點或數據：橙色部分標明，每次對賬應將對賬數據進行凍結；淺紅色部分差異處理邏輯比較重要；中紅色部分特殊標明凍結本財月，指的是從本節點往后生成財月報表及財月憑證邏的輯，其成果輸出一般每財月處理一次（月結、季結、年度總結等）。

5.1.3 依賴關系

5.1.3.1 系統間依賴

我們從總框圖中已經可以看到，從系統關聯維度考慮，包括上游輸入系統、對賬系統、下游輸出系統，三個系統組成整體的業務流程，這三個系統之間存在著強依賴關系：

對賬系統依賴上游輸入系統提供的數據源；

下游輸出系統依賴對賬系統提供的對賬結果數據。

其所形成的業務鏈如下，且不可逆、不可空缺。

5.1.3.2 功能組件依賴

在總框圖及主流程圖中，我們不難看出，對賬系統核心組件主要包括數據獲取、數據準備、對賬引擎、結果處理、業務輸出；其業務關系如展示順序，業務不可逆不可缺。

其中，設計的規則部分雖然獨屬于系統設置模塊，但其目的亦是為以上業務組件服務，可以拆解到五大核心中。

從圖中也可以看出，整個對賬系統組件關系也可以基于業務有效區分事前、事中、事后。與我們前面所講的產品階段思考維度又有重疊。

因此，在做產品設計階段，我們應該從多維度去剖析，互相驗證，以保證設計成果的準確性、可行性。

注：以上部分圖片來自互聯網，如有侵權請私聊告知刪除，謝謝！