सादे टेक्स्ट फ़ाइलों में 10 साल तक व्यक्तिगत वित्त प्रबंधित करने का रिकॉर्ड

 (sgoel.dev)
2 पॉइंट द्वारा GN⁺ 2026-01-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Beancount का उपयोग करके 10 साल तक व्यक्तिगत वित्त को सादा टेक्स्ट फ़ाइलों में रिकॉर्ड किया गया, और लगभग 45,000 पंक्तियों के डेटा तथा 10,000 लेन-देन का प्रबंधन किया गया
  • हर महीने 30–45 मिनट लगाकर बैंक स्टेटमेंट CSV फ़ाइलें इम्पोर्ट कर मैन्युअल और ऑटोमेटेड तरीके से व्यवस्थित किया गया, और पठनीयता बनाए रखने के लिए उन्हें सालवार फ़ाइलों में विभाजित किया गया
  • जर्मन बैंकों के लिए Python-आधारित importer लाइब्रेरी खुद विकसित की गई और Beancount के साथ जोड़ी गई; इनमें से कुछ का रखरखाव आज भी जारी है
  • Beancount शुरुआती उपयोगकर्ताओं की कठिनाइयों को महसूस करते हुए शुरुआती लोगों के लिए एक परिचयात्मक गाइड लिखी गई, जिसे कम्युनिटी में सकारात्मक प्रतिक्रिया मिली
  • सारा डेटा अपने लोकल डिवाइस और Git रिपॉज़िटरी में रखा जाता है, इसलिए किसी खास ऐप या सेवा की तुलना में दीर्घकालिकता और नियंत्रण अधिक है

10 साल के Beancount ledger की संरचना

  • 2016 से Beancount के साथ वित्तीय डेटा प्रबंधित किया जा रहा है, और कुल 45,011 पंक्तियों की एंट्रियाँ 16 .beancount फ़ाइलों में संग्रहीत हैं
    • main.beancount फ़ाइल को केंद्र में रखकर सालवार फ़ाइलों को include तरीके से जोड़ा गया है
    • कुल लेन-देन लगभग 9,895 हैं, और उनके भीतर posting (विभाजित प्रविष्टियाँ) 19,743 हैं
  • कुल 1,086 account मौजूद हैं, लेकिन ये वास्तविक बैंक खाते नहीं बल्कि वर्चुअल वर्गीकरण खाते हैं
    • उदाहरण: सुपरमार्केट खर्च, आय, subscription service आदि के लिए अलग-अलग account बनाए जा सकते हैं
  • 507 PDF दस्तावेज़ लेन-देन से अटैच हैं, जिससे टैक्स फाइलिंग के समय संबंधित रसीदें आसानी से देखी जा सकती हैं
  • सालवार posting की संख्या 2016 में 715 से बढ़कर 2023 में 2,651 हो गई, और 2023 सबसे सक्रिय वर्ष के रूप में दर्ज हुआ

मासिक प्रबंधन प्रक्रिया

  • हर महीने लगभग 30–45 मिनट लगाकर बैंक स्टेटमेंट को CSV के रूप में डाउनलोड किया जाता है और फिर Beancount में इम्पोर्ट किया जाता है
    • PDF की तुलना में CSV को parse करना आसान होने के कारण उसका उपयोग किया जाता है
    • Python-आधारित importer CSV डेटा को Beancount फ़ॉर्मेट में बदलता है
  • बदले गए लेन-देन को .beancount फ़ाइल में जोड़ने के बाद, double-entry bookkeeping के सिद्धांत के अनुसार बैलेंस 0 होने तक समायोजित किया जाता है
    • कुछ का वर्गीकरण अपने आप हो जाता है, कुछ को मैन्युअल रूप से समायोजित किया जाता है
  • नया साल शुरू होने पर पिछले साल के लेन-देन को <year>.beancount फ़ाइल में स्थानांतरित किया जाता है और main.beancount में शामिल करके प्रबंधित किया जाता है
  • सभी लेन-देन का रिकॉर्ड एक ही डायरेक्टरी के भीतर टेक्स्ट फ़ाइलों में व्यवस्थित रहता है

जर्मन बैंकों के लिए Beancount Importer का विकास

  • Beancount अपने-आप बैंक स्टेटमेंट के फ़ॉर्मेट को नहीं समझता, इसलिए importer class के ज़रिए रूपांतरण की ज़रूरत होती है
  • चूँकि जर्मन बैंक खाते उपयोग किए जाते हैं, इसलिए कई importer खुद विकसित किए गए
  • पहली तीन लाइब्रेरी आज भी सक्रिय रूप से maintained और उपयोग की जा रही हैं

उपयोगकर्ता से लेखक तक

  • Beancount का दस्तावेज़ीकरण बहुत व्यापक है, लेकिन शुरुआती लोगों के लिए इसमें प्रवेश की बाधा अधिक है
  • trial and error से सीखे गए अनुभव के आधार पर एक परिचयात्मक गाइड लिखी गई
    • personalfinancespython.com पर प्रकाशित
    • Beancount के आधिकारिक दस्तावेज़ों के external contributions पेज पर इसका उल्लेख है
    • पाठकों की समीक्षाओं में सकारात्मक प्रतिक्रिया मिली

समापन

  • सारा वित्तीय डेटा Git से version-controlled लोकल टेक्स्ट फ़ाइलों के रूप में संग्रहीत है
  • डेटा अपने डिवाइस पर मौजूद है और किसी खास ऐप या सेवा पर निर्भर नहीं है
  • Beancount ecosystem के टूल्स का उपयोग करके इसे स्वतंत्र रूप से विश्लेषित किया जा सकता है
  • plaintext accounting का यह तरीका किसी भी ऐप से अधिक लंबे समय तक टिक सकने वाला वित्त प्रबंधन का एक मजबूत रूप है

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

1 टिप्पणियां

 
GN⁺ 2026-01-03
Hacker News की राय

  • मैं OP की किताब से पूरी तरह सहमत हूँ। मैंने अब तक जो देखा है, उसमें Beancount / plaintext accounting को समझने के लिए यह सबसे बेहतरीन शुरुआती गाइड थी
    मैं भी जिंदगी भर double-entry bookkeeping को ठीक से नहीं समझ पाया था, लेकिन Martin Kleppman का "Accounting for Computer Scientists" पढ़ने के बाद जाकर बात समझ में आई। graph theory से समझाने का तरीका हैरान कर देने जितना सहज था

    • “Quicken एक single-entry accounting system है, इसलिए पैसा अचानक पैदा हो सकता है या गायब हो सकता है। double-entry bookkeeping में, अगर एक account में पैसा डालना है तो वह किसी दूसरे account से निकलना ही चाहिए” — यह सार बात के बिल्कुल केंद्र पर जाता है। यह पंक्ति मैंने quicken2beancount में देखी थी
    • यह दिलचस्प है कि तुम्हें double-entry bookkeeping कठिन लगी। असल में हर transaction एक साथ दो accounts को छूता है, और debit व credit का योग बराबर होना चाहिए — सिद्धांत तो काफी सीधा है। graph theory इसे और सरल कैसे बनाती है, यह मैं आसानी से कल्पना नहीं कर पा रहा
    • इसका ज़िक्र करने के लिए धन्यवाद, Michael!

  • मैं पहले Quicken इस्तेमाल करता था, लेकिन हर बार version बदलने पर data दोबारा दर्ज करना पड़ता था, इसलिए आखिरकार GNU Cash पर चला गया। लेकिन migration की दिक्कतें वहाँ भी थीं
    फिर मुझे plaintext accounting(PTA) मिला और मैंने hledger चुना (क्योंकि लगा कि Beancount में performance issues हो सकते हैं)। double-entry bookkeeping सीखने पर यह उम्मीद से ज्यादा सरल निकला।
    PDF में आने वाले investment statements और payslips को मैं Python scripts से parse करता हूँ, और bank/card CSV को auto-classify करने की व्यवस्था भी बना रखी है, इसलिए ज़्यादातर चीज़ें automated हैं।
    मैं महीने में लगभग एक घंटा लगाकर investment reports, budget, और tax summary बनाता हूँ।
    plain text होने की वजह से format बदल जाए तब भी data सुरक्षित रहता है, और git से version control भी किया जा सकता है।
    कमी बस यह है कि mobile पर काम नहीं करता, और थोड़ा technical knowledge चाहिए। लेकिन जिन लोगों के लिए पैसों का flow महत्वपूर्ण है, उनके लिए यही सही जवाब है

    • “data दोबारा दर्ज करना पड़ता था” से तुम्हारा क्या मतलब है, यह जानने की जिज्ञासा है। मैं 1992 से Quicken इस्तेमाल कर रहा हूँ, और version बदलने पर मुझे कभी data फिर से दर्ज नहीं करना पड़ा
    • मैं भी Quicken से निकलना चाहता हूँ, लेकिन Intuit पर निर्भरता बहुत गहरी है। 2000 के बाद के सारे transactions proprietary format में बंधे हुए हैं।
      लेकिन Quicken का automatic sync feature अब भी सबसे बेहतर है, इसलिए उसका विकल्प ढूँढना मुश्किल है। मैं 27 accounts रोज़ check करता हूँ ताकि fraud या errors पकड़ सकूँ, और हर बार CSV डाउनलोड करके manually process करना एक बुरा सपना होगा।
      ऊपर से आजकल banks OFX बंद कर रहे हैं और Intuit को बीच के hub की तरह इस्तेमाल कर रहे हैं, इसलिए इससे बाहर निकलना और मुश्किल होता जा रहा है

  • निजी वित्त को project build system की तरह manage करने का विचार मैंने full-fledged-hledger से सीखा
    financial institutions से मिला raw data जैसा है वैसा ही store किया जाता है, scripts से उसे CSV में बदला जाता है, और फिर rule files के जरिए PTA entries में map किया जाता है।
    इससे फायदा यह है कि अगर conversion logic या classification rules बदलें, तो पूरा पुराना data अपने-आप update हो जाता है।
    शुरुआत में सिर्फ एक महीने के data से शुरू किया जा सकता है, और धीरे-धीरे दायरा बढ़ाया जा सकता है — जैसे Amazon order history या Paypal receipts तक शामिल करना

    • किसी ने मज़ाक किया: “PTA का Parent Teacher Association से क्या संबंध है?”
    • mortgage accounting मुझे उलझाऊ लगा था, और उस link में इसकी अच्छी व्याख्या है। जिज्ञासा है कि क्या तुमने सच में वही codebase इस्तेमाल किया, या सिर्फ उसके सिद्धांतों से प्रेरणा ली। मुझे Haskell नहीं आती, इसलिए यह भी नहीं पता कि इसमें कितना modification चाहिए होगा

  • मैं कई सालों से Beancount इस्तेमाल कर रहा हूँ।
    इस साल से मैंने भी OP की तरह साल-दर-साल file structure अपना लिया। पहले 20 लाख पंक्तियों की एक single file थी, और Emacs plugin धीमा पड़ने लगा था।
    इस तरीके का फायदा यह है कि आप सब कुछ track कर सकते हैं — investments, pension, RSU, bank accounts वगैरह। यहाँ तक कि बिजली की खपत (kWh) भी model की जा सकती है।
    हाल में मैं LLM का इस्तेमाल करने वाले automation tools बहुत बना रहा हूँ। उदाहरण के लिए, मैंने Claude की मदद से transaction rule engine को UI वाले app में refactor किया। पहले ऐसा काम कई दिन ले लेता

    • मैंने भी बिजली का बिल kWh के हिसाब से track किया था, लेकिन सच कहूँ तो उसका ज़्यादा फायदा नहीं निकला 😂
    • मैं भी LLM से personal finance tools बनाना चाहता हूँ, लेकिन sensitive data देने की चिंता रहती है। शायद anonymized local model पर process करना बेहतर होगा

  • लगता है बहुत से लोग plain text और double-entry bookkeeping को आपस में गड़बड़ा रहे हैं।
    Beancount दोनों को support करता है, लेकिन double-entry bookkeeping जाने बिना भी plain text accounting की जा सकती है।
    फिर भी, double-entry bookkeeping ज्ञान को व्यवस्थित करने का शानदार साधन है, इसलिए मैं इसे सीखने की सलाह दूँगा।
    plain text की उपयोगिता को लेकर मैं थोड़ा संशय में हूँ। यह शायद cloud dependence या vendor lock-in से बचने की प्रतिक्रिया जैसा है, लेकिन local पर free software के साथ double-entry bookkeeping करना ही काफी है।
    मेरा निष्कर्ष यह है:

    • accounting: महत्वपूर्ण
    • double-entry bookkeeping: महत्वपूर्ण
    • cloud/lock-in से बचना: महत्वपूर्ण
    • proprietary formats से बचना: महत्वपूर्ण
    • plain text: महत्वपूर्ण नहीं
      मैं GnuCash इस्तेमाल करता हूँ, और यह परफेक्ट तो नहीं है, लेकिन इस दर्शन के काफ़ी अनुरूप है
    • accounting में automation ज़रूरी है, ऐसा मेरा मानना है। manual work में errors बहुत होते हैं, और accuracy सबसे ऊँची प्राथमिकता (P0) requirement है
    • मैं भी GnuCash को प्यार भी करता हूँ और उससे चिढ़ता भी हूँ। उसका UI बहुत पुराना लगने लगा है। अच्छा होता अगर engine को library की तरह अलग किया जाता ताकि अलग-अलग UI उसके ऊपर बनाए जा सकें

  • मैंने हाल ही में PTA शुरू किया है, और इसकी entry barrier काफ़ी ऊँची है।
    पहले double-entry bookkeeping सीखनी पड़ती है, फिर ledger-cli / hledger / beancount में से एक चुनना होता है। इनके बीच फर्क सूक्ष्म हैं, इसलिए community और documentation quality ही निर्णायक बनते हैं।
    उसके बाद सोचना पड़ता है कि कौन-कौन से accounts पहले import किए जाएँ, कितना पुराना data शामिल किया जाए, और automatic importers कैसे set up किए जाएँ।
    hledger DSL इस्तेमाल करता है, जबकि Beancount Python का उपयोग करता है। ज़्यादातर समय manual editing में जाता है।
    उसके बाद budget, tax, spouse के साथ sharing जैसी नई समस्याएँ सामने आती हैं।
    लेकिन मुझे लगता है कि इन सवालों को खुद पहचानना ही PTA की असली कीमत है।
    हर साल pension, insurance, internet bill, नई नौकरी के offer जैसी अनगिनत वित्तीय निर्णय लेते समय, अपनी अर्थव्यवस्था को बारीकी से समझना बहुत ताकत देता है

    • मैं गणितज्ञ, programmer, और finance major रहा हूँ, इसलिए मैंने double-entry bookkeeping जल्दी सीख ली थी। मुझे यह अमूर्त और सुरुचिपूर्ण प्रणाली बेहद सुंदर लगती है।
      मैं 10 साल से ledger-cli और Emacs इस्तेमाल कर रहा हूँ, और पहले GnuCash भी इस्तेमाल कर चुका हूँ।
      शुरुआती लोगों के लिए मेरी लिखी double-entry bookkeeping की पाठ्यपुस्तक भी है
    • double-entry bookkeeping की आदत पड़ जाने पर यह आसान लगती है, लेकिन शुरुआत में learning curve काफ़ी steep होती है।
      मैं 2018 से PTA इस्तेमाल कर रहा हूँ, और trial-and-error से बहुत कुछ सीखा है।
      commercial services कुछ चुने हुए accounts ही दिखाती हैं, लेकिन PTA से पूरे वित्तीय प्रवाह को पूरी तरह समझा जा सकता है।
      उदाहरण के लिए, company से मिले shares बिककर bank account में जमा होने तक की पूरी provenance track की जा सकती है
    • मुझे लगता है कि personal finance के लिए double-entry bookkeeping कुछ ज़्यादा ही overkill है।
      मेरे लिए Excel spreadsheet एकदम सही tool है। मैं हर हफ्ते बस ज़रूरी numbers जोड़ देता हूँ
    • मैं सहमत हूँ कि accounting ऊपर से आसान दिखती है, लेकिन सीखना कठिन है।
      इसका साहित्य विरोधाभासी और जटिल है, और यहाँ तक कि accountants भी कई बार इसे अवधारणात्मक रूप से गलत समझते हैं

  • मैं 20 साल से एक सरल तरीके से spreadsheet में अपना वित्त संभाल रहा हूँ।
    मैं महीने में लगभग 5 मिनट update करता हूँ, और सिर्फ बिजली, heating, insurance, savings जैसे मुख्य मदों को track करता हूँ।
    लक्ष्य है खर्च के रुझान समझना और सालाना budget बनाए रखना। जो पैसा बचता है, उसे बस खर्च कर देता हूँ

    • मैं भी लगभग ऐसा ही करता हूँ। महीने के हिसाब से account balances, income, taxes, investment transfers, housing cost, insurance दर्ज करता हूँ। इतना वित्तीय स्थिति समझने के लिए काफी है
    • मैं भी पहले plain text में करता था, लेकिन शादी के बाद shared management के लिए spreadsheet पर चला गया।
      मैं सिर्फ $100 से ऊपर के खर्च अलग से दर्ज करता हूँ ताकि बड़े खर्चों पर नज़र रहे
    • मैं भी household finance के लिए spreadsheet इस्तेमाल करता हूँ, लेकिन दूसरों के पैसे (जैसे trusts) manage करते समय hledger का उपयोग करता हूँ। क्योंकि वहाँ double-entry bookkeeping और reconciliation ज़रूरी है
    • अगर automation चाहिए तो Tiller की सिफारिश करूँगा। यह bank से जुड़कर transactions अपने-आप spreadsheet में लाता है और budget templates भी देता है
    • मैं भी बहुत ज़्यादा obsessed नहीं हूँ, लेकिन proprietary services या paid apps पसंद नहीं हैं।
      मैं हर महीने bank/card CSV डाउनलोड करके Python scripts से उनका analysis करता हूँ।
      LLM से लिखवाए गए code से merchant-wise spending trends देखता हूँ, और एक card को सिर्फ recurring payments के लिए dedicated रखा है ताकि बदलाव आसानी से समझ आ जाएँ

  • मैं Beancount के लिए Fava नाम का GUI frontend सुझाऊँगा
    https://beancount.github.io/fava/
    यह पूरे accounts को visualize करता है, और इसका search/query interface और real-time editing feature बहुत उपयोगी हैं

  • यह system सच में बहुत बढ़िया लगता है, लेकिन मैं सोचता हूँ कि non-technical partner के साथ finances manage करते समय इसे कैसे अपनाया जाए।
    हम YNAB इस्तेमाल करते हैं, क्योंकि उसका UI साफ-सुथरा है और collaboration आसान है। क्या Beancount में भी ऐसा interface बनाया जा सकता है?

    • ठीक नीचे वाली comment में Fava की सिफारिश की गई है
    • अगर आप iPhone इस्तेमाल करते हैं, तो MoneyStats app की सिफारिश करूँगा। यह सुंदर है और set up करना आसान है, इसलिए साथ में इस्तेमाल करने के लिए अच्छा है

  • मैं भी पहले PTA में काफ़ी डूब गया था और logs रखना शुरू किया था, लेकिन कई banks से transactions manually डाउनलोड करना बहुत झंझट वाला निकला
    लोग कहते हैं automation ही जवाब है, लेकिन असल में वे यह कैसे करते हैं — क्या Plaid जैसी API इस्तेमाल करते हैं, या web scraper और PDF parser बनाते हैं?
    आखिरकार मैं YNAB को साल के $130 दे रहा हूँ। spouse satisfaction भी ऊँची है, और सब कुछ अपने-आप connect हो जाता है।
    शायद YNAB API से data backup लेकर PTA को साथ-साथ चलाया जा सकता है

    • मैंने PDF statement parsers खुद बनाए हैं। कुछ सीधे PyMuPDF से लिखे, और कुछ Claude को sample statements देकर generate करवाए।
      financial industry इस मामले में बहुत पीछे है। automation बढ़ तो रही है, लेकिन अभी भी मेहनत के मुकाबले लाभ कम है
    • मैंने भी आज सुबह setup पूरा किया। हर दो हफ्ते में 18 accounts check करना मुझे अच्छा लगता है, इसलिए मेरे लिए यह बड़ी परेशानी नहीं है।
      मैं पहले YNAB इस्तेमाल करता था, लेकिन duplicate transactions की समस्या बार-बार आती थी, इसलिए आखिरकार छोड़ दिया।
      मैंने तीन बार reset किया, लेकिन errors आते ही रहे, इसलिए अंत में manual tracking पर लौट आया।
      अब PTA कहीं ज़्यादा stable लगता है, और ऐसा महसूस होता है कि नियंत्रण मेरे हाथ में है