डबल-एंट्री बहीखाते को directed graph के रूप में समझना

 (matheusportela.com)
3 पॉइंट द्वारा GN⁺ 2024-04-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • भले ही accounting की terminology अपरिचित लगे, account और balance को समय के साथ ट्रैक करने वाली संरचना के रूप में देखें तो डबल-एंट्री बहीखाते को पैसों के flow model की तरह समझा जा सकता है
  • सिर्फ मौजूदा balance को overwrite करने वाली तालिका बदलाव की प्रक्रिया खो देती है, लेकिन ledger हर transaction पर नया item जोड़कर history और correction के निशान बचाए रखता है
  • single-entry bookkeeping account-वार बदलाव दर्ज करने के लिए काफी हो सकती है, लेकिन जब कई account साथ चलते हैं, तो संबंधित items को transaction में बाँधकर source और destination को दिखाना पड़ता है
  • डबल-एंट्री bookkeeping में हर transaction के लिए बाहर जाने वाली और अंदर आने वाली राशि बराबर होनी चाहिए, और यह balance condition manual accounting में checksum की तरह errors पकड़ने में मदद करती है
  • अगर account और transaction को node, और debit/credit items को direction वाले edge की तरह देखें, तो ledger समय के साथ बढ़ने वाला directed graph बन जाता है, और financial statements को भी उसकी visualization की तरह देखा जा सकता है

सिर्फ balance रिकॉर्ड करने पर कौन-सी जानकारी खो जाती है

  • accounting समय के साथ गिने जा सकने वाले किसी subject को track करने का काम है, और यहाँ focus पैसों के flow पर है
  • उदाहरण में 1 जनवरी 2024 को Alice के पास $100 और Bob के पास $50 से शुरुआत होती है
  • अगर Alice, Bob को किताब के लिए $20 देती है, तो Alice का balance $80 और Bob का $70 हो जाता है
  • यहाँ account वह जगह है जहाँ पैसा रखा जाता है, और balance किसी खास समय पर account में मौजूद पैसे की मात्रा है
  • अगर सिर्फ current balance overwrite किया जाए, तो यह समझना मुश्किल हो जाता है कि Alice के पास $80 क्यों हैं
    • क्या वह शुरू में $0 से $80 तक पहुँची
    • या $10,000 में से $9,920 खर्च किए
  • सिर्फ balance snapshots छोड़ने का तरीका यह मिटा देता है कि बदलाव कैसे हुआ

single-entry ledger और immutable records

  • अगर बदलाव का history रखना हो, तो हर transaction पर पुरानी value बदलने के बजाय नई row जोड़नी चाहिए
  • ledger entry में आम तौर पर ये जानकारी होती है
    • Description: transaction का विवरण, किसे payment हुआ, reference number आदि जैसी human-readable जानकारी
    • Date: transaction की तारीख, जिसे monthly report जैसी period-based grouping में भी इस्तेमाल किया जा सकता है
    • Balance: transaction के बाद account balance, जो duplicate data है लेकिन review में उपयोगी होता है
  • हर row एक entry है, और एक account की entries का संग्रह ledger कहलाता है
  • Alice के ledger में 1 जनवरी 2024 opening balance $100, 1 फ़रवरी 2024 bought book -$20 दर्ज है
  • Bob के ledger में opening balance $50, sold book $20 बचा रहता है
  • यह तरीका single-entry bookkeeping system है
    • हर account का अपना ledger होता है
    • एक समय में एक account को प्रभावित करने वाली entry दर्ज की जाती है
    • छोटे business या personal finance के लिए यह ठीक बैठ सकता है

ledger event sourcing की तरह काम करता है

  • ledger की एक अहम विशेषता यह है कि data immutable होता है
  • एक बार entry लिखने के बाद पूरी history बचाने के लिए उसे बदला नहीं जाता
  • अगर किताब की कीमत गलती से $20 लिख दी गई हो लेकिन असली कीमत $30 हो, तो पुरानी row बदल देने से मूल राशि और correction, दोनों की जानकारी खो जाएगी
  • बेहतर तरीका यह है कि पुरानी entry को offset करने वाली नई entry जोड़ें और फिर सही entry दोबारा डालें
    • -$20 entry को +$20 से cancel करें
    • उसके बाद -$30 entry नई दर्ज करें
    • अंतिम balance $70 ही रहेगा, लेकिन गलती और correction की वजह दर्ज रहेगी
  • यह तरीका computer science के event sourcing जैसा है
    • system में होने वाले events store किए जाते हैं
    • उन्हीं events को replay करके current state निकाली जाती है
    • किसी भी खास समय की state दोबारा बनाई जा सकती है

जहाँ डबल-एंट्री की ज़रूरत पड़ती है

  • जब किसी transaction में कई account साथ बदलते हैं, तो single-entry से उनके संबंध को साफ़-साफ़ समझना मुश्किल हो जाता है
  • Alice का -$20 और Bob का +$20 एक ही पैसा है, लेकिन साधारण ledger देखने पर यह अलग नहीं किया जा सकता कि Bob को पैसा Charlie से मिला या Alice से
  • अगर संबंधित entries को transaction में बाँध दिया जाए, तो यह स्पष्ट हो जाता है कि वे एक ही घटना का हिस्सा हैं
    • Transaction 1: Alice का opening balance
    • Transaction 2: Bob का opening balance
    • Transaction 3: Alice, Bob से किताब खरीदती है
  • transaction, अलग-अलग accounts को प्रभावित करने वाली संबंधित entries का समूह है
  • डबल-एंट्री bookkeeping संबंधित entries को transaction unit में जोड़कर accounts के बीच पैसों के flow को दिखाती है

debit, credit और balance condition

  • पारंपरिक accounting पैसों के flow को debit और credit नाम की दो columns में दिखाती है
    • Credit: account से बाहर जाने वाला पैसा
    • Debit: account में आने वाला पैसा
  • अगर Alice, Bob को $20 देती है, तो Alice account में $20 credit और Bob account में $20 debit दर्ज होगा
  • bank card पर इस्तेमाल होने वाले credit/debit शब्द और accounting के debit/credit शब्द अलग अर्थ में इस्तेमाल होते हैं
  • कागज़ी ledger में बाएँ debit और दाएँ credit के रूप में बाँटा गया T-account format इस्तेमाल होता था
  • computer system में दो columns बनाए रखना ज़रूरी नहीं है
    • Type column में Debit या Credit रखा जा सकता है और Amount अलग रखा जा सकता है
    • या फिर एक single amount column रखा जा सकता है जहाँ credit negative और debit positive हो
  • पारंपरिक terminology की तुलना में incoming money और outgoing money कम confusing अभिव्यक्ति हो सकती है

transaction सिर्फ दो entries तक सीमित नहीं होता

  • डबल-एंट्री bookkeeping का मुख्य सिद्धांत यह है कि हर transaction के बाद system में कुल पैसे का योग नहीं बदलता
  • किसी खास account का balance बढ़ या घट सकता है, लेकिन सभी accounts के balances का total स्थिर रहना चाहिए
  • opening balance को भी balance में रखने के लिए पैसा कहीं-न-कहीं से आना चाहिए
  • उदाहरण में Bank account जोड़कर Alice के $100 और Bob के $50 को Bank से निकला हुआ दर्ज किया गया है
  • यह Bank account नियम निभाने के लिए एक तरह का अस्थायी account है, जिसे accounting terminology में contra account कहा जाता है
  • हर transaction में बाहर जाने वाला और अंदर आने वाला पैसा बराबर होना चाहिए, और यह manual accounting में checksum की तरह errors पकड़ता है
  • जटिल transactions को भी इसी सिद्धांत से model किया जा सकता है
    • Alice, Bob को $20 देती है और credit card company को foreign exchange fee $2 देती है
    • Bob, Alice से $20 पाता है और tax authority को sales tax $2, तथा credit card company को fee $1 देता है
    • credit card company, Alice से $2 और Bob से $1 पाती है
    • tax authority, Bob से $2 पाती है
  • इस स्थिति में एक ही Transaction 3 में ठीक 8 entries शामिल होंगी
  • “Double-entry” का मतलब यह नहीं कि transaction में सिर्फ दो entries हों, बल्कि यह कि उसमें बाहर जाने और अंदर आने वाले पैसे, यानी दो पहलू, दोनों होते हैं

ledger को directed graph की तरह देखना

  • डबल-एंट्री bookkeeping को पैसों के flow के directed graph model की तरह देखा जा सकता है
  • graph mapping इस तरह है
    • account, graph के node हैं
    • transaction भी अलग node हैं
    • Credit entry, account से transaction की ओर जाने वाला outgoing edge है
    • Debit entry, transaction से account की ओर आने वाला incoming edge है
    • entry की राशि edge की value है
    • account balance = incoming edges का योग - outgoing edges का योग
  • Transaction 1, Bank से Alice तक $100 ले जाता है
  • Transaction 2, Bank से Bob तक $50 ले जाता है
  • Transaction 3, Alice से Bob तक $20 ले जाता है
  • इस representation में Alice का balance $80 और Bob का $70 हो जाता है

जटिल transactions को बाँटने का modeling choice

  • अगर fee और tax सबको एक ही transaction में डाल दिया जाए, तो Transaction 3 के edges बहुत बढ़ जाते हैं और चीज़ें जटिल हो जाती हैं
  • उसी पैसे के flow को छोटे transactions में भी बाँटा जा सकता है
    • Alice account से $22 निकलते हैं
    • Bob को $19 मिलते हैं
    • बाकी $3 credit card company को जाते हैं
    • Bob का $2 sales tax अलग Transaction 4 में process होता है
  • transaction और entries को जैसे भी group किया जाए, final account balances एक जैसे रह सकते हैं
    • Alice: $78
    • Bob: $67
    • Tax authority: $2
    • Credit card company: $3
  • accounting system इतने flexible होते हैं कि अलग-अलग requirements समेट सकें, और transaction तथा entries को group करने का तरीका business के हिसाब से तय करना चाहिए

financial statements, graph की visualization हैं

  • graph में जैसे-जैसे नए transactions जुड़ते हैं, वह समय के साथ बढ़ता जाता है
  • graph की बुनियादी properties वैसी ही रहती हैं
    • account, node बने रहते हैं
    • transaction, पैसे के flow को enforce करने वाले node बने रहते हैं
    • हर transaction में outgoing amount का कुल योग और incoming amount का कुल योग बराबर होना चाहिए
  • Balance sheet, income statement, cash flow statement को इस graph की visualization की तरह देखा जा सकता है
  • Assets, liabilities, equity, income, expenses जैसी categories को graph के node groups की तरह देखा जा सकता है
  • graph के नज़रिए से देखें, तो यह अधिक सहज हो जाता है कि credit और debit इन categories के balances को कैसे बढ़ाते या घटाते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-11
Hacker News की टिप्पणियाँ

  • Double-entry bookkeeping को “Alice की एक entry, Bob की एक entry” के रूप में समझाना अजीब चुनाव लगता है
    अगर लेन-देन के दो पक्ष हैं तो दो जगह रिकॉर्ड हो सकता है, यह तो स्वाभाविक है, लेकिन असली बात यह है कि लेन-देन के हर पक्ष के लिए दो entries चाहिए होती हैं। अगर Alice, Bob से किताब खरीदती है तो चार entries बनती हैं
    समझाने के लिए simplification करना ठीक है, लेकिन यह मुझे ऐसी over-simplification लगती है जो मूल बात ही हटा देती है

    • अगर आप Quickbooks जैसे software को बिना accounting background के समझना चाहते हैं, तो कंपनी के हर account को अपनी ledger रखने वाले actor की तरह personify करना वास्तव में मददगार हो सकता है
      उदाहरण के लिए, जब cash से accounts payable चुकाया जाता है, तो मानो Accounts Payable actor और Cash actor दोनों को एक साथ message भेजा जा रहा हो, और हर actor उस घटना को अपनी प्रकृति के हिसाब से debit/credit में बदलकर balance बनाए रखता है। इस नज़रिए से double-entry bookkeeping का मतलब इस बात के ज़्यादा करीब है कि हर घटना ठीक एक-एक बार, और वह भी actors की सम संख्या द्वारा absorb की जानी चाहिए
      अगर आप payment rail बना रहे हैं, तो वह घटना खुद भी transaction intent को track करने वाली meta-event से निकली घटनाओं की जोड़ी में से एक हो सकती है। Accounting में जिस graph edge की बात होती है, उसे पैसे की बजाय derived event hierarchy के भीतर के data के रूप में देखना ज़्यादा उपयोगी है
      लेकिन मूल लेख यह साफ़ नहीं कर पाया कि यह उपमा किसलिए है, और डर है कि यह भ्रम घटाने के बजाय बढ़ा सकती है
    • मैं भी यही कहने वाला था। अगर आप जानते हैं कि double-entry bookkeeping सिर्फ़ मेरी ledger पर लागू होती है, तो Bob की ledger में भी entries होने वाला उदाहरण उल्टा confusing हो जाता है
      मुझे Bob की accounting ledger की परवाह नहीं, मैं सिर्फ़ अपनी ledger track करना चाहता हूँ। अगर मैंने किताब खरीदी है, तो मैं यह जानना चाहता हूँ कि अपनी accounting ledger में इस transaction को double-entry bookkeeping से कैसे record करूँ
      और फिर, Bob bookkeeping नहीं कर रहा, वह तो किताब बेच रहा है ;-)
    • Double-entry accounting की व्याख्याएँ अक्सर वही गलती करती दिखती हैं। मैं जानना चाहता हूँ कि double-entry bookkeeping में double तकनीकी रूप से किस चीज़ की ओर इशारा करता है, और वास्तव में क्या “दोगुना” होता है
      इस लेख को ठीक करके “double” वाले हिस्से को सही तरह समझाना हो तो कैसे करेंगे? क्या यह सिर्फ़ Bob या Alice, किसी एक पक्ष के दृष्टिकोण से भी किया जा सकता है?
    • तकनीकी रूप से भी यह गलत है
      उदाहरण के लिए, बैंक यह मान सकता है कि मैं loan वापस नहीं चुका पाऊँगा, और अपनी ledger में उसे शून्य तक write down कर सकता है। मैं चुकाने का इरादा रख सकता हूँ, इसलिए अपनी ledger में liability बनाए रखूँगा। बैंक अपने system में संबंधित entries बना लेता है और debit/credit संतुलित हो जाते हैं, और मैं कुछ भी न करूँ तब भी मेरी ledger balanced रहती है
      Double-entry bookkeeping का दूसरे पक्षों से कोई लेना-देना नहीं, यह सिर्फ़ अपनी ledger से संबंधित है
    • उम्मीद है CPA के नज़रिए से लिखा मेरा स्पष्टीकरण ज़्यादा सहज लगेगा: https://www.winstoncooke.com/blog/a-basic-introduction-to-ac...

  • मेरा मानना है कि accounting की सुंदरता और प्रभाव, दोनों को कम आंका जाता है
    बहुत कम औपचारिक नियमों—यानी accounting identity—और income statement, balance sheet जैसे financial statements के सहारे किसी संगठन में क्या हो रहा है, उसे मोटे तौर पर तुलनीय रूप में व्यक्त किया जा सकता है। इसमें कुछ वैसा एहसास है जैसा calculus के fundamental theorem या biology के central dogma में होता है
    Accounting, mathematics और written language की उत्पत्ति का भी हिस्सा रही है। प्राचीन Mesopotamian सभ्यताओं ने शुरू में वस्तुओं को track करने के लिए उन चीज़ों के आकार जैसे “accounting tokens” इस्तेमाल किए, और माना जा सकता है कि वहीं से written language, जैसे hieroglyphs, विकसित हुई
    बाद में Al-Khwarizmi ने इस्लामी inheritance law को हल करने के लिए Al-Jabr, यानी algebra, विकसित किया, और inheritance distribution के नियम equations बन गए, जिन्हें जल्दी और सही ढंग से हल करने की ज़रूरत थी। Al-Khwarizmi की quadratic equations हल करने की विधि ही “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

    • दूसरी ओर, पारंपरिक accounting की कुछ पद्धतियाँ ऐसी सीमाएँ ढोती हैं जो इसलिए बनीं क्योंकि accounting, बहुत-सी “आधुनिक” mathematics से पहले विकसित हुई थी
      Negative numbers का पहला उपयोग चीन में लगभग तीसरी सदी में हुआ था, और यूरोप में वे 16वीं सदी तक व्यापक नहीं हुए थे। आधुनिक double-entry bookkeeping 14वीं सदी के यूरोप में विकसित हुई थी
      इसलिए debit और credit के लिए अलग-अलग columns रखना, और कुछ अटपटी लगने वाली परिभाषाएँ, सिर्फ़ positive numbers के सहारे काम चलाने का सबसे अच्छा तरीका था
    • यह विचार कि accounting में सब कुछ perfectly match होना चाहिए, एक साफ़-सुथरी simplicity रखता है, लेकिन वहाँ से यह कहना कि “income statement और balance sheet किसी संगठन की स्थिति को मोटे तौर पर तुलनीय रूप में व्यक्त करते हैं”, काफ़ी financialized worldview जैसा लगता है
      संगठन की संरचना के कई महत्वपूर्ण पहलू ऐसे होते हैं जिनका financial statements से सिर्फ़ ढीला-ढाला संबंध होता है
    • Accounting के प्रभाव को सचमुच कम आंका गया है। 1800 के आसपास तक यूरोप में, कुछ mathematicians को छोड़कर, negative numbers जैसी कोई व्यावहारिक अवधारणा नहीं थी; गणना भले संभव मानी जाए, उसे स्पष्ट रूप से अर्थहीन समझा जाता था
      जब bookkeeping समाज की हर परत में गहराई से बस गई, तभी negative numbers को positive numbers जितना वास्तविक माना जाने लगा
    • यह संगठन में क्या हो रहा है, उसे व्यक्त कर सकती है, लेकिन काफ़ी अच्छी तरह छिपा भी सकती है

  • अगर double-entry bookkeeping से अटपटे “credit” और “debit” शब्द हटा दिए जाएँ, तो इसे समझना बहुत आसान है
    मूल बात यह है कि accounting equation हमेशा सही रहनी चाहिए। बुनियादी समीकरण है Equity = Assets - Liabilities, और क्योंकि profit आखिरकार capital में जाता है, इसलिए Equity + Income - Expenses = Assets - Liabilities बनता है। नकारात्मक मान हटाने के लिए इसे फिर से लिखें तो Equity + Income + Liabilities = Assets + Expenses होता है
    यह समीकरण हमेशा सही होना चाहिए, वरना इसका मतलब होगा कि पैसा कहीं से भी पैदा हो गया या गायब हो गया। इसलिए अगर आप समीकरण के बाएँ तरफ़ वाले खाते में पैसा जोड़ते हैं, तो आपको या तो दूसरी तरफ़ वाले खाते में उतनी ही राशि जोड़नी होगी, या उसी तरफ़ कहीं उतनी ही राशि घटानी होगी
    उदाहरण के लिए, अगर आप lemonade 5 डॉलर में बेचते हैं, तो Sales(Income) में 5 डॉलर जोड़ते हैं और Current Account(Assets) में भी 5 डॉलर जोड़ते हैं
    “credit” और “debit” इसलिए अटपटे लगते हैं क्योंकि account type के हिसाब से उनकी परिभाषा उलट जाती है, और यही बेतुकी शब्दावली लोगों के उलझने की मुख्य वजह है

    • accounting equation के रूप में सोचना सही तरीका है। लोग debit और credit में ज़रूरत से ज़्यादा अर्थ भरने की कोशिश करते हैं
      accounting 100-level class के instructor ने इसे काफ़ी संक्षेप में कहा था। Debit बाएँ कॉलम की चीज़ है, और Credit दाएँ कॉलम की चीज़। उस transaction का business के लिए क्या मतलब है, यह account पर निर्भर करता है
    • “अगर अटपटे credit/debit शब्द हटा दें तो double-entry bookkeeping आसान है” — यह बात मुझे पसंद आई
      जिसने accounting नहीं पढ़ी, उसके लिए यह शब्दावली बहुत ज़्यादा उलझाने वाली है, और जो लोग भ्रमित हैं उन्हें दिए गए कई जवाब तकनीकी रूप से सही होते हुए भी एक साथ बहुत मददगार नहीं होते। क्योंकि वे पहले से मानकर चलते हैं कि आपको शब्दों का मतलब पता है
      “balance बढ़ा है, तो bank account debited क्यों हो रहा है? क्या debit negative नहीं होता? क्या cash balance negative दिखाया जा रहा है?” — यह सच में बहुत अच्छा सवाल है। सहज रूप से direct debit में पैसा निकलता है, debit card से पैसा खर्च होता है, और debit सुनने में debt जैसा लगता है, इसलिए यह सोचना स्वाभाविक है कि debit हमेशा negative होगा
      एक ही शब्द पर लोग जैसे अलग-अलग भाषाएँ बोल रहे हों, यह मज़ेदार भी है और झुंझलाहट भरा भी। कभी-कभी बात छोटी-सी wording पकड़कर यह साबित करने की दिशा में चली जाती है कि कौन सही है
    • इसे “incoming” और “outgoing” से बदलने का सुझाव भी उसी तरह की समस्या वाला लगता है
      क्योंकि lemonade पर 5 डॉलर खर्च करने वाले व्यक्ति के नज़रिए से, वह अपनी Sales item में 5 डॉलर डाल ही नहीं रहा होता। इस लेख और टिप्पणियों में जिस भ्रम की बात हो रही है, वह ठीक-ठीक क्या है, यह मैं अभी भी पूरी तरह नहीं समझ पाया हूँ
    • अगर double-entry bookkeeping से “accounting equation” जैसी अटपटी अभिव्यक्ति हटा दी जाए, तो इसे समझना बहुत आसान है
      credit का मतलब source, debit का मतलब destination है
      अगर आप किसी ग्राहक को 10,000 euro का invoice भेजते हैं, तो मौजूदा exchange rate के हिसाब से 11,000 dollar का एक promise बनता है। तब आप source यानी “Income: Customer A” account को 11,000 dollar credit करते हैं, और “Assets: Accounts Receivable” को 11,000 dollar debit करते हैं
      बाद में अगर ग्राहक ने भुगतान किया लेकिन exchange rate बदल गया और आपको सिर्फ़ 10,500 dollar मिले, तो पहले 11,000 dollar पर दर्ज किया गया वह promise source है, इसलिए Accounts Receivable को 11,000 dollar credit करते हैं। cash में 10,500 dollar आए, इसलिए cash को 10,500 dollar debit करते हैं, और debit तथा credit को balance करने के लिए “Expenses: Loss on Foreign Exchange” में 500 dollar debit करते हैं
      आम तौर पर हर business day के अंत में कंपनी को liquidate नहीं किया जाता, तो उस 500 dollar को किसी काल्पनिक instant liquidation scenario में जबरन फिट करने की क्या ज़रूरत है। बस credit और debit के balance के रूप में रिकॉर्ड कर दीजिए
    • कॉलेज की economics class में मुझे जो बात सबसे ज़्यादा याद रही, वह यह थी कि economists बहुत अजीब mathematical conventions इस्तेमाल करते हैं और उन्हें इसकी परवाह भी नहीं होती
      मैंने बहुत सारे graph देखे जिनमें independent variable Y-axis पर रखा गया था

  • “Credit वह entry है जिसमें पैसा account से बाहर जाता है, और Debit वह entry है जिसमें पैसा account में आता है” — यह सही नहीं है
    debit और credit का मतलब account type के हिसाब से बदलता है: https://en.wikipedia.org/wiki/Debits_and_credits
    शायद यही वजह है कि CPA बनने के लिए एक से ज़्यादा subjects की ज़रूरत होती है: https://www.accounting.com/careers/cpa/how-to-become/

    • जब भी मैं accounting देखता हूँ, account type हमेशा मुझे उलझा देता है। कौन-सा account कहाँ इस्तेमाल होता है, किस account में credit positive है और किसमें negative — यह मुझे ठीक से कभी समझ नहीं आता
      मुझे यह ऐसा तरीका लगता है जिसमें उस ज़माने में, जब लोग entries भरते थे और हाथ से हिसाब लगाते थे, कुछ खास गलतियाँ पकड़ने के लिए काम को दोगुना कर दिया गया था। अपने आप में यह बात समझ में आती है
      लेकिन क्योंकि मैं ऐसी दुनिया में बड़ा हुआ हूँ जहाँ computer सारे calculation करते हैं, यह मुझे “एक ही काम दोहराओ मत” वाले सिद्धांत के ख़िलाफ़ लगता है। अगर आप एक ही बात दो जगह लिखेंगे, तो आखिरकार उनमें से एक ग़लत हो ही जाएगी
      अगर accounting आज के समय में design की जाती, तो शायद इसे ऐसे नहीं बनाया जाता। मैं accountant नहीं हूँ और शायद मैं इसे समझ नहीं पा रहा, इसका मतलब यह नहीं कि व्यवस्था ग़लत है, लेकिन “credit asset account को कम करता है” वाली बात से जो उलझन पैदा होती है, वह किसी बुनियादी गड़बड़ी का संकेत जैसी लगती है
    • उस Wikipedia लेख का दूसरा वाक्य यह है: “किसी account की debit entry यह दिखाती है कि value उस account में transfer हो रही है, और credit entry यह दिखाती है कि value उस account से transfer हो रही है”
    • ज़्यादातर accountants ऐसा ही सोचते हैं, लेकिन मुझे लगता है कि इससे भी ज़्यादा बुनियादी नज़रिया मौजूद है
      CR entry वह है जिसमें कंपनी पर जो देनदारी है — यानी creditors या shareholders के प्रति उसका obligation — बढ़ता है, और DR entry वह है जिसमें कंपनी के पास जो चीज़ें हैं, वे बढ़ती हैं
      accounting equation से इसका संबंध यहाँ देखें: https://news.ycombinator.com/item?id=32501707

  • credit/debit शब्दावली को लेकर काफ़ी उलझन दिखती है
    अगर इसे आधुनिक नज़रिए से ज़्यादा सरल तरीके से सोचना हो, तो बस यह याद रखें कि accounting, negative numbers के आम इस्तेमाल से कहीं ज़्यादा पुरानी है। अगर accounting आज ईजाद की जाती, तो संभव है कि debit/credit accounts की जगह positive/negative accounts इस्तेमाल होते
    addition पर आधारित algebra आज हमें स्वाभाविक लगती है, लेकिन 1604 के एक आम व्यापारी के लिए यह इतनी स्पष्ट नहीं थी, और negative numbers तब भी बहुत पसंद नहीं किए जाते थे
    महत्वपूर्ण बात यह है कि हर transaction के हमेशा दो पहलू होते हैं, और वे एक-दूसरे की inverse operation होते हैं। आखिरकार credit और debit संख्याओं पर inverse operations ही हैं
    इसलिए हम यह नियम बना सकते हैं कि credit = debit हो तो transaction balanced है। आधुनिक ढंग से देखें तो इसे debit + credit = 0 भी कहा जा सकता है, लेकिन जब यह system बना था तब negative numbers पसंद नहीं किए जाते थे, इसलिए यह किसी लक्ष्य से ज़्यादा हमेशा सही निकल आने वाला एक सुखद संयोग जैसा है
    हाथ में मौजूद cash को सबसे ज़्यादा positive, यानी debit प्रकृति वाले account की तरह मानकर उलटा सोचें तो बात तर्कसंगत लगती है। किसी खर्च को process करने के लिए cash account को उल्टी दिशा में process करना पड़ता है, इसलिए उसे credit करते हैं, और पैसा जहाँ गया वहाँ opposite entry के रूप में debit करते हैं। इसलिए expense accounts में आम तौर पर debit balance होता है
    cash आया कहाँ से? income से, और अगर आप cash को debit जैसा बनाना चाहते हैं, तो उसका source credit जैसा होना चाहिए ताकि transaction imbalance न हो। इसलिए income accounts आम तौर पर credit accounts होते हैं, यानी सामान्यतः negative balance या “credit normal” रखते हैं
    इस system की खूबसूरती यह है कि रोज़मर्रा के सभी transactions balanced transactions में सिमट जाते हैं, और जिन accounts का इस्तेमाल हो सकता है वे हर एक लगातार या तो सामान्य credit या सामान्य debit balance प्रकृति रखते हैं। सच में काफ़ी elegant है

    • capital/equity account के normal balance को याद रखने के लिए मैं अक्सर Capital और Credit की alliteration का सहारा लेता हूँ
      उसे और accounting equation को याद रख लें, तो बाकी सभी account types के normal balances निकाले जा सकते हैं
    • मुझे नहीं लगता कि negative numbers का इस्तेमाल बहुत मददगार है। उदाहरण के लिए income को negative मानना बहुत confusing हो जाता है
      करीब एक महीने पहले PTA subreddit में मैंने PTA grammar को और intuitive बनाने पर चर्चा शुरू की थी, और किसी ने सुझाव दिया कि “from”, यानी credit/negative account, और “to”, यानी debit/positive account, को arrows से दिखाया जाए। संख्याओं पर sign नहीं रहता और credit/debit जैसे शब्द भी नहीं आते, इसलिए यह कहीं ज़्यादा intuitive लगता है
      https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
    • debit/credit शब्दावली को लेकर उलझन है, यह देखकर तसल्ली होती है। मैं भी इसे लेकर सच में भ्रमित हो जाता हूँ
      negative numbers वाला पृष्ठभूमि-प्रसंग दिलचस्प है

  • यह अब भी बहुत जटिल है। बात “Transaction कॉलम को table में जोड़ें” से ही पटरी से उतर जाती है
    account data को store नहीं करना चाहिए, बल्कि transactions को store करना चाहिए। accounts तो वहीं से calculate किए जा सकते हैं। “Transactions” table में Date, Amount, SourceAccount, TargetAccount, Description fields हों तो काफ़ी है
    मेरे हिसाब से यहीं चीज़ सुंदर बनती है। bank statement से परिचित होने की वजह से account-केंद्रित सोचने की आदत छोड़कर cash flow के हिसाब से सोचना चाहिए
    बेशक, tax use cases के लिए यह बहुत सरल है। कई बार किसी transaction के कई sources या कई destinations होते हैं, इसलिए ऊपर वाला schema समायोजन माँगेगा। फिर भी मुख्य बात यह है कि सोचने का तरीका अलग होना चाहिए

    • bookkeeping या accounting software में जब भी “Rebalance accounts” जैसा feature दिखता है, तो वह संदिग्ध लगता है और सावधान कर देता है
      यह संकेत है कि किसी programmer ने चालाकी दिखाने की कोशिश में source transactions से calculate करने के बजाय running totals बनाए रखने की कोशिश की है। वहाँ dragons हैं
    • ऐसा design अच्छा नहीं है, इसलिए उससे बचना बेहतर है
      इससे बेहतर design header और detail tables रखना है
      Header: TransactionID, Date, Description, और ज़रूरत के हिसाब से posting status या reconciliation status जैसे fields
      Detail: TransactionID, LineNumber, Account, Amount, Description, और subledger reference number जैसे ज़रूरी fields
      इससे एक ही transaction मनचाही संख्या में accounts को प्रभावित कर सकता है। आखिरकार transaction को ऐसे business event को reflect करना चाहिए जो कई accounts को प्रभावित कर सकता है
    • अगर current balance देखने के लिए हर बार पूरी transaction history फिर से चलानी पड़े, तो क्या वह काफ़ी inefficient नहीं होगा?
    • मूलतः लोगों ने blockchain इसी वजह से ईजाद कर ली
      बारीकियों में यह थोड़ा और जटिल है, जैसे हर transfer के output में source address शामिल होना चाहिए, लेकिन विचार वही है। जैसा इस thread में दूसरी जगह भी कहा गया है, हर transaction में कई inputs और कई outputs चाहिए होते हैं
    • मूल रूप से क्या beancount यही नहीं करता?
      एक plain text file में सभी transactions होते हैं, और जब valuation चाहिए होती है, तब उसी से पूरा ledger मौके पर generate कर लिया जाता है

  • मैं accountant नहीं हूँ, लेकिन पहले मैंने double-entry bookkeeping और basic accounting पढ़ने का फैसला किया था, और HN के अच्छे thread समेत कई जगहों से बहुत कुछ सीखा।
    इस लेख में double-entry bookkeeping कैसे काम करती है और यह समझने की प्रक्रिया बताई गई है कि यह दरअसल एक directed graph है। HN पर accounting के शौकीन बहुत हैं, इसलिए अगर कहीं गलती हो तो आलोचना या सुधार के सुझाव आमंत्रित हैं।

    • उन thread में से एक शायद Martin Kleppmann की ब्लॉग पोस्ट थी। उन्होंने भी double-entry bookkeeping को directed graph के रूप में समझाया है।
      https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
    • मैंने finance क्षेत्र में लगभग 20 साल काम किया है, और मानने में थोड़ी झिझक है, लेकिन यह सच में बहुत अच्छा है।
      अच्छा होता अगर मेरे controllers sales performance को ऐसे graphic flow के रूप में बना पाते। एक निश्चित scale के बाद accounting काफी कठिन हो जाती है, और accounting policy team में professor-level लोगों की ज़रूरत पड़ने लगती है।
      मैंने statistics से जो सीखा, वह यह है कि graphics महत्वपूर्ण होते हैं। सही abstraction का उपयोग करें तो किसी भी संख्या को उसके components के graph के रूप में दिखाया जा सकता है। यह तुरंत समझ में आने वाला क्षण था।
    • computer science के सबसे मज़ेदार क्षणों में से एक वह होता है जब आप समझते हैं कि जो समस्या शुरू में graph जैसी नहीं लग रही थी, वह दरअसल किसी प्रकार की graph problem है।
    • पूरी ज़िंदगी information systems में काम करते हुए जो बड़ी समझ मिली, उनमें से एक यह है कि ERP systems की बुनियाद बनने वाले transactions, जैसे purchase या sale, दो flows में बदल जाते हैं।
      एक तरफ अंदर आने या बाहर जाने वाला पैसा होता है, और दूसरी तरफ product या service। यही accounting की double-entry है। यह साफ़ और सरल लग सकता है, लेकिन मेरे क्षेत्र में इसे समझने वाले लोग बहुत कम हैं।

  • लेख अच्छा लिखा गया है, लेकिन जिन शब्दों के आम तौर पर स्वीकृत अर्थ हैं, उन्हें दोबारा परिभाषित करते समय सावधानी रखनी चाहिए।
    Debit/Credit को Incoming/Outgoing में बदलना एक और technical jargon जैसा लग सकता है और इससे भ्रम पैदा हो सकता है। कोई भी bookkeeper समझता है कि credit cash और debit expense का क्या मतलब है।
    इसे incoming/outgoing में बदल देने से उन लोगों को मदद नहीं मिलती जो वास्तव में यह काम करते हैं या जिन्हें यह काम समझाना होता है। जो naming कई सौ वर्षों से उपयोगी रही है, उसे सीखना किसी उपमा पर निर्भर रहने से अधिक मूल्यवान है।

    • मैं इस बात से सहमत नहीं हूँ कि Debit/Credit को Incoming/Outgoing में बदलना भ्रम पैदा करता है।
      HN पर ऐसी चर्चा आते ही हमेशा कोई न कोई कहता है, “यह बहुत सरल है। credit बस…” और तुरंत जवाब आता है, “तुमने इसे उल्टा समझा है। सरल है। credit…”
      मुझे उन शब्दों को हमेशा के लिए छोड़ देने में ज़रा भी आपत्ति नहीं होगी।
    • समस्या यह है कि accounting jargon आम लोगों की सहज समझ के उलट जाता है।
      जब पैसे को credited कहा जाता है या credit card का इस्तेमाल होता है, तो अच्छा लगता है मानो कहीं से पैसा आ गया हो; और debit, debt जैसा सुनाई देता है, इसलिए बुरा लगता है मानो मेरा पैसा कम हो गया हो।
      मैं जानता हूँ कि इन नामों के पीछे कारण हैं, लेकिन अगर कोई क्षेत्र ऐसे non-intuitive jargon पर अड़ा रहे जो बाहरी लोगों के लिए मौजूद हर दूसरे उपयोग से टकराता हो, तो शायद कम overlapped और अलग अभिव्यक्ति इस्तेमाल करना बेहतर होगा।
    • इससे भी आगे, बुनियादी accounting·bookkeeping terminology जानना finance वालों के साथ काम करते समय लगभग एक superpower जैसा है।
      अगर आप सही jargon का सही तरह से उपयोग करके बातचीत कर सकें, तो आपकी credibility बहुत बढ़ जाती है।
    • लगता नहीं कि यह लेख उन लोगों के लिए है जो पहले से accounting जानते हैं।
      मुझे समझ नहीं आता कि accounting jargon debit/credit को आम भाषा में समझाना technical jargon जैसा क्यों लगेगा। शायद इसलिए कि मैं आम आदमी हूँ।
      जिन लोगों की accounting background नहीं है, उन्हें credit/debit को “पैसा अंदर आना, पैसा बाहर जाना” के रूप में समझाना इस लेख के संदर्भ में पूरी तरह ठीक लगता है। क्या यहाँ credit/debit की “असल” परिभाषा किसी अर्थपूर्ण तरीके से अलग तरह से काम करती है?

  • David P. Ellerman accounting के लिए एक mathematical approach प्रस्तुत करते हैं, जो उस चीज़ पर आधारित है जिसे वे Pacioli group कहते हैं।
    Pacioli group के formal elements x//y की तरह दिखते हैं, जहाँ x और y non-negative integers हैं। x//y और u//v को तब equivalent माना जाता है जब cross-sums x+v और y+u बराबर हों।
    group operation है x//y + u//v = (x+u)//(y+v), और x//y का inverse है y//x, जबकि identity element 0//0 है। अधिक जानकारी के लिए, उदाहरण के तौर पर यह दस्तावेज़ देखें: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...

  • लगता है यहाँ मैं कुछ चूक रहा हूँ। transaction history को directed graph के रूप में देखने से किस बात में मदद मिलती है?
    क्या यह सैकड़ों साल पुरानी double-entry bookkeeping practice से कोई सुधार देता है?
    कुछ transactions वाले toy example में तो यह किसी तरह चलता हुआ लगता है, लेकिन ज़रा सोचिए कि जब node pairs के बीच दर्जनों या सैकड़ों edges बन जाएँगे तो graph कैसा दिखेगा। यह भी स्पष्ट नहीं है कि सामान्य graph algorithms का उपयोग कहाँ होगा।
    यह pliers को hammer की तरह इस्तेमाल करने जैसा लगता है। कर तो सकते हैं, लेकिन क्यों करना चाहिए?

    • मैं आपकी बात समझता हूँ, लेकिन मुझे लगता है कि यह दो तरीकों से मददगार हो सकता है।
      पहला, यह concept को समझने का एक और तरीका है। ज़्यादातर मामलों में यह प्रासंगिक न भी हो, लेकिन कौन जानता है कि कोई कठिन accounting समस्या graph theory के उपयोग से हल हो जाए, या उल्टा accounting से कोई graph theory समस्या हल हो जाए।
      दूसरा, यह flows को visualize करने का एक और तरीका है। हर कोई financial literacy या numbers की समझ में मजबूत नहीं होता, इसलिए संख्याओं वाली table देकर flows को अंकों से infer करवाने के बजाय उन्हें spatial रूप में दिखाया जा सकता है। हर tool सिर्फ experts के लिए नहीं होता।
      पूरी cumulative history को एक ही graph में देखना ज़रूरत से ज़्यादा हो सकता है, लेकिन सिर्फ transaction-date filter जोड़ देने से भी ऐसी insights मिल सकती हैं जो दूसरी visualizations से छूट जाती हैं। location जैसी दूसरी जानकारी से cross-reference करें तो यह और उपयोगी हो सकता है।
    • यह एक काल्पनिक-सा approach है। लेख बहुत बढ़ा-चढ़ाकर लिखा गया है।
      इसने अपनी वैधता स्थापित नहीं की, और यह visualisation अधिक स्पष्ट समझ देती है—लेखक का यह दावा भी कमजोर हो जाता है, क्योंकि double-entry bookkeeping को शुरू से ही geek-style में समझाने की प्रक्रिया में एक category error दिखाई देती है।
      ऊपर से इसने सिर्फ एक बेहद simple transaction को ही दिखाया है। अगर tax depreciation और accounting depreciation अलग हों, foreign exchange gain/loss adjustment हो, franked dividends allocation हो, PAYG हो, किसी और के लिए रखी गई रकम हो, या deferred revenue का कुछ हिस्सा recognise करना हो, तो समझ नहीं आता कि ऐसे अधिक abstract मामलों को graph-based visualisation से कैसे निकाला जाएगा।
    • यह लेख मुझे cryptocurrency के शुरुआती विचारों जैसी एक insight देता है।
      जैसे engineers किसी दूसरे क्षेत्र में पहले से मौजूद मूलभूत सिद्धांतों को बहुत बाद में खोजते हैं, जब software उस क्षेत्र की नकल करने लगता है।