คู่มือ
การตั้งค่าผู้ให้บริการเทคโนโลยี eInvoicing หรือ ASP ในสหรัฐอาหรับเอมิเรตส์
คำตอบสั้นๆ
กระทรวงการคลังกำหนดกรอบการออกใบแจ้งหนี้อิเล็กทรอนิกส์ (eInvoicing) ของสหรัฐอาหรับเอมิเรตส์และรับรองผู้ให้บริการ ส่วนหน่วยงานภาษีของรัฐบาลกลาง (Federal Tax Authority) ดำเนินการระบบแลกเปลี่ยนและระบบ EmaraTax ซึ่งธุรกิจใช้เลือกผู้ให้บริการ สิทธิที่สำคัญคือสถานะผู้ให้บริการที่ได้รับการรับรอง (Accredited Service Provider หรือ ASP) ตามคำวินิจฉัยของรัฐมนตรี ฉบับที่ 64 ปี 2025 ซึ่งแตกต่างจากใบอนุญาตการค้าด้านเทคโนโลยีทั่วไป ที่บริษัทสามารถถือไว้ได้โดยไม่ต้องเกี่ยวข้องกับระบบแลกเปลี่ยนที่อยู่ภายใต้การกำกับดูแลเลย คำถามที่ชี้ขาดเส้นทางนั้นเรียบง่าย: บริษัทแลกเปลี่ยนใบแจ้งหนี้ในฐานะหนึ่งในสี่มุม (corner) หรือจัดหาซอฟต์แวร์ให้แก่ผู้ที่ทำเช่นนั้น
โมเดลสี่มุม (four-corner model) และใครเป็นผู้ตัดสินบทบาทของคุณ
ระบบแลกเปลี่ยนทำงานบนโมเดลสี่มุม (four-corner model) โดยมุมที่ 1 (Corner 1) คือผู้จำหน่ายที่ออกใบแจ้งหนี้ มุมที่ 4 คือลูกค้าผู้รับใบแจ้งหนี้ และทั้งสองฝ่ายแลกเปลี่ยนข้อมูลใบแจ้งหนี้แบบมีโครงสร้างผ่านตัวกลางที่ได้รับการรับรอง แทนที่จะส่งเป็น PDF ทางอีเมล มุมที่ 5 รายงานข้อมูลเดียวกันนี้ไปยัง Federal Tax Authority เพื่อวัตถุประสงค์ทางภาษี และมุมรายงานนี้เริ่มใช้งานจริงก่อนโครงการนำร่องซึ่งเริ่มต้นเมื่อวันที่ 1 กรกฎาคม 2026
ธุรกิจไม่สามารถประกาศตนเป็นส่วนหนึ่งของห่วงโซ่นี้ได้เอง ASP ได้รับการรับรองจากกระทรวงการคลัง และลูกค้าเลือก ASP ของตนโดยทำข้อตกลงเชิงพาณิชย์และเลือกผ่านระบบ EmaraTax ของหน่วยงานภาษีของรัฐบาลกลาง หากผลิตภัณฑ์ของบริษัทเพียงจัดเตรียมหรือแสดงข้อมูลใบแจ้งหนี้โดยไม่ส่งผ่านระบบแลกเปลี่ยน บริษัทนั้นไม่ได้ทำหน้าที่เป็น Corner 1, 4 หรือ 5 และการรับรองน่าจะไม่เกี่ยวข้อง แต่นั่นเป็นคำถามเกี่ยวกับสิ่งที่ซอฟต์แวร์ทำจริง ไม่ใช่สิ่งที่ใบอนุญาตการค้าเรียกไว้
สิ่งที่กระทรวงการคลังและ Federal Tax Authority กำหนดไว้จริง
คำวินิจฉัยของรัฐมนตรีสามฉบับมีน้ำหนักทางกฎหมายในเรื่องนี้ No. 243 of 2025 จัดตั้งระบบ eInvoicing; No. 244 of 2025 กำหนดขั้นตอนการปฏิบัติ; No. 64 of 2025 กำหนดว่าใครสามารถเป็น Accredited Service Provider ได้และด้วยวิธีใด Federal Tax Authority ให้นิยาม eInvoicing ไว้อย่างจำกัด คือ ข้อมูลใบแจ้งหนี้แบบมีโครงสร้างที่ออกและแลกเปลี่ยนกันทางอิเล็กทรอนิกส์ ซึ่งไม่รวมถึงไฟล์ PDF หรือใบแจ้งหนี้ที่ส่งทางอีเมลไม่ว่าจะจัดรูปแบบมาอย่างเรียบร้อยเพียงใดก็ตาม
สำหรับธุรกิจที่มีรายได้ต่อปีเกิน 50 ล้านดิรฮัม กระทรวงได้กำหนดสองวันที่: แต่งตั้ง ASP ภายในวันที่ 30 ตุลาคม 2026 (ขยายเวลาในเดือนพฤษภาคม 2026 จากกำหนดเดิมคือวันที่ 31 กรกฎาคม 2026) และให้ระบบพร้อมใช้งานภายในวันที่ 1 มกราคม 2027 กระทรวงระบุว่ากลุ่มรายได้อื่นและหน่วยงานรัฐบาลจะเป็นไปตามกำหนดการที่ตามมาภายหลัง แต่ ณ เวลาที่เขียนนี้ได้เผยแพร่กำหนดการดังกล่าวเป็นรูปภาพบนพอร์ทัลของตนเองแทนที่จะเป็นข้อความ ดังนั้นคู่มือนี้จึงไม่ระบุวันที่เฉพาะสำหรับธุรกิจที่มีรายได้ต่ำกว่าเกณฑ์ 50 ล้านดิรฮัม โปรดตรวจสอบพอร์ทัล eInvoicing ฉบับปัจจุบันของกระทรวงก่อนยึดถือวันที่ใด ๆ
ภายในเดือนพฤษภาคม 2026 Ministry ได้อนุมัติผู้ให้บริการไปแล้ว 32 ราย โดยมีรายอื่น ๆ อยู่ในขั้นตอนสุดท้ายของการรับรอง และได้แก้ไขกฎระเบียบให้บริษัท UAE สามารถร่วมมือกับผู้ให้บริการระดับนานาชาติ เพื่อนำเทคโนโลยีและความรู้เชิงเทคนิคเข้ามาได้
ผู้จำหน่าย ผู้รวมระบบ หรือ ASP: การตัดสินใจเรื่องโครงสร้างที่เปลี่ยนคำตอบ
กำหนดให้ชัดเจนว่าธุรกิจเป็นรูปแบบใดจริง ๆ ก่อนเปรียบเทียบเขตอำนาจทางกฎหมาย (jurisdiction) เพราะแต่ละรูปแบบตอบสนองต่อส่วนที่แตกต่างกันของกฎระเบียบ
- ผู้จำหน่ายซอฟต์แวร์ ERP หรือซอฟต์แวร์บัญชี ที่จำหน่ายเครื่องมือซึ่งสร้างข้อมูลที่เป็นไปตามข้อกำหนด แต่อยู่นอกระบบแลกเปลี่ยนเอง
- ผู้รวมระบบ (systems integrator) ที่เชื่อมต่อระบบ ERP ของลูกค้าเข้ากับ ASP โดยไม่ได้เป็น ASP เอง
- Accredited Service Provider ที่นำพาใบแจ้งหนี้ผ่านระบบแลกเปลี่ยนในฐานะมุมที่ 1, 4 หรือ 5 (Corner 1, 4 or 5) ในนามของลูกค้า
- ชั้นงานด้านการปฏิบัติตามกฎระเบียบ การจัดเก็บเอกสาร หรือการวิเคราะห์ข้อมูล ที่สร้างขึ้นรอบข้อมูลหลังจากที่ข้อมูลนั้นถูกส่งไปแล้ว
การตัดสินใจสร้างเอง ร่วมมือ หรือใช้แบรนด์ของผู้อื่นตามมาจากเรื่องนี้ การแก้ไขเมื่อเดือนพฤษภาคม 2026 ที่อนุญาตให้บริษัทท้องถิ่นร่วมมือกับผู้ให้บริการต่างประเทศมีขึ้นเพราะผู้เข้าตลาดยูเออีส่วนใหญ่ไม่ได้สร้างโครงสร้างพื้นฐานการแลกเปลี่ยนตั้งแต่ศูนย์ แต่ขอใบอนุญาตใช้หรือใช้แบรนด์ของผู้อื่น ทางเลือกนั้นเปลี่ยนว่ากระทรวงรับรองใคร ใครลงนามสัญญากับลูกค้า และใครรับความเสี่ยงด้านการปฏิบัติตามกฎระเบียบหากเทคโนโลยีพื้นฐานล้มเหลว: สามคำถามแยกกันที่ชื่อบริษัทเดียวอาจบดบัง
เงินและความรับผิดเคลื่อนไหวผ่านระบบแลกเปลี่ยนอย่างไร
ธนาคารที่ประเมินธุรกิจนี้ต้องการเห็นรายได้ประจำจากซอฟต์แวร์หรือธุรกรรม ไม่ใช่เพียงใบอนุญาตการค้าที่ได้มาครั้งเดียว และจะถามว่าใครต้องรับผิดชอบเมื่อใบแจ้งหนี้ถูกปฏิเสธหรือส่งผิดพลาด: ผู้ขาย ผู้ผสานระบบ ASP หรือลูกค้า ควรกำหนดการจัดสรรนี้ไว้ในสัญญากับลูกค้าก่อนที่ใบแจ้งหนี้ฉบับแรกจะเคลื่อนไหว ไม่ใช่หลังเกิดข้อพิพาท
หากธุรกิจได้รับเงินทุนจากนักลงทุนหรือพันธมิตรด้านเทคโนโลยีระหว่างประเทศ แหล่งที่มาของเงินทุนและโครงสร้างของความร่วมมือมีความสำคัญทั้งต่อธนาคารและต่อการพิจารณาการรับรองของกระทรวง ควรจัดทำเอกสารแหล่งที่มาของเงินทุนควบคู่ไปกับคำขอด้านเทคนิค แทนที่จะทำภายหลัง การประเมินความพร้อมด้านธนาคารก่อนยื่นขอการรับรองมักช่วยให้คำถามเหล่านี้ปรากฏเร็วขึ้น ซึ่งเป็นช่วงที่ยังตอบได้ในต้นทุนต่ำ ต้นทุนในที่นี้ไม่ใช่ตัวเลขหลักเพียงตัวเดียว แต่ประกอบขึ้นเป็นชั้น ๆ ตั้งแต่การจัดตั้งนิติบุคคล การรับรอง และการปฏิบัติตามกฎระเบียบอย่างต่อเนื่อง และค่าบริการ Velarozone สำหรับการดำเนินการทั้งหมดนี้ระบุเป็นรายการในหนังสือข้อตกลงการให้บริการ (engagement letter) ดูวิธีที่ Velarozone ทำงาน
ข้อผิดพลาดที่พบได้ทั่วไป
- การทำการตลาดในฐานะ ASP ที่ได้รับการอนุมัติ หรือบอกเป็นนัยว่าได้รับการรับรองแล้ว ก่อนที่ Ministry จะอนุมัติให้จริง
- การถือว่าการแลกเปลี่ยนใบแจ้งหนี้แบบมีโครงสร้างเทียบเท่ากับการส่ง PDF ทางอีเมล ซึ่งนิยามของ Federal Tax Authority เองไม่นับรวมไว้
- การปล่อยให้ความรับผิดสำหรับใบแจ้งหนี้ที่ถูกปฏิเสธหรือส่งผิดพลาดไม่มีการกำหนดไว้ในสัญญากับลูกค้า
- การสมมติว่าใบอนุญาตการค้า (trade licence) ด้านซอฟต์แวร์เพียงอย่างเดียวเพียงพอต่อภาระผูกพันตามเกณฑ์รายได้ของลูกค้า
- การสร้างความร่วมมือแบบไวท์เลเบล (white-label) โดยไม่บันทึกเป็นเอกสารว่านิติบุคคลใดที่ Ministry รับรองจริง ๆ
จากการรับรองสู่การดำเนินงานประจำวัน
การได้รับการรับรองไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว กระทรวงจะทบทวนการรับรองดังกล่าว ดังนั้นทีมเทคนิค การจัดเตรียมการโฮสต์ข้อมูล และรูปแบบการสนับสนุนจึงต้องคงเป็นไปตามที่ระบุไว้ในใบสมัคร ไม่เบี่ยงเบนไปเมื่อมีลูกค้าเข้าสู่ระบบแล้ว โดยทั่วไปบุคลากรด้านเทคนิคและด้านการปฏิบัติตามกฎระเบียบที่สำคัญต้องมีวีซ่าพำนักในสหรัฐอาหรับเอมิเรตส์ (UAE) ที่ผูกกับนิติบุคคลผู้ดำเนินงาน และบริษัทเองก็ต้องจดทะเบียนภาษีนิติบุคคลและภาษีมูลค่าเพิ่ม (VAT) เช่นเดียวกับธุรกิจอื่น ๆ ใน UAE การรับรองด้านใบกำกับภาษีอิเล็กทรอนิกส์ (eInvoicing) จึงอยู่เคียงข้างภาระภาษีตามปกติ ไม่ได้มาแทนที่ภาระเหล่านั้น
แผนการดำเนินงานที่จัดทำเป็นเอกสาร ซึ่งแยกปฏิทินการต่ออายุการรับรองออกจากการต่ออายุใบอนุญาตการค้าตามปกติ ทำให้ธุรกิจมีปฏิทินเดียวที่ต้องบริหารจัดการ แทนที่จะมีสองปฏิทินที่ค่อย ๆ คลาดเคลื่อนจากกันโดยไม่รู้ตัว ในกรณีที่บทบาทด้านการแลกเปลี่ยนข้อมูลอยู่ในนิติบุคคลหนึ่ง และการพัฒนาซอฟต์แวร์อยู่ในอีกนิติบุคคลหนึ่ง (พบได้บ่อยในโครงสร้างแบบพันธมิตรหรือแบบไวต์เลเบล) ควรถือว่าเป็นประเด็นเรื่องโครงสร้างความเป็นเจ้าของที่ซับซ้อน ที่ต้องแก้ไขให้เรียบร้อยก่อนที่นิติบุคคลใดนิติบุคคลหนึ่งจะยื่นสมัคร

