สมมติว่าบริษัทขายบริการดูแลระบบให้ลูกค้า ฝ่ายการเงินอนุมัติสัญญาที่ให้ชำระเงินภายใน 30 วัน แต่ลูกค้าขอแก้เป็น 60 วันก่อนเซ็น ฝ่ายขายส่งฉบับแก้ไขเข้าโปรแกรมลงนาม แล้วเก็บ PDF ที่เซ็นครบไว้ในโฟลเดอร์ลูกค้า
ทุกคนเห็นว่าสัญญาเซ็นแล้ว แต่เมื่อถึงวันวางบิล ฝ่ายการเงินเพิ่งพบว่าเงื่อนไขไม่ตรงกับที่อนุมัติ คำถามจึงไม่ได้มีแค่ว่าใครเซ็น แต่รวมถึงใครยอมรับเงื่อนไขใหม่ และหลักฐานชิ้นไหนยืนยันคำตอบนั้น
ก่อนซื้อหรือเปลี่ยนโปรแกรมลงนาม บริษัทควรรู้ก่อนว่าปัญหาเกิดตรงไหน ตั้งแต่การแก้สัญญา ขออนุมัติ ตรวจผู้ลงนาม ไปจนถึงเก็บเอกสารหลังเซ็น จึงจะตัดสินใจได้ว่าต้องแก้วิธีทำงานหรือเปลี่ยนเครื่องมือ
ร่างกฎหมายอยู่ขั้นไหน และเกี่ยวอะไรกับสัญญาที่ใช้อยู่
ทำเนียบรัฐบาลแถลงเมื่อ 29 กันยายน 2569 ว่ามีการเสนอร่าง พ.ร.บ. ธุรกรรมทางอิเล็กทรอนิกส์ต่อคณะรัฐมนตรี เนื้อหาที่รัฐบาลสรุปกล่าวถึงลายมือชื่อและตราประทับอิเล็กทรอนิกส์ สัญญาอัตโนมัติ ตราสารเปลี่ยนมืออิเล็กทรอนิกส์ และการกำกับผู้ให้บริการตามความเสี่ยง
ข่าวนี้เป็นเพียงสรุปข้อเสนอ ไม่ใช่ตัวบทฉบับสุดท้าย ข่าวระบุว่า หากร่างผ่านกระบวนการตามกฎหมายและประกาศในราชกิจจานุเบกษาแล้ว จะมีผลเมื่อพ้น 180 วันนับแต่วันประกาศ ไม่ใช่นับจากวันแถลงข่าว จึงนำข่าวนี้ไปตั้งเส้นตายเปลี่ยนระบบของบริษัทไม่ได้
ธุรกิจไม่ต้องรอร่างใหม่จึงจะใช้ลายมือชื่ออิเล็กทรอนิกส์ได้ กฎหมายปัจจุบันมีหลักเรื่องนี้อยู่แล้ว โดยมาตรา 9 มีเงื่อนไขเรื่องการระบุตัวผู้ลงนาม การแสดงเจตนา และวิธีการที่เชื่อถือได้เหมาะกับวัตถุประสงค์และพฤติการณ์ หรือวิธีอื่นที่ยืนยันตัวบุคคลและเจตนาได้ตามที่มาตรากำหนด ส่วนมาตรา 10 ถึง 12 มีหลักเรื่องความถูกต้องของข้อมูล น้ำหนักพยานหลักฐาน และการเก็บรักษาข้อมูล อ่านกฎหมายฉบับรวมแก้ไขในเว็บไซต์ ETDA
มาตรา 13/2 ยังรองรับสัญญาที่เกิดจากระบบอัตโนมัติอยู่แล้ว ข่าวรัฐบาลจึงไม่ควรอ่านว่าเพิ่งจะยอมรับสัญญาลักษณะนี้เป็นครั้งแรก ส่วนเงื่อนไขที่คู่สัญญาคาดหมายการทำงานตามปกติของระบบได้เป็นสิ่งที่ข่าวสรุปไว้ในข้อเสนอ ต้องตรวจตัวบทร่างและฉบับสุดท้ายต่อไป
บริษัทเริ่มจากตรวจว่าสัญญาที่เซ็นแล้วตรงกับฉบับที่อนุมัติหรือไม่ และมีหลักฐานอธิบายการเปลี่ยนเงื่อนไขได้หรือไม่ วิธีทำงานต่อจากนี้เป็นข้อเสนอของ Enersys ไม่ใช่รายการหน้าที่ใหม่ตามร่างกฎหมาย และต้องปรับให้เข้ากับประเภทธุรกรรม กฎหมายเฉพาะ และอำนาจอนุมัติของแต่ละบริษัท
ก่อนส่งลงนาม ต้องรู้ว่ากำลังส่งฉบับที่ใครอนุมัติ
กลับมาที่สัญญาบริการในตัวอย่าง ให้เรียกฉบับที่ฝ่ายการเงินอนุมัติเครดิต 30 วันว่า v1 และฉบับที่ลูกค้าขอเครดิต 60 วันว่า v2 v1 กับ v2 มีเงื่อนไขทางธุรกิจต่างกัน การอนุมัติ v1 จึงยังไม่ตอบว่าฝ่ายการเงินยอมรับเครดิต 60 วันใน v2 ด้วยหรือไม่
ในกระบวนการที่เสนอ ฝ่ายขายเป็นผู้บันทึกคำขอแก้ไขและแนบเอกสารเปรียบเทียบ ฝ่ายการเงินพิจารณาเครดิต 60 วันตามอำนาจของตน ฝ่ายกฎหมายตรวจหากการแก้ไขกระทบข้อสัญญาอื่น จากนั้นผู้รับผิดชอบสัญญาจึงส่งฉบับที่อนุมัติใหม่ให้ผู้มีอำนาจลงนาม การอนุมัติควรชี้ถึงไฟล์หรือเลขรุ่นที่แน่นอน ไม่ใช่ข้อความในอีเมลว่า “ตามที่คุยกัน”
ถ้ายังไม่ได้รับอนุมัติเงื่อนไขใหม่ ให้พักขั้นตอนส่งลงนามไว้ก่อน แต่ถ้า v2 เซ็นไปแล้ว อย่าแก้ PDF ให้กลับเป็น 30 วันหรือทับไฟล์เดิมเพื่อให้ตรงกับระบบบัญชี ให้เก็บไฟล์และการติดต่อเดิมไว้ แล้วส่งเรื่องให้ผู้มีอำนาจกับฝ่ายกฎหมายพิจารณาวิธีจัดการ การพบว่าผิดขั้นตอนอนุมัติภายในยังไม่ใช่ข้อสรุปว่าสัญญาไม่มีผล
ข้อผิดพลาดนี้อาจแก้ได้ด้วยการกำหนดจุดอนุมัติใหม่และสิทธิ์แก้ไฟล์ในระบบเดิม หากระบบแยกฉบับร่างกับฉบับที่อนุมัติไม่ได้ หรือไม่มีทางทราบว่าใครเปลี่ยนข้อความ จึงค่อยนำข้อจำกัดนั้นไปเป็นโจทย์เลือกซอฟต์แวร์
คนที่ใช้บัญชีลงนาม มีอำนาจลงนามเรื่องนี้หรือไม่
เมื่อได้ v2 ที่อนุมัติแล้ว ขั้นต่อไปคือกำหนดผู้ลงนามของทั้งสองฝ่าย การยืนยันว่าใครเปิดอีเมลหรือใช้บัญชีลงนามช่วยตอบเรื่องตัวบุคคล แต่ไม่ได้ตอบครบว่าบุคคลนั้นมีอำนาจทำสัญญาแทนบริษัทในเงื่อนไขนี้หรือไม่
ตัวอย่างเช่น หากเงื่อนไขของนิติบุคคลกำหนดให้กรรมการสองคนลงนามร่วมกัน การได้ลายมือชื่อจากคนหนึ่งไม่ใช่เหตุให้ทีมงานข้ามการตรวจอีกคน หรือหากผู้ลงนามเป็นผู้รับมอบอำนาจ ก็ต้องตรวจว่าขอบเขตที่มอบหมายครอบคลุมสัญญานี้หรือไม่ ETDA แยกกรณีผู้มีอำนาจลงนามกับผู้รับมอบอำนาจไว้ใน แนวทางการลงลายมือชื่ออิเล็กทรอนิกส์ ขมธอ. 23-2563 ซึ่งเป็นข้อเสนอแนะมาตรฐาน ไม่ใช่กฎหมายที่บังคับให้ทุกบริษัทใช้ขั้นตอนเดียวกัน
ในตัวอย่างของเรา ให้ฝ่ายกฎหมายหรือผู้ที่บริษัทมอบหมายตรวจเงื่อนไขลงนามและเอกสารประกอบ แล้วบันทึกว่าใช้ข้อมูลใดตรวจ ใครตรวจ และยังมีประเด็นใดค้างอยู่ ฝ่ายขายจึงส่งคำขอลงนามไปยังคนที่ผ่านการตรวจ ไม่ใช่เลือกผู้ติดต่อที่ตอบอีเมลเร็วที่สุดโดยอัตโนมัติ
หากชื่อผู้ลงนามไม่ตรงกับข้อมูลที่ตรวจ หรือหนังสือมอบอำนาจไม่ครอบคลุมเรื่องนี้ ให้ขอคำชี้แจงก่อนดำเนินงานขั้นต่อไป ไม่ควรให้เจ้าหน้าที่เปลี่ยนชื่อหรือแนบเอกสารใหม่ย้อนหลังโดยไม่เหลือประวัติ ส่วนสัญญาที่ลงนามไปแล้วควรให้ฝ่ายกฎหมายประเมินจากข้อเท็จจริง ไม่ตัดสินจากสถานะบนหน้าจออย่างเดียว
หลังเซ็นครบ ควรเก็บอะไรไว้ด้วยกัน
ไฟล์สัญญาที่ลงนามแล้วเป็นจุดเริ่มต้นของชุดเอกสาร แต่คำถามเรื่องการอนุมัติและอำนาจลงนามอาจต้องใช้หลักฐานจากที่อื่น การเก็บ PDF อย่างเดียวจึงอาจไม่พอสำหรับอธิบายเหตุการณ์ของบริษัท แม้จะเปิดอ่านเนื้อหาสัญญาได้ก็ตาม
สำหรับสัญญาตัวอย่าง อาจกำหนดรหัสอ้างอิงว่า SV-001 แล้วทำรายการเชื่อมไฟล์ที่เกี่ยวข้องไว้ดังนี้ รหัสและรูปแบบตารางนี้เป็นเพียงตัวอย่าง ไม่จำเป็นต้องซื้อระบบใหม่เพื่อทำตาม
| สิ่งที่ต้องอธิบาย |
เอกสารหรือข้อมูลที่เชื่อมไว้กับ SV-001 |
ผู้รับผิดชอบในตัวอย่าง |
| ทำไมจึงให้เครดิต 60 วัน |
v1, v2, รายการแก้ไข และผลอนุมัติ v2 ที่ระบุผู้อนุมัติ |
ฝ่ายขายและฝ่ายการเงิน |
| ใครมีอำนาจลงนาม |
ข้อมูลเงื่อนไขลงนามหรือการมอบอำนาจที่ใช้ตรวจ พร้อมชื่อผู้ตรวจ |
ฝ่ายกฎหมายหรือผู้ที่ได้รับมอบหมาย |
| คู่สัญญาลงนามในสัญญาฉบับไหน |
ไฟล์จากระบบลงนามฉบับสมบูรณ์และเอกสารแนบที่เป็นส่วนหนึ่งของสัญญา |
ผู้รับผิดชอบสัญญา |
| ระบบบันทึกการลงนามไว้อย่างไร |
บันทึกเหตุการณ์และข้อมูลตรวจสอบลายมือชื่อที่บริการนั้นมีให้ |
ไอทีร่วมกับผู้ให้บริการ |
| ใครค้นใช้ได้ และจะทบทวนการเก็บเมื่อใด |
ตำแหน่งจัดเก็บ สิทธิ์เข้าถึง และเงื่อนไขเก็บรักษาที่บริษัทกำหนด |
ผู้รับผิดชอบเอกสารร่วมกับฝ่ายกฎหมาย |
ตารางนี้เป็นสารบัญของหลักฐาน ไม่ใช่เหตุให้คัดลอกข้อมูลส่วนบุคคลทุกชิ้นมาไว้ในโฟลเดอร์เดียวกัน อาจเชื่อมไปยังแหล่งจัดเก็บที่มีสิทธิ์เข้าถึงต่างกันได้ ให้เก็บเท่าที่จำเป็นและกำหนดระยะเวลาตามกฎและความจำเป็นของธุรกรรม ไม่กำหนดจำนวนปีขึ้นมาเองเพราะโปรแกรมตั้งค่าเริ่มต้นไว้เช่นนั้น
ควรเก็บไฟล์ที่ได้รับจากระบบลงนามไว้ในรูปแบบเดิมด้วย การพิมพ์เป็น PDF ใหม่หรือถ่ายภาพหน้าจออาจไม่รักษาข้อมูลที่ใช้ตรวจสอบลายมือชื่อไว้เหมือนไฟล์เดิม ถ้าต้องใช้สำเนาสำหรับทำงาน ให้แยกจากไฟล์ที่เก็บเป็นหลักฐาน และถามผู้ให้บริการว่ารูปแบบใดตรวจสอบย้อนหลังได้
วันเวลาบนรายงาน ช่วยตอบคำถามอะไรได้บ้าง
สมมติว่ารายงานระบุว่าลูกค้าลงนามเวลา 09:00 แต่ไฟล์ที่ฝ่ายขายรับทางอีเมลแสดงเวลาอีกแบบหนึ่ง ยังไม่ควรสรุปว่ามีคนแก้ไขเอกสาร อาจเป็นเวลาเหตุการณ์คนละขั้น หรือใช้เขตเวลาต่างกัน
ให้ไอทีตรวจว่าระบบบันทึกเหตุการณ์อะไร ใช้แหล่งเวลาและเขตเวลาใด และรายการนั้นเชื่อมกับไฟล์ฉบับไหน เก็บคำอธิบายหรือผลตรวจไว้กับ SV-001 หากยังอธิบายไม่ได้ ให้ระบุข้อสงสัยไว้และขอข้อมูลจากผู้ให้บริการ แทนการปรับเวลาในรายงานให้ตรงกันเอง
เวลาจากบันทึกเหตุการณ์ทั่วไปกับบริการประทับเวลาที่มีวิธีตรวจสอบเฉพาะไม่ใช่สิ่งเดียวกัน การเลือกว่าจะใช้แบบใดควรอิงความเสี่ยงของธุรกรรมและข้อกำหนดที่เกี่ยวข้อง ไม่ใช่เห็นคำว่า timestamp ในรายการคุณสมบัติแล้วถือว่าเพียงพอทุกกรณี ETDA แนะนำให้เลือกวิธีลงลายมือชื่อให้เหมาะกับวัตถุประสงค์และความเสี่ยง
ทดสอบก่อนเปลี่ยนผู้ให้บริการ ด้วยการเปิดหลักฐานโดยไม่ใช้บัญชีเดิม
การทดสอบที่มีประโยชน์กว่าดูว่าปุ่มดาวน์โหลดทำงานหรือไม่ คือให้ผู้ที่ไม่ได้เจรจาสัญญาลองอธิบาย SV-001 จากข้อมูลที่ส่งออก โดยไม่ใช้บัญชีของฝ่ายขายหรือบัญชีผู้ดูแลระบบเป็นทางลัด ผู้ทดสอบควรมีสิทธิ์เข้าถึงเฉพาะข้อมูลที่จำเป็น
เริ่มจากถามว่าเอกสารฉบับไหนลงนามครบ ใครอนุมัติเครดิต 60 วัน ผู้ลงนามมีอำนาจจากหลักฐานใด และมีวิธีตรวจสอบไฟล์อย่างไร จากนั้นลองเปิดเอกสารแนบกับรายงานที่เชื่อมกัน หากข้อมูลอ่านได้เฉพาะในหน้าจอของผู้ให้บริการ ให้ถามต่อว่าหลังยกเลิกบริการจะตรวจด้วยวิธีใด และต้องจ่ายค่าเก็บหรือส่งออกข้อมูลเพิ่มหรือไม่
ผลทดสอบควรบอกได้ว่าต้องแก้อะไรและใครรับผิดชอบ เช่น ฝ่ายการเงินยืนยันช่องทางอนุมัติเครดิต ฝ่ายขายเลิกส่งฉบับที่ยังไม่อนุมัติ ไอทีทดสอบการส่งออก หรือฝ่ายกฎหมายตรวจเงื่อนไขเก็บหลักฐานหลังหมดสัญญาบริการ ประเด็นใดที่ยังไม่มีคำตอบให้ระบุว่า “ยังตรวจไม่ได้” พร้อมคนติดตาม ไม่ควรเปลี่ยนเป็น “ผ่าน” เพียงเพราะไฟล์เปิดได้
หากใช้ระบบเดิมทำสิ่งเหล่านี้ได้ การปรับวิธีทำงานอาจเป็นงานแรกที่ควรลงทุน แต่ถ้าระบบส่งออกหลักฐานที่จำเป็นไม่ได้ เรียกดูข้อมูลได้ผ่านบัญชีพนักงานเพียงคนเดียว หรือแยกฉบับอนุมัติกับฉบับที่ส่งเซ็นไม่ได้ ก็มีเหตุผลชัดขึ้นว่าต้องเปลี่ยนอะไรและจะตรวจรับระบบใหม่อย่างไร
คำถามที่ควรตอบก่อนอนุมัติโครงการ
มี PDF ที่เซ็นแล้ว จะตรวจว่าพอใช้กับงานของเราหรือไม่อย่างไร
เริ่มจากระบุว่าจะใช้เอกสารทำอะไร หากใช้วางบิล ให้ฝ่ายการเงินตรวจว่าเงื่อนไขชำระเงินตรงกับที่อนุมัติ หากต้องอธิบายว่าใครตกลงเปลี่ยนเงื่อนไข ให้ค้นผลอนุมัติและการติดต่อประกอบ หากต้องตรวจลายมือชื่อ ให้ทดสอบไฟล์และข้อมูลจากระบบลงนามด้วย ผู้ตรวจแต่ละเรื่องจึงอาจต้องใช้หลักฐานต่างกัน การเปิด PDF ได้ไม่ใช่คำตอบแทนทั้งหมด และการจัดชุดเอกสารก็ไม่รับประกันผลคดี
เมื่อไรควรแก้วิธีทำงาน และเมื่อไรควรเปลี่ยนโปรแกรม
หากหลักฐานอยู่ครบแต่ไม่มีคนรับผิดชอบอนุมัติเครดิตใหม่ ให้กำหนดผู้ตัดสินและขั้นตอนส่งกลับก่อน หากคนรับผิดชอบชัดแล้วแต่ระบบยังส่งฉบับที่ไม่อนุมัติไปเซ็นได้ ให้ตรวจว่าตั้งสิทธิ์หรือเพิ่มขั้นตอนตรวจได้หรือไม่ ส่วนข้อจำกัดที่แก้ไม่ได้ เช่น ส่งออกข้อมูลตรวจสอบที่ธุรกิจต้องใช้ไม่ได้ ควรบันทึกเป็นเงื่อนไขตรวจรับผู้ให้บริการรายใหม่ อย่าใช้คำว่า “มี audit trail” แทนรายละเอียดว่าต้องตรวจเหตุการณ์ใดได้บ้าง
ผู้รับผิดชอบกระบวนการควรนำผลตรวจไปเสนอผู้อนุมัติโครงการให้ตัดสินใจได้: สัญญาประเภทไหนจะทดลอง ใครตรวจแต่ละช่วง หลักฐานใดยังขาด และเรื่องใดต้องพักไว้จนกว่าผู้มีอำนาจจะตัดสิน การตอบได้ว่าสัญญาฉบับหนึ่งผ่านมือใครและเปลี่ยนเงื่อนไขเมื่อใด เป็นเกณฑ์ที่ใช้ตรวจงานได้ชัดกว่าคำว่า “รองรับการเซ็นออนไลน์”
ภาพประกอบสร้างด้วย AI เพื่ออธิบายการตามรอยเอกสารและการลงนาม ไม่ใช่ภาพระบบจริง เอกสารราชการ หรือหลักฐานว่าระบบใดผ่านข้อกำหนดทางกฎหมาย
แหล่งข้อมูลตรวจเมื่อ 18 ตุลาคม 2569: ข่าวทำเนียบรัฐบาล 29 กันยายน 2569, กฎหมายธุรกรรมทางอิเล็กทรอนิกส์ฉบับรวมแก้ไขในเว็บไซต์ ETDA, แนวทางการลงลายมือชื่ออิเล็กทรอนิกส์ ขมธอ. 23-2563 และ คำถามที่พบบ่อยเรื่อง e-Signature ของ ETDA ตัวอย่างสัญญาและวิธีตรวจงานเป็นข้อเสนอของ Enersys ไม่ใช่กรณีลูกค้าจริงหรือคำวินิจฉัยทางกฎหมาย
พูดคุยเรื่องการเชื่อมงานอนุมัติสัญญากับระบบข้อมูลธุรกิจ
