E-Tax Invoice and Cancellation Note in Accounting System

"ใบยกเลิกอิเล็กทรอนิกส์" (CLN cancellation note) อยู่ตรงไหนในระบบบัญชี
 
ในการยกร่างข้อเสนอมาตรฐานข้อมูล E-Tax Invoice version 1.7 เมื่อ 21/12/2559 มีการเพิ่มเอกสารประเภทพิเศษขึ้นมาคือ "ใบยกเลิกอิเล็กทรอนิกส์" (CLN cancellation note) วัตถุประสงค์เพื่อใช้ยกเลิกเอกสารอิเลกทรอนิกส์ที่เปิดไปแล้ว เป็นทางออกสำหรับเงื่อนไขห้ามกลับไปแก้ไขเอกสารที่บันทึกไปแล้ว

เป็นวิธีที่ดีและถูกต้องในแง่รองรับ operation จากมุมมองของฝั่งผู้ตรวจสอบอย่างกรมสรรพากร ผ่าทางตันกรณีเอกสารผิดพลาดแล้วไม่สามารถแก้ไขย้อนหลัง เพราะมีตัวกลางที่ทำหน้าที่เป็นพยานประทับรับรองอยู่ด้วย
 
แต่มีผลทำให้จุดเด่นสำคัญของการใช้คอมพิวเตอร์หายไป เราเลิกใช้พิมพ์ดีดไฟฟ้า เพราะสามารถแก้ไขจดหมายที่บันทึกเก็บไว้ในไฟล์ words แล้วพิมพ์ออกมาใหม่ สะดวกกว่ามากมาย
 
เมื่อบิลถูกพิมพ์และบันทึกโดยคอมพิวเตอร์ การแก้ไขข้อความที่ไม่มีผลกระทบทางภาษี หรือบิลที่ยังไม่ถึงกำหนดรอบยื่นรายงานภาษี ผู้ซื้อกับผู้ขายอาจเจรจากันเอง แก้ไขแล้วพิมพ์บิลเลขที่เดิมได้ เป็นความสะดวกทั้งสองฝ่าย
 
เพราะเราเปลี่ยนผ่านยุคสมัยของบิลเล่ม ที่สั่งพิมพ์และตีเลขที่มาจากโรงพิมพ์ สมัยนั้นหากเขียนผิดก็ต้องขีดฆ่าทิ้งเก็บสำเนาติดเล่ม แล้วใช้บิลเลขถัดใบ โดนบังคับห้ามแก้ไขไร้ร่องรอยโดยปริยาย
 
กฏหมายภาษีมูลค่าเพิ่มออกมาบังคับใช้ครั้งแรกก็ประมาณยุคของบิลเขียนมือ เมื่อฝ่ายบัญชีส่วนใหญ่ใช้คอมพิวเตอร์เปิดบิล การแก้ไขข้อมูลเดิมแล้วพิมพ์บิลเลขเดิมทำได้สะดวกกว่า ตราบใดที่ยังไม่มีคนกลางอย่างสรรพากรรับรู้จึงเป็นเรื่องที่ทำได้ เมื่อเวลาผ่านไปการปฏิบัติเช่นนี้กลายเป็นความปกติใหม่
 
สมมติว่าคุณโพสต์ในห้อง chat ว่า "เย็นนี้จะไปดูคอนเสิร์ต"
 
แล้วเพื่อน ๆ ก็โพสต์ตอบว่า "งั้นเจอกัน" "ไปด้วย" ฯลฯ
 
หลังจากนั้นคุณกลับไปแก้ข้อความเป็น "เย็นนี้จะไปงานศพ" 
 
เพื่อนที่โพสต์ตอบไปแล้วจะทำอย่างไร
 
โลกของคอมพิวเตอร์ที่ช่วยงานพิมพ์แทนการเขียนมือ กำลังเปลี่ยนเป็นโลกที่กระจายข่าวให้รับรู้ทั่วถึงในเวลาเดียวกัน
 
Eventual Consistency
 
หมายถึง "ความสอดคล้องในท้ายที่สุด" เป็นคำศัพท์ที่ใช้กันบ่อยสำหรับผู้ที่ใช้งาน distributed database ซึ่งเก็บสำเนาของข้อมูลไว้ใน server หลายแห่ง จะมีช่วงเวลาสั้น ๆ ที่ sync ระหว่าง server ไม่ทัน มีโอกาสที่เกิดความไม่สอดคล้องขึ้น ผู้ที่อ่านข้อมูลจาก server ตัวแรก อาจได้ผลลัพธ์ไม่ตรงกับผู้ที่อ่านข้อมูลจาก server ตัวที่สอง
 
สำหรับใบกำกับภาษี กรมสรรพากรก็มีช่วงเวลายืดหยุ่นยอมให้เกิดสภาวะไม่นิ่ง สามารถแก้ไขได้จนกว่าจะยื่นนำส่งภาษี เมื่อนั้นจึง cut off ด้วยรายงานภาษีขายและซื้อ หากเปลี่ยนแปลงอะไรหลังจากนั้นควรมีหลักฐานร่องรอยที่สำแดงได้
 
กับลูกค้าหรือคู่ค้ากลับอาจจะขึ้นอยู่กับเงื่อนไขแต่ละกรณี ถ้าลูกค้ายังไม่ได้รับใบกำกับภาษี หรือเอาใบกำกับภาษีเดิมมาคืน หากยังไม่ถึงเวลา cut off การกลับไปแก้ไขที่ใบเดิมง่ายกว่า
 
ความเชื่อที่ว่า ใบกำกับภาษีต้องเรียงวันและเรียงเลข มิฉะนั้นจะถูกสงสัยว่าทุจริต ของผู้ทำหน้าที่ตรวจสอบ ไม่ว่าเจ้าหน้าที่สรรพากร ลามไปถึงนักบัญชีภายนอกและผู้สอบบัญชี กลายเป็นเหตุผลสำคัญทำให้การยกเลิกใบกำกับภาษี แล้วเปิดใบกำกับภาษีใบใหม่ โดยย้อนวันที่ตามใบเดิม กลายเป็นมีปัญหาถูกเพ่งเล็ง มากกว่าการทำแบบไร้ร่องรอย
 
ธรรมชาติของการบันทึกบัญชีต้องการเพียงความสอดคล้องในท้ายที่สุด เพื่อสรุปผลที่จบแล้ว การนำส่งภาษีมูลค่าเพิ่มมีเวลาถึงวันที่ 15 ของเดือนถัดไป การปิดงบให้เวลา 150 วัน ดังนั้นบัญชีจึงไม่จำเป็นรีบรับรู้รายละเอียดความเปลี่ยนแปลงของเรื่องที่ยังไม่สะเด็ดน้ำ
 
Real Time Events
 
E-Tax Invoice เป็นการเปิดมิติใหม่ที่ไม่คุ้นชินในโลกนักบัญชีผู้เป็นอิสระต่อเวลา ต่อไปนี้เมื่อเปิดบิลจะเป็นการประกาศให้ผู้เกี่ยวข้องรับรู้ทั่วพร้อม และไม่สามารถย้อนกลับคืนหรือแก้ไข หากมีอะไรผิดพลาดต้องประกาศใหม่เป็น "ใบแจ้งยกเลิก" ให้ทุกฝ่ายรับรู้อีกครั้ง
 
เป็นการบังคับให้งานเอกสารแบบนี้ต้องเป็นเหตุการณ์ตามเวลาจริง ควรแยกมิติออกมาจากงานบัญชีแบบเดิม เพราะไม่สามารถยุบหรือลัดขั้นตอนเอามาใช้บันทึกบัญชีได้ทันที
 
ผมนึกถึง blockchain layer 2 ที่แยกออกมาสรุปธุรกรรมก่อนส่งไปบันทึกใน layer 1
 
จุดอ่อน
 
จุดอ่อนของนิยาม หากว่าตามสเปคไม่ได้บอกด้วยว่า "ใบแจ้งยกเลิก" ห้ามใช้ยกเลิก "ใบแจ้งยกเลิก" อื่น หรือห้ามอ้างถึงใบกำกับภาษีเลขเดิมซ้ำ หากเป็นเช่นนั้นจะเสมือนการถอนคำสั่งยกเลิกหรือไม่ (มึน) แล้วโค้ดระบบประมวลผล XML ของสรรพากรจะตีความกรณีนี้อย่างไร
 
การออกแบบให้ยกเลิกโดยใช้เลขที่อ้างถึงเพียงอย่างเดียว ไม่ได้กำหนดกรอบเวลาที่สามารถแจ้งยกเลิก หากมีการแจ้งยกเลิกเลขใบกำกับภาษีที่ไม่เคยมี หรือหากเก็บสะสมข้อมูลไปนาน ๆ มีการอ้างถึงบิลที่ย้อนหลังยาวนานในอดีต จะกลายเป็นพยายามค้นหาเลขอ้างถึงนั้นจาก database จนค้างไปเลยหรือไม่

 
Accounting Transactions
 
โปรแกรมบัญชีที่รองรับ E-Tax Invoice จะต้องออกแบบให้เป็น 2 layer เพราะใบแจ้งยกเลิก ตัวมันเองไม่มีคุณสมบัติใช้บันทึกบัญชี ตั้งหนี้ ลดหนี้ หรือตัดสต็อค แต่เป็นเหมือนเป็นการ์ดพิเศษ หากหงายออกมาสามารถใช้สาปให้ใบกำกับภาษีอื่นสิ้นสภาพกลายเป็น 0 ได้ 
 
ในมุมมองของผมมีความรู้สึกว่า Cancellation Note เป็นสิ่งแปลกปลอมไม่ควรออกแบบให้ใช้เป็นข้อมูลทางบัญชีโดยตรง เช่นเดียวกับกรณีใบแทนใบกำกับภาษี (ผู้ที่เปิดบิลด้วยคอมพิวเตอร์แทบไม่มีใครใช้เพราะสามารถ reprint ได้) เป็นบันทึกเหตุการณ์ต่อเนื่องภายหลัง ก่อนที่จะสรุปว่าใบกำกับภาษีแต่ละใบจะมีสถานะสุดท้ายอย่างไร โชคร้ายที่ CLN มีผลเปลี่ยนสถานะทางบัญชีด้วย
 
คล้ายกับการออกแบบ Event Sourcing ในซอฟต์แวร์ขนาดใหญ่ เราเอาเหตุการณ์ (event) ที่เกี่ยวข้องกับเอกสาร (entity) ใด ๆ มา rewind, replay ตาม time line เพื่อประมวลผลให้กลายเป็นสถานะเอกสารหรือข้อมูลที่มีผลทางบัญชีในที่สุด แม้กระทั่งโปรแกรมเมอร์ก็ยังสับสนหากยังแยกไม่ออกว่าข้อมูลที่ออกแบบเป็น actual state ใน database หรือ events stream
 
(["E-Tax Invoice"] + ["Cancellation Note"]) => ["Accounting Tax Invoice"]
 
ลองสมมติเหตุการณ์ที่อาจเกิดขึ้น
 
วันที่ 1 เปิด E-Tax Invoice เลขที่ EIV0001 เมื่อสั่งประมวลผลทางบัญชี จะได้เอกสารทางบัญชีที่ใช้บันทึกรายได้/ตัดสต็อค/ภาษีขาย เลขที่ A-EIV0001
วันที่ 3 อีกสองวันต่อมา เปิด Cancellation Note เลขที่ CLN0001 (เพื่อยกเลิก EIV0001) เมื่อสั่งประมวลผลบัญชี จะทำการยกเลิก A-EIV0001 ถอนการบันทึกบัญชีรายได้/ตัดสต็อค/ภาษีขาย เหมือนกับการเปิดใบกำกับภาษีแล้วยกเลิกตามระบบบัญชีปกติ
สมมติว่าเป็นการแก้ไขรายการบิลเดิมที่ผิดพลาดจึงเปิด E-Tax Invoice ใบใหม่และเลขที่ใหม่ สมมติว่าเลขที่ล่าสุดเป็น EIV0008 โดยต้องลงวันที่ย้อนหลังเป็นวันที่ 1 ดังนั้น ขณะที่เลขที่ EIV0007 อาจเป็นวันที่ 2 ไปแล้ว การทำให้ใบกำกับภาษีต้องเรียงวันที่และเลขที่ให้สอดคล้องกันจึงเป็นเรื่องสุดวิสัย
 
ไอเดียของการทำให้วันที่กับเลขที่ต้องเรียงลำดับสอดคล้องกัน โปรแกรม E-Tax Invoice ควรใช้ format เลขที่เป็น ปีเดือนวัน เช่น EIV670101001
 
สิ่งที่เกิดขึ้น รายงานภาษีขายที่นำส่งสรรพากร จะต้องใช้เอกสาร A-EIV เพื่อสำแดงรายการใบกำกับภาษีที่ยกเลิกได้ ส่วนรายการเอกสาร EIV และ CLN ในระบบ E-Tax Invoice เอาไว้แสดงเหตุการณ์ที่เกิดขึ้นตามลำดับเวลาจริง
 
สรุป
 
คิดแบบเร็ว ๆ โปรแกรมบัญชีเดิมที่เปิดใบกำกับภาษีได้ อาจไม่สามารถปรับให้ใช้กับ E-Tax Invoice ได้ครบสมบูรณ์ ยกเว้นผู้ประกอบการจะพยายามไม่ทำใบแจ้งยกเลิก หลบไปทำใบลดหนี้ทั้งบิลแทน (แต่ที่ปรึกษาที่ผมสอบถามไม่แนะนำให้ทำเช่นนี้ เพราะเหตุผลในการลดหนี้อาจใช้ไม่ได้)
 
จากเล่มบิลที่พิมพ์โดยโรงพิมพ์ เปลี่ยนมาเป็นพิมพ์บิลด้วยคอมพิวเตอร์ทั้งฉบับ โปรแกรมบัญชีทำให้โรงพิมพ์ท้องถิ่นค่อย ๆ โรยรา ต่อไปบิลอิเล็กทรอนิกส์ อาจทำให้ระบบที่เคยยึดโยงกับกระดาษต้องเลิกรา แต่ละยุคต่างก็มี use case ข้อดีข้อเสียแตกต่างกัน บางทีเราก็ไม่อาจใช้วิธีทำงานแบบเดิม, หลักคิดเดิม รวมถึงเครื่องมือเดิม โปรแกรมบัญชีและ business workflow
 
ดังนั้นอาจถึงเวลาที่โปรแกรมบัญชีทั้งหมด ต้องทบทวนการออกแบบใหม่ เป็นสองแนวทาง
 
ไม่รองรับ E-Tax Invoice ให้ผู้ประกอบการใช้ผู้ให้บริการภายนอก แล้วทำกลไก import E-Tax Invoice + Cancellation Note (เสมือนคำสั่ง สร้าง หรือ ยกเลิก ใบกำกับภาษี) มาเป็นใบกำกับภาษีที่มีคุณสมบัติตามระบบบัญชี
 
ออกแบบ E-Tax Invoice เป็น extension เสริม (เอกสารประเภทใหม่ ไม่ใช่ใบกำกับภาษีตามความหมายเดิม) แล้วมีกลไก sync เป็นข้อมูลใบกำกับภาษีทางบัญชี (ที่สามารถ update สถานะล่าสุดเป็นยกเลิกได้)
 
จุดที่ควรระวังคือ การทำใบแจ้งยกเลิกในทางทฤษฏี ไม่มีข้อห้ามเรื่องทำกับบิลเก่าย้อนหลังว่าไม่เกินเมื่อไหร่ ณ เวลานี้ ยังไม่มีคำสั่งให้สำแดงในรายงานภาษีขาย (เพราะไม่ใช่ใบกำกับภาษี) แต่ในทางปฏิบัติจึงขึ้นอยู่กับข้อจำกัดทางกฏหมายรอบ ๆ เช่น หากยื่นภาษีไปแล้ว ไม่ควรยกเลิก หรือแก้ไขสาระสำคัญที่เกี่ยวข้อง ผู้สอบบัญชีทำงานยาก เช่นเดียวกับแนวทางการยกเลิกใบกำกับภาษีของระบบบัญชีทั่วไป
 
ข้อสังเกต ผู้ให้บริการ E-Tax Invoice บางรายก็ยังไม่มีฟีเจอร์ ทำใบแจ้งยกเลิก
 
เล่าไว้ลอย ๆ เบลอ ๆ 
 
หากผิดพลาดคลาดเคลื่อนขออภัย 
 
/ ดึกดื่นคืนหนึ่งในเดือน มกราคม 2567
 
อ้างอิง
 
ขมธอ. 32560 https://www.etda.or.th/getattachment/8b822c07-693d-44d3-9cf1-61d672a17ccd/%E0%B8%82%E0%B8%A1%E0%B8%98%E0%B8%AD-3-2560-%E0%B9%80%E0%B8%A7%E0%B8%AD%E0%B8%A3%E0%B8%8A%E0%B8%99-2-0.aspx
 
เพิ่มเติม
 
เหนื่อยล้า แต่ความคิดไม่ยอมสงบ ในที่สุดผมก็นึกได้ว่า น่าจะเป็นเพราะ cold brew เมื่อตอนบ่าย ทำให้นอนไม่หลับ
 
นึกถึงกรณี Statement หรือสมุดเงินฝากธนาคาร การบันทึก transaction ของ core banking กรณีที่จำเป็นต้อง void ยอดรายการที่พิมพ์ลงสมุดไปแล้ว ออกแบบอย่างไรให้ audit ง่าย และแสดงคนทั่วไปอ่านเข้าใจได้ด้วย
 
ถ้าใบยกเลิกนี้แสดงในรายงานภาษีขายด้วยยอดที่ปรับปรุง เช่น ยอดในรายการใบกำกับภาษีเดิม 100 รายการปรับปรุงตามใบยกเลิกก็จะเป็น -100 จะช่วยให้ผู้ตรวจสอบทำงานง่ายกว่าไหม

เริ่มจากออกแบบ XML spec ของ CLN (Cancellation Note) ให้มีความเป็น transaction ไม่ใช่ command ทำหน้าที่สั่งหรือแจ้งยกเลิก โดยปรับเปลี่ยนส่วน Applicable Trade Tax จากไม่ใช้ NU (Not Used) เป็นต้องระบุ R (Required) จำนวนเงินที่ปรับปรุงด้วย เหมือนกับในคอลัมน์ TIV (Tax Invoice) และ DCN (Debit Credit Note)
 
แล้วสรรพากรก็สามารถออกประกาศให้ใบยกเลิกอิเล็กทรอนิกส์เป็นรายการที่ต้องแสดงในรายงานภาษีขาย เมื่อใบยกเลิกอิเล็กทรอนิกส์ มียอดจำนวนเงินที่ต้อง reverse กลับ ก็จะมีคุณสมบัติของ transaction ที่สมบูรณ์ในตัวเองได้ สามารถแสดงเป็นรายการปรับปรุงในรายงานภาษีขาย เหมือนกับที่เราเห็นรายการที่มี transaction code COR, ER, EC (แต่ละธนาคารใช้รหัสไม่เหมือนกัน)
 
ผลที่ตามมาในทางบัญชีก็สามารถเอามาใช้บันทึกเพื่อกระทบยอดโดยไม่ต้องย้อนไปหาต้นทาง ทำให้กระบวน audit ง่ายกว่าการออกแบบให้เป็นแค่ส่งคำสั่งยกเลิก โดยไม่มีคุณสมบัติเป็น transaction