複式簿記を有向グラフで表現する
(matheusportela.com)- 会計用語になじみがなくても、勘定と残高を時間に沿って追跡する構造として見れば、複式簿記をお金の流れのモデルとして理解できる
- 現在の残高だけを上書きする表は変化の過程を失ってしまうが、元帳は取引が発生するたびに項目を追加し、履歴と修正の痕跡を残す
- 単式簿記は勘定ごとの変化の記録には十分な場合があるが、複数の勘定が一緒に動く場合は、関連する項目を取引としてまとめ、出所と行き先を明らかにする必要がある
- 複式簿記では、取引ごとに出ていく金額と入ってくる金額が等しくなければならず、この均衡条件が手作業の会計でチェックサムのように誤りを検出してくれる
- 勘定と取引をノード、借方・貸方項目を向きのあるエッジとして見ると、帳簿は時間とともに成長する有向グラフになり、財務諸表もその可視化として見られる
残高だけを記録すると失われる情報
- 会計とは、時間に沿って数えられる対象を追跡する作業であり、ここではお金の流れに焦点を当てる
- 例では、2024年1月1日にAliceが$100、Bobが$50を持っている状態から始める
- AliceがBobに本代$20を支払うと、Aliceの残高は$80、Bobの残高は$70になる
- ここで勘定(account) とはお金が保管される場所であり、残高(balance) とは特定時点で勘定に入っているお金の量である
- 現在の残高だけを上書きすると、Aliceがなぜ$80を持つようになったのか分かりにくい
- 最初に$0から$80を受け取ったのか
- $10,000から$9,920を使ったのか区別できない
- 残高のスナップショットだけを残す方法は、変化が起きた過程を消してしまう
単式簿記の元帳と不変記録
- 変化の履歴を残すには、取引が発生するたびに既存の値を変えず、新しい行を追加する必要がある
- 元帳項目には通常、次の情報が含まれる
- Description: 取引の説明、支払先、参照番号など、人が読める説明
- Date: 取引発生日であり、月次レポートのような期間別のグループ化にも利用できる
- Balance: 取引後の勘定残高で、重複情報ではあるがデータの確認に有用
- 各行は項目(entry) であり、1つの勘定の項目の集合が元帳(ledger) である
- Aliceの元帳には、2024年1月1日のopening balance $100、2024年2月1日のbought book -$20が記録される
- Bobの元帳には、opening balance $50、sold book $20が残る
- この方式は単式簿記(single-entry bookkeeping)システムである
- 各勘定が自分の元帳を持つ
- 一度に1つの勘定に影響する項目を記録する
- 小規模事業や個人の財務にはよく合う場合がある
元帳はイベントソーシングのように動作する
- 元帳の重要な特徴は、データが不変(immutable) である点だ
- 項目を一度書いたら、全履歴を保存するために修正しない
- 本代を$20と誤って記録したが実際の価格が$30だった場合、既存の行を変えると元の金額と修正の事実を失ってしまう
- よりよい方法は、既存の項目を相殺する新しい項目を追加し、正しい項目を改めて入れることだ
- -$20の項目を+$20で取り消す
- その後-$30の項目を新たに記録する
- 最終残高は$70で同じだが、誤りと修正理由が残る
- この方式はコンピュータサイエンスのイベントソーシング(event sourcing)に似ている
- システムで発生したイベントを保存する
- イベントを再生して現在の状態を計算する
- 特定時点の状態を再作成できる
複式簿記が必要になる瞬間
- 複数の勘定が一緒に動く取引では、単式簿記だけでは関係を明確に把握しにくい
- Aliceの-$20とBobの+$20は同じお金だが、単純な元帳だけを見ると、BobがCharlieからお金を受け取った可能性と区別できない
- 関連する項目を取引(transaction) としてまとめると、同じ出来事に属する項目であることを明示できる
- Transaction 1: Aliceのopening balance
- Transaction 2: Bobのopening balance
- Transaction 3: AliceがBobから本を購入する
- 取引とは、異なる勘定に影響する関連項目のまとまりである
- 複式簿記は、勘定間のお金の流れを見られるように、関連項目を取引単位で結び付ける
借方、貸方、均衡条件
- 伝統的な会計では、お金の流れをdebitとcreditの2列で表現する
- Credit: 勘定からお金が出ていく項目
- Debit: 勘定へお金が入ってくる項目
- AliceがBobに$20を支払うと、Aliceの勘定は$20 credit、Bobの勘定は$20 debitとして記録される
- 銀行カードのcredit/debitという用語と、会計のdebit/creditという用語は異なる意味で使われる
- 紙の帳簿では、左側をdebit、右側をcreditに分けるT-account形式が使われていた
- コンピュータシステムでは、必ずしも2列を維持する必要はない
Type列にDebitまたはCreditを入れ、Amountを別に持たせることができる- あるいはcreditを負数、debitを正数とする単一の金額列を使うこともできる
- 伝統的な用語よりも、incoming moneyとoutgoing moneyのほうが混乱の少ない表現かもしれない
取引は2項目に限定されない
- 複式簿記の中核原則は、各取引の後でシステム全体のお金の合計が変わらないことだ
- 特定の勘定残高は増減し得るが、すべての勘定残高の合計は一定でなければならない
- Opening balanceも均衡を取るには、お金がどこかから出てこなければならない
- 例ではBank勘定を追加し、Aliceの$100、Bobの$50がBankから出たものとして記録する
- このBank勘定はルールを守るための一種の一時勘定であり、会計用語ではcontra accountに該当する
- すべての取引では、出ていくお金と入ってくるお金が等しくなければならず、これは手作業の会計で誤りを検出するチェックサム(checksum)のように機能する
- 複雑な取引も同じ原則でモデル化できる
- AliceはBobに$20を支払い、クレジットカード会社に外国為替手数料$2を支払う
- BobはAliceから$20を受け取り、税務当局に売上税$2、クレジットカード会社に手数料$1を支払う
- クレジットカード会社はAliceから$2、Bobから$1を受け取る
- 税務当局はBobから$2を受け取る
- この場合、1つのTransaction 3には正確に8つの項目が含まれる
- “Double-entry”は、取引が2つの項目だけを持つという意味ではなく、お金が出ていく側と入ってくる側という2つの面を持つという意味である
帳簿を有向グラフとして見る
- 複式簿記は、お金の流れを有向グラフとしてモデル化したものと見ることができる
- グラフとの対応関係は次のとおり
- 勘定はグラフのノード
- 取引も別個のノード
- Credit項目は勘定から取引へ向かう出ていくエッジ
- Debit項目は取引から勘定へ向かう入ってくるエッジ
- 項目の金額はエッジの値
- 勘定残高は、入ってくるエッジの合計から出ていくエッジの合計を引いた値
- Transaction 1はBankからAliceへ$100を移動させる
- Transaction 2はBankからBobへ$50を移動させる
- Transaction 3はAliceからBobへ$20を移動させる
- この表現では、Aliceの残高は$80、Bobの残高は$70になる
複雑な取引を分割するというモデリング上の選択
- 手数料と税金まで1つの取引にすべて入れると、Transaction 3のエッジが多くなり複雑になる
- 同じお金の流れを、より小さな取引に分割することもできる
- Aliceの勘定からは$22が出ていく
- Bobは$19を受け取る
- 残りの$3はクレジットカード会社へ行く
- Bobの売上税$2は別のTransaction 4として処理される
- どのように取引と項目をまとめても、最終的な勘定残高は同じになり得る
- Alice: $78
- Bob: $67
- Tax authority: $2
- Credit card company: $3
- 会計システムは多様な要件を受け入れられるほど柔軟であり、取引と項目のグループ化の方法は事業に合わせて決めるべきである
財務諸表はグラフの可視化
- グラフは新しい取引が追加されるほど、時間とともに成長する
- グラフの基本的な性質は維持され続ける
- 勘定はノードとして残る
- 取引はお金の流れを強制するノードとして残る
- 取引ごとに、出ていく金額の合計と入ってくる金額の合計が等しくなければならない
- Balance sheet、income statement、cash flow statementは、このグラフの可視化として見ることができる
- Assets、liabilities、equity、income、expensesのような分類は、グラフ内のノードグループとして見ることができる
- グラフの観点で見ると、creditとdebitが各分類の残高をどのように増減させるかを、より直感的に理解できる
1件のコメント
Hacker News の意見
複式簿記を「Alice の項目 1 つ、Bob の項目 1 つ」で説明するのは、奇妙な選択に思える
取引当事者が 2 人なら 2 か所に記録されうるのは当然だが、核心は取引の各当事者ごとに 2 つの項目が必要だという点にある。Alice が Bob から本を買えば、項目は 4 つ作られる
教育用の単純化なのはわかるが、要点を落としてしまった過度な単純化だと思う
たとえば現金で買掛金を支払うときは、Accounts Payable という行為者と Cash という行為者に同時にメッセージを送るようなもので、各行為者はその出来事を自分の性質に応じて借方/貸方へ翻訳し、残高を維持する。この見方では、複式簿記とは各出来事が偶数個の行為者にちょうど 1 回ずつ取り込まれなければならない、という意味に近い
決済レールを作るなら、その出来事自体も、取引意図を追跡するメタイベントから派生した一対の出来事の片方かもしれない。会計でいうグラフの辺はお金ではなく、派生イベント階層内のデータだと考えるほうが有用だ
ただ、原文はこの比喩が何のためのものかを明確にできておらず、混乱を減らすより増やしてしまうのではと心配になる
Bob の会計帳簿は気にせず、自分の帳簿だけを追いたい。自分が本を買ったなら、自分の会計帳簿にはこの取引を複式簿記でどう記録すべきかが知りたい
それに Bob は簿記をしているのではなく、本を売っているのだから ;-)
この記事を直して “double” の部分をきちんと説明するにはどうすればいいのだろう？ Bob か Alice のどちらか一方の視点だけでも可能だろうか？
たとえば銀行は、私がローンを返せそうにないと判断して帳簿上で 0 まで減額できる。私は返すつもりがあるので、自分の帳簿には依然として負債を残しておける。銀行は自分のシステム内で関連項目を作り、借方/貸方が一致し、私は何もしなくても自分の帳簿は均衡を保つ
複式簿記は他の主体とは無関係で、あくまで自分自身の帳簿に関するものだ
会計の美しさと影響力は過小評価されていると思う
ごく少数の公式、つまり 会計等式 と損益計算書・貸借対照表のような財務諸表だけで、どんな組織で起きていることでも、おおむね比較可能な形で表現できる。微積分学の基本定理や生物学のセントラルドグマのような感覚すらある
会計は数学と言語の起源でもある。古代メソポタミア文明は当初、商品を追跡するために対象の形をかたどった「会計トークン」を使っており、それが文字言語、たとえば象形文字へ発展したとみなせる
その後、Al-Khwarizmi はイスラム相続法を解くために Al-Jabr、すなわち algebra を作り、相続分配の規則が方程式となったことで、それを速く正確に解く必要が生じた。Al-Khwarizmi の二次方程式の解法が “algorithm” という名の語源になった
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
負数は中国で 3 世紀ごろに初めて使われ、ヨーロッパでは 16 世紀まで広く使われなかった。現代的な複式簿記は 14 世紀のヨーロッパで作られた
そのため、借方列と貸方列を分け、定義がやや奇妙に見える伝統的方式は、正の数だけで動かすための最善の方法だった
組織設計の重要な側面には、財務諸表と緩やかにしか相関しないものが多い
簿記が社会のあらゆる層に根づいて初めて、負数は正の数と同じくらい現実的なものとして受け入れられた
複式簿記は、おかしな
creditとdebitという用語を捨てればとても理解しやすい。核心は、会計等式が常に成り立つように保つことにある。基本式は Equity = Assets - Liabilities であり、利益は最終的に資本に入るので Equity + Income - Expenses = Assets - Liabilities となる。負数をなくすように整理すると Equity + Income + Liabilities = Assets + Expenses である。
この式は常に真でなければならず、そうでなければお金がどこからともなく生まれたり消えたりしたことになる。したがって、式の左側の勘定にお金を足すなら、反対側の勘定にも同額を足すか、同じ側で同額を引かなければならない。
たとえばレモネードを5ドルで売ったなら、Sales（Income）に5ドルを足し、Current Account（Assets）にも5ドルを足す。
creditとdebitがおかしいのは、勘定の種類によって定義が逆転するからであり、このばかげた言葉遣いが人々を混乱させる主な理由である。初級会計の講師がかなり簡潔に言っていた。Debit は左の列の項目で、Credit は右の列の項目である。その取引が事業にとって何を意味するかは勘定によって変わる。
会計を学んでいない人にとって、この用語法はものすごく混乱しやすく、混乱している人に付く多くの返信は技術的には正しくても同時にあまり役に立たない。すでに用語を知っている前提だからだ。
「残高が増えたのに、なぜ銀行口座が debited されるのか？ debit はマイナスではないのか？ 現金残高がマイナスで表示されるのか？」という問いは本当に良い質問である。直感的には、direct debit はお金が出ていき、debit card でお金を使い、debit は debt に似て聞こえるので、debit は常にマイナスだと思ってしまう。
同じ単語をめぐって互いに別の言語を話しているかのようにすれ違う様子は、面白くもありもどかしくもある。細かな言い回しを突いて自分が正しいことを示そうとする流れになりがちでもある。
incomingとoutgoingに変えようという提案にも同じ問題がありそうだ。レモネードに5ドルを使う人の立場では、自分の Sales 項目に5ドルを入れるわけではまったくないからである。この記事とコメントで言っている混乱が何なのか、まだ完全には理解できていない。
credit は出発点、debit は到着点を意味する。
顧客に10,000ユーロを請求すると、現在の為替レートでは11,000ドル相当の約束が生じる。すると、出発点である
Income: Customer A勘定に11,000ドルを credit し、Assets: Accounts Receivableに11,000ドルを debit する。後になって顧客が支払ったが、為替が動いて10,500ドルしか受け取れなかったとする。もともと11,000ドルとして記録した約束が出発点なので、Accounts Receivable に11,000ドルを credit する。現金10,500ドルを受け取ったので cash に10,500ドルを debit し、借方と貸方を一致させるために
Expenses: Loss on Foreign Exchangeに500ドルを debit する。通常は営業日ごとに会社を清算するわけではないのに、なぜその500ドルを架空の即時清算シナリオに無理やり押し込もうとするのか。ただ credit と debit の釣り合いとして記録すればよい。
独立変数をY軸に置いたグラフがあまりにも多かった。
「Credit は勘定からお金が出ていく項目で、Debit は勘定にお金が入ってくる項目だ」というのは正確ではない。
debit と credit の意味は勘定の種類によって変わる: https://en.wikipedia.org/wiki/Debits_and_credits
CPA になるのに1科目以上必要なのには理由があるのかもしれない: https://www.accounting.com/careers/cpa/how-to-become/
私には、人が項目を入力して計算していた時代に、特定のミスを見つけるために作業を二重化した方式のように見える。それ自体には理屈がある。
ただ、コンピュータがすべての計算をする世界で育ったせいか、同じことを繰り返してはいけないという原則に反しているように見える。同じ内容を二か所に書けば、そのうち片方は結局間違うものだからだ。
会計が現代に設計されていたら、こうはなっていなかった気がする。私が会計士ではなく理解できていないからといって制度が間違っているという意味ではないが、「credit が資産勘定を減らす」という点に感じる混乱は、何か根本的に噛み合っていないことの兆候のように思える。
CR 項目は会社が負っているもの、つまり債権者や株主に対する負担が増えたことを表し、DR 項目は会社が持っているものが増えたことを表す。
会計等式との関係についてはここを参照: https://news.ycombinator.com/item?id=32501707
credit/debit という用語にかなりの混乱が見られる。
現代的な観点でもっと単純に考えるなら、会計は 負数の一般的な使用 よりはるかに古い、という点を思い出せばよい。もし今日会計を発明していたなら、debit/credit 勘定の代わりに正数/負数勘定を使っていた可能性が高い。
加算の上に成り立つ代数は今の私たちには自然だが、1604年の普通の商人にとっては当然ではなく、負数は当時でもあまり好意的に受け止められていなかった。
重要なのは、取引には常に二つの側面があり、互いに逆演算だということだ。credit と debit は結局のところ数に対する逆演算である。
だから credit = debit なら取引は均衡している、という規則を作れる。現代風には debit + credit = 0 と見ることもできるが、この体系が作られた当時は負数が好まれていなかったので、これは目標というより常に成り立つうれしい偶然に近い。
手元の現金を最も正数的な、つまり debit 性質の勘定として見て逆向きに考えると理にかなっている。費用を処理するには現金勘定を逆向きに処理する必要があるので credit し、お金が行った先には反対項目として debit する。したがって費用勘定は通常 debit 残高を持つ。
現金はどこから来たのか。収入から来たのであり、現金を debit 的にしたいなら、その源泉は credit 的でなければ取引の均衡が崩れる。だから収入勘定は通常 credit 勘定、つまり一般に負の残高、あるいは “credit normal” を持つ。
この体系のすばらしい点は、日常的なあらゆる取引が均衡した取引へと帰着し、ありうる勘定がそれぞれ通常 credit または debit という一貫した残高の性質を持つことだ。本当に優雅である。
それと会計方程式さえ覚えていれば、残りのすべての勘定種類の正常残高を導き出せる。
1か月ほど前に PTA subreddit で PTA の文法をもっと直感的にする議論を始めたところ、ある人が “from”、つまり credit/負数勘定と、“to”、つまり debit/正数勘定を矢印で表そうと提案した。数値には符号がなく、"credit" と "debit" という用語も使わないので、ずっと直感的に感じられる。
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
負数に関する背景は興味深い。
それでもまだ複雑すぎる。「Transaction 列を表に追加しよう」の時点ですでにずれている。
勘定データ を保存するのではなく 取引 を保存すべきである。勘定はそこから計算すればよい。“Transactions” テーブルには Date, Amount, SourceAccount, TargetAccount, Description フィールドがあればよい。
私にはここで美しさが生まれるように見える。銀行明細で見慣れているからという理由で勘定中心に考える習慣を捨て、キャッシュフローで考えるべきだ。
もちろん税務用途には単純すぎる。取引に複数の出所や複数の行き先がある場合があるので、上のスキーマは調整が必要になる。それでも、考え方を変えるべきだというのが要点だ。
プログラマが賢くやろうとして、元の取引から計算せず 累積合計 を維持しようとした兆候だからだ。そこにはドラゴンがいる。
よりよい設計はヘッダー表と明細表を持つことだ。
Header: TransactionID, Date, Description, posting status や reconciliation status など必要なフィールド。
Detail: TransactionID, LineNumber, Account, Amount, Description, subledger 参照番号など必要なフィールド。
こうすると一つの取引が任意の数の勘定に影響を与えられる。最終的に取引は、複数の勘定に影響しうるビジネス取引を反映することになる。
詳細には、各送金の出力に出所アドレスを含める必要があるなど、もう少し複雑だが、アイデアは同じだ。このスレッドの別の箇所でも言われているように、各取引には複数の入力と複数の出力が必要になる。
プレーンテキストのファイルにすべての取引があり、評価が必要なときには、そこから元帳全体をその場で生成する。
会計士ではないが、以前に複式簿記と基礎会計を学ぼうと決め、HNの良いスレッドを含めいろいろな場所で多くを学んだ。
この記事では、複式簿記の仕組みと、それが有向グラフだと気づくに至った過程を説明している。HNには会計オタクが多いので、間違っている部分があれば批判や修正提案をお願いしたい。
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
うちのcontrollersが営業実績をこうしたグラフィカルなフローとして作ってくれたらいいのにと思う。ある規模になると会計はかなり難しくなり、会計方針チームに教授級の人材が必要になるほどだ。
統計学で学んだのは、グラフィックが重要だということだ。適切な抽象化を使えば、どんな数値でも構成要素のグラフとして表せる。腑に落ちる瞬間があった。
一方には入ってくる、あるいは出ていくお金があり、もう一方には製品やサービスがある。これが会計の複式記入だ。明白で単純に見えるかもしれないが、自分の分野でこれを理解している人は多くない。
よく書かれた記事だが、一般的に受け入れられた意味を持つ用語を再定義するときは注意すべきだ。
Debit/CreditをIncoming/Outgoingに置き換えるのは、また別の専門用語のように見え、混乱を招く可能性がある。どんなbookkeeperでもcredit cashとdebit expenseが何を意味するか理解している。
これをincoming/outgoingに変えても、実務を行う人やその実務を説明しなければならない人の助けにはならない。何百年にもわたって有用だった命名法を学ぶほうが、比喩に頼るより価値がある。
HNでこういう議論が出ると、いつも誰かが「とても簡単だ。creditは単に……」と言い、すぐに「逆に理解している。簡単だ。creditは……」という返答がつく。
自分はその用語を永久に捨ててもまったく構わない。
お金がcreditedされたりcredit cardを使ったりすると、お金がどこかから生まれたように感じて良い意味に思えるし、debitはdebtのように聞こえて自分のお金が減ったように感じられ、悪い意味に思える。
実際にはその名称に理由があるのはわかるが、部外者が接するあらゆる用例と衝突する非直感的な専門用語に固執する分野であれば、重複の少ない別の表現を使ってもよいのではないか。
正しい専門用語を適切に使って会話できれば、信頼性は大きく上がる。
会計の専門用語であるdebit/creditを一般人の言葉で説明することが、なぜ専門用語のように見えるのかよくわからない。自分が一般人だからかもしれない。
会計の背景がない人にcredit/debitを「お金が入る、お金が出る」と説明するのは、この記事の文脈では十分に問題ないように見える。ここでcredit/debitの「本当の」定義は、意味のある形で異なる働きをするのだろうか。
David P. Ellermanは、自身がPacioli groupと呼ぶものに基づいた会計の数学的アプローチを提示している。
Pacioli groupの仮の要素はx//yのような形をしており、xとyは非負整数である。x//yとu//vは、交差和x+vとy+uが等しければ同値とみなす。
群演算は x//y + u//v = (x+u)//(y+v) であり、x//yの逆元は y//x、単位元は 0//0 である。詳しくは、たとえば次の文書を参照されたい。: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
ここで何か見落としている気がする。取引履歴を有向グラフとして見ることは何の役に立つのか。
何百年も続いてきた複式簿記の慣行より改善された点があるのか。
数件の取引しかないおもちゃの例ではかろうじて機能しているように見えるが、ノードのペアの間に数十本、数百本もの辺が生じたとき、グラフがどう見えるか想像してみればよい。一般的なグラフアルゴリズムがどこで役立つのかもわからない。
ペンチを金づちのように使っている感じだ。できることはできるだろうが、なぜそうしなければならないのか。
第一に、概念を理解するための別の方法だ。たいていの場合は関係ないかもしれないが、難しい会計問題がグラフ理論の適用で解けるかもしれないし、逆に会計からグラフ理論の問題が解けるかもしれない。誰にもわからない。
第二に、フローを可視化する別の方法だ。誰もが金融リテラシーや数的センスに優れているわけではないので、数値の列がある表を渡してフローを数字から推論させる代わりに、空間的に表現できる。すべての道具が専門家だけのためのものではない。
全履歴の累積を1つのグラフとして見るのはやりすぎかもしれないが、取引日フィルターを追加するだけでも、別の可視化では見落とされる洞察を得られるかもしれない。位置のような他の情報とクロスリファレンスすれば、さらに有用になる可能性もある。
正当性を示せておらず、この可視化がより明確な理解に役立ったという著者の主張も、複式簿記を最初からgeek風に説明しようとする過程で露呈するカテゴリエラーのせいで弱くなっている。
しかも、ごく単純な1件の取引しか表現していない。税務上の減価償却と会計上の減価償却が異なる場合、外貨建て損益の調整、franked dividendsの配分、PAYG、他人のために保管している金額、繰延収益の一部認識といった、より抽象的な内容をグラフベースの可視化でどう扱うのか見当もつかない。
エンジニアが、ソフトウェアがその分野を複製するようになってから、他分野に以前から存在していた根本原理を後になって発見する、という形だ。