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

약 5가지 개념이면 충분하며, 학위가 필요하지 않습니다. 다섯 가지 계정 유형(자산, 부채, 자본, 수익, 비용), 모든 거래가 이들 중 적어도 두 개 사이에서 가치를 이동시킨다는 개념, 그리고 거래는 균형을 이루어야 한다는 규칙을 알아야 합니다. Beancount는 나머지를 강제합니다. 거래가 합산되지 않는 파일은 로드를 거부하므로, 초보자가 조용히 저지를 수 있는 실수를 소프트웨어가 잡아냅니다.

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

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

전통적인 회계 소프트웨어를 사용해 본 적이 있다면, 차변은 양수, 대변은 음수입니다. 분개 작성 방법은 언어 구문 참조를, 평이한 영어로 된 회계 배경 지식은 차변과 대변 설명을 참조하세요.

돈은 항상 어딘가에서 오기 때문에, 제로섬은 그 사실을 오류 검사로 바꿔줍니다. 식료품에 40달러를 썼다면, 그 돈은 은행 계좌에서 나간 것입니다. 양쪽을 모두 기록하면 두 금액이 상쇄되어야 하며, 어느 한쪽의 오타가 있으면 파일이 로드되지 않아 조용히 잘못된 잔액을 생성하는 대신 오류가 발생합니다.

이것이 바로 일반 텍스트 원장이 비용 스프레드시트보다 더 신뢰할 수 있는 이유입니다. 구조 자체가 자체 점검 기능을 하기 때문입니다. 잔액 확인은 원장을 현실과 대조하는 관련 메커니즘입니다.

시작 날짜에 각 계정의 현재 잔액을 Equity:Opening-Balances에서 이동시키는 거래를 기록한 다음, balance 확인을 추가하여 이를 고정합니다. 재정 기록을 재구성할 필요는 없습니다. 시작 날짜를 선택하고, 그날의 잔액을 그대로 가져와서 그 시점부터 진행하면 됩니다.

빠른 시작에서 전체 개시 잔액 예제를 설명합니다.

거칠게 시작하고, 세분화가 결정을 바꿀 때만 분할하세요. 약 20개의 계정으로 시작하기에 충분합니다. "Expenses:Food"에서 식료품과 외식을 분리해야 할지 고민된다면, 유용한 테스트는 분할을 알았을 때 실제로 다르게 행동할 것인지입니다.

나중에 이름을 바꾸고 분할하는 것은 텍스트 파일에서 찾기 및 바꾸기 작업이므로, 간단하게 시작하는 비용은 낮습니다. 계정 이름은 중첩되므로, 광범위한 범주로 시작하여 나중에 기록을 다시 쓰지 않고 하위 계정으로 분할할 수 있습니다. 복사할 구조를 원한다면 계정 체계 설계 방법을 참조하세요.

스프레드시트는 언제 잘못되었는지 알려줄 수 없습니다. 일반 텍스트 회계는 복식 부기를 강제하므로 모든 거래가 자체 점검되며, 파일은 텍스트 파일이 존재하는 한 검색(grep) 가능하고, 차이(diff) 가능하며, 스크립팅 가능합니다. 또한 실제 버전 기록을 얻을 수 있습니다: 원장에서 git log를 실행하면 정확히 무엇이, 언제, 왜 변경되었는지 보여줍니다.

실용적인 차이는 여러 계정, 통화 또는 투자가 있을 때 나타나며, 단식 부기 스프레드시트는 조용히 부정확해집니다. 투명하고 감사 가능한 회계를 참조하세요.

커피에 얼마를 썼는지만 알고 싶다면, 그렇습니다. 스프레드시트면 충분합니다. 복식 부기는 여러 계정, 모기지, 증권 계좌 또는 둘 이상의 통화가 있을 때 그 가치를 발휘합니다. 정확히 이런 상황에서 단식 부기 추적은 알리지 않고 돈을 잃어버리기 때문입니다.

유용한 사고 방식은 복식 부기를 재무의 체크섬으로 생각하는 것입니다. 더 자세한 내용은 소개를 참조하세요.

아닙니다. Fava는 동일한 텍스트 파일 위에서 작동하는 완전한 웹 인터페이스(대차 대조표, 손익 계산서, 차트, 거래 입력)를 제공하며, Beancount.io는 원장을 클라우드에서 실행해 줍니다. 텍스트 파일은 진실의 원천으로 남아 있으므로, 평소에는 웹 UI를 사용하고 필요할 때만 터미널을 사용할 수 있습니다.

인터페이스 기능은 UI 기능을 참조하거나, 라이브 데모를 시도해 보세요.

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

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

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

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

다른 해결책은 이체입니다. 두 계정 간의 자금 이동은 두 은행의 내보내기에 나타납니다. 두 개의 분개가 있는 단일 거래로 한 번만 기록하세요.

OFX는 CSV보다 이를 더 쉽게 만들어 줍니다: 모든 거래에는 은행이 다운로드 간에 안정적으로 유지하는 FITID가 포함되어 있어, 임포터가 추론 대신 식별자로 매칭할 수 있습니다 — OFX 변환기는 이를 id: 메타데이터 필드로 보존합니다.

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

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

명세서의 기말 잔액과 날짜로 balance 확인을 추가하세요. 원장이 은행과 일치하지 않으면 Beancount가 파일 로드를 거부하므로, 조정이 수동 비교에서 소프트웨어가 실행될 때마다 확인하는 작업으로 바뀝니다.

월 단위 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는 각 로드 시 전체 거래 내역에서 잔액을 다시 계산하며, 수십만 개의 항목까지 빠르게 유지됩니다. 그 이상이 되면 include로 연도별로 분할하면 쾌적하게 유지됩니다.

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