صورتحساب الکترونیکی سامانه مودیان دیگر یک گزینهٔ اختیاری نیست؛ برای خیلی از کسب‌وکارها همان فاکتوری است که سازمان امور مالیاتی می‌بیند. اگر نوع صورتحساب، الگو، شناسه کالا یا اطلاعات خریدار اشتباه باشد، فاکتور در کارپوشه رد می‌شود، اصلاحش زمان می‌برد و گزارش ارزش افزوده با فروش واقعی یکی نمی‌شود. این راهنما برای حسابدار و صاحب کسب‌وکاری نوشته شده که می‌خواهد در سال ۱۴۰۵ صورتحساب را درست صادر کند، خطا را بفهمد و قبل از ارسال کنترل کند — نه اینکه فقط دکمهٔ ارسال را بزند.
صورتحساب الکترونیکی چیست و چه فرقی با فاکتور کاغذی دارد؟
فاکتور کاغذی یا فایل اکسل فقط بین فروشنده و خریدار رد و بدل می‌شود. صورتحساب الکترونیکی همان معامله را در قالب استاندارد سازمان امور مالیاتی می‌سازد: نوع صورتحساب، الگوی فعالیت، نقش خریدار و فروشنده، شناسه کالا یا خدمت، مبلغ، تخفیف، ارزش افزوده و روش تسویه. بعد از امضا با حافظهٔ مالیاتی، این داده به کارپوشه می‌رود و یک شناسه یکتا می‌گیرد.
نتیجه عملی این است که «فاکتور فروش در نرم‌افزار حسابداری» و «صورتحساب مورد قبول سامانه» باید از یک منبع ساخته شوند. اگر در نرم‌افزار یک رقم بزنید و در سامانه رقم دیگری بفرستید، بعداً برای اظهارنامه، رسیدگی و خریدار مشکل می‌سازید. اتصال مستقیم فاکتور به سامانه مودیان دقیقاً برای همین است؛ در حسابداری و گزارش مالی حسابیکس سند فروش و ارسال مالیاتی روی همان داده می‌نشینند.
انواع صورتحساب الکترونیکی که باید از هم جدا کنید
قبل از هر ارسال، نوع صورتحساب را با نوع مشتری و الزام قانونی کسب‌وکار خود تطبیق دهید. انتخاب غلط نوع، یکی از پرتکرارترین دلایل رد شدن صورتحساب است.
صورتحساب نوع ۱
وقتی خریدار کسب‌وکار است و باید در کارپوشهٔ خودش این خرید را ببیند، معمولاً با نوع ۱ کار می‌کنید. اینجا شناسه ملی یا کد اقتصادی خریدار، کد پستی و اطلاعات کامل طرف‌حساب لازم است. اگر کد اقتصادی را خالی بگذارید یا شناسه ملی شخص حقیقی را با شرکت حقوقی جابه‌جا کنید، سامانه خطا می‌دهد.
صورتحساب نوع ۲
برای فروش به مصرف‌کنندهٔ نهایی، در چارچوب ضوابط سازمان، ممکن است صورتحساب نوع ۲ صادر شود؛ یعنی جزئیات هویتی کامل خریدار مثل مؤدی ثبت‌شده لازم نباشد. این نوع برای فروشگاه خرده‌فروشی و صندوق روزمره رایج است، اما سقف و شرایط آن را باید از آخرین دستورالعمل بخوانید. نوع ۲ را نباید برای فروش عمده به شرکت‌ها «از روی عادت» استفاده کرد.
سایر وضعیت‌ها
برخی فعالیت‌ها الگوی جدا دارند، نه فقط نوع جدا: طلا و جواهر، پیمانکاری، قبض خدماتی، بلیط، صادرات و موارد مشابه. اگر الگوی فروش عادی را برای قراردادی که باید الگوی پیمانکاری باشد بفرستید، صورتحساب از نظر سامانه ناقص است حتی اگر جمع مبلغ درست باشد.
الگوی صورتحساب را با فعالیت واقعی یکی کنید
الگو یعنی «این معامله از نظر سازمان چه جنسی دارد». حسابدار باید برای هر کالا/خدمت یا هر نوع فروش، الگوی پیش‌فرض را در نرم‌افزار قفل کند تا صندوقدار هر بار حدس نزند.
- فروش کالا یا خدمت معمولی: الگوی فروش
- طلا، جواهر و پلاتین: الگوی تخصصی با فیلدهای عیار و اجرت
- پیمانکاری: اطلاعات قرارداد و صورت‌وضعیت
- قبض خدماتی: شناسه قبض و دوره
- صادرات: اطلاعات گمرکی و ارز
اگر چند فعالیت دارید، یک الگوی پیش‌فرض برای کل شرکت کافی نیست. فروشگاه مواد غذایی که گاهی خدمت نصب هم می‌فروشد، باید خدمت را جدا از کالا ببیند. در کسب‌وکارهای صنفی این موضوع با حسابداری مغازه و صنف خیلی زود خودش را نشان می‌دهد.
صورتحساب اصلی، اصلاحی، ابطالی و برگشت از فروش
سامانه چهار موضوع اصلی را از هم جدا می‌کند. قاطی کردن آن‌ها باعث می‌شود هم کارپوشه شلوغ شود هم خریدار نتواند خریدش را ارجاع دهد.
اصلی
اولین صدور بابت یک معامله. شماره و سریال این صورتحساب مرجع بقیهٔ اسناد می‌شود.
اصلاحی
وقتی معامله همان معامله است ولی فیلدی اشتباه بوده: مبلغ، تعداد، تخفیف، شناسه کالا، شرح. اصلاحی باید به صورتحساب اصلی ارجاع بدهد. اصلاحی برای «پشیمانی از فروش» نیست؛ برای تصحیح داده است.
ابطالی
وقتی آن معامله از اساس نباید در سامانه می‌ماند: صدور تکراری، صدور به خریدار غلط، یا معامله‌ای که واقع نشده. ابطال بی‌دلیل آمار فروش را به هم می‌ریزد و در رسیدگی سؤال ایجاد می‌کند.
برگشت از فروش
وقتی کالا برگشت می‌شود یا خدمت لغو می‌شود و باید اثر مالی معامله کم شود. برگشت از فروش با ابطال فرق دارد: ابطال یعنی آن سند نباید وجود می‌داشت؛ برگشت یعنی معامله رخ داد و بعداً بخشی یا تمامش برگردانده شد.
قانون عملی تیم مالی: هیچ‌کس جز حسابدار مسئول، حق ارسال اصلاحی/ابطالی/برگشت را بدون سند پشتیبان نداشته باشد. در نرم‌افزار باید این اسناد از روی فاکتور اصلی ساخته شوند، نه با ثبت دستی جداگانه.
مثال: فروشگاه قطعه، ۱۰ عدد دینام به یک تعمیرگاه فروخته و نوع ۱ ارسال شده. فردا مشتری ۲ عدد را به‌خاطر ایراد فنی برمی‌گرداند. اینجا ابطال کل فاکتور غلط است؛ باید برگشت از فروش برای همان ۲ عدد به فاکتور اصلی وصل شود. اگر به‌جای آن فاکتور جدید منفی در اکسل بزنید و به سامانه نرود، موجودی و مالیات از هم جدا می‌شوند.
مثال دوم: فاکتور نوع ۱ به شناسه ملی اشتباه خورده. معامله واقعی با آن شرکت نبوده. این مورد اصلاح مبلغ نیست؛ ابطال است. بعد فاکتور اصلی جدید برای خریدار درست صادر می‌شود.
خطاهای رایجی که صورتحساب را در کارپوشه زمین‌گیر می‌کنند
بیشتر خطاها محاسباتی پیچیده نیستند؛ دادهٔ پایه ناقص است. قبل از ارسال گروهی، این موارد را در فاکتور و کارت کالا چک کنید.
- شناسه کالا و خدمت نامعتبر یا خالی: هر ردیف باید شناسهٔ متناظر در فهرست سازمان را داشته باشد. شناسهٔ کلی و مبهم برای کالای خاص، در رسیدگی به ضرر شما تمام می‌شود. جزئیات را در مقالهٔ شناسه کالا و خدمت در سامانه مودیان ببینید.
- اطلاعات خریدار: شناسه ملی، کد اقتصادی، کد پستی و نقش حقیقی/حقوقی باید با استعلام همخوان باشد.
- مالیات ارزش افزوده: نرخ باید با وضعیت معافیت کالا یکی باشد. کالای معاف را با ۹ درصد نفرستید و کالای مشمول را صفر نزنید.
- تاریخ و بازهٔ مجاز: تاریخ صورتحساب خارج از مهلت یا جلوتر از منطق سامانه، رد می‌شود.
- روش تسویه و مبلغ: جمع ردیف‌ها، تخفیف، مالیات و مبلغ پرداختی باید ریاضی‌وار یکی باشند. یک ریال اختلاف کافی است.
- حافظه مالیاتی و امضا: اگر گواهی منقضی شده یا حافظه به پرونده وصل نیست، ارسال اصلاً شروع نمی‌شود. برای راه‌اندازی به راهنمای حافظه مالیاتی و کارپوشه مراجعه کنید.
بعد از ارسال، کار تمام نیست. وضعیت هر صورتحساب را در کارپوشه یا گزارش نرم‌افزار بخوانید: موفق، در انتظار، ردشده. ردشده را همان روز تعیین‌تکلیف کنید؛ انباشته شدن خطای هفته‌های قبل، در اظهارنامه خودش را نشان می‌دهد.
چک‌لیست روزانهٔ صدور صورتحساب در ۱۴۰۵
این چک‌لیست را می‌توانید به مسئول فروش و حسابدار بدهید تا قبل از ارسال گروهی اجرا شود.
- کارت مشتری برای فروش نوع ۱ کامل است و با آخرین تغییر ثبتی یکی است.
- هر کالا شناسه خدمت/کالای تأییدشده دارد؛ کالای جدید بدون شناسه فروخته نشده.
- الگوی فاکتور با نوع فعالیت یکی است.
- تخفیف روی ردیف یا سند با سیاست فروشگاه یکی است و مالیات بعد از تخفیف درست حساب شده.
- روش تسویه (نقد، چک، نسیه، ترکیبی) با دریافت واقعی می‌خواند.
- پیش‌نمایش XML یا خلاصهٔ ارسالی با فاکتور چاپی مشتری یکی است.
- ارسال آزمایشی یک فاکتور در شروع روز، قبل از ارسال صد فاکتور.
برای فروشگاه‌هایی که صندوق شلوغ دارند، این کنترل‌ها باید در لحظهٔ ثبت فاکتور قفل شوند، نه آخر شب. اگر آخر شب صد فاکتور رد شود، اصلاح فردا با صف مشتری تداخل می‌کند.
تقسیم کار در تیم؛ چه کسی چه چیزی را قفل می‌کند
بیشتر خطاهای سامانه مودیان از نامشخص بودن مسئولیت است. یک مدل ساده برای کسب‌وکار کوچک تا متوسط این است:
- مسئول کالا: شناسه کالا/خدمت، واحد اندازه‌گیری، نرخ ارزش افزوده و معافیت را روی کارت کالا نگه می‌دارد. کالای بدون شناسه نباید قابل فروش باشد.
- مسئول اشخاص: شناسه ملی، کد اقتصادی، کد پستی و حقیقی/حقوقی بودن مشتری نوع ۱ را قبل از اولین فروش قطعی تکمیل می‌کند.
- صندوق یا فروش: فاکتور را می‌زند، تخفیف را در چارچوب سیاست می‌دهد، روش تسویه را درست انتخاب می‌کند. حق تغییر نوع صورتحساب و الگو را ندارد مگر با دسترسی جدا.
- حسابدار: ارسال، خواندن وضعیت، اصلاحی و ابطالی، مغایرت هفتگی با کارپوشه.
اگر همه این کارها را یک نفر در مغازه انجام می‌دهد، باز هم این چهار نقش را در چک‌لیست جدا کنید. ذهن در ساعت شلوغ صندوق، شناسه کالا را حدس می‌زند؛ قفل نرم‌افزار جلوی حدس را می‌گیرد.
ارسال مستقیم، شرکت معتمد یا فایل جدا؟
سه مسیر رایج وجود دارد. انتخاب مسیر باید با حجم فاکتور و بلوغ نرم‌افزار حسابداری یکی باشد.
ارسال مستقیم از نرم‌افزار حسابداری: مناسب وقتی فاکتور، موجودی و مالیات یک جا هستند. خطا کمتر می‌شود چون داده دوباره تایپ نمی‌شود. مناسب کسب‌وکارهایی که نرم‌افزارشان الگوهای لازم را پشتیبانی می‌کند.
شرکت معتمد: وقتی حجم بالاست یا تیم مالی می‌خواهد مسئولیت فنی تبادل را برون‌سپاری کند. باید معلوم باشد چه کسی خطا را می‌بیند و چه کسی اصلاح می‌کند. مقایسه را در شرکت معتمد یا ارسال مستقیم بخوانید.
نرم‌افزار واسط جدا از حسابداری: سریع راه می‌افتد، اما دو منبع حقیقت می‌سازد. هر بار که در حسابداری فاکتور را اصلاح می‌کنید، باید یادتان باشد در واسط هم اصلاح شود. برای کسب‌وکار در حال رشد این مدل زود می‌شکند.
نقش نرم‌افزار حسابداری؛ نه فقط دکمهٔ ارسال
نرم‌افزار خوب سامانه مودیان فقط API ندارد. باید قبل از ارسال اعتبارسنجی کند، وضعیت را نگه دارد، اصلاحی را به فاکتور اصلی وصل کند و گزارش مغایرت با کارپوشه بدهد. اگر این‌ها نباشد، حسابدار بین اکسل، پنل سازمان و نرم‌افزار فروش گرفتار می‌شود.
در حسابیکس آرک فاکتور فروش همان سندی است که می‌تواند به سامانه برود؛ موجودی، شخص و مالیات از یک دفتر خوانده می‌شوند. نسخهٔ اصلی پلتفرم برای استفادهٔ اصلی رایگان و متن‌باز است. اگر هنوز بین ابزارها مردد هستید، مقالهٔ بهترین نرم‌افزار حسابداری متصل به سامانه مودیان ۱۴۰۵ معیار انتخاب را جدا از شعار تبلیغاتی جمع می‌کند.
یک نکتهٔ عملی برای تیم‌هایی که از چند کانال می‌فروشند: سفارش ووکامرس، فروش حضوری و فروش عمده نباید سه روش جدا برای ساخت صورتحساب داشته باشند. اگر کانال فروش فرق می‌کند ولی کالا و مشتری یکی است، الگوی سامانه و شناسه کالا باید همان باشد. صفحهٔ حسابداری فروش آنلاین و مارکت‌پلیس همین یکپارچگی را از زاویهٔ فروشگاه اینترنتی توضیح می‌دهد.
ارتباط صورتحساب با ارزش افزوده و اظهارنامه
سامانه مودیان جایگزین اظهارنامه نیست؛ خوراک آن است. اگر صورتحساب‌های ارسالی با فروش ثبت‌شده در دفتر یکی نباشد، در دورهٔ ارزش افزوده باید دستی توضیح بدهید. سه مغایرت کلاسیک این‌هاست:
- فاکتور در حسابداری هست ولی به سامانه نرفته یا رد شده و رها شده است.
- صورتحساب در کارپوشه موفق است ولی در دفتر کل سند فروش ندارد.
- برگشت از فروش در انبار ثبت شده اما سند برگشت به سامانه نرفته؛ خریدار هنوز آن خرید را در کارپوشه‌اش می‌بیند.
گزارش هفتگی ساده کافی است: تعداد فاکتور فروش، تعداد موفق سامانه، تعداد ردشده، مبلغ مالیات ارسالی. اگر این سه ستون از هم دور شدند همان هفته ببندید، نه در مهلت اظهارنامه. برای جریمه‌ها و دیرکرد، جزئیات جدا در مقالهٔ جرایم سامانه مودیان آمده است؛ اینجا اصل کار پیشگیری است نه چانه‌زنی بعد از خطا.
سؤالات پرتکرار
اگر صورتحساب رد شود باید فاکتور جدیدی بزنم؟
نه لزوماً. اول متن خطا را بخوانید. اگر داده قابل اصلاح است، همان فاکتور را درست کنید و دوباره بفرستید یا حسب مورد اصلاحی صادر کنید. فاکتور جدید بدون بستن تکلیف قبلی، فروش را دو بار در گزارش‌ها نشان می‌دهد.
فاکتور اصلاحی را مشتری هم باید تأیید کند؟
خریدار مؤدی معمولاً در کارپوشه اثر این سند را می‌بیند. بهتر است قبل از ارسال اصلاحی با خریدار هماهنگ کنید، مخصوصاً اگر مبلغ یا مالیات عوض می‌شود؛ وگرنه طرف مقابل در ارزش افزوده دچار مغایرت می‌شود.
فروش نقدی فروشگاه را هم باید همان روز بفرستم؟
مهلت قانونی را از آخرین بخشنامه بخوانید و محافظه‌کارانه عمل کنید. از نظر عملی، ارسال روزانه هم خطا را کوچک نگه می‌دارد هم فشار آخر دوره را کم می‌کند. انباشته کردن یک ماه فاکتور برای یک شب، دقیقاً جایی است که خطاها با هم قاطی می‌شوند.
آیا پیش‌فاکتور را هم باید به سامانه فرستاد؟
پیش‌فاکتور پیشنهاد قیمت است، معامله قطعی نیست. تا وقتی فروش قطعی و فاکتور صادر نشده، نباید آن را به عنوان صورتحساب اصلی بفرستید. تبدیل پیش‌فاکتور به فاکتور باید آگاهانه باشد.
جمع‌بندی
صورتحساب الکترونیکی سامانه مودیان در ۱۴۰۵ یعنی نظم در دادهٔ پایه: نوع و الگو درست، شناسه کالا معتبر، خریدار کامل، مالیات سازگار، و وضعیت ارسال خوانا. اگر این‌ها در همان نرم‌افزاری که فاکتور می‌زند قفل شود، کارپوشه دیگر محل غافلگیری آخر ماه نیست. از یک فاکتور واقعی امروز شروع کنید: پیش‌نمایش را با فاکتور مشتری مقایسه کنید، بفرستید، وضعیت را بخوانید و خطا را همان روز ببندید.