پرسش‌های متداول Beancount: پرسش‌های حسابداری متن‌ساده

حدود پنج مفهوم، نه یک مدرک. شما به پنج نوع حساب (دارایی‌ها، بدهی‌ها، سرمایه، درآمد، هزینه‌ها)، این ایده که هر تراکنش ارزش را بین حداقل دو عدد از آن‌ها جابه‌جا می‌کند، و این قاعده که یک تراکنش باید متوازن باشد، نیاز دارید. Beancount بقیه را برای شما اعمال می‌کند — هر تراکنشی که اعدادش جمع نشوند را به عنوان خطا علامت می‌زند به جای اینکه بی‌صدا بپذیرد، بنابراین نرم‌افزار اشتباهاتی را که یک مبتدی در غیر این صورت از دست می‌دهد، می‌گیرد.

با مقدمه‌ای بر Beancount شروع کنید، واژه‌نامه را در یک زبانه باز نگه دارید، و اولین تراکنش‌های خود را در شروع سریع ثبت کنید.

Beancount اصلاً از کلمات «بدهکار» و «بستانکار» استفاده نمی‌کند — آن از اعداد علامت‌دار استفاده می‌کند که باید به صفر برسند. پول خروجی از یک حساب منفی است، پول ورودی مثبت است، و یک تراکنش زمانی معتبر است که اقلام آن یکدیگر را خنثی کنند. این همان دفترداری دوطرفه‌ای است که حسابداران انجام می‌دهند، با حذف واژگانی که تازه‌کارها را گیج می‌کند.

اگر از نرم‌افزار حسابداری سنتی استفاده کرده‌اید، ترجمه این است: بدهکار یک عدد مثبت است و بستانکار یک عدد منفی. برای نحوه نوشتن اقلام، به مرجع نحو زبان مراجعه کنید، یا برای پیشینه حسابداری به زبان ساده، بدهکار و بستانکار توضیح داده شده را ببینید.

زیرا پول همیشه از جایی می‌آید، و جمع صفر چیزی است که این واقعیت را به یک بررسی خطا تبدیل می‌کند. اگر ۴۰ دلار برای خواربار خرج کنید، آن پول از یک حساب بانکی خارج شده — ثبت هر دو طرف به این معنی است که آن دو باید یکدیگر را خنثی کنند، و هر اشتباه تایپی در هر مبلغی به عنوان خطا علامت زده می‌شود به جای اینکه بی‌صدا یک مانده اشتباه تولید کند.

به همین دلیل است که یک دفتر متن‌ساده قابل اعتمادتر از یک صفحه‌گسترده از هزینه‌ها است: ساختار خودش خود-بررسی است. یک تأیید مانده (balance assertion) سازوکار مرتبطی است که دفتر شما را با واقعیت بررسی می‌کند.

یک تراکنش در تاریخ شروع خود ثبت کنید که مانده فعلی هر حساب را از Equity:Opening-Balances منتقل می‌کند، سپس یک تأیید مانده balance اضافه کنید تا آن را قفل کنید. شما نیازی به بازسازی تاریخچه مالی خود ندارید — یک تاریخ شروع انتخاب کنید، مانده‌ها را همانطور که هستند در آن روز بگیرید، و از آن به بعد به جلو بروید.

شروع سریع یک مثال کامل از مانده افتتاحیه را قدم به قدم نشان می‌دهد.

درشت شروع کنید و فقط زمانی تقسیم کنید که یک تقسیم دقیق‌تر یک تصمیم را تغییر دهد. حدود بیست حساب برای شروع کاملاً کافی است؛ اگر متوجه شدید که از خود می‌پرسید آیا «Expenses:Food» باید خواربار را از رستوران‌ها جدا کند، آزمون مفید این است که آیا واقعاً با دانستن این تقسیم، کار متفاوتی انجام می‌دادید.

تغییر نام و تقسیم بعداً یک جستجو-و-جایگزینی در یک فایل متنی است، بنابراین هزینه شروع ساده کم است. نام حساب‌ها تو در تو هستند، بنابراین می‌توانید با یک دسته کلی شروع کنید و آن را بعداً به حساب‌های فرعی تقسیم کنید بدون بازنویسی تاریخچه — به چگونه یک نمودار حساب طراحی کنیم مراجعه کنید اگر ساختاری برای کپی کردن می‌خواهید.

یک صفحه‌گسترده نمی‌تواند به شما بگوید که چه زمانی اشتباه است. حسابداری متن‌ساده دفترداری دوطرفه را اعمال می‌کند، بنابراین هر تراکنش خود-بررسی است، و فایل قابل جستجو، قابل مقایسه (diff)، و قابل اسکریپت‌نویسی است تا زمانی که فایل‌های متنی وجود دارند. شما همچنین تاریخچه نسخه واقعی دارید: git log روی دفتر شما دقیقاً نشان می‌دهد چه چیزی، چه زمانی، و چرا تغییر کرده است.

تفاوت عملی با چندین حساب، ارز، یا سرمایه‌گذاری ظاهر می‌شود، جایی که یک صفحه‌گسترده تک‌طرفه بی‌صدا از حقیقت فاصله می‌گیرد. به حسابداری شفاف و قابل رسیدگی مراجعه کنید.

اگر فقط می‌خواهید بدانید چقدر برای قهوه خرج کرده‌اید، بله — یک صفحه‌گسترده کافی است. دفترداری دوطرفه ارزش خود را از لحظه‌ای نشان می‌دهد که چندین حساب، وام مسکن، کارگزاری، یا بیشتر از یک ارز داشته باشید، زیرا این‌ها دقیقاً موقعیت‌هایی هستند که پیگیری تک‌طرفه پول را بدون اینکه به شما بگوید گم می‌کند.

یک راه مفید برای فکر کردن به آن: دفترداری دوطرفه یک جمع کنترلی برای امور مالی شماست. برای استدلال طولانی‌تر، مقدمه را ببینید.

خیر. Fava یک رابط وب کامل روی همان فایل متنی است — ترازنامه‌ها، صورت‌های سود و زیان، نمودارها، و ورود تراکنش — و Beancount.io آن را با دفتر شما در ابر اجرا می‌کند. فایل متنی منبع حقیقت باقی می‌ماند، بنابراین می‌توانید روزانه از رابط وب استفاده کنید و فقط وقتی خواستید به ترمینال بروید. اگر ترجیح میدهید از ترمینال استفاده کنید، دستور خط فرمان bea همان فایل را ایجاد، بررسی و گزارش میدهد — به شروع سریع CLI مراجعه کنید.

برای اینکه ببینید رابط چه کاری می‌تواند انجام دهد، ویژگی‌های رابط کاربری را ببینید، یا دموی زنده را امتحان کنید.

اکثر افراد ۸۰–۹۵٪ تراکنش‌ها را وارد می‌کنند و بقیه را دستی وارد می‌کنند. به ترتیب قابلیت اطمینان: دانلود مستقیم OFX/QFX از بانک شما، خروجی CSV به همراه قوانین import، اتصال aggregator، و — فقط به عنوان آخرین راه حل — صورتحساب PDF تبدیل شده به CSV. همگام‌سازی بانکی Beancount.io اتصال و دسته‌بندی را برای شما انجام می‌دهد.

انتظار داشته باشید که به ازای هر مؤسسه مالی یک قانون بنویسید یا تنظیم کنید: خروجی‌های CSV بانک بدنام ناسازگار هستند، و یک نام فروشنده حاوی کامای بدون escape یک مشکل واقعی و رایج است. وارد کردن هوشمند را برای مسیر خودکار ببینید.

برای یک فایل یک‌بار مصرف، دو مبدل مرورگر کار مکانیکی را بدون آپلود هیچ چیز انجام می‌دهند: CSV به Beancount برای خروجی‌های صفحه‌گسترده، و OFX و QIF به Beancount برای دانلودهای .ofx، .qfx، .qbo و .qif که بانک‌ها ارائه می‌دهند وقتی اصلاً CSV ارائه نمی‌دهند.

ابزارهای وارد کردن بر اساس ورودی‌هایی که قبلاً در دفتر شما هستند، موارد تکراری را حذف می‌کنند، با تطبیق تاریخ، مبلغ، و پرداخت‌کننده، و هر مورد مبهم را برای تأیید شما علامت می‌زنند نه اینکه حدس بزنند. گردش کار معمول واردات نامشخص را به عنوان معلق علامت می‌زند تا شما آن‌ها را بررسی کنید قبل از اینکه بخشی از سابقه دائمی شوند.

OFX این را از CSV آسان‌تر می‌کند: هر تراکنش یک FITID دارد که بانک آن را پایدار نگه می‌دارد در طول دانلودها، بنابراین یک importer می‌تواند بر اساس هویت به جای استنتاج تطبیق دهد — مبدل OFX آن را به عنوان یک فیلد فراداده id: حفظ می‌کند.

نیمه دیگر پاسخ، انتقال‌ها هستند: پولی که بین دو حسابی که مالک آن هستید جابه‌جا می‌شود در خروجی هر دو بانک ظاهر می‌شود. آن را یک بار به عنوان یک تراکنش واحد با دو قلم ثبت کنید.

خیر — و برای بسیاری از مردم این دلیلی است که اصلاً از حسابداری متن‌ساده استفاده می‌کنند. شما می‌توانید OFX یا CSV را خودتان از بانک خود خروجی بگیرید و هرگز اطلاعات ورود را به یک aggregator ندهید. اگر همگام‌سازی خودکار را ترجیح می‌دهید، Beancount.io از یک aggregator مورد تأیید بانک استفاده می‌کند به جای اینکه رمز عبور بانک آنلاین شما را ذخیره کند.

جزئیات را در صفحه امنیت بخوانید.

یک تأیید مانده balance برای رقم پایانی صورتحساب اضافه کنید، با تاریخ یک روز بعد از تاریخ پایان. تأییدهای مانده در ابتدای تاریخ خود ارزیابی می‌شوند، بنابراین تأیید صبح روز بعد همان چیزی است که تمام تراکنش‌های تا آخرین روز صورتحساب را شامل می‌شود. اگر دفتر شما با بانک مغایرت داشت، bea check یک خطای Balance failed گزارش می‌دهد و با کد خروج غیرصفر پایان می‌یابد، که تطبیق را از یک مقایسه دستی به چیزی تبدیل می‌کند که نرم‌افزار هر بار که اجرا می‌شود بررسی می‌کند.

یک برنامه ماهانه برای اکثر مردم کافی است. به فیلتر کردن و جستجو برای یافتن یک مغایرت مراجعه کنید.

به صورت بومی، و این یکی از قوی‌ترین مزیت‌های آن نسبت به برنامه‌های مالی مصرف‌کننده است. هر مبلغ ارز خود را حمل می‌کند، حساب‌ها می‌توانند چندین را همزمان داشته باشند، و تبدیل‌ها به صورت صریح با @ برای قیمت یا {} برای هزینه ثبت می‌شوند، بنابراین یک تغییر نرخ ارز هرگز بی‌صدا تاریخچه شما را بازنویسی نمی‌کند.

هیچ چیز پشت سر شما تبدیل نمی‌شود — شما همیشه هم ارز اصلی و هم ارزش تبدیل‌شده را می‌بینید. برای جنبه حسابداری به نحو زبان، دقت و تلورانس‌ها، و حسابداری چند-ارزی مراجعه کنید.

خریدها را با هزینه در آکولاد ثبت کنید — 10 AAPL {150.00 USD} — و Beancount هر قطعه (lot) را جداگانه پیگیری می‌کند. وقتی می‌فروشید، مشخص می‌کنید کدام قطعه را کاهش می‌دهید، و سود سرمایه به طور خودکار از محاسبات به دست می‌آید به جای اینکه چیزی باشد که با دست محاسبه کنید.

Beancount از روش‌های ثبت سفارش STRICT، FIFO، LIFO و NONE پشتیبانی می‌کند. ثبت هزینه متوسط تجزیه می‌شود اما به طور کامل پیاده‌سازی نشده است — اگر حوزه مالیاتی شما هزینه متوسط را الزام می‌کند، برنامه ریزی کنید آن را با یک پلاگین یا قطعه‌های صریح پیگیری کنید. به مدیریت موجودی مراجعه کنید.

دقیقاً مانند هر کالای دیگری: یک ارز دیجیتال یک واحد با هزینه است، بنابراین همان ماشین‌آلات قطعه و ثبت سفارش اعمال می‌شود. یک معاوضه یک توکن با توکن دیگر یک تراکنش واحد است که یک قطعه را کاهش می‌دهد و قطعه دیگری را باز می‌کند، که همچنین راهی است که سود تحقق‌یافته را به دست می‌آورید که اکثر مقامات مالیاتی می‌خواهند گزارش شود.

به پیگیری سبد ارز دیجیتال و قالب‌های آماده ارز دیجیتال مراجعه کنید.

کسب‌وکارها از آن استفاده می‌کنند، از جمله شرکت‌هایی با صدها هزار تراکنش. این حسابداری تعهدی، ساختارهای چند-واحدی، و گزارش‌هایی که یک حسابدار انتظار دارد را مدیریت می‌کند. محدودیت‌های صادقانه این است که ویرایش همزمان چند-کاربره وجود ندارد، رابط کاربری داخلی فاکتورینگ وجود ندارد، و گردش کار تأیید حساب‌های پرداختنی وجود ندارد — آن یک دفتر است، نه یک ERP.

به راه‌اندازی‌های خاص صنعت و دفتر باز نمایشی از دفاتر واقعی شرکت‌ها مراجعه کنید.

آن‌ها را جدا نگه دارید — یا به عنوان درختان حساب سطح بالا متمایز در یک فایل یا به عنوان دو فایل ترکیب شده با include. مخلوط کردن آن‌ها صورت سود و زیان کسب‌وکار را بی‌معنی می‌کند و زمان مالیات را سخت‌تر می‌کند، و جدا کردن آن‌ها از ابتدا هیچ هزینه‌ای ندارد.

دو فایل معمولاً انتخاب تمیزتری است وقتی کسب‌وکار حساب بانکی خودش را دارد. به پشتیبانی چند-فایلی مراجعه کنید.

دریافتنی‌ها را به عنوان یک حساب دارایی و پرداختنی‌ها را به عنوان یک بدهی مدل کنید، سپس فاکتور را وقتی صادر می‌کنید و پرداخت را وقتی می‌رسد ثبت کنید — این حسابداری تعهدی است، و Beancount مستقیماً از آن پشتیبانی می‌کند. چیزی که ندارد یک رابط فاکتورینگ است: آن پیگیری می‌کند چه چیزی به شما بدهکار هستند، تولید یا ارسال فاکتور نمی‌کند.

برای سمت گزارش به قالب‌های گزارشگری مالی، برای مثال‌های کاربردی به راه‌اندازی‌های خاص صنعت، و برای مفاهیم به درک حساب‌های دریافتنی مراجعه کنید.

به جای دفتر، گزارش‌ها را صادر کنید. حسابدار شما تقریباً مطمئناً یک فایل متنی نمی‌خواهد — آن‌ها یک صورت سود و زیان، یک ترازنامه، و یک لیست تراکنش می‌خواهند، که می‌توانید به صورت CSV یا PDF از رابط وب یا با یک query تولید کنید.

به راهنماهای آماده‌سازی مالیات، قالب‌های گزارشگری مالی، و query با SQL برای استخراج دقیقاً اعدادی که آن‌ها درخواست می‌کنند مراجعه کنید.

هر سه سیستم متن‌ساده دفترداری دوطرفه با فرمت‌های فایل مشابه هستند. Ledger اصلی و سهل‌گیرترین parser است؛ hledger یک بازپیاده‌سازی Haskell است که به خاطر قوانین import CSV دوستانه و مستندات شناخته شده است؛ Beancount سخت‌گیرانه‌ترین parser و قوی‌ترین پشتیبانی را برای سرمایه‌گذاری‌ها، قطعه‌ها، و چند ارز دارد، به علاوه یک API پلاگین Python.

سخت‌گیری معامله واقعی است: Beancount از بارگذاری فایلی که مبهم می‌یابد خودداری می‌کند، که خطاها را زود می‌گیرد به قیمت سخت‌گیرتر بودن. به Beancount در برابر Ledger CLI و Beancount در برابر hledger مراجعه کنید.

به صورت بومی نه — این یک شکاف واقعی است نه یک ویژگی پنهان. بودجه‌بندی داخلی Beancount محدود است، و افرادی که رفتار پاکتی سخت می‌خواهند معمولاً از یک پلاگین جامعه استفاده می‌کنند یا پاکت‌ها را به عنوان حساب مدل می‌کنند.

اگر بودجه‌بندی پاکتی اصلی‌ترین چیزی است که می‌خواهید، Beancount در برابر YNAB را قبل از تغییر بخوانید. برای آنچه امروز کار می‌کند، بودجه‌بندی در Beancount را ببینید.

بله. دستور document یک فایل را به یک حساب و تاریخ پیوند می‌دهد، و رابط وب به شما اجازه می‌دهد آن اسناد را در کنار تراکنش‌هایی که به آن تعلق دارند آپلود و مرور کنید. رسیدها به عنوان فایل‌های معمولی روی دیسک باقی می‌مانند، بنابراین به اندازه خود دفتر قابل حمل هستند.

به ویژگی‌های رابط کاربری مراجعه کنید.

بله — Beancount.io برنامه‌های iOS و Android را برای مشاهده دفتر و ثبت تراکنش‌ها در حال حرکت منتشر می‌کند، که شکافی است که اکثر راه‌اندازی‌های متن‌ساده باز می‌گذارند.

برای ثبت سریع بدون برنامه، بسیاری از مردم یک یادداشت تقریبی ثبت می‌کنند و بعداً آن را در دفتر تطبیق می‌دهند.

یک دهه امور مالی شخصی چند مگابایت است و در کسری از ثانیه بارگذاری می‌شود. Beancount مانده‌ها را از کل تاریخچه تراکنش در هر بار بارگذاری دوباره محاسبه می‌کند، و این تا صدها هزار ورودی سریع می‌ماند. بعد از آن محدودیت، راحتی ویرایش و diff است، نه زمان بارگذاری: تقسیم به سال با include فایل‌های فردی را کوچک نگه می‌دارد، اما فایل‌های شامل‌شده هنوز یک دفتر ترکیبی تشکیل می‌دهند که Beancount به طور کامل بارگذاری و دوباره محاسبه می‌کند، بنابراین این یک راحتی سازمان‌دهی فایل است نه یک سرعت‌بخش یا راهی برای نگه داشتن دفترهای جداگانه.

برای نحوه تقسیم یک دفتر در حال رشد به پشتیبانی چند-فایلی مراجعه کنید.