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 เลขที่เป็น ปีเดือนวัน เช่น EIV670101–001

สิ่งที่เกิดขึ้น รายงานภาษีขายที่นำส่งสรรพากร จะต้องใช้เอกสาร 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

อ้างอิง

• ขมธอ. 3–2560 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