- ใช้ Beancount บันทึกการเงินส่วนบุคคลด้วย ไฟล์ข้อความล้วน ตลอด 10 ปี โดยจัดการข้อมูลราว 45,000 บรรทัดและธุรกรรม 10,000 รายการ
- ใช้เวลาราว 30–45 นาทีต่อเดือนเพื่อ นำเข้าไฟล์ CSV จากรายการเดินบัญชีธนาคารแล้วจัดระเบียบทั้งแบบแมนนวลและอัตโนมัติ พร้อมแยกเป็นไฟล์รายปีเพื่อให้อ่านง่าย
- พัฒนา ไลบรารี importer ที่เขียนด้วย Python สำหรับธนาคารในเยอรมนีขึ้นเองเพื่อเชื่อมต่อกับ Beancount และบางส่วนยังคงดูแลรักษาอยู่จนถึงปัจจุบัน
- จากการพบว่าผู้เริ่มต้นใช้งาน Beancount มีความยากลำบาก จึงได้เขียน คู่มือสำหรับผู้เริ่มต้น และได้รับการตอบรับเชิงบวกจากชุมชน
- ข้อมูลทั้งหมดถูกเก็บไว้ใน อุปกรณ์ภายในเครื่องและคลัง Git ของตนเอง จึงมี ความต่อเนื่องและการควบคุม สูงกว่าแอปหรือบริการใดบริการหนึ่ง
โครงสร้างสมุดบัญชี Beancount ตลอด 10 ปี
- จัดการข้อมูลการเงินด้วย Beancount มาตั้งแต่ปี 2016 และมี รายการรวม 45,011 บรรทัด เก็บอยู่ในไฟล์
.beancount จำนวน 16 ไฟล์
- ใช้ไฟล์
main.beancount เป็นศูนย์กลาง และเชื่อมไฟล์รายปีด้วยวิธี include
- ธุรกรรมทั้งหมดมีประมาณ 9,895 รายการ และมี posting (รายการลงบัญชี) ภายในนั้น 19,743 รายการ
- มี บัญชี (account) ทั้งหมด 1,086 บัญชี แต่ไม่ได้หมายถึงบัญชีธนาคารจริง หากเป็น บัญชีจัดหมวดหมู่เสมือน
- ตัวอย่าง: สามารถสร้างบัญชีแยกตามหมวดอย่างค่าใช้จ่ายซูเปอร์มาร์เก็ต รายได้ บริการสมัครสมาชิก เป็นต้น
- มี เอกสาร PDF จำนวน 507 ไฟล์ แนบกับธุรกรรม จึงสามารถตรวจสอบใบเสร็จที่เกี่ยวข้องได้ง่ายเมื่อต้องยื่นภาษี
- จำนวน posting รายปีเพิ่มขึ้นจาก 715 รายการในปี 2016 เป็น 2,651 รายการในปี 2023 โดยปี 2023 เป็นปีที่มีความเคลื่อนไหวมากที่สุด
ขั้นตอนการจัดการรายเดือน
- ใช้เวลาประมาณ 30–45 นาที ในแต่ละเดือนเพื่อดาวน์โหลดรายการเดินบัญชีธนาคารเป็นไฟล์ CSV แล้วนำเข้าไปยัง Beancount
- ใช้ CSV เพราะแยกวิเคราะห์ได้ง่ายกว่า PDF
- importer ที่เขียนด้วย Python จะแปลงข้อมูล CSV ให้อยู่ในรูปแบบของ Beancount
- หลังเพิ่มธุรกรรมที่แปลงแล้วลงในไฟล์
.beancount จะ ปรับให้ยอดคงเหลือเป็น 0 ตามหลักการบัญชีคู่
- บางส่วนจัดหมวดหมู่อัตโนมัติ และบางส่วนปรับด้วยตนเอง
- เมื่อขึ้นปีใหม่ จะย้ายธุรกรรมของปีก่อนหน้าไปไว้ในไฟล์
<year>.beancount แล้วรวมไว้ใน main.beancount เพื่อจัดการ
- ประวัติธุรกรรมทั้งหมดถูกจัดเก็บเป็น ไฟล์ข้อความภายในไดเรกทอรีเดียว
การพัฒนา Beancount Importer สำหรับธนาคารเยอรมนี
- โดยพื้นฐานแล้ว Beancount ไม่รู้จักรูปแบบรายการเดินบัญชีของธนาคาร จึงจำเป็นต้องแปลงผ่าน คลาส importer
- เนื่องจากใช้งานบัญชีธนาคารในเยอรมนี จึงได้พัฒนา importer หลายตัวขึ้นเอง
- ไลบรารีสามตัวแรกยังคง ได้รับการดูแลและใช้งานอย่างต่อเนื่อง ในปัจจุบัน
จากผู้ใช้สู่ผู้เขียน
- เอกสารของ Beancount มีจำนวนมาก แต่ สำหรับผู้เริ่มต้นนั้นมีอุปสรรคในการเริ่มต้นสูง
- จากประสบการณ์ที่เรียนรู้ผ่านการลองผิดลองถูก จึงได้เขียน คู่มือเบื้องต้น ขึ้นมา
- เผยแพร่ที่ personalfinancespython.com
- ถูกกล่าวถึงในหน้า external contributions ของเอกสารทางการ Beancount
- ได้รับ תגובותเชิงบวก จากรีวิวของผู้อ่าน
บทสรุป
- ข้อมูลการเงินทั้งหมดถูกเก็บเป็น ไฟล์ข้อความภายในเครื่องที่มีการจัดการเวอร์ชันด้วย Git
- ข้อมูลอยู่บน อุปกรณ์ของตนเอง และ ไม่ผูกติดกับแอปหรือบริการใดบริการหนึ่ง
- สามารถวิเคราะห์ได้อย่างอิสระโดยใช้เครื่องมือในระบบนิเวศของ Beancount
- แนวทาง plaintext accounting แบบนี้คือรูปแบบการจัดการการเงินที่ ทรงพลังและอาจอยู่ได้นานกว่าแอปใด ๆ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เห็นด้วยกับหนังสือของ OP แบบเต็มที่ นี่เป็นหนังสือแนะนำที่ดีที่สุดเท่าที่เคยเห็นมาสำหรับการทำความเข้าใจ Beancount / plaintext accounting
ผมเองก็ไม่เคยเข้าใจระบบบัญชีคู่ได้ดีมาตลอดชีวิต จนกระทั่งได้อ่าน "Accounting for Computer Scientists" ของ Martin Kleppman ถึงเริ่มมองภาพออก วิธีอธิบายด้วยทฤษฎีกราฟนั้นตรงไปตรงมาจนน่าประหลาดใจ
เมื่อก่อนผมใช้ Quicken แต่ทุกครั้งที่เปลี่ยนเวอร์ชันต้องป้อนข้อมูลใหม่ เลยสุดท้ายย้ายไป GNU Cash แต่ก็ยังมีปัญหาเรื่องการย้ายข้อมูลอยู่ดี
จากนั้นก็มาเจอ plaintext accounting (PTA) แล้วเลือกใช้ hledger (เพราะกลัวว่า Beancount จะมีปัญหาเรื่องประสิทธิภาพ) พอได้เรียนบัญชีคู่แล้วกลับพบว่ามันง่ายกว่าที่คิด
ผมเขียนสคริปต์ Python เพื่อ parse รายการลงทุนหรือสลิปเงินเดือนที่มาเป็น PDF และทำระบบจัดหมวดหมู่อัตโนมัติให้กับ CSV จากธนาคาร/บัตร เลยทำงานส่วนใหญ่เป็นอัตโนมัติได้
ทุกเดือนใช้เวลาแค่ประมาณหนึ่งชั่วโมงเพื่อทำรายงานการลงทุน งบประมาณ และสรุปภาษี
เพราะเป็น plain text ต่อให้ฟอร์แมตเปลี่ยน ข้อมูลก็ยังปลอดภัย และยัง จัดการเวอร์ชันด้วย git ได้ด้วย
ข้อเสียคือใช้งานบนมือถือไม่ได้ และต้องมีความรู้ทางเทคนิคอยู่บ้าง แต่ถ้าคุณให้ความสำคัญกับกระแสเงิน นี่แหละคือคำตอบ
แต่ฟีเจอร์ ซิงก์อัตโนมัติ ของ Quicken ก็ยังดีที่สุดอยู่ดี เลยแทบหาตัวแทนไม่ได้ ผมเช็ก 27 บัญชีทุกวันเพื่อจับการฉ้อโกงหรือความผิดพลาด การต้องดาวน์โหลด CSV ทุกครั้งแล้วมาจัดการเองเป็นฝันร้ายชัดๆ
แถมช่วงนี้ธนาคารหลายแห่งก็ปิด OFX แล้วหันมาใช้ Intuit เป็นฮับกลาง ทำให้ยิ่งหนีออกมายากขึ้นเรื่อยๆ
ผมได้ไอเดียว่าควร จัดการการเงินส่วนบุคคลเหมือนระบบ build ของโปรเจกต์ มาจาก full-fledged-hledger
โดยเก็บข้อมูลดิบจากสถาบันการเงินไว้ตามเดิม แปลงเป็น CSV ด้วยสคริปต์ แล้วใช้ไฟล์กฎแมปไปเป็นรายการ PTA
แบบนี้ถ้าแก้ logic การแปลงหรือกฎการจัดหมวด ข้อมูลย้อนหลังทั้งหมดก็จะอัปเดตอัตโนมัติ
เริ่มจากข้อมูลแค่หนึ่งเดือนก่อนแล้วค่อยๆ ขยายได้ — เช่นรวมถึง ประวัติคำสั่งซื้อ Amazon หรือ ใบเสร็จ Paypal ก็ยังได้
ผมใช้ Beancount มาหลายปีแล้ว
ปีนี้ก็เปลี่ยนไปใช้โครงสร้างไฟล์แยกตามปีแบบ OP เหมือนกัน ก่อนหน้านี้ใช้ไฟล์เดียวขนาด 2 ล้านบรรทัดจนปลั๊กอิน Emacs เริ่มช้า
ข้อดีของวิธีนี้คือสามารถติดตามทุกอย่างได้ — การลงทุน เงินบำนาญ RSU บัญชีธนาคาร ฯลฯ แม้แต่ การใช้ไฟฟ้า (kWh) ก็ยังสร้างโมเดลได้
ช่วงหลังผมทำ เครื่องมืออัตโนมัติที่ใช้ LLM เยอะมาก เช่น รีแฟกเตอร์ transaction rule engine ด้วย Claude ให้กลายเป็นแอปที่มี UI ซึ่งเมื่อก่อนคงต้องใช้เวลาหลายวัน
ดูเหมือนหลายคนจะสับสนระหว่าง plain text กับ บัญชีคู่
Beancount รองรับทั้งสองอย่าง แต่ถึงไม่รู้บัญชีคู่ก็ยังทำบัญชีแบบ plain text ได้
อย่างไรก็ตาม บัญชีคู่เป็นเครื่องมือที่ยอดเยี่ยมมากสำหรับจัดระบบความรู้ เลยแนะนำให้เรียนไว้
ส่วนประโยชน์ของ plain text เองนั้นผมค่อนข้างกังขา มันดูเหมือนเป็นปฏิกิริยาตอบโต้ต่อ การพึ่งพาคลาวด์ หรือ vendor lock-in แต่ถ้าทำบัญชีคู่บนเครื่องตัวเองด้วยซอฟต์แวร์เสรี ก็เพียงพอแล้ว
ข้อสรุปของผมมีดังนี้:
ผมใช้ GnuCash อยู่ และแม้จะไม่สมบูรณ์แบบ แต่มันสอดคล้องกับแนวคิดนี้มาก
ผมเพิ่งเริ่มใช้ PTA ไม่นานนี้ และกำแพงในการเริ่มต้นค่อนข้างสูง
ก่อนอื่นต้องเรียนบัญชีคู่ แล้วก็ต้องเลือกหนึ่งใน ledger-cli / hledger / beancount ซึ่งความต่างค่อนข้างละเอียดอ่อน และมักตัดสินกันที่คุณภาพของชุมชนหรือเอกสาร
หลังจากนั้นก็ต้องคิดว่าจะดึงข้อมูลจากบัญชีไหนก่อน จะเอาข้อมูลย้อนหลังมากแค่ไหน และจะตั้งค่า importer อัตโนมัติอย่างไร
hledger ใช้ DSL ส่วน Beancount ใช้ Python เวลาส่วนใหญ่หมดไปกับการแก้ไขด้วยมือ
จากนั้นก็จะมีคำถามใหม่ๆ ตามมา เช่น งบประมาณ ภาษี การแชร์กับคู่สมรส ฯลฯ
แต่ผมรู้สึกว่า คุณค่าที่แท้จริงของ PTA คือการที่มันทำให้เราเริ่มตระหนักถึงคำถามเหล่านี้ด้วยตัวเอง
ทุกปีเราต้องตัดสินใจทางการเงินมากมาย ทั้งเรื่องบำนาญ ประกัน ค่าอินเทอร์เน็ต หรือข้อเสนองานใหม่ การเข้าใจเศรษฐกิจของตัวเองอย่างละเอียดจึงเป็นพลังอย่างมาก
ผมใช้ ledger-cli กับ Emacs มา 10 ปีแล้ว และเมื่อก่อนก็เคยใช้ GnuCash ด้วย
สำหรับมือใหม่ ผมมี หนังสือสอนบัญชีคู่ ที่เขียนไว้ด้วย
ผมใช้ PTA มาตั้งแต่ปี 2018 และได้บทเรียนมากมายจากการลองผิดลองถูก
บริการเชิงพาณิชย์มักแสดงแค่บางบัญชี แต่ PTA ทำให้เห็น ภาพการไหลของการเงินทั้งหมด ได้ครบถ้วน
ตัวอย่างเช่นสามารถตามดู ที่มาที่ไป (provenance) ของทุกขั้นตอนได้ ตั้งแต่หุ้นที่ได้รับจากบริษัทถูกขาย จนเงินเข้าบัญชีธนาคาร
สำหรับผม สเปรดชีต Excel คือเครื่องมือที่สมบูรณ์แบบ ผมแค่เพิ่มตัวเลขที่ต้องใช้ทุกสัปดาห์
เอกสารต่างๆ ขัดแย้งกันและเข้าใจยาก และแม้แต่นักบัญชีเองหลายคนก็ยังเข้าใจแนวคิดพื้นฐานผิดๆ อยู่
ผมจัดการการเงินด้วยวิธีง่ายๆ โดยใช้ สเปรดชีต มาตลอด 20 ปี
อัปเดตเดือนละประมาณ 5 นาที และติดตามแค่รายการหลัก เช่น ค่าไฟ ค่าทำความร้อน ประกัน เงินออม ฯลฯ
เป้าหมายคือ ดูแนวโน้มการใช้จ่าย และ กันงบประมาณรายปี ส่วนเงินที่เหลือก็ใช้ไปตามปกติ
ผมบันทึกแยกเฉพาะค่าใช้จ่ายที่เกิน $100 เพื่อจะได้ตามดูเฉพาะรายการใหญ่ๆ
ผมดาวน์โหลด CSV จากธนาคาร/บัตรทุกเดือนแล้วใช้สคริปต์ Python วิเคราะห์
ใช้ โค้ดที่ LLM เขียนให้ วิเคราะห์แนวโน้มการใช้จ่ายตามร้านค้า และตั้งให้บัตรใบหนึ่งใช้ เฉพาะการเรียกเก็บเงินแบบประจำ เพื่อดูความเปลี่ยนแปลงได้ง่าย
ขอแนะนำ Fava ซึ่งเป็น GUI frontend สำหรับ Beancount
https://beancount.github.io/fava/
มันช่วยแสดงภาพรวมของทุกบัญชี และมี อินเทอร์เฟซค้นหา/คิวรี กับ การแก้ไขแบบเรียลไทม์ ที่มีประโยชน์มาก
ระบบนี้ดูเจ๋งมากจริงๆ แต่ผมสงสัยว่าเวลา ต้องจัดการการเงินร่วมกับพาร์ตเนอร์ที่ไม่ใช่สายเทคนิค ควรทำอย่างไร
ตอนนี้เราใช้ YNAB อยู่ เพราะ UI เรียบร้อยและทำงานร่วมกันง่าย Beancount จะทำอินเทอร์เฟซแบบนั้นได้ไหม?
ผมเองก็เคยหมกมุ่นกับ PTA แล้วเริ่มทำ log ไว้ แต่ การต้องดาวน์โหลดธุรกรรมด้วยมือจากหลายธนาคารมันยุ่งยากเกินไป
ได้ยินมาว่าระบบอัตโนมัติคือคำตอบ แต่ก็อยากรู้ว่าคนอื่นทำกันอย่างไรจริงๆ — ใช้ API อย่าง Plaid หรือสร้าง web scraper หรือ PDF parser กันเอง?
สุดท้ายผมเลยยอมจ่าย YNAB ปีละ $130 เพราะคู่สมรสพอใจและทุกอย่างเชื่อมอัตโนมัติหมด
น่าจะใช้ YNAB API สำรองข้อมูลออกมาแล้วทำ PTA ควบคู่กันได้ด้วย
วงการการเงินตามหลังในเรื่องนี้มาก แม้ระบบอัตโนมัติจะเพิ่มขึ้นเรื่อยๆ แต่ตอนนี้ก็ยัง ไม่ค่อยคุ้มแรง เท่าไร
เมื่อก่อนผมใช้ YNAB แต่มี ปัญหาธุรกรรมซ้ำ บ่อยมาก จนสุดท้ายเลิกใช้
รีเซ็ตไปสามรอบก็ยังมีข้อผิดพลาด เลยกลับมาจดตามด้วยมือแทน
ตอนนี้ PTA เสถียรกว่ามาก และให้ความรู้สึกว่า ผมเป็นคนควบคุมเอง