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

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

В това ръководство ще разгледаме как да приспособим счетоводна книга на Beancount за различни нужди: фрийланс професионалист, бутиков малък бизнес и лични/домакински финанси. Всеки сценарий идва с уникални структури на сметки и съображения. Ще обясним обосновката зад всяка настройка, ще предоставим примерни фрагменти от Beancount и ще подчертаем полезни функции (като потребителски тагове и автоматизирани импорти), които улесняват проследяването. Тонът е на обучителен, но достъпен – независимо дали сте програмист, технически грамотен професионалист или финансов ентусиаст, тези примери ще ви помогнат да приложите Beancount в реалния свят.

Фрийлансъри

Фрийлансърите (като софтуерни разработчици или графични дизайнери) често жонглират с множество клиенти и проектни разходи. Една проста настройка на Beancount може да помогне за проследяване на приходите от всеки клиент, бизнес разходите (включително наетите подизпълнители) и парите, заделени за данъци. Целта е да се запази просто, така че да се мащабира с растежа на вашия фрийланс бизнес, без ненужна сложност.

Ключови сметки за фрийлансър: Счетоводната книга на фрийлансър обикновено разделя бизнес финансите от личните финанси. Например, можете да използвате:

• Assets:Business:Checking – Бизнес банкова сметка за всички клиентски плащания и бизнес разходи.
• Assets:Business:TaxSavings – Спестовна сметка за заделяне на част от приходите за данъчни плащания (тъй като никой работодател не удържа данъци вместо вас).
• Income:Client:Име** – Сметки за приходи от клиентски плащания. Можете да създадете подсметки за всеки основен клиент (например, Income:Client:ACME) или да използвате единична сметка Income:Freelance с имена на клиенти, маркирани в транзакциите.
• Expenses:Business:Contractors – За плащания към всякакви подизпълнители или работа, извършена от външни лица.
• Expenses:Business:Software (и други категории като Travel, Supplies) – За редовни бизнес разходи (софтуерни абонаменти, оборудване, пътуване до обекти на клиенти и т.н.).
• Equity:OwnerDraw – (По избор) За записване на трансфери на печалба от бизнеса към вас лично. Това помага да се разграничат бизнес средствата от личните средства, когато си плащате.

Обосновка: Тази структура гарантира, че всички пари, свързани с бизнеса, се проследяват в специализирани сметки. Приходите от всеки клиент се записват (което улеснява да видите кои са вашите най-добри клиенти), а разходите са категоризирани за данъчни облекчения. Заделянето на данъци в отделна сметка за активи (или записването на пасив за дължими данъци) предотвратява случайното изразходване на пари, които ще бъдат дължими на правителството. Счетоводната книга остава проста: ако придобиете нови клиенти или категории разходи, можете да добавите нови сметки или да използвате тагове, без да реорганизирате всичко. Често срещан проблем е смесването на лични и бизнес транзакции в една сметка; чрез поддържане на специализирана бизнес разплащателна сметка (и съответната сметка за активи), съгласуването и отчитането стават по-чисти. Друг проблем, който трябва да се избягва, е да забравите да запишете парични преводи за данъци или тегления на собственика – като използвате сметки като TaxSavings и OwnerDraw, всеки долар се отчита.

Beancount Функции за подчертаване: Таговете и метаданните са изключително полезни за фрийлансърите. Например, можете да маркирате транзакции с номер на проект или фактура или да използвате поле за метаданни, за да отбележите името на клиента, ако изберете да не използвате отделни сметки за приходи за всеки клиент. Това улеснява филтрирането или заявките за транзакции за конкретен клиент или проект (например, сумиране на всички разходи, маркирани с #ProjectX). Освен това, автоматизираните импорти на Beancount могат да опростят въвеждането на данни – например, можете да настроите импортер за вашите банкови извлечения или извлечения от кредитни карти, за да въвеждате транзакции във вашата счетоводна книга, след което просто добавете подходящите имена на сметки за разходи или приходи. Това спестява време, когато имате много малки транзакции (като софтуерни абонаменти или пътни разходи).

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

По-долу е опростен фрагмент от Beancount за фрийланс разработчик. Той показва отваряне на няколко ключови сметки, входящо плащане от клиент, изходящо плащане към подизпълнител, типичен бизнес разход и прехвърляне на пари в сметка за спестявания за данъци. (На практика, ще записвате и други разходи като пътуване или покупки на оборудване по подобен начин.)

1970-01-01 open Assets:Business:Checking
1970-01-01 open Assets:Business:TaxSavings
1970-01-01 open Income:Client:ACME
1970-01-01 open Expenses:Business:Contractors
1970-01-01 open Expenses:Business:Software

; Приход от клиент – плащане за фактура
2025-08-15 * "Плащане по фактура от ACME Corp"
  invoice: "INV-2025-08-15"
  Assets:Business:Checking       5000 USD
  Income:Client:ACME           -5000 USD

; Редовен разход – напр. софтуерен абонамент за бизнеса
2025-08-05 * "GitHub Subscription"
  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 * "Заделяне за данъци за Q3"
  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, фрийлансърът е платил на подизпълнител (Jane Doe) $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:Продукт** – Сметки за инвентар за вашите продукти. Можете да третирате всеки продукт (или категория продукти) като стока в 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 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 всяка)

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

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

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

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

• Записване на COGS за продажбата: Също така на 2025-04-05, имаме отделна транзакция за записване на себестойността на продадените 2 Widgets. Дебитираме Expenses:COGS 20 USD и кредитираме Assets:Inventory:Widgets -2 WIDGET {10 USD}. Това, което прави това, е да премахне 2 единици от инвентара (всяка е имала цена от $10, както е записано по-рано, така че общо $20). Посочваме {10 USD}, за да кажем на Beancount от коя ценова партида да тегли – в този случай, тя съвпада с партидата, която добавихме на 2025-03-10. Сега сметката за инвентар ще има 48 Widgets, оставащи и свързана цена от $480. $20 се преместват в разходите за COGS, които ще се появят в отчета за приходите, намалявайки брутната печалба с цената на тези стоки. (Ако не запишем това, приходите ни ще бъдат надценени спрямо разходите.) Използваме отделна транзакция за яснота, но също така е възможно да комбинирате продажбата и COGS в една многоредова транзакция. Някои предпочитат да ги разделят, както е показано за четливост и съгласуване (можете ясно да свържете всеки COGS запис към поръчка). Също така повторихме номера на поръчката в разказа, за да видим лесно, че този COGS запис съответства на Поръчка #1001. Добра практика е да се гарантира, че всяка продажба има съответстващ COGS запис, когато е включен инвентар – липсата на един ще означава, че вашите инвентарни бройки са изключени. Проблем, който трябва да се избягва, е да забравите да премахнете инвентара за продажба, което ще остави вашия баланс с фантомни запаси и вашите разходи подценени. Използването на функциите за инвентар на Beancount (нотацията за цена {}) помага да се хване, ако се опитате да премахнете повече единици, отколкото имате на склад (софтуерът ще даде грешка в този случай).

Резюме: Малък бизнес, използващ Beancount, може да поддържа изненадващо стабилна счетоводна система. Чрез структуриране на сметки за проследяване къде са парите, откъде идват и как текат разходите, вие получавате точна картина на рентабилността. Нашият пример показа как да се обработва инвентар и продажби; по същия начин бихте записали други транзакции като плащане на сметка за интернет (Expenses:Operating:Internet срещу Assets:Bank:Checking), получаване на заем или инвестиция (Assets:Bank срещу Liabilities:Loan или Equity:OwnerEquity) или плащане на данък върху продажбите (Liabilities:SalesTax срещу Assets:Bank при превеждане). Ключът е последователността: записвайте всеки тип транзакция със същия модел и Beancount ще поддържа книгите балансирани. С функции като автоматизирано импортиране на данни (например, изтегляне на месечни такси от Stripe или банкови транзакции) и потребителски тагове/връзки (за корелиране на свързани транзакции като продажби и възстановявания), системата може да бъде както гъвкава, така и ефективна. Резултатът е организирана счетоводна книга, която може да се мащабира с растежа на бизнеса – можете да добавите нови сметки за инвентар на продукти, нови категории разходи или допълнителни потоци на приходи (да речем нов онлайн пазар), без да преработвате цялата система.

Лични финанси

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

Ключови сметки за лични финанси: Книгата за лични финанси обикновено включва различни сметки за активи, пасиви, приходи и разходи:

• Assets:Bank:Checking – Вашата основна разплащателна сметка за депозити на приходи и плащания на сметки.
• Assets:Bank:Savings – Спестовна с