산업별 설정

프리랜서, 소규모 사업, 개인 금융을 위한 예제 구성

이 가이드에서는 프리랜서 전문가, 부티크 소규모 사업, 개인 가계 재정과 같은 다양한 요구 사항에 맞게 Beancount 원장을 조정하는 방법을 살펴봅니다. 각 시나리오에는 고유한 계정 구조와 고려 사항이 있습니다. 각 설정의 배경, Beancount 예제 스니펫, 추적을 용이하게 해주는 유용한 기능(사용자 정의 태그 및 자동 가져오기 등)을 설명합니다. 이 자료는 교육적이면서도 접근하기 쉬운 어조로 작성되었습니다. 개발자, 기술 전문가, 금융 애호가 모두 이러한 예제를 통해 Beancount를 실제 세계에 적용할 수 있습니다.

프리랜서

프리랜서(소프트웨어 개발자 또는 그래픽 디자이너 등)는 여러 고객과 프로젝트 비용을 동시에 처리하는 경우가 많습니다. 간단한 Beancount 설정을 통해 각 고객으로부터의 소득, 사업 비용(고용된 하청업체 포함), 세금을 위해 따로 확보해둔 금액을 추적할 수 있습니다. 목표는 불필요한 복잡성 없이 프리랜서 사업이 성장함에 따라 확장될 수 있도록 간단하게 유지하는 것입니다.

프리랜서를 위한 주요 계정: 프리랜서 원장은 일반적으로 사업 자금과 개인 자금을 분리합니다. 예를 들어 다음을 사용할 수 있습니다.

• 자산:사업:당좌예금 – 모든 고객 지불 및 사업 비용을 위한 사업 은행 계좌.
• 자산:사업:세금저축 – 세금 납부를 위해 소득의 일부를 따로 확보해두는 저축 계좌(고용주가 세금을 원천 징수하지 않으므로).
• 수익:고객:이름** – 고객 지불에 대한 수익 계정. 주요 고객별로 하위 계정(예: 수익:고객:ACME)을 만들거나 거래에 고객 이름이 태그된 단일 수익:프리랜서 계정을 사용할 수 있습니다.
• 비용:사업:계약자 – 하청업체 또는 아웃소싱 작업에 대한 지불.
• 비용:사업:소프트웨어(및 여행, 용품과 같은 기타 범주) – 일반적인 사업 비용(소프트웨어 구독, 장비, 고객 사이트 여행 등).
• 자본:소유주인출 – (선택 사항) 사업에서 개인적으로 이익을 이전하는 것을 기록합니다. 이를 통해 급여를 지급할 때 사업 자금과 개인 자금을 구별하는 데 도움이 됩니다.

배경: 이 구조는 모든 사업 관련 자금이 전용 계정에서 추적되도록 합니다. 각 고객으로부터의 소득이 기록되고(상위 고객을 쉽게 확인할 수 있음), 비용은 세금 공제를 위해 분류됩니다. 별도의 자산 계정에서 세금을 따로 확보해두면(또는 납부해야 할 세금에 대한 부채를 기록하면) 정부에 납부해야 할 돈을 실수로 소비하는 것을 방지할 수 있습니다. 원장은 단순하게 유지됩니다. 새로운 고객 또는 비용 범주를 확보하는 경우 모든 것을 재구성하지 않고도 새 계정을 추가하거나 태그를 사용할 수 있습니다. 일반적인 함정은 하나의 계정에 개인 거래와 사업 거래를 혼합하는 것입니다. 전용 사업 당좌 예금(및 해당 자산 계정)을 유지 관리하면 조정 및 보고가 더 깔끔해집니다. 피해야 할 또 다른 함정은 세금 또는 소유주 인출을 위한 현금 이체를 기록하는 것을 잊는 것입니다. 세금저축 및 소유주인출과 같은 계정을 사용하면 모든 달러가 계산됩니다.

강조할 Beancount 기능: 태그와 메타데이터는 프리랜서에게 매우 유용합니다. 예를 들어 프로젝트 또는 송장 번호로 거래에 태그를 지정하거나 고객별로 별도의 수익 계정을 사용하지 않기로 선택한 경우 메타데이터 필드를 사용하여 고객 이름을 기록할 수 있습니다. 이렇게 하면 특정 고객 또는 프로젝트에 대한 거래를 필터링하거나 쿼리하기가 쉽습니다(예: #ProjectX 태그가 지정된 모든 비용 합산). 또한 Beancount의 자동 가져오기를 사용하면 데이터 입력을 간소화할 수 있습니다. 예를 들어 은행 또는 신용 카드 명세서에 대한 가져오기를 설정하여 거래를 원장으로 가져온 다음 적절한 비용 또는 수익 계정 이름을 추가하기만 하면 됩니다. 이렇게 하면 소액 거래가 많은 경우(예: 소프트웨어 구독 또는 출장 비용) 시간을 절약할 수 있습니다.

프리랜서 예제 원장 스니펫

다음은 프리랜서 개발자를 위한 단순화된 Beancount 스니펫입니다. 몇 가지 주요 계정을 개설하고, 고객으로부터의 수입 지불, 하청업체에 대한 지불, 일반적인 사업 비용, 세금 저축 계정으로 돈을 이체하는 것을 보여줍니다. (실제로는 출장 또는 장비 구매와 같은 다른 비용도 비슷하게 기록합니다.)

1970-01-01 open Assets:Business:Checking
1970-01-01 open Assets:Business:TaxSavings
1970-01-01 open Income:Client:ACME
1970-01-01 open Expenses:Business:Contractors
1970-01-01 open Expenses:Business:Software

; 고객 수입 – 송장 지불
2025-08-15 * "ACME Corp로부터 송장 지불"
  invoice: "INV-2025-08-15"
  Assets:Business:Checking       5000 USD
  Income:Client:ACME           -5000 USD

; 정기 비용 – 예: 사업용 소프트웨어 구독
2025-08-05 * "GitHub 구독"
  Expenses:Business:Software       15 USD
  Assets:Business:Checking       - 15 USD

; 계약자 비용 – 도움을 위해 하청업체에 지불
2025-08-20 * "계약자 지불 – Jane Doe"
  Expenses:Business:Contractors   2000 USD
  Assets:Business:Checking      -2000 USD

; 세금 원천 징수 – 세금 저축으로 돈 이체
2025-08-31 * "3분기 세금 따로 확보"
  Assets:Business:TaxSavings     1500 USD
  Assets:Business:Checking     -1500 USD  #tax

무슨 일이 일어나고 있는지 분석해 보겠습니다.

• 상단에서 필요한 계정을 개설합니다(시작 날짜 포함). Beancount에서는 엄격하게 요구되는 것은 아니지만(계정은 열지 않은 경우 처음 사용할 때 생성됨) 선언하는 것이 좋습니다. Assets:Business:Checking 및 Assets:Business:TaxSavings 계정은 USD 잔액을 보유합니다. 수익 및 비용 계정은 거래 통화(이 경우 USD)를 상속하므로 열기 지시문에서 통화를 생략할 수 있습니다.
• 고객으로부터 송장 지불: 2025-08-15에 수익 거래는 송장에 대한 고객 지불 $5,000를 기록합니다. Income:Client:ACME를 대변하고(복식 부기에서 수익은 음수 금액으로 증가) 당좌 예금을 차변합니다. 메타데이터 필드 invoice: "INV-2025-08-15"가 포함되어 송장 번호를 기록합니다. 이는 선택 사항이지만 거래에 추가 정보를 첨부할 수 있는 방법을 보여줍니다. 이 거래에 #ACME 또는 #client-ACME로 태그를 지정하여 빠르게 필터링할 수도 있습니다. 고객이 여러 명인 경우 여러 하위 계정을 만드는 대신 일반적인 Income:Clients 계정을 사용하고 이러한 메타데이터 또는 수취인 필드에 의존하여 고객을 구별할 수 있습니다.
• 사업 비용(소프트웨어): 2025-08-05에 GitHub 구독에 대한 $15 비용을 기록합니다(예: 개인 리포지토리 또는 기타 서비스). 게시물은 Expenses:Business:Software로 이동하고 사업 당좌 예금을 줄입니다. 이와 같이 작고 반복적인 비용에는 태그를 지정할 수 있습니다(예: 아래 세금 거래에 #tax를 추가했습니다. 마찬가지로 특정 비용이 매달 발생하는 경우 #recurring으로 태그를 지정할 수 있음). 이 경우 계정 이름 자체(Software)가 명확하게 만듭니다.
• 계약자 지불: 2025-08-20에 프리랜서는 하청업체(Jane Doe)에 $2,000를 지불했습니다. 이것은 Expenses:Business:Contractors의 비용으로 기록되고 당좌 예금에서 현금이 나옵니다. 계약자의 이름을 내레이션에 포함하거나(수행한 대로) 메타데이터 필드(예: contractor: "Jane Doe")로 포함할 수 있습니다. 이렇게 하면 누구에게 왜 지불했는지에 대한 감사 추적을 유지할 수 있습니다(세금 신고 또는 예산 책정 중에 세부 정보가 필요한 경우 유용함).
• 세금 저축 이체: 2025-08-31에 프리랜서는 주 당좌 예금에서 전용 세금 저축 계정으로 $1,500를 이체합니다. 가시성을 위해 이 거래에 #tax로 태그를 지정했습니다. 이것은 비용이 아니므로(자신의 돈을 이체하는 것뿐임) 두 자산 계정 간에 이동합니다. 매달 또는 분기마다 이렇게 하면 예상 세금을 충당하기 위해 자금이 누적됩니다. 실제로 정부에 세금을 납부해야 할 때 비용(Expenses:Taxes라고 함)과 세금 저축(또는 당좌 예금)에서 공제를 기록합니다. 일반적인 함정은 이 이체를 보고서에서 비용으로 취급하는 것입니다. 비용이 아니라 예방 조치 할당임을 기억하세요. IRS/세무 당국에 대한 실제 세금 납부만이 비용(또는 발생하는 세금 부채의 감소)입니다(해당 방식으로 추적하는 경우).

요약: 프리랜서의 Beancount 원장은 단순성과 명확성을 강조합니다. 사업과 관련된 모든 수입과 지출은 체계적으로 기록됩니다. 의미 있는 계정 이름과 가끔 태그/메타데이터를 사용하면 고객별 또는 비용 범주별로 보고서를 쉽게 생성할 수 있습니다(예: 고객별 총 수입, 올해 계약자에게 지출한 총액 등). 이 설정은 확장 가능합니다. 사업이 발전함에 따라 새 고객 또는 비용 범주를 추가할 수 있습니다. 자동 가져오기(은행 거래를 가져오기 위해) 및 프로젝트 또는 송장에 대한 사용자 정의 태그 지정과 같은 기능을 사용하면 Beancount는 프리랜서의 회계 오버헤드를 크게 줄이면서 언제든지 재정에 대한 명확한 그림을 제공할 수 있습니다.

소규모 사업

다음으로 수제 상품을 판매하는 온라인 상점과 같은 소규모 부티크 전자 상거래 사업을 고려해 보겠습니다. 이 시나리오에서는 재고 관리, 매출 원가(COGS), 온라인 결제 처리업체 처리와 같은 복잡성이 추가됩니다. Beancount는 신중한 계정 구조와 거래 기록 방법으로 이러한 요구 사항을 충족할 수 있습니다. 이 사업체가 재고의 제품을 추적하고, 온라인 플랫폼(결제에 Stripe와 함께 Shopify와 같은)을 통해 판매를 기록하고, 일반적인 사업 비용을 기록하는 사례를 사용하겠습니다.

부티크 전자 상거래 사업을 위한 주요 계정: 기본 은행 및 비용 계정 외에도 소매 사업 원장에는 재고 및 판매 흐름을 추적하는 계정이 포함됩니다.

• 자산:은행:당좌예금 – 사업체의 당좌 예금 계정(공급업체, 운영 비용 지불, 결제 처리업체로부터 이체 수령).
• 자산:Stripe:잔액(또는 자산:PayPal 등) – 아직 은행에 입금되지 않은 온라인 결제를 통해 징수된 자금을 위한 정리 계정. 예를 들어 고객이 Stripe를 통해 지불하면 돈이 일괄적으로 은행에 입금되기 전에 Stripe 계정에 보관될 수 있습니다.
• 자산:재고:제품** – 제품에 대한 재고 계정. Beancount에서 각 제품(또는 제품 범주)을 상품으로 취급하여 수량을 추적할 수 있습니다. 예를 들어 자산:재고:위젯은 현재 재고에 있는 "위젯" 품목의 수량을 원가로 평가하여 보유할 수 있습니다.
• 수익:판매 – 제품 판매에서 발생한 수익을 기록합니다. 사업체가 여러 채널을 가지고 있는 경우 다른 판매 채널(예: 수익:판매:온라인 대 수익:판매:매장)에 대한 하위 계정을 사용할 수 있지만 하나의 판매 수익 계정으로 간단하게 유지합니다.
• 비용:COGS – 판매된 재고 품목의 원가를 캡처하기 위한 매출 원가. 이 계정은 효과적으로 판매된 재고가 일정 기간 동안 (사업주로서) 얼마나 들었는지 보여줍니다. 이것은 총 이익을 계산하기 위한 핵심 구성 요소입니다.
• 비용:수수료 – 결제 처리 수수료 및 플랫폼 수수료(Stripe 요금, Shopify 수수료, PayPal 수수료 등은 모두 여기에 기록할 수 있음). 원하는 경우 더 자세한 계정(예: 비용:수수료:Stripe 및 비용:수수료:Shopify)으로 분리할 수 있지만 하나의 계정으로 모든 거래 수수료를 충당할 수 있습니다.
• 비용:운영 – 마케팅, 웹 호스팅, 소프트웨어, 배송 용품 등과 같이 COGS와 직접 관련이 없는 일반적인 사업 비용. 이러한 비용은 다른 비용 센터를 분석하기 위해 하위 계정(예: 비용:마케팅, 비용:웹호스팅, 비용:배송)으로 나눌 수 있습니다.
• 부채:매출세 – (해당되는 경우 선택 사항) 사업체가 판매에 대한 매출세 또는 VAT를 징수해야 하는 경우 이 부채 계정은 징수되었지만 아직 정부에 납부되지 않은 세금을 추적합니다. 그런 다음 각 판매는 세금 부분을 이 계정으로 분할합니다. 이렇게 하면 징수된 세금이 수익으로 계산되지 않고 세무 당국에 대한 지불을 위해 책정됩니다.
• 자본:소유주자본 – (선택 사항) 소유주의 투자 및 유보 이익을 나타냅니다. 사업이 시작되었을 때 소유주의 초기 자금 조달은 여기에 대변됩니다(현금 또는 재고를 기부한 경우 은행 또는 재고에 대한 차변 포함). 또한 소유주가 이익을 가져가는 경우(분배), 해당 이익은 이 자본 계정에 대해 기록될 수 있습니다. 이렇게 하면 대차 대조표의 균형이 유지되지만 일상적인 운영에는 자주 사용되지 않습니다.

배경: 이 설정은 상품과 돈의 흐름을 분리합니다. 재고 구매는 즉시 비용으로 처리하기보다는 대차 대조표(자산으로)에 먼저 기록됩니다. 제품을 판매할 때만 해당 비용(COGS)을 비용으로 처리하여 적절한 이익 계산을 위해 수익을 관련 비용과 일치시킵니다. 판매에서 발생한 수익은 총 판매 가격으로 기록되는 반면 수수료는 별도로 기록되므로 총 수익과 지불된 수수료(따라서 순수익)를 모두 확인할 수 있습니다. 자산:Stripe:잔액과 같은 정리 계정을 사용하면 예금을 조정하는 데 도움이 됩니다. 돈은 Stripe에서 은행으로 일괄적으로 이동하며 혼란 없이 해당 이체를 기록할 수 있습니다. 신규 상점 소유자의 일반적인 함정은 재고를 적절하게 기록하는 것을 소홀히 하는 것입니다. 예를 들어 모든 재고 구매를 즉시 비용으로 처리합니다. 그것은 현금 흐름 추적에는 괜찮을 수 있지만 이익을 왜곡합니다. 재고를 비축하는 달에는 수익성이 낮아 보이고, 재고를 일찍 샀더라도 판매하는 달에는 수익성이 높아 보입니다. 재고 자산 계정과 COGS를 사용하면 비용을 판매와 일치시킬 수 있습니다. 또 다른 함정은 수수료 또는 환불을 설명하지 않는 것입니다. 그러면 은행 또는 Stripe 잔액이 기록된 수입과 일치하지 않을 수 있습니다. 수수료를 명시적으로 기록하고 Stripe 자산 계정을 사용하여 Stripe가 지불해야 하거나 지불한 금액을 추적함으로써 이를 방지합니다.

강조할 Beancount 기능: Beancount의 재고 추적 기능은 상품과 비용을 처리하는 기능을 활용합니다. 각 제품은 상품 기호(예: WIDGET)가 될 수 있으므로 수량과 단가를 모두 기록할 수 있습니다. 품목을 판매할 때 Beancount의 재고 논리(기본적으로 FIFO)는 재고 로트에서 올바른 비용을 자동으로 선택할 수 있습니다. 예제에서 이를 확인할 수 있습니다. 메타데이터 또는 링크를 사용하여 판매와 해당 COGS 항목을 연결할 수도 있습니다(예를 들어 두 거래에서 동일한 주문 번호를 사용하거나 판매 및 재고 감소에 #order1001과 같은 공유 태그를 사용하여 각 판매에 일치하는 COGS 항목이 있는지 쿼리하거나 다시 확인하기 쉽습니다). 또한 자동 가져오기가 여기에 도움이 될 수 있습니다. 스크립트를 사용하여 Shopify 또는 Stripe 지불 보고서에서 판매 데이터를 가져오거나 은행 명세서를 가져와 비용 거래 및 지불을 파악할 수 있습니다. 이러한 반복적인 데이터 입력 작업을 자동화하면 분석에 더 많은 시간을 할애하고 숫자를 입력하는 데 시간을 덜 소비할 수 있습니다.

소규모 사업 예제 원장 스니펫

다음은 부티크 전자 상거래 사업을 위한 축약된 Beancount 예제입니다. 재고 구매, 판매 기록(결제 처리업체 수수료가 차감됨), 해당 판매에 대한 매출 원가를 기록하는 것을 보여줍니다. 실제로 플랫폼 수수료, 광고 비용 등과 같은 다른 비용도 표시된 수수료 예제와 유사하게 기록합니다. USD를 통화로 가정하고 재고에서 상품으로 추적하는 "위젯"이라는 제품을 가정합니다.

1970-01-01 open Assets:Bank:Checking
1970-01-01 open Assets:Stripe:Balance
1970-01-01 open Assets:Inventory:Widgets WIDGET
1970-01-01 open Income:Sales
1970-01-01 open Expenses:COGS
1970-01-01 open Expenses:Fees

; 재고 구매(위젯 50개, 개당 원가 $10)
2025-03-10 * "SupplierCo에서 위젯 50개 구매"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD

; 고객에게 판매(온라인 상점을 통해 주문 #1001, 위젯 2개 판매)
2025-04-05 * "판매 주문 #1001(Shopify를 통해 위젯 2개)"
  Assets:Stripe:Balance         58 USD   ; 수수료 후 수령한 순 지불액
  Expenses:Fees                  2 USD   ; 처리 수수료(Stripe)
  Income:Sales                 -60 USD   ; 위젯 2개(@ 개당 $30)에 대한 수익

; 위의 판매에 대한 매출 원가(위젯 2개, 개당 원가 $10)
2025-04-05 * "주문 #1001에 대한 COGS(위젯 2개)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

단계별로 진행되는 내용은 다음과 같습니다.

• 계정 개설: 당좌 예금 계정, Stripe 잔액 계정, 위젯에 대한 재고 계정(단위 추적을 위해 상품 WIDGET로 선언됨), 핵심 수익 및 비용 계정(판매, COGS, 수수료)을 개설합니다. Assets:Inventory:Widgets WIDGET을 선언하면 이 계정이 상품 "WIDGET"의 수량을 보유한다는 신호를 보냅니다. 이렇게 하면 Beancount가 상품 단위를 예상하는 것을 알 수 있으며 해당 단위에 비용을 첨부할 수 있습니다.

• 재고 구매: 2025-03-10에 공급업체에서 위젯 50개를 개당 $10, 총 $500에 구매합니다. 이 거래는 Assets:Inventory:Widgets를 50 WIDGET {10 USD}로 차변합니다. 즉, 10 USD의 기록된 비용이 있는 상품 WIDGET 50개가 재고 계정에 추가됩니다. 대변은 Assets:Bank:Checking -500 USD입니다(현금 지출). 여기서 비용 계정을 직접 건드리지 않았습니다. 구매를 재고 자산으로 자본화하고 있습니다. 이제 대차 대조표에는 총 $500 상당의 위젯 50개가 재고에 있습니다. (잔액 보고서를 실행하면 재고 계정에 $500 상당의 위젯 단위 50개가 표시됩니다.)

• 판매 기록(주문 #1001): 2025-04-05에 온라인 상점을 통해 위젯 2개를 판매한 것을 기록합니다. 내레이션에는 명확성을 위해 주문 번호가 포함되어 있습니다. 이 거래에는 세 가지 게시물이 포함됩니다.

  • Assets:Stripe:Balance 58 USD: 판매에서 받은 돈이지만 현재 Stripe에 있습니다(수수료 제외). 고객이 총 $60를 지불했다고 가정합니다. Stripe는 $2 수수료를 받았고 $58가 현재 Stripe 계정에 있습니다(나중에 은행으로 이체됨). $58를 Stripe의 자산으로 기록합니다.
  • Expenses:Fees 2 USD: $2 수수료는 사업 비용으로 기록됩니다. 이렇게 하면 손익 계산서에 해당 비용이 반영되고 Stripe 자산과 수수료 비용이 함께 총 고객 지불액과 같아집니다.
  • Income:Sales -60 USD: 판매에서 $60의 수익을 기록합니다. (수익 계정은 대변으로 증가하므로 Beancount의 표기법에서는 음수 금액입니다).

  이 거래 후 순 효과는 다음과 같습니다. 수익:판매가 60 증가하고 추가 $58 자산(Stripe에서 받을 수 있음)과 수수료에 대한 $2 비용이 발생합니다. Stripe가 나중에 $58를 은행에 입금하면 Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USD와 같은 간단한 이체를 지불 날짜에 기록합니다. 이렇게 하면 자산이 Stripe 계정에서 은행으로 이동하고 수익 또는 비용에 영향을 미치지 않습니다(자산만 이동). 위에서 해당 이체를 보여주지는 않았지만 실제 회계에서는 모든 것이 이체되면 Stripe 계정을 $0로 유지하는 것이 중요한 단계입니다.

• 판매에 대한 COGS 기록: 2025-04-05에 판매된 위젯 2개의 비용을 기록하는 별도의 거래가 있습니다. Expenses:COGS 20 USD를 차변하고 Assets:Inventory:Widgets -2 WIDGET {10 USD}를 대변합니다. 이것은 재고에서 2단위를 제거합니다(각각은 이전에 기록된 대로 $10의 비용이 들었습니다. 따라서 총 $20). {10 USD}를 지정하여 Beancount에 어떤 비용 로트에서 가져올지 알려줍니다. 이 경우 2025-03-10에 추가한 로트와 일치합니다. 이제 재고 계정에 48개의 위젯이 남아 있고 관련 비용은 $480입니다. $20가 COGS 비용으로 이동하여 손익 계산서에 나타나 이러한 상품의 비용만큼 총 이익을 줄입니다. (이것을 기록하지 않으면 비용에 비해 수입이 과장됩니다.) 명확성을 위해 별도의 거래를 사용하지만 판매와 COGS를 하나의 여러 줄 거래로 결합할 수도 있습니다. 일부는 가독성과 조정을 위해 표시된 대로 분할하는 것을 선호합니다(각 COGS 항목을 주문에 명확하게 연결할 수 있음). 또한 이 COGS 항목이 주문 #1001에 해당하는 것을 쉽게 확인할 수 있도록 내레이션에서 주문 번호를 반복했습니다. 좋은 방법은 재고가 관련된 경우 모든 판매에 일치하는 COGS 항목이 있는지 확인하는 것입니다. 하나를 놓치면 재고 수가 잘못되었음을 의미합니다. 판매에 대한 재고 제거를 잊어버리는 것을 피해야 할 함정입니다. 그러면 대차 대조표에 유령 재고가 남고 비용이 과소 평가됩니다. Beancount의 재고 기능( {} 비용 표기법)을 사용하면 보유한 것보다 더 많은 단위를 제거하려고 시도하는 경우 파악하는 데 도움이 됩니다(소프트웨어에서 오류가 발생합니다).

요약: Beancount를 사용하는 소규모 사업체는 놀라울 정도로 강력한 회계 시스템을 유지 관리할 수 있습니다. 돈이 어디에 있는지, 어디에서 왔는지, 비용이 어떻게 흐르는지를 추적하기 위해 계정을 구성하면 수익성에 대한 정확한 그림을 얻을 수 있습니다. 예제에서는 재고 및 판매를 처리하는 방법을 보여주었습니다. 인터넷 요금 지불(Expenses:Operating:Internet 대 Assets:Bank:Checking), 대출 또는 투자 수령(Assets:Bank 대 Liabilities:Loan 또는 Equity:OwnerEquity) 또는 매출세 지불(Liabilities:SalesTax 대 Assets:Bank를 납부할 때)과 같은 다른 거래도 비슷하게 기록합니다. 핵심은 일관성입니다. 동일한 패턴으로 각 유형의 거래를 기록하면 Beancount는 장부를 균형 있게 유지합니다. 자동 데이터 가져오기(예: 월별 Stripe 수수료 또는 은행 거래 가져오기) 및 사용자 정의 태그/링크(판매 및 환불과 같은 관련 거래를 상호 연결하기 위해)와 같은 기능을 사용하면 시스템을 유연하고 효율적으로 만들 수 있습니다. 그 결과 사업이 성장함에 따라 확장될 수 있는 체계적인 원장이 만들어집니다. 전체 시스템을 재작업하지 않고도 새 제품 재고 계정, 새 비용 범주 또는 추가 수익원(예: 새 온라인 마켓플레이스)을 추가할 수 있습니다.

개인 금융

마지막으로 개인 또는 가계 재정에 Beancount를 사용하는 것을 고려해 보겠습니다. 이 설정은 일일 비용, 은행 계좌, 신용 카드, 대출 및 투자를 관리하는 개인 또는 가족을 위한 것입니다. 여기서 강조하는 것은 돈이 어디로 가는지(비용), 어디에서 오는지(수익), **저축 또는 투자되는 방식(자산 및 부채)**을 추적하는 것입니다. Beancount는 아무것도 이중으로 계산되거나 잊혀지지 않도록 복식 부기의 엄격함을 갖춘 투명하고 사용자 정의 가능한 재정 보기를 제공하여 예산 책정 앱을 대체하거나 보완할 수 있습니다.

개인 금융을 위한 주요 계정: 개인 금융 원장에는 일반적으로 다양한 자산, 부채, 수익 및 비용 계정이 포함됩니다.

• 자산:은행:당좌예금 – 수입 예금 및 청구서 지불을 위한 기본 당좌 예금 계정.
• 자산:은행:저축 – 비상 자금 또는 특정 목표를 위한 저축 계정. (여러 저축 또는 투자 계정이 있을 수 있으며 각 계정은 자산 계정이 될 수 있습니다.)
• 자산:현금 – 비용에 현금을 사용하는 경우 인출 및 현금 지출을 추적하기 위한 현금 계정을 보유할 수 있습니다.
• 자산:투자:브로커** – 중개, 퇴직 401(k)/IRA 등과 같은 투자 계정. 이러한 계정은 투자 유형별로 더 세분화하거나 기관별로 하나의 계정으로 일괄 처리할 수 있습니다. 예를 들어 자산:투자:VanguardIRA 또는 자산:투자:Robinhood가 있습니다. 투자 추적에는 주식 또는 펀드에 대한 상품이 포함될 수도 있지만 너무 자세한 경우 기여금과 계정 잔액만 추적하면 됩니다.
• 부채:신용카드:이름** – 신용 카드당 하나의 계정(예: 부채:신용카드:Visa 또는 은행 이름별). 카드에 대한 모든 구매는 여기에 기록되고(동등한 비용 포함) 카드에 대한 지불은 이 부채를 줄이는 이체입니다.
• 부채:대출:이름** – 모든 대출(학자금 대출, 주택 담보 대출, 자동차 대출)은 부채 계정으로 추적할 수 있습니다. 원금 잔액과 각 지불금을 이자(비용)와 원금(부채 감소)으로 분할하여 기록합니다. 이것은 고급 측면이지만 완전한 재정 상황을 위해서는 중요합니다.
• 수익:급여(및/또는 수익:보너스, 수익:이자 등) – 급여, 보너스, 이자 수입, 배당금 등을 기록합니다. 수익 계정을 사용하면 다양한 출처에서 총 수익을 확인할 수 있습니다. (급여에서 이미 세금이 공제된 경우 당좌 예금에 대한 순 예금을 수입으로 기록하거나 총액과 세금 원천 징수를 비용 또는 부채로 기록할 수 있습니다. 다른 접근 방식이 있지만 많은 사람들이 개인 장부에서 단순화를 위해 순 지불액을 수입으로 기록합니다.)
• 비용: 일반적으로 여러 개이며 자신에게 의미 있는 범주로 나뉩니다. 예를 들어 비용:주택:임대료, 비용:식품:식료품, 비용:식품:외식, 비용:유틸리티:전기, 비용:엔터테인먼트, 비용:여행, 비용:세금, 비용:기타 - 자신의 지출 습관을 반영하는 모든 범주. 원하는 만큼 세분화하거나 일반화할 수 있습니다. 계정 계층 구조는 집계에 도움이 됩니다(예: 비용:식품은 식료품과 외식을 모두 합산함). 일반적인 방법은 주요 그룹(주택, 식품, 교통, 의료 등)에 대한 계층 구조를 갖는 것입니다.
• 자본:시작-잔액 – 원장을 시작할 때 계정 잔액을 초기화하는 데 사용됩니다(모든 자산에서 부채를 뺀 값이 자본에 기록된 시작 순자산과 같도록 함). 시작한 후에는 누적 순이익을 나타내기 위해 자본:유보-이익 또는 이와 유사한 것을 사용할 수도 있습니다(개인 금융에서는 일반적으로 수입에서 지출을 뺀 금액이 순자산으로 굴러가도록 함). 자본 계정은 일상 생활에서 덜 눈에 띄지만 회계 방정식의 균형을 유지합니다.

배경: 개인 금융 설정은 재정 생활을 하나의 일관된 시스템으로 캡처하는 것입니다. 위의 각 계정은 "이번 달에 음식에 얼마나 썼습니까?"(비용:식품:* 합산), "남은 빚이 얼마나 됩니까?"(부채 계정 확인) 또는 "내 순자산은 얼마입니까?"(자산에서 부채를 뺀 값)와 같은 질문에 대답할 수 있도록 다양한 종류의 재정을 분리하는 데 사용됩니다. 여기서 복식 부기의 큰 장점은 정확성입니다. 예를 들어 신용 카드로 $100 식료품 청구서를 청구하면 비용 과 부채 증가로 기록합니다. 나중에 신용 카드를 지불할 때 은행에서 카드로 이체를 기록합니다. 이렇게 하면 부채가 줄어들지만 식료품 비용을 이중으로 계산하지 않습니다(이미 기록됨). 복식 부기가 없으면 신용 카드 지불을 비용 자체로 취급하여 효과적으로 $100를 두 번 계산하는 것이 일반적인 함정입니다. Beancount는 설계상 이를 방지합니다. 피해야 할 또 다른 함정은 계정 조정을 실패하는 것입니다. Beancount를 사용하면 잔액 어설션 또는 잔액 지시문을 사용하여 예를 들어 원장의 당좌 예금 잔액이 실제 은행 명세서와 일치하는지 확인할 수 있습니다. 이렇게 하면 누락되거나 중복된 항목을 파악할 수 있습니다.

강조할 Beancount 기능: 개인 금융의 경우 거래량이 많기 때문에 자동 가져오기가 특히 유용합니다. Beancount의 가져오기 프레임워크 또는 커뮤니티 스크립트를 사용하여 은행 거래, 신용 카드 명세서, 심지어 CSV, OFX 또는 API 소스에서 투자 거래를 가져올 수 있습니다. 즉, 매번 커피 구매를 수동으로 입력하는 데 시간을 덜 소비할 수 있습니다. 사용자 정의 태그는 계정에서 가능하지 않을 수 있는 방식으로 데이터를 조각하는 데 유용합니다. 예를 들어 항공편, 호텔 또는 식사에 관계없이 모든 휴가 관련 비용에 #vacation2025로 태그를 지정하면 해당 휴가의 총 비용을 쉽게 쿼리할 수 있습니다. 또는 나중에 참조할 수 있도록 세금 공제 항목을 추적해야 하는 경우 특정 비용에 #deductible로 태그를 지정합니다. 또한 모든 구독 및 고정 비용을 연간 검토하기 위해 반복되는 청구서(예: #monthly)에 태그를 지정할 수도 있습니다. 메타데이터를 사용하여 메모 또는 영수증을 첨부할 수 있습니다(예: 저장된 영수증 이미지가 있음을 나타내기 위해 영수증: "path/to/file.jpg" 또는 상환 가능한 항목을 추적하는 경우 범주: "업무 비용"). 태그 및 메타데이터의 유연성은 추가 계정을 수십 개 만들지 않고도 개인 추적 요구 사항에 맞게 시스템을 조정할 수 있음을 의미합니다.

개인 금융 예제 원장 스니펫

다음은 몇 가지 일반적인 거래를 캡처하는 개인 Beancount 원장의 예제 스니펫입니다. 신용 카드로 청구된 일일 비용, 당좌 예금에서 지불된 반복되는 청구서, 퇴직 투자 계정에 대한 기여금입니다. (간결성을 위해 계정을 개설하고 급여 수입을 기록하기 위해 초기 설정이 완료되었다고 가정합니다. 여기서는 지출 및 저축 측면에 중점을 둡니다.)

1970-01-01 open Assets:Bank:Checking
1970-01-