Перейти до основного вмісту

Налаштування для різних галузей

Налаштуйте свій журнал Beancount відповідно до унікальних потреб фрілансерів, малого бізнесу та особистих фінансів. Цей посібник містить практичні налаштування, приклади фрагментів коду та поради щодо ефективного фінансового обліку.

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

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

Фрілансери​

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

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

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

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

Функції 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 фрілансер заплатив субпідряднику (Джейн Доу) $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:Товар — Рахунки запасів для ваших товарів. Ви можете розглядати кожен товар (або категорію товарів) як товар (commodity) у 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, які варто виділити: Відстеження запасів у 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 у запасах. (Якщо ви запустите звіт про баланс, рахунок Запаси покаже 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 на нулі після переказу всіх коштів.

  • Фіксація 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:Брокер — Інвестиційні рахунки, такі як брокерський, пенсійний 401(k)/IRA тощо. Вони можуть бути розбиті за типами інвестицій або об’єднані в один рахунок на установу. Наприклад, Assets:Investments:VanguardIRA або Assets:Investments:Robinhood. Відстеження інвестицій також може включати товари для акцій або фондів, але якщо це надто детально, ви можете просто відстежувати внески та баланси рахунків.
  • Liabilities:CreditCard:Назва — Один рахунок для кожної кредитної картки (наприклад, Liabilities:CreditCard:Visa або за назвою банку). Усі покупки за карткою фіксуються тут (з відповідною витратою), а платежі за карткою є переказами, які зменшують це зобов’язання.
  • Liabilities:Loan:Назва — Будь-які кредити (студентський, іпотека, автокредит) можна відстежувати за допомогою рахунку зобов’язань. Ви записували б залишок основної суми та кожен платіж, розділяючи відсотки (витрати) та основну суму (зменшення зобов’язання). Це складніший аспект, але важливий для повної фінансової картини.
  • 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 підсумує і продукти, і ресторани). Поширена практика — мати ієрархію для основних груп (Житло, Їжа, Транспорт, Охорона здоров’я тощо).
  • Equity:Opening-Balances — Використовується для ініціалізації балансів рахунків, коли ви починаєте журнал (щоб усі активи мінус зобов’язання дорівнювали початковому власному капіталу, записаному в equity). Після початку ви також можете використовувати Equity:Retained-Earnings або подібний для представлення накопиченого чистого прибутку (хоча в особистих фінансах зазвичай просто дозволяєте доходу мінус витрати переходити у власний капітал). Рахунки власного капіталу менш помітні в повсякденному житті, але забезпечують баланс бухгалтерського рівняння.

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

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

Спробуйте конвертер перед написанням імпортера

Пропустіть експорт банку за минулий місяць через конвертер CSV у Beancount або завантаження .ofx, .qfx чи .qif через OFX та QIF у Beancount. Для більшості особистих журналів цього достатньо, і це показує вам форму запису, яку мав би створювати індивідуальний імпортер.

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

Нижче наведено приклад фрагмента особистого журналу 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 (тобто ви винні $5.50 Visa). Якби ви заплатили за цю каву готівкою, транзакція замість цього кредитувала б 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 USD (залежно від того, як ви відстежуєте інвестиції, ви можете згодом купити одиниці взаємного фонду за цю готівку — це буде ще одна транзакція на інвестиційному рахунку, наприклад, купівля X акцій фонду за ціною Y, з відтоком готівки з активу 401k). У базовому особистому журналі ви можете просто розглядати 401k як ощадний рахунок і періодично оновлювати його баланс або записувати внески таким чином і, можливо, використовувати котирування цін для зростання. Важливо, що ця транзакція є переказом, а не витратою — це нарощування ваших активів. Багато інструментів бюджетування рахували б пенсійні внески як "витрати" (оскільки вони залишають ваш поточний рахунок), але в бухгалтерському сенсі це просто переміщення грошей в іншу кишеню. Ця відмінність допомагає зрозуміти норму заощаджень проти витрат.

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

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

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

Налаштування для різних галузей

Джерело: https://beancount.io/uk/docs/industry-specific-setups