FinTech 沈浮人生 — 記賬問題:借方/貸方?正負號?

John Hu
Dec 12, 2022

--

一個工程背景的金融小白進入金融科技叢林後,我們常常會遇到很多難以理解或是很少遇到的問題。

今天我們要來討論一下會計基本知識!學過會計的人一定都知道日記帳,其中,日記帳裡面的數字都是正的,而且紀錄時,數字都要放在借方或是貸方。日記帳中,借方或貸方可能代表增加或減少,或是相反,這一切都是依照帳戶來做決定。然而,工程通常是找到裡面一致性的部分,並且用最簡單的設計來表達資料,所以,工程師們可能認為直接使用正負號來代表一個帳戶的增加或減少。這種設計可能有好有壞,我們今天就來看一下一個實際的案例。

Photo by Kelly Sikkema on Unsplash

借方 (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.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

No responses yet

Write a response