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

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

У цьому посібнику ми розглянемо, як адаптувати леджер 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, які слід виділити: Теги та метадані надзвичайно корисні для фрілансерів. Наприклад, ви можете позначати транзакції номером проєкту або рахунку-фактури або використовувати поле метаданих, щоб зазначити ім'я клієнта, якщо ви вирішите не використовувати окремі рахунки доходів для кожного клієнта. Це полегшує фільтрування або запит транзакцій для конкретного клієнта або проєкту (наприклад, підсумовування всіх витрат, позначених #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; рахунки доходів і витрат можна залишити без валюти у директиві 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). Поширена помилка – розглядати цей переказ як витрату у ваших звітах – пам’ятайте, це не витрата, а лише запобіжний розподіл. Лише фактична сплата податку IRS/податковому органу буде витратою (або зменшенням нарахованого податкового зобов’язання, якщо ви відстежуєте його таким чином).

Підсумок: Леджер 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, які слід виділити: Відстеження запасів у Beancount використовує його здатність обробляти товари та витрати. Кожен продукт може бути символом товару (наприклад, WIDGET), що дозволяє записувати як кількість, так і собівартість одиниці. Коли ви продаєте товари, логіка інвентаризації Beancount (FIFO за замовчуванням) може автоматично вибрати правильну вартість із ваших партій інвентаризації. Ми побачимо це в прикладі. Ви також можете використовувати метадані або посилання, щоб пов’язати продажі та відповідні записи 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

; Придбання запасів (50 одиниць Widget за ціною $10 кожна)
2025-03-10 * "Куплено 50 віджетів у SupplierCo"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD

; Продаж клієнту (Замовлення №1001 через інтернет-магазин, продано 2 віджети)
2025-04-05 * "Продаж Замовлення №1001 (2x Widget через Shopify)"
  Assets:Stripe:Balance         58 USD   ; чиста сума, отримана після сплати комісій
  Expenses:Fees                  2 USD   ; комісія за обробку (Stripe)
  Income:Sales                 -60 USD   ; дохід за 2 віджети (@ $30 кожен)

; Собівартість проданих товарів для вищезазначеного продажу (2 віджети за ціною $10 кожна)
2025-04-05 * "COGS для Замовлення №1001 (2x Widget)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

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

• Відкриття рахунків: Ми відкриваємо розрахунковий рахунок, рахунок балансу Stripe, рахунок запасів для віджетів (задекларований з товаром WIDGET для відстеження одиниць) і основні рахунки доходів і витрат (Продажі, COGS, Комісії). Заявляючи 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 віджетів вартістю $500 загалом у запасах. (Якщо ви запустите звіт про баланс, рахунок запасів покаже 50 одиниць WIDGET вартістю $500.)

• Запис продажу (Замовлення №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 може замінити або розширити програми для складання бюджету, надаючи прозорий і настроюваний огляд ваших фінансів, а суворість подвійного бухгалтерського обліку гарантує, що ніщо не буде підраховано двічі або забуто.

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

• Assets:Bank:Checking – Ваш основний розрахунковий рахунок для внесення доходів і оплати рахунків.
• Assets:Bank:Savings – Ощадний рахунок для надзвичайного фонду або конкретних цілей. (У вас може бути кілька ощадних або інвестиційних рахунків – кожен з них може бути рахунком активів).
• Assets:Cash – Якщо ви використовуєте готівку для витрат, ви можете мати рахунок готівки для відстеження зняття та витрат готівки.
• Assets:Investments:Broker** – Інвестиційні рахунки, такі як брокерський рахунок, пенсійний 401(k)/IRA тощо. Вони можуть бути далі розбиті за типами інвестицій або просто об'єднані як один рахунок на установу. Наприклад, Assets:Investments:VanguardIRA або Assets:Investments:Robinhood. Відстеження інвестицій може також включати товари для акцій або фондів, але якщо це занадто детально, ви