搞明白了清結算，你就明白了支付業務是怎麼運轉的。從技術上來說，清結算並不是最難的，風控、信用，實施起來比清結算難多了。但從業務的角度來說，清結算可以說是最難理解的支付業務過程了。它牽扯到支付所有相關的概念。為了降低理解難度，我們從常見的支付行為入手，逐步分析清結算如何進行。
支付流程
先說個比較簡單的支付場景，用戶（姑且稱他為小明）用綁定的銀行卡（用宇宙第一大行工行為例）來購買某電商公司（老熊公司）的產品。小明需要先在老熊公司網站上完成銀行卡綁定的操作，綁卡的過程參見之前的文檔支付系統之綁卡、籤約和身份驗證。綁卡以後，就可以使用這個卡來購買商品。首先是挑選商品和下單，其後是執行支付。下單之前的流程不做介紹， 我們從支付開始，來說明支付過程中的清結算問題。
為了簡化，我們先從比較簡單的同渠道、公司內購買的場景來開始。商品也先假定為虛擬產品，比如會員卡。為了實現這個流程，有一些前置的操作需要完成：
老熊公司已經對接了工行的快捷支付接口。通過這個接口，可以實現綁卡（籤約）、支付、退款、查單等操作。如何對接，參見文檔支付系統之銀行卡支付。
老熊公司已經按照工行的要求，在工行開了備付金帳戶。老熊公司通過工行接口的所有收款、退款等資金往來，都發生在這個帳戶上。
小明在老熊公司的應用中綁定了自己的一張卡，為了簡化處理，小明綁定的也是工行的卡，先省略掉跨行結算的步驟。具體的綁卡流程參見支付系統之綁卡、籤約和身份驗證。
用戶小明在手機或者PC Web上購買了100元的虛擬產品，比如很多公司會使用的會員卡。這裡我們先從虛擬物品入手，因為實體物品情況會複雜一點，供應鏈和物流也是一個大課題，購買實體物品就需要考慮這個問題，而虛擬產品就可以暫不考慮。然後小明在網站上執行下單、支付操作。
老熊公司的支付系統接收到小明的支付操作請求後，系統首先會校驗訂單是否有問題，然後調用工行快捷支付接口，從用戶的工行卡上扣除100元， 用戶的工行卡的扣款是實時進行的，也就是說，這個操作完成後，小明查看他的工行餘額和流水，會有一筆100元的交易，並且帳戶餘額也減少了100元。 但是這個錢並不是直接就進入了老熊公司的（結算）帳戶上的。工行在第二天凌晨會對前天的交易進行清算和結算。在計算收入的同時，也從中扣除掉通道費用，得到最終應該劃撥到結算帳戶上的金額。在這個例子中我們假定手續費按支付金額收費，比例為0.1%。 這裡筆交易，支付給工行0.10元，公司收入99.9元。這裡有個需要注意的地方。有些銀行是在扣除手續費後，將前一天的餘額全部劃撥到結算帳戶上；有些銀行是先全額劃撥所有收入到結算帳戶上，然後扣除手續費。
交易流水
用戶執行支付後，系統首先需要記錄交易流水，流水的內容包括：
交易主體：即發起本次交易的出款的用戶，一般是記錄ID、姓名等信息。
交易帳戶：即用戶購買時使用的出款的帳戶，這是用戶在工商銀行的卡，實際帳戶是建立在工行，但在電商系統中，為了便於結算，為這個帳戶建立一個代理。這個帳戶在系統中的ID是10001（數據本身無其他含義）
交易對手：即出賣虛擬產品的業務部門，一般記錄部門的ID、名稱等信息。
結算收益： 交易對手能夠拿到的金額。這裡是 支付金額-渠道費用，即99.9元
對手帳戶：即虛擬產品的收款帳戶，為了便於結算，公司一般會對每項業務設置獨立的結算帳戶。這個帳戶在系統中的ID是 20001（數據本身無其他含義）。
交易渠道：即工商銀行的快捷支付，還需要記錄渠道的ID， 名稱等；
渠道結算帳號：這也是個代理帳號，記錄在渠道側的交易流水。
渠道提交時間：請求渠道執行支付的時間；
渠道支付時間：渠道一般會在返回的報文中說明本次交易的執行時間。 如果沒有，則使用渠道的支付接口返回時間。
渠道費率：渠道的手續費，這裡假定工行是按支付金額收費，比例為支付金額的0.1%。
渠道費用：這裡是支付金額*手續費率， 即0.1元。
發起交易日期：2016年12月12日 13:00:10，即用戶提交訂單後，虛擬產品業務調用支付系統接口執行支付的時間。
執行交易日期： 2016年12月12日 13:00:11，即支付系統接口調用時間。
支付截止日期：必須在此日期前完成支付。
訂單信息：在本例子中是會員卡，一般需要記錄業務方訂單ID、名稱、內容等信息。
訂單金額：提交過來的原始訂單的金額 100元；
支付金額： 用戶實際支付的金額，由於沒有使用優惠券、打折卡等，這裡支付金額等於訂單金額，都是100元。
沒有使用卡券、沒有和合作方分成，這兩塊內容暫不記錄。
交易流水是在完成支付時實時生成的。這個流水信息是後續記帳的依據，所以務必在流水中真實記錄能收集到的所有的現場信息。 這裡從：
交易主體，即掏錢的小明
交易對手，即收錢的業務方
交易渠道，即工行快捷
交易商品，即會員卡
角度來多方位全角度的描述這筆交易。大家會注意到這裡有不少冗餘信息。實際上對交易涉及到所有可能會被修改的信息，比如用戶姓名，商品名稱，商品價格，都需要在這裡留一個快照，以便後續回溯和審核。
會計主體
不用說，這一筆帳是老熊公司的帳務，不是工行的帳務，也不是小明家的帳務。雖然這裡會有工行和小明的信息，但記帳的目的是為了了解和改進老熊公司的經營狀況服務的。老熊公司不是某個大公司的分公司或者子公司，它是一家獨立核算的、具有獨立的資金和經營業務的單位，從會計學角度來說，他是一個獨立的會計實體。
會計要素
從概念上來說，所有和錢有關的活動，買會員、用戶充值、支付手續費等，都需要記帳，這些活動，稱之為會計對象。每個公司都有不同的會計對象，有時候同一類活動，叫法還不一樣。如果直接用這些活動內容來記帳，那就沒法比較每個公司的情況。 比如新浪說我家微博廣告收入300萬，網易說我家賣豬收入了300萬，到底誰家更賺錢？需要有一個記帳的標準，讓大家分門別類的做記錄。對會計對象做規範化的管理，這就引入會計要素的概念。
會計要素是對會計對象進行的基本分類，是會計核算對象的具體化。 如果說會計對象是個Object，則會計要素是定義這個Object的Class。 不同的國家對會計要素有不同的規定。 國際會計準則委員會（IASC）在《編制和呈報財務報表的結構》將會計要素其歸類為資產、負債、權益、收益和費用五個要素。美國財務會計準則委員會（FASB）在《財務會計概念公告》中將會計要素歸類為資產、負債、所有者權益(淨資產)、業主投資、派給業主款、綜合收益、營業收入、費用、利潤、損失十個要素。我國《會計準則》將會計要素歸類為資產、負債、所有者權益、收入、費用和利潤六個要素。其中資產、負債和所有者權益，是反應公司的財務狀況的；它滿足如下恆等式：
會計科目
六大會計要素指明了需要記帳的scope，但畢竟粒度還是太大了。為了更詳細地了解公司財務情況，引入會計科目來對會計對象進行第二層次的劃分。使用IT的語言來說，會計科目其實就是一個分類體系，用來分門別類地記帳。在實現上，他也是一個編號+名稱，IT俗稱字典表。從定義上來說，會計科目是指一個涵義明確、概念清楚、簡明扼要、通俗易懂的標準名稱。會計科目按照經濟內容的性質不同，可以分為資產類科目、負債類科目、所有者權益類科目、損益類科目，成本類科目，有些金融企業還有資產負債共同類科目。在每一類會計科目下，還可以繼續細分，詳細內容可以參考2016年財政部發布的新會計準則。
會計科目和要素之間的關係：
會計科目還分為總帳科目和明細科目。從IT角度，可以認為總帳科目是一級分類，而明細科目則是這個一級分類下的二級、三級，甚至更多級別的詳細的科目。 記帳時，會同時記錄到總帳、明細科目。 在電商的支付系統中，一般會設置如下科目：
會計帳戶
帳戶是指對會計要素的具體內容所作的科學的分類，其包括兩方面的內容：帳戶的名稱、帳戶的用途與結構。會計科目是設置帳戶的依據，也是帳戶的名稱。比如對銀行存款這個會計科目，也會設置一個對應的銀行存款帳戶，用來跟蹤公司在銀行存款的變動。在這個案例中，將設置的帳戶同會計科目。
記帳憑證
想想在以前沒有電腦的時候，去買公交卡，公交公司阿姨會認真地記錄你買的卡的卡號、買卡人的姓名、卡的面值等信息，運氣好的時候還會給個發票。 一般來說，阿姨會將購買記錄登記到一個帳冊上，形成記帳憑證，並在這裡會登記發票號碼。在現在高科技時代，這個憑證還是少不了了。先說明細帳，記錄內容如下：
這裡詳細記錄每一條交易信息，當然，通過計算機系統，可以記錄更多詳情，包括時間、地點等。
會計分錄和記帳
大家經常看到的記錄應該是這樣的：
如上， 銀行存款、服務成本、主營業務收入，屬於總帳科目，而工行收款、會員卡、工行手續費，屬於明細科目。這裡採用的是複式記帳法中借貸記帳法。對應的帳戶結構如下：
借貸複式記帳法的特點是：
採用借、貸作為記帳符號，建立在會計恆等式基礎上，遵循有借必有貸，借貸必相等的原則。
帳戶基本結構是： 左側為借，右側為貸。
一般採用如上圖所示的T行帳戶的形式來描述。
借貸所代表的增加、減少的含義並不固定，和帳戶的性質有關。
更多問題
作為清結算的入門介紹，這裡介紹的是最簡單的場景，以此來解釋清結算相關的概念，特別是會計學一些從IT角度不容易理解的名詞。實際上，這個場景還有很多問題：
嚴格的說，會員卡的收入，還不能立即作為公司主營業務收入。會員卡是預付款項，用戶開始使用會員卡，公司需要為這個使用提供服務；用戶結束使用會員卡之後，這一筆開支才算是真正落入公司主營業務收入中。
會員卡在使用期間，公司針對會員業務的各種開銷，要分攤到這一段期間的會員上。將開銷分攤到每張會員卡上，計算其使用成本，最終才能夠計算出收益。
用戶會員卡購買的款項是立即反映到備付金帳戶的，但並不是立即到結算帳戶的，一般是T+1結算，也就是第二天銀行才會將清算好的資金打到公司結算帳戶上，這種情況應該如何記帳？
如果支付過程中使用了代金券和優惠券，那又應該如何考慮？
此外，還有退款、充值等場景的清結算，這些問題都將在本系列的文章中詳細介紹。本文僅介紹一些相關的概念， 歡迎大家繼續關注後續內容。
雷鋒網(公眾號：雷鋒網)注：本文由人人都是產品經理社區@鳳凰牌老熊（微信公眾號：shamphone）原創發布。鳳凰牌老熊，程式設計師 & 架構師。未經許可，禁止轉載。
雷鋒網版權文章，未經授權禁止轉載。詳情見轉載須知。