فاکتور الکترونیکی امارات: پیش از مهلت ۳۰ اکتبر برای انتخاب ASP چه چیزی را درست کنیم

اگر گردش مالی سالانه‌ی شرکت شما در امارات ۵۰ میلیون درهم یا بیشتر است، ۳۰ اکتبر ۲۰۲۶ (۸ آبان ۱۴۰۵) آخرین مهلت انتخاب «ارائه‌دهنده‌ی خدمات معتبر» (ASP) برای فاکتور الکترونیکی است. اجرای کامل از ۱ ژانویه‌ی ۲۰۲۷ شروع می‌شود. وزارت دارایی امارات یک بار این مهلت را از ۳۱ ژوئیه عقب انداخته و صریح گفته که تاریخ ژانویه تغییری نکرده است.

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

وضعیت در سپتامبر ۲۰۲۶

• مبنای قانونی، تصمیم‌های وزارتی شماره‌ی ۲۴۳ و ۲۴۴ سال ۲۰۲۵ است. تصمیم ۲۴۳ چارچوب را تعیین می‌کند (دامنه، نقش ASP، مدل داده، بایگانی) و تصمیم ۲۴۴ مرحله‌ها و مهلت‌ها را.
• در ۱۰ مه ۲۰۲۶ وزارت دارایی مهلت انتخاب ASP را برای کسب‌وکارهای بالای ۵۰ میلیون درهم از ۳۱ ژوئیه به ۳۰ اکتبر ۲۰۲۶ تمدید کرد، اجرای کامل را همان ۱ ژانویه‌ی ۲۰۲۷ نگه داشت و اعلام کرد تا آن زمان ۳۲ ارائه‌دهنده تأیید شده‌اند.
• کسب‌وکارهای زیر ۵۰ میلیون درهم تا ۳۱ مارس ۲۰۲۷ ASP انتخاب می‌کنند و از ۱ ژوئیه‌ی ۲۰۲۷ وارد می‌شوند. نهادهای دولتی از ۱ اکتبر ۲۰۲۷. پیوستن داوطلبانه از ۱ ژوئیه‌ی ۲۰۲۶ باز شده است (خلاصه‌ی Andersen).
• دامنه شامل معاملات بین کسب‌وکارها (B2B) و با دولت (B2G) است. فروش به مصرف‌کننده (B2C) فعلاً خارج است، همین‌طور برخی خدمات مالی و بلیت مسافری هواپیما (KPMG).
• جریمه‌ها طبق تصمیم هیئت وزیران شماره‌ی ۱۰۶ سال ۲۰۲۵ از تاریخ شروع هر مرحله اعمال می‌شوند: ماهانه ۵٬۰۰۰ درهم برای اجرا نکردن، ۱۰۰ درهم برای هر فاکتوری که دیر ارسال شود (سقف ماهانه ۵٬۰۰۰ درهم) و روزانه ۱٬۰۰۰ درهم برای گزارش نکردن خرابی سیستم یا تغییر داده‌ها (VATupdate).

در عمل چه چیزی عوض می‌شود

فایل PDF پیوست‌شده به ایمیل دیگر خودِ فاکتور نیست. فاکتور یک سند ساخت‌یافته‌ی XML در قالب PINT AE (نسخه‌ی اماراتی فاکتور بین‌المللی Peppol) می‌شود و از یک مدل پنج‌گوشه عبور می‌کند. Boru Consulting این پنج گوشه را چنین توضیح می‌دهد: سیستم مبدأ فروشنده، ASP فروشنده (که فاکتور را با PINT AE تطبیق می‌دهد و از شبکه‌ی Peppol می‌فرستد)، ASP خریدار، سیستم دریافت خریدار، و سازمان مالیات فدرال (FTA) که داده‌ی مالیاتی را از ASP فروشنده می‌گیرد.

دو نتیجه معمولاً از قلم می‌افتد. اول اینکه خریدار هم به ASP نیاز دارد؛ یعنی تیم حساب‌های پرداختنی هم شیوه‌ی دریافت فاکتور را عوض می‌کند، نه فقط تیم فروش شیوه‌ی صدورش را. دوم اینکه کل این زنجیره فقط به اندازه‌ی کیفیت داده‌ای است که سیستم مبدأ شما تولید می‌کند. شماره‌ی ثبت مالیاتی (TRN) ناقص خریدار یا دسته‌ی اشتباه مالیات بر ارزش افزوده دیگر با ویرایش یک PDF بی‌سروصدا درست نمی‌شود. فاکتور رد می‌شود، و فاکتور ردشده‌ای که کسی متوجهش نشود، تبدیل به فاکتور دیرکرد می‌شود.

همه‌ی سیستم‌هایی را که فاکتور صادر می‌کنند فهرست کنید، نه فقط ERP

معمولاً فروشنده‌ی ERP یک رابط آماده دارد. مشکل جاهای دیگری است که به مشتری صورت‌حساب می‌دهند. در شرکت‌هایی که با آن‌ها کار می‌کنیم، این‌ها رایج‌ترند:

• یک اپلیکیشن سفارشی صورت‌حساب یا اشتراک که فاکتورهای خودش را می‌فرستد،
• فروشگاه آنلاین یا پرتال مشتری که برای خریداران سازمانی فاکتور مالیاتی صادر می‌کند،
• ماژول خدمات یا نگهداری که کار قراردادی را صورت‌حساب می‌کند،
• اعلامیه‌های بستانکاری (credit note) که دستی در اکسل ساخته و ایمیل می‌شوند.

اعلامیه‌ی بستانکاری تابع همان قواعد فاکتور است و خلاصه‌ی Andersen می‌گوید هر دو باید ظرف ۱۴ روز از معامله صادر شوند. اگر امروز این اعلامیه‌ها در اکسل‌اند، با فرایندی سروکار دارید که باید از نو ساخته شود، نه فیلدی که فقط باید نگاشت شود. این فهرست‌برداری فرصت خوبی هم هست برای پیدا کردن اتصال‌های مستقیم و مستندنشده بین سیستم‌ها؛ همان مشکلی که در چرا سیستم‌های سازمانی با هم یکپارچه نمی‌شوند درباره‌اش نوشته‌ایم.

درسی که از اتصال درگاه پرداخت خودمان گرفتیم

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

درگاه شناسه‌ی ارجاع را به‌صورت عدد در JSON برمی‌گرداند و کد ما رشته انتظار داشت. نتیجه اینکه هر درخواست در سمت ما خطا می‌داد، آن هم بعد از اینکه درگاه تراکنش را واقعاً ساخته بود. کاربر پیغام خطا می‌دید و در طرف مقابل یک تراکنش واقعی وجود داشت. به زبان فاکتور الکترونیکی: فاکتوری که ASP پذیرفته، در حالی که ERP شما فکر می‌کند ارسال شکست خورده. اگر منطق تلاش مجدد فقط دوباره بفرستد، یک فاکتور تکراری نزد سازمان مالیات دارید.

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

چیزی که عوض کردیم، و چیزی که از هر اتصال به ASP انتظار داریم:

• نوع شناسه‌ها را یک بار، در همان لایه‌ای که با ارائه‌دهنده حرف می‌زند، یکسان کنید؛ نه در پنج جای مختلف.
• شماره‌ی فاکتور خودتان را کلید جلوگیری از تکرار قرار دهید. قبل از هر تلاش مجدد، وضعیت همان شماره را از ASP بپرسید، نه اینکه دوباره بفرستید.
• «ASP دریافتش کرد» و «فاکتور اعتبارسنجی و تحویل شد» را دو وضعیت جدا بدانید. شناسه‌ی پیام ASP و هر تغییر وضعیت را ذخیره کنید. یک ریدایرکت یا پاسخ 200 چیزی را ثابت نمی‌کند.
• یک صفحه یا کوئری داشته باشید که جواب دهد «کدام فاکتورهای هفته‌ی گذشته هنوز به وضعیت نهایی نرسیده‌اند؟» اگر برای این کار برنامه‌نویس لازم باشد، کسی بررسی‌اش نمی‌کند.

خرابی‌ای را که نبینید، نمی‌توانید گزارش کنید

قواعد می‌گویند خرابی فنی باید ظرف ۲ روز کاری به FTA گزارش شود و تغییر داده‌های ثبت‌شده ظرف ۵ روز کاری به ASP اطلاع داده شود (Andersen). هر دو فرض می‌کنند شما می‌دانید چیزی خراب شده است. اتصالی که بی‌صدا شکست بخورد پرهزینه‌ترین حالت است، چون جریمه‌ی گزارش نکردن روزانه حساب می‌شود.

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

داده‌های پایه و محل نگهداری داده

بیشتر ردشدن‌های اولیه از داده‌های پایه می‌آیند، نه از کد. TRN طرف‌های معامله، کد کالاها و دسته‌ی مالیات هر ردیف دفتر کل را قبل از شروع بررسی کنید، نه بعدش. چک‌لیست Boru هم دقیقاً به همین دلیل پاک‌سازی داده‌های پایه را کنار انتخاب ASP گذاشته است.

تصمیم ۲۴۳ قواعد بایگانی و حاکمیت داده هم دارد و خلاصه‌ی Andersen می‌گوید داده‌ی فاکتور الکترونیکی باید داخل امارات نگهداری شود. بپرسید هر نسخه واقعاً کجاست: ERP اگر ابری است، ASP، بایگانی ایمیل که هنوز نسخه‌های PDF را نگه داشته، و نسخه‌های پشتیبان. این همان سؤالی است که درباره‌ی سرور ایمیل از ما می‌پرسند و استدلال چرا شرکت‌ها در ۲۰۲۶ هنوز ایمیل را روی سرور خودشان نگه می‌دارند اینجا هم صدق می‌کند. مدت و قالب دقیق بایگانی را با مشاور مالیاتی‌تان تأیید کنید؛ این مقاله مشاوره‌ی مالیاتی نیست.

برنامه‌ی چهار هفته‌ای تا ۳۰ اکتبر

1. هفته‌ی اول: همه‌ی سیستم‌هایی که فاکتور یا اعلامیه‌ی بستانکاری صادر می‌کنند و همه‌ی سیستم‌هایی که فاکتور تأمین‌کننده دریافت می‌کنند را فهرست کنید و برای هرکدام یک مسئول تعیین کنید.
2. هفته‌ی دوم: فهرست کوتاه ASPها را بر اساس کیفیت API هم بچینید، نه فقط قیمت. محیط تست، مدل وضعیت‌ها، نحوه‌ی برخورد با تکرار و کدهای خطا را بخواهید و بپرسید داده‌هایشان کجا میزبانی می‌شود.
3. هفته‌ی سوم: داده‌های پایه را پاک‌سازی کنید (TRN خریداران، کد کالا، دسته‌های مالیاتی) و یک فاکتور واقعی از هر سیستم مبدأ را به فیلدهای PINT AE نگاشت کنید.
4. هفته‌ی چهارم: قرارداد ASP را ببندید، سپس از هر مبدأ فاکتور آزمایشی در محیط تست بفرستید؛ شامل یک خطای عمدی و یک تلاش مجدد. مطمئن شوید هر دو را در سوابق خودتان می‌بینید.

بعد از ۳۰ اکتبر کار تا ۱ ژانویه ادامه دارد، اما در آن مرحله سؤال باید این باشد که اتصال چقدر خوب کار می‌کند، نه اینکه کدام ارائه‌دهنده را انتخاب کنیم.

جایگاه فنپینو

ما ASP نیستیم و چیزی به FTA ارسال نمی‌کنیم. کار ما همان سمتِ شماست: وصل کردن اپلیکیشن‌های داخلی صورت‌حساب، پرتال‌ها و سیستم‌های خدمات به ASPی که انتخاب می‌کنید، با ارسال بدون تکرار، پیگیری وضعیت و لاگ‌هایی که تیم مالی بتواند بخواند. اگر یکی از منابع فاکتور شما سیستمی سفارشی است که کسی دوست ندارد به آن دست بزند، معمولاً کار ما از همان‌جا شروع می‌شود.

منابع

• وزارت دارایی امارات: اصلاحات هدفمند در تصمیم‌های سامانه‌ی فاکتور الکترونیکی (۱۰ مه ۲۰۲۶)
• Andersen امارات: تصمیم‌های وزارتی ۲۴۳ و ۲۴۴ سال ۲۰۲۵
• KPMG: اجرای سامانه‌ی فاکتور الکترونیکی در امارات
• VATupdate: جریمه‌های عدم رعایت فاکتور الکترونیکی (تصمیم هیئت وزیران ۱۰۶ سال ۲۰۲۵)
• Boru Consulting: مهلت ۳۰ اکتبر ۲۰۲۶ برای انتخاب ASP