Beancount FAQ: Питання про простий текст для бухгалтерії

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

Почніть із Вступу до Beancount, тримайте Глосарій відкритим у вкладці та додайте свої перші транзакції у Швидкому старті.

Beancount взагалі не використовує слова "дебет" і "кредит" — він використовує числа зі знаком, які мають у сумі давати нуль. Гроші, що залишають рахунок, є від'ємними, гроші, що надходять, — додатніми, і транзакція є дійсною, коли її проведення врівноважуються. Це та сама подвійна бухгалтерія, яку ведуть бухгалтери, але без словника, що бентежить новачків.

Якщо ви користувалися традиційним бухгалтерським програмним забезпеченням, переклад такий: дебет — це додатне число, а кредит — від'ємне. Дивіться довідку Синтаксис мови про те, як записуються проведення, або Дебет і кредит пояснено для бухгалтерської основи простою мовою.

Тому що гроші завжди звідкись беруться, і нульова сума — це те, що перетворює цей факт на перевірку помилок. Якщо ви витрачаєте $40 на продукти, ці гроші залишили банківський рахунок — запис обох половин означає, що вони мають врівноважитися, і будь-яка друкарська помилка в будь-якій із сум позначається як помилка, а не тихо створює неправильний баланс.

Ось чому бухгалтерська книга у простому тексті надійніша за електронну таблицю витрат: сама структура самоперевіряється. Твердження про баланс — це пов'язаний механізм, який звіряє вашу книгу з реальністю.

Запишіть транзакцію на вашу дату початку, яка переміщує поточний баланс кожного рахунку з Equity:Opening-Balances, потім додайте твердження balance, щоб його закріпити. Вам не потрібно відтворювати свою фінансову історію — виберіть дату початку, візьміть баланси такими, як вони є того дня, і рухайтеся далі звідти.

Швидкий старт проводить через повний приклад початкового балансу.

Почніть з укрупнених категорій і розділяйте лише тоді, коли детальніший поділ змінив би рішення. Двадцяти з чимось рахунків цілком достатньо для початку; якщо ви ловите себе на думці, чи має "Expenses:Food" відокремлювати продукти від ресторанів, корисний тест — чи справді ви зробили б щось інакше, знаючи цей поділ.

Перейменування й поділ пізніше — це пошук із заміною в текстовому файлі, тож ціна початку з простого низька. Назви рахунків вкладаються одна в одну, тож ви можете почати з широкої категорії та розділити її на підрахунки пізніше, не переписуючи історію — дивіться Як спроєктувати план рахунків, якщо хочете структуру, яку можна скопіювати.

Електронна таблиця не може сказати вам, коли вона помиляється. Бухгалтерія у простому тексті забезпечує подвійний запис, тож кожна транзакція самоперевіряється, а файл залишається доступним для grep, порівняння та скриптів, поки існують текстові файли. Ви також отримуєте справжню історію версій: git log на вашій книзі показує точно, що змінилося, коли і чому.

Практична різниця проявляється з кількома рахунками, валютами чи інвестиціями, де однозаписна електронна таблиця тихо відхиляється від істини. Дивіться Прозора та перевірювана бухгалтерія.

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

Корисний спосіб подумати про це: подвійний запис — це контрольна сума для ваших фінансів. Дивіться Вступ для докладнішого обґрунтування.

Ні. Fava — це повний вебінтерфейс над тим самим текстовим файлом — баланси, звіти про прибутки, графіки та введення транзакцій — а Beancount.io запускає його для вас із вашою книгою в хмарі. Текстовий файл залишається джерелом істини, тож ви можете щодня користуватися вебінтерфейсом і переходити до термінала лише тоді, коли захочете. Якщо ви таки віддаєте перевагу терміналу, командний рядок bea створює, перевіряє та звітує за тим самим файлом — дивіться Швидкий старт CLI.

Дивіться Функції інтерфейсу про те, що може робити інтерфейс, або спробуйте живе демо.

Більшість людей імпортує 80–95% транзакцій, а решту вводить вручну. У приблизному порядку за надійністю: пряме завантаження OFX/QFX з вашого банку, експорт CSV плюс правила імпорту, підключення через агрегатор і — лише як останній засіб — виписка PDF, сконвертована в CSV. Синхронізація з банком від Beancount.io займається підключенням і категоризацією за вас.

Очікуйте, що доведеться написати або скоригувати правило для кожної установи: експорт CSV з банків сумно відомий своєю неузгодженістю, а назва продавця, що містить неекрановану кому, — реальна й поширена проблема. Дивіться Розумний імпорт для автоматизованого шляху.

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

Імпортери усувають дублікати щодо записів, які вже є у вашій книзі, зіставляючи за датою, сумою та отримувачем, і позначають будь-що неоднозначне для вашого підтвердження, а не вгадують. Звичайний робочий процес позначає непевні імпорти як очікувані, щоб ви переглянули їх, перш ніж вони стануть частиною постійного запису.

OFX робить це легшим за CSV: кожна транзакція несе FITID, який банк тримає сталим між завантаженнями, тож імпортер може зіставляти за ідентичністю, а не за здогадом — конвертер OFX зберігає його як поле метаданих id:.

Інша половина відповіді — це перекази: гроші, що переміщуються між двома вашими рахунками, з'являються в експорті обох банків. Запишіть це один раз як єдину транзакцію з двома проведеннями.

Ні — і для багатьох людей це взагалі причина користуватися бухгалтерією у простому тексті. Ви можете самі експортувати OFX або CSV зі свого банку й ніколи не передавати облікові дані агрегатору. Якщо ви віддаєте перевагу автоматизованій синхронізації, Beancount.io використовує санкціонований банком агрегатор, а не зберігає ваш пароль до онлайн-банкінгу.

Читайте подробиці на сторінці безпеки.

Додайте твердження balance для кінцевої суми виписки, датоване днем після дати закриття. Твердження про баланс оцінюються на початку їхньої дати, тож твердження наступного ранку включає кожну транзакцію аж до останнього дня виписки. Якщо ваша книга не збігається з банком, bea check повідомляє помилку Balance failed і завершується з ненульовим кодом, що перетворює звірку з ручного порівняння на щось, що програмне забезпечення перевіряє щоразу під час запуску.

Місячної частоти достатньо для більшості людей. Дивіться Фільтрування та пошук для відстеження розбіжності.

Нативно, і це одна з його найсильніших переваг над споживчими фінансовими застосунками. Кожна сума несе свою валюту, рахунки можуть тримати кілька одночасно, а конверсії записуються явно за допомогою @ для ціни або {} для вартості, тож зміна обмінного курсу ніколи не переписує тихо вашу історію.

Нічого не конвертується за вашою спиною — ви завжди бачите і початкову валюту, і сконвертовану вартість. Дивіться Синтаксис мови, Точність і допуски та Мультивалютна бухгалтерія для бухгалтерської сторони.

Використовуйте Живі ціни для підтримуваних активів у розміщеній книзі Beancount.io, або отримуйте котирування у локальні файли цін для upstream Beancount і Fava. Вибір дає змогу обрати валюту котирування та скопіювати керовані include-и. Сумісні версії bea також підтримують керовані include-и; посібник із налаштування посилається на їхні інструкції.

Керовані ціни впливають на ринкову оцінку, а не на суми транзакцій чи базу витрат. Ваша власна ціна має пріоритет для тієї самої дати й пари. Оновлення можуть використовувати застарілі кешовані ціни під час збою, і пізніше котирування не може заповнити відсутню історичну дату оцінки.

Записуйте покупки з вартістю у фігурних дужках — 10 AAPL {150.00 USD} — і Beancount відслідковує кожен лот окремо. Коли ви продаєте, ви вказуєте, який лот зменшуєте, і приріст капіталу випливає з арифметики автоматично, а не є чимось, що ви обчислюєте вручну.

Beancount підтримує методи обліку STRICT, FIFO, LIFO та NONE. Облік за середньою вартістю розпізнається, але не повністю реалізований — якщо ваша податкова юрисдикція вимагає середньої вартості, плануйте відслідковувати її за допомогою плагіна або явних лотів. Дивіться Управління запасами.

Точно так само, як будь-який інший товар: криптовалюта — це одиниця з вартістю, тож той самий механізм лотів і обліку застосовується. Обмін одного токена на інший — це єдина транзакція, яка зменшує один лот і відкриває інший, що також дає вам реалізований приріст, який більшість податкових органів хочуть бачити в звітності.

Дивіться Відстеження криптовалютного портфеля та готові шаблони для крипто.

Бізнеси його використовують, зокрема компанії з сотнями тисяч транзакцій. Він підтримує облік за методом нарахування, структури з кількома юридичними особами та звіти, яких очікує бухгалтер. Честні обмеження: немає багатокористувацького одночасного редагування, немає вбудованого інтерфейсу для виставлення рахунків і немає робочого процесу затвердження кредиторської заборгованості — це книга, а не ERP.

Дивіться Галузеві налаштування та Відкриту книгу — вітрину справжніх книг компаній.

Тримайте їх окремо — або як окремі дерева рахунків верхнього рівня в одному файлі, або як два файли, об'єднані за допомогою include. Їхнє змішування робить звіт про прибутки бізнесу безглуздим і ускладнює час подання податків, а розділення нічого не коштує на старті.

Два файли зазвичай є чистішим вибором, щойно бізнес має власний банківський рахунок. Дивіться Підтримку кількох файлів.

Моделюйте дебіторську заборгованість як рахунок активів, а кредиторську — як зобов'язання, потім записуйте рахунок-фактуру, коли ви його виставляєте, і платіж, коли він надходить — це облік за методом нарахування, і Beancount підтримує його безпосередньо. Чого в ньому немає — так це інтерфейсу для виставлення рахунків: він відслідковує, скільки вам винні, але не генерує й не надсилає рахунок-фактуру.

Дивіться Шаблони фінансової звітності для сторони звітності, Галузеві налаштування для опрацьованих прикладів і Розуміння дебіторської заборгованості для концепцій.

Експортуйте звіти, а не книгу. Ваш бухгалтер майже напевно не хоче текстового файлу — він хоче звіт про прибутки, баланс і список транзакцій, які ви можете створити як CSV або PDF з вебінтерфейсу чи за допомогою запиту.

Дивіться Посібники з підготовки податків, Шаблони фінансової звітності та Запити за допомогою SQL для витягування саме тих чисел, які вони просять.

Усі три — це системи подвійного запису у простому тексті зі схожими форматами файлів. Ledger — оригінал і найбільш поблажливий парсер; hledger — реалізація на Haskell, відома дружніми правилами імпорту CSV та документацією; Beancount має найсуворіший парсер і найсильнішу підтримку інвестицій, лотів і кількох валют, а також API плагінів на Python.

Суворість — це справжній компроміс: Beancount відмовляється завантажувати файл, який вважає неоднозначним, що вловлює помилки рано ціною більшої прискіпливості. Дивіться Beancount проти Ledger CLI та Beancount проти hledger.

Нативно — ні, це справжня прогалина, а не прихована функція. Вбудоване бюджетування Beancount обмежене, і люди, які хочуть строгої поведінки конвертів, зазвичай використовують плагін спільноти або моделюють конверти як рахунки.

Якщо бюджетування за конвертами — головне, чого ви хочете, прочитайте Beancount проти YNAB, перш ніж переходити. Про те, що працює сьогодні, дивіться Бюджетування в Beancount.

Так. Директива document пов'язує файл із рахунком і датою, а вебінтерфейс дає змогу завантажувати й переглядати ці документи поряд із транзакціями, до яких вони належать. Чеки залишаються звичайними файлами на диску, тож вони такі ж портативні, як і сама книга.

Дивіться Функції інтерфейсу.

Так — Beancount.io публікує застосунки для iOS та Android для перегляду вашої книги й фіксації транзакцій на ходу, а це та прогалина, яку залишає відкритою більшість налаштувань у простому тексті.

Для швидкої фіксації без застосунку багато людей записують приблизну нотатку й звіряють її з книгою пізніше.

Десятиліття особистих фінансів — це кілька мегабайтів, і воно завантажується значно швидше за секунду. Beancount перераховує баланси з повної історії транзакцій під час кожного завантаження, і це залишається швидким аж до сотень тисяч записів. Понад це обмеженням є зручність редагування й порівняння, а не час завантаження: розділення за роками за допомогою include тримає окремі файли малими, але включені файли все одно утворюють одну об'єднану книгу, яку Beancount завантажує й перераховує повністю, тож це зручність організації файлів, а не прискорення чи спосіб тримати окремі книги.

Дивіться Підтримку кількох файлів про те, як розділити зростаючу книгу.