"Double-Entry" 태그로 연결된 10개 게시물개의 게시물이 있습니다.

분개는 복식 회계의 핵심이며, Beancount에서는 작성하는 모든 * 거래가 바로 분개입니다. 이 가이드는 차변과 대변, 조정 분개, 역분개의 핵심 개념을 설명하고, 이를 Beancount의 평문 구문에 어떻게 깔끔하게 매핑하는지 보여줍니다. 최소한의 절차로 정확한 장부를 유지하는 방법을 배울 수 있습니다.

빠른 복습: 분개란 무엇인가?​

분개는 재무 거래를 날짜와 함께 공식적으로 기록한 것입니다. 차변과 대변으로 표현되며, 기본 회계 방정식을 균형 있게 유지합니다:

$Assets = Liabilities + Equity$

복식 시스템에서는 모든 거래가 최소 두 개의 계정에 영향을 미치며, 차변 총액은 대변 총액과 반드시 일치해야 합니다. 이 간단한 규칙 덕분에 손익계산서와 대차대조표 같은 하위 재무 보고서가 신뢰할 수 있고 정확합니다.

1분 안에 이해하는 차변과 대변​

차변과 대변 개념은 처음에 혼란스러울 수 있지만, 몇 가지 간단한 규칙으로 정리됩니다. “가치는 어디서 왔는가?” (대변)와 “가치는 어디로 갔는가?” (차변)라고 생각하면 됩니다.

다음은 다섯 가지 핵심 계정 유형을 어떻게 증가시키는지 보여주는 요약표입니다:

Beancount에서 분개는 어떻게 보이는가​

Beancount는 간단하고 사람이 읽기 쉬운 텍스트 지시문으로 거래를 기록합니다. 각 거래는 모든 통화(예: USD, EUR, AAPL 주식)마다 합계가 0이 되어야 합니다. 균형이 맞지 않으면 Beancount가 오류를 발생시킵니다.

다음은 커피를 구매하는 기본 거래 예시입니다:

2025-09-10 * "Coffee Bar" "팀 커피"
  Expenses:Food:Coffee          18.00 USD
  Assets:Bank:Checking         -18.00 USD

두 개의 포스팅(계정이 적힌 줄)이 합쳐서 0이 되는 것을 확인하세요: $18.00 + (-$18.00) = 0.

태그(예: #clientX)와 링크(예: ^INV-2025-001)를 사용해 내러티브에 직접 컨텍스트를 추가하고, 보고서에서 쉽게 필터링하거나 관련 항목을 연결할 수 있습니다.

예를 들어, 청구서와 결제를 연결하는 방법은 다음과 같습니다:

; 먼저, 고객에게 보낸 청구서를 기록합니다
2025-09-15 * "Acme Corp" "Invoice 2025-001 #clientX ^INV-2025-001"
  Assets:AccountsReceivable   1000.00 USD
  Income:Consulting         -1000.00 USD

; 나중에, 결제를 기록하고 원래 청구서와 연결합니다
2025-09-28 * "Acme Corp" "Payment on ^INV-2025-001"
  Assets:Bank:Checking       1000.00 USD
  Assets:AccountsReceivable -1000.00 USD

#clientX 태그를 사용하면 해당 고객의 모든 거래를 쉽게 필터링할 수 있고, ^INV-2025-001 링크는 두 항목 사이에 연결 고리를 만들어 보고서에서 추적할 수 있습니다.

바로 사용할 수 있는 일반적인 분개 예시​

다음은 Beancount 형식으로 정리한 여러 일반 비즈니스 거래 예시입니다.

소유주 현금 투자​

소유주가 개인 자금을 사업에 투입합니다.

2025-01-01 * "Owner" "초기 자본 투자"
  Assets:Bank:Checking        10000.00 USD
  Equity:Owner-Capital      -10000.00 USD

현금 판매와 부가세​

고객이 현금으로 제품을 구매하고, 8% 부가세를 포함합니다. 부가세는 나중에 정부에 납부해야 합니다.

2025-01-05 * "Walk-in Customer" "현금 판매 (8% 세금 포함)"
  Assets:Cash                   108.00 USD
  Income:Sales                -100.00 USD
  Liabilities:Tax:Sales         -8.00 USD

외상 매출(청구서) 및 회수​

서비스를 제공하고 청구서를 발행한 뒤, 나중에 결제를 받습니다.

2025-01-10 * "Acme Corp" "Consulting invoice ^INV-2025-002"
  Assets:AccountsReceivable   2500.00 USD
  Income:Consulting         -2500.00 USD

2025-01-30 * "Acme Corp" "Payment on ^INV-2025-002"
  Assets:Bank:Checking       2500.00 USD
  Assets:AccountsReceivable -2500.00 USD

신용카드 사용 비용​

회사 신용카드로 사무용품을 구매합니다.

2025-01-12 * "OfficeMax" "신용카드 사용 사무용품"
  Expenses:Office:Supplies       75.00 USD
  Liabilities:CreditCard        -75.00 USD

급여 (단순 모델)​

급여를 지급하면서 총 급여 비용, 직원 세금 원천징수, 은행에서의 순지급액을 기록합니다.

2025-01-31 * "Payroll" "1월 급여 및 원천징수"
  Expenses:Payroll:Wages      2000.00 USD
  Liabilities:Taxes:Withheld   -400.00 USD
  Assets:Bank:Checking       -1600.00 USD

월별 감가상각​

노트북 같은 자산에 대한 월별 감가상각 비용을 기록합니다.

2025-01-31 * "Depreciation" "노트북, 직선법"
  Expenses:Depreciation          100.00 USD
  Assets:Equipment:AccumDepr    -100.00 USD

선불 비용 및 월별 상각​

연간 보험료를 한 번에 선불로 지불하고, 매월 비용을 인식합니다.

; 1. 연간 보험료 선불 결제
2025-01-01 * "InsureCo" "연간 보험료"
  Assets:Prepaid:Insurance     1200.00 USD
  Assets:Bank:Checking       -1200.00 USD

; 2. 1월 말에 한 달분 비용 인식
2025-01-31 * "InsureCo" "보험료 1/12 상각"
  Expenses:Insurance             100.00 USD
  Assets:Prepaid:Insurance      -100.00 USD

이연 수익 및 월별 인식​

고객이 3개월 구독 서비스를 선불로 결제합니다. 현금을 기록한 뒤, 매월 수익을 인식합니다.

; 1. 서비스 선불 결제
2025-02-01 * "Subscriber" "3개월 구독 선불"
  Assets:Bank:Checking           300.00 USD
  Liabilities:Unearned:Subs     -300.00 USD

; 2. 1개월분 수익 인식
2025-02-28 * "Recognition" "1개월 구독 수익 인식"
  Liabilities:Unearned:Subs      100.00 USD
  Income:Subscriptions          -100.00 USD

대손충당금 설정 및 차감​

채권 회수 가능성이 낮은 청구서에 대한 충당금을 설정하고, 실제로 회수 불가능한 청구서를 차감합니다.

; 1. 매출채권의 2%에 해당하는 충당금 설정
2025-03-31 * "Provision" "매출채권 2% 충당금"
  Expenses:BadDebt               200.00 USD
  Assets:AllowanceForDoubtful   -200.00 USD

; 2. 회수 불가능한 청구서 차감
2025-04-15 * "Write-off" "고객 XYZ 청구서 차감"
  Assets:AllowanceForDoubtful    150.00 USD
  Assets:AccountsReceivable     -150.00 USD

주기적 재고 및 매출원가 조정​

기간 말에 재고조사를 통해 매출원가(COGS)를 조정합니다.

2025-03-31 * "COGS adjustment" "주기적 재고 방법"
  Expenses:COGS                4500.00 USD
  Assets:Inventory           -4500.00 USD

조정 분개 vs. 역분개​

조정 분개는 회계 기간(월말·분기말 등) 말에 매출·비용을 실제 발생 시점에 맞추기 위해 기록합니다. 여기에는 발생액, 이연액, 감가상각 등 추정치가 포함됩니다.

역분개는 선택 사항으로, 다음 기간 첫 날에 이전 기간의 특정 조정 분개를 정확히 반대로 기록합니다. 이렇게 하면 이후 현금 거래를 표준 방식으로 기록할 때 별도의 부채 계정을 생각할 필요가 없어 장부 관리가 간편해집니다.

예시: 공과금 발생액과 역분개​

1월에 공과금 비용을 발생시키지만 청구서는 2월에 도착한다고 가정합니다.

; 1. 1월 말에 추정 비용 발생액 기록
2025-01-31 * "Accrual" "1월 공과금 추정 비용"
  Expenses:Utilities              500.00 USD
  Liabilities:Accrued:Utilities  -500.00 USD

; 2. (선택) 다음 기간 첫 날에 역분개
2025-02-01 * "Reversal" "1월 공과금 역분개"
  Liabilities:Accrued:Utilities   500.00 USD
  Expenses:Utilities             -500.00 USD

; 3. 실제 청구서가 2월에 도착했을 때 결제 기록
; 실제 청구액은 $520입니다. 역분개 덕분에 전체 금액을 비용 계정에 바로 기록할 수 있습니다.
; 2월 순 비용은 $520 - $500 = $20이 됩니다.
2025-02-10 * "City Utilities" "1월 청구서 결제"
  Expenses:Utilities             520.00 USD
  Assets:Bank:Checking          -520.00 USD

Note: 위 예시는 최종 결제 시 금액을 나누어 기록하는 방법을 보여줍니다. 역분개 방식은 결제 기록을 단순화하는 대안입니다.

Beancount 분개 체크리스트​

다음 절차를 따라 입력이 깔끔하고 정확한지 확인하세요:

1. 날짜(YYYY-MM-DD)와 거래 플래그(*)를 입력합니다.
2. 거래 상대와 설명을 적습니다. 검색을 위해 #tags와 ^links를 활용합니다.
3. 각 통화마다 두 개 이상의 포스팅 라인을 넣어 합계가 0이 되도록 합니다.
4. Assets, Liabilities, Equity, Income, Expenses 다섯 가지 유형에 맞는 계정명을 사용합니다.
5. 필요에 따라 document: "invoices/INV-2025-001.pdf"와 같은 메타데이터를 추가해 추적성을 높입니다.

흔히 저지르는 실수 (Beancount가 도와주는 부분)​

• 불균형 포스팅: 차변·대변 합계가 0이 아니면 Beancount가 입력을 거부합니다. 이는 오류를 사전에 방지하는 핵심 기능입니다. 금액을 비워두면 Beancount가 자동으로 계산해 줍니다.
• 계정 부호 오류: Income, Equity, Liabilities는 대변(보통 음수)으로 증가한다는 점을 놓치기 쉽습니다. 잘못 입력하면 보고서가 이상하게 보이지만, 균형 규칙이 안전망 역할을 합니다.
• 링크 누락: 청구서와 결제를 연결하지 않으면 미수금 파악이 어려워집니다. ^links를 일관되게 사용하면 감사 가능한 흐름을 만들 수 있습니다.

다음 단계​

• Beancount 언어 및 균형 규칙: 공식 문서를 깊이 있게 살펴보세요.
• 구문 요약표: 모든 Beancount 지시문을 한눈에 볼 수 있는 참고 자료.
• 차변·대변 입문: 회계 규칙이 처음이라면 좋은 시작점.
• 조정·역분개: 회계 이론에 대한 자세한 기사.

부록: 회계 용어 → Beancount 매핑​

이 간단한 변환표를 활용하면 회계 지시를 Beancount 구문으로 바로 옮길 수 있습니다.

이러한 패턴과 예시를 통해 거의 모든 비즈니스 이벤트를 Beancount에 깔끔하게 모델링할 수 있으며, 재무 보고서가 예상치 못한 오류 없이 정확히 맞춰집니다.

세금은 개인 재무 세계에서 특별하고 복잡한 존재처럼 느껴질 수 있습니다. 하지만 그렇지 않다면 어떨까요? 세금을 원장에 있는 다른 금전 흐름처럼 취급할 수 있다면요? 좋은 소식: 가능합니다. 세금을 단순한 가치 이동으로 취급하면 Beancount 원장이 깔끔하고 쿼리하기 쉬우며—무엇보다도—이해하기 쉬워집니다.

아래는 개인 또는 소규모 비즈니스 Beancount 파일에 바로 적용할 수 있는 실용적이고 간결한 패턴입니다. 급여, 세금 납부 및 새해로 넘어가는 성가신 환급까지 처리할 수 있는 간단한 시스템입니다. 필요한 핵심 계정들을 소개하고 실제 예시를 따라가며, 필요한 답을 얻기 위한 정확한 쿼리도 보여드립니다.

핵심 원칙​

코드에 들어가기 전에 몇 가지 간단한 규칙에 동의합시다. 이러한 원칙은 논리적 흐름을 유지하고 미래의 골칫거리를 방지합니다.

• "무엇인지"와 "현금이 이동하는 시점"을 구분하세요. 🗓️
  이것이 가장 중요한 개념입니다. 세금 비용은 소득을 얻은 연도(예: 2024)에 속하며, IRS에 2025년 4월에 청구서를 정산하더라도 마찬가지입니다. 비용 발생 시점과 현금 지급 시점을 구분하지 않으면 연도별 보고서가 혼란스럽고 오해를 불러일으킵니다.

• 계정 계층 구조를 단순하고 지루하게 유지하세요. 📁
  세금 유형에 따라 계정을 명확히 이름 짓습니다(예: IncomeTax, SocialSecurity). 이렇게 하면 쿼리가 매우 간단해집니다. 계정 이름에 공급업체명이나 양식 번호(W-2, 1099 등)를 넣지 말고 메타데이터와 태그를 사용하세요.

• 연말 조정을 위해 발생주의를 받아들이세요. ⚖️
  개인 원장이라도 연말에 간단한 발생주의 항목을 사용하는 것이 보고서를 정확하게 만드는 가장 깔끔한 방법입니다. 이는 돈이 다음 해에 이동하더라도 해당 연도에 비용이나 환급을 인식한다는 의미입니다. 작은 추가 단계 하나가 나중에 복잡한 사고를 방지해 줍니다.

• 미래의 자신을 위해 작성하세요. 🧠
  목표는 명확성입니다. 세금 연도와 같은 추가 정보를 계정 이름에 넣는 것은 실제로 쿼리를 더 쉽게 만들 때만 적용하세요. 특별한 이유가 없는 한 매년 새로운 계정 집합(Expenses:Taxes:2024:Federal, Expenses:Taxes:2025:Federal 등)을 만들지 마세요. 평면 구조가 관리하기 더 쉽습니다.

최소 계정 골격​

시작을 위한 기본 계정 세트를 소개합니다. 이 구조는 미국 중심이지만, 자신의 국가 세제에 맞게 이름을 쉽게 바꿀 수 있습니다. 아래 open 지시문을 Beancount 파일에 넣기만 하면 됩니다.

2024-01-01 open Income:Taxes:Federal:IncomeTax USD
2024-01-01 open Income:Taxes:Federal:SocialSecurity USD
2024-01-01 open Income:Taxes:Federal:Medicare USD
2024-01-01 open Income:Taxes:State:IncomeTax USD
2024-01-01 open Income:Taxes:State:SalesTax USD

2024-01-01 open Expenses:Taxes:Federal:IncomeTax USD
2024-01-01 open Expenses:Taxes:Federal:SocialSecurity USD
2024-01-01 open Expenses:Taxes:Federal:Medicare USD
2024-01-01 open Expenses:Taxes:State:IncomeTax USD
2024-01-01 open Expenses:Taxes:State:SalesTax USD

2024-01-01 open Liabilities:Taxes:Federal:IncomeTax USD
2024-01-01 open Liabilities:Taxes:Federal:SocialSecurity USD
2024-01-01 open Liabilities:Taxes:Federal:Medicare USD
2024-01-01 open Liabilities:Taxes:State:IncomeTax USD
2024-01-01 open Liabilities:Taxes:State:SalesTax USD

2024-01-01 open Assets:Tax:Receivable USD

이 설정은 원천징수된 세금과 직접 납부 및 환급을 구분하여 돈이 정확히 어디로 갔는지 쉽게 확인할 수 있게 합니다. Liabilities와 Assets 계정은 연말 보고를 정확하게 유지하기 위한 비밀 무기입니다.

예시 1: 급여​

세금이 자동으로 원천징수되는 일반적인 급여를 기록해 봅시다. 핵심은 총 급여를 먼저 기록하고, 세금과 실제 은행 계좌에 입금된 현금으로 어떻게 나뉘었는지 보여주는 것입니다.

2025-07-15 * "급여 지급"
  Assets:Bank:Checking               -4341.00 USD
  Expenses:Taxes:Federal:IncomeTax   1200.00 USD
  Expenses:Taxes:Federal:SocialSecurity   372.00 USD
  Expenses:Taxes:Federal:Medicare   87.00 USD
  Income:Salary:Employer             6000.00 USD

이 하나의 거래가 전체 이야기를 전달합니다:

• 총 $6,000의 총소득을 벌었습니다.
• 그 중 $1,200은 연방 소득세로 IRS에 송금되었습니다.
• $372은 사회보장세, $87은 메디케어에 사용되었습니다.
• 나머지 $4,341이 실제 수령액입니다.

팁: 급여 명세서의 메타데이터(예: pay_period_end: "2025-07-15")를 거래에 첨부하면 감사 추적이 쉬워집니다.

예시 2: 신고하기 (연도 교차 문제)​

많은 사람들이 헷갈려하는 상황입니다: 2025년 4월에 2024년 세금을 신고하고 있습니다. 원천징수 후에도 추가로 $3,000을 더 내야 한다는 것을 알게 되었습니다.

이를 어떻게 기록할까요? 비용은 2024년에 반영하고, 현금 지급은 2025년에 발생하도록 해야 합니다. 이를 처리하는 두 가지 훌륭한 방법을 소개합니다.

옵션 A: 수동 2단계 발생주의​

이 방법은 순수 Beancount만 사용하며 플러그인이 필요 없습니다. 명확한 2단계 프로세스입니다.

단계 1: 세금 연도 말에 비용을 인식합니다. 2024년 마지막 날에 “정산” 항목을 생성합니다. 아직 현금 이동은 없으며, 비용을 인정하고 임시 부채 계정에 보관하는 것입니다.

2024-12-31 * "세금 정산"
  Liabilities:Taxes:Federal:IncomeTax   3000.00 USD

이제 2024년 손익계산서에 $3,000 비용이 정확히 표시됩니다.

단계 2: 현금 지급이 발생할 때 기록합니다. 2025년 4월에 실제로 IRS에 돈을 송금하면 부채를 정산합니다.

2025-04-15 * "세금 납부"
  Assets:Bank:Checking                 -3000.00 USD
  Liabilities:Taxes:Federal:IncomeTax          3000.00 USD

2024년 보고서는 정확하고, 2025년 현금 흐름도 정확합니다. 완벽합니다! 환급의 경우에도 같은 패턴을 역으로 적용하면 되며, 부채 계정 대신 Assets:Tax:Receivable를 사용하면 됩니다.

옵션 B: 플러그인으로 자동화​

지불을 하나의 거래로 유지하고 싶다면, beancount_reds_plugins.effective_date라는 훌륭한 커뮤니티 플러그인이 도움이 됩니다. 이 플러그인은 단일 항목에 다른 “유효일”을 지정할 수 있게 해줍니다.

먼저 메인 Beancount 파일에 플러그인을 활성화합니다: plugin "beancount_reds_plugins.effective_date"

이제 하나의 거래를 작성하면 플러그인이 자동으로 내부에서 분할하여 보고서를 정확하게 만들어 줍니다.

2025-04-15 * "세금 납부 (플러그인 사용)"
  plugin "effective_date"
  Assets:Bank:Checking                 -3000.00 USD
  Expenses:Taxes:Federal:IncomeTax    3000.00 USD
    effective_date: 2024-12-31

여기서는 현금 부분이 2025년 4월 15일에 기록되고, 비용 부분은 2024년 12월 31일에 소급 적용됩니다. 이는 옵션 A와 동일한 결과를 다른 워크플로우로 달성한 것입니다.

판매세는 어떻게 할까요?​

대부분의 개인 원장에서는 판매세가 간단합니다. 환급을 청구하지 않는다면 구매 시 별도의 비용으로 분리하면 됩니다.

2025-03-10 * "구매 - 판매세 포함"
  Expenses:Goods:OfficeSupplies      -200.00 USD
  Expenses:Taxes:Sales               -15.00 USD
  Assets:Bank:Checking               215.00 USD

이를 통해 연간 판매세 지출을 쉽게 추적할 수 있습니다. 부가가치세(VAT)를 다루는 사업을 운영한다면, 지급 및 수취 계정을 사용하는 보다 정식 시스템을 사용하지만 원리는 동일합니다.

실제로 실행할 쿼리​

이 구조의 핵심은 답을 쉽게 얻는 것입니다. 아래는 세금 현황을 확인하기 위한 BQL 쿼리 예시입니다.

1. 2024년 연방 소득세 총액은 얼마인가요?

SELECT SUM(position) FROM "Expenses:Taxes:Federal:IncomeTax"
WHERE date >= '2024-01-01' AND date < '2025-01-01';

2. 그 총액이 원천징수, 납부, 환급으로 어떻게 구분되는가?

SELECT
  SUM(CASE WHEN account LIKE '%IncomeTax%' THEN position ELSE 0 END) AS withholding,
  SUM(CASE WHEN account LIKE '%Payments%' THEN position ELSE 0 END) AS payments,
  SUM(CASE WHEN account LIKE '%Refunds%' THEN position ELSE 0 END) AS refunds
FROM "Expenses:Taxes:Federal"
WHERE date >= '2024-01-01' AND date < '2025-01-01';

3. 미결 세금 부채나 수취금이 있나요? (작업 확인에 유용!)

SELECT account, SUM(position) FROM "Liabilities:Taxes:Federal"
WHERE date >= '2024-01-01' AND date < '2025-01-01'
GROUP BY account;

요약​

• 세금을 간단한 거래로 취급합니다.
• 제공된 계정 구조를 사용합니다.
• 코드 블록을 활용하여 명확히 합니다.
• 쿼리를 실행해 데이터를 검증합니다.

최종 생각​

여기까지 읽었다면, Beancount에서 세금을 처리하기 위한 탄탄한 기반을 갖추게 된 것입니다. 원장을 깔끔하고 정확하며 이해하기 쉽게 유지하는 것이 목표임을 기억하세요. 회계 작업을 즐기세요!

재무제표는 마법처럼 나타나는 것이 아닙니다. 이는 회계 사이클이라 불리는 구조화되고 반복 가능한 프로세스의 최종 산물입니다. 원칙은 보편적이지만, 사용하는 도구에 따라 경험이 크게 달라질 수 있습니다. 이 가이드는 강력한 텍스트 기반 회계 도구인 Beancount에 초점을 맞춰 회계 사이클을 단계별로 안내합니다.

Beancount의 텍스트 우선 접근 방식이 어떻게 번거로운 단계를 없애는지, 자동화해야 할 부분은 무엇인지, 그리고 재무 건전성을 가장 명확히 파악할 수 있는 보고서는 무엇인지 살펴보겠습니다. 🧑‍💻

TL;DR: Beancount 워크플로우​

• Capture & Journal: 모든 거래를 깔끔한 복식부기 포스팅으로 .beancount 텍스트 파일에 기록합니다.
• Validate & Reconcile: balance 어설션을 사용해 원장이 은행 명세와 일치하는지 확인하고 bean-check로 오류를 잡습니다.
• Review: 조정되지 않은 시산표를 생성해 빠르게 sanity check를 합니다.
• Adjust: 발생비용, 이연비용, 감가상각 및 기타 기간 말 항목에 대한 조정 분개를 기록합니다.
• Re-review: 조정된 시산표를 확인해 모든 것이 정확한지 검증합니다.
• Publish & Close: 손익계산서, 대차대조표, 현금흐름표를 생성합니다. Beancount에서는 보고서가 날짜를 인식하므로 장부 마감은 선택 사항입니다.

이 흐름은 다음과 같이 시각화할 수 있습니다:

Step 1: 거래 캡처 및 기록​

이것이 기본 단계입니다. 모든 재무 이벤트—판매, 구매, 은행 수수료—는 반드시 기록되어야 합니다. Beancount에서는 main.beancount와 같이 간단한 텍스트 파일에 거래를 생성함으로써 이를 수행합니다. 파일을 연도별로 나누어 관리할 수도 있습니다.

각 거래는 복식부기 규칙을 따라야 하며, 모든 포스팅의 합은 반드시 0이어야 합니다. Beancount이 이를 자동으로 강제합니다.

2025-08-10 * "Walmart" "사무용품 구매"
  Expenses:Office:Supplies      45.67 USD
  Assets:Bank:Checking         -45.67 USD

• Pro-Tip: #project-phoenix 또는 #client-acme와 같은 태그를 사용해 데이터에 차원을 추가하세요. 나중에 쿼리와 보고서를 훨씬 유연하게 만들 수 있습니다.

조정 위생 ✅​

정확성을 보장하는 가장 강력한 기능은 balance 어설션입니다. 명세 기간 말(예: 월말)에는 해당 계정의 잔액이 어떠해야 하는지 선언합니다.

2025-08-31 balance Assets:Bank:Checking  12345.67 USD

Assets:Bank:Checking에 영향을 주는 모든 거래의 합이 12345.67 USD와 일치하지 않으면 Beancount이 오류를 발생시킵니다. 이 간단한 지시문은 원장을 자체 감사 문서로 전환합니다.

역사 데이터를 뒤늦게 입력하는 경우, pad 지시문을 사용해 개시 잔액이 첫 어설션과 맞도록 자동으로 균형 거래를 생성할 수 있습니다.

Step 2: "원장에 포스팅" (무료!)​

전통 회계 시스템에서는 먼저 "분개장(journal)"에 입력하고, 별도의 "포스팅" 단계에서 이를 "총계정원장(general ledger)"에 복사합니다.

Beancount에서는 .beancount 파일 자체가 분개장과 원장을 동시에 겸합니다. 거래를 작성하고 저장하면 이미 포스팅이 완료된 것입니다. 별도의 단계가 없습니다. 이 직접성은 텍스트 기반 회계의 핵심 장점이며, 보는 그대로가 결과가 됩니다.

Step 3: 조정되지 않은 시산표 준비​

조정을 시작하기 전에 빠르게 “모두 맞는가?”를 확인해야 합니다. 시산표는 모든 계정과 그 총액을 나열하는 간단한 보고서이며, 차변 총액과 대변 총액이 일치해야 합니다.

다음과 같은 간단한 쿼리로 생성할 수 있습니다:

bean-query main.beancount \
  "SELECT account, sum(position) GROUP BY 1 ORDER BY 1"

또는 Fava(Beancount 웹 인터페이스)를 열어 “Trial Balance” 보고서를 확인하세요. 자산 계정에 대변 잔액이 있거나, 비용 계정에 이상한 값이 있는지 살펴보세요.

Step 4: 조정 분개 기록​

조정 분개는 발생주의 회계에 따라 정확한 보고를 위해 필수적입니다. 현금 흐름과 무관하게 수익은 발생 시점에, 비용은 발생 시점에 인식됩니다.

일반적인 조정 항목:

• 발생비용(Accruals): 아직 청구하지 않은 매출이나 아직 지급하지 않은 비용을 기록합니다.
• 이연수익(Deferrals): 선불을 처리합니다. 고객이 1년 서비스 비용을 선불로 지급하면 Liabilities:UnearnedRevenue로 부채를 잡고 매월 1/12씩 수익으로 인식합니다.
• 비현금 항목: 감가상각 등.
• 수정(Corrections): 오류 수정 또는 은행 피드에서 누락된 항목(예: 소액 이자 지급) 반영.

예시: 매출 발생(Accruing Revenue)​

8월 31일에 프로젝트를 완료했지만 청구서는 9월에 보냅니다. 올바른 기간(8월)에 수익을 인식하려면 다음과 같이 조정 분개를 합니다:

2025-08-31 * "프로젝트 #1042 매출 발생"
  Assets:AccountsReceivable      3000.00 USD
  Income:Consulting             -3000.00 USD

예시: 감가상각 기록​

회사에 자산 감가상각 일정이 있습니다. 기간 말에 다음과 같이 비용을 기록합니다:

2025-12-31 * "컴퓨터 장비 연간 감가상각"
  Expenses:Depreciation                  4800.00 USD
  Assets:Fixed:AccumulatedDepreciation  -4800.00 USD

Step 5: 조정된 시산표 실행 및 검증​

조정 분개를 모두 입력한 뒤 다시 시산표를 실행합니다. 이것이 조정된 시산표이며, 재무제표 작성에 사용될 최종 숫자입니다.

또한 Beancount 내장 검증 명령을 실행해 보세요:

bean-check main.beancount

출력이 없으면 구문, 균형 규칙, 어설션 모두 정상이라는 뜻입니다.

Step 6: 재무제표 발행 📊​

이제 조정된 시산표의 숫자를 활용해 핵심 재무 보고서를 생성합니다. 가장 쉬운 방법은 Fava를 이용하는 것으로, 인터랙티브하고 드릴다운 가능한 보고서를 바로 제공합니다.

• 손익계산서 (Income Statement / P&L): 기간 동안의 수익과 비용을 보여주며 순이익 또는 순손실을 나타냅니다.
• 대차대조표 (Balance Sheet): 특정 시점에 자산, 부채, 자본(Equity)을 한눈에 보여줍니다.
• 현금흐름표 (Cash Flow Statement): 시작 현금과 종료 현금을 연결해 현금이 어디서 들어오고 어디로 나갔는지 보여줍니다.

맞춤형 보고서는 Beancount Query Language (BQL)를 사용해 만들 수 있습니다. 아래는 월간 손익계산서 쿼리 예시입니다:

-- 2025년 8월 손익계산서
SELECT account, sum(position)
WHERE account   '^(Income|Expenses)'
  AND date >= 2025-08-01 AND date <= 2025-08-31
GROUP BY account ORDER BY account;

Step 7: 장부 마감 (선택)​

전통 회계에서는 “마감” 절차를 통해 모든 임시 계정(수익·비용)을 0으로 만들고 순이익을 Retained Earnings(이익잉여금)으로 이전합니다. 이는 다음 회계 연도를 위해 임시 계정을 초기화하는 과정입니다.

Beancount에서는 보통 이 단계가 필요 없습니다. Fava 보고서는 날짜를 인식하므로 2025년 P&L을 요청하면 2025년 데이터만 사용합니다. 잔액이 “넘쳐” 나오지 않으며, 대부분의 사용자는 그대로 두고 작업합니다.

하지만 규정 준수나 주주 보고를 위해 공식 마감이 필요하다면, 연말에 총 수익·비용을 Equity:Retained-Earnings로 옮기는 간단한 거래를 추가하면 됩니다.

실용적인 월간 마감 체크리스트​

Beancount를 사용해 매월 장부를 마감하는 반복 가능한 체크리스트입니다.

• Capture: 모든 은행·신용카드 거래를 가져옵니다. 현금 지출이나 비정규 항목은 수동으로 입력합니다.
• Reconcile: 모든 은행·카드·대출 계정에 balance 어설션을 추가해 명세와 일치시키세요.
• Review: Fava에서 조정되지 않은 시산표를 검토합니다. 이상하거나 예상치 못한 잔액을 조사합니다. 미수금(Assets:AccountsReceivable)이나 미지급금(Liabilities:AccountsPayable)이 오래 남아 있지 않은지 확인합니다.
• Adjust: 발생수익·발생비용, 이연수익·이연비용 및 필요한 수정 분개를 기록합니다.
• Validate: bean-check를 실행하고 최종 조정된 시산표를 검토합니다.
• Publish: 손익계산서와 대차대조표를 생성해 이해관계자에게 전달하거나 보관합니다.
• Wrap-up: 필요 시 마감 분개를 수행하고, 해당 기간 .beancount 파일을 아카이브합니다.

Beancount가 회계 사이클에 강력한 이유​

• 투명성 및 감사 가능성: 원장이 텍스트 파일이므로 git으로 버전 관리하고 diff로 변경 사항을 검토하며 회계사와 명확하게 협업할 수 있습니다.
• 완전한 제어: 차트 오브 어카운트를 직접 정의합니다. 소프트웨어 공급업체의 구조에 얽매이지 않으며, 데이터는 영원히 열려 있는 포맷으로 여러분의 소유입니다.
• 비할 데 없는 파워: SQL‑like 쿼리(BQL)와 풍부한 웹 인터페이스(Fava)의 조합으로 재무 데이터를 자유롭게 슬라이스·다이스·분석할 수 있습니다.

시작을 위한 복사·붙여넣기 스니펫​

간단한 차트 오브 어카운트:

option "title" "My Personal Ledger"
option "operating_currency" "USD"

;; --- Accounts ---
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Assets:AccountsReceivable
1970-01-01 open Liabilities:CreditCard
1970-01-01 open Liabilities:UnearnedRevenue
1970-01-01 open Equity:Owner:Capital
1970-01-01 open Equity:Retained-Earnings
1970-01-01 open Income:Consulting
1970-01-01 open Expenses:Office:Supplies
1970-01-01 open Expenses:Software
1970-01-01 open Expenses:Depreciation

유용한 BQL 쿼리:

-- 미수금이 남아 있는 고객 찾기
SELECT payee, sum(position)
WHERE account = 'Assets:AccountsReceivable'
GROUP BY payee
HAVING sum(position) > 0
ORDER BY sum(position) DESC;

텍스트 기반 도구인 Beancount와 영원한 회계 사이클을 연결하면 견고하고 투명하며 오래 지속되는 시스템을 구축할 수 있습니다. 즐거운 부기 되세요!

수십 년 동안 비즈니스 회계 분야는 QuickBooks, Xero, FreshBooks 와 같은 폐쇄형 GUI 기반 시스템이 주류를 이루어 왔습니다. 이들 시스템은 사용하기 쉬운 시각적 워크플로우를 제공해 비기술 사용자에게 친숙합니다. 하지만 개발자, 파워 유저, 그리고 절대적인 투명성과 제어를 중시하는 사람들에게는 완전히 다른 접근 방식이 등장했습니다: Beancount.io.

이 글에서는 Beancount.io와 전통 회계 소프트웨어를 직접 비교합니다. 철학, 유연성, 비용, 장기 유지 관리 측면에서 핵심 차이를 살펴보고, 어떤 시스템이 여러분의 요구에 가장 잘 맞는지 판단할 수 있도록 돕겠습니다.

1. 철학과 워크플로우​

두 접근 방식의 가장 근본적인 차이는 핵심 철학에 있습니다.

Beancount.io
Beancount.io는 플레인 텍스트 회계라는 철학 위에 구축되었습니다. 모든 재무 거래는 단순 텍스트 파일의 한 줄로 기록됩니다. 이 “코드로서의 회계” 모델은 인간이 읽기 쉬운, 버전 관리가 가능한 레코드를 우선시합니다. 여러분의 재무 데이터는 언제든지 열어볼 수 있는 개방형 포맷에 보관되며, 공급업체에 의해 잠기지 않습니다. 이 워크플로우는 코드 편집기, Git 과 같은 버전 관리 시스템, 그리고 커맨드 라인 도구에 익숙한 사용자를 위해 설계되었습니다.

전통 소프트웨어
전통 회계 플랫폼은 GUI 기반이며 폼 중심입니다. 마법사, 드롭다운 메뉴, 시각적 폼을 통해 데이터를 입력합니다. 이 접근 방식은 즉시성 및 접근성을 강조해 비기술 사용자가 별다른 학습 곡선 없이 시작할 수 있게 합니다. 그러나 데이터는 독점 포맷이나 클라우드 데이터베이스에 저장되며, 다른 서비스로 마이그레이션하려면 복잡한 내보내기·가져오기 절차가 필요합니다.

판단: 완전한 제어, 데이터 소유권, 투명성, 자동화를 중시한다면 Beancount.io가 명백히 우수합니다. “클릭하고 바로 사용” 인터페이스와 최소 학습 곡선을 원한다면 전통 소프트웨어가 더 자연스럽게 느껴질 것입니다.

2. 유연성 및 맞춤화​

소프트웨어가 여러분의 구체적인 요구에 얼마나 잘 맞출 수 있나요?

Beancount.io
100 % 스크립트 가능하다는 것이 Beancount.io의 강점입니다. Python 과 완벽히 통합돼 은행 피드에서 데이터를 자동으로 가져오고, 복잡한 규칙에 따라 거래에 태그를 자동 부여하며, 정확히 원하는 형태의 맞춤 보고서를 생성할 수 있습니다. 확장성과 맞춤화 가능성은 사실상 무한하며, 공급업체가 부과하는 제한이 없습니다.

전통 소프트웨어
이들 플랫폼은 PayPal, Stripe, 급여 서비스 등 인기 도구와의 연동을 제공하지만, 공급업체가 만든 ‘벽’ 안에서만 동작합니다. 맞춤화는 플랫폼이 허용하는 범위에 제한되며, 고급 보고서나 자동화 기능은 종종 상위 플랜 업그레이드 또는 서드파티 애드온 구매가 필요합니다. API 를 사용할 수는 있지만, 언제나 해당 생태계의 규칙과 속도 제한에 얽매이게 됩니다.

판단: Beancount.io는 개발자와 기술 사용자를 위한 탁월한 유연성을 제공합니다. 전통 도구는 표준 비즈니스 애플리케이션과의 플러그‑앤‑플레이 워크플로우에 더 적합합니다.

3. 협업 및 투명성​

다른 사람과 작업하고 기록을 감사하는 방식이 크게 다릅니다.

Beancount.io
협업은 Git 으로 관리됩니다. 재무 원장에 대한 모든 변경 사항이 완전히 투명하고 감사 가능하게 기록됩니다. 누가 언제 무엇을 왜 바꿨는지 코드를 리뷰하듯 확인할 수 있습니다. 이는 이미 GitHub·GitLab 등 도구를 활용하는 분산 팀에 최적입니다. 또한 보고서에 나타나는 모든 숫자는 원장 파일의 정확한 라인 아이템으로 추적 가능해 완전한 감사성을 보장합니다.

전통 소프트웨어
협업은 내장된 사용자 역할 및 권한을 통해 이루어집니다. 회계사, 부기 담당자, 비즈니스 파트너를 웹 인터페이스에 초대해 직접 장부에 접근하도록 할 수 있습니다. 전통적인 재무 감독 모델에 매우 효과적이지만, 세금 계산이나 자동 잔액 조정 같은 내부 로직이 “블랙 박스”처럼 보일 수 있어 독립적인 검증이 어려울 수 있습니다.

판단: Beancount.io는 세밀한 감사 가능성과 코드 스타일 협업을 중시하는 팀에 최적입니다. 전통 시스템은 실시간 GUI 접근을 선호하는 회계 담당자에게 더 친숙합니다.

4. 비용 및 소유권​

재무 모델과 데이터 소유권 개념이 완전히 다릅니다.

Beancount.io
핵심 Beancount 소프트웨어는 오픈 소스이며 무료입니다. 비용은 호스팅, 지능형 자동화, 프리미엄 기능 등 부가 서비스에만 발생합니다. 사용자당 라이선스 비용이 없으므로 팀 규모가 커져도 추가 비용이 발생하지 않습니다. 가장 중요한 점은 공급업체 락인(lock‑in)이 전혀 없다는 것입니다. 데이터는 언제든지 옮기고, 편집하고, 저장할 수 있는 텍스트 파일 컬렉션입니다.

전통 소프트웨어
이들 서비스는 구독 모델을 채택해 월간·연간 요금이 청구됩니다. 기능에 따라 티어가 나뉘며, 사용자당 또는 기업당 비용이 증가합니다. 구독을 중단하면 데이터와 소프트웨어 기능에 대한 접근 권한을 잃을 위험이 있습니다. 이는 장기적인 의존성을 초래하는 중요한 리스크입니다.

판단: 기술 팀이 데이터 주권을 중시한다면 Beancount.io가 장기적으로 훨씬 비용 효율적입니다. 전통 소프트웨어는 예측 가능한 구독 비용을 제공하지만 장기 의존성을 만들게 됩니다.

5. 학습 곡선 및 도입 속도​

얼마나 빨리 시작할 수 있나요?

Beancount.io
학습 곡선이 확실히 가파릅니다. 텍스트 기반 편집, 기본 문법 이해, Git 등 도구 사용에 익숙해야 합니다. 그러나 초기 투자는 큰 보상을 가져옵니다. 일단 숙달하면 매우 빠르고 반복 가능한 워크플로우를 구현할 수 있으며, 재무 상황에 대한 깊이 있는 이해를 얻게 됩니다.

전통 소프트웨어
비기술 비즈니스 오너를 위해 설계돼 온보딩 마찰이 최소입니다. 몇 분 안에 인보이스 발행·비용 분류를 시작할 수 있습니다. 다만 맞춤 보고서 작성이나 다중 법인 회계 설정 등 고급 기능을 익히려면 여전히 상당한 시간 투자가 필요합니다.

판단: 강력한 시스템을 배우는 데 시간을 투자할 의향이 있다면 Beancount.io가 적합합니다. 즉각적인 결과가 필요하고 비기술 사용자인 경우 전통 소프트웨어가 더 빠르게 시작할 수 있습니다.

나란히 비교​

선택 시점​

결정은 궁극적으로 팀의 역량, 우선순위, 워크플로우에 달려 있습니다.

Beancount.io를 선택하세요 if you:

• 개발자, 데이터 분석가, 혹은 기술에 익숙한 파워 유저일 때.
• 절대적인 투명성, 제어, 장기 데이터 이동성을 최우선으로 할 때.
• 회계를 완전 자동화하고 맞춤 워크플로우에 깊게 통합하고 싶을 때.
• 재무 기록을 소스 코드처럼 엄격히 관리하고 싶을 때.

전통 회계 소프트웨어를 선택하세요 if you:

• 기술 설정 없이 빠른 시각적 인터페이스를 원할 때.
• 회계사 친화적인 즉시 접근성을 최소 교육으로 제공하고 싶을 때.
• 공급업체가 모든 업데이트와 규정 준수를 관리해 주는 관리형 호스팅 솔루션을 선호할 때.
• 통합 요구가 인기 있는 오프‑더‑쉘프 앱으로 충분히 충족될 때.

마무리 생각​

Beancount.io는 QuickBooks 를 능가하려는 것이 아니라 근본적으로 다른 사고 방식을 제시합니다. 회계를 코드로 보는 접근은 버전 관리와 Git 이 소프트웨어 개발에 가져다 준 투명성, 완전 재현성, 궁극적 제어와 같은 이점을 재무 분야에 적용합니다.

동시에 전통 회계 소프트웨어는 비기술 팀을 위한 즉시 사용 가능한 편의성과 준비된 통합을 계속해서 강점으로 유지합니다. 어느 쪽이 “더 좋다”는 문제가 아니라, 여러분의 워크플로우, 우선순위, 재무 데이터에 대한 제어 수준에 가장 잘 맞는 선택을 하는 것이 핵심입니다.

Beancount의 핵심 기능과 철학​

Beancount는 일반 텍스트 파일을 사용하여 거래를 기록하는 오픈소스 복식 부기 회계 시스템입니다. 핵심적으로 Beancount는 당신의 원장을 단순하고 엄격한 문법으로 정의된 데이터셋으로 취급합니다. 모든 금융 이벤트(거래, 계좌 개설, 상품 가격 등)는 텍스트 파일의 지시어(directive)이며, Beancount는 이를 파싱하여 인메모리(in-memory) 데이터베이스의 항목으로 변환합니다. 이 설계는 복식 부기 원칙을 강제합니다: 모든 거래는 계좌 간의 차변과 대변이 균형을 이루어야 합니다. 그 결과, 버전 관리가 가능하고, 쉽게 검사하고 질의할 수 있는 매우 투명하고 감사 가능한 원장이 만들어집니다.

철학 – 정확성과 미니멀리즘: Beancount의 설계는 데이터 무결성과 단순성을 우선시합니다. 개발자인 마틴 블레이스(Martin Blais)는 Beancount가 사용자가 실수를 할 것이라고 가정하는 "비관적(pessimistic)"인 태도를 취하며, 따라서 추가적인 검사와 제약을 부과한다고 설명합니다. 예를 들어, Beancount는 한 번도 추가된 적 없는 자산을 제거하는 것을 허용하지 않으며(마이너스 주식 보유나 현금 잔액 방지), 모든 계좌가 사용 전에 개설되도록 강제할 수 있습니다. Ledger의 "가상(virtual)" 또는 자동 균형 조정 전기(posting) 개념이 없는데, 이는 완전하게 균형 잡힌 항목을 강제하기 위한 의도적인 선택입니다. Beancount는 기본적인 복식 부기가 제공하는 것보다 더 많은 교차 검증을 통해 정확성에 대해 매우 엄격한 입장을 취합니다. 이러한 신중한 접근 방식은 "자기 자신을 너무 신뢰하지 않고" 소프트웨어가 자신의 실수를 잡아주기를 원하는 사용자들에게 매력적입니다.

최소한의 옵션, 최대한의 일관성: Ledger의 수많은 커맨드 라인 플래그와 튜닝 옵션과는 대조적으로, Beancount는 미니멀리즘을 선택합니다. 전역 옵션은 거의 없으며, 원장 파일 외부에서 거래의 의미를 변경하는 옵션은 전혀 없습니다. 회계에 영향을 미치는 모든 설정(예: 상품 원가 기준법이나 예약 가정)은 파일 내 지시어나 플러그인을 통해 이루어지므로, 보고서가 어떻게 생성되든 동일한 파일을 로드하면 항상 동일한 결과가 나옵니다. 이 설계는 Ledger의 많은 설정과 그들 사이의 미묘한 상호작용의 복잡성을 피합니다. Beancount의 철학은 회계 도구가 입력 파일에서 보고서까지 안정적이고 결정론적인 파이프라인이어야 한다는 것입니다. 이는 원장을 순차적으로 프로그래밍 방식으로 처리할 수 있는 지시어의 순서 있는 스트림으로 취급함으로써 달성됩니다. Ledger가 특별한 구문으로 취급하는 것들(예: 기초 잔액이나 가격 명세)조차도 Beancount의 데이터 모델에서는 일급 지시어이므로, 시스템의 확장성이 매우 높습니다.

플러그인과 쿼리 언어를 통한 확장성: Beancount는 Python으로 구현되었으며, 처리 파이프라인에 사용자 정의 로직을 주입할 수 있는 훅(hook)을 제공합니다. 사용자는 Python으로 플러그인을 작성하여 거래 스트림에 작용하게 할 수 있습니다(예: 사용자 정의 규칙을 강제하거나 자동 항목을 생성). 이 플러그인들은 파일이 처리될 때 실행되어, 소스 코드를 수정할 필요 없이 Beancount의 핵심 기능을 효과적으로 확장합니다. Beancount에는 또한 원장을 분석하기 위한 강력한 쿼리 언어(SQL에서 영감 받음)가 포함되어 있습니다. bean-query 도구는 파싱된 원장을 데이터베이스로 취급하고, 분석적인 쿼리를 실행할 수 있게 해줍니다. 예를 들어, 카테고리별 비용을 합산하거나 특정 수취인에 대한 모든 거래를 추출할 수 있습니다. Beancount 3.x에서는 이 쿼리 기능이 독립적인 beanquery 패키지로 옮겨졌지만, 사용자 관점에서는 여전히 SQL과 유사한 쿼리를 통해 유연한 보고를 제공합니다.

일반 텍스트와 버전 관리: 일반 텍스트 회계 도구로서, Beancount는 사용자 제어와 데이터의 장기 보존을 강조합니다. 원장은 단순히 어떤 텍스트 편집기에서나 편집할 수 있는 .beancount 텍스트 파일입니다. 이는 전체 금융 기록이 사람이 읽을 수 있는 형태로 저장되고, Git이나 다른 VCS에 넣어 시간 경과에 따른 변경 사항을 추적할 수 있음을 의미합니다. 사용자들은 종종 모든 편집의 감사 추적(변경 사항을 설명하는 커밋 메시지와 함께)을 유지하기 위해 Beancount 파일을 버전 관리 하에 둡니다. 이 접근 방식은 회계 데이터, 특히 개인이나 소규모 사업체의 재무 정보는 투명하고 "미래에도 사용 가능(future-proof)"해야 하며, 독점적인 데이터베이스에 갇혀 있어서는 안 된다는 Beancount의 철학과 일치합니다. 마틴 블레이스의 말에 따르면, Beancount는 커뮤니티를 위해 단순하고, 내구성 있고, 무료로 만들어진 "사랑의 노동(labor of love)"입니다. 이는 2007년경에 처음 개발되었으며, 주요 재작성(v1에서 v2로, 그리고 2024년의 v3)을 통해 미니멀리즘과 정확성이라는 핵심 철학을 유지하면서 설계를 개선해 왔습니다.

Beancount 생태계의 도구, 플러그인 및 확장 기능​

Beancount 생태계는 핵심 원장 기능을 향상시키는 풍부한 도구, 플러그인 및 확장 기능을 갖추게 되었습니다. 이들은 데이터 가져오기, 원장 편집, 보고서 보기, 그리고 전문화된 회계 기능 추가 등을 다룹니다. 다음은 Beancount 세계의 주요 구성 요소 및 애드온에 대한 개요입니다.

데이터 가져오기 유틸리티 (임포터)​

실용적인 사용을 위해 가장 중요한 요구 사항 중 하나는 은행, 신용카드 및 기타 금융 기관에서 거래를 가져오는 것입니다. Beancount는 이를 위해 임포트 프레임워크와 커뮤니티가 기여한 임포트 스크립트를 제공합니다. Beancount 2.x에서는 내장 모듈 beancount.ingest(bean-extract 및 bean-identify와 같은 명령어 포함)를 사용하여 Python으로 임포터 플러그인을 정의하고 다운로드한 명세서에 적용했습니다. Beancount 3.x에서는 이것이 Beangulp라는 외부 프로젝트로 대체되었습니다. Beangulp는 beancount.ingest에서 발전한 전용 임포터 프레임워크이며, 현재 Beancount 3.0의 거래 임포트 자동화를 위한 권장 방법입니다. 이는 외부 파일(CSV나 PDF 명세서 등)을 읽고 Beancount 항목을 출력하는 Python 스크립트나 커맨드 라인 도구를 작성할 수 있게 해줍니다. 이 새로운 접근 방식은 임포트 로직을 Beancount 코어와 분리합니다. 예를 들어, 오래된 bean-extract 명령어는 v3에서 제거되었고, 대신 당신의 임포트 스크립트 자체가 Beangulp의 CLI 인터페이스를 통해 거래를 생성합니다.

다양한 은행과 형식을 위한 수십 개의 기성 임포터가 커뮤니티의 기여로 존재합니다. 중국의 Alipay와 WeChat Pay부터 다양한 유럽 은행(Commerzbank, ING, ABN AMRO 등), 미국의 Chase와 Amex 같은 은행에 이르기까지 전 세계 기관을 위한 임포터 스크립트가 있습니다. 이들 중 다수는 공개 저장소(주로 GitHub)나 beancount-importers와 같은 패키지에 수집되어 있습니다. 예를 들어, Tarioch Beancount Tools 프로젝트(tariochbctools)는 스위스와 영국 은행을 위한 임포터를 제공하며 암호화폐 거래 임포트까지 처리합니다. 또 다른 예는 Lazy Beancount로, 일반적인 임포터 세트(Wise, Monzo, Revolut, IBKR 등)를 패키징하고 쉬운 자동화를 위한 Docker 기반 설정을 제공합니다. 당신이 어떤 은행이나 금융 서비스를 사용하든, 누군가가 그것을 위한 Beancount 임포터를 작성했을 가능성이 높습니다. 그렇지 않다면 Beangulp의 프레임워크를 사용하여 직접 작성할 수 있습니다. Python의 유연성은 임포터가 CSV/Excel 파일 파싱, OFX/QIF 다운로드, 심지어 API 스크래핑까지 처리한 다음, 표준화된 Beancount 형식으로 거래를 내보낼 수 있음을 의미합니다.

편집 및 편집기 통합​

Beancount 원장은 단지 텍스트이기 때문에, 사용자들은 종종 자신이 선호하는 텍스트 편집기나 IDE를 사용하여 관리합니다. 생태계는 이 경험을 더 원활하게 만들기 위해 편집기 지원 플러그인을 제공합니다. 많은 인기 편집기를 위한 확장 기능이 있어 구문 강조, 계정 이름 자동 완성, 실시간 오류 검사 등을 추가합니다.

• Emacs Beancount-Mode: .beancount 파일을 편집하기 위한 Emacs 메이저 모드(beancount-mode)가 있으며, 구문 색상 지정 및 Beancount의 검사기와의 통합과 같은 기능을 제공합니다. 백그라운드에서 bean-check를 실행하여 원장의 오류(예: 불균형 거래)를 편집하는 동안 플래그를 지정할 수도 있습니다.
• VS Code 확장 프로그램: VSCode Marketplace의 Beancount 확장 프로그램은 Visual Studio Code 사용자에게 유사한 편의를 제공합니다. 구문 강조, 금액 정렬, 계정/수취인 자동 완성, 그리고 파일을 저장할 때 즉석 잔액 검사까지 지원합니다. 또한 Fava와 통합되어 VSCode 내에서 Fava 웹 인터페이스를 시작할 수 있습니다.
• Vim, Atom 및 기타 편집기를 위한 플러그인이나 모드도 존재합니다. 예를 들어, Beancount용 Tree-sitter 문법이 있어 최신 편집기에서 구문 강조를 지원하며, Fava의 웹 기반 편집기 컴포넌트에도 채택되었습니다. 요컨대, 당신의 편집 환경이 무엇이든, 커뮤니티는 Beancount 파일 편집을 편리하고 오류 없이 만들기 위한 플러그인을 제공했을 가능성이 높습니다.

전통적인 편집기 외부에서 빠르게 거래를 입력하기 위해, Bean-add와 모바일 앱과 같은 도구도 있습니다. Bean-add는 프롬프트나 한 줄 명령어를 통해 새로운 거래를 추가할 수 있게 해주는 커맨드 라인 도구로, 날짜와 계정 제안을 처리합니다. 모바일에서는 Beancount Mobile이라는 프로젝트가 이동 중에 거래를 입력할 수 있는 간단한 인터페이스를 제공합니다(예: 휴대폰에서 현금 구매 기록). 또한, 메시지를 통해 거래를 캡처하는 Beancount Telegram Bot이 존재합니다. 거래 세부 정보와 함께 메시지를 보내면 봇이 이를 원장 파일에 형식화해 줍니다.

웹 프론트엔드 및 시각화 도구​

(Fava) Fava의 웹 인터페이스는 Beancount를 위한 대화형 대시보드를 제공하며, 계정과 잔액 테이블과 함께 시각화된 손익계산서(여기서는 카테고리별 비용의 트리맵으로 표시됨)와 같은 보고서를 특징으로 합니다.

Beancount의 대표적인 프론트엔드는 현대적인 웹 인터페이스인 Fava입니다. Fava는 로컬 웹 앱으로 실행되어 Beancount 파일을 읽고 브라우저에서 풍부한 대화형 경험을 제공합니다. 대차대조표, 손익계산서, 시간 경과에 따른 순자산, 포트폴리오 보유 현황, 성과 차트, 예산 등 모든 보고서 제품군을 기본적으로 제공합니다. 사용자들은 종종 다른 일반 텍스트 회계 도구보다 Beancount를 선택하는 주요 이유로 Fava를 꼽습니다. fava ledger.beancount라는 단일 명령어로, 텍스트 대신 그래프와 표로 재무 상태를 탐색할 수 있습니다. Fava는 다음과 같은 기능을 지원합니다: 계정 드릴다운, 수취인 또는 태그별 거래 필터링, 쿼리 편집기(브라우저에서 Beancount 쿼리를 실행하고 결과를 볼 수 있음), 그리고 원장을 위한 통합 웹 기반 편집기까지. 사용성이 매우 뛰어나 시각적 인터페이스를 선호하는 사람들에게 일반 텍스트 회계를 접근하기 쉽게 만듭니다.

내부적으로 Fava는 Python(백엔드는 Flask)과 JavaScript(프론트엔드는 Svelte)로 작성되었습니다. 자체 출시 주기를 가지며 활발하게 유지 관리됩니다. 특히, Fava는 Beancount의 개발과 보조를 맞추어 왔습니다. 예를 들어, Fava 1.30은 Beancount v3 지원을 추가하여 내부적으로 새로운 beanquery 및 beangulp 패키지를 사용하도록 전환했습니다. (오래된 원장을 위해 Beancount 2도 여전히 지원합니다.) Fava의 사용성에 대한 집중은 웹 편집기의 자동 완성, 다크 모드와 반응형 차트를 갖춘 세련된 UI와 같은 멋진 기능들을 포함합니다. 또한 Fava-GTK라는 파생 프로젝트도 있는데, 이는 Fava를 데스크톱 애플리케이션으로 패키징하여 네이티브 앱 느낌을 선호하는 GNOME/Linux 사용자를 위한 것입니다.

Fava 외에도 다른 시각화 및 분석 옵션이 존재합니다. Beancount 데이터를 테이블로 내보내거나 쿼리할 수 있기 때문에, 사용자들은 종종 Jupyter 노트북이나 Pandas와 같은 도구를 사용하여 사용자 정의 분석을 수행합니다. 예를 들어, 한 사용자는 사용자 정의 보고서를 준비하기 위해 쿼리 인터페이스를 통해 Beancount에서 데이터를 Pandas DataFrame으로 가져온다고 설명합니다. 특정 보고서를 위한 커뮤니티 기여 스크립트도 있습니다. 예를 들어, 포트폴리오 배분 분석 도구나 지출 대 순자산의 공정 관리도 등이 있습니다. 그러나 대부분의 사람들에게 Fava는 코드를 작성할 필요 없이 충분한 보고 기능을 제공합니다. 심지어 확장 기능도 지원합니다: 새로운 보고서 페이지나 차트를 Fava에 추가하는 Python 파일을 드롭인할 수 있습니다. 주목할 만한 확장 기능은 Fava 내에서 봉투 예산 관리를 위한 fava-envelope입니다. 전반적으로 Fava는 Beancount 생태계의 중앙 시각화 허브 역할을 합니다.

커맨드 라인 유틸리티 및 스크립트​

Beancount는 다양한 CLI 도구와 함께 제공됩니다(특히 오래된 v2 브랜치에서, 일부는 v3에서 정리되었습니다). 이 도구들은 원장 파일을 조작하여 확인하거나 특정 보고서를 텍스트나 HTML로 생성합니다.

• bean-check: 파일의 구문 오류나 회계 오류를 확인하는 검사기입니다. bean-check myfile.beancount를 실행하면 불균형, 누락된 계정 또는 기타 문제를 알려주고, 파일에 오류가 없으면 아무것도 출력하지 않습니다.
• bean-format: 소스 코드에 코드 포맷터를 실행하는 것과 같이 숫자를 깔끔한 열로 정렬하여 원장을 정리하는 포맷터입니다. 파일을 깨끗하고 읽기 쉽게 유지하는 데 도움이 됩니다.
• bean-query: 원장에 대한 Beancount의 쿼리 언어를 실행하기 위한 대화형 셸 또는 배치 도구입니다. 사용자 정의 테이블 형식 보고서를 생성하는 데 사용할 수 있습니다(예: bean-query myfile.beancount "SELECT account, sum(amount) WHERE ...").
• bean-report: 미리 정의된 보고서(대차대조표, 손익계산서, 시산표 등)를 콘솔이나 파일로 출력할 수 있는 다용도 보고서 생성기(v2에서)입니다. 예를 들어, bean-report file.beancount balances는 계정 잔액을 인쇄합니다. (실제로 이러한 텍스트 보고서 중 다수는 Fava의 더 나은 프레젠테이션으로 대체되었습니다.)
• bean-web / bean-bake: localhost에서 보고서를 제공하거나 정적 HTML 파일로 "굽는(bake)" 오래된 웹 인터페이스입니다. 이들은 주로 Fava가 인기를 얻기 전에 사용되었습니다. bean-web은 bean-report가 생성할 수 있는 것과 동일한 보고서의 기본 웹 뷰를 제공했습니다. Beancount 3에서는 bean-web이 제거되었습니다(Fava가 이제 권장되는 웹 프론트엔드이며 우수한 경험을 제공하기 때문입니다).
• bean-example: 예제 원장 파일을 생성하는 유틸리티입니다(새로운 사용자가 Beancount 항목의 템플릿을 보는 데 유용합니다).
• bean-doctor: 원장이나 환경의 문제를 진단할 수 있는 디버깅 도구입니다.

Beancount v3부터 이러한 도구 중 다수가 핵심 프로젝트에서 분리되었다는 점은 주목할 가치가 있습니다. 핵심 Beancount 패키지는 간소화되었고, 쿼리 엔진 및 임포터와 같은 도구는 유지 관리를 용이하게 하기 위해 별도의 패키지(beanquery, beangulp 등)로 분리되었습니다. 예를 들어, bean-query의 기능은 이제 별도로 설치되는 beanquery 도구에 의해 제공됩니다. 사용자 관점에서 기능은 여전히 사용 가능하지만, 모듈화된 것뿐입니다. Arch Linux 커뮤니티는 Fava를 업데이트할 때 이 변경 사항을 주목했습니다: Fava 패키지는 Beancount 3.x를 지원하기 위해 beanquery와 beangulp에 대한 의존성을 추가했습니다. 이 모듈식 접근 방식은 또한 커뮤니티의 다른 사람들이 Beancount의 출시 주기와는 독립적으로 이러한 보조 도구에 더 쉽게 기여할 수 있게 합니다.

Beancount 플러그인 및 확장 기능​

Beancount 생태계의 뛰어난 강점 중 하나는 플러그인 시스템입니다. Beancount 파일에 plugin "module.name" 줄을 추가함으로써, 원장 처리 중에 실행되는 사용자 정의 Python 로직을 통합할 수 있습니다. 커뮤니티는 Beancount의 기능을 확장하기 위해 많은 플러그인을 만들었습니다.

• 데이터 품질 및 규칙: 예를 들어, 여러 계정을 포함하는 방정식을 주장할 수 있게 해주는 beancount-balexpr(예: 자산 A + 자산 B = 부채 X), 그리고 계정을 닫을 때 자동으로 잔액 검증을 삽입하여 순액이 0이 되도록 보장하는 beancount-checkclosed가 있습니다. 파일의 거래가 날짜순으로 정렬되었는지 확인하여 순서가 맞지 않는 항목을 잡아내는 플러그인(autobean.sorted)도 있습니다.
• 자동화: beancount-asset-transfer 플러그인은 계정 간에 현물 이체 항목을 생성할 수 있습니다(원가 기준을 유지하면서 브로커 간에 주식을 옮기는 데 유용합니다). 또 다른 플러그인인 autobean.xcheck는 불일치를 찾기 위해 Beancount 원장을 외부 명세서와 교차 확인합니다.
• 반복 거래 및 예산: Akuukis의 "repeat" 또는 보간 플러그인은 반복 거래를 정의하거나 연간 비용을 월별로 분산할 수 있게 해줍니다. 예산 관리를 위해, fava-envelope 확장 기능(Fava를 통해 사용)은 일반 텍스트로 봉투 예산 관리 방법론을 지원합니다. Frank Davies의 MiniBudget도 있습니다. 이는 개인 또는 소규모 사업체 예산 관리를 돕기 위해 Beancount에서 영감을 받은 작은 독립형 도구입니다.
• 세금 및 보고: 일부 플러그인은 세금 회계에 도움이 됩니다. 예를 들어, 자본 이득을 자동으로 단기 대 장기로 분류하는 플러그인이 있습니다. 또 다른 플러그인(fincen_114, Justus Pendleton 제작)은 해외 계좌를 가진 미국 납세자를 위한 FBAR 보고서를 생성하여 Beancount 데이터가 규제 보고에 어떻게 활용될 수 있는지를 보여줍니다.
• 커뮤니티 플러그인 저장소: 감가상각 항목 등에 초점을 맞춘 beancount-plugins(Dave Stephens 제작)와 정렬 지시어와 같은 다양한 도우미를 포함하는 beancount-plugins-zack(Stefano Zacchiroli 제작)과 같은 큐레이션된 플러그인 세트가 있습니다.

플러그인 외에도, Beancount를 중심으로 한 다른 유틸리티 도구들이 특정 요구를 해결합니다. 예를 들어, beancount-black은 Black 코드 포맷터와 유사하지만 Beancount 원장 파일을 위한 자동 포맷터입니다. 앞서 언급했듯이 채팅을 통해 거래를 추가하기 위한 Beancount Bot(Telegram/Mattermost)이 있으며, macOS용 Alfred 워크플로우를 사용하여 파일에 거래를 빠르게 추가할 수 있습니다. Pinto라는 도구는 대화형 입력(향상된 bean-add와 같은)을 갖춘 "강화된" CLI를 제공합니다. 다른 시스템에서 마이그레이션하는 사람들을 위해, 다른 곳에서 데이터를 가져오는 데 도움이 되는 변환기(YNAB2Beancount, CSV2Beancount, GnuCash2Beancount, Ledger2Beancount)가 존재합니다.

요약하자면, Beancount 생태계는 매우 광범위합니다. 아래 표 1은 주요 도구와 확장 기능 및 그 역할을 나열합니다.

Ledger, hledger 및 유사 시스템과의 비교​

Beancount는 일반 텍스트 복식 부기 회계 도구 제품군에 속하며, 그중에서도 Ledger CLI(존 위글리의 Ledger)와 hledger가 두드러집니다. 이 모든 시스템은 일반 텍스트 원장 파일과 복식 부기라는 핵심 아이디어를 공유하지만, 구문, 철학, 생태계 성숙도에서 차이가 있습니다. 다음 표는 Beancount, Ledger, hledger 간의 주요 차이점을 강조합니다.

요약하자면, Beancount는 엄격함, 플러그인 기반 확장성, 그리고 사용자 친화적인 웹 인터페이스를 강조함으로써 차별화됩니다. Ledger는 커맨드 라인 순수주의자들과 최고의 속도를 필요로 하는 사람들(Ledger의 C++ 엔진은 거대한 파일에서 매우 빠름)이 선호하는 고전적이고 매우 유연한 도구로 남아 있습니다. hledger는 중간 지점을 제공합니다 – Ledger의 기능 대부분을 약간 더 구조화하고 공식적으로 지원되는 (단순하지만) 웹 UI와 함께 제공합니다. 세 가지 모두 일반 텍스트 회계의 장점(감사 가능성, Git 버전 관리, 일반 데이터)을 공유하지만, Beancount의 생태계(특히 Fava와 함께)는 최근 몇 년 동안 일반 사용자가 더 접근하기 쉽게 만들었다고 할 수 있습니다. 반면에 Ledger/hledger 사용자들은 때때로 설정의 상대적 단순함(Python 불필요)과 오랜 기간 입증된 안정성을 선호합니다. 궁극적으로 이들 사이의 선택은 개인적인 선호에 달려 있습니다. 엄격한 정확성과 풍부한 생태계를 중시하는 사람들은 Beancount로 기울어지는 반면, 가볍고 터미널 중심적인 도구를 원하는 사람들은 Ledger나 hledger를 고수할 수 있습니다.

Beancount 사용 시나리오​

Beancount는 개인 재무 추적뿐만 아니라 (경우에 따라) 소규모 사업 회계에도 사용할 수 있을 만큼 다재다능합니다. 핵심 복식 부기 접근 방식은 두 시나리오에서 동일하지만, 규모와 특정 관행은 다를 수 있습니다.

개인 재무​

많은 Beancount 사용자는 개인 또는 가계 재무를 관리하기 위해 이를 사용합니다. Beancount의 일반적인 개인 재무 설정에는 당좌 및 저축 예금 계좌, 신용카드, 투자, 대출, 소득 카테고리(급여, 이자 등), 그리고 비용 카테고리(임대료, 식료품, 오락 등)가 포함될 수 있습니다. 사용자들은 일상적인 거래를 수동으로 기록하거나(영수증, 청구서 등 입력) 앞서 논의한 임포터 도구를 사용하여 은행 명세서에서 가져옵니다. Beancount가 개인 재무에 가져다주는 이점은 다음과 같습니다.

• 통합 및 분석: 모든 거래가 수년간의 금융 기록을 나타내는 단일 텍스트 파일(또는 파일 세트)에 저장될 수 있습니다. 이를 통해 장기적인 추세를 쉽게 분석할 수 있습니다. Beancount의 쿼리 언어나 Fava를 사용하면 "지난 5년간 여행에 얼마나 썼나?" 또는 "월평균 식료품비는 얼마인가?"와 같은 질문에 몇 초 만에 답할 수 있습니다. 한 사용자는 Beancount로 전환한 후, Fava를 통하거나 데이터를 쿼리하고 Pandas와 같은 도구를 사용하여 *"금융 데이터(지출, 기부, 세금 등) 분석이 사소해졌다"*고 언급했습니다. 본질적으로, 당신의 원장은 마음대로 쿼리할 수 있는 개인 금융 데이터베이스가 됩니다.
• 예산 및 계획: Beancount가 예산 시스템을 강제하지는 않지만, 구현할 수는 있습니다. 일부 사용자는 예산 계정을 만들거나 fava-envelope 플러그인을 사용하여 봉투 예산 관리를 합니다. 다른 사람들은 단순히 주기적인 보고서를 사용하여 지출을 목표와 비교합니다. 일반 텍스트이기 때문에, Beancount를 외부 예산 도구나 스프레드시트와 통합하는 것은 간단합니다(데이터를 내보내거나 쿼리에서 CSV 출력을 사용).
• 투자 및 순자산 추적: Beancount는 원가 기준 및 시장 가격을 강력하게 처리하기 때문에 투자 추적에 탁월합니다. 주식, 암호화폐 등의 매수/매도를 원가 세부 정보와 함께 기록한 다음, Prices 지시어를 사용하여 시장 가치를 추적할 수 있습니다. Fava는 시간 경과에 따른 순자산 차트와 자산 클래스별 포트폴리오 분석을 보여줄 수 있습니다. 이는 개인 자산 관리에 매우 유용합니다. Mint나 Personal Capital과 같은 상용 도구가 제공하는 것과 유사한 통찰력을 얻을 수 있지만, 완전히 자신의 통제 하에 있습니다. 다중 통화 처리도 내장되어 있어, 외화나 암호화폐를 보유하고 있다면 Beancount가 이를 추적하고 보고를 위해 변환할 수 있습니다.
• 대조 및 정확성: 개인 재무는 종종 은행 명세서와의 대조를 포함합니다. Beancount를 사용하면 잔액 검증이나 문서 기능을 사용하여 정기적으로 계정을 대조할 수 있습니다. 예를 들어, 매월 balance Assets:Bank:Checking <날짜> <잔액> 항목을 추가하여 원장이 월말 은행 명세서와 일치하는지 확인할 수 있습니다. bean-check 도구(또는 Fava의 오류 표시)는 일치하지 않는 경우 경고합니다. 한 사용자는 모든 계정을 매월 대조하는데, 이는 "어떤 비정상적인 활동도 잡아내는 데 도움이 된다"고 언급했습니다. 이는 Beancount가 촉진하는 좋은 개인 재무 위생 관행입니다.
• 자동화: 기술에 능숙한 개인들은 Beancount로 개인 재무 워크플로우의 상당 부분을 자동화했습니다. 임포터, cron 작업, 그리고 약간의 Python을 사용하여, 예를 들어 매일 은행 거래가 가져와져(일부는 OFX나 API 사용) 규칙에 따라 분류되어 Beancount 파일에 추가되도록 시스템을 설정할 수 있습니다. 시간이 지남에 따라 원장은 대부분 자동으로 업데이트되며, 필요에 따라 검토하고 조정하기만 하면 됩니다. 해커 뉴스(Hacker News)의 한 커뮤니티 회원은 3년 후 자신의 Beancount 장부가 "95% 자동화"되었다고 공유했습니다. 이러한 수준의 자동화는 Beancount의 일반 텍스트 개방성과 스크립팅 기능 덕분에 가능합니다.

개인 재무 사용자들은 스프레드시트나 앱보다 Beancount를 선택하는 경우가 많은데, 이는 데이터에 대한 완전한 소유권을 부여하고(폐쇄될 수 있는 클라우드 서비스에 의존하지 않음 – 예를 들어 Mint가 중단된 것과 같은 우려) 모든 데이터가 통합되었을 때 통찰력의 깊이가 더 크기 때문입니다. 학습 곡선은 간단하지 않습니다 – 기본적인 회계와 Beancount 구문을 배워야 하지만, 공식 문서와 커뮤니티 튜토리얼과 같은 자료들이 신규 사용자의 시작을 돕습니다. 일단 설정되면, 많은 사람들은 항상 자신의 재무 상태를 명확하고 신뢰할 수 있는 그림으로 볼 수 있다는 점에서 마음의 평화를 얻는다고 합니다.

소규모 사업 회계​

소규모 사업체(또는 비영리 단체, 클럽 등)에 Beancount를 사용하는 것은 개인적인 사용보다 덜 일반적이지만, 확실히 가능하며 일부는 성공적으로 해냈습니다. Beancount의 복식 부기 프레임워크는 사실상 기업 회계를 뒷받침하는 것과 동일한 시스템이지만, 전용 회계 소프트웨어가 제공하는 일부 상위 수준 기능(송장 모듈이나 급여 통합 등)이 없습니다. 다음은 Beancount가 소규모 사업 환경에 어떻게 부합할 수 있는지에 대한 설명입니다.

• 총계정원장 및 재무제표: 소규모 사업체는 Beancount 파일을 총계정원장으로 취급할 수 있습니다. 은행 계좌, 매출채권, 재고자산에 대한 자산 계정; 신용카드, 대출, 매입채무에 대한 부채 계정; 소유주 자본에 대한 자본 계정; 매출이나 서비스에 대한 수입 계정; 모든 사업 비용에 대한 비용 계정을 가질 수 있습니다. 이 원장을 유지함으로써, Beancount의 보고서나 쿼리를 사용하여 언제든지 손익계산서(P&L)와 대차대조표를 생성할 수 있습니다. 실제로, Beancount의 내장 보고서나 Fava는 회계 원칙에 완벽하게 부합하는 대차대조표와 P&L을 몇 초 만에 생성할 수 있습니다. 이는 소규모 사업체가 수익성, 재무 상태, 현금 흐름을 평가하기에 충분할 수 있습니다(현금 흐름표는 직접 내장되어 있지 않지만 쿼리를 통해 도출할 수 있음).
• 송장 및 매출채권(A/R), 매입채무(A/P): Beancount에는 내장된 송장 시스템이 없습니다. 사용자들은 일반적으로 외부에서 송장을 처리하고(예: Word나 송장 앱에서 송장 생성) 그 결과를 Beancount에 기록합니다. 예를 들어, 송장을 발행하면 매출채권을 차변에, 수입을 대변에 기록하는 항목을 기록합니다. 지불이 들어오면 현금/은행을 차변에, 매출채권을 대변에 기록합니다. 이런 식으로, A/R 계정의 잔액을 보고 미수금을 추적할 수 있습니다. 청구서(A/P)에도 동일하게 적용됩니다. 전문 회계 소프트웨어(알림을 보내거나 이메일과 통합할 수 있음)보다 수동적이지만, 완벽하게 가능합니다. 일부 사용자들은 Beancount로 송장을 관리하고 미결 송장을 놓치지 않도록 하는 방법에 대한 템플릿이나 워크플로우를 공유했습니다(예: 메타데이터나 사용자 정의 쿼리를 사용하여 미지급 송장 목록을 만듦).
• 재고 또는 매출원가(COGS): 제품을 판매하는 사업체의 경우, Beancount는 재고 구매 및 판매를 추적할 수 있지만, 규율 있는 항목 입력이 필요합니다. Inventory 및 원가 회계 기능을 사용할 수 있습니다: 재고 구매는 자산 계정을 증가시키고(항목에 원가 첨부), 판매는 원가를 비용(COGS)으로 이동시키고 수익을 기록합니다. Beancount는 로트 일치를 주장하기 때문에, 올바른 원가로 재고를 적절히 감소시키도록 강제하며, 이는 올바르게 수행될 경우 총이익 계산이 정확함을 보장할 수 있습니다. 그러나 자동화된 SKU 추적 같은 것은 없습니다 – 모든 것이 재무 수준(수량 및 원가)에서 이루어집니다.
• 급여 및 복잡한 거래: Beancount는 급여 거래(급여 비용, 세금 원천징수 등)를 기록할 수 있지만, 해당 수치를 계산하는 것은 외부에서 또는 다른 도구를 통해 수행된 다음 Beancount에 기장될 수 있습니다. 매우 작은 사업체(예: 한두 명의 직원)의 경우, 이는 관리 가능합니다. 예를 들어, 급여, 원천징수세, 고용주 세금 비용, 현금 지급 등을 분할하는 단일 분개 항목을 각 급여 기간마다 기록할 것입니다. 이를 수동으로 하는 것은 QuickBooks 분개 항목에서 하는 것과 유사합니다 – 어떤 계정을 사용해야 하는지에 대한 지식이 필요합니다.
• 다중 사용자 및 감사: 사업 환경에서의 한 가지 과제는 여러 사람이 장부에 접근해야 하거나 회계사가 검토해야 하는 경우입니다. Beancount는 텍스트 파일이므로 실시간으로 다중 사용자가 사용할 수 없습니다. 그러나 Git 저장소에서 파일을 호스팅하면 협업이 가능해집니다: 각 사람이 편집하고 커밋할 수 있으며, 차이점을 병합할 수 있습니다.
• 규제 준수: 세금 신고나 준수를 위해, Beancount의 데이터를 사용하여 필요한 보고서를 생성할 수 있지만, 사용자 정의 쿼리나 플러그인이 필요할 수 있습니다. 인도 정부 준수 보고를 위한 커뮤니티 플러그인과 FinCEN FBAR 보고를 위한 플러그인의 예를 보았습니다. 이는 노력만 있다면 Beancount가 특정 보고 요구 사항을 충족하도록 조정될 수 있음을 보여줍니다. 간단한 요구 사항(현금 회계 또는 기본 발생주의)을 가진 관할권의 소규모 사업체는 확실히 Beancount에서 장부를 유지하고 세금 신고를 위한 재무제표를 생성할 수 있습니다. 그러나 감가상각 일정이나 상각과 같은 기능은 자체적으로 항목을 작성하거나 플러그인을 사용해야 할 수 있습니다(예를 들어 Dave Stephens의 감가상각 플러그인이 이를 자동화하는 데 도움이 됩니다). 일부 회계 소프트웨어처럼 "자산 감가상각 클릭"과 같은 GUI는 없습니다. 감가상각을 거래로 인코딩해야 합니다(이는 어떤 면에서는 그것을 명확하게 만듭니다 – 모든 것이 검사할 수 있는 항목입니다).

실제로, 많은 기술 지향적인 소규모 사업주들은 QuickBooks의 편리함보다 통제와 투명성을 선호한다면 Beancount(또는 Ledger/hledger)를 사용해 왔습니다. Reddit의 한 토론에서는 거래량이 제한적인 표준 소규모 사업 회계의 경우 Beancount가 잘 작동한다고 언급했습니다. 제한 요소는 대개 편안함 수준입니다 – 사업주(또는 회계사)가 텍스트 기반 도구에 익숙한지 여부입니다. 한 가지 장점은 비용입니다: Beancount는 무료이지만, 회계 소프트웨어는 소규모 사업체에게 비용이 많이 들 수 있습니다. 반면에, 공식적인 지원 부족과 DIY 특성은 사업주이면서 어느 정도 기술적으로 능숙한 사람들에게 가장 적합하다는 것을 의미합니다. 프로그래밍 기술을 가진 프리랜서나 개인 사업자에게 Beancount는 클라우드 회계 서비스에 의존하지 않고 재무를 관리할 수 있는 매력적인 선택이 될 수 있습니다.

하이브리드 접근 방식도 가능합니다. 일부 소규모 사업체는 송장이나 급여를 위해 공식 시스템을 사용하지만, 분석 및 보관을 위해 주기적으로 데이터를 Beancount로 가져옵니다. 이런 식으로 그들은 두 세계의 장점을 모두 얻습니다 – 일상적인 운영을 위한 준수와 용이성, 그리고 통합된 통찰력을 위한 Beancount의 힘입니다.

요약하자면, Beancount는 사용자가 상용 소프트웨어가 자동화하는 것들을 수동으로 관리할 의향이 있다면 소규모 사업 회계를 처리할 수 있습니다. 이는 높은 수준의 투명성을 보장하며 – 장부를 직접 작성하기 때문에 깊이 이해하게 됩니다 – 부지런한 사용자에게는 흠잡을 데 없는 장부를 만들어낼 수 있습니다. 개인 및 사업 사용자 모두 Beancount의 핵심 강점으로부터 이익을 얻습니다: 신뢰할 수 있는 회계 엔진, 완전한 감사 추적, 그리고 독특한 시나리오에 적응할 수 있는 유연성(스크립팅 및 플러그인을 통해). 가계 예산을 추적하든 스타트업의 재무를 추적하든, Beancount는 정밀하고 개방적으로 이를 수행할 수 있는 도구 키트를 제공합니다.

커뮤니티 및 개발 활동​

Beancount는 헌신적인 커뮤니티와 그 오픈소스, 틈새 시장이지만 열정적인 특성을 반영하는 개발 스토리를 가지고 있습니다. 다음은 커뮤니티, 유지 관리자 및 관련 프로젝트에 대한 주요 사항입니다.

• 프로젝트 유지 관리: Beancount의 주요 저자는 마틴 블레이스(Martin Blais)로, 2007년경에 프로젝트를 시작하여 여러 버전을 거쳐 이끌어왔습니다. 오랫동안 개발은 대부분 1인 노력(커뮤니티의 패치 기여 제외)이었습니다. 마틴의 철학은 "가장 단순하고 내구성 있는 방식으로, 나 자신과 다른 사람들에게 유용한" 회계 도구를 만드는 것이었습니다. 이 개인적인 동기가 프로젝트를 사랑의 노동으로 계속 이끌었습니다. 2025년 현재, 마틴 블레이스는 여전히 수석 유지 관리자이며(그의 이름이 커밋에 나타나고 메일링 리스트/이슈 트래커에서 질문에 답함), Beancount 주변 생태계에는 각자의 프로젝트에서 많은 다른 기여자들이 있습니다.

• GitHub 및 저장소: 소스 코드는 GitHub의 beancount/beancount 저장소에서 호스팅됩니다. 프로젝트는 GPL-2.0 라이선스이며 수년에 걸쳐 소수의 기여자를 유치했습니다. 2024년 중반, Beancount 버전 3이 새로운 안정 브랜치로 공식 출시되었습니다. 이 릴리스는 일부 구성 요소를 분리하는 것을 포함했습니다. 예를 들어, beangulp 저장소(임포터용)와 beanquery 저장소(쿼리 도구용)는 이제 beancount GitHub 조직의 일부이며, 다소 독립적으로 유지 관리됩니다. 주요 Beancount 저장소는 핵심 회계 엔진과 파일 파서에 중점을 둡니다. 2025년 현재, Beancount의 GitHub는 활발한 이슈 토론과 일부 진행 중인 개발을 보여줍니다 – 비록 많은 양은 아니지만, 이슈와 풀 리퀘스트가 꾸준히 들어오고 버그 수정이나 기능 개선을 위한 가끔의 업데이트가 이루어집니다.

• Fava 개발: 웹 인터페이스인 Fava는 별도의 프로젝트로 시작되었습니다(2016년에 저작권을 등록한 도미닉 오마이어가 제작). 자체 커뮤니티 기여자들이 있으며 GitHub의 beancount/fava 아래에 있습니다. Fava의 유지 관리자들과 기여자들(예: 최근 몇 년간 야콥 슈네츠, 슈테판 오테 등)은 인터페이스를 활발히 개선하고 있으며, 몇 달에 한 번씩 릴리스됩니다. Fava의 Gitter 채팅(Fava 문서에 링크됨)과 GitHub 이슈 트래커는 사용자와 개발자가 새로운 기능이나 버그를 논의하는 장소입니다. 프로젝트는 기여를 환영하며, 이는 여러 커뮤니티 구성원에게 PR에 대한 감사를 표하는 CHANGELOG 노트에서 증명됩니다. Beancount v3 및 새로운 beanquery 구문 지원을 신속하게 추가하는 등 Beancount 개발과의 긴밀한 연계는 두 프로젝트 간의 좋은 협업을 나타냅니다.

• 메일링 리스트 및 포럼: Beancount는 공식 메일링 리스트(이전에는 Google 그룹스, "Beancount" 또는 때때로 일반 Ledger 리스트에서 논의됨)를 가지고 있습니다. 이 메일링 리스트는 지식의 보고입니다 – 사용자들은 특정 시나리오를 모델링하는 방법, 버그 보고, 팁 공유에 대해 질문합니다. 마틴 블레이스는 메일링 리스트에서 상세한 설명으로 응답하는 것으로 알려져 있습니다. 또한, 더 넓은 일반 텍스트 회계 커뮤니티와 많이 겹칩니다. Ledger CLI 메일링 리스트는 종종 Beancount에 대한 질문도 다루며, plaintextaccounting.org의 포럼과 r/plaintextaccounting 서브레딧에서 Beancount 주제가 자주 올라옵니다. 이 플랫폼의 사용자들은 비교, 개인 설정 공유, 신규 사용자 돕기 등을 논의합니다. 커뮤니티의 일반적인 분위기는 매우 협조적입니다 – Beancount 사용자는 종종 Ledger 사용자를 돕고 그 반대도 마찬가지이며, 모든 도구가 비슷한 목표를 가지고 있음을 인식합니다.

• 채팅 그룹: 메일링 리스트 외에도 Plaintext Accounting Slack/Discord(커뮤니티 조직) 및 Fava Gitter와 같은 채팅 채널이 있습니다. 이는 도움을 받거나 기능을 논의하는 덜 공식적이고 더 실시간적인 방법입니다. 예를 들어, 누군가 특정 은행의 임포터가 있는지 묻기 위해 Slack에 참여할 수 있습니다. 또한 일부 오랜 사용자들이 머무는 Matrix/IRC 채널(역사적으로 IRC의 #ledger 또는 #beancount)도 있습니다. 주류 소프트웨어 커뮤니티만큼 인구가 많지는 않지만, 이 채널들에는 종종 까다로운 회계 질문에 답할 수 있는 지식이 풍부한 사람들이 있습니다.

• 기여자 및 주요 커뮤니티 구성원: Beancount 커뮤니티에서 몇몇 이름이 두드러집니다.

  • "Redstreet" (Red S): 많은 플러그인(beancount-balexpr, sellgains 등)을 작성하고 종종 지원을 제공하는 다작의 기여자. 또한 임포터 스크립트 세트와 명세서를 가져오는 bean-download라는 도구를 유지 관리합니다.
  • Vasily M (Evernight): 일부 임포터 프레임워크와 beancount-valuation과 같은 플러그인의 저자이며, 투자 관련하여 Fava에 기여했습니다.
  • Stefano Zacchiroli (zack): Emacs용 beancount-mode와 자신의 플러그인 저장소를 만든 Debian 개발자. 학술 환경에서도 일반 텍스트 회계를 옹호해 왔습니다.
  • Simon Michael: 주로 hledger의 리더이지만, Beancount를 포함하는 plaintextaccounting.org를 운영합니다. 이 교차 수분은 Ledger/hledger 사용자들의 관심을 Beancount로 이끄는 데 도움이 되었습니다.
  • Frank hell (Tarioch): 특히 유럽 기관을 위한 주요 임포터 및 가격 수집기 세트인 Tarioch Beancount Tools의 기여자.
  • Siddhant Goel: Beancount에 대해 블로그를 쓰는(예: v3로 마이그레이션하는 가이드) 커뮤니티 회원이며 일부 임포터를 유지 관리합니다. 그의 블로그 게시물은 많은 신규 사용자에게 도움이 되었습니다.

  이들과 다른 많은 사람들이 코드, 문서, 포럼에서의 도움을 통해 생태계를 활기차게 만듭니다.

• GitHub 통계 및 포크: Beancount의 GitHub 저장소는 수백 개의 스타(관심도 표시)와 포크를 축적했습니다. Beancount 자체의 주목할 만한 포크는 드뭅니다 – "Beancount이지만 기능 X가 있는" 것을 시도하는 잘 알려진 분기된 포크는 없습니다. 대신, 사용자들이 다른 것을 원했을 때, 그들은 플러그인을 작성하거나 다른 도구(hledger 등)를 사용했으며 Beancount를 포크하지는 않았습니다. hledger는 Ledger의 일종의 포크(Beancount가 아님)로, Beancount 자체는 Ledger 아이디어의 독립적인 재해석으로 간주될 수 있지만, Beancount 저장소 내에는 큰 분열 프로젝트가 없습니다. 커뮤니티는 일반적으로 주요 저장소를 중심으로 모여 코드베이스를 분열시키는 대신 플러그인 인터페이스를 통해 확장했습니다. 이는 마틴 블레이스가 외부 기여에 개방적이었고(그의 문서에는 외부 기여 및 모듈을 인정하는 섹션도 있음) 플러그인 아키텍처가 대부분의 새로운 기능을 위해 포크를 유지할 필요가 없게 만들었기 때문일 것입니다.

• 커뮤니티 리소스: 커뮤니티에서 만든 Beancount 학습 및 사용을 위한 몇 가지 고품질 리소스가 있습니다.

  • GitHub Pages의 Beancount 문서(및 마틴이 유지 관리하는 소스 Google Docs) – 회계 이론과 Beancount가 이를 어떻게 구현하는지 포함하여 매우 포괄적입니다.
  • 수많은 블로그 게시물 및 개인 노트 – 예: LWN.net에는 "Counting beans... with Beancount"라는 기사가 있었고, 많은 개인 블로그(Awesome Beancount의 "블로그 게시물" 섹션에 나열됨)가 경험과 팁을 공유합니다. 이는 지식을 구축하고 새로운 사용자를 유치하는 데 도움이 됩니다.
  • 강연 및 프레젠테이션: Beancount는 밋업과 컨퍼런스에서 발표되었습니다(예: Python/Beancount로 재무 관리에 대한 PyMunich 2018 강연). 이러한 강연은 도구를 더 넓은 청중에게 소개하고 종종 해커 뉴스와 같은 포럼에서 관심을 불러일으킵니다.

• 주목할 만한 관련 프로젝트: Fava 외에도 Beancount와 관련된 일부 다른 프로젝트에는 자체 커뮤니티가 있습니다.

  • Plain Text Accounting 사이트 – 사이먼 마이클이 유지 관리하며, 모든 관련 도구에 대한 정보를 집계하고 사람들이 Beancount를 포함한 다양한 도구의 사용법을 공유하는 포럼이 있습니다.
  • 금융 도구 통합: 일부 사용자는 Beancount를 비즈니스 인텔리전스 도구나 데이터베이스와 통합합니다. 예를 들어, 한 Google 그룹스 스레드는 사용자 정의 함수를 통해 PostgreSQL을 Beancount 데이터와 함께 사용하는 방법을 자세히 설명합니다. 주류는 아니지만, 이는 커뮤니티가 Beancount의 기능(예: 매우 큰 데이터 세트나 내장된 것 이상의 복잡한 쿼리 처리)을 확장하려는 실험 정신을 보여줍니다.

요약하자면, Beancount의 커뮤니티는 대규모 오픈소스 프로젝트보다 작지만 매우 참여도가 높고 지식이 풍부합니다. 프로젝트는 꾸준한 개선과 매우 유용한 지원 채널을 누리고 있습니다. 협력적인 정신(임포터 공유, 플러그인 작성, 질문에 답변)은 2025년의 신규 사용자가 회계 시스템을 설정하기 위해 광범위한 이전 작업과 커뮤니티의 지혜에 의존할 수 있음을 의미합니다. 개발은 생태계 차원에서 활발합니다 – Fava 릴리스, 플러그인 개발 등 – 비록 핵심 변경이 더 드물더라도 말입니다. 생태계의 성장(Awesome Beancount 목록에 있는 수십 개의 도구로 입증됨)은 Beancount를 더욱 유능하게 만드는 건강한 커뮤니티를 말해줍니다.

최근 개발 및 예정된 기능​

2025년 현재, Beancount 생태계는 지난 몇 년간 상당한 발전을 보였으며, 미래의 개선에 대한 논의가 진행 중입니다. 다음은 주목할 만한 최근 개발 사항과 앞으로 나올 기능에 대한 간략한 전망입니다.

• Beancount 3.0 출시 (2024년): Beancount 2.x가 오랫동안 표준이었던 후, 버전 3가 2024년 중반에 공식적으로 출시되었습니다. v3는 코드베이스의 단순화와 현대화를 나타내기 때문에 이는 주요 이정표였습니다. 마틴 블레이스는 v3를 시스템을 더욱 "재정렬하고 단순화"할 기회로 구상했습니다. 원래는 큰 재작성이 될 것으로 생각되었지만, 실제로는 사용자에게 미치는 업데이트는 그다지 파괴적이지 않았습니다. 주요 변경 사항은 내부적인 것이었습니다: 새로운 파서, 일부 성능 개선, 그리고 핵심에서 선택적 구성 요소를 추출한 것입니다. 릴리스는 점진적으로 진행되었으며(v3는 2022년부터 베타였지만, 2024년 7월까지 권장 안정 버전이 됨), Siddhant Goel과 같은 사용자들은 2.x에서 3.x로의 마이그레이션이 몇 가지 워크플로우 변경만으로 "대부분 무난했다"고 보고했습니다.

• 모듈화 – 도구들이 별도 패키지로 이동: Beancount 3의 큰 변화 중 하나는 모놀리식 저장소에 있던 많은 도구들이 분리되었다는 것입니다. 예를 들어, bean-query는 이제 beanquery 패키지에서 제공되며, beancount.ingest는 beangulp 패키지로 대체되었습니다. bean-extract 및 bean-identify와 같은 명령어(임포트용)는 핵심 Beancount에서 제거되었습니다. 대신, 임포트를 위해 독립적인 스크립트를 사용하는 것이 철학입니다. 이는 v3로 업그레이드하면 beangulp를 설치하고 임포터 스크립트(각 임포터는 기본적으로 작은 프로그램임)를 실행해야 한다는 것을 의미하며, 중앙 bean-extract 설정 파일을 사용하는 대신입니다. 마찬가지로, 쿼리는 Beancount 코어와 독립적으로 설치하고 업데이트할 수 있는 beanquery를 통해 실행됩니다. 이 모듈식 접근 방식은 유지 관리를 더 쉽게 하고 커뮤니티 기여를 장려하기 위해 설계되었습니다. 또한 Beancount의 핵심을 간소화하여, 핵심은 순수하게 파싱 및 회계 로직에 집중하고 보조 기능은 별도로 발전할 수 있게 했습니다. 사용자 관점에서, 업그레이드 후에는 명령어(예: beanquery에서 bean-query 사용, 또는 이를 추상화하는 Fava 사용)를 조정해야 합니다. Fava의 변경 로그는 이러한 변경 사항을 명시적으로 언급합니다: Fava는 이제 beanquery와 beangulp에 의존하며, Beancount 3 대 2에 대해 임포트 워크플로우를 다르게 처리합니다.

• 성능 개선: 성능은 Beancount의 설계를 재검토하는 동기 중 하나였습니다. v3 계획(마틴의 "V3 목표" 문서에 요약됨)에는 파서 최적화와 로딩 프로세스를 더 빠르고 메모리 집약도를 낮추는 것이 포함되었습니다. 2025년까지 이러한 개선 사항 중 일부가 실현되었습니다. 일화적으로, 매우 큰 원장(수만 건의 거래 또는 많은 주식 거래)을 가진 사용자들은 최신 버전에서 더 나은 성능을 보고했습니다. 예를 들어, "소액 투자 거래"를 다루면서 성능 문제에 직면했던 한 사용자는 Google 그룹스에서 이러한 우려를 언급했으며, 이러한 피드백이 v3에 영향을 미쳤을 가능성이 높습니다. 새로운 파서는 더 효율적이고 명확한 방식으로 작성되어 미래에 확장될 수 있습니다. 또한, Fava 1.29는 원장이 변경될 때 응답성을 향상시키기 위해 더 효율적인 파일 감시 메커니즘(watchfiles 라이브러리 사용)으로 전환했습니다. 앞으로 커뮤니티는 큰 원장을 더 빠르게 처리하기 위해 증분 파싱(전체가 아닌 변경된 부분만 재처리)을 탐색할 수 있습니다. 이는 문서에서 "Beancount 서버 / 증분 부기" 아이디어로 암시되었습니다.

• 투자 추적 향상: 투자 및 포트폴리오 보고를 개선하기 위한 작업이 계속 진행 중입니다. 예를 들어, 평균 원가 기준 대 FIFO 처리가 길게 논의되었습니다. Beancount는 로트 일치를 강제하지만, 일부 사용자는 특정 관할권에 대해 평균 원가를 선호합니다. 원가 기준 부기를 더 유연하게 만들기 위한 제안과 논의가 있습니다(아마도 플러그인이나 옵션을 통해). 2025년까지 평균 원가를 위한 내장 스위치는 없지만, v3의 기반 작업(부기 재설계)은 플러그인이 이를 구현하기 더 쉽게 만듭니다. 세금을 최소화하기 위해 어떤 로트를 판매해야 하는지 제안할 수 있는 커뮤니티 플러그인 "Gains Minimizer"가 출시되었으며, 이는 투자 주변에 구축되고 있는 고급 도구의 종류를 보여줍니다. Fava 역시 포트폴리오 요약 확장 기능(수익률 계산 포함)과 같은 기능을 추가했습니다. 예정된 기능 측면에서, 이 영역에서 더 많은 것을 기대할 수 있습니다. 아마도 자동화된 포트폴리오 리밸런싱 제안이나 위험 분석이 있을 것이며, 이는 Beancount 데이터를 읽는 외부 도구일 가능성이 높습니다(모든 데이터가 거기에 있기 때문입니다).

• 새로운 플러그인 및 확장 기능: 플러그인 생태계는 계속해서 성장하고 있습니다. 최근 주목할 만한 추가 사항은 다음과 같습니다.

  • 예산 보고 도구 – 예: Fava의 UI를 사용하지 않는 경우를 위한 간단한 CLI 예산 보고서.
  • 암호화 및 보안 – Fava가 온라인에서 호스팅될 때 원장이 미사용 시 암호화되도록 하는 fava-encrypt 설정이 도입되어 재무 정보를 자체 호스팅하는 우려를 해결했습니다.
  • 삶의 질 향상 플러그인 – autobean-format(파일을 파싱하고 다시 인쇄하여 더 많은 예외적인 경우를 처리할 수 있는 새로운 포맷터) 및 편집기에서의 beancheck 통합(Emacs용 flymake).

  앞으로 커뮤니티는 플러그인을 통해 계속해서 공백을 메울 가능성이 높습니다. 예를 들어, 더 많은 세금 관련 플러그인(일부 사용자는 워시 세일 계산이나 특정 지역 세금 보고서와 같은 스크립트를 공유했습니다)을 보게 될 수도 있습니다.

• 잠재적인 예정 기능: 이슈 트래커와 메일링 리스트의 논의를 바탕으로 몇 가지 아이디어가 떠오르고 있습니다(보장되지는 않음).

  • 시간 해상도: 현재 Beancount는 거래에 대한 날짜만 추적합니다(타임스탬프 없음). 시간(주식 거래나 당일 거래 순서)을 추가하는 것에 대한 질문이 있었습니다. 마틴 블레이스는 일을 단순하게 유지하기 위해 일 이하의 타임스탬프는 범위 밖이라고 명시적으로 결정했습니다. 이는 곧 바뀔 것 같지 않습니다 – 따라서 예정된 버전은 아마도 시간 해상도를 추가하지 않고, 시간이 필요하다면 설명이나 계정에 통합하라는 입장을 고수할 것입니다.
  • 향상된 GUI 편집: Fava는 지속적으로 편집 기능을 개선하고 있습니다. 더 완전한 기능을 갖춘 웹 편집기(자동 제안, 새로운 거래를 위한 양식 기반 입력)가 가능성입니다. Fava 편집기에서 tree-sitter를 사용하는 기반이 마련되었습니다. 우리는 Fava가 단순한 뷰어가 아니라 더 강력한 편집기가 되어 많은 작업에 대해 텍스트 편집기를 열 필요성을 줄이는 것을 볼 수 있습니다.
  • 더 나은 다중 원장 지원: 일부 사용자는 여러 Beancount 파일을 유지 관리합니다(다른 법인 또는 개인과 사업 분리). 현재 파일 포함은 가능하지만 제한이 있었습니다(포함된 파일의 플러그인 등). 최근 autobean.include 플러그인이 외부 원장을 안전하게 포함하기 위해 만들어졌습니다. 미래에는 다중 파일 설정을 위한 일급 지원을 볼 수 있을 것입니다 – 아마도 여러 파일이 있는 Beancount "프로젝트" 개념(이는 VSCode 확장 기능의 beancount.mainBeanFile 설정과 같은 기능에 의해 암시됨). 이는 다중 법인 부기를 실행하거나 원장을 모듈화하려는 사람들에게 도움이 될 것입니다.
  • 실시간 또는 증분 계산: 원장이 커짐에 따라 보고서를 신속하게 재계산하는 능력이 중요해집니다. 실행 상태를 유지하고 거래가 변경될 때 결과를 업데이트하는 Beancount 서버라는 아이디어가 있습니다. 이는 Fava의 최적화나 편집기 플러그인이 쿼리할 수 있는 데몬으로 나타날 수 있습니다. 아마도 미래의 Fava 릴리스는 지속적으로 실행되는 Beancount 프로세스를 활용하여 거대한 원장에 대해 UI를 더 반응적으로 만들 것입니다.
  • 기금 회계 / 비영리 기능: Beancount의 기금 회계에 대한 개선 제안이 있었습니다. 비영리 단체는 회계 요구 사항(제한된 기금 대 비제한 기금)이 있으며, 이는 잠재적으로 Beancount의 태그나 계정 계층 구조로 모델링될 수 있습니다. 논의는 아직 내장 기능으로 이어지지 않았지만, 더 많은 비영리 단체가 Beancount를 채택하면 이는 새로운 기능(아마도 문서화된 모범 사례나 기금 잔액 추적 플러그인)을 이끌 수 있습니다.

• 장기 전망: 마틴 블레이스는 Beancount의 미래가 핵심을 더 엔진처럼 만들고 더 많은 기능을 플러그인으로 옮기는 데 있다고 암시했습니다. 이는 우리가 보는 것(v3의 모듈화)과 일치합니다. 따라서 철학적인 관점에서 "예정된 기능"은 더 큰 확장성입니다 – 아마도 플러그인이 새로운 지시어 유형을 정의하거나 통제된 방식으로 구문을 확장할 수 있게 하는 것까지도 포함할 수 있습니다. 그렇게 되면 Beancount의 핵심은 상대적으로 작고 안정적으로 유지되는 반면, 생태계는 대부분의 새로운 기능을 애드온으로 제공할 것입니다. 이는 플러그인 마켓플레이스나 사용자가 선택하고 고를 수 있도록 더 중앙화된 플러그인 목록으로 이어질 수 있습니다(Awesome Beancount 목록이 그 시작입니다).

결론적으로, 2025년의 Beancount 생태계는 활발하고 진화하고 있습니다. Beancount 3.0의 출시는 프로젝트의 기반이 미래를 위해 견고함을 보장하는 주요 최근 이벤트였습니다. 성능, 도구, 사용성(특히 Fava를 통해)의 개선은 진입 장벽을 계속해서 낮추었습니다. Beancount는 여전히 어느 정도의 전문 지식을 요구하는 도구로 남아 있지만, 이러한 발전 덕분에 몇 년 전보다 훨씬 더 접근하기 쉬워졌습니다. 예정된 기능은 핵심 철학에 대한 급격한 변화보다는 경험을 개선하는 데 초점을 맞출 가능성이 높습니다 – 더 빠른 성능, 더 나은 통합, 그리고 전문화된 확장 기능. 커뮤니티의 궤적은 Beancount가 복식 부기의 엄격한 힘과 현대 소프트웨어의 편리함 사이의 균형을 맞추며, 일반 텍스트 회계의 중심으로 계속 성숙할 것임을 시사합니다. 한 사용자가 해커 뉴스에서 재치있게 말했듯이, 일반 텍스트 회계는 재무를 이해하는 데 "초능력"을 부여하며 – Beancount의 최근 및 미래의 개선은 모든 사람이 그 초능력을 더 쉽게 휘두를 수 있도록 하는 것을 목표로 합니다.

출처: Beancount documentation and repository; Fava documentation; “A Comparison of Beancount and Ledger” by Martin Blais; Awesome Beancount resource list; User experiences and community reports;

여러분, 안녕하세요! 오늘 블로그 포스트에서는 단순함과 강력함으로 많은 사랑을 받고 있는 복식회계 도구 Beancount의 세계로 들어가 보겠습니다. 특히 두 가지 핵심 개념인 매출채권과 매입채무에 대해 이야기하겠습니다.

이 용어들을 이해하는 것은 Beancount(또는 모든 복식회계 시스템)를 효과적으로 사용하기 위해 필수적입니다. 초보자라면 걱정하지 마세요—단계별로 차근차근 설명해 드리겠습니다!

매출채권 및 매입채무: 기본 개념​

회계에서 “매출채권”과 “매입채무”는 빚진 돈을 추적하기 위해 사용되는 용어입니다. “매출채권”은 타인이 당신에게 빚진 돈을 의미하고, “매입채무”는 당신이 타인에게 빚진 돈을 의미합니다.

1. Accounts Receivable (A/R): 당신이 서점을 운영하고 고객이 신용으로 책을 구매했다고 가정해 보세요. 그 책에 대해 고객이 당신에게 빚진 금액이 매출채권이 됩니다.

2. Accounts Payable (A/P): 반대로, 출판사에 새 책 세트를 주문했지만 선불로 지불하지 않았다고 상상해 보세요. 출판사에게 당신이 빚진 금액이 매입채무가 됩니다.

Beancount에서는 이러한 항목들을 해당 계정을 통해 추적합니다. 주요 장점은 언제든지 재무 상태를 명확하고 정확하게 파악할 수 있다는 점입니다.

Beancount에서 매출채권 및 매입채무 설정하기​

Beancount 파일 구조는 필요에 따라 단순하게도, 복잡하게도 만들 수 있습니다. 매출채권과 매입채무를 위해서는 자산과 부채 섹션 아래에 별도 계정을 생성하는 것이 일반적입니다.

1970-01-01 open Assets:AccountsReceivable
1970-01-01 open Liabilities:AccountsPayable

거래 추적​

채권자 측​

계정을 설정한 후, 매출채권 및 매입채무와 관련된 거래를 추적할 수 있습니다. 예시를 살펴보겠습니다:

2023-05-29 * "Sold books to customer on credit"
  Assets:AccountsReceivable  100 USD
  Income:BookSales          -100 USD

여기서는 고객이 $100을 빚졌으므로 매출채권에 $100을 추가합니다. 동시에 아직 현금을 받지 않았으므로 수익을 동일 금액만큼 감소시켜 균형을 맞춥니다.

고객이 나중에 결제하면 다음과 같이 기록합니다:

2023-06-01 * "Received payment from customer"
  Assets:Bank:Savings        100 USD
  Assets:AccountsReceivable -100 USD

채무자 측​

매입채무에도 동일한 원리가 적용되지만 부호가 반대입니다:

2023-05-30 * "Bought books from publisher on credit"
  Liabilities:AccountsPayable  200 USD
  Expenses:BookPurchases     -200 USD

채무를 상환할 때는 다음과 같이 기록합니다:

2023-06-02 * "Paid off debt to publisher"
  Liabilities:AccountsPayable -200 USD
  Assets:Bank:Checking        200 USD

마무리​

매출채권과 매입채무는 모든 회계 시스템의 핵심입니다. 이를 정확히 추적함으로써 재무 상태를 포괄적으로 이해할 수 있습니다.

이는 시작에 불과하며 Beancount는 훨씬 더 많은 기능을 제공합니다. 이 블로그 포스트가 중요한 개념을 명확히 이해하는 데 도움이 되길 바랍니다. 언제나 그렇듯 즐거운 회계 되세요!

오늘 블로그 포스트에서는 비즈니스를 위한 Beancount 원장을 상세히 분석하여, 이 평문 복식부기 회계 시스템의 복잡성을 이해하도록 도와드리겠습니다.

먼저 코드를 살펴보겠습니다:

1970-01-01 open Assets:Bank:Mercury
1970-01-01 open Assets:Crypto

1970-01-01 open Equity:Bank:Chase

1970-01-01 open Income:Stripe
1970-01-01 open Income:Crypto:ETH

1970-01-01 open Expenses:COGS
1970-01-01 open Expenses:COGS:Contabo
1970-01-01 open Expenses:COGS:AmazonWebServices

1970-01-01 open Expenses:BusinessExpenses
1970-01-01 open Expenses:BusinessExpenses:ChatGPT

2023-05-14 * "CONTABO.COM" "Mercury Checking ••1234"
  Expenses:COGS:Contabo                               17.49 USD
  Assets:Bank:Mercury                                -17.49 USD

2023-05-11 * "Amazon Web Services" "Mercury Checking ••1234"
  Expenses:COGS:AmazonWebServices                  14490.33 USD
  Assets:Bank:Mercury                             -14490.33 USD

2023-03-01 * "STRIPE" "Mercury Checking ••1234"
  Income:Stripe                                   -21230.75 USD
  Assets:Bank:Mercury                              21230.75 USD

2023-05-18 * "customer_182734" "0x5190E84918FD67706A9DFDb337d5744dF4EE5f3f"
  Assets:Crypto                                         -19 ETH {1,856.20 USD}
  Income:Crypto:ETH                                      19 ETH @@ 35267.8 USD

코드 이해​

1. 계정 개설: 코드는 1970‑01‑01에 일련의 계정을 개설하면서 시작합니다. 여기에는 자산 계정(Assets:Bank:Mercury, Assets:Crypto), 자본 계정(Equity:Bank:Chase), 수익 계정(Income:Stripe, Income:Crypto:ETH), 그리고 비용 계정(Expenses:COGS, Expenses:COGS:AmazonWebServices, Expenses:BusinessExpenses, Expenses:BusinessExpenses:ChatGPT)이 포함됩니다.

2. 거래: 이후 2023‑03‑01부터 2023‑05‑18까지 여러 거래가 기록됩니다.

   • 2023‑05‑14 거래는 CONTABO.COM에 $17.49를 Mercury Checking ••1234에서 지불한 내용이며, 비용(Expenses:COGS:Contabo)과 Assets:Bank:Mercury 계정에서의 차감으로 기록됩니다.

   • 2023‑05‑11 거래는 Amazon Web Services에 $14,490.33을 동일한 은행 계좌에서 지불한 것으로, Expenses:COGS:AmazonWebServices 아래에 기록됩니다.

   • 2023‑03‑01 거래는 STRIPE로부터 수익이 입금된 것으로, 총액 $21,230.75가 Assets:Bank:Mercury에 추가되고, 수익(Income:Stripe)으로 기록됩니다.

   • 2023‑05‑18 마지막 거래는 고객으로부터 19 ETH를 받은 암호화폐 거래이며, Assets:Crypto와 Income:Crypto:ETH에 각각 기록됩니다. {1,856.20 USD}는 거래 시점의 ETH 가격을, @@ 35267.8 USD는 19 ETH 전체 가치(USD)를 나타냅니다.

모든 거래에서 복식부기 원칙이 적용되어 자산 = 부채 + 자본 방정식이 항상 성립하도록 유지됩니다.

최종 생각​

이 Beancount 원장은 재무 거래를 추적하기 위한 간단하면서도 강력한 시스템을 제공합니다. 특히 마지막 거래에서 보듯이 Beancount는 암호화폐와 같은 비전통적 자산도 손쉽게 기록할 수 있어, 디지털 금융 환경에 매우 적합합니다.

이번 분석이 Beancount의 구조와 기능을 이해하는 데 도움이 되었기를 바랍니다. 회계 전문가이든 개인 재무를 처음 관리하는 초보자이든, Beancount는 여러분의 요구에 맞는 유연한 솔루션을 제공합니다. 다음 포스트에서는 보다 고급 Beancount 활용법을 다룰 예정이니 많은 기대 바랍니다.

예시 계정명​

Assets:US:BofA:Checking

계정 유형​

Assets          +
Liabilities     -
Income          -
Expenses        +
Equity          -

상품​

CNY, EUR, CAD, AUD
GOOG, AAPL, RBF1005
HOME_MAYST, AIRMILES
HOURS

지시문​

일반 구문

YYYY-MM-DD <Directive> <Parameters...>

계정 개설 및 종료​

2001-05-29 open Expenses:Restaurant
2001-05-29 open Assets:Checking     USD,EUR  ; 통화 제약

2015-04-23 close Assets:Checking

상품 선언 (선택 사항)​

1998-07-22 commodity AAPL
  name: "Apple Computer Inc."

가격​

2015-04-30 price AAPL   125.15 CNY
2015-05-30 price AAPL   130.28 CNY

메모​

2013-03-20 note Assets:Checking "Called to ask about rebate"

문서​

2013-03-20 document Assets:Checking "path/to/statement.pdf"

거래​

2015-05-30 * "Some narration about this transaction"
  Liabilities:CreditCard   -101.23 CNY
  Expenses:Restaurant       101.23 CNY

2015-05-30 ! "Cable Co" "Phone Bill" #tag ˆlink
  id: "TW378743437"               ; 메타데이터
  Expenses:Home:Phone  87.45 CNY
  Assets:Checking                 ; 금액을 하나 생략할 수 있습니다

포스팅​

  ...    123.45 USD                             Simple
  ...        10 GOOG {502.12 USD}               With per-unit cost
  ...        10 GOOG {{5021.20 USD}}            With total cost
  ...        10 GOOG {502.12 # 9.95 USD}        With both costs
  ...   1000.00 USD   @ 1.10 CAD                With per-unit price
  ...        10 GOOG {502.12 USD} @ 1.10 CAD    With cost & price
  ...        10 GOOG {502.12 USD, 2014-05-12}   With date
  ! ...   123.45 USD ...                        With flag

잔액 검증 및 패딩​

; 지정된 통화에 대해서만 금액을 검증합니다:
2015-06-01 balance Liabilities:CreditCard  -634.30 CNY

; 다음 검증을 만족시키기 위해 자동으로 거래를 삽입합니다:
2015-06-01pad Assets:Checking Equity:Opening-Balances

이벤트​

2015-06-01 event "location" "New York, USA"
2015-06-30 event "address" "123 May Street"

옵션​

option "title" "My Personal Ledger"

기타​

pushtag #trip-to-peru
...
poptag  #trip-to-peru
; 주석은 세미콜론으로 시작합니다

Discover the Magic of Plain Text Accounting with Beancount

Introduction​

플레인 텍스트 회계가 더 이상 두려운 작업이 아닌 세상에 오신 것을 환영합니다. 오늘은 강력하고 유연하며 직관적인 플레인 텍스트 회계 도구인 Beancount를 소개합니다. Beancount는 투명하고 직관적인 접근 방식을 제공함으로써 여러분이 재무를 직접 관리할 수 있도록 돕습니다.

이 포괄적인 가이드에서는 Beancount의 기본 개념을 살펴보고 핵심 개념을 설명하며, 간단하지만 강력한 기능들을 단계별로 안내합니다. 이 블로그를 모두 읽고 나면 Beancount에 대한 확고한 이해를 갖게 되며, 재무 생활을 조직하고 분석하는 데 바로 활용할 수 있게 됩니다.

What is Beancount?​

Beancount는 Martin Blais가 만든 오픈 소스 플레인 텍스트 회계 시스템입니다. John Wiegley의 Ledger 시스템에서 영감을 받아, 플레인 텍스트 파일만으로 개인 및 소규모 사업 재무를 관리할 수 있는 견고하고 신뢰할 수 있는 방법을 제공하고자 합니다. Beancount를 사용하면 수입, 지출, 투자 등을 손쉽게 추적할 수 있습니다.

Why Beancount?​

플레인 텍스트 회계는 전통적인 스프레드시트 기반 또는 소프트웨어 기반 회계 시스템에 비해 여러 장점을 제공합니다.

• 투명성: Beancount 파일은 사람이 읽을 수 있는 형식이므로 재무 데이터를 이해하고 감사하기가 쉽습니다.
• 유연성: Beancount는 필요에 맞게 쉽게 커스터마이징할 수 있으며, 좋아하는 텍스트 편집기와 버전 관리 시스템을 사용해 재무 데이터를 관리할 수 있습니다.
• 휴대성: 재무 데이터는 어떤 기기에서도 접근 가능하며, 시스템 간 이전이나 다른 사람과 공유도 간편합니다.
• 미래 대비: 플레인 텍스트 파일은 보편적으로 호환되므로 기술이 변하더라도 재무 데이터에 계속 접근할 수 있습니다.

Beancount's Core Concepts​

Beancount를 효과적으로 사용하려면 핵심 개념을 이해하는 것이 중요합니다.

• 트랜잭션: 수입, 지출, 계정 간 이체 등 재무 이벤트는 트랜잭션으로 기록됩니다.
• 계정: 트랜잭션은 자산, 부채, 수입, 지출 등 하나 이상의 계정을 포함합니다.
• 복식부기: Beancount는 복식부기를 강제하여 모든 트랜잭션이 차변과 대변이 균형을 이루도록 합니다.
• 지시문: Beancount는 트랜잭션, 계정 개설, 기타 재무 이벤트를 정의하기 위해 일련의 지시문을 사용합니다.

Getting Started with Beancount​

Beancount를 시작하려면 다음 간단한 단계를 따르세요.

• Beancount 설치: 운영 체제에 맞는 설치 안내에 따라 Beancount를 설치합니다.
• Beancount 파일 생성: .beancount 확장자를 가진 새 플레인 텍스트 파일을 만듭니다 (예: my_finances.beancount).
• 계정 정의: open 지시문을 사용해 트랜잭션에 사용할 계정을 정의합니다.
• 트랜잭션 기록: txn 지시문을 사용해 재무 트랜잭션을 기록합니다.

또는 https://beancount.io 에서 바로 가입할 수도 있습니다. 아래는 플레인 텍스트 회계 예시입니다.

Example 1: Basic Transaction​

2023-04-01 open Assets:Checking
2023-04-01 open Expenses:Groceries

2023-04-10 txn "Grocery Store" "Buying groceries"
  Assets:Checking         -50.00 USD
  Expenses:Groceries       50.00 USD

이 예시에서는 Assets:Checking 과 Expenses:Groceries 두 계정을 개설합니다. 2023년 4월 10일에 식료품 구매 트랜잭션을 $50에 기록합니다. 트랜잭션은 Assets:Checking 잔액을 $50 차감(차변)하고, Expenses:Groceries 잔액을 $50 증가(대변)시킵니다.

Example 2: Income and Expense Transaction​

2023-04-01 open Assets:Checking
2023-04-01 open Income:Salary
2023-04-01 open Expenses:Rent

2023-04-05 txn "Employer" "Salary payment"
  Assets:Checking       2000.00 USD
  Income:Salary        -2000.00 USD

2023-04-06 txn "Landlord" "Monthly rent payment"
  Assets:Checking       -1000.00 USD
  Expenses:Rent          1000.00 USD

이 예시에서는 Assets:Checking, Income:Salary, Expenses:Rent 세 계정을 개설합니다. 2023년 4월 5일에 $2,000 급여 트랜잭션을 기록하면 Assets:Checking 잔액이 $2,000 증가(대변)하고 Income:Salary 잔액이 $2,000 감소(차변)합니다. 4월 6일에 $1,000 월세 트랜잭션을 기록하면 Assets:Checking 잔액이 $1,000 차감(차변)하고 Expenses:Rent 잔액이 $1,000 증가(대변)합니다.

Example 3: Transfer Between Accounts​

2023-04-01 open Assets:Checking
2023-04-01 open Assets:Savings

2023-04-15 txn "Bank" "Transfer from Checking to Savings"
  Assets:Checking       -500.00 USD
  Assets:Savings         500.00 USD

이 예시에서는 Assets:Checking 과 Assets:Savings 두 계정을 개설합니다. 2023년 4월 15일에 체크 계좌에서 저축 계좌로 $500을 이체하는 트랜잭션을 기록하면 Assets:Checking 잔액이 $500 차감(차변)하고 Assets:Savings 잔액이 $500 증가(대변)합니다.

위 예시들은 Beancount의 복식부기 시스템 기본 개념을 보여줍니다. 트랜잭션을 올바르게 기록함으로써 사용자는 정확한 재무 기록을 유지하고, 재무 상황을 파악할 수 있는 보고서를 생성할 수 있습니다.

Generating Reports and Analyzing Data​

Beancount는 대차대조표, 손익계산서 등 다양한 재무 보고서를 생성할 수 있는 강력한 도구 세트를 제공합니다. 또한 웹 기반 사용자 인터페이스인 Fava를 사용해 재무 데이터를 시각화하고 상호작용할 수 있습니다. https://beancount.io 는 MIT 라이선스로 제공되는 Fava 위에 구축되었습니다.

Conclusion​

플레인 텍스트 회계의 힘과 단순함을 Beancount와 함께 누려보세요. 핵심 개념을 이해하고 이 가이드의 단계들을 따라 하면 개인이나 소규모 사업 재무를 손쉽고 정확하게 관리할 수 있습니다. Beancount에 익숙해지면 고급 기능과 커스터마이징 옵션을 탐색해 여러분만의 요구에 맞게 시스템을 최적화할 수 있습니다.

지출을 추적하든, 미래를 계획하든, 재무 습관을 분석하든, Beancount는 목표 달성을 위한 유연성과 투명성을 제공합니다. 사용자 친화적인 접근 방식을 통해 Beancount는 여러분의 재무 관리 방식을 혁신하고, 재무 미래를 스스로 통제할 수 있게 해줍니다.

이제 Beancount에 대한 탄탄한 기반을 갖추었으니 플레인 텍스트 회계 여정을 시작할 시간입니다. 번거로운 스프레드시트와 복잡한 소프트웨어는 이제 안녕하고, Beancount의 세계를 환영하세요. 즐거운 회계 되세요!

현대 부기의 중요성​

여전히 스프레드시트로 투자를 관리하고 계신가요? 스프레드시트는 다재다능하지만, 포트폴리오가 커질수록 번거롭고 오류가 발생하기 쉽습니다. 여기 Beancount.io가 있습니다 – 주식 및 암호화폐 포트폴리오 관리를 위해 특별히 설계된, 정교하면서도 사용하기 쉬운 투자 추적 플랫폼입니다. 엔지니어와 금융 미니멀리스트를 염두에 두고 만든 Beancount.io는 강력한 기능과 직관적인 인터페이스를 결합해 투자 추적 경험을 간소화합니다.

복식부기: 정확성의 기반​

Beancount.io는 전 세계 금융 기관이 오랫동안 사용해 온 복식부기 원칙 위에 구축되었습니다. 이 시스템은 간단하면서도 강력한 개념을 통해 수학적 정확성을 보장합니다: 모든 금융 거래는 완벽히 균형을 이루어야 합니다.

복식부기에서는 각 거래에 최소 두 개의 항목이 필요합니다 – 차변(+)과 대변(-) – 서로 다른 계정에 기록됩니다. 이 내장 검증 시스템 덕분에 불균형 거래를 기록하는 것이 사실상 불가능해지며, 재무 기록이 정확하고 신뢰할 수 있게 유지됩니다.

1970-01-01 open Income:BeancountCorp
1970-01-01 open Assets:Cash
1970-01-01 open Expenses:Food
1970-01-01 open Assets:Receivables:Alice
1970-01-01 open Assets:Receivables:Bob
1970-01-01 open Assets:Receivables:Charlie
1970-01-01 open Liabilities:CreditCard

2019-05-31 * "BeancountCorp" "Salary of May 15th to May 31st"
  Income:BeancountCorp               -888 USD
  Assets:Cash                         888 USD

2019-07-12 * "Popeyes chicken sandwiches" "dinner with Alice, Bob, and Charlie"
  Expenses:Food 20 USD
  Assets:Receivables:Alice 20 USD
  Assets:Receivables:Bob 20 USD
  Assets:Receivables:Charlie 20 USD
  Liabilities:CreditCard -80 USD

위 두 예시에서 보듯이, 모든 거래는 회계 방정식을 만족해야 합니다.

자산 = 부채 + 자본(또는 순자산)

우리는 Martin Blais의 Beancount 구문과 Jakob Schnitzer의 웹 프로젝트 Fava를 사용해 이 웹사이트를 구축했습니다. 그리고 거래의 어느 한쪽이라도 0이 되지 않으면 경고를 표시합니다.

이제 원장을 어떻게 정확히 유지하는지 이해하셨을 것입니다. 그런데 “계정”이란 무엇일까요?

계정 이해하기: 물통 비유​

재무 계정을 서로 연결된 물통 시스템이라고 생각해 보세요. 돈은 물처럼 한 통에서 다른 통으로 흐릅니다. 이 비유는 복식부기를 직관적으로 만들어 줍니다: 한 계정에서 다른 계정으로 돈을 옮길 때, 물을 한 물통에서 다른 물통으로 부어 넣는 것과 같으며, 시스템 전체의 물(돈) 양은 변하지 않습니다.

Beancount.io는 다섯 종류의 계정을 제공합니다.

1. 수익(Income) — 금액은 항상 음수 또는 차변입니다. 이는 수익을 얻을 때 “수익” 계정에서 차변으로 기록되고, 자산 계정으로 대변이 되기 때문입니다.
2. 비용(Expenses) — 금액은 항상 양수 또는 대변입니다. 이는 비용을 지출할 때 “비용” 계정으로 대변이 되고, 자산 또는 부채에서 차변이 되기 때문입니다.
3. 부채(Liabilities) — 금액은 양수 또는 0입니다. 신용카드 부채가 좋은 예이며, 주기적으로 증가·감소합니다.
4. 자산(Assets) — 금액은 양수 또는 0입니다. 현금이나 부동산 등은 언제나 일정 가치를 가집니다.
5. 자본(Equity) — 순자산을 의미합니다. 시스템이 자동으로 계산합니다. Equity = Assets - Liabilities 로 표시되며, 여러분의 부를 나타냅니다.

이제 위 키워드들을 사용해 맞춤형 계정을 열 수 있습니다:

1970-01-01 open Assets:Cash
1970-01-01 open Assets:Stock:Robinhood
1970-01-01 open Assets:Crypto:Coinbase
1970-01-01 open Expenses:Transportation:Taxi
1970-01-01 open Equity:OpeningBalance

상품을 포함한 고급 투자 추적​

Beancount.io는 주식부터 암호화폐까지 다양한 투자를 추적하는 데 뛰어납니다. 복잡한 투자 시나리오를 어떻게 다루는지 살펴보겠습니다. 예를 들어, 2014년에 비트코인 10개를 개당 100달러에 매수한 경우는 다음과 같이 기록합니다:

2014-08-08 * "Buy 10 Bitcoin"
  Assets:Trade:Cash -1000.00 USD
  Assets:Trade:Positions  10 BTC {100.00 USD}

그리고 3년 뒤, 동일한 비트코인을 개당 10,000달러에 매도하면 다음과 같이 기록합니다 (@ 10,000.00 USD 로 표시).

2017-12-12 * "Sell 2 Bitcoin"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @ 10,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

같은 거래를 @@ 20,000.00 USD 로 표시하면 총 20,000달러에 매도한 의미가 됩니다.

2017-12-12 * "Sell 2 Bitcoin"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @@ 20,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

거래의 모든 항목, 즉 -2 BTC {100.00 USD} 를 포함한 합계는 언제나 0이 됩니다.

{100.00 USD} 라는 비용 태그는 동일한 상품을 서로 다른 가격에 여러 번 매수했을 때 중요합니다.

100 BTC {10.00 USD, 2012-08-08}
10 BTC {100.00 USD, 2014-08-08}

프로세스를 단순화하고 싶다면 계정을 FIFO 또는 LIFO 로 설정할 수 있습니다. FIFO는 “먼저 들어온 것이 먼저 나간다”, LIFO는 “마지막에 들어온 것이 먼저 나간다”는 의미이며, 미국 IRS는 PnL과 세금을 계산할 때 FIFO 방식을 사용합니다.

1970-01-01 open Assets:Trade:Positions "FIFO"

그 후 -2 BTC {} 와 같이 간단히 매도하면 Beancount가 자동으로 FIFO 전략을 적용해 가장 오래된 상품을 판매합니다.

Beancount.io 시작하기​

Beancount.io는 현대적인 클라우드 기반 재무 관리 플랫폼으로, 텍스트 기반 거래 기록을 손익계산서, 대차대조표, 시산표 등 포괄적인 재무 보고서로 변환합니다. 평문 파일의 신뢰성과 강력한 시각화 도구를 결합해 재무 생활을 정확히 통제하면서 투자 성과에 대한 귀중한 인사이트를 제공합니다.

Beancount.io와 함께 재무 여정을 시작하세요 – 프로모션 기간 동안 무료!