Сметкопланове на 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.io за свободни професии.

Полезни възможности на Beancount: Таговете и метаданните са особено полезни при свободните професии. Можете да отбелязвате проект или номер на фактура с таг или да записвате името на клиента в поле с метаданни, ако не използвате отделни приходни сметки. Така лесно филтрирате транзакции за конкретен клиент или проект, например сумирате всички разходи с #ProjectX. Освен това автоматизираните импортери на 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. За приходните и разходните сметки може да не задавате валута в директивата за откриване, тъй като ще използват валутите на транзакциите, в случая USD.
• Плащане на фактура от клиент: На 2025-08-15 приходна транзакция записва клиентско плащане от $5,000 по фактура. Кредитираме Income:Client:ACME — при двойното записване приходът се увеличава с отрицателна сума — и дебитираме разплащателната сметка. Полето invoice: "INV-2025-08-15" съдържа номера на фактурата. То не е задължително, но показва как да добавяте допълнителна информация. Можете да използвате и таг #ACME или #client-ACME за бързо филтриране. При повече клиенти можете да запазите обща сметка Income:Clients и да ги различавате чрез метаданни или полето за получател, вместо да създавате много подсметки.
• Служебен разход за софтуер: На 2025-08-05 записваме разход от $15 за абонамент за GitHub, например за частни хранилища или други услуги. Записът е към Expenses:Business:Software и намалява служебната разплащателна сметка. Подобни малки периодични разходи могат да имат тагове: както добавихме #tax към данъчната транзакция по-долу, можете да използвате #recurring за месечни разходи. Тук самото име на сметката Software е достатъчно ясно.
• Плащане към подизпълнител: На 2025-08-20 специалистът плаща $2,000 на подизпълнител, Jane Doe. Това е разход по Expenses:Business:Contractors и изходяща сума от разплащателната сметка. Името на подизпълнителя може да е в описанието, както в примера, или в метаданни, например contractor: "Jane Doe". Така остава проследима информация на кого сте платили и защо, полезна при данъчна отчетност или бюджетиране.
• Прехвърляне на спестявания за данъци: На 2025-08-31 специалистът прехвърля $1,500 от основната разплащателна сметка към отделна спестовна сметка за данъци. Тагът #tax улеснява намирането на транзакцията. Това не е разход, а движение на собствени средства между две сметки за активи. Ако го правите всеки месец или тримесечие, натрупвате средства за авансовите данъчни плащания. При действителното плащане към държавата записвате разход, например Expenses:Taxes, и намаление на TaxSavings или Checking. Честа грешка е самият превод да се отчита като разход. Той е само предпазно заделяне на средства. Разход е действителното плащане към IRS или съответната данъчна администрация, а ако отчитате начислени данъчни задължения, плащането намалява това задължение.

Обобщение: Книгата за свободна практика в Beancount поставя на първо място простотата и яснотата. Всички приходи и плащания по дейността се записват систематично. Със смислени имена на сметки и подходящи тагове или метаданни лесно получавате отчети по клиент или категория разход: общи приходи от клиент, годишни плащания към подизпълнители и други. Конфигурацията се разширява с дейността ви чрез нови клиенти и категории. Автоматизираният импорт на банкови транзакции и таговете за проекти или фактури намаляват счетоводната работа и дават ясна финансова картина по всяко време.

Малки фирми​

Нека разгледаме малък бутиков онлайн бизнес, например магазин за ръчно изработени изделия. Тук се добавят управление на запасите, себестойност на продадените стоки (COGS) и работа с доставчици на онлайн плащания. Beancount може да ги обхване чрез добре обмислена структура на сметките и начин на записване. В нашия пример фирмата следи складовите наличности, отчита продажби през онлайн платформа, като Shopify с плащания чрез Stripe, и записва обичайните си разходи.

Основни сметки за бутиков онлайн магазин: Освен банкови и разходни сметки, счетоводната книга на търговска фирма включва сметки за запасите и потоците от продажби:

• Assets:Bank:Checking – Разплащателната сметка на фирмата за плащания към доставчици, оперативни разходи и получаване на преводи от платежните оператори.
• Assets:Stripe:Balance или Assets:PayPal и други – Разчетна сметка за събрани онлайн плащания, които още не са постъпили в банката. Когато клиент плати чрез Stripe, средствата могат да останат там, преди да бъдат преведени накуп към банковата ви сметка.
• Assets:Inventory:Продукт – Сметки за запасите от продукти. Можете да представите всеки продукт или категория като стокова единица в 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 – Общи разходи, които не са пряко свързани със себестойността: маркетинг, уеб хостинг, софтуер, опаковъчни материали и други. Подсметки като Expenses:Marketing, Expenses:WebHosting и Expenses:Shipping позволяват анализ на различните разходни направления.
• Liabilities:SalesTax – Незадължителна сметка, ако е приложима. Когато фирмата събира данък върху продажбите или ДДС, тя проследява събраните, но все още невнесени данъци. При всяка продажба данъчната част се отделя в тази сметка. Така събраните данъци не се броят за приход и остават предназначени за данъчната администрация.
• Equity:OwnerEquity – Незадължителна сметка за инвестицията на собственика и неразпределената печалба. Първоначалното финансиране се кредитира тук, а срещу него се дебитира банката или запасите според вида на вноската. Разпределянето на печалба към собственика също може да се отчита по тази сметка. Тя поддържа счетоводния баланс, но обикновено не участва често в ежедневните операции.

Логика: Конфигурацията разделя движението на стоките от това на парите. Покупките на запаси първоначално се записват като актив в баланса, а не направо като разход. Себестойността се признава за разход едва при продажбата, така че приходът и свързаният разход да попаднат заедно при изчисляването на печалбата. Продажбите се отчитат по брутна цена, а таксите — отделно, за да виждате брутния приход, платените такси и нетния приход. Разчетна сметка като Assets:Stripe:Balance улеснява сверяването на преводите: Stripe изпраща средствата накуп и можете ясно да отразите тези движения. Начинаещите търговци често отчитат всички покупки на стоки веднага като разход. Това може да е удобно за паричните потоци, но изкривява печалбата: месеците на зареждане изглеждат по-слаби, а месеците на продажба — по-печеливши, въпреки че стоките са купени по-рано. Със сметка за запаси и COGS свързвате разхода с продажбата. Друг пропуск е неотчитането на такси или възстановени суми, което води до разминаване между банковите или Stripe салдата и отчетените приходи. Изричното записване на таксите и използването на активна сметка за Stripe показва какво операторът ви дължи и какво е изплатил.

За да поддържате счетоводството на малка фирма в хостинг среда, с отчети, които вашият счетоводител може да чете, и регистър, който можете да експортирате по всяко време, вижте Beancount.io за малки фирми.

Полезни възможности на Beancount: Проследяването на запасите използва поддръжката на стокови единици и разходи за придобиване. Всеки продукт може да има символ на стокова единица, например WIDGET, и така да записвате количество и единична себестойност. При продажба посочвате коя партида намалявате и Beancount изписва от нея. Вижте запаси и методи за отчитане за всички възможности. Методът по подразбиране е STRICT и изисква еднозначно определена партида; затова примерът я задава изрично с {10 USD}. Ако искате автоматичен избор на най-старата партида, задайте FIFO в директивата open: open Assets:Inventory:Widgets WIDGET "FIFO". В примера използваме изричната форма със STRICT. Можете да свържете продажбата и съответния COGS запис чрез метаданни или връзки: един и същ номер на поръчка или общ таг като #order1001 върху продажбата и изписването на запасите. Така лесно проверявате дали всяка продажба има съответен разход. Автоматизираният импорт също помага: скрипт може да внася продажби от Shopify, отчети за изплащания от Stripe или банкови извлечения с разходи и преводи. Автоматизирането на повтарящото се въвеждане оставя повече време за анализ.

Примерни записи за малка фирма​

Следва съкратен пример за бутиковия онлайн магазин: покупка на запаси, продажба с удържана такса на платежния оператор и записване на себестойността на продадените стоки. Други разходи, като такси за платформи и реклама, бихте записвали подобно на показаната такса. Използваме 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 за последващ превод към банката. Записваме тези $58 като актив в Stripe.
  • Expenses:Fees 2 USD: таксата от $2 е служебен разход. Така тя се отразява в отчета за приходите и разходите, а активът в Stripe заедно с таксата е равен на общото клиентско плащане.
  • Income:Sales -60 USD: записваме $60 приход от продажби. Приходните сметки се увеличават с кредит, затова сумата в Beancount е отрицателна.

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

• Записване на COGS за продажбата: Също на 2025-04-05 отделна транзакция отчита себестойността на продадените 2 Widgets. Дебитираме Expenses:COGS 20 USD и кредитираме Assets:Inventory:Widgets -2 WIDGET {10 USD}. Това изписва 2 единици от запасите, всяка с вече записана стойност $10, общо $20. Чрез {10 USD} посочваме партидата, от която Beancount да изпише стоките — тук тя съответства на добавената на 2025-03-10. Остават 48 Widgets с отчетна стойност $480. Сумата от $20 преминава в разхода COGS и намалява брутната печалба в отчета за приходите и разходите. Без този запис приходите биха били завишени спрямо разходите. Използваме отделна транзакция за яснота, но продажбата и COGS могат да бъдат обединени в една транзакция с повече редове. Разделянето улеснява четенето и сверяването, защото всяко изписване ясно се свързва с поръчка. Повтаряме номера в описанието, за да се вижда връзката с поръчка #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:Retained-Earnings или подобна сметка за натрупания нетен резултат, въпреки че при лични финанси обикновено оставяте разликата между приходите и разходите да се отразява в нетното състояние. Сметките за собствен капитал участват по-рядко в ежедневието, но поддържат счетоводното равенство.

Логика: Конфигурацията обединява финансовия ви живот в последователна система. Сметките разграничават различните видове средства и отговарят на въпроси като „Колко похарчих за храна този месец?“ чрез сумиране на Expenses:Food:*, „Колко дълг ми остава?“ чрез сметките Liabilities и „Какво е нетното ми състояние?“ чрез активите минус пасивите. Голямото предимство на двойното записване е точността: покупка на хранителни стоки за $100 с кредитна карта се записва като разход и увеличение на задължението. По-късно плащането по картата е превод от банката към нея, който намалява дълга, без повторно да отчита вече записания разход. Без двойно записване лесно бихте отчели плащането по картата като втори разход и преброили $100 два пъти. Beancount предотвратява това чрез самата си структура. Друг риск е да не сверявате сметките: проверките на салдата или директивата balance потвърждават например, че салдото на разплащателната сметка съвпада с банковото извлечение, и откриват липсващи или дублирани записи.

Полезни възможности на Beancount: При личните финанси автоматизираният импорт е особено полезен заради големия брой транзакции. Системата за импортери на Beancount и скриптове от общността могат да внасят банкови транзакции, извлечения по кредитни карти и инвестиционни операции от CSV, OFX или API. Така не въвеждате ръчно всяко кафе. Собствените тагове групират данните по начини, които сметките не позволяват. Например #vacation2025 върху всички разходи за почивка — полети, хотели и хранене — позволява лесно да изчислите общата ѝ цена. Тагът #deductible може да отбелязва разходи, подлежащи на данъчно приспадане. Периодични сметки с #monthly позволяват годишен преглед на абонаментите и постоянните разходи. Метаданни могат да добавят бележки и разписки, например receipt: "path/to/file.jpg" за запазено изображение на касова бележка или category: "Work Expense" за възстановими разходи. Така приспособявате системата към нуждите си, без да създавате десетки допълнителни сметки.

Примерни записи за лични финанси​

Следва пример с типични лични транзакции: ежедневен разход с кредитна карта, периодична сметка, платена от разплащателната сметка, и вноска в пенсионна инвестиционна сметка. За краткост приемаме, че началната настройка, откриването на сметките и записването на заплатите вече са направени; тук се съсредоточаваме върху харченето и спестяването.

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, разходна сметка Coffee като подкатегория на храната, разходна сметка за наем и инвестиционна сметка 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 като спестовна сметка, периодично да обновявате салдото или да записвате вноски и евентуално да използвате ценови котировки за промяната в стойността. Главното е, че това е превод, а не разход: натрупвате активи. Много приложения за бюджетиране броят пенсионните вноски като „разходи“, защото парите напускат разплащателната сметка. Счетоводно обаче ги местите в друг джоб. Това разграничение помага да разбирате дела на спестяванията спрямо потреблението.

За инвестиции, записани като брой единици от поддържани ценни книжа, Live Prices може да поддържа котировки за оценяване в хоствана счетоводна книга. Пенсионно салдо, записано само като парична сума, не може да получи пазарни стойности на ценни книжа от ценови поток. Записвайте действително притежаваните активи и посочвайте изрично разходите за придобиването им.

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

Обобщение: Личната счетоводна книга в Beancount внася дисциплина и структура в проследяването на парите. Категоризирането чрез сметки и по желание тагове дава полезни отчети за месечни разходи по категории, годишни суми и спестявания. Двойното записване проследява всеки долар: ако едно салдо намалява, парите са отишли някъде и друга сметка се увеличава. Това открива грешки и предотвратява „липсващите пари“ в по-прости инструменти. Чрез автоматизация можете да импортирате повечето транзакции и само да ги преглеждате и категоризирате. С времето изграждате пълен финансов дневник, който може да обхване разделяне на сметки с приятели чрез сметки за капитал, вземания или задължения, погасяване на заеми и инвестиционна доходност. Дори основният пример дава яснота за ежедневните разходи, периодичните задължения и напредъка към дългосрочни цели като пенсионни спестявания. Обикновеният текст осигурява пълен контрол: можете да използвате скриптове, заявки и интеграции, включително удобния уеб интерфейс Fava. Така личните ви финанси се превръщат в надеждни данни за анализ, без поддръжката да се превръща в тежест.

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