- असली पैसे से जुड़ी fintech में कुछ cents का फर्क भी users का भरोसा तोड़ देता है, और transactions को single-entry तरीके से रिकॉर्ड करने वाले stock trading startup को dancing cents समस्या का सामना करना पड़ा
- Single-entry ledger में सिर्फ पैसे का आना-जाना बचता है, इसलिए foreign exchange, broker के rounding to even, FINRA TAF fees जैसे फर्क पैदा करने वाले कारणों को trace करना मुश्किल होता है
- Double-entry ledger मानता है कि पैसा हमेशा एक account से दूसरे account में जाता है, और Accounts, Entries, Transactions को अलग करके source और destination दोनों रिकॉर्ड करता है
- अगर Entries की pending, discarded, posted states और Transactions की posting conditions स्पष्ट रखी जाएँ, तो partial failures और compensation Entries को अधिक सुरक्षित तरीके से संभाला जा सकता है
- Ledger accounting reporting के लिए interface होने के साथ-साथ पैसे की consistency बनाए रखने वाला system of record भी है, इसलिए scale करते समय availability और strong consistency के बीच tension बढ़ता है
कुछ cents के फर्क ने user trust तोड़ दिया
- Stock trading platform बना रहे startup ने “make it work, make it right, make it fast” principle अपनाया और शुरुआत से double-entry accounting system नहीं बनाया
- Launch के तुरंत बाद vendor द्वारा पहचानी गई राशि और internal system द्वारा पहचानी गई राशि में कुछ cents का अंतर आने लगा
- Internally इसे dancing cents कहा गया
- User ने Apple stock के 5 dollars खरीदे, लेकिन order 4.98 dollars दिखे तो वह तुरंत customer support से संपर्क करता है
- समस्या का असली मुद्दा loss की रकम से ज्यादा trust और growth था
- नाराज़ users service recommend नहीं करते थे, और startup की growth रुक गई
- CEO ने निर्देश दिया कि गलत transaction होने पर customer support कुछ cents manually compensate करे
- इसे handle करने के लिए Slack bot भी बनाया गया
पैसा current balance नहीं, future value तक track करता है
- Ledger पैसे को track करने वाला system है
- पैसा सिर्फ current balance नहीं है; आगे मिलने वाली value या दी जाने वाली value को express करने के लिए इसकी जरूरत होती है
- Conceptually पैसा future asset है
- “User ने 5 dollars दिए”, “User ने 6 dollars दिए” जैसे सिर्फ deposits/withdrawals रिकॉर्ड करना actual financial flow समझाने के लिए पर्याप्त नहीं है
- Bank transfer internet standards से धीमे होते हैं, और कई banks transfers को next business day settle करते हैं
- Payment complete होने पर यह भरोसा हो जाता है कि कभी न कभी पैसा मिलेगा
- लेकिन stock अभी broker के जरिए खरीदना होता है
- कुछ दिनों बाद settle होने वाली pending amount और तुरंत broker को जाने वाली amount, दोनों को साथ-साथ express करना पड़ता है
- Single-entry approach में error आने पर rollback बहुत मुश्किल होता है, और कुछ corner cases में rollback की कोशिश भी नहीं की जा सकती
Single-entry ledger debugging को क्यों रोकता है
- Single-entry ledger funds flow दिखा सकता है, लेकिन यह नहीं समझा सकता कि वह flow क्यों हुआ
- किसी खास money movement का कारण खोजने के लिए कई models के data को जोड़ना पड़ता था, और कुछ cases में वह भी संभव नहीं था
- Double-entry ledger क्या हुआ और क्यों हुआ, दोनों साथ में रिकॉर्ड करता है
- हर money movement एक account से दूसरे account में होता है
- हर cent किस account से आया और किस account में गया, यह रिकॉर्ड होता है
- Dancing cents समस्या single-entry system में solve करना कठिन था
- गायब हुए कुछ cents foreign exchange की वजह से हैं या नहीं, जानना मुश्किल था
- यह broker के rounding to even mechanism की वजह से हो सकता था
- यह दिन के अंत में लगने वाली FINRA TAF fees की वजह से हो सकता था
- अगर यह समझ न आए कि system कैसे काम करता है, तो bugs हटाना भी मुश्किल होता है
Ledger data model: Accounts, Entries, Transactions
- कई engineers पहली बार पैसा track करते समय domain model के अंदर amount डाल देते हैं
- Order में price property रखना या expenses table में amount column रखना ऐसा ही तरीका है
- यह balance as property approach है
- यह approach शुरुआत में जल्दी काम करती है, लेकिन समय के साथ reporting complex और slow हो जाती है, और payment processing व analytics भी मुश्किल हो जाते हैं
- अगर nightly report job में कई घंटे लग रहे हैं, तो यह approach root cause हो सकती है
- Ledger को system की सभी financial transactions derive कर सकने वाले अलग data model के रूप में treat करना बेहतर है
- तीन entities basic structure बनाती हैं
- Accounts: value के buckets, और समय के साथ value कैसे बदलती है इसे देखने का perspective
- Entries: accounts के बीच funds flow, जो हमेशा value के exchange को दर्शाते हैं
- Transactions: Entries सही तरह pair और process हों, यह ensure करने वाली unit
Entries की states और immutability
- Entries की तीन states हो सकती हैं: pending, discarded, posted
- Entry हमेशा pending state में बनाई जाती है
- exchange की गई value
- direction: credit या debit
- referenced account की जानकारी
- Amount की direction को positive और negative numbers से express करना एक common mistake है
- Entries मूल रूप से immutable होती हैं, लेकिन pending Entry को posted Entry बनाने के लिए discarded किया जा सकता है
- Pending Entry को reverse करने के लिए reversal Entry बनाने का alternative भी है
- लेकिन reversal Entry approach account history को messy बना सकती है
- discarded state इस्तेमाल करने पर current Entries देखते समय बस वे items exclude करने होते हैं जिनमें
discarded_atset है, और history भी नहीं खोती
- Double-entry system में non-discarded credit Entries का total और non-discarded debit Entries का total बराबर होता है
- Conceptually इसका मतलब है कि जेब के अंदर पैसा जैसे भी move करें, total amount वही रहती है
- External world को represent करने वाले और Profit and Loss statement में merge होने वाले कुछ special accounts exception के तौर पर balance नहीं हो सकते
Transactions और partial failure handling
- Entries pairs में बनाई जाती हैं, और Transactions ensure करती हैं कि प्रक्रिया intended तरीके से चले
- Transaction तभी posted होती है जब linked Entries posted हों या discarded state में हों और posted Entries से replace की गई हों
- Partial failure वाली Transaction को compensating Entries के जरिए semantically reverse किया जा सकता है
- यह approach Saga pattern के साथ अच्छी तरह फिट होती है
- Saga atomicity को availability के बदले trade off करता है
- कई tables lock करने वाली slow transaction के बजाय process को छोटे individual operations और intermediate checkpoints में बाँटता है
- बीच में अन्य transactions काम कर सकती हैं, जिससे throughput बेहतर होता है
Accounts और normal balance
- Single Account के perspective से Ledger single-entry system जैसा दिखता है
- एक Account का कई Entries से one-to-many relationship होता है
- Total balance linked Entries के individual balances के aggregate value से match होना चाहिए
- Account के normal balance के अनुसार total calculate करने का तरीका बदलता है
- Entry amount के साथ positive/negative sign जोड़ना accounting के लिहाज से avoid करना चाहिए
- कुछ accounts में net credit normal होता है, और कुछ accounts में net debit normal होता है
- उदाहरण के लिए bank cash account में net debit normal हो सकता है, लेकिन overdraft होने पर यह negative हो सकता है
- Normal credit balance का मतलब है कि linked credit Entries का total debit Entries के total से बड़ा होना normal है
- Normal debit balance इसका उल्टा है
Accounting system और engineering system के बीच tension
- Ledger में अलग-अलग needs वाले दो systems साथ मौजूद होते हैं
- Accounting system: बाहरी दुनिया के लिए Ledger का interface
- Engineering system: Ledger खुद को जिस implementation के रूप में देखता है
- Accounting system कई perspectives से aggregated data expose करता है
- Reporting
- Financial ratios
- Business Intelligence
- Engineering system को data की consistency और accuracy ensure करनी होती है
- Fintech company में Ledger sales team के CRM की तरह source of truth की भूमिका निभाता है
- Ledger को scale करना इसलिए मुश्किल है क्योंकि दोनों systems की requirements अलग हैं
- Accounting system high availability और low latency मांगता है
- Engineering system strong consistency और schema-on-write checks मांगता है
Developers के लिए accounting resources
- An Engineer’s Guide to Double-Entry Bookkeeping: basic Python code के साथ double-entry accounting समझाता है
- Double Entry Accounting For Developers: Django Hordak का developers के लिए double-entry accounting explanation
- Modern Treasury ledger series part I: Ledger scaling पर 6-part series का पहला लेख
- Beancount, Martin Kleppmann, Modern Treasury Accounting for Developers: अलग-अलग angles से accounting समझाने वाले developer resources
- Peter Selinger accounting tutorial: गहराई से सीखने के लिए tutorial
- Uber, Square, Airbnb ने भी अपने-अपने systems में double-entry Ledger implement करने के तरीके public किए हैं
1 टिप्पणियां
Hacker News की टिप्पणियां
Synapse के ग्राहकों से भी यही कह कर देखने का मन करता है। कई मिलियन डॉलर गायब हो गए थे
बैंकों को सख्त नियमों के तहत यह मिलान करना होता है कि पैसा कहां गया, लेकिन fintech आम तौर पर ग्राहकों का पैसा जमा रखने वाले एक या कुछ आधारभूत FBO खातों के ऊपर अपना ledger रखती हैं और हर ग्राहक का balance track करती हैं। Synapse के मामले में उसके अपने ledger पर ग्राहकों के balances का कुल योग वास्तविक FBO account balance से कहीं ज्यादा था
बहुत से लोग fraud का शक करते हैं, लेकिन मैं इस पर दांव लगाऊंगा कि यह बस एक अव्यवस्थित और bugs से भरा ledger रहा होगा। अंदरूनी हाल देखने के बाद मुझे नहीं लगता कि मैं कभी fintech deposit account में पैसा रखूंगा; असली bank इस्तेमाल करना बेहतर है। कोई fintech भले ही deposit को FDIC-insured बताकर प्रचार करे, वह सुरक्षा सिर्फ तब मिलती है जब underlying bank fail हो जाए; तब नहीं जब fintech मेरे पैसे को track करने में नाकाम हो जाए
संदर्भ: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...
Andreessen Horowitz ने इसमें निवेश किया था, और ये लोग हर तरह के सरकारी regulation के खिलाफ total war की तरफ रहते हैं
https://finance.yahoo.com/personal-finance/synapse-bankruptc...
उससे पहले ही मुझे लगा था कि codebase इतना बिखरा हुआ है कि ये चीजें ठीक से track नहीं हो पाएंगी, और इस पर मेरी उस manager से बहस हुई थी जो मानती थी कि सब कुछ जादू की तरह चल रहा है। कुछ दिन बाद accounting discrepancies पर audit शुरू होने वाला है, ऐसा email मिला
JPMC ने internally cash flow को consistent तरीके से manage करने के लिए cryptocurrency इस्तेमाल करने का प्रस्ताव रखा था, लेकिन वह असल में कहां तक पहुंचा, नहीं पता
https://lex.substack.com/p/podcast-what-really-happened-at-s...
काफी समय तक बहस की, लेकिन उन्होंने ठीक से माना भी नहीं और ठीक भी नहीं किया। बिना सबूत के मुझे शक हुआ कि शायद अंदर किसी तरह की subtle theft हो, लेकिन incompetence ज्यादा plausible explanation लगती है
BoA में system administrator के तौर पर काम कर चुके एक दोस्त ने बताया कि कुछ logs को 7 साल तक रखना जरूरी था, लेकिन disk भरने लगती तो वे बस उन्हें delete कर देते थे
Google में काम शुरू करने पर जिन चीजों को समझने में समय लगा, उनमें से एक थी scalability के लिए reliability या accuracy से समझौता करना
पहले मैं billing systems या छोटे OLTP web applications बनाता था, और acceptable data loss या non-zero error rate जैसे सवाल मेरे दिमाग में आए ही नहीं थे। प्रति सेकंड millions of requests handle करने पर कुछ requests fail होंगी, इस तथ्य से ज्यादा engineering attitude का फर्क झटका देने वाला था
इसी पल शायद हजारों लोग Gmail खोल रहे हों और वह सही से load न हो रहा हो, या उन्हें 500 error मिला हो। कोई भी उसकी वजह track नहीं करता, क्योंकि user refresh करेगा और अपना दिन आगे बढ़ा देगा। दूसरी तरफ storage durability अगर सालाना 99.99999% जैसी प्रभावशाली संख्या भी हो, तो 2 billion customers होने पर 200 लोगों का दिन सचमुच सबसे खराब गुजर सकता है
logs में हर error की जांच करने की आदत से यह मानने की तरफ जाना कि हर चीज हमेशा थोड़ी-थोड़ी टूटी रहती है और कुछ ठीक करने से पहले उसकी cost देखी जाती है, काफी झटका देने वाला बदलाव था
इसी तरह के scale पर मैंने जो rule of thumb अक्सर देखा है, वह पूरे infrastructure के आधार पर 100 साल में data loss की 1 घटना को लक्ष्य बनाने का है। आम तौर पर cost 10% से काफी कम बढ़ती है, लेकिन data placement algorithms design करते समय combinatorics समझने वाला व्यक्ति चाहिए होता है
अगर इस क्षेत्र को समझना है तो copyset paper अच्छी शुरुआत है
solution present करते हुए जब मैंने यह error rate बताया, तो मुझसे पूछा गया कि वे 200,000 Android users recover कैसे करेंगे। recover करने का कोई तरीका नहीं था और contacts sync बस टूट जाता, इसलिए मुझे redesign करने को कहा गया
ये numbers खुद ही विनम्र बना देते हैं। 99.99% जहां पर्याप्त है ऐसे क्षेत्र निश्चित रूप से हैं, लेकिन उतने ही क्षेत्र ऐसे भी हैं जहां यह पर्याप्त नहीं है
ऐसे मामलों में शुरुआत से ही सही लोगों को हायर करना मदद करता है। ढेर सारे LeetCode विशेषज्ञ हायर करके यह न पूछना ठीक नहीं कि वे data structures और algorithms को दिमाग में याद रखने की क्षमता के अलावा, जो चीज़ सच में बनानी है उसे बना भी सकते हैं या नहीं
अगर लोगों को पता हो कि उस चीज़ को कैसे बनाना है, तो growth की बलि देने की ज़रूरत नहीं पड़ती और वह शुरुआत से ही सही बनती है
कभी-कभी accounting, finance, biology जैसी अलग educational background वाले engineers की ज़रूरत होती है। मेरे career में सबसे अहम बात यह रही कि मैं जिस industry के लिए चीज़ बना रहा हूँ उसे गहराई से समझूँ, और उस field के ऐसे experts को जानूँ जो सच में महत्वपूर्ण सवाल पूछ सकें। वही problem solving और engineering है; बाकी सब programming/coding है
मैंने अपने career का ज़्यादातर हिस्सा technology और finance के overlap वाले क्षेत्र में, मुख्यतः sales tax/use tax compliance में बिताया है। इस दौरान accountants, controllers और lawyers ने मुझ पर कितना असर डाला, यह मैंने पर्याप्त रूप से महसूस नहीं किया था
हाल ही में मैंने एक काफी पुरानी startup के ledger system पर सलाह दी, और यह देखकर हैरान रह गया कि जब finance या accounting background न रखने वाले engineers accounting system बनाते हैं तो वह कैसा दिखता है
किसी जादुई accountant-cum-engineer को ढूँढने की ज़रूरत नहीं है। design process में engineering team के बगल में किसी वास्तविक accountant को बैठा देना ही काफी है। पूरा redesign तैयार करने के बाद मैंने अपने CPA दोस्त से पूरी समीक्षा करवाई; उसने कुछ scenarios में holes निकाले, लेकिन कुल मिलाकर यह ठीक था
पैसा एक कठिन engineering problem है। क्योंकि पैसे के साथ उसके इर्द-गिर्द मौजूद इंसानों की हर तरह की अजीबोगरीब बातें जुड़ी आती हैं
इससे फिर पुष्टि होती है कि engineering leadership में domain knowledge महत्वपूर्ण है। अगर आप किसी finance company में काम करते हैं, तो सही technical decisions और trade-offs के लिए finance की कुछ समझ होनी चाहिए; journalism या commerce में भी यही बात लागू होती है
जिन सफल organizations में मैंने काम किया, वे हमेशा tech team interviews में domain-specific non-technical questions शामिल करते थे। इसके उलट, कुछ technically बहुत मजबूत teams domain insight की कमी की वजह से जूझती रहीं
जहाँ भी देखता हूँ, लगता है कि लोग मेरे जैसे व्यक्ति—जिसके पास accounting career और comparatively छोटा software engineering career है—की बजाय ऐसे व्यक्ति को कहीं ज़्यादा पसंद करते हैं जिसके पास domain knowledge बिल्कुल न हो लेकिन software engineering experience दोगुना हो। सोचता हूँ कि क्या इसे प्रभावी ढंग से इस्तेमाल करने का कोई तरीका है
finance भी technical है, mechanical engineering भी technical है, और sports management या sociology में भी बड़ा technical element होता है। technical competence क्या है, इसे व्यापक रूप से देखने से कई domains में collaboration के लिए ज़रूरी विनम्रता आती है
requirements सही हैं या नहीं, और बना हुआ product उन requirements को पूरा करता है या नहीं, यह engineering के साथ मिलकर verify करना PM का काम है। agile environment में ऐसी बातचीत और validation हर sprint में होती है, इसलिए किसी चीज़ का बहुत लंबे समय तक बिना छने निकल जाना मुश्किल है
अगर PM न हो तो engineering team को गहरी domain knowledge चाहिए होगी, लेकिन वरना यह engineering की responsibility नहीं है। यह product organization की responsibility है
एक पुरानी कहानी सुनाऊँ तो, मैंने double-entry bookkeeping system तो कभी नहीं बनाया, लेकिन दशकों पहले एक internet/telecom startup में billing system बनाया था जिसका revenue 8 digits तक बढ़ा
एक युवा developer के तौर पर मुझे ज़्यादा पता नहीं था और संयोग से पहले ही दिन से billing logic बनाना पड़ गया; अच्छा हो या बुरा, मैंने system में दो जगह इसे बनाया। एक consumer-facing billing webpage में, और दूसरा अलग backend process में जो invoices generate करता था और credit card payments करता था
दोनों को sync में रखना हैरान करने की हद तक मुश्किल था। हम capital burn करते हुए market response खोजने के लिए लगातार iterations कर रहे थे, और नए products और services, नए discount/pricing models, usage-based billing, monthly billing, पहले X बार free, enterprise accounts के primary payer/sub-accounts, users द्वारा specified cost centers, उन cost centers में tax allocation और 1-cent तक allocation जैसी features लगातार जुड़ते गए। हर बार नई wrinkle और exception आती, और दोनों screens/तरीकों के numbers match नहीं करते थे
billing का जिम्मेदार मैं था, इसलिए हर महीने कई दिन सभी invoices को हाथ से देखता था, ताकि credit card charges और paper invoices भेजने से पहले final check में numbers match कर रहे हैं या नहीं। हमेशा, या अक्सर, किसी एक या कुछ customers को प्रभावित करने वाली नई problem मिल जाती थी, और असल billing से पहले code ठीक कर देता था। सब कुछ हाथ से recheck किए बिना छोड़ देना हमेशा बेचैन करता था
mismatch और manual cross-verification हटाने के लिए मैंने billing logic को एक जगह refactor करने पर विचार किया, लेकिन काफी सोचने के बाद समझ आया कि single codebase मुझे असहज करता था, और उल्टा दो codebases मेरी errors पकड़ने में मदद करते थे। बाद में मैंने दोनों implementations के बीच automated runs और cross-validation को धीरे-धीरे आसान बनाया
billing code कुछ messy था, जिस पर घमंड करना मुश्किल है, लेकिन billing accuracy, complaints की कमी, और कई वर्षों तक टली दिल दहला देने वाली गलतियों पर मुझे बहुत गर्व था। successors के लिए छोड़ी गई complexity को लेकर थोड़ा guilt है, लेकिन आज भी मुझे बड़ा regret नहीं है
उस experience के बाद double-entry bookkeeping की motivation मुझे हमेशा अच्छी तरह समझ आई। customers को नुकसान न हो इसलिए अपनी mistakes रोकने के लिए, मैंने एक घटिया तरीके से dual-logic billing code को फिर से invent कर लिया था
पिछली company में जिस data team को मैंने lead किया, उसे पैसे “खो देने” की बदकिस्मत आदत थी। असली पैसा कहीं और जाते हुए गायब नहीं होता था; बल्कि customers से charge करने के records गायब हो जाते थे
जब revenue नहीं खोते थे, तब double billing कर देते थे, और यह सब चलता रहा। management का trust वापस पाने में 3 साल की कठिन मेहनत लगी
क्या टेस्ट भी नहीं थे? अगर हर transaction पर पैसे गायब हो रहे थे—यहाँ तक कि “हर बार 5 डॉलर की खरीद पर transaction log में 4.98 डॉलर रह जाते थे” जैसा उदाहरण देना पड़े—तो समस्या double-entry bookkeeping की कमी से कहीं बड़ी है
ऐसा financial system कौन बनाता है और उसे सामान्य मानता है? compensation भी समस्या है, लेकिन ऐसी service हो तो जितनी जल्दी हो सके भाग जाना चाहिए
वे “dancing cents” जैसे मज़ाक करते थे, और ऐसा इसलिए करते थे क्योंकि उन्हें पता था कि meaningful consequences नहीं झेलने पड़ेंगे। वे तेज़ी से चले, कुछ—पैसों से जुड़ी चीज़—तोड़ दी, और हँसकर टाल दिया
अब वे लोगों को ऐसे सिखाने की कोशिश कर रहे हैं जैसे जानबूझकर ऐसे decisions लेने की वजह से उनके पास कोई moral और technical authority हो। यह हैरान कर देने वाली घमंडी startup VC culture वाली बकवास है
हाँ, bug खोजने में clue मिल सकता था, लेकिन basic tests लिखने से भी वही होता
समझ नहीं आता कि लेखक “make it work, make it right, make it fast” वाली कहावत को negative तरीके से क्यों ला रहा है। शायद उसे “make it fast” कहाँ fit होता है, यह गलत समझ आया है
“make it right” दूसरा step है, और जब तक चीज़ सही तरीके से काम न करने लगे, वहीं काम रुकना चाहिए। system को healthy तरीके से operate करना चाहिए। “make it fast”, यानी optimization, accuracy और soundness की समस्याएँ पूरी तरह हल होने के बाद ही शुरू होता है
इसका delivery speed या जल्दी काम करने से कोई लेना-देना नहीं है; इसका मतलब है optimization को आखिरी step तक टालना
हाँ, अगर लेखक का मतलब यह था कि कोई चीज़ मोटे तौर पर “काम” कर भी रही हो, तो भी वह “सही” से इतनी दूर हो सकती है कि बाद में वापस जाकर ठीक नहीं की जा सकती, और मुश्किल से काम करना शुरू करने से पहले ही उसे शुरू से “सही” बनाना पड़ता है—तो बात समझ आती है
मैं भी सहमत हूँ, और fintech systems की audit में शामिल रहा हूँ। auditors को books approve करने से पहले सब कुछ Excel spreadsheets में download करके numbers reconcile करने पड़ते थे। इसमें बहुत time और money लगा, और मेरा अंदाज़ा है कि 3 साल बाद liquidity event में कम से कम 0.1 unicorn जितना फर्क पड़ा होगा
fast-moving startups में जितनी जल्दी हो सके practically MVP launch किया जाता है। customer base और finances वगैरह बनाने होते हैं, इसलिए वे “make it work” stage पर ही रुक जाते हैं
बेहतर कहावत Facebook की “move fast and break things” होती। हालांकि वह तभी काम करती है जब बाद में ठीक किया जा सके। उदाहरण के लिए, aircraft बना रहे हों तो ऐसा नहीं करेंगे
उस context को देखें तो पहले वाक्य में बताई गई misunderstanding सबसे plausible लगती है। क्योंकि उसके ठीक बाद startups पर आने वाले time pressure की बात है
यहाँ ज्यादातर comments वही दोहरा रहे हैं जिसकी आलोचना लेख कर रहा है। single-entry bookkeeping का बचाव करने वाली लंबी बहसें अनगिनत दिख रही हैं
single-entry bookkeeping आसान और ज्यादा generalized हो सकती है, लेकिन कभी-कभी सदियों में विकसित हुए systems और abstractions को बस अपनाना ही अच्छा विचार होता है
जब तक सच में कुछ अलग जरूरी न हो, double-entry bookkeeping इस्तेमाल करना बेहतर है। programmer instincts को यह असहज लग सकता है, लेकिन जब inconsistencies साफ करने के लिए असली accountant बुलाना पड़ेगा, तब आप इसके लिए शुक्रगुजार होंगे
इसी से जुड़ा सवाल: क्या किसी को payments या पास के domains में programmers के लिए अच्छे resources पता हैं? जैसे “accounting for programmers”
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
https://www.moderntreasury.com/journal/accounting-for-develo...
[0]: https://www.winstoncooke.com/blog/a-basic-introduction-to-ac...
अगर कोई कहे कि आप ऐसा database system इस्तेमाल कर रहे हैं जिसमें हर 10 transactions पर data का 1% गायब हो जाता है, तो क्या आप ऐसी engineering blog advice को seriously ले पाएंगे? यह लेख concept introduction से ज्यादा किसी खास व्यक्ति या group के लिए शांत ढंग से packaged promo ad जैसा लगता है
पैसे move करने वाले software के प्रति इस तरह का लापरवाह रवैया असली लोगों पर क्या असर डाल सकता है, यह देखना हो तो Post Office scandal देखें
https://en.wikipedia.org/wiki/British_Post_Office_scandal
पैसे move करने वाली हर चीज़ को maximum seriousness से लेना चाहिए, और जितनी हो सके उतनी historical failures के बारे में पता होना चाहिए
https://en.wikipedia.org/wiki/Mr_Bates_vs_The_Post_Office