평문 회계(Plain Text Accounting, PTA)

• Plain Text Accounting(PTA) 은 평문 파일에 회계 데이터를 기록하고 Ledger, hledger, Beancount 같은 명령줄 친화적 도구로 처리하는 방식이며, 이 사이트는 관련 자료를 한곳에 모은 포털임
• 커뮤니티 활동은 Matrix/IRC, 포럼, Reddit, Lemmy, Hacker News, Mastodon, X, Bluesky 등으로 나뉘어 있어 질문·소식·프로젝트별 대화를 여러 경로에서 따라갈 수 있음
• 학습 자료는 앱 비교, 공식 문서, 회계 기초, 입문서, 치트시트, 쿡북, FAQ, 슬라이드, 영상으로 정리되어 PTA를 처음 쓰는 사람도 단계별로 접근 가능함
• 앱 생태계는 Ledger, Beancount, hledger를 중심으로 여러 구현체와 기능 매트릭스를 제공하며, 대표 3개 도구는 각각 C++/Python/Haskell 기반이고 2025~2026년 릴리스 기록이 있음
• 가져오기·변환, 편집기 플러그인, 송장, 가격 조회, 리포팅, 시간 기록, UI, 워크플로, 라이브러리까지 연결되어 평문 회계 데이터를 다양한 작업 환경에 붙일 수 있음

---

PTA의 개념과 plaintextaccounting.org의 역할

• Plain Text Accounting은 평문 파일과 Ledger, hledger, Beancount 같은 효율적인 명령줄 친화적 소프트웨어로 부기와 회계를 수행하는 방식임
• plaintextaccounting.org는 PTA 커뮤니티의 도구, 문서, 실천 사례로 가는 포털 역할을 함
• 사이트 저장소 업데이트를 받을 수 있고, 재무 보고서와 후원 안내도 함께 제공됨

커뮤니티와 토론 채널

• 실시간 대화는 Matrix의 #plaintextaccounting, plaintextaccounting Matrix space, Libera Chat의 #plaintextaccounting IRC 채널로 이어짐
• 토론과 소식은 여러 공개 채널에 분산되어 있음
  • PTA forum
  • /r/plaintextaccounting
  • lemmy.world/c/plaintextaccounting
  • Hacker News의 plain text accounting 관련 stories/comments 검색
  • Mastodon의 #plaintextaccounting, #ledgercli, #hledger, #beancount
  • Twitter/X, Bluesky 검색과 해시태그
• Stack Exchange에는 ledger-cli와 hledger 태그 및 검색 링크가 제공됨
• 프로젝트별 메일링리스트와 채팅, This Week In Hledger도 연결되어 있음

문서와 학습 자료

• 앱 비교 자료는 PTA 앱 목록, 기능 매트릭스, “어떤 PTA 앱을 선택해야 하는가” FAQ, Syntax Quick Reference를 포함함
• 앱 공식 문서로 Ledger, hledger, Beancount, rustledger, Ledger(Go), Tackler, pta 문서가 연결됨
• 회계 기초 자료는 PTA FAQ, hledger의 Accounting basics/links, Beancount의 Double-Entry Counting Method, “Accounting for Computer Scientists” 등을 포함함
• 입문 자료는 시작점별로 나뉘어 있음
  • What is Plain Text Accounting?
  • Getting Started With Ledger
  • hledger: Get Started
  • Getting Started with Beancount
  • PTA Cookbook: Getting started
• 치트시트, 쿡북, FAQ, 슬라이드, 영상 자료도 별도 섹션으로 정리되어 있으며, 영상 섹션에는 YouTube에서 PTA 영상을 찾기 어렵다는 메모가 있음

주요 PTA 앱과 기능 비교

• PTA를 시작할 때는 사이트에 나열된 앱 중 하나 이상을 시도할 수 있고, 일반적으로 앱 사이의 데이터 마이그레이션이 가능함
• 현재 주요 앱 목록에는 여러 프로젝트가 함께 정리되어 있음
  • Ledger: C++, 2003년 시작, 2025년 마지막 릴리스, 약 245명 커미터, 약 5.9k stars
  • Beancount: Python, 2008년 시작, 2026년 마지막 릴리스, 약 103명 커미터, 약 5.5k stars
  • hledger: Haskell, 2007년 시작, 2026년 마지막 릴리스, 약 194명 커미터, 약 4.4k stars
  • Transity, Ledger(Go), Abandon, zhang, Tackler, rustledger, knut, acc, ledg 등도 현재 목록에 포함됨
• 과거 또는 비활성 프로젝트는 placc, budget-cli, mynt, awk-pta, pta, blossom, .Net Ledger, monescript, Penny, UMM, cl-ledger 등으로 따로 정리됨
• Ledger, hledger, Beancount의 기능 매트릭스는 2024-09 기준으로 갱신되었고, 사용자 인터페이스·설치·도움말·입출력 형식·명령·설정·확장성·계정명·예산·차트·가격 조회·쿼리·검증 등을 비교함
• 대표 차이는 도구 선택 시 바로 영향을 주는 항목에 집중되어 있음
  • CLI는 Ledger의 ledger, hledger의 hledger, Beancount의 beanquery가 연결됨
  • 쉬운 설치와 설정은 Ledger/hledger는 yes, Beancount는 no로 표시됨
  • hledger는 text/html/csv/tsv/fods/beancount/sql/json 출력 형식을 제공함
  • Beancount의 검증은 항상 엄격한 것으로 표시되고, Ledger와 hledger는 설정 가능으로 표시됨

소프트웨어 생태계

• AI 섹션에는 hledger를 사용하는 로컬 우선 멀티모델 AI 에이전트 accountant24, hledger와 Obsidian vault에서 Claude Code를 에이전트 계층으로 쓰는 설정 글이 포함됨
• 대체 배포·설정으로 Full-fledged hledger, hledger-flow, Lazy Beancount, hledger-youtube-business, rtrLEDGER, docker-finance가 정리됨
• 데이터 변환·가져오기는 큰 비중을 차지하며, Ledger와 hledger의 내장 CSV 변환 외에도 Beancount v2의 import 도구, banks2ledger, beancount-import, beancount2ledger, hledger2beancount, ledger2beancount, plaid2text 등이 나열됨
  • GnuCash, Intuit/QuickBooks/QIF, KMyMoney, YNAB에서 *ledger 또는 Beancount로 옮기는 도구도 별도 하위 섹션으로 정리됨
• 데이터 생성 도구는 가격 트랜잭션, 감가상각, 이자, 반복 거래, 자본 손익 postings 등을 만드는 작업에 쓰임
• 편집기 플러그인은 Emacs, JetBrains IDE, Nano, Sublime, TextMate, Vim, VS Code용으로 나뉨
  • 예: ledger-mode, beancount-mode, hledger-mode, vim-ledger, vim-beancount, hledger-vscode, vscode-beancount
• 포맷팅 도구로 beancount-black, beancount-black web app, hledger-fmt가 나열됨
• 송장 도구로는 hledger timedot 파일에서 송장을 생성하는 Go 도구 kairos가 소개됨

UI, 리포팅, 워크플로, 라이브러리

• 가격 조회 도구에는 Beancount의 bean-price, hledger-stockquotes, ledger-get-prices, pricehist, Yahoo Finance 기반 주가·환율 조회 도구 등이 포함됨
• 리포팅 도구는 예산, 자산 분석, 차이 리포트, 내부수익률, 차트, Sankey, PDF 출력, 자본이득 계산 등으로 확장됨
• 시간 기록 도구는 org, Taskwarrior hook, Toggl CSV, timeclock 변환 및 hledger 기반 시간 기록 예제를 포함함
• 터미널 UI는 hledger add, hledger-ui, hledger-iadd, bean-add, ledger xact, puffin, regdel 등으로 거래 입력·조회·편집을 지원함
• GUI, 웹, 모바일 UI도 별도 도구로 연결됨
  • 웹: fava, hledger-web, Paisa, BeanHub
  • 모바일: Beancount Mobile CE, beancount-mobile, NanoLedger, cashier, cone, MoLe
  • GUI: fruit-credits, Ledgera, Prudent, Surebeans 등
• 워크플로 섹션은 CSV에서 hledger 저널을 생성하거나 Docker 기반으로 전통 금융·암호화폐 재무를 추적·리포팅하는 구성을 다룸
• 라이브러리 섹션은 Beancount 파서, BeanHub API, hledger-lib, hledger-web JSON API, node-hledger, pyhledger 등 PTA 파일을 파싱·조회·리포팅·연동하는 개발용 구성요소를 모음

[GN⁺]

Hacker News 의견들

• 즉시 엄격한 분류를 요구하는 시스템은 어떤 사람들에게 맞지 않음. 예전에 일하던 회사에서는 먼저 iPhone Notes에 -50 Alice tools, +20 Bob returned loan처럼 짧게 적고, 나중에 스크립트가 날짜·키워드·상대방·내부 분석 항목을 파싱해 복식부기 템플릿으로 바꾸는 2단계 방식을 썼음
  스크립트가 못 알아낸 항목은 수동 분류하고 필요하면 규칙 목록에 추가했으며, Alice와 Bob이 같은 어휘를 맞출 필요가 없도록 사람별 대응 목록을 뒀음
  돈이 오갈 때마다 줄 서 있거나 운전 중이거나 대화 중인 사람이 Cat1:cat2:cat3 같은 형식을 매번 채우리라고는 상상하기 어려움. 결국 다시 짧은 메모나 채팅으로 돌아가거나, 하루 끝이 아니라 아마 주말에 “기억해서” 채우려 할 가능성이 큼

  • 그 방식도 결국 일반 텍스트 회계처럼 들림. 원장 파일에 직접 입력하지 않고 KMyMoney에 넣은 뒤 스크립트로 ledger 파일로 변환하는 식으로 나도 거의 비슷하게 씀
    텍스트 기반 도구라면 iPhone 메모를 받아 ledger 형식으로 바꾸는 스크립트를 붙이는 등 원하는 흐름을 자유롭게 만들 수 있으니, 불만으로 보기에는 좀 이상하게 느껴짐
  • 우리도 ledger 파일을 직접 치지는 않고, 자유 형식 메모를 변환하기보다는 은행 앱과 Zoho 비용 보고 앱의 메모 필드에 적용할 계정을 적어둠
    분기마다 은행 계좌, 신용카드, Zoho에서 CSV를 내려받고 Ruby 스크립트가 메모 필드를 보고 ledger 파일로 변환함. 스크립트와 결과물은 조금씩 손봐야 하지만 95% 이상 자동화됨
    덤으로 은행에서 받은 잔액과 맞는지, 항목이 현재 기간 안에 있는지 같은 정합성 검사도 ledger 파일에 추가함

• 자영업을 시작한 순간부터 거의 20년 동안 ledger-cli를 써왔고, 완벽하진 않아도 매우 만족함. 모든 것이 일반 텍스트라 스크립트로 처리하고, VIM에서 읽고, 데이터를 쉽게 뽑을 수 있음
  현재 운영 중인 회사 중 하나의 ledger 파일은 2016년 이후 거래를 담은 2MB짜리 일반 텍스트임. 계정/분류를 아주 세분화하는 데서는 큰 가치를 못 느꼈지만, 전체 추적에는 없어서는 안 될 도구였음
  ledger 같은 도구가 쓰는 복식부기를 배우는 것도 재미있었고, 돌이켜보면 어렵지 않았으며 평생 유용할 기술처럼 느껴짐

  • 아직 이런 도구를 쓰지는 않지만, QuickBooks와 은행이 거래 몇 개를 놓쳐서 정리하는 중이라 이 글이 딱 맞는 시점에 보였음
    계정/분류 전략으로는 캐나다 국세청이 세금 신고서에서 요구하는 비용 분류와 맞추는 방식을 씀. 처음엔 호스팅 비용, 시제품/제조 비용처럼 논리적 분류를 만들었지만, 몇 년 동안 CRA 분류로 다시 매핑하다 보니 애초에 세금 분류에 맞춰두는 편이 연말 신고를 훨씬 단순하게 만든다는 걸 깨달음
  • 집을 팔 때 에스크로 회사가 마감 정산으로 약 3,000달러 환급 수표를 보냈는데, 그 수표를 받은 적이 없었음. 5년 뒤 ledger-cli를 쓰기 시작하고서야 그 사실을 알게 됨
  • ledger에 한 표. 지금까지 써본 것 중 최고였고, 스크립트화 가능하다는 점이 엄청남. 쓰기 시작한 뒤 2년 넘게 세금 처리가 정확해짐
  • 더 생각해보면 가장 큰 아쉬움은 일반 텍스트 전반의 한계인 첨부파일 부재임. 특정 파일을 참조하는 개인 시스템을 만들고, 거래에 파일을 드롭하면 지정 폴더로 복사하고 거래에 태그를 붙이는 Mac 앱도 만들었음
    데이터가 SQLite였다면 훨씬 쉽게 구현됐겠지만, 그러면 텍스트 편집기로 직접 수정하는 장점은 잃게 됨

• LLM 덕분에 일반 텍스트 회계를 꾸준히 하기 훨씬 쉬워졌음. 특히 은행 명세서를 hledger로 가져오면서 수동 입력을 피하는 데 도움이 됨
  은행 거래를 hledger 계정에 매핑하는 JSON 파일을 쓰고, 새 매핑이 없는 거래가 있으면 Python 스크립트가 Claude용 프롬프트를 생성함. Claude는 계정 목록을 보고 새 거래의 매핑을 제안하고, 그 기반으로 hledger 분개를 반환함
  이후 다른 스크립트가 그달 은행 거래의 hledger 분개를 깔끔하게 출력하고, 몇 분만 손봐서 확정함. 예전 같으면 취약한 정규식과 조건문 더미가 됐을 매핑 지침도 자연어로 적을 수 있음

  • LLM이 취약하지 않다고 보는 건가? 그리고 은행 정보를 Anthropic에 보내는 것도 꽤 대담함

• Beancount를 쓰면서 배우는 과정, 데이터 가져오기 도구 작성, 회계를 직접 만지는 경험을 즐겼음. 하지만 마지막으로 데이터를 가져온 지 거의 1년이 됐고, 매달 하려 했지만 자동화가 꽤 되어 있어도 30~60분이 걸려 번거로움

  • 은행들이 데이터 내보내기를 적극적으로 방해하지 않았으면 좋겠음. 예전에 로그인 과정을 OCR로 역공학하고 잘못된 항목을 정리하는 스크립트를 만들었지만, 유지보수 비용이 너무 컸음
    모바일 확인까지 필요해지자 그냥 포기함
  • GnuCash에서도 정확히 같은 경험을 함. 매주 할 때는 괜찮지만 1~3주 놓치는 건 버틸 만해도 그 이상 지나면 따라잡는 부담이 눈덩이처럼 커짐
    나도 가져오기를 안 한 지 1년쯤 됐고, 다시 살리려면 며칠에 걸쳐 한 달치씩 올리는 식으로 잘게 나누는 방법밖에 떠오르지 않음
  • 약간 찝찝함을 감수할 수 있다면 Plaid를 볼 만함. 개인 용도에는 충분한 테스트 티어가 있었고, 연결 계정 100개까지 가능했음
    https://plaid.com/
  • teller.io를 쓰면 Plaid보다 설정이 훨씬 쉬운 편임. Chase 은행과 신용카드 명세서를 Google Sheets로 동기화하는 데 쓰고 있음

• 개인과 여러 LLC의 부기·회계에 ledger를 씀. 터미널에 익숙하고 CLI를 잘 다루며 vim이나 emacs, sed/awk 기본기, bash/python/perl/ruby 스크립팅을 자주 한다면 ledger와 복식부기를 배워서 전환하는 편이 지금 쓰는 방식보다 훨씬 만족스러울 가능성이 큼
  거래를 빠르게 가져오는 데는 reckon이 유용함: https://github.com/cantino/reckon
  include로 문제를 쪼개는 것도 좋음. bal --dc는 미국 회계사에게 조금 익숙할 수 있지만, ledger가 음수를 쓰는 방식을 제대로 이해하지 못하는 경우가 많아서 차라리 DR/CR 스타일로 변환하는 스크립트를 몇 개 짜는 편이 쉬웠음. 상대했던 회계사들이 추상화를 얼마나 못 다루는지 보고 놀랐음

  • 앞의 두 팁에는 동의함. 세 번째도 좋을 것 같지만 필요했던 적은 없음
    팁을 하나만 보태자면 Makefile이나 비슷한 것으로 전부 묶어두라는 것임. 계정별로 거래 파일이 많이 나뉘어 있고, 올바른 파일을 포함시키는 명령이 길어지기 쉬움
    각종 그래프와 요약 스크립트도 정확한 문법을 매번 기억하지 못하는데, make를 쓰면 make cashflow, make balance 'A=Checking', make balance-plot 'A=retirement'처럼 호출할 수 있음

• Ledger를 기본 튜토리얼을 넘어 더 복잡한 상황에서 효과적으로 쓰는 실전 레시피 글을 여러 편 썼음: https://felixcrux.com/blog/ledger-practices

  • ledger를 많이 쓰는 입장에서 저 레시피들은 훌륭함. 고객과 공급업체를 세밀하게 추적하고, 지급·수취를 특정 프로젝트와 그 안의 분류에 배정해야 하는 패턴을 쓰고 있음
    은행 거래를 가져올 때 상대방 이름의 계정에 먼저 배정하고, 스크립트가 ledger print로 상대방별 두 번째 저널 파일을 만들어 원거래를 반전시킨 뒤 Unknown 프로젝트와 Unknown 분류 하위 계정에 임시로 넣음
    이후 장부 담당자가 거래를 특정 송장에 맞추고 Project:Category 계정으로 배정하며, 필요하면 단일 결제를 여러 프로젝트/분류로 쪼갬. 모든 은행 거래 저널과 상대방 저널을 포함하면 ledger bal로 부기 처리가 끝났는지 확인할 수 있음

• 일반 텍스트 회계는 멋지지만, 많은 사람에게 가장 큰 장벽은 은행 데이터를 표준 형식으로 내려받는 일이라고 봄
  은행들은 CSV나 Excel 이상을 적극적으로 지원하지 않을 것이고, Yodlee나 Plaid 같은 데이터 집계 플랫폼은 오픈소스나 취미 사용자에게 친화적이지 않음
  예전에 Wesabe(https://en.wikipedia.org/wiki/Wesabe)라는 회사가 데스크톱에서 은행 동기화를 하는 소프트웨어를 만들었음. Mint.com 때문에 사실상 밀려났지만, 그 접근은 아직도 생각나며 오픈소스에서도 가능해 보임

  • hledger에는 꽤 임의적인 CSV를 거래로 변환하는 도구가 있음: https://hledger.org/1.40/hledger.html#csv
    아직 써보진 않았지만, SaaS 부기 회사의 은행 연결 문제를 며칠에 걸쳐 4시간이나 도와준 뒤라면 기꺼이 시간을 들여볼 생각임
    거래를 대조할 때마다 내부를 볼 수도 직접 고칠 수도 없는 시스템과 싸우게 됨. 이제는 들인 노력만큼 가치가 있는지 의심스러워졌고, 쓸 만한 도구만 있다면 CSV를 직접 다루는 편이 낫겠음. 참고로 그 회사는 “일반적인 일”이라며 환불도 해주지 않았음
  • 최근 Paisa를 발견했는데, 기본적으로 ledger-cli 위에 얹힌 괜찮은 UI임. 가져오기가 아주 편해서 CSV 같은 파일을 올리고 미리보기를 본 뒤, 각 행을 ledger 텍스트 형식으로 바꾸는 스크립트를 작성하면 됨
    린트도 있고 결과가 마음에 들면 스크립트를 저장해 언제든 다시 가져올 수 있음. 주식 같은 것을 추적할 때 상품 가격 다운로드도 지원함
    차트는 내 취향에는 충분히 범용적이지 않아 데이터를 다른 곳으로 내보내지만, 데이터 입력용으로는 훌륭함
  • 은행이 법적으로 제공해야 하는 PDF 명세서와 CSV가 맞지 않는 경우를 겪었음. 게다가 CSV에는 잔액 데이터가 거의 없음
    그래서 PDF를 내려받아 데이터를 추출하는데, 필요 이상으로 고통스러움. 기계가 읽기 쉬운 PDF를 제공하려면 거래 필드 3~4개와 날짜·잔액 같은 명세서 필드 몇 개를 취약한 휴리스틱 없이 뽑을 수 있게 간단한 규칙만 따르면 됨
    브랜드가 들어가고 사람이 읽기 좋은 PDF와 기계가 읽기 좋은 PDF는 충돌하지 않음
  • 영국에는 은행 데이터 접근을 위한 표준 API인 Open Banking이 있음: https://www.openbanking.org.uk/
  • 우리나라에서는 모든 거래가 SMS로 오기 때문에 Tasker로 SMS를 잡아 CSV 파일에 저장하는 시스템을 만들었음. 그 CSV는 SyncThing으로 데스크톱에 동기화되는 폴더에 넣었음
    그 데이터를 처리해 회계 시스템에 넣을 계획이었지만 실행하지 못했고, 이후 휴대폰이 망가지면서 Tasker 액션도 잃어버림. 다시 구현할 의욕이 안 남

• 관련 도메인이 그대로 있음. 2023년 글: https://news.ycombinator.com/item?id=36022005, 2021년 글: https://news.ycombinator.com/item?id=28420797, 2016년 글: https://news.ycombinator.com/item?id=11164330
  개념에 대한 다른 언급은 https://hn.algolia.com/?q=Plain+Text+Accounting에서 더 볼 수 있음

• 다른 사람들이 일반 텍스트 회계 도구를 실제로 어떻게 쓰는지 궁금함. 지출 습관을 파악하고 행동을 바꾸는 데 쓰는지, 비용·수익·순자산 추적용인지, 아니면 질서 있는 과정 자체가 매력인 건지 알고 싶음
  이 주제를 볼 때마다 완전히 몰입하고 싶은 충동과, 예전 시도를 꾸준히 못 한 죄책감이 동시에 듦. 지금은 개인 원장을 한 달 반째 업데이트하지 않아 죄책감 쪽이 더 큼
  결국 내가 왜 이걸 쓰는지 확신이 없어서, 시간이 지나면 거래를 기록하기 위해 기록하는 느낌이 됨

  • 나는 즉흥적인 그룹 정산에 항상 씀. 세 명이 여행하는 식의 상황에서는 그날이나 그 주 후반에 비용을 나누는 편이 훨씬 쉽고, 채무 관계를 쌓아뒀다가 필요할 때 정리하면 됨. 이런 혼란스러운 지출은 다른 방식으로 추적하기 매우 어려움
    업무 비용도 비슷함. 장비나 서비스 비용을 내 카드로 결제하고 나중에 보고해 현금이나 이체로 돌려받음. 다만 일부 국가나 사업체에서는 통하지 않음
    개인적인 일상 지출은 은행과 경험으로 이미 알 수 있어 회계까지 할 필요는 없음. 감정적 동기가 아니라 금전적 동기가 있어야 함. 회계를 포기하면 친구가 수백 달러를 술값으로 날리거나 회사가 HDMI 케이블 하나를 공짜로 가져가게 된다고 알면, 망설임 없이 금액을 입력하게 됨. 개인 회계가 잘 안 되는 이유는 잃는 것이 돈이 아니라 분석뿐이기 때문임
  • 자영업자라 Beancount를 사업 계정과 주식 포트폴리오에 씀. 더 엄격한 접근이 마음에 들고, 웹 UI인 Fava는 보고서와 시각화에 편리함
    Wise 거래 가져오기나 환율 추적 같은 과정을 자동화하는 스크립트도 몇 개 있음. 하지만 매일의 개인 지출이나 예산 관리에 쓸 만큼의 규율은 없음
  • 지출 습관을 바꾸는 동기부여 도구로 쓰지는 않지만, 모든 계정과 자산 기록을 유지하는 건 좋아함. 전체 재정 상태를 더 잘 이해하게 해주고, 현금성 저축 계정 안에 가상 계정을 만들어 자동차 정비나 보험처럼 상각해두는 항목별로 잔액을 나눠둠
  • hledger로 여러 용도에 씀. 고객 미수금, 식비·외식·책·잡지 구독 같은 지출 분류, 여러 통화 계좌의 현재 잔액, 다른 사람에게 빌려준 돈과 선물, 여행·선물·투자 목표 같은 저축용 가상 봉투를 추적함
    매일 외식에 얼마나 낭비했는지 확인하고, 그 금액을 인덱스펀드에 넣었을 때의 복리 결과를 계산해보면서 외식 습관을 줄이는 데 큰 도움이 됨. 고객 미수금과 실제 현금흐름·예상 수입 기준 현금흐름도 구분해 볼 수 있음
    저축 계좌 잔액을 “투자 목표 40%, 선물 1%”처럼 마음속에서 쪼개 보니 큰 잔액을 보고 충동적으로 써버리는 일이 줄었음. 자산 증가, 분류별 지출 증가·감소를 차트로 만들고, 그 변화가 삶에 순효과였는지 메모해 웹페이지로 덤프하는 프로그램도 있으며 매년 다음 계획을 정할 때 씀
    ledger 파일을 Excel로 변환해 회계사에게 연간 세금 신고용으로 보내는 Python 스크립트도 있음. 사업용 ledger 파일은 따로 두고, 직접 수동 관리하지는 않으며 회계사 소프트웨어에서 데이터를 내보내 집에서 자체 계산함
    사업에서는 매출 증가에 따라 지출이 어떻게 늘지 예측하는 현금흐름 전망, 부서별 지출 이상치 탐지, 채용을 늘릴지 마케팅 지출을 늘릴지, ROIC 같은 지표 계산에 씀
    복식부기는 은행 명세서를 가져와 ledger를 생성한 뒤 회계상 불일치를 잡는 데 도움이 됨. 재량 지출, 직원 복지, 사업 투입비처럼 용도별 계정을 나누고 주 계정에서 매주 입금되게 해서 이상 여부를 확인함
    예전에 회계사가 투명하게 말하지 않고 가짜 비용을 장부에 올려 세금을 많이 아낀 것처럼 보이게 했다가 법정에 가고 큰 벌금과 지연 가산금을 낸 적이 있음. 이제 회계사를 믿지 않고 반드시 재확인함
    Stripe, 은행 명세서, 회계사 장부 등을 가져오는 자동화 스크립트가 많고, Python으로 서로 맞춰보며 불일치를 찾음. 프로그래머인 내게 일반 텍스트 회계는 잘 맞고, hledger 위에 수년간 나만의 시스템을 쌓았음