هر عددی که در سود و زیان یا ترازنامه می‌بینید، روزی به شکل یک سند حسابداری وارد دفتر شده است. فاکتور فروش، رسید بانک، برگشت کالا، پرداخت اجاره، صدور چک و ثبت حقوق اگر به سند نرسند، فقط کاغذ و پیامک هستند. برعکس، اگر سند بدون رویداد واقعی زده شود، دفتر از مغازه جدا می‌شود و دیگر به هیچ‌کدام نمی‌شود اعتماد کرد. سند حسابداری ترجمهٔ رویداد به زبان بدهکار و بستانکار است؛ کار حسابدار این نیست که تمام روز عدد تایپ کند، کارش این است که رویداد درست به سند درست برسد و استثناها کنترل شوند.
در نرم‌افزارهای امروز بیشتر سندهای فروش، خرید، دریافت و پرداخت خودکار ساخته می‌شوند. این نعمت است اگر الگو درست باشد، و دام است اگر الگو روی حساب غلط قفل شده باشد. این مقاله اجزای سند، تفاوت سند خودکار و دستی، نمونه‌های فروش و خزانه، قواعد تاریخ و شماره، و کنترل روزانه را با مثال کسب‌وکار ایرانی جمع می‌کند.
سند دوطرفه یعنی چه و چرا یک‌طرفه ذخیره نمی‌شود
حسابداری مالی که صورت‌های مالی از آن ساخته می‌شود، دوطرفه است: هر رویداد حداقل یک بدهکار و یک بستانکار دارد و جمع دو طرف باید برابر باشد. اگر بانک بدهکار می‌شود، حتماً جایی بستانکار شده؛ درآمد، بدهی، یا حساب شخص. این برابری همان چیزی است که تراز آزمایشی را ممکن می‌کند. نرم‌افزاری که سند نامتراز ذخیره می‌کند، اشکال جدی دارد؛ اگر کاربر بتواند طرف خالی بگذارد، دیر یا زود دفتر از ریاضی می‌افتد و پیدا کردن اختلاف روزها طول می‌کشد.
برابری دو طرف شرط لازم است نه کافی. سندی که بانک را بدهکار و برداشت مالک را بستانکار کرده، ممکن است از نظر ریاضی تراز باشد ولی رویداد را غلط ترجمه کرده باشد؛ اگر آن پول اجاره فروشگاه بوده، باید هزینه اجاره بدهکار می‌شد. کنترل ماهیت حساب و ارجاع به مدرک، همان لایهٔ دوم است که بعد از تراز عددی می‌آید.
اجزای سندی که بعداً قابل دفاع باشد
یک سند قابل اتکا حداقل این‌ها را دارد: تاریخ رویداد، شماره یکتا در دوره، شرح قابل فهم، حداقل دو سطر با معین مشخص، مبلغ برابر دو طرف، و ارجاع به مدرک بیرون از دفتر. مدرک می‌تواند فاکتور فروش، فاکتور خرید، رسید بانکی، تصویر چک، لیست حقوق یا قرارداد اجاره باشد. سندی که فقط می‌گوید «ثبت» یا «بابت بدهی»، سه ماه بعد حتی برای خود نویسنده هم مبهم است.
تفصیلی را خالی نگذارید وقتی معین اشخاص یا بانک است. اگر «حساب‌های دریافتنی» بدهکار شود ولی مشتری مشخص نباشد، در پایان ماه نمی‌دانید از چه کسی باید پول بگیرید. اگر «بانک» بدهکار شود ولی معلوم نباشد کدام حساب، مغایرت‌گیری با صورتحساب بانک ملت بی‌معنی می‌شود. در عمل، خالی ماندن تفصیلی یکی از دلایل اصلی اختلاف تراز کل با تراز تفصیلی است.
نرخ ارز، مرکز هزینه و شماره پیگیری وقتی موضوعیت دارند باید روی همان سند باشند، نه در ذهن کاربر یا در ستون توضیحات پیام‌رسان. اگر فروش ارزی دارید، مبلغ ریالی مبنای دفتر و تفاوت تسعیر باید سیاست مشخص داشته باشند؛ مخلوط کردن ارزها در یک سطر بدون نرخ، گزارش را خراب می‌کند.
سند خودکار و سند دستی؛ هر کدام کجا مشروع است
مسیر اصلی عملیات باید سند خودکار بسازد. فروش از روی فاکتور، خرید از روی فاکتور خرید، دریافت از روی رسید خزانه، پرداخت از روی اعلامیه، خروج کالا از روی حواله. فایده این مدل فقط سرعت نیست؛ فایده‌اش این است که یک منبع حقیقت دارید. اگر فاکتور را در فروش بزنید و همان مبلغ را دوباره دستی در دفتر کل تایپ کنید، دیر یا زود یکی از دو جا اصلاح می‌شود و دیگری جا می‌ماند.
سند دستی برای استثناست: اصلاح اشتباه دوره‌های قبل در چارچوب سیاست شرکت، ثبت استهلاک اگر ماژول جدا ندارید، ثبت حقوق اگر سیستم حقوق متصل نیست، انتقال بین حساب‌های انتظامی، و رویدادهایی که فرم آماده ندارند. اگر هر فروش نقدی را هم دستی می‌زنید، نرم‌افزار را دور زده‌اید. در حسابداری حسابیکس الگو به فاکتور و خزانه وصل است؛ کار حسابدار مسئول، بازبینی الگو و بستن دوره است نه ورود مجدد همان داده.
یک نشانهٔ خطر این است که حجم سند دستی از سند خودکار بیشتر باشد. آن وقت باید بپرسید کدام فرم عملیاتی ناقص است. شاید برگشت از فروش فرم ندارد و همه با سند دستی منفی می‌زنند؛ شاید کارمزد درگاه جایی ثبت نمی‌شود و آخر ماه یکجا دستی می‌آید. به‌جای عادی کردن دستی، فرم را کامل کنید.
نمونه اول: فروش نقدی کالا با ارزش افزوده
فروشگاه قطعه، یک دینام را به مصرف‌کننده نهایی می‌فروشد. مبلغ کالا ۱۰ میلیون تومان، ارزش افزوده ۹ درصد معادل ۹۰۰ هزار تومان، جمع دریافتی ۱۱٫۹ میلیون تومان که همان لحظه به کارت‌خوان واریز می‌شود. ترجمهٔ حسابداری، اگر کالا مشمول باشد، تقریباً این است: بانک بدهکار ۱۱٫۹ میلیون تومان؛ درآمد فروش کالا بستانکار ۱۰ میلیون؛ مالیات بر ارزش افزوده فروش بستانکار ۹۰۰ هزار تومان. همزمان اگر سیستم ادواری نیست و کاردکس دائمی دارید، بهای تمام‌شده همان دینام از موجودی کالا خارج و به بهای تمام‌شده کالای فروش‌رفته می‌رود. اگر فقط بخش اول را بزنید و خروج انبار نزنید، سود کاغذی زیاد می‌شود و قفسه با دفتر یکی نیست.
اگر همین فروش به یک تعمیرگاه حقوقی و با صورتحساب نوع ۱ باشد، منطق دفتر عوض نمی‌شود؛ آنچه عوض می‌شود دادهٔ هویتی خریدار و مسیر سامانه مودیان است. سند حسابداری و صورتحساب الکترونیکی باید از یک فاکتور بیایند. جزئیات نوع و اصلاحی را در مقالهٔ اصلاحی، ابطالی و برگشت از فروش ببینید. این‌جا نکته این است که ابطال فاکتور در سامانه بدون سند معکوس در دفتر، فروش را در کارپوشه کم و در سود و زیان زیاد نگه می‌دارد.
نمونه دوم: فروش نسیه و دریافت بعدی
همان دینام را به تعمیرگاه نسیه می‌فروشید. در روز فروش، به‌جای بانک، حساب دریافتنی آن شخص بدهکار می‌شود؛ درآمد و مالیات مثل قبل بستانکار می‌مانند. دو هفته بعد، تعمیرگاه ۷ میلیون تومان به حساب واریز می‌کند و بقیه را چک سه ماهه می‌دهد. دریافت نقدی، بانک را بدهکار و شخص را بستانکار می‌کند. چک دریافتنی تا قبل از وصول دارایی جداست، نه موجودی بانک. اگر چک را همان روز ورود در مانده بانک نشان دهید، مغایرت بانکی قطعی است و نقدینگی دروغ می‌گویید. مدیریت وضعیت چک را در مقالهٔ مدیریت چک دریافتنی و پرداختنی دنبال کنید؛ در سند فروش فقط باید معلوم باشد که تسویه ترکیبی از نسیه، بانک و چک بوده است.
این نمونه نشان می‌دهد چرا «سود» با «پول در بانک» یکی نیست. درآمد روز فروش شناسایی شده، اما نقد هفته‌ها بعد می‌آید. اگر مبنای گزارش را ننویسید، صاحب کسب‌وکار از سود ماه شگفت‌زده می‌شود و از خالی بودن حساب جاری عصبانی. تفاوت تعهدی و نقدی را جداگانه در مقالهٔ مربوط بخوانید؛ روی سند، حداقل باید طرف حساب شخص و بانک درست انتخاب شده باشد.
نمونه سوم: هزینه و برداشت؛ دو رویداد که شبیه هم دیده می‌شوند
مالک از حساب فروشگاه اجاره مغازه را می‌پردازد: هزینه اجاره بدهکار، بانک بستانکار. همان مالک فردا برای هزینه شخصی کارت فروشگاه را می‌کشد: برداشت یا جاری شریک بدهکار، بانک بستانکار. هر دو از حساب بانکی کم می‌کنند، اما یکی سود را کم می‌کند و دیگری حقوق مالکانه را. اگر هر دو را «هزینه» بزنید، سود فروشگاه کمتر از واقعیت عملیاتی دیده می‌شود و در رسیدگی هم توضیح می‌خواهید. الگوی پرداخت باید نوع هزینه را از روی ماهیت تراکنش بپرسد، نه اینکه هر خروجی بانک را هزینه فرض کند.
تاریخ، شماره، دوره و قفل
تاریخ سند تاریخ وقوع رویداد است، نه تاریخ تایپ. فاکتور روز ۲۸ ماه را روز سوم ماه بعد زدن، فروش ماه را جابه‌جا می‌کند و با سامانه مودیان هم ممکن است درگیر شود. عقب‌زدن تاریخ برای جا شدن در ماه قبل، بدون سیاست اصلاحی روشن، در رسیدگی به عنوان دستکاری دوره دیده می‌شود. اگر رویداد واقعاً در ماه قبل بوده و دوره هنوز باز است، با مدرک ثبت کنید. اگر دوره بسته است، مسیر اصلاح را جدا ببینید نه اینکه قفل را سرخود باز کنید.
شماره سند در هر دوره باید یکتا باشد. فاصله در شماره‌ها لزوماً تقلب نیست؛ ممکن است پیش‌نویس حذف شده باشد. اما پرش‌های منظم بدون توضیح، سؤال ایجاد می‌کند. دوره مالی را با سال مالیاتی و با نیاز گزارش مدیریتی هماهنگ کنید. دوره قفل‌شده نباید سند جدید بپذیرد مگر با دسترسی مشخص و ردپا. بستن سال بدون قفل، یعنی هر کس بعداً بتواند تاریخچه را عوض کند.
کنترل روزانه اسناد؛ پانزده دقیقه‌ای که ماه را نجات می‌دهد
در فروشگاه شلوغ، آخر روز این‌ها را نگاه کنید. اسناد بدون شرح یا با شرح تک‌کلمه‌ای. اسناد روی معین متفرقه. فاکتورهای فروش بدون سند یا سندهای فروش بدون فاکتور. دریافت‌های کارت‌خوان که در بانک ثبت نشده‌اند. اسناد دستی که کاربر غیرحسابدار زده است. عدم تراز؛ اگر سیستم اجازهٔ ذخیره نامتراز می‌دهد، همان روز با پشتیبانی یا با اصلاح دسترسی برخورد کنید.
هفتگی، تراز آزمایشی بگیرید و مانده بانک و اشخاص را با واقعیت بسنجید. مقالهٔ تراز آزمایشی مسیر پیدا کردن اختلاف را می‌گوید. روزانه بودن کنترل فروش و هفتگی بودن تراز، ترکیب معقولی برای تیم کوچک است. اگر کنترل را برای آخر ماه بگذارید، باید صد سند را در دو روز بخوانید و کیفیت افت می‌کند.
یک گزارش سادهٔ «سندهای امروز به تفکیک کاربر و نوع» از هر دستورالعمل اخلاقی مؤثرتر است. وقتی معلوم باشد چه کسی سند دستی زده، رفتار عوض می‌شود. نقش‌ها را روشن کنید: صندوق فقط فرم فروش و دریافت، انبار حواله، حسابدار الگو و سند دستی و بستن دوره.
شرح سند؛ کوتاه، کامل، بدون رمز شخصی
شرح خوب سه چیز را در یک خط می‌گوید: چه شد، با چه کسی، با کدام مدرک. «دریافت از تعمیرگاه پارس بابت فاکتور ۱۲۴۳، واریز کارت‌خوان» از «واریزی» مفیدتر است. الگوهای تکراری را در نرم‌افزار پیش‌فرض کنید تا کاربر خسته آن را پاک نکند. شماره فاکتور و نام شخص را از روی کارت بیاورید، نه از حافظه. شرح رمزگونه بین دو همکار، با رفتن یکی از آن‌ها می‌میرد.
سؤالات پرتکرار
می‌شود سند یک‌طرفه زد؟
در حسابداری دوطرفه که مبنای صورت‌های مالی است، خیر. جمع بدهکار و بستانکار باید صفر شود. بعضی سیستم‌های صندوق صرفاً لیست دریافت و پرداخت دارند؛ آن لیست تا به سند دوطرفه تبدیل نشود، ترازنامه نمی‌سازد. اگر نرم‌افزارتان «ثبت ساده» دارد، باید معلوم باشد پشت صحنه سند دوطرفه ساخته می‌شود یا نه.
فاکتور ابطالی یا برگشتی هم سند می‌خواهد؟
بله. ابطال یعنی سند معکوس یا موضوع ابطالی که اثر فاکتور قبلی را بردارد. برگشت از فروش یعنی کاهش درآمد و برگشت کالا به موجودی، در صورت برگشت فیزیکی. این دو را با هم عوض نکنید. مسیر سامانه مودیان باید با دفتر یکی باشد وگرنه خریدار هنوز آن خرید را در کارپوشه می‌بیند و شما در انبار کالا را گذاشته‌اید.
چه کسی حق سند دستی دارد؟
حسابدار مسئول یا مدیر مالی با دسترسی مشخص. صندوق و فروش نباید به دفتر کل خام برسند. اگر در کسب‌وکار تک‌نفره همه کارها با یک نفر است، باز هم بهتر است فروش را از فرم فاکتور بزند نه از سند دستی؛ عادت تک‌نفره وقتی نفر دوم اضافه شود خطرناک می‌شود.
شماره سند را می‌توانیم دستی انتخاب کنیم تا با شماره فاکتور یکی شود؟
بهتر است شماره سند و شماره فاکتور جدا بمانند و با فیلد ارجاع به هم وصل شوند. یکی کردن آن‌ها وقتی چند نوع سند در یک روز دارید قاطی می‌شود: دریافت، سند اصلاحی، افتتاحیه. ارجاع صریح از سردرگمی بهتر است.
اگر سند غلط در دوره بسته پیدا کنیم چه کنیم؟
دوره بسته را بی‌سیاست باز نکنید. مسیر درست معمولاً سند اصلاحی در دوره جاری با شرح ارجاع به سند قدیم است، مگر الزام قانونی یا حسابرسی بازکردن دوره مشخص را ایجاب کند. هر بازگشتنی باید ردپا داشته باشد. جزئیات مقطع سال را در چک‌لیست بستن سال مالی ببینید.
جمع‌بندی
سند خوب از رویداد واقعی می‌آید، دو طرفش برابر است، تفصیلی خالی ندارد، به مدرک ارجاع می‌دهد و تاریخش با وقوع می‌خواند. مسیر اصلی را خودکار کنید تا فروش و بانک دو بار تایپ نشوند؛ دستی را برای استثنا نگه دارید و هر روز آن را محدودتر کنید. دفتر شلوغ از سند بی‌شرح و معین متفرقه، آخر ماه را به حدس تبدیل می‌کند. یک فاکتور امروز را از روی پیش‌نمایش سندش بخوانید: اگر نتوانستید بدون پرسیدن از همکار بگویید چه شده، شرح و الگو هنوز برای کار واقعی آماده نیست.