Специфични настройки за различни индустрии

Примерни конфигурации за фрийлансъри, малки бизнеси и лични финанси

В това ръководство ще разгледаме как да адаптирате 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 * "Плащане към подизпълнител – Джейн Доу"
  Expenses:Business:Contractors   2000 USD
  Assets:Business:Checking      -2000 USD

; Заделяне на данъци – преместване на пари към данъчни спестявания
2025-08-31 * "Заделяне на данъци за Q3"
  Assets:Business:TaxSavings     1500 USD
  Assets:Business:Checking     -1500 USD  #tax

Нека разгледаме какво се случва:

• Отваряме (open) необходимите сметки в началото (с начална дата). Това не е строго задължително за Beancount (сметките се създават при първата употреба, ако не са отворени), но е добра практика да бъдат декларирани. Сметките Assets:Business:Checking и Assets:Business:TaxSavings ще държат наличности в USD; приходните и разходните сметки могат да бъдат оставени без валута в директивата open, тъй като те ще наследят валутите на транзакциите (USD в този случай).
• Плащане на фактура от клиент: На 2025-08-15 приходна транзакция записва клиентско плащане от 5000 долара по фактура. Кредитираме 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 фрийлансърът е платил на подизпълнител (Джейн Доу) 2000 долара. Това е регистрирано като разход в Expenses:Business:Contractors и изходящи пари от разплащателната сметка. Можете да включите името на подизпълнителя в описанието (както направихме ние) или като поле за метаданни (напр. contractor: "Jane Doe"). Това поддържа одитна пътека на това на кого сте платили и защо (полезно, ако се нуждаете от подробности по време на подаване на данъчни декларации или бюджетиране).
• Трансфер за данъчни спестявания: На 2025-08-31 фрийлансърът превежда 1500 долара от основната разплащателна сметка към специализирана сметка за данъчни спестявания. Маркирали сме тази транзакция с #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, които да подчертаем: Проследяването на инвентара в Beancount се възползва от способността му да работи със стоки и себестойност. Всеки продукт може да бъде символ на стока (напр. WIDGET), което ви позволява да записвате както количеството, така и единичната цена. Когато продавате артикули, логиката за инвентар на Beancount (FIFO по подразбиране) може автоматично да избере правилната цена от вашите партиди инвентар. Ще видим това в примера. Можете също да използвате метаданни или връзки, за да свържете продажбите и съответните записи на COGS (например чрез използване на един и същ номер на поръчка в двете трансакции или споделен таг като #order1001 за продажбата и намаляването на инвентара, което улеснява справките или проверката дали всяка продажба има съответстващ запис за себестойност). Освен това автоматизираният импорт може да помогне тук: можете да използвате скрипт за импортиране на данни за продажбите от Shopify или отчети за плащания от Stripe или да импортирате банковите си извлечения, за да уловите трансакциите за разходи и плащанията. Автоматизирането на тези повтарящи се задачи по въвеждане на данни означава, че прекарвате повече време в анализиране и по-малко време в писане на цифри.

Примерен фрагмент от главна книга за малък бизнес

По-долу е представен съкратен пример в Beancount за нашия бутиков бизнес за електронна търговия. Илюстрираме покупка на инвентар, записване на продажба (с приспадане на таксата за платежния оператор) и отразяване на себестойността на продадените стоки за тази продажба. На практика бихте записвали и други разходи (като такси за платформи, разходи за реклама и т.н.) по подобен начин на показания пример с таксата. Приемаме USD за валута и продукт, наречен „Widget“, който следим като стока (commodity) в инвентара.

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 USD всяка)
2025-03-10 * "Покупка на 50 Widgets от SupplierCo"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD

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

; Себестойност на продадените стоки за горната продажба (2 Widgets по цена на придобиване 10 USD всеки)
2025-04-05 * "Себестойност (COGS) за Поръчка № 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 USD всяка, на обща стойност 500 USD. Трансакцията дебитира Assets:Inventory:Widgets с 50 WIDGET {10 USD}. Това означава, че 50 единици от стоката WIDGET, всяка със записана цена на придобиване от 10 USD, се добавят към сметката за инвентар. Кредитът е Assets:Bank:Checking -500 USD (изплатени парични средства). Забележете, че тук не сме докоснали директно сметка за разходи; ние капитализираме покупката като актив в инвентара. Сега нашият баланс показва 50 броя Widgets на обща стойност 500 USD в инвентара. (Ако генерирате отчет за баланса, сметката Inventory ще покаже 50 единици WIDGET на стойност 500 USD.)

• Записване на продажба (Поръчка № 1001): На 2025-04-05 записваме продажба на 2 броя Widgets чрез нашия онлайн магазин. Описанието включва номер на поръчка за яснота. Тази трансакция включва три записа:

  • Assets:Stripe:Balance 58 USD: пари, получени от продажбата, но в момента намиращи се в Stripe (нето след такси). Да приемем, че клиентът е платил общо 60 USD; Stripe е взел такса от 2 USD и сега в нашата сметка в Stripe има 58 USD (които по-късно ще бъдат преведени в нашата банка). Записваме тези 58 USD като актив в Stripe.
  • Expenses:Fees 2 USD: таксата от 2 USD се записва като бизнес разход. Това гарантира, че нашият отчет за приходите и разходите ще отразява този разход, а нашият актив в Stripe плюс разхода за такса заедно се равняват на общото плащане от клиента.
  • Income:Sales -60 USD: записваме 60 USD приход от продажби. (Сметките за приходи се увеличават с кредити, откъдето идва и отрицателната сума в нотацията на Beancount).

  След тази трансакция нетният ефект е: Приходите (Income:Sales) се увеличават с 60, имаме допълнителен актив от 58 USD (вземане от Stripe) и 2 USD разход за такса. Ако по-късно Stripe преведе тези 58 USD в нашата банка, бихме записали обикновен трансфер като Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USD на датата на плащането – това премества актива от сметката в Stripe към банката, без влияние върху приходите или разходите (просто преместване на активи). Не сме показали този трансфер по-горе, но това е важна стъпка в реалното счетоводство, за да поддържате сметката си в Stripe на 0 USD, след като всичко бъде преведено.

• Записване на себестойността (COGS) за продажбата: Също на 2025-04-05 имаме отделна трансакция за записване на себестойността на двата продадени броя Widgets. Дебитираме Expenses:COGS 20 USD и кредитираме Assets:Inventory:Widgets -2 WIDGET {10 USD}. Това премахва 2 единици от инвентара (всяка е имала цена на придобиване от 10 USD, както беше записано по-рано, общо 20 USD). Указваме {10 USD}, за да кажем на Beancount от коя партида да тегли – в този случай тя съвпада с партидата, която добавихме на 10.03.2025 г. Сега в сметката за инвентар ще останат 48 броя Widgets със съответна обща себестойност от 480 USD. Сумата от 20 USD се премества в разхода за себестойност (COGS), който ще се появи в отчета за приходите и разходите, намалявайки брутната печалба със себестойността на тези стоки. (Ако не запишем това, нашите приходи ще бъдат надценени спрямо разходите.) Използваме отделна трансакция за яснота, но е възможно също така да комбинираме продажбата и себестойността в една многоредова трансакция. Някои предпочитат разделянето им, както е показано, за по-добра четимост и равняване (можете ясно да свържете всеки запис за себестойност с конкретна поръчка). Също така повторихме номера на поръчката в описанието, за да се види лесно, че този запис за себестойност съответства на Поръчка № 1001. Добра практика е да се уверите, че всяка продажба има съответстващ запис за себестойност, когато е намесен инвентар – ако пропуснете такъв, наличността в инвентара ви ще бъде грешна. Подводен камък, който трябва да се избягва, е забравянето да се изпише инвентар при продажба, което би оставило баланса ви с фиктивни наличности, а разходите ви биха били подценени. Използването на функциите за инвентар на 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. Проследяването на инвестициите може също да включва активи (commodities) за акции или фондове, но ако това е твърде детайлно, можете просто да проследявате вноските и салдата по сметките.
• 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 ще сумира както хранителните стоки, така и храненето навън). Обща практика е да имате йерархия за основните групи (Жилище, Храна, Транспорт, Здравеопазване и др.).
• Equity:Opening-Balances – Използва се за иницииране на салдата по сметките, когато започвате своя регистър (така че всички активи минус пасивите да са равни на вашето начално нетно състояние, записано в собствения капитал). След стартирането може също да използвате Equity:Retained-Earnings или подобна сметка, за да представите натрупаната нетна печалба (въпреки че в личните финанси обикновено просто оставяте приходите минус разходите да се вливат в нетното състояние). Сметките за собствен капитал са по-малко видими в ежедневието, но гарантират, че счетоводното уравнение е балансирано.

Обосновка: Конфигурацията за лични финанси има за цел да обхване вашия финансов живот в една съгласувана система. Всяка сметка по-горе служи за разделяне на различните видове финанси, за да можете да отговорите на въпроси като „Колко похарчих за храна този месец?“ (чрез сумиране на Expenses:Food:*), „Колко дълг ми остава?“ (чрез преглед на сметките Liabilities) или „Какво е моето нетно състояние?“ (Активи минус Пасиви). Голямо предимство на двустранното записване тук е точността: например, когато платите сметка за хранителни стоки на стойност $100 с вашата кредитна карта, вие я записвате като разход и увеличение на пасива. По-късно, когато платите кредитната карта, записвате трансфер от вашата банка към картата – това погасява пасива, но не дублира разхода за хранителни стоки (който вече е бил записан). Честа грешка без двустранно счетоводство е плащането по кредитна карта да се третира като самия разход, като на практика тези $100 се броят два пъти. Beancount предотвратява това по дизайн. Друг капан, който трябва да се избягва, е липсата на равняване на сметките: с Beancount можете да използвате потвърждения на салдото (balance assertions) или директивата 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

; Пример за ежедневен разход (кафе с кредитна карта)
2025-09-10 * "Starbucks Coffee"
  Expenses:Food:Coffee       5.50 USD
  Liabilities:CreditCard:Visa   -5.50 USD  #daily

; Регулярна месечна сметка (наем, платен от разплащателна сметка)
2025-09-01 * "Apartment Rent September"
  Expenses:Housing:Rent    1200 USD
  Assets:Bank:Checking    -1200 USD  #recurring

; Вноска за пенсиониране (трансфер от разплащателна към 401k инвестиционна сметка)
2025-09-15 * "401(k) Contribution"
  Assets:Investment:401k    500 USD
  Assets:Bank:Checking     -500 USD  #retirement

Нека интерпретираме тези транзакции:

• Отваряне на сметки: Отваряме разплащателната сметка, сметка за кредитна карта Visa, сметка за разходи за кафе (като пример за подкатегория на разходите за храна), сметка за разходи за наем и 401k инвестиционна сметка. В един реален регистър бихте отворили всички сметки, които планирате да използвате (спестявания, други категории разходи, приходи и т.н.). Тук се ограничаваме само до необходимото за примера.
• Ежедневен разход – кафе: На 2025-09-10 е записана покупка на кафе за 5.50 USD. Разходът е категоризиран под Expenses:Food:Coffee и тъй като е платен с кредитна карта Visa, кредитираме (увеличаваме) Liabilities:CreditCard:Visa. Добавен е тагът #daily, за да укаже, че това е елемент от ежедневните разходи – по-късно може да пожелаете да филтрирате всички ежедневни дискреционни разходи. Забележете, че след това сметката на кредитната карта ще показва баланс от 5.50 USD (което означава, че дължите 5.50 USD на Visa). Ако бяхте платили в брой за това кафе, транзакцията щеше вместо това да кредитира Assets:Cash (намалявайки наличните ви пари в брой). Ако беше покупка с дебитна карта, тя щеше да кредитира Assets:Bank:Checking. Механиката е сходна, само сметките са различни.
• Регулярна сметка – наем: На 2025-09-01 записваме плащането на месечния наем от 1200 USD. Сумата излиза от разплащателната сметка (кредитиране на Assets:Bank:Checking) и се категоризира като Expenses:Housing:Rent. Тагнахме го с #recurring, за да отбележим, че това е повтаряща се сметка. В една пълна главна книга може да имате такъв запис всеки месец. (Beancount няма вградена функция за автоматични повтарящи се транзакции, но можете да постигнете това чрез скриптове или просто чрез копиране и поставяне всеки месец. Таговете помагат по-късно да се уверите, че не сте пропуснали месец или бързо да сумирате наема за годината.) Някои потребители използват функцията за периодични транзакции чрез рамката за импортиране на Beancount, за да генерират тези записи автоматично, но това е напреднала употреба извън настоящия обхват. Ключовото е, че тази транзакция ясно показва къде са отишли парите ви – разход за жилище – и вашия намален банков баланс. Капан, за който трябва да внимавате: ако споделяте разходи или имате съквартиранти, може да плащате само част от наема; в такъв случай бихте могли да разделите транзакцията на вашата част и частта, която някой друг плаща (евентуално записвайки другата част като Income:Reimbursements, ако те ви плащат). В нашия прост случай плащаме пълната сума.
• Вноска за пенсиониране: На 2025-09-15 сумата от 500 USD се прехвърля от разплащателната сметка в 401(k) инвестиционна сметка. Това не е разход, а по-скоро трансфер на активи от една форма (пари в брой) в друга (пенсионен фонд). Транзакцията дебитира Assets:Investment:401k и кредитира Assets:Bank:Checking. Тагваме я с #retirement за яснота. След това балансът на разплащателната ви сметка ще спадне с 500, а балансът на вашата 401k сметка в регистъра ще се увеличи с това, което представляват тези 500 USD (в зависимост от това как проследявате инвестициите, може впоследствие да закупите дялове от взаимни фондове с тези пари – това би било друга транзакция в инвестиционната сметка, например покупка на X акции от фонд на цена Y, като парите излизат от актива на 401k). В един базов личен регистър можете просто да третирате 401k като спестовна сметка и периодично да актуализирате баланса ѝ или да записвате вноски като тази и може би да използвате ценови котировки за проследяване на растежа. Важното е, че тази транзакция е трансфер, а не разход – тя изгражда вашите активи. Много инструменти за бюджетиране биха броили вноските за пенсиониране като „разходи“ (тъй като парите напускат разплащателната ви сметка), но в счетоводно отношение това е просто преместване на пари в друг джоб. Това разграничение ви помага да разберете процента на спестявания спрямо разходите.

Ако имахме транзакция за плащане на сметката по кредитна карта, тя би изглеждала като прехвърляне на пари от разплащателната сметка към пасива на кредитната карта (напр. Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD). Това би върнало баланса на кредитната карта обратно надолу (може би до нула, ако сте я платили изцяло) и би намалило банковия ви баланс съответно, без ефект върху сметките за разходи – защото вече сте записали разходите в момента на покупката. Помненето да обработвате кредитните карти по този начин е от решаващо значение за точното проследяване на личните финанси. Можете също така да тагнете плащането (някои използват #cc-payment или подобни) или да включите периода на извлечението в описанието за яснота.

Обобщение: Регистърът за лични финанси в Beancount помага за налагането на дисциплина и структура при проследяването на вашите пари. Чрез категоризиране на транзакциите със сметки (и по избор тагове), можете да генерирате проницателни отчети: месечни разходи по категории, годишни общи суми, колко сте спестили и т.н. Подходът на двустранното счетоводство означава, че всеки долар е отчетен: ако балансът на една сметка намалее, той е отишъл някъде (балансът на друга сметка се увеличава). Това улавя грешки и предотвратява често срещания проблем с „липсващи пари“ при по-простите инструменти за проследяване. С автоматизацията можете да импортирате повечето транзакции и след това просто да ги прегледате и класифицирате, което прави поддръжката напълно осъществима. С течение на времето изграждате финансов дневник, който е всеобхватен – той може дори да обработва неща като разделяне на сметки с приятели (използвайки сметки за собствен капитал или сметки за вземания/задължения), проследяване на амортизация на заеми или доходност от инвестиции, ако решите да се разширите в тези области. Дори в най-основния си вид (както е показано в откъса), Beancount ви дава яснота за ежедневните разходи, регулярните задължения и напредъка към дългосрочни цели (като спестявания за пенсиониране). И тъй като е в чист текстов формат, вие имате пълен контрол: можете да го обработвате със скриптове, да правите заявки към него или да го интегрирате с други инструменти (като уеб интерфейса Fava за по-приятен изглед). Накратко, тази настройка превръща вашите лични финанси в данни, които можете да анализирате и на които можете да се доверите, като същевременно остава достатъчно проста, за да не бъде бреме.

---

Чрез адаптиране на вашия Beancount регистър към вашата ситуация – независимо дали сте на свободна практика, управлявате малък бизнес или ръководите личните си средства – вие се възползвате от систематичния подход на двустранното счетоводство за финансово проследяване с гъвкавостта на система с чист текст. Тези примерни конфигурации демонстрират основни модели, върху които можете да градите. С разрастването на вашия бизнес или усложняването на финансовия ви живот, можете да разширите сметкоплана или да използвате разширени функции (като бюджети, анализ на отклоненията или работа с множество валути) според нуждите. Ключът е да започнете с чиста, логична структура (като показаните) и последователно да записвате транзакциите. С това налице, Beancount ще бъде мощен съюзник в разбирането и управлението на вашите финанси, независимо от индустрията или личните сценарии. Приятно осчетоводяване!