Налаштування планів рахунків Beancount за галузями

Приклади конфігурацій для фрилансерів, малого бізнесу та особистих фінансів

У цьому посібнику ми розглянемо, як адаптувати журнал Beancount під різні потреби: фрилансера-професіонала, невеликий бутиковий бізнес і особисті фінанси домогосподарства. Кожен сценарій має унікальну структуру рахунків і особливості. Ми пояснимо обґрунтування кожного налаштування, наведемо приклади фрагментів Beancount і висвітлимо корисні функції (як-от власні теги та автоматизований імпорт), які полегшують відстеження. Тон викладу — навчальний, але доступний: незалежно від того, чи ви розробник, технічно підкований професіонал або ентузіаст фінансів, ці приклади допоможуть вам застосувати Beancount у реальному світі.

Фрілансери​

Фрилансери (як-от розробники програмного забезпечення чи графічні дизайнери) часто балансують між кількома клієнтами та витратами на проєкти. Просте налаштування Beancount допоможе відстежувати дохід від кожного клієнта, бізнес-витрати (зокрема будь-яких найманих субпідрядників) і гроші, відкладені на податки. Мета — зберегти простоту, щоб система масштабувалася разом із зростанням вашого фриланс-бізнесу без зайвої складності.

Ключові рахунки для фрилансера: Журнал фрилансера зазвичай відокремлює бізнес-фінанси від особистих. Наприклад, ви можете використовувати:

• Assets:Business:Checking – Бізнес-банківський рахунок для всіх клієнтських платежів і бізнес-витрат.
• Assets:Business:TaxSavings – Ощадний рахунок для відкладання частини доходу на податкові платежі (оскільки жоден роботодавець не утримує податки за вас).
• Income:Client:Name – Рахунки доходу для клієнтських платежів. Ви можете створити субрахунки для кожного великого клієнта (наприклад, Income:Client:ACME) або використовувати один рахунок Income:Freelance з іменами клієнтів, позначеними тегами в транзакціях.
• Expenses:Business:Contractors – Для платежів будь-яким субпідрядникам або за аутсорсингову роботу.
• Expenses:Business:Software (та інші категорії, як-от Travel, Supplies) – Для регулярних бізнес-витрат (підписки на програмне забезпечення, обладнання, поїздки до клієнтів тощо).
• Equity:OwnerDraw – (Необов'язково) Для запису переказів прибутку від бізнесу собі особисто. Це допомагає відрізняти бізнес-кошти від особистих, коли ви виплачуєте собі зарплату.

Обґрунтування: Ця структура гарантує, що всі бізнес-гроші відстежуються на виділених рахунках. Дохід від кожного клієнта записується (що дозволяє легко побачити, хто ваші найбільші клієнти), а витрати категоризуються для відрахувань під час сплати податків. Відкладання податків на окремий рахунок активів (або запис зобов'язання з податків до сплати) запобігає випадковому витрачанню грошей, які належатимуть державі. Журнал залишається простим: якщо ви залучаєте нових клієнтів або категорії витрат, ви можете додати нові рахунки або використовувати теги, не перебудовуючи все. Поширена помилка — змішування особистих і бізнес-транзакцій на одному рахунку; підтримуючи виділений бізнес-рахунок (і відповідний рахунок активів), звірка та звітність стають чистішими. Ще одна помилка, якої слід уникати, — забути записати грошові перекази на податки або вилучення власника; використовуючи такі рахунки, як TaxSavings і OwnerDraw, кожен долар враховано.

Щоб запустити цю конфігурацію як розміщений журнал із доходом за клієнтами, дебіторською заборгованістю за рахунками-фактурами та податковим резервом, див. Beancount.io для фрилансерів.

Функції 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
 
; Client income – payment for an invoice
2025-08-15 * "Invoice payment from ACME Corp"
  invoice: "INV-2025-08-15"
  Assets:Business:Checking       5000 USD
  Income:Client:ACME           -5000 USD
 
; Regular expense – e.g. software subscription for the business
2025-08-05 * "GitHub Subscription"
  Expenses:Business:Software       15 USD
  Assets:Business:Checking        -15 USD
 
; Contractor expense – paying a subcontractor for help
2025-08-20 * "Contractor payment – Jane Doe"
  Expenses:Business:Contractors   2000 USD
  Assets:Business:Checking      -2000 USD
 
; Tax withholding – moving money to tax savings
2025-08-31 * "Set aside Q3 taxes" #tax
  Assets:Business:TaxSavings     1500 USD
  Assets:Business:Checking     -1500 USD

Розберімо, що відбувається:

• Ми відкриваємо необхідні рахунки вгорі (із датою початку). Beancount вимагає, щоб кожен рахунок було відкрито перед використанням — проведення на неоголошений рахунок є помилкою завантаження — тож ці директиви open обов'язкові, а не необов'язковий стиль. Рахунки Assets:Business:Checking і Assets:Business:TaxSavings зберігатимуть баланси в USD; рахунки доходу та витрат можна залишити без валюти в директиві open, оскільки вони успадкують валюти транзакцій (у цьому випадку USD).
• Оплата рахунку-фактури від клієнта: 2025-08-15 транзакція доходу фіксує клієнтський платіж у розмірі $5,000 за рахунком-фактурою. Ми кредитуємо Income:Client:ACME (дохід зростає з від'ємною сумою в подвійному записі) і дебетуємо поточний рахунок. Поле метаданих invoice: "INV-2025-08-15" додано для зазначення номера рахунку-фактури — це необов'язково, але показує, як можна прикріпити додаткову інформацію до транзакції. Ви також можете позначити цю транзакцію тегом #ACME або #client-ACME для швидкої фільтрації. Якби у вас було кілька клієнтів, ви могли б використовувати загальний рахунок Income:Clients і покладатися на такі метадані або поле Payee для розрізнення клієнтів замість створення багатьох субрахунків.
• Бізнес-витрата (програмне забезпечення): 2025-08-05 ми записуємо витрату в $15 за підписку GitHub (можливо, для приватних репозиторіїв чи інших послуг). Проведення йде на 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) і списання з рахунку TaxSavings (або Checking). Поширена помилка — вважати цей переказ витратою у звітах; пам'ятайте, це не витрата, а лише запобіжний розподіл. Лише фактична сплата податку до податкового органу буде витратою (або зменшенням нарахованого податкового зобов'язання, якщо ви відстежуєте його таким чином).

Підсумок: Журнал Beancount фрилансера наголошує на простоті та ясності. Усі доходи та відтоки, пов'язані з бізнесом, записуються методично. Використовуючи змістовні назви рахунків і час від часу теги/метадані, ви можете легко генерувати звіти за клієнтом чи категорією витрат (наприклад, загальний дохід на клієнта, загальні витрати на субпідрядників цього року тощо). Це налаштування масштабоване — ви можете додавати нових клієнтів чи категорії витрат у міру розвитку бізнесу. Завдяки таким функціям, як автоматизований імпорт (для завантаження банківських транзакцій) і власні теги для проєктів чи рахунків-фактур, Beancount може значно зменшити витрати часу на бухгалтерію для фрилансерів, водночас даючи чітку картину фінансів у будь-який момент.

Малий бізнес​

Далі розглянемо невеликий бутиковий бізнес електронної комерції — наприклад, інтернет-магазин, що продає вироби ручної роботи. Цей сценарій додає складності, як-от управління запасами, собівартість проданих товарів (COGS) та обробку онлайн-платіжних процесорів. Beancount може впоратися з цим завдяки продуманій структурі рахунків і методу запису транзакцій. Ми використаємо випадок, коли бізнес відстежує товари в запасах, записує продажі через онлайн-платформу (як-от Shopify зі Stripe для платежів) і фіксує типові бізнес-витрати.

Ключові рахунки для бутикового бізнесу електронної комерції: На додаток до базових банківських рахунків і рахунків витрат, журнал роздрібного бізнесу включатиме рахунки для відстеження запасів і потоків продажів:

• Assets:Bank:Checking – Поточний рахунок бізнесу (для оплати постачальникам, операційних витрат і отримання переказів від платіжних процесорів).
• Assets:Stripe:Balance (або Assets:PayPal тощо) – Кліринговий рахунок для коштів, зібраних через онлайн-платежі, які ще не надійшли на банківський рахунок. Наприклад, коли клієнт платить через Stripe, гроші можуть перебувати на рахунку Stripe, перш ніж бути зарахованими на ваш банківський рахунок пакетами.
• Assets:Inventory:Product – Рахунки запасів для ваших товарів. Ви можете трактувати кожен товар (або категорію товарів) як товар у Beancount для відстеження наявної кількості. Наприклад, Assets:Inventory:Widgets може зберігати кількість товарів "Widget", наявних на складі, оцінених за їхньою собівартістю.
• Income:Sales – Записує виторг від продажу товарів. Ви можете використовувати субрахунки для різних каналів продажу (наприклад, Income:Sales:Online проти Income:Sales:InStore), якби бізнес мав кілька каналів, але ми залишимо все простим з одним рахунком доходу від продажів.
• Expenses:COGS – Собівартість проданих товарів, для фіксації базової вартості товарів запасів, коли їх продано. Цей рахунок фактично показуватиме, скільки коштували вам (як власнику бізнесу) продані запаси за певний період. Це ключовий компонент для розрахунку валового прибутку.
• Expenses:Fees – Для комісій за обробку платежів і платформних зборів (комісії Stripe, Shopify, PayPal тощо можна записувати тут). За бажанням ви можете розділити це на детальніші рахунки (наприклад, Expenses:Fees:Stripe і Expenses:Fees:Shopify), але одного рахунку може бути достатньо для всіх комісій за транзакції.
• Expenses:Operating – Загальні бізнес-витрати, не пов'язані безпосередньо з COGS, як-от маркетинг, вебхостинг, програмне забезпечення, пакувальні матеріали тощо. Їх можна розбити на субрахунки (наприклад, Expenses:Marketing, Expenses:WebHosting, Expenses:Shipping) для аналізу різних центрів витрат.
• Liabilities:SalesTax – (Необов'язково, якщо застосовно) Якщо бізнес має збирати податок з продажів або ПДВ, цей рахунок зобов'язань відстежує зібрані, але ще не перераховані державі податки. Тоді кожен продаж відокремлюватиме податкову частину на цей рахунок. Це гарантує, що зібрані податки не враховуються як дохід і призначені для сплати податковим органам.
• Equity:OwnerEquity – (Необов'язково) Представляє інвестиції власника та нерозподілений прибуток. Коли бізнес було засновано, будь-яке початкове фінансування власника кредитувалося б тут (із дебетом на банк або запаси, якщо він вніс готівку чи запаси). Також, якщо власник вилучає прибуток (розподіли), це можна записати проти цього рахунку капіталу. Це зберігає баланс, але для щоденних операцій він рідко задіюється.

Обґрунтування: Це налаштування розмежовує потік товарів і грошей. Закупівлі запасів спочатку записуються в балансі (як активи), а не одразу як витрати. Лише коли ви продаєте товари, ви витрачаєте їхню собівартість (COGS), зіставляючи виторг із відповідною витратою для правильного розрахунку прибутку. Дохід від продажів записується за валовою ціною продажу, тоді як комісії записуються окремо, щоб ви бачили і валовий виторг, і сплачені комісії (а отже, чистий виторг). Використання клірингового рахунку, як-от Assets:Stripe:Balance, допомагає звіряти депозити — гроші надходять від Stripe на ваш банківський рахунок пакетами, і ви можете записувати ці перекази без плутанини. Поширена помилка нових власників магазинів — нехтувати належним записом запасів, наприклад, відносити всі закупівлі запасів одразу до витрат. Це може бути прийнятно для відстеження грошових потоків, але це викривлює ваш прибуток: ви виглядатимете менш прибутковими в місяці, коли робите запаси, і більш прибутковими в місяці, коли продаєте, хоча запаси було куплено раніше. Використовуючи рахунок активів запасів і COGS, ви зіставляєте витрату з продажем. Ще одна помилка — не враховувати комісії чи повернення коштів, що може призвести до розбіжності між балансами вашого банку чи Stripe і записаним доходом. Ми уникаємо цього, явно записуючи комісії та використовуючи рахунок активів Stripe для відстеження того, що Stripe заборгував або виплатив.

Щоб вести бухгалтерію малого бізнесу в хмарі, зі звітами, які може читати ваш бухгалтер, і реєстром, який ви можете експортувати будь-коли, дивіться Beancount.io для малого бізнесу.

Функції Beancount, на які варто звернути увагу: Відстеження запасів у Beancount використовує його здатність працювати з товарами та витратами. Кожен товар може бути символом товару (наприклад, WIDGET), що дозволяє записувати як кількість, так і собівартість одиниці. Коли ви продаєте товари, ви вказуєте, з якої партії собівартості ви списуєте, і Beancount бере з неї — див. методи обліку запасів для повного набору. Типовий метод проведення — STRICT, який вимагає, щоб партія була однозначною; саме тому приклад називає її явно через {10 USD}. Щоб Beancount автоматично вибирав партію (найстарішу першою), увімкніть для рахунку FIFO у його директиві open: open Assets:Inventory:Widgets WIDGET "FIFO". У прикладі ми використаємо явну форму STRICT. Ви також можете використовувати метадані або посилання для зв'язування продажів та їхніх відповідних записів COGS (наприклад, використовуючи той самий номер замовлення в обох транзакціях або спільний тег, як-от #order1001, на продажі та зменшенні запасів, що полегшує запит або перевірку того, що кожен продаж має відповідний запис COGS). Крім того, тут можуть допомогти автоматизовані імпорти: ви можете використати скрипт для імпорту даних про продажі з Shopify чи звітів про виплати Stripe або імпортувати банківські виписки для фіксації транзакцій витрат і виплат. Автоматизація цих повторюваних завдань введення даних означає, що ви витрачаєте більше часу на аналіз і менше на введення цифр.

Приклад фрагмента журналу малого бізнесу​

Нижче наведено стислий приклад Beancount для нашого бутикового бізнесу електронної комерції. Ми ілюструємо закупівлю запасів, запис продажу (з вирахуванням комісії платіжного процесора) та запис собівартості проданих товарів для цього продажу. На практиці ви так само записували б інші витрати (як-от платформні збори, витрати на рекламу тощо), подібно до наведеного прикладу з комісією. Ми припускаємо USD як валюту та товар під назвою "Widget", який ми відстежуємо як товар у запасах.

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
 
; Purchase inventory (50 units of Widget at $10 cost each)
2025-03-10 * "Bought 50 Widgets from SupplierCo"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD
 
; Sale to customer (Order #1001 via online store, 2 Widgets sold)
2025-04-05 * "Sale Order #1001 (2x Widget via Shopify)"
  Assets:Stripe:Balance         58 USD   ; net payment received after fees
  Expenses:Fees                  2 USD   ; processing fee (Stripe)
  Income:Sales                 -60 USD   ; revenue for 2 Widgets (@ $30 each)
 
; Cost of goods sold for the above sale (2 Widgets at $10 cost each)
2025-04-05 * "COGS for Order #1001 (2x Widget)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

Ось що відбувається крок за кроком:

• Відкриття рахунків: Ми відкриваємо поточний рахунок, рахунок балансу Stripe, рахунок запасів для Widgets (оголошений із товаром WIDGET для відстеження одиниць) та основні рахунки доходу й витрат (Sales, COGS, Fees). Оголошуючи Assets:Inventory:Widgets WIDGET, ми сигналізуємо, що цей рахунок зберігатиме кількості товару "WIDGET". Це гарантує, що Beancount знатиме, що тут очікуються одиниці товару, і ми можемо прикріпити собівартість до цих одиниць.

• Закупівля запасів: 2025-03-10 ми купуємо запаси — 50 одиниць Widget від постачальника по $10 кожна, загальною вартістю $500. Транзакція дебетує Assets:Inventory:Widgets на 50 WIDGET {10 USD}. Це означає, що 50 одиниць товару WIDGET, кожна із записаною собівартістю 10 USD, додаються до рахунку запасів. Кредит — Assets:Bank:Checking -500 USD (вибуття готівки). Зверніть увагу, ми не торкалися безпосередньо рахунку витрат; ми капіталізуємо закупівлю як актив запасів. Тепер у нашому балансі є 50 Widgets загальною вартістю $500 у запасах. (Якби ви запустили звіт про баланс, рахунок Inventory показував би 50 одиниць WIDGET вартістю $500.)

• Запис продажу (Замовлення #1001): 2025-04-05 ми записуємо продаж 2 Widgets через наш інтернет-магазин. Опис включає номер замовлення для ясності. Ця транзакція включає три проведення:

  • 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).

  Після цієї транзакції чистий ефект такий: Income:Sales зростає на 60, додатковий актив $58 (до отримання від Stripe) і витрата $2 на комісію. Якщо згодом Stripe зарахує $58 на наш банківський рахунок, ми запишемо простий переказ, як-от Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USD, на дату виплати — це переміщує актив із рахунку Stripe на банківський рахунок без впливу на дохід чи витрати (лише переміщення активів). Ми не показали цей переказ вище, але це важливий крок у реальній бухгалтерії, щоб тримати ваш рахунок Stripe на $0, коли все переказано.

• Запис COGS для продажу: Також 2025-04-05 у нас є окрема транзакція для запису собівартості 2 проданих Widgets. Ми дебетуємо Expenses:COGS 20 USD і кредитуємо Assets:Inventory:Widgets -2 WIDGET {10 USD}. Це вилучає 2 одиниці з запасів (кожна мала собівартість $10, як записано раніше, тож $20 загалом). Ми вказуємо {10 USD}, щоб сказати Beancount, з якої партії собівартості списувати — у цьому випадку вона збігається з партією, доданою 2025-03-10. Тепер рахунок запасів матиме 48 Widgets, що залишилися, і пов'язану собівартість $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 може замінити або доповнити застосунки для бюджетування, забезпечуючи прозорий і настроюваний погляд на ваші фінанси з точністю подвійного запису, який гарантує, що нічого не подвоєно чи забуто.

Ключові рахунки для особистих фінансів: Журнал особистих фінансів зазвичай включатиме різноманітні рахунки активів, зобов'язань, доходу та витрат:

• Assets:Bank:Checking – Ваш основний поточний рахунок для зарахування доходу та оплати рахунків.
• Assets:Bank:Savings – Ощадний рахунок для резервного фонду чи конкретних цілей. (У вас може бути кілька ощадних чи інвестиційних рахунків — кожен може бути рахунком активів).
• Assets:Cash – Якщо ви використовуєте готівку для витрат, у вас може бути готівковий рахунок для відстеження зняття та витрачання готівки.
• Assets:Investments:Broker – Інвестиційні рахунки, як-от брокерський, пенсійний 401(k)/IRA тощо. Вони можуть далі розбиватися за типами інвестицій або просто зводитися в один рахунок на установу. Наприклад, Assets:Investments:VanguardIRA або Assets:Investments:Robinhood. Відстеження інвестицій може також включати товари для акцій чи фондів, але якщо це занадто детально, ви можете просто відстежувати внески та баланси рахунків.
• Liabilities:CreditCard:Name – Один рахунок на кожну кредитну картку (наприклад, Liabilities:CreditCard:Visa або за назвою банку). Усі покупки на картку записуються тут (з рівною витратою), а платежі на картку — це перекази, що зменшують це зобов'язання.
• Liabilities:Loan:Name – Будь-які позики (студентська, іпотека, автопозика) можна відстежувати за допомогою рахунку зобов'язань. Ви записували б основний баланс і кожен платіж, розділяючи відсотки (витрата) та основний борг (зменшення зобов'язання). Це просунутий аспект, але важливий для повної фінансової картини.
• Income:Salary (та/або Income:Bonus, Income:Interest тощо) – Для запису зарплат, бонусів, доходу від відсотків, дивідендів тощо. Рахунки доходу дозволяють бачити ваш загальний заробіток із різних джерел. (Якщо з вашої зарплати вже утримано податки, ви можете записати чистий депозит на поточний рахунок як дохід або записати валову суму та податкові утримання як витрату чи зобов'язання — існують різні підходи, але багато хто для простоти в особистих книгах записує чисту зарплату як дохід.)
• Expenses: Зазвичай численні, розділені на категорії, значущі для вас. Наприклад: Expenses:Housing:Rent, Expenses:Food:Groceries, Expenses:Food:DiningOut, Expenses:Utilities:Electricity, Expenses:Entertainment, Expenses:Travel, Expenses:Taxes, Expenses:Misc — будь-які категорії, що відображають ваші звички витрачання. Ви можете бути настільки детальними чи загальними, як забажаєте. Ієрархія рахунків допомагає агрегувати (наприклад, Expenses:Food підсумує і продукти, і харчування поза домом). Поширена практика — мати ієрархію для великих груп (Housing, Food, Transportation, Healthcare тощо).
• Equity:Opening-Balances – Використовується для ініціалізації балансів рахунків на початку ведення журналу (щоб усі активи мінус зобов'язання дорівнювали вашому початковому чистому капіталу, записаному в капіталі). Після початку ви також можете використовувати Equity:Retained-Earnings чи подібне для представлення накопиченого чистого прибутку (хоча в особистих фінансах ви зазвичай просто дозволяєте доходу мінус витратам переходити в чистий капітал). Рахунки капіталу менш помітні в щоденному використанні, але забезпечують баланс бухгалтерського рівняння.

Обґрунтування: Налаштування особистих фінансів полягає у фіксації вашого фінансового життя в одній цілісній системі. Кожен рахунок вище слугує відокремленню різних видів фінансів, щоб ви могли відповідати на запитання, як-от "Скільки я витратив на їжу цього місяця?" (підсумовуючи Expenses:Food:*), "Скільки боргу в мене залишилося?" (дивлячись на рахунки зобов'язань) чи "Який мій чистий капітал?" (активи мінус зобов'язання). Велика перевага подвійного запису тут — точність: наприклад, коли ви списуєте $100 за продукти на кредитну картку, ви записуєте це як витрату і збільшення зобов'язання. Згодом, коли ви сплачуєте кредитну картку, ви записуєте переказ із банку на картку — це погашає зобов'язання, але не подвоює витрату на продукти (яку вже було записано). Поширена помилка без подвійного запису — вважати платіж за кредитною карткою самою витратою, фактично рахуючи $100 двічі. Beancount запобігає цьому за своєю конструкцією. Ще одна помилка, якої слід уникати, — не звіряти рахунки: з Beancount ви можете використовувати перевірки балансу або директиву balance, щоб переконатися, наприклад, що баланс вашого поточного рахунку в журналі збігається з фактичною банківською випискою. Це виявляє пропущені чи дубльовані записи.

Функції Beancount, на які варто звернути увагу: Для особистих фінансів автоматизовані імпорти особливо корисні через обсяг транзакцій. Ви можете використовувати фреймворк імпортерів Beancount або скрипти спільноти для імпорту банківських транзакцій, виписок з кредитних карток і навіть інвестиційних транзакцій із CSV, OFX чи джерел API. Це означає, що ви витрачаєте менше часу на ручне введення кожної покупки кави. Власні теги корисні для розбиття даних у спосіб, який рахунки можуть не забезпечити. Наприклад, позначте всі витрати, пов'язані з відпусткою, тегом #vacation2025 незалежно від того, чи це авіаквитки, готелі чи харчування — тоді ви можете легко запитати загальну вартість тієї відпустки. Або позначте певні витрати як #deductible, якщо вам потрібно відстежувати статті, що підлягають податковому відрахуванню, для подальшого використання. Ви також можете позначати повторювані рахунки (наприклад, #monthly) для щорічного перегляду всіх ваших підписок і фіксованих витрат. Метадані можна використовувати для прикріплення нотаток чи квитанцій (наприклад, receipt: "path/to/file.jpg", щоб зазначити, що ви маєте збережене зображення квитанції, або category: "Work Expense", якщо відстежуєте статті, що підлягають відшкодуванню). Гнучкість тегів і метаданих означає, що ви можете адаптувати систему до своїх потреб особистого відстеження без створення десятків додаткових рахунків.

Приклад фрагмента журналу особистих фінансів​

Нижче наведено приклад фрагмента особистого журналу Beancount, що фіксує кілька типових транзакцій: щоденну витрату, списану на кредитну картку, повторюваний рахунок, сплачений з поточного рахунку, і внесок на інвестиційний пенсійний рахунок. (Для стислості ми припускаємо, що початкове налаштування вже виконано для відкриття рахунків і запису будь-якого доходу від зарплати; тут ми зосереджуємося на стороні витрат і заощаджень.)

1970-01-01 open Assets:Bank:Checking
1970-01-01 open Liabilities:CreditCard:Visa
1970-01-01 open Expenses:Food:Coffee
1970-01-01 open Expenses:Housing:Rent
1970-01-01 open Assets:Investment:401k
 
; Daily spending example (coffee on a credit card)
2025-09-10 * "Starbucks Coffee" #daily
  Expenses:Food:Coffee       5.50 USD
  Liabilities:CreditCard:Visa   -5.50 USD
 
; Recurring monthly bill (rent paid from checking)
2025-09-01 * "Apartment Rent September" #recurring
  Expenses:Housing:Rent    1200 USD
  Assets:Bank:Checking    -1200 USD
 
; Retirement contribution (transfer from checking to 401k investment)
2025-09-15 * "401(k) Contribution" #retirement
  Assets:Investment:401k    500 USD
  Assets:Bank:Checking     -500 USD

Розтлумачмо ці транзакції:

• Відкриття рахунків: Ми відкриваємо поточний рахунок, рахунок кредитної картки Visa, рахунок витрат на каву (як приклад підкатегорії витрат на їжу), рахунок витрат на оренду та інвестиційний рахунок 401k. У реальному журналі ви відкрили б усі рахунки, які плануєте використовувати (ощадні, інші категорії витрат, дохід тощо). Ми обмежуємося лише необхідним для цього фрагмента.
• Щоденна витрата — кава: 2025-09-10 записується покупка кави за $5.50. Витрата категоризується як Expenses:Food:Coffee, і оскільки її було сплачено кредитною карткою Visa, ми кредитуємо (збільшуємо) Liabilities:CreditCard:Visa. Тег #daily додано, щоб позначити, що це була щоденна стаття витрат — можливо, згодом ви захочете відфільтрувати всі щоденні дискреційні витрати. Зверніть увагу, що після цього рахунок кредитної картки показуватиме баланс $5.50 (тобто ви винні Visa $5.50). Якби ви сплатили готівкою за цю каву, транзакція натомість кредитувала б Assets:Cash (зменшуючи наявну у вас готівку). Якби це була покупка дебетовою карткою, вона кредитувала б Assets:Bank:Checking. Механіка подібна, лише різні рахунки.
• Повторюваний рахунок — оренда: 2025-09-01 ми записуємо сплату щомісячної оренди в $1200. Це виходить із поточного рахунку (кредитуючи Assets:Bank:Checking) і категоризується як Expenses:Housing:Rent. Ми позначили це тегом #recurring, щоб зазначити, що це повторюваний рахунок. У повному журналі у вас, ймовірно, був би такий самий запис щомісяця. (Beancount не має вбудованої функції автоматичних повторюваних транзакцій, але ви могли б досягти цього за допомогою скриптів або просто копіювати-вставляти щомісяця. Теги допомагають згодом переконатися, що ви не пропустили місяць, або швидко підсумувати річну оренду.) Деякі користувачі використовують функцію періодичних транзакцій через фреймворк імпортерів Beancount для автоматичної генерації цих записів, але це просунуте використання поза межами цього матеріалу. Головне, що ця транзакція чітко показує, куди пішли ваші гроші — витрата на житло — і ваш зменшений банківський баланс. Помилка, на яку варто зважати: якщо ви ділите витрати або маєте сусідів по квартирі, ви можете сплачувати лише частину оренди; у такому разі ви могли б розділити транзакцію на вашу частину та частину, яку сплачує хтось інший (можливо, записуючи іншу частину як Income:Reimbursements, якщо вони платять вам). У нашому простому випадку ми сплачуємо повну суму.
• Пенсійний внесок: 2025-09-15 $500 переміщується з поточного рахунку на інвестиційний рахунок 401(k). Це не витрата, а радше переказ активів з однієї форми (готівка) в іншу (пенсійний фонд). Транзакція дебетує Assets:Investment:401k і кредитує Assets:Bank:Checking. Ми позначили її тегом #retirement для ясності. Після цього баланс вашого поточного рахунку зменшиться на 500, а баланс рахунку 401k у журналі збільшиться на суму, яку представляють $500 (залежно від того, як ви відстежуєте інвестиції, ви можете згодом купити паї пайового фонду за цю готівку — це буде ще одна транзакція на інвестиційному рахунку, наприклад, купівля X паїв фонду за ціною Y, з вибуттям готівки з активу 401k). У базовому особистому журналі ви можете просто трактувати 401k як ощадний рахунок і періодично оновлювати його баланс або записувати внески, як тут, і, можливо, використовувати котирування цін для зростання. Важливо те, що ця транзакція є переказом, а не витратою — вона нарощує ваші активи. Багато інструментів бюджетування рахували б пенсійні внески як "витрати" (оскільки вони залишають ваш поточний рахунок), але в бухгалтерських термінах це просто переміщення грошей до іншої кишені. Це розрізнення допомагає вам зрозуміти норму заощаджень проти витрат.

Для інвестицій, записаних як одиниці підтримуваних цінних паперів, Live Prices можуть підтримувати котирування оцінки в розміщеному журналі. Пенсійний баланс, що складається лише з готівки, не може отримувати ринкові вартості цінних паперів із потоку даних; записуйте фактичні holdings і зберігайте їхні витрати на придбання явними.

Якби у нас була транзакція для сплати рахунку за кредитною карткою, вона виглядала б як переказ грошей із поточного рахунку на зобов'язання CreditCard (наприклад, Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD). Це повернуло б баланс кредитної картки назад (можливо, до нуля, якщо ви сплатили повністю) і відповідно зменшило б ваш банківський баланс без впливу на рахунки витрат — оскільки ви вже записали витрати під час покупки. Пам'ятати про такий підхід до кредитних карток критично важливо для точного відстеження особистих фінансів. Ви також можете позначити платіж тегом (деякі використовують #cc-payment чи подібне) або включити період виписки в опис для ясності.

Підсумок: Журнал особистих фінансів у Beancount допомагає навести дисципліну та структуру у відстеженні ваших грошей. Категоризуючи транзакції за рахунками (і, за бажанням, тегами), ви можете створювати змістовні звіти: щомісячні витрати за категоріями, річні підсумки, скільки ви заощадили тощо. Підхід подвійного запису означає, що кожен долар враховано: якщо баланс рахунку зменшується, він кудись пішов (інший рахунок зростає). Це виявляє помилки та запобігає поширеній проблемі "зниклих грошей" у простіших інструментах відстеження. Завдяки автоматизації ви можете імпортувати більшість транзакцій, а потім просто переглядати й класифікувати їх, що робить обслуговування цілком здійсненним. З часом ви будуєте вичерпний фінансовий щоденник — він навіть може впоратися з такими речами, як поділ рахунків із друзями (використовуючи рахунки капіталу або рахунки до сплати/до отримання), відстеження амортизації позики чи ефективності інвестицій, якщо ви вирішите розширитися в ці сфери. Навіть у найпростішому вигляді (як показано у фрагменті) Beancount дає вам ясність щодо щоденних витрат, повторюваних зобов'язань і прогресу до довгострокових цілей (як-от пенсійні заощадження). А оскільки це звичайний текст, ви маєте повний контроль: ви можете писати скрипти, робити запити чи інтегрувати його з іншими інструментами (як-от вебінтерфейс Fava для зручного перегляду). Коротко кажучи, це налаштування перетворює ваші особисті фінанси на дані, які ви можете аналізувати й яким можете довіряти, залишаючись достатньо простим, щоб не бути тягарем.

Адаптуючи свій журнал Beancount до вашої ситуації — чи то фриланс, чи малий бізнес, чи управління особистими коштами — ви отримуєте перевагу системного подвійного запису для відстеження фінансів із гнучкістю системи на основі звичайного тексту. Ці приклади конфігурацій демонструють основні шаблони, на яких ви можете будувати. У міру зростання бізнесу чи ускладнення фінансового життя ви можете розширювати план рахунків або використовувати просунуті функції (як-от бюджети, аналіз відхилень чи обробку кількох валют) за потреби. Головне — почати з чистої, логічної структури (як-от показані) та послідовно записувати транзакції. Маючи це на місці, Beancount стане потужним союзником у розумінні та управлінні вашими фінансами, у різних галузях і особистих сценаріях. Успішного обліку!