Beancount FAQ: 일반 텍스트 회계 질문

학위가 아니라 대략 다섯 가지 개념이면 됩니다. 다섯 가지 계정 유형(자산, 부채, 자본, 수익, 비용), 모든 거래가 이들 중 최소 두 개 사이에서 가치를 이동시킨다는 개념, 그리고 거래는 반드시 균형을 이루어야 한다는 규칙을 알아야 합니다. 나머지는 Beancount가 알아서 처리합니다 — 숫자가 맞지 않는 거래는 조용히 받아들이지 않고 오류로 표시하므로, 초보자가 놓칠 수 있는 실수를 소프트웨어가 잡아줍니다.

Beancount 소개로 시작하고, 용어집을 탭에 열어 두고, 빠른 시작에서 첫 거래를 추가해 보세요.

Beancount는 "차변"과 "대변"이라는 단어를 전혀 사용하지 않습니다 — 대신 합이 0이 되어야 하는 부호 있는 숫자를 사용합니다. 계정에서 나가는 돈은 음수, 들어오는 돈은 양수이며, 전기가 서로 상쇄될 때 거래가 유효합니다. 이는 회계사들이 하는 것과 동일한 복식부기이며, 초보자를 혼란스럽게 하는 용어만 제거한 것입니다.

전통적인 회계 소프트웨어를 사용해 본 적이 있다면, 변환은 이렇습니다: 차변은 양수, 대변은 음수입니다. 전기가 어떻게 작성되는지는 언어 문법 참고 자료를 보거나, 회계 배경을 쉬운 영어로 설명한 차변과 대변 설명을 참고하세요.

돈은 항상 어딘가에서 오기 때문이며, 제로섬이 바로 그 사실을 오류 검사로 바꿔주는 것입니다. 식료품에 $40을 썼다면 그 돈은 은행 계좌에서 나간 것입니다 — 양쪽을 모두 기록하면 둘이 상쇄되어야 하며, 어느 한쪽 금액의 오타라도 조용히 잘못된 잔액을 만드는 대신 오류로 표시됩니다.

이것이 플레인 텍스트 원장이 지출 스프레드시트보다 더 신뢰할 수 있는 이유입니다: 구조 자체가 자기 검증을 합니다. 잔액 검증(balance assertion)은 원장을 실제와 대조하는 관련 메커니즘입니다.

시작 날짜에 각 계정의 현재 잔액을 Equity:Opening-Balances에서 이동시키는 거래를 기록한 다음, balance 검증을 추가하여 고정하세요. 재무 이력을 재구성할 필요는 없습니다 — 시작 날짜를 정하고, 그날의 잔액을 그대로 가져와서, 거기서부터 앞으로 나아가면 됩니다.

빠른 시작에서 완전한 기초 잔액 예시를 다룹니다.

거칠게 시작하고, 더 세분화된 구분이 의사결정을 바꿀 때만 나누세요. 처음에는 20개 정도의 계정이면 충분합니다. "Expenses:Food"를 식료품과 외식으로 분리해야 할지 고민된다면, 유용한 기준은 그 구분을 알고 나서 실제로 다르게 행동할 것인지입니다.

나중에 이름을 바꾸고 분리하는 것은 텍스트 파일에서 찾아 바꾸기이므로, 단순하게 시작하는 비용은 낮습니다. 계정 이름은 중첩되므로, 넓은 범주로 시작해서 나중에 이력을 다시 쓰지 않고도 하위 계정으로 분리할 수 있습니다 — 복사할 구조를 원한다면 계정과목표 설계 방법을 참고하세요.

스프레드시트는 틀렸을 때 알려주지 못합니다. 플레인 텍스트 회계는 복식부기를 강제하므로 모든 거래가 자기 검증을 하고, 파일은 텍스트 파일이 존재하는 한 grep하고, diff하고, 스크립팅할 수 있습니다. 또한 실제 버전 이력도 얻습니다: 원장에 git log를 실행하면 무엇이, 언제, 왜 바뀌었는지 정확히 보여줍니다.

실질적인 차이는 여러 계정, 통화, 투자가 있을 때 드러나는데, 단식부기 스프레드시트는 이럴 때 조용히 진실에서 벗어납니다. 투명하고 감사 가능한 회계를 참고하세요.

커피에 얼마를 썼는지만 알고 싶다면, 네 — 스프레드시트로 충분합니다. 복식부기는 여러 계정, 주택담보대출, 증권 계좌, 또는 둘 이상의 통화가 있는 순간부터 제값을 합니다. 왜냐하면 바로 그런 상황에서 단식부기 추적이 알리지 않고 돈을 잃기 때문입니다.

유용한 사고 방식은 이렇습니다: 복식부기는 재정을 위한 체크섬입니다. 더 긴 논거는 소개를 참고하세요.

아니요. Fava는 같은 텍스트 파일 위에 동작하는 완전한 웹 인터페이스입니다 — 재무상태표, 손익계산서, 차트, 거래 입력 — 그리고 Beancount.io는 클라우드에 원장을 두고 이를 대신 실행해 줍니다. 텍스트 파일은 진실의 원천으로 남으므로, 일상적으로 웹 UI를 쓰다가 원할 때만 터미널로 내려갈 수 있습니다. 터미널을 선호한다면 bea 명령줄이 같은 파일을 생성, 검사, 보고합니다 — CLI 빠른 시작을 참고하세요.

인터페이스가 무엇을 할 수 있는지는 UI 기능을 보거나, 라이브 데모를 사용해 보세요.

대부분의 사람들은 거래의 80~95%를 가져오고 나머지는 직접 입력합니다. 대략 신뢰성 순으로: 은행에서 직접 OFX/QFX 다운로드, CSV 내보내기와 가져오기 규칙, 애그리게이터 연결, 그리고 — 최후의 수단으로만 — PDF 명세서를 CSV로 변환. Beancount.io의 은행 동기화가 연결과 분류를 대신 처리해 줍니다.

기관마다 규칙을 하나씩 작성하거나 조정할 것으로 예상하세요: 은행 CSV 내보내기는 일관성이 나쁘기로 악명 높고, 이스케이프되지 않은 쉼표가 포함된 가맹점 이름은 실제로 흔한 문제입니다. 자동화 경로는 스마트 가져오기를 참고하세요.

일회성 파일의 경우, 두 개의 무료 브라우저 변환기가 아무것도 업로드하지 않고 기계적인 부분을 처리합니다: 스프레드시트 내보내기용 CSV에서 Beancount로, 그리고 은행이 CSV를 전혀 제공하지 않을 때 제공하는 .ofx, .qfx, .qbo, .qif 다운로드용 OFX & QIF에서 Beancount로.

가져오기 도구는 원장에 이미 있는 항목과 날짜, 금액, 지급인을 기준으로 중복을 제거하고, 추측하는 대신 모호한 것은 확인할 수 있도록 표시합니다. 일반적인 워크플로는 불확실한 가져오기를 보류(pending)로 표시하여 영구 기록의 일부가 되기 전에 검토하도록 합니다.

OFX는 CSV보다 이를 쉽게 만듭니다: 모든 거래에 은행이 다운로드 간에 안정적으로 유지하는 FITID가 있어서, 가져오기 도구가 추론이 아닌 식별자로 매칭할 수 있습니다 — OFX 변환기는 이를 id: 메타데이터 필드로 보존합니다.

답의 나머지 절반은 이체입니다: 본인이 소유한 두 계정 사이를 이동하는 돈은 양쪽 은행 내보내기에 모두 나타납니다. 두 개의 전기가 있는 하나의 거래로 한 번만 기록하세요.

아니요 — 그리고 많은 사람들에게 이것이 바로 플레인 텍스트 회계를 쓰는 이유입니다. 은행에서 직접 OFX나 CSV를 내보낼 수 있고, 애그리게이터에 자격 증명을 넘길 필요가 없습니다. 자동 동기화를 선호한다면, Beancount.io는 온라인 뱅킹 비밀번호를 저장하는 대신 은행이 승인한 애그리게이터를 사용합니다.

자세한 내용은 보안 페이지를 참고하세요.

명세서 마감 수치에 대한 balance 검증을 마감일 다음 날짜로 추가하세요. 잔액 검증은 해당 날짜의 시작 시점에 평가되므로, 다음 날 아침의 검증이 마지막 명세서 날짜까지의 모든 거래를 포함합니다. 원장이 은행과 일치하지 않으면, bea check가 Balance failed 오류를 보고하고 0이 아닌 값으로 종료하여, 대사를 수동 비교에서 소프트웨어가 실행될 때마다 검사하는 것으로 바꿔줍니다.

대부분의 사람에게는 월별 주기로 충분합니다. 불일치를 추적하는 방법은 필터링과 검색을 참고하세요.

기본적으로 지원하며, 이는 소비자 금융 앱 대비 가장 강력한 장점 중 하나입니다. 모든 금액은 통화를 가지며, 계정은 여러 통화를 동시에 보유할 수 있고, 환전은 가격에는 @를, 원가에는 {}를 사용해 명시적으로 기록되므로, 환율 변동이 이력을 조용히 다시 쓰는 일이 없습니다.

아무것도 몰래 환산되지 않습니다 — 항상 원래 통화와 환산된 가치를 모두 볼 수 있습니다. 회계 측면은 언어 문법, 정밀도와 허용 오차, 다중 통화 회계를 참고하세요.

호스팅되는 Beancount.io 원장의 지원 자산에는 실시간 가격을 사용하거나, 로컬 가격 파일에 시세를 가져와 업스트림 Beancount와 Fava에서 사용하세요. 선택기를 통해 견적 통화를 고르고 관리형 include를 복사할 수 있습니다. 호환되는 bea 버전도 관리형 include를 지원합니다; 설정 가이드에 해당 지침 링크가 있습니다.

관리형 가격은 시장 평가에 영향을 미치며, 거래 금액이나 취득원가에는 영향을 미치지 않습니다. 같은 날짜와 통화쌍에 대해서는 본인의 가격이 우선합니다. 장애 중에는 갱신이 오래된 캐시 가격을 사용할 수 있으며, 이후 시세는 누락된 과거 평가 날짜를 채울 수 없습니다.

매수를 중괄호로 원가와 함께 기록하세요 — 10 AAPL {150.00 USD} — 그러면 Beancount가 각 로트(lot)를 개별적으로 추적합니다. 매도할 때 어떤 로트를 줄이는지 명시하면, 자본 이득이 손으로 계산할 대상이 아니라 산술에서 자동으로 도출됩니다.

Beancount는 STRICT, FIFO, LIFO, NONE 부킹 방식을 지원합니다. 평균원가 부킹은 파싱되지만 완전히 구현되지는 않았습니다 — 세법 관할 지역에서 평균원가를 요구한다면 플러그인이나 명시적 로트로 추적할 계획을 세우세요. 재고 관리를 참고하세요.

다른 어떤 상품과도 똑같이: 암호화폐는 원가를 가진 단위이므로, 동일한 로트와 부킹 메커니즘이 적용됩니다. 한 토큰을 다른 토큰으로 교환하는 것은 한 로트를 줄이고 다른 로트를 여는 하나의 거래이며, 이는 대부분의 세무 당국이 보고받기를 원하는 실현 이득을 얻는 방법이기도 합니다.

암호화폐 포트폴리오 추적과 바로 사용할 수 있는 암호화폐 템플릿을 참고하세요.

사업체도 사용하며, 수십만 건의 거래가 있는 회사도 포함됩니다. 발생주의 회계, 다중 법인 구조, 회계사가 기대하는 보고서를 처리합니다. 솔직한 한계는 다중 사용자 동시 편집이 없고, 내장 인보이싱 UI가 없으며, 미지급금 승인 워크플로가 없다는 것입니다 — ERP가 아니라 원장입니다.

산업별 설정과 실제 기업 장부를 보여주는 오픈 원장 쇼케이스를 참고하세요.

분리하세요 — 하나의 파일에 서로 다른 최상위 계정 트리로 두거나, include로 결합된 두 개의 파일로 두세요. 섞으면 사업의 손익계산서가 무의미해지고 세금 신고 시기가 더 어려워지며, 분리하는 데 드는 초기 비용은 없습니다.

사업체가 자체 은행 계좌를 가지고 있다면 보통 두 개의 파일이 더 깔끔한 선택입니다. 다중 파일 지원을 참고하세요.

매출채권은 자산 계정으로, 매입채무는 부채로 모델링한 다음, 인보이스를 발행할 때와 대금이 들어올 때 각각 기록하세요 — 이것이 발생주의 회계이며, Beancount가 직접 지원합니다. 없는 것은 인보이싱 인터페이스입니다: 받을 돈을 추적할 뿐, 인보이스를 생성하거나 발송하지는 않습니다.

보고서 측면은 재무 보고 템플릿, 구체적 예시는 산업별 설정, 개념은 매출채권 이해를 참고하세요.

원장이 아니라 보고서를 내보내세요. 회계사는 거의 확실히 텍스트 파일을 원하지 않습니다 — 손익계산서, 재무상태표, 거래 목록을 원하며, 이는 웹 인터페이스나 쿼리로 CSV나 PDF로 생성할 수 있습니다.

세금 준비 가이드, 재무 보고 템플릿, 그리고 요청하는 정확한 숫자를 뽑아내는 SQL로 쿼리하기를 참고하세요.

세 가지 모두 비슷한 파일 형식을 가진 플레인 텍스트 복식부기 시스템입니다. Ledger는 원조이며 가장 관대한 파서입니다; hledger는 친절한 CSV 가져오기 규칙과 문서로 알려진 Haskell 재구현입니다; Beancount는 가장 엄격한 파서와 투자, 로트, 다중 통화에 대한 가장 강력한 지원, 그리고 Python 플러그인 API를 갖추고 있습니다.

엄격함이 진짜 트레이드오프입니다: Beancount는 모호하다고 판단한 파일은 로드를 거부하여, 더 까다로운 대신 오류를 일찍 잡아냅니다. Beancount vs Ledger CLI와 Beancount vs hledger를 참고하세요.

기본적으로는 아닙니다 — 이는 숨겨진 기능이 아니라 실제 격차입니다. Beancount의 내장 예산 기능은 제한적이며, 엄격한 봉투 동작을 원하는 사람들은 보통 커뮤니티 플러그인을 사용하거나 봉투를 계정으로 모델링합니다.

봉투 예산이 주된 목적이라면, 전환하기 전에 Beancount vs YNAB를 읽어보세요. 오늘 실제로 작동하는 것은 Beancount에서의 예산을 참고하세요.

네. document 지시문은 파일을 계정과 날짜에 연결하며, 웹 인터페이스에서 해당 문서를 소속 거래와 함께 업로드하고 탐색할 수 있습니다. 영수증은 디스크상의 일반 파일로 남으므로 원장 자체만큼 이식성이 있습니다.

UI 기능을 참고하세요.

네 — Beancount.io는 원장을 보고 이동 중에 거래를 기록할 수 있는 iOS와 Android 앱을 제공하며, 이는 대부분의 플레인 텍스트 환경이 열어둔 격차입니다.

앱 없이 빠르게 기록하려면, 많은 사람들이 대략적인 메모를 남기고 나중에 원장에 대사합니다.

10년치 개인 재정은 몇 메가바이트이며 1초 훨씬 안에 로드됩니다. Beancount는 로드할 때마다 전체 거래 이력에서 잔액을 재계산하며, 이는 수십만 건의 항목까지도 빠르게 유지됩니다. 그 이상에서는 한계가 로드 시간이 아니라 편집과 diff의 편안함입니다: include로 연도별로 나누면 개별 파일이 작게 유지되지만, 포함된 파일들은 여전히 하나의 결합된 원장을 이루어 Beancount가 전체를 로드하고 재계산하므로, 이는 속도 향상이나 별도 장부를 유지하는 방법이 아니라 파일 구성상의 편의일 뿐입니다.

커지는 원장을 나누는 방법은 다중 파일 지원을 참고하세요.