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

학위가 아니라 약 5가지 개념만 알면 됩니다. 다섯 가지 계정 유형(자산, 부채, 자본, 수익, 비용), 모든 거래가 최소 두 개의 계정 간에 가치를 이동시킨다는 개념, 그리고 거래의 균형이 맞아야 한다는 규칙이 필요합니다. Beancount는 나머지를 강제합니다. 숫자가 맞지 않는 거래는 조용히 수락하는 대신 오류로 표시하므로, 소프트웨어가 초보자가 놓치기 쉬운 실수를 잡아줍니다.

Beancount 소개로 시작하고, 용어집을 옆에 두고, 빠른 시작에서 첫 거래를 입력해 보세요.

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

전통적인 회계 소프트웨어를 사용해 본 적이 있다면, 차변은 양수, 대변은 음수라고 생각하면 됩니다. 포스팅 작성 방법은 언어 구문 참조, 또는 차변 및 대변 설명에서 회계 배경 지식을 확인하세요.

돈은 항상 어딘가에서 오고 어딘가로 가기 때문입니다. 0이 되는 균형은 이 사실을 오류 검사로 바꿔줍니다. 식료품점에서 40달러를 쓰면 그 돈은 은행 계좌에서 나갑니다. 양쪽을 모두 기록하면 두 금액이 상쇄되어야 하며, 어느 쪽에든 오타가 있으면 조용히 잘못된 잔액을 만드는 대신 오류로 표시됩니다.

이것이 일반 텍스트 장부가 비용 스프레드시트보다 더 신뢰할 수 있는 이유입니다. 구조 자체가 스스로 검사하기 때문입니다. 잔액 검증은 장부를 실제 은행 잔액과 대조하는 관련 메커니즘입니다.

시작일에 각 계정의 현재 잔액을 Equity:Opening-Balances에서 이체하는 거래를 기록하고, balance 검증을 추가하여 잠급니다. 과거 재무 기록을 재구성할 필요는 없습니다. 시작일을 정하고, 그날의 잔액을 그대로 가져온 후そこ부터 진행하면 됩니다.

빠른 시작에서 완전한 개시 잔액 예제를 안내합니다.

처음에는 크게 시작하고, 더 세분화된 구분이 의사 결정을 바꿀 때만 나누는 것이 좋습니다. 계정 20개 정도면 충분합니다. "Expenses:Food"를 "식료품"과 "외식"으로 나눌지 고민된다면, 그 구분이 실제로 무엇을 다르게 하게 만드는지 생각해 보세요.

나중에 이름을 바꾸거나 나누는 것은 텍스트 파일에서 찾아 바꾸기일 뿐이므로 처음부터 완벽할 필요는 없습니다. 계정 이름은 중첩되므로 넓은 범주에서 시작해 나중에 하위 계정으로 쪼개도 기록을 다시 쓸 필요가 없습니다. 구조 복사에 대한 자세한 내용은 계정 과목표 설계 방법을 참조하세요.

스프레드시트는 잘못된 것을 알려주지 않습니다. 일반 텍스트 회계는 복식 부기를 강제하므로 모든 거래가 스스로 검증됩니다. 또한 파일은 grep, diff, 스크립트로 처리할 수 있으며, git log를 사용하면 실제 버전 기록을 얻을 수 있습니다. 즉, 언제, 무엇이, 왜 변경되었는지 정확히 알 수 있습니다.

이 차이는 계정이 여러 개이거나 통화가 여러 개이거나 투자가 있을 때 실질적으로 드러납니다. 단식 입력 스프레드시트는 조용히 균형을 잃지만, Beancount는 그렇지 않습니다. 투명하고 감사 가능한 회계에서 더 자세히 설명합니다.

커피에 얼마를 썼는지만 알고 싶다면 스프레드시트로 충분합니다. 하지만 계좌가 여러 개이거나, 모기지나 투자 계좌가 있거나, 여러 통화를 다룬다면 복식 부기는 그만한 가치가 있습니다. 단식 입력은 돈이 어디서 오는지 추적하지 않으므로, 대차대조표가 실제 현실과 어긋나기 시작해도 알아차리기 어렵습니다.

유용한 비유: 복식 부기는 재무를 위한 체크섬입니다. 숫자가 맞지 않으면 즉시 알 수 있습니다. 더 긴 설명은 Beancount 소개를 참조하세요.

아니요. Fava는 동일한 텍스트 파일 위에서 작동하는 완전한 웹 인터페이스로, 대차대조표, 손익 계산서, 차트, 거래 입력을 제공합니다. Beancount.io는 클라우드에서 이를 실행하므로 명령줄을 전혀 만질 필요 없이 모든 기능을 사용할 수 있습니다.

텍스트 파일이 진실의 원천이므로 필요할 때 언제든지 명령줄로 내려가서 고급 작업을 할 수 있습니다. UI 기능에서 인터페이스로 무엇을 할 수 있는지, 라이브 데모에서 직접 사용해 보세요.

대부분의 사람들은 거래의 80–95%를 가져오고 나머지는 수동으로 입력합니다. 신뢰성 순으로: 은행의 직접 OFX/QFX 다운로드, CSV 내보내기 및 가져오기 규칙, 은행-승인 집계기입니다. 마지막 수단은 PDF 명세서를 CSV로 변환하는 것입니다. Beancount.io의 은행 동기화는 연결과 분류를 처리합니다.

가져오기 규칙은 일반적으로 기관마다 작성하거나 조정해야 합니다. 은행 CSV 내보내기는 악명 높을 정도로 일관성이 없으며, 쉼표가 포함된 판매처 이름은 실제로 흔한 문제입니다. 자동화된 가져오기에 대한 자세한 내용은 스마트 가져오기를 참조하세요.

일회성 파일의 경우, 업로드 없이 브라우저에서만 작동하는 두 가지 무료 도구가 있습니다: 스프레드시트용 CSV to Beancount와 은행이 내보내는 .ofx, .qfx, .qbo, .qif 파일용 OFX & QIF to Beancount가 있습니다.

가져오기는 이미 장부에 있는 항목과 날짜, 금액, 판매처를 기준으로 중복을 제거하고, 모호한 항목은 추측하지 않고 확인을 요청합니다. 일반적인 워크플로는 확실하지 않은 가져오기를 "보류" 상태로 표시하여 영구 기록이 되기 전에 검토하도록 합니다.

OFX는 CSV보다 이 문제를 더 쉽게 만듭니다. 모든 거래에는 은행이 다운로드 간에 안정적으로 유지하는 FITID가 있어, 가져오기는 추론 대신 신원을 기준으로 일치시킬 수 있습니다. OFX 변환기는 이를 id: 메타데이터 필드로 보존합니다.

해답의 나머지 절반은 이체입니다: 소유한 두 계정 간의 돈 이동은 두 은행의 내보내기에 모두 나타납니다. 두 개의 포스팅이 있는 단일 거래로 한 번만 기록하세요.

아니요 — 그리고 많은 사람들이 바로 이 때문에 일반 텍스트 회계를 사용합니다. 은행에서 OFX나 CSV를 직접 내보내면 집계자에게 자격 증명을 넘겨줄 필요가 없습니다. 자동 동기화를 선호한다면, Beancount.io는 온라인 뱅킹 비밀번호를 저장하는 대신 은행이 승인한 집계자를 사용합니다.

자세한 내용은 보안 페이지에서 확인하세요.

명세서의 마감 잔액에 대해 마감일 다음 날 날짜로 balance 검증을 추가하세요. 잔액 검증은 해당 날짜 시작 시 평가되므로, 다음 날 아침의 검증이 마지막 명세서일까지의 모든 거래를 포함합니다. 장부가 은행과 일치하지 않으면 bean-check가 Balance failed 오류를 보고하고 0이 아닌 종료 코드를 반환합니다. 이렇게 하면 조정이 수동 비교에서 소프트웨어가 실행될 때마다 검사하는 작업으로 바뀝니다.

월 단위 cadence가 대부분의 사람에게 충분합니다. 불일치를 추적하는 방법은 필터링 및 검색을 참조하세요.

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

배후에서 아무것도 변환되지 않습니다. 항상 원래 통화와 변환된 가치를 모두 볼 수 있습니다. 구문은 언어 구문, 정밀도 및 허용 오차는 정밀도 및 허용 오차, 회계 측면은 다중 통화 회계를 참조하세요.

구매를 중괄호 안에 원가와 함께 기록하세요 — 10 AAPL {150.00 USD} — 그러면 Beancount가 각 로트를 별도로 추적합니다. 판매 시 감소시킬 로트를 지정하면 자본 이득은 수동 계산 대신 산술에서 자동으로 도출됩니다.

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가 전체를 로드하고 다시 계산하는 하나의 결합된 장부를 형성하므로 파일 구성의 편의일 뿐 속도 향상이나 별도 장부 유지 방법은 아닙니다.

성장하는 장부를 분할하는 방법은 다중 파일 지원을 참조하세요.