一個工程背景的金融小白進入金融科技叢林後，我們常常會遇到很多難以理解或是很少遇到的問題。
今天我們要來討論一下會計基本知識！學過會計的人一定都知道日記帳，其中，日記帳裡面的數字都是正的，而且紀錄時，數字都要放在借方或是貸方。日記帳中，借方或貸方可能代表增加或減少，或是相反，這一切都是依照帳戶來做決定。然而，工程通常是找到裡面一致性的部分，並且用最簡單的設計來表達資料，所以，工程師們可能認為直接使用正負號來代表一個帳戶的增加或減少。這種設計可能有好有壞，我們今天就來看一下一個實際的案例。
借方 (debit) vs 貸方 (credit)
開始之前，我們要先知道什麼是借方、什麼是貸方。這邊，我們用 wikipedia 上面的內容與範例來簡單介紹相關的知識。
基本會計 (general accounting) 裡，大家一定都會學到一個恆等式：資產 (asset) + 費用 (expense) = 負債 (liability) + 業主權益 (stockholder equity) + 收入 (income)。在這裡面，我們就會把會計帳戶（或是叫科目）分在左邊（資產…端）跟右邊（負債 + 業主權益…端），並叫他們借方帳戶或是貸方帳戶。
記賬的時候，我們會採用複式記賬法，它記錄兩個帳戶之間的變化（數值的增減），他的基本原則就是借方帳戶放在借方就是增加，借方帳戶放在貸方就是減少；貸方帳戶放在借方就是減少，貸方帳戶放在貸方就是增加。
了解之後，我們就可以看一下 wikipedia 的這個表，就可以知道怎麼編寫日記帳了：
話個題外話，我們還真不知道用這種方式的優缺點是什麼，只知道這個方式是會計人員約定成俗的記帳方式。如果大家能解釋這個問題，還請在下方留言告訴大家。
正負號的設計
現在，我們要轉換腦袋，換成工程師思維來看記賬的問題。
記賬會有幾個資訊要紀錄下來：什麼時候、發生什麼事、移動錢的來源帳戶、接收錢的目的帳戶、幣別跟金額。什麼時候跟發生什麼事相對單純，就是一個日期跟一個文字就可以描述；帳戶部分又可以分成：兩個帳戶合併紀錄或分開紀錄；幣別跟金額就單純文字跟數字而已。
如果帳戶採是合併紀錄的方式，我們可以紀錄成：date, description, fromAccount, toAccount, currency, amount。但是， 我們在進行每日結算的時候，每一個紀錄都會被兩個帳戶計算到，同時要依照出現的位置(fromAccount or toAccount) 來決定是來源還是目的。這個方式，當我們在跟公司內部的會計系統對接的時候，我們就要依照帳戶的類別，找出對應的借方貸方位置。這個部分，對剛接觸系統的菜鳥來說，很容易在這裡出錯。
如果是分開紀錄的方式，我們可以把前面的結果拆解成兩筆成對的紀錄，例如：date, description, account, currency, amount，單純透過正負號來代表來源帳戶或目的帳戶，這樣可以簡化每日結算的邏輯，而且結算的時候，也會是先透過加總來確認單一帳戶是否有結餘對不上的問題。
這個正負號的設計看起來很清爽，不過當我們與公司內部的會計系統對接的時候，就要面對前面說的：日記帳裡面的數字都是正的數字的問題。所以，我們勢必要再加入一個 adapter，來紀錄到會計系統中正負號的轉換，並且在每日結算前推到會計系統中並產生當日報表。大家可能會認為都是負的轉正的不是嘛？很簡單的！但是實際上，還要依照會計帳戶找出他要放在借方還是貸方。這個部分，對剛接觸系統的菜鳥來說，很容易在這裡出錯。
不過，本質上來說，系統的紀錄與會計系統的整合已經很成功的被切割成 FinTech 系統與 Adapter 兩個地方，我們只要確保修改 Adapter 的人都能瞭解會計帳戶的規則就可以了。
我們的看法
採用正負號的設計確實給了工程師比較直覺的開發環境。但是，實務面上，我們很常會遇到系統無法支援突發事件，比如：合作夥伴的系統回報成功，但是，實際上是人員操作錯誤，導致我們的系統要進行退款，或例如：公司要優惠合作夥伴應付的手續費。在這種突發事件的情況下，會需要進入手動調賬的環節，做這件事的人，就必須要知道每一個環節。
大家可能會有疑問：手動調賬不是應該有一個專門帶著 business logic 的系統嗎？是的，正確的做法是在確認調賬的流程後，工程師把這個調賬的流程做成手動調賬的功能，然後執行調賬。但是，實務面上，手動調賬都要先完成，大家根本等不及工程師把這部分做出來。所以，FinTech 系統中都會留著一個沒有限制的手動調賬功能。只是要執行這個步驟都要經過人員的層層審查。
對我們來說，正負號的設計沒什麼大問題，最關鍵的地方就是突發事件的處理流程與自動化程度。畢竟叫突發事件，就代表不常會發生，一個月來個一次或是一季來個一次都是可以接受的。關鍵的問題還是，突發事件發生時，能否等到系統支援這項功能後在執行，或是，在突發事件解決後，是不是有把這個流程做成自動化的功能。
如果我們比較一下正負號的設計跟會計借方/貸方的處理流程，兩邊的差異就只是正負號的設計少了借方/貸方的資訊。如果我們直接把借方/貸方的資訊加到 FinTech 的帳戶系統中，並採用會計常見的日記帳的方式來進行記賬，它根本就可以與會計系統相容。在處理突發事件上，可以很容易的依照會計部門的要求跟流程來進行調賬，不會出現一些工程師思維的調賬紀錄。對菜鳥來說，一開始可能不容易理解借方/貸方，但是，只需要看過一些會計基礎知識，他們就可以很快的理解借方/貸方，並且透過帳戶的借方/貸方資訊，很明確的把日記帳寫出來跟結算出當日金額。
最後，我們最建議的方式是直接使用會計的借方/貸方帳戶跟複式記賬法來紀錄 FinTech 系統中金融帳戶資料的變化。
喜歡這系列文章的朋友們，我們會在每週一晚上 8 點 8 分的時候發佈這個系列的文章。不論喜歡或是不喜歡，希望大家可以把想法在下方留言告訴我們！
Sorry for English readers! This series are all in Mandarin. Because there are a plenty of articles about the conflicts between Engineers and Bankers. So, it’s time for learning Mandarin! We will write English version after finishing this series.