ข้ามไปยังเนื้อหา
Velarozone

คู่มือ

การตั้งค่าผู้ให้บริการเทคโนโลยี 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) เพราะแต่ละรูปแบบตอบสนองต่อส่วนที่แตกต่างกันของกฎระเบียบ

  1. ผู้จำหน่ายซอฟต์แวร์ ERP หรือซอฟต์แวร์บัญชี ที่จำหน่ายเครื่องมือซึ่งสร้างข้อมูลที่เป็นไปตามข้อกำหนด แต่อยู่นอกระบบแลกเปลี่ยนเอง
  2. ผู้รวมระบบ (systems integrator) ที่เชื่อมต่อระบบ ERP ของลูกค้าเข้ากับ ASP โดยไม่ได้เป็น ASP เอง
  3. Accredited Service Provider ที่นำพาใบแจ้งหนี้ผ่านระบบแลกเปลี่ยนในฐานะมุมที่ 1, 4 หรือ 5 (Corner 1, 4 or 5) ในนามของลูกค้า
  4. ชั้นงานด้านการปฏิบัติตามกฎระเบียบ การจัดเก็บเอกสาร หรือการวิเคราะห์ข้อมูล ที่สร้างขึ้นรอบข้อมูลหลังจากที่ข้อมูลนั้นถูกส่งไปแล้ว

การตัดสินใจสร้างเอง ร่วมมือ หรือใช้แบรนด์ของผู้อื่นตามมาจากเรื่องนี้ การแก้ไขเมื่อเดือนพฤษภาคม 2026 ที่อนุญาตให้บริษัทท้องถิ่นร่วมมือกับผู้ให้บริการต่างประเทศมีขึ้นเพราะผู้เข้าตลาดยูเออีส่วนใหญ่ไม่ได้สร้างโครงสร้างพื้นฐานการแลกเปลี่ยนตั้งแต่ศูนย์ แต่ขอใบอนุญาตใช้หรือใช้แบรนด์ของผู้อื่น ทางเลือกนั้นเปลี่ยนว่ากระทรวงรับรองใคร ใครลงนามสัญญากับลูกค้า และใครรับความเสี่ยงด้านการปฏิบัติตามกฎระเบียบหากเทคโนโลยีพื้นฐานล้มเหลว: สามคำถามแยกกันที่ชื่อบริษัทเดียวอาจบดบัง

เงินและความรับผิดเคลื่อนไหวผ่านระบบแลกเปลี่ยนอย่างไร

ธนาคารที่ประเมินธุรกิจนี้ต้องการเห็นรายได้ประจำจากซอฟต์แวร์หรือธุรกรรม ไม่ใช่เพียงใบอนุญาตการค้าที่ได้มาครั้งเดียว และจะถามว่าใครต้องรับผิดชอบเมื่อใบแจ้งหนี้ถูกปฏิเสธหรือส่งผิดพลาด: ผู้ขาย ผู้ผสานระบบ ASP หรือลูกค้า ควรกำหนดการจัดสรรนี้ไว้ในสัญญากับลูกค้าก่อนที่ใบแจ้งหนี้ฉบับแรกจะเคลื่อนไหว ไม่ใช่หลังเกิดข้อพิพาท

หากธุรกิจได้รับเงินทุนจากนักลงทุนหรือพันธมิตรด้านเทคโนโลยีระหว่างประเทศ แหล่งที่มาของเงินทุนและโครงสร้างของความร่วมมือมีความสำคัญทั้งต่อธนาคารและต่อการพิจารณาการรับรองของกระทรวง ควรจัดทำเอกสารแหล่งที่มาของเงินทุนควบคู่ไปกับคำขอด้านเทคนิค แทนที่จะทำภายหลัง การประเมินความพร้อมด้านธนาคารก่อนยื่นขอการรับรองมักช่วยให้คำถามเหล่านี้ปรากฏเร็วขึ้น ซึ่งเป็นช่วงที่ยังตอบได้ในต้นทุนต่ำ ต้นทุนในที่นี้ไม่ใช่ตัวเลขหลักเพียงตัวเดียว แต่ประกอบขึ้นเป็นชั้น ๆ ตั้งแต่การจัดตั้งนิติบุคคล การรับรอง และการปฏิบัติตามกฎระเบียบอย่างต่อเนื่อง และค่าบริการ Velarozone สำหรับการดำเนินการทั้งหมดนี้ระบุเป็นรายการในหนังสือข้อตกลงการให้บริการ (engagement letter) ดูวิธีที่ Velarozone ทำงาน

ข้อผิดพลาดที่พบได้ทั่วไป

  • การทำการตลาดในฐานะ ASP ที่ได้รับการอนุมัติ หรือบอกเป็นนัยว่าได้รับการรับรองแล้ว ก่อนที่ Ministry จะอนุมัติให้จริง
  • การถือว่าการแลกเปลี่ยนใบแจ้งหนี้แบบมีโครงสร้างเทียบเท่ากับการส่ง PDF ทางอีเมล ซึ่งนิยามของ Federal Tax Authority เองไม่นับรวมไว้
  • การปล่อยให้ความรับผิดสำหรับใบแจ้งหนี้ที่ถูกปฏิเสธหรือส่งผิดพลาดไม่มีการกำหนดไว้ในสัญญากับลูกค้า
  • การสมมติว่าใบอนุญาตการค้า (trade licence) ด้านซอฟต์แวร์เพียงอย่างเดียวเพียงพอต่อภาระผูกพันตามเกณฑ์รายได้ของลูกค้า
  • การสร้างความร่วมมือแบบไวท์เลเบล (white-label) โดยไม่บันทึกเป็นเอกสารว่านิติบุคคลใดที่ Ministry รับรองจริง ๆ

จากการรับรองสู่การดำเนินงานประจำวัน

การได้รับการรับรองไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว กระทรวงจะทบทวนการรับรองดังกล่าว ดังนั้นทีมเทคนิค การจัดเตรียมการโฮสต์ข้อมูล และรูปแบบการสนับสนุนจึงต้องคงเป็นไปตามที่ระบุไว้ในใบสมัคร ไม่เบี่ยงเบนไปเมื่อมีลูกค้าเข้าสู่ระบบแล้ว โดยทั่วไปบุคลากรด้านเทคนิคและด้านการปฏิบัติตามกฎระเบียบที่สำคัญต้องมีวีซ่าพำนักในสหรัฐอาหรับเอมิเรตส์ (UAE) ที่ผูกกับนิติบุคคลผู้ดำเนินงาน และบริษัทเองก็ต้องจดทะเบียนภาษีนิติบุคคลและภาษีมูลค่าเพิ่ม (VAT) เช่นเดียวกับธุรกิจอื่น ๆ ใน UAE การรับรองด้านใบกำกับภาษีอิเล็กทรอนิกส์ (eInvoicing) จึงอยู่เคียงข้างภาระภาษีตามปกติ ไม่ได้มาแทนที่ภาระเหล่านั้น

แผนการดำเนินงานที่จัดทำเป็นเอกสาร ซึ่งแยกปฏิทินการต่ออายุการรับรองออกจากการต่ออายุใบอนุญาตการค้าตามปกติ ทำให้ธุรกิจมีปฏิทินเดียวที่ต้องบริหารจัดการ แทนที่จะมีสองปฏิทินที่ค่อย ๆ คลาดเคลื่อนจากกันโดยไม่รู้ตัว ในกรณีที่บทบาทด้านการแลกเปลี่ยนข้อมูลอยู่ในนิติบุคคลหนึ่ง และการพัฒนาซอฟต์แวร์อยู่ในอีกนิติบุคคลหนึ่ง (พบได้บ่อยในโครงสร้างแบบพันธมิตรหรือแบบไวต์เลเบล) ควรถือว่าเป็นประเด็นเรื่องโครงสร้างความเป็นเจ้าของที่ซับซ้อน ที่ต้องแก้ไขให้เรียบร้อยก่อนที่นิติบุคคลใดนิติบุคคลหนึ่งจะยื่นสมัคร

ห้องประชุมสำนักงานทันสมัยที่มองเห็นเส้นขอบฟ้าของเมือง

คำแนะนำทั่วไปที่นี่; รายละเอียดที่สำคัญขึ้นอยู่กับกิจกรรมและตลาดของคุณ

คำถาม

คำถามที่พบบ่อย

บริษัทซอฟต์แวร์ eInvoicing ทุกแห่งต้องขอรับการรับรอง ASP หรือไม่
ไม่ต้องเสมอไป การรับรองมีผลกับบริษัทที่ทำหน้าที่เป็นมุมที่ 1, 4 หรือ 5 (Corner 1, 4 or 5) ในระบบแลกเปลี่ยนเท่านั้น ผู้จำหน่ายซอฟต์แวร์ ERP หรือซอฟต์แวร์บัญชี หรือผู้รวมระบบที่เชื่อมต่อลูกค้าเข้ากับ ASP ของผู้อื่น สามารถดำเนินการได้โดยไม่ต้องมีการรับรองนี้ ตราบใดที่ผลิตภัณฑ์ยังคงอยู่ฝั่งผู้จำหน่ายอย่างแท้จริง ไม่ได้นำพาใบแจ้งหนี้ผ่านระบบแลกเปลี่ยนเอง
จะเกิดอะไรขึ้นหากรายได้ของบริษัทต่ำกว่า 50 ล้านเดอร์แฮม?
กระทรวงการคลังระบุว่ากำหนดเวลาในภายหลังจะใช้กับธุรกิจที่มีรายได้ต่ำกว่า แต่ยังไม่ได้เผยแพร่วันที่เฉพาะเป็นข้อความที่สามารถตรวจสอบได้อย่างเป็นอิสระ ณ เวลาที่เขียนนี้ ให้ถือว่าวันที่ 30 ตุลาคม 2026 และวันที่ 1 มกราคม 2027 เป็นวันที่ได้รับการยืนยันสำหรับธุรกิจที่มีรายได้สูงกว่า 50 ล้านเดอร์แฮม และตรวจสอบพอร์ทัลใบกำกับภาษีอิเล็กทรอนิกส์ (eInvoicing) ของกระทรวงเองเพื่อดูสถานะล่าสุดสำหรับรายได้ต่ำกว่าเกณฑ์นั้น
ใครเป็นผู้รับผิดชอบเมื่อใบแจ้งหนี้ที่แลกเปลี่ยนถูกปฏิเสธ
เรื่องนี้ขึ้นอยู่กับสัญญา ไม่ใช่เทคโนโลยี ฝ่ายใดก็ตามที่สร้างการเชื่อมต่อระบบ ดำเนินการส่งข้อมูล หรือดำเนินขั้นตอนการแลกเปลี่ยนในจุดที่เกิดความล้มเหลว มักจะเป็นผู้รับผิดชอบ แต่จะเป็นเช่นนั้นก็ต่อเมื่อสัญญากับลูกค้าระบุไว้เช่นนั้น ควรตัดสินใจและบันทึกการจัดสรรความรับผิดนี้ไว้ก่อนรับลูกค้ารายแรกเข้าร่วม ไม่ใช่หลังจากถูกปฏิเสธไปแล้ว
เทคโนโลยีของผู้ให้บริการที่ได้รับการรับรองสามารถนำไปใช้ภายใต้แบรนด์หรือนิติบุคคลอื่นได้หรือไม่
ได้ และการแก้ไขเพิ่มเติมของกระทรวงเมื่อเดือนพฤษภาคม 2026 ก็มีวัตถุประสงค์ส่วนหนึ่งเพื่อให้ทำได้ง่ายขึ้น โดยอนุญาตให้บริษัทในสหรัฐอาหรับเอมิเรตส์ร่วมมือกับผู้ให้บริการระดับนานาชาติเพื่อนำระบบหลักเข้ามาใช้ สิ่งที่กระทรวงให้ความสำคัญคือนิติบุคคลใดที่กำลังได้รับการรับรองจริง และนิติบุคคลใดที่ต้องรับผิดชอบต่อบริการนั้น ไม่ใช่ชื่อที่ปรากฏอยู่บนแบรนด์ที่ลูกค้ามองเห็น

รับแผนการตั้งค่าใน UAE ของคุณ

ธุรกิจใบแจ้งหนี้อิเล็กทรอนิกส์จะอยู่รอดหรือไม่นั้น ขึ้นอยู่กับว่าธุรกิจนั้นอยู่ที่มุมใดของการแลกเปลี่ยนจริง และควรตัดสินใจเรื่องนี้ให้แล้วเสร็จก่อนที่จะเลือกเขตอำนาจทางกฎหมาย (jurisdiction) หรือธนาคาร Velarozone จะตรวจสอบธุรกิจนั้นเทียบกับข้อกำหนดการรับรองของ Ministry of Finance พิจารณาว่าสถานะที่เหมาะสมคือผู้จำหน่าย ผู้ผนวกระบบ หรือผู้ให้บริการที่ได้รับการรับรอง (ASP) และกำหนดราคาการจัดตั้งเมื่อคำตอบชัดเจนแล้ว

ใช้เรื่องนี้กับสถานการณ์ของคุณ

คู่มือจะอธิบายตำแหน่งทั่วไป ส่งข้อมูลของคุณให้เราและผู้ให้คำปรึกษาจะแจ้งให้คุณทราบว่าส่วนใดที่ใช้ได้จริงกับคุณ

ส่งข้อความหเราใน WhatsApp

การประเมินฟรี: ตัวเลขล่าสุดจะได้รับการยืนยันในการเปรียบเทียบเส้นทางที่ที่ปรึกษาตรวจสอบแล้วสำหรับท่าน ข้อมูลของท่านจะไม่ถูกแบ่งปันกับบุคคลที่สาม

เริ่มด้วยการประเมินโครงสร้าง

ในการปรึกษาครั้งแรก คุณจะได้รับสารสรุปการตัดสินใจที่ใช้ภาษาง่าย รายการการเตรียมเอกสาร และขั้นตอนถัดไปสำหรับสถานการณ์ของคุณ ตัวเลขปัจจุบันได้รับการยืนยันภายในการเปรียบเทียบเส้นทางที่ตรวจสอบโดยที่ปรึกษาของคุณ。

คู่มือนี้ให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำด้านกฎหมาย, กฎระเบียบ, ภาษี, การลงทุน หรือการเงิน มันไม่ได้รับประกันใบอนุญาต, การอนุญาต, วีซ่า, บัญชีธนาคาร, เงินทุน หรือผลลัพธ์ด้านภาษี.

ข้อมูลทั่วไปที่ดึงมาจาก CBUAE Rulebook รวมถึง Retail Payment Services and Card Schemes Regulation (C 15/2021) และ Cabinet Resolution No. (134) of 2025 ตามที่เผยแพร่ ไม่ใช่คำแนะนำทางกฎหมายหรือภาษี กฎและแนวทางเปลี่ยนแปลงได้ จึงควรยืนยันข้อความฉบับปัจจุบันและข้อกำหนดของแต่ละสถาบันก่อนยื่น

หน้าแปล. หน้านี้เป็นการแปลจากเวอร์ชันภาษาอังกฤษ หากทั้งสองเวอร์ชันแตกต่างกัน เวอร์ชันภาษาอังกฤษจะมีผลบังคับใช้ ความต้องการอย่างเป็นทางการจะถูกกำหนดโดยหน่วยงานของรัฐบาลกลางและของเอมิเรต และทะเบียนเขตอิสระ และเอกสารที่มาหลายรายการจะถูกเผยแพร่เป็นภาษาอารบิก, เมื่อต้องการทำงานควรตรวจสอบเอกสารต้นฉบับหรือสอบถามเราก่อน.