ERP, e-Tax Invoice และ PromptBiz ในไทย (2026)

ผู้จัดการฝ่ายการเงินอ่านข่าวว่าคณะรัฐมนตรีอนุมัติมาตรการลดหย่อนภาษี 200% สำหรับค่าใช้จ่าย e-Tax Invoice แล้วคิดว่านี่คือเส้นตายที่มาถึงแล้วในที่สุด ซื้อซอฟต์แวร์ ติ๊กช่องปฏิบัติตามกฎหมาย จบ แต่นักบัญชีชี้ให้เห็นสิ่งที่ไม่ค่อยสะดวกใจนัก คือ e-Tax Invoice ในไทยยังคงเป็นระบบแบบสมัครใจ ไม่มีข้อบังคับทางกฎหมายให้ต้องใช้ในการซื้อขายแบบ B2B สำหรับปี 2569 หรือ 2570 มาตรการนี้ไม่ใช่เส้นตาย แต่เป็นคำเชิญ และธุรกิจยังต้องตัดสินใจเองว่าข้อมูลของตัวเองพร้อมรับคำเชิญนั้นจริงหรือไม่

คณะรัฐมนตรีของไทยอนุมัติมาตรการชุดปัจจุบันเมื่อวันที่ 16 มิถุนายน 2569 คือลดอัตราภาษีหัก ณ ที่จ่ายอิเล็กทรอนิกส์ให้เหลือ 1% แบบเดียวกันทุกประเภท และให้หักรายจ่ายได้ 200% สำหรับค่าใช้จ่ายที่เข้าเงื่อนไขในระบบ e-Tax Invoice, e-Receipt และ e-Withholding โดยขยายมาตรการทั้งสองไปจนถึงวันที่ 31 ธันวาคม 2570 ธุรกิจขนาดเล็กก็มีทางเข้าที่ง่ายกว่าด้วย เพราะเส้นทาง e-Tax Invoice by Email แบบง่าย ยังเปิดให้ธุรกิจที่มีรายได้ไม่เกิน 30 ล้านบาทใช้ได้ โดยไม่ต้องตั้งค่าระบบ XML แบบเต็มรูปแบบ

ฟังดูเหมือนเป็นการตัดสินใจเรื่องการปฏิบัติตามกฎหมายภาษี แต่จริง ๆ แล้วเป็นการตัดสินใจเรื่องการจับคู่ข้อมูลต่างหาก มาตรการนี้ให้รางวัลกับธุรกิจที่ใบแจ้งหนี้ การชำระเงิน และใบเสร็จ สามารถจับคู่กันได้อย่างน่าเชื่อถือด้วยเอกสารอ้างอิงอยู่แล้ว ไม่ใช่ธุรกิจที่แค่ซื้อซอฟต์แวร์ e-Tax แล้วแปลงกระดาษเป็น PDF การแปลงใบแจ้งหนี้กระดาษเป็น PDF ไม่เคยเป็นส่วนที่ยากอยู่แล้ว ส่วนที่ยากคือการจับคู่มันกับการชำระเงินที่ถูกต้องได้อย่างน่าเชื่อถือต่างหาก

เอกสารดิจิทัลจะใช้งานได้จริง เมื่อเหตุการณ์ทางธุรกิจ ข้อมูลหลัก การอนุมัติ และเอกสารอ้างอิงการชำระเงินตรงกัน

บทความนี้จะครอบคลุมว่าระบบ e-Tax ของกรมสรรพากรและโครงสร้างพื้นฐาน PromptBiz ของธนาคารแห่งประเทศไทยเชื่อมอะไรกันจริง ๆ "พร้อมสำหรับ ERP" หมายถึงอะไรแยกจาก "ธนาคารหรือผู้ให้บริการของคุณพร้อมแล้ว" และเช็กลิสต์ที่ใช้ได้จริงสำหรับทดสอบกรณีที่มักพังก่อนใคร

ทำความเข้าใจภาพรวมทางการก่อนตัดสินใจ

กรมสรรพากรของไทยดูแลบริการ e-Tax Invoice และ e-Receipt ครอบคลุมการลงทะเบียน การตรวจสอบโครงสร้างเอกสาร และการส่งข้อมูลแบบ host-to-host การเข้าร่วมยังคงเป็นแบบสมัครใจ ไม่มีเกณฑ์รายได้บังคับให้ต้องใช้ แม้ว่าเส้นทางแบบง่ายผ่านอีเมลจะจำกัดไว้ที่รายได้ต่อปีไม่เกิน 30 ล้านบาท สำหรับธุรกิจที่ไม่ต้องการตั้งค่า XML แบบเต็มรูปแบบ ควรยืนยันสิทธิ์และข้อกำหนดทางเทคนิคปัจจุบันโดยตรงกับกรมสรรพากรและที่ปรึกษาด้านภาษีของคุณก่อนตัดสินใจเลือกเส้นทางใดเส้นทางหนึ่ง

PromptBiz ของธนาคารแห่งประเทศไทยคือโครงสร้างพื้นฐานแบบรวมศูนย์ที่ใช้มาตรฐาน ISO 20022 สำหรับการส่งข้อมูลการค้าและการชำระเงินข้ามธนาคาร เชื่อมใบแจ้งหนี้อิเล็กทรอนิกส์ ใบเสร็จอิเล็กทรอนิกส์ e-Tax Invoice การโอนเงินแบบ Bulk Payment และการเงินห่วงโซ่อุปทาน เพื่อให้ข้อมูลการชำระเงินจับคู่กลับไปยังใบแจ้งหนี้ที่ถูกต้องได้จริง เฟสแรกเปิดตัวเมื่อวันที่ 29 สิงหาคม 2566 โดยมีธนาคารนำร่องได้แก่ กรุงไทย กรุงเทพ กรุงศรีอยุธยา กสิกรไทย และทีทีบี ธุรกิจขนาดเล็กที่กำลังเตรียมตัวไปสู่จุดนี้ยังดูโครงการ Business Development Service ของ สสว. (OSMEP) ที่ร่วมจ่าย 50-80% ของค่าใช้จ่ายด้านเทคโนโลยีและพัฒนาธุรกิจที่เข้าเงื่อนไข ตามขนาดกิจการ (จำกัดวงเงิน 50,000-200,000 บาทต่อปี) และคูปอง mini transformation ของ depa มูลค่าสูงสุด 10,000 บาท ได้ด้วย

The Reference Match ทำไมใบแจ้งหนี้ PDF ถึงไม่เหมือนใบแจ้งหนี้ที่เชื่อมต่อกัน

เรียกมันว่า Reference Match หรือ "การจับคู่ด้วยเอกสารอ้างอิง" คือข้อกำหนดเฉพาะเจาะจงที่ไม่ค่อยหวือหวาว่า ใบแจ้งหนี้ การชำระเงิน และใบเสร็จ จะต้องผูกกันได้อย่างน่าเชื่อถือด้วยเลขอ้างอิงที่คงที่ ไม่ใช่ให้คนมานั่งเทียบสายตาระหว่างรายการเดินบัญชีธนาคารกับโฟลเดอร์ PDF นี่คือสิ่งที่แยกธุรกิจที่ "เปลี่ยนเป็นดิจิทัลแล้ว" ออกจากธุรกิจที่สร้างงานปฏิบัติการที่เชื่อมต่อกันจริง ๆ และก็ไม่ใช่เรื่องบังเอิญเลยที่นี่คือสิ่งที่มาตรการลดหย่อน 200% กับโครงสร้างพื้นฐาน PromptBiz ถูกออกแบบมาให้รางวัลและสนับสนุนพอดี

ลองนึกภาพธุรกิจสมมติชื่อ "บริษัท สยามแพ็คเกจจิ้ง" ผู้จำหน่ายกล่องและวัสดุบรรจุภัณฑ์แบบ B2B ให้โรงงานผลิต ซึ่งไม่มีอยู่จริง สยามแพ็คเกจจิ้งเปลี่ยนมาออกใบแจ้งหนี้ e-Tax เป็น PDF ตั้งแต่เนิ่น ๆ ภูมิใจที่เลิกใช้กระดาษได้แล้ว หกเดือนต่อมา ทีมการเงินยังต้องใช้เวลาสองวันทุกเดือนจับคู่การโอนเงินธนาคารกับใบแจ้งหนี้ด้วยมือ เพราะเลขอ้างอิงที่ลูกค้าพิมพ์ในแอปธนาคารมักไม่ตรงกับเลขใบแจ้งหนี้ที่สยามแพ็คเกจจิ้งออกให้ และการจ่ายบางส่วน หรือการจ่ายรวมสองใบแจ้งหนี้ในโอนครั้งเดียว ก็ทำให้การจับคู่พังไปเลย ไม่มีสิ่งไหนในนี้เป็นปัญหาของ PromptBiz หรือปัญหาของกรมสรรพากรเลย มันคือปัญหา Reference Match ต่างหาก สยามแพ็คเกจจิ้งแปลงเอกสารเป็นดิจิทัลไปแล้ว แต่ยังไม่ได้ออกแบบข้อมูลที่จะทำให้การชำระเงินหาใบแจ้งหนี้ของตัวเองเจอโดยอัตโนมัติ

เตรียมข้อมูลหลักและวางผังสถานะเอกสาร

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

เชื่อมต่อการกระทบยอดการชำระเงินโดยไม่ต้องเดา

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

แยกความพร้อมของ ERP ออกจากความพร้อมของผู้ให้บริการ

ERP ของคุณอาจมีศักยภาพทางเทคนิคสร้างข้อมูลแบบมีโครงสร้างได้อยู่แล้ว ในขณะที่ธนาคาร ผู้ให้บริการ หรือวิธีการทางภาษีที่คุณเลือก อาจยังมีเงื่อนไขการลงทะเบียน รูปแบบ และเงื่อนไขการดำเนินงานของตัวเองแยกต่างหากที่ต้องทำให้ครบ ยืนยันเส้นทางบริการปัจจุบันกับผู้ให้บริการทางการแต่ละรายโดยตรง แทนที่จะสันนิษฐานว่าผู้ให้บริการซอฟต์แวร์ของคุณจัดการให้เรียบร้อยแล้ว หากคุณยังไม่ได้ยืนยันว่า ERP คือการลงทุนที่ถูกต้องตั้งแต่แรก ควรกลับไปทบทวน7 สัญญาณด้านปฏิบัติงานที่บอกว่า Excel และ LINE เอาไม่อยู่แล้วก่อนเพิ่มขอบเขตงานด้าน e-Tax และ PromptBiz ทับปัญหาการประสานงานที่ยังไม่ได้แก้

อย่าสัญญาว่าจะเชื่อมต่อกับ PromptBiz หรือกรมสรรพากรได้โดยอัตโนมัติ เพียงเพราะโบรชัวร์สินค้าใช้คำว่า "API" ตรวจสอบขอบเขตงานจริง การรับรองมาตรฐานที่เกี่ยวข้อง ประเภทเอกสารที่รองรับ การจัดการข้อผิดพลาด และใครเป็นผู้รับผิดชอบเมื่อการส่งข้อมูลล้มเหลว

กำหนดความเป็นเจ้าของก่อนจะทำให้อะไรเป็นอัตโนมัติ

ฝ่ายบัญชีควรเป็นเจ้าของกฎด้านภาษีและการกระทบยอด ฝ่ายปฏิบัติการควรเป็นเจ้าของเหตุการณ์ทางธุรกิจที่เป็นต้นเหตุ ฝ่ายเทคโนโลยีควรเป็นเจ้าของการส่งข้อมูลที่เชื่อถือได้และการเฝ้าติดตาม ฝ่ายบริหารตัดสินนโยบายและอำนาจจัดการข้อยกเว้นเมื่อทั้งสามฝ่ายเห็นไม่ตรงกัน หากยังไม่ชัดเจนจริง ๆ ว่าหน้าที่ด้านภาษีและการกระทบยอดควรอยู่ใน ERP ซอฟต์แวร์บัญชี หรือส่วนเสริมของ CRM ควรลองเปรียบเทียบว่าแต่ละระบบถูกออกแบบมาให้เป็นเจ้าของอะไรจริง ๆก่อนมอบหมายความรับผิดชอบถาวรให้ระบบที่ผิด สร้างแดชบอร์ดง่าย ๆ สำหรับเอกสารที่รออนุมัติ เอกสารที่ตรวจสอบไม่ผ่าน การชำระเงินที่จับคู่ไม่ได้ และใบเสร็จที่ยังไม่ออก แล้วมอบเจ้าของและเป้าหมายด้านอายุของงานให้แต่ละคิว

ทดสอบกรณีที่ยุ่งยาก แล้ววัดผลอย่างตรงไปตรงมา

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

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

Playbook ของ Reference Match

Stable Reference, Every Time เอกสารอ้างอิงที่คงที่ทุกครั้ง — ทุกใบแจ้งหนี้และการชำระเงินมีเลขอ้างอิงที่รอดพ้นจากการชำระบางส่วน การชำระรวม และการแก้ไข โดยไม่พัง
No Screenshot Approvals ไม่อนุมัติจากภาพหน้าจอ — การชำระเงินจะถือว่ายืนยันแล้วก็ต่อเมื่อสถานะที่ยืนยันได้จากธนาคารหรือผู้ให้บริการบอกไว้เท่านั้น ไม่ใช่ภาพที่ส่งต่อกันมาให้ใครสักคนดูผ่าน ๆ
One Uncomfortable Case a Week ทดสอบกรณียุ่งยากหนึ่งกรณีทุกสัปดาห์ — ระหว่างเปิดใช้งาน ตั้งใจทดสอบสถานการณ์ยากหนึ่งอย่างทุกสัปดาห์ เช่น ใบลดหนี้ การชำระด้วยสกุลเงินต่างประเทศ การชำระบางส่วน แทนที่จะสันนิษฐานว่ากรณีง่าย ๆ พิสูจน์แล้วว่าระบบใช้ได้
Cross-Industry Check ตรวจสอบข้ามอุตสาหกรรม — บริษัทที่ปรึกษาวิชาชีพที่เรียกเก็บค่าบริการรายชั่วโมงก็เจอปัญหา Reference Match แบบเดียวกันเป๊ะ ในวินาทีที่ลูกค้าจ่ายบางส่วนของค่าธรรมเนียมค้างจ่ายสามเดือน ทางแก้คือวินัยแบบเดียวกัน ไม่ใช่ซอฟต์แวร์เฉพาะด้านบัญชี

Match สิ่งที่ทุกอย่างสรุปรวมมาที่จุดเดียว

ถ้าต้องเหลือคำเดียวที่อธิบายว่าอะไรกันแน่ที่ทำให้ e-Tax Invoice และ PromptBiz ใช้งานได้จริงสำหรับธุรกิจ คำนั้นคือ Match หรือ "การจับคู่" ไม่ใช่ว่าคุณแปลงเอกสารเป็นดิจิทัลแล้วหรือยัง แต่คือเอกสารนั้น การชำระเงินของมัน และใบเสร็จของมัน หากันเจอโดยอัตโนมัติทุกครั้งได้หรือเปล่า โดยไม่ต้องมีคนมานั่งเทียบสองหน้าจอด้วยมือ

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

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

e-Tax Invoice บังคับใช้กับธุรกิจไทยในปี 2569 หรือยัง

ยัง ณ ปี 2569 การเข้าร่วมยังคงเป็นแบบสมัครใจ ไม่มีข้อบังคับทางกฎหมายให้ต้องใช้ในการซื้อขายแบบ B2B สำหรับปี 2569 หรือ 2570 การเข้าร่วมได้รับการสนับสนุนผ่านมาตรการภาษี ไม่ใช่การบังคับตามเกณฑ์รายได้

มาตรการลดหย่อน 200% ครอบคลุมอะไรบ้างกันแน่

บริษัทและห้างหุ้นส่วนที่จดทะเบียนสามารถหักรายจ่ายที่เข้าเงื่อนไขได้ 200% สำหรับระบบ e-Tax Invoice, e-Receipt และ e-Withholding รวมถึงซอฟต์แวร์ ฮาร์ดแวร์ ระบบจัดเก็บข้อมูลอิเล็กทรอนิกส์ และค่าธรรมเนียมที่จ่ายให้ผู้ให้บริการที่ได้รับอนุมัติ ไปจนถึงวันที่ 31 ธันวาคม 2570 ตามมติคณะรัฐมนตรีวันที่ 16 มิถุนายน 2569

มี e-Tax Invoice แล้วแปลว่าเชื่อมกับ PromptBiz โดยอัตโนมัติเลยไหม

ไม่ใช่ ทั้งสองเรื่องเกี่ยวข้องกันแต่แยกจากกัน e-Tax Invoice คือระบบเอกสารของกรมสรรพากร ส่วน PromptBiz คือโครงสร้างพื้นฐานด้านการชำระเงินและเอกสารการค้าของธนาคารแห่งประเทศไทย ควรยืนยันการลงทะเบียน PromptBiz ของธนาคารและผู้ให้บริการของคุณแยกต่างหากจากการตั้งค่า e-Tax

เหตุผลอันดับหนึ่งที่โปรเจกต์ e-Tax และ PromptBiz มักติดขัดคืออะไร

การสันนิษฐานว่าการแปลงเอกสารเป็นดิจิทัลเท่ากับการเชื่อมต่อมันแล้ว จุดติดขัดที่เกิดซ้ำคือ Reference Match ต่างหาก คือใบแจ้งหนี้ การชำระเงิน และใบเสร็จ ที่ผูกกันไม่ได้อย่างน่าเชื่อถือโดยไม่ต้องเทียบด้วยมือ

ถ้าคุณกำลังชั่งน้ำหนักว่าธุรกิจพร้อมสำหรับ e-Tax Invoice และ PromptBiz จริงหรือยัง หรือทีมการเงินของคุณยังจับคู่การชำระเงินด้วยมืออยู่ ขอการประเมินความพร้อมด้าน ERP และเอกสารดิจิทัลจาก NAWA แล้วเราจะช่วยวางผังข้อมูล การอนุมัติ และช่องว่างในการเชื่อมต่อระบบ ก่อนคุณจะตัดสินใจ

ERP, e-Tax Invoice และ PromptBiz: มาตรการลดหย่อนภาษี 200% ของไทย ต้องการอะไร จากข้อมูลของคุณจริง ๆ