FAQ
e-Tax Invoice กับหน้าที่ตาม PDPA ต้องทำคู่กันอย่างไร
การเปลี่ยนมาออกใบกำกับภาษีอิเล็กทรอนิกส์ทำให้ข้อมูลลูกค้าถูกเก็บเป็นไฟล์ดิจิทัลจำนวนมาก ซึ่งเข้าข่ายข้อมูลส่วนบุคคลตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 คลัสเตอร์นี้อธิบายวิธีวางระบบให้ผ่านทั้งข้อกำหนดของกรมสรรพากรเรื่องการเก็บรักษาเอกสารและหน้าที่ตาม PDPA ในเวลาเดียวกัน โดยไม่ต้องเลือกอย่างใดอย่างหนึ่ง
ระบบ e-Tax Invoice by Email ออกแบบสำหรับกิจการขนาดเล็กที่มีรายได้ไม่เกินสามสิบล้านบาทต่อปี วิธีทำคือสร้างใบกำกับภาษีเป็นไฟล์ PDF/A-3 แล้วส่งอีเมลถึงผู้ซื้อโดยสำเนาถึงระบบประทับรับรองเวลาของสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ ระบบจะประทับเวลาและส่งกลับให้ทั้งสองฝ่าย ข้อดีคือเริ่มได้เร็ว ต้นทุนต่ำ ไม่ต้องซื้อใบรับรองอิเล็กทรอนิกส์ ข้อจำกัดคือรองรับปริมาณน้อย ทำได้เฉพาะรูปแบบอีเมลทีละฉบับ และไม่รองรับใบรับ ส่วนระบบ e-Tax Invoice & e-Receipt เป็นระบบเต็มรูปแบบ ต้องมีใบรับรองอิเล็กทรอนิกส์สำหรับลงลายมือชื่อดิจิทัล จัดทำไฟล์ตามรูปแบบ XML มาตรฐาน ขมธ.3-2560 และนำส่งข้อมูลให้กรมสรรพากรทุกเดือนภายในวันที่สิบห้าของเดือนถัดไป รองรับทั้งใบกำกับภาษี ใบเพิ่มหนี้ ใบลดหนี้ และใบรับ เหมาะกับกิจการที่ออกเอกสารจำนวนมากหรือมีระบบขายเชื่อมต่ออัตโนมัติ หลักการตัดสินใจคือถ้าออกเอกสารต่ำกว่าประมาณห้าสิบฉบับต่อเดือนและยังไม่ต้องออกใบรับอิเล็กทรอนิกส์ ให้เริ่มที่ by Email ก่อนแล้วค่อยยกระดับ แต่ถ้าขายออนไลน์ ขายผ่านมาร์เก็ตเพลส หรือมีการออกใบรับทุกวัน ควรลงทุนระบบเต็มรูปแบบตั้งแต่ต้นเพื่อไม่ต้องย้ายระบบซ้ำ
ถ้าผู้ซื้อเป็นบุคคลธรรมดา คำตอบคือใช่ ชื่อ ที่อยู่ เลขประจำตัวประชาชน เบอร์โทรศัพท์ และอีเมล ล้วนเป็นข้อมูลส่วนบุคคลตามมาตรา 6 แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 เพราะระบุตัวบุคคลได้ทั้งทางตรงและทางอ้อม แต่ถ้าผู้ซื้อเป็นนิติบุคคล ข้อมูลของนิติบุคคลเองไม่ใช่ข้อมูลส่วนบุคคล ยกเว้นชื่อผู้ติดต่อ อีเมลพนักงาน หรือเบอร์มือถือผู้ประสานงานที่ปรากฏในเอกสาร ซึ่งยังเป็นข้อมูลส่วนบุคคลของพนักงานคนนั้น ประเด็นสำคัญคือฐานการประมวลผล การออกและเก็บใบกำกับภาษีไม่ต้องขอความยินยอม เพราะใช้ฐานการปฏิบัติตามกฎหมายตามมาตรา 24 (6) ประกอบมาตรา 86/4 แห่งประมวลรัษฎากรที่บังคับให้ใบกำกับภาษีต้องมีชื่อและที่อยู่ผู้ซื้อ ปัญหาจึงไม่ได้อยู่ที่การเก็บ แต่อยู่ที่การเอาข้อมูลไปใช้เกินวัตถุประสงค์ เช่น นำอีเมลจากใบกำกับภาษีไปส่งโปรโมชันการตลาด ซึ่งต้องใช้ฐานอื่นหรือขอความยินยอมแยกต่างหาก
สิทธิขอให้ลบข้อมูลตามมาตรา 33 แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลไม่ใช่สิทธิเด็ดขาด ผู้ควบคุมข้อมูลปฏิเสธได้เมื่อการเก็บรักษายังจำเป็นเพื่อปฏิบัติตามกฎหมาย ในกรณีเอกสารทางบัญชีและภาษีมีกฎหมายบังคับชัดเจนสองฉบับ คือมาตรา 14 แห่งพระราชบัญญัติการบัญชี พ.ศ. 2543 ที่ให้เก็บบัญชีและเอกสารประกอบไม่น้อยกว่าห้าปีนับแต่วันปิดบัญชี และมาตรา 87/3 แห่งประมวลรัษฎากรที่ให้เก็บรายงานและเอกสารประกอบไม่น้อยกว่าห้าปี โดยอธิบดีสั่งให้เก็บนานขึ้นได้แต่ไม่เกินเจ็ดปี ดังนั้นวิธีตอบที่ถูกต้องคือแจ้งผู้ร้องเป็นลายลักษณ์อักษรภายในสามสิบวันว่าไม่สามารถลบข้อมูลส่วนที่เป็นเอกสารทางบัญชีและภาษีได้ พร้อมอ้างฐานกฎหมายและระบุกำหนดเวลาที่จะลบจริงเมื่อพ้นระยะเก็บรักษา แต่ต้องลบส่วนที่ไม่ได้ผูกกับหน้าที่ตามกฎหมาย เช่น รายชื่อรับข่าวสารการตลาด ประวัติการเข้าชมเว็บไซต์ หรือข้อมูลในระบบ CRM ที่ไม่เกี่ยวกับธุรกรรม แนวปฏิบัติที่ดีคือแยกฐานข้อมูลธุรกรรมออกจากฐานข้อมูลการตลาดตั้งแต่แรก เพื่อให้ลบส่วนที่ต้องลบได้โดยไม่กระทบเอกสารที่ต้องเก็บ
ต้องทำครับ เมื่อกิจการส่งข้อมูลพนักงานสำหรับทำเงินเดือนและข้อมูลลูกค้าสำหรับออกใบกำกับภาษีให้สำนักงานบัญชี กิจการเป็นผู้ควบคุมข้อมูลส่วนบุคคล ส่วนสำนักงานบัญชีเป็นผู้ประมวลผลข้อมูล มาตรา 40 วรรคสาม แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลกำหนดให้ต้องมีข้อตกลงเป็นหนังสือควบคุมการประมวลผล สาระสำคัญที่ควรมีคือขอบเขตและวัตถุประสงค์ของการประมวลผล ประเภทข้อมูลและกลุ่มเจ้าของข้อมูล ข้อห้ามใช้ข้อมูลนอกคำสั่งของผู้ควบคุม มาตรการรักษาความมั่นคงปลอดภัยขั้นต่ำ เช่น การเข้ารหัสไฟล์และการควบคุมสิทธิเข้าถึงรายบุคคล เงื่อนไขการใช้ผู้ประมวลผลช่วง เช่น ผู้ให้บริการคลาวด์หรือระบบเงินเดือน หน้าที่แจ้งเหตุละเมิดข้อมูลกลับมายังผู้ควบคุมโดยไม่ชักช้า หน้าที่ช่วยตอบคำขอใช้สิทธิของเจ้าของข้อมูล และวิธีคืนหรือทำลายข้อมูลเมื่อสิ้นสุดสัญญา ควรแนบภาคผนวกระบุรายการระบบที่ใช้จริงและที่ตั้งของเซิร์ฟเวอร์ เพราะถ้าข้อมูลถูกเก็บนอกประเทศจะต้องพิจารณาเงื่อนไขการส่งข้อมูลข้ามพรมแดนตามมาตรา 28 และ 29 ด้วย
มาตรา 37 (4) แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลกำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้าและภายในเจ็ดสิบสองชั่วโมงนับแต่ทราบเหตุ เว้นแต่พิสูจน์ได้ว่าไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล และหากเหตุนั้นมีความเสี่ยงสูง ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาด้วย ข้อมูลเงินเดือนถือว่าเสี่ยงสูงเกือบทุกกรณีเพราะมีเลขบัญชีธนาคาร เลขประจำตัวประชาชน และรายได้ ในทางปฏิบัติควรเตรียมล่วงหน้าสามอย่าง หนึ่งแบบฟอร์มบันทึกเหตุที่ระบุเวลาที่ทราบเหตุ ระบบที่ถูกกระทบ จำนวนรายการ และประเภทข้อมูล สองรายชื่อผู้รับผิดชอบและช่องทางติดต่อฉุกเฉินนอกเวลาทำการ สามการซ้อมตอบสนองอย่างน้อยปีละครั้ง เพราะเส้นตายเจ็ดสิบสองชั่วโมงเริ่มนับตั้งแต่วินาทีที่ทราบเหตุ ไม่ใช่ตั้งแต่สอบสวนเสร็จ กิจการจำนวนมากพลาดเพราะรอผลตรวจสอบให้ครบก่อนจึงแจ้ง ทั้งที่กฎหมายอนุญาตให้แจ้งข้อมูลเบื้องต้นก่อนแล้วส่งรายละเอียดเพิ่มเติมภายหลังได้
หลักการคือไฟล์ที่ยื่นต่อกรมสรรพากรต้องคงความถูกต้องครบถ้วนตลอดอายุการเก็บรักษา ห้ามแก้ไขย้อนหลังโดยไม่มีร่องรอย ในทางเทคนิคควรทำสี่อย่าง หนึ่งเก็บไฟล์ XML ต้นฉบับพร้อมลายมือชื่อดิจิทัลไว้ในที่เก็บแบบเขียนครั้งเดียวอ่านได้หลายครั้ง หรือเปิดฟีเจอร์ object lock ของระบบคลาวด์เพื่อป้องกันการลบและทับไฟล์ สองบันทึกค่าแฮชของแต่ละไฟล์ไว้ในทะเบียนแยกต่างหาก เพื่อพิสูจน์ภายหลังว่าไฟล์ไม่ถูกแก้ สามสำรองข้อมูลอย่างน้อยสองชุดในสถานที่ต่างกันและทดสอบกู้คืนจริงปีละครั้ง เพราะข้อมูลสำรองที่กู้ไม่ได้เท่ากับไม่มีสำรอง สี่จำกัดสิทธิเข้าถึงตามหน้าที่ ผู้ออกเอกสาร ผู้อนุมัติ และผู้ดูแลระบบควรเป็นคนละบัญชีผู้ใช้ พร้อมเปิดบันทึกการเข้าถึงย้อนหลังได้ นอกจากนี้ควรวางแผนอายุใบรับรองอิเล็กทรอนิกส์ล่วงหน้า เพราะใบรับรองมักมีอายุหนึ่งถึงสามปี หากปล่อยหมดอายุจะออกเอกสารไม่ได้ทันที และการต่ออายุใหม่ต้องใช้เวลาตรวจสอบตัวตนอีกครั้ง
ไม่ต้องขอความยินยอมสำหรับตัวการส่งเอกสารเอง เพราะเป็นการปฏิบัติตามสัญญาตามมาตรา 24 (3) และปฏิบัติตามกฎหมายภาษีตามมาตรา 24 (6) ความเข้าใจผิดที่พบบ่อยคือคิดว่าทุกการใช้ข้อมูลต้องมีคำยินยอม ทั้งที่พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลวางฐานทางกฎหมายไว้หลายฐาน และการขอความยินยอมทั้งที่มีฐานอื่นรองรับกลับสร้างปัญหา เพราะเมื่อลูกค้าถอนความยินยอมกิจการจะอยู่ในสถานะลำบาก สิ่งที่ต้องทำคือแจ้งประกาศความเป็นส่วนตัวให้ครบตามมาตรา 23 ก่อนหรือขณะเก็บข้อมูล โดยระบุวัตถุประสงค์ ฐานทางกฎหมาย ระยะเวลาเก็บ ผู้ที่อาจได้รับข้อมูล เช่น สำนักงานบัญชีและผู้สอบบัญชี สิทธิของเจ้าของข้อมูล และช่องทางติดต่อ ส่วนกรณีที่ต้องขอความยินยอมจริงคือการใช้ข้อมูลนอกวัตถุประสงค์เดิม เช่น ส่งจดหมายข่าวการตลาด แชร์ข้อมูลให้พันธมิตรทางธุรกิจ หรือใช้ภาพและชื่อลูกค้าเป็นกรณีศึกษาบนเว็บไซต์ ซึ่งต้องขอแยกรายการและถอนได้ง่ายเท่ากับตอนให้
มาตรา 39 กำหนดให้ผู้ควบคุมข้อมูลจัดทำและเก็บบันทึกรายการกิจกรรมการประมวลผลไว้ให้เจ้าของข้อมูลและสำนักงานตรวจสอบได้ สำหรับฝ่ายบัญชีควรแยกเป็นรายกิจกรรมอย่างน้อยห้ารายการ ได้แก่ การออกใบกำกับภาษีและใบเสร็จ การจัดทำเงินเดือนและยื่นประกันสังคม การจ่ายชำระเจ้าหนี้และคืนเงินลูกค้า การจัดเก็บหนี้และติดตามลูกหนี้ และการส่งข้อมูลให้ผู้สอบบัญชีและหน่วยงานราชการ แต่ละรายการควรระบุแปดช่อง คือวัตถุประสงค์ ฐานทางกฎหมาย ประเภทข้อมูลและกลุ่มเจ้าของข้อมูล ผู้รับข้อมูลทั้งภายในและภายนอก ระยะเวลาเก็บรักษาและเหตุผล มาตรการความปลอดภัยที่ใช้ ระบบหรือแฟ้มที่จัดเก็บจริง และผู้รับผิดชอบ ควรทบทวนอย่างน้อยปีละครั้งหรือเมื่อเปลี่ยนระบบ เช่น เปลี่ยนโปรแกรมบัญชีหรือย้ายขึ้นคลาวด์ เอกสารนี้ยังมีประโยชน์เชิงปฏิบัติมากกว่าการปฏิบัติตามกฎหมาย เพราะเวลามีคำขอใช้สิทธิเข้ามา ทีมงานจะรู้ทันทีว่าข้อมูลของบุคคลนั้นอยู่ในระบบใดบ้าง ไม่ต้องไล่ค้นทีละแฟ้ม
ไม่ผิดโดยตัวมันเอง แต่ต้องเข้าเงื่อนไขการส่งหรือโอนข้อมูลไปต่างประเทศตามมาตรา 28 ซึ่งกำหนดว่าประเทศปลายทางต้องมีมาตรฐานคุ้มครองข้อมูลที่เพียงพอ หรือเข้าข้อยกเว้น เช่น เป็นการปฏิบัติตามสัญญากับเจ้าของข้อมูล หรือได้รับความยินยอมหลังแจ้งถึงมาตรฐานที่ไม่เพียงพอแล้ว ส่วนมาตรา 29 เปิดทางให้กลุ่มบริษัทในเครือใช้นโยบายคุ้มครองข้อมูลภายในเครือกิจการที่ผ่านการตรวจสอบได้ ในทางปฏิบัติสำหรับเอสเอ็มอีที่ใช้บริการคลาวด์รายใหญ่ สิ่งที่ควรทำมีสี่ข้อ หนึ่งตรวจสอบว่าผู้ให้บริการเสนอข้อสัญญาการประมวลผลข้อมูลและข้อสัญญามาตรฐานสำหรับการโอนข้ามพรมแดนหรือไม่ สองเลือกภูมิภาคจัดเก็บข้อมูลในสิงคโปร์หรือในประเทศไทยหากผู้ให้บริการมีตัวเลือก เพื่อลดความซับซ้อน สามระบุการโอนข้อมูลไปต่างประเทศไว้ในประกาศความเป็นส่วนตัวและในบันทึกรายการกิจกรรมการประมวลผล สี่เก็บหลักฐานการประเมินผู้ให้บริการไว้ เช่น รายงานมาตรฐาน ISO 27001 หรือ SOC 2 เพื่อแสดงว่าได้ใช้ความระมัดระวังตามสมควรแล้ว
กิจการขนาดกลางทั่วไปใช้เวลาประมาณสามถึงสี่เดือน แบ่งเป็นสี่ระยะ ระยะที่หนึ่งสำรวจสถานะปัจจุบันประมาณสามสัปดาห์ ได้แก่ นับปริมาณเอกสารต่อเดือน ตรวจรูปแบบเลขที่เอกสาร สำรวจว่าข้อมูลลูกค้าและพนักงานเก็บอยู่ที่ใดบ้าง และประเมินว่าระบบขายปัจจุบันเชื่อมต่อได้หรือไม่ ระยะที่สองออกแบบและจัดหาประมาณสี่สัปดาห์ ได้แก่ เลือกวิธีเข้าร่วมระบบ ขอใบรับรองอิเล็กทรอนิกส์จากผู้ให้บริการที่ได้รับการรับรอง จัดทำประกาศความเป็นส่วนตัวและข้อตกลงประมวลผลข้อมูล ระยะที่สามทดสอบประมาณสี่สัปดาห์ ได้แก่ ทดสอบสร้างไฟล์ XML ทดสอบนำส่ง ทดสอบใบลดหนี้และการยกเลิก และซ้อมกระบวนการตอบคำขอใช้สิทธิ ระยะที่สี่ใช้งานจริงและติดตามสองถึงสี่สัปดาห์ โดยเดือนแรกควรออกเอกสารคู่ขนานทั้งกระดาษและอิเล็กทรอนิกส์เพื่อเทียบยอด จุดที่โครงการมักสะดุดคือข้อมูลลูกค้าเดิมไม่สมบูรณ์ เช่น เลขประจำตัวผู้เสียภาษีผิดหรือขาดรหัสสาขา ทำให้ไฟล์ไม่ผ่านการตรวจรูปแบบ จึงควรเริ่มทำความสะอาดฐานข้อมูลลูกค้าตั้งแต่สัปดาห์แรกของโครงการ ไม่ใช่รอถึงตอนทดสอบ
ลัดไปยังคำถามในหมวดนี้
- e-Tax Invoice by Email กับ e-Tax Invoice & e-Receipt ต่างกันอย่างไร ควรเลือกแบบไหน
- ใบกำกับภาษีที่มีชื่อและที่อยู่ลูกค้าถือเป็นข้อมูลส่วนบุคคลตาม PDPA หรือไม่
- ลูกค้าขอให้ลบข้อมูลตาม PDPA แต่กฎหมายภาษีบังคับให้เก็บเอกสารห้าปี ต้องทำอย่างไร
- ต้องทำข้อตกลงประมวลผลข้อมูลกับสำนักงานบัญชีหรือไม่ และควรมีอะไรบ้าง
- ถ้าไฟล์ใบกำกับภาษีหรือข้อมูลเงินเดือนรั่วไหล ต้องแจ้งใครภายในกี่ชั่วโมง
- ไฟล์ XML และไฟล์ลายมือชื่อดิจิทัลต้องเก็บอย่างไรให้ปลอดภัยและตรวจสอบได้
- ต้องขอความยินยอมลูกค้าก่อนส่งใบกำกับภาษีทางอีเมลหรือไม่
- บันทึกรายการกิจกรรมการประมวลผลข้อมูลของฝ่ายบัญชีควรมีหน้าตาอย่างไร
- ใช้ระบบบัญชีคลาวด์ที่เซิร์ฟเวอร์อยู่ต่างประเทศผิด PDPA หรือไม่
- ถ้าจะเริ่มโครงการ e-Tax พร้อมจัดระเบียบ PDPA ควรวางแผนกี่เดือนและทำอะไรบ้าง
หัวข้ออื่น