Odoo payroll Thailand: ประกันสังคม ภาษี PND และเครื่องมือท้องถิ่น
บริษัทไทยทุกรายที่เราเริ่มงานด้วยมักถามคำถามเดียวกัน Odoo รันเงินเดือนได้ครบวงจรไหม ทั้งประกันสังคมและการยื่น PND คำตอบตรงไปตรงมาคือใช่และไม่ใช่ แอป Payroll ของ Odoo รองรับโครงสร้างได้ดี แต่ส่วนที่เป็นกฎเฉพาะของไทยต้องตั้งค่าเพิ่มเอง บางกรณีเครื่องมือเงินเดือนท้องถิ่นกลับเป็นทางเลือกที่ดีกว่า บทความนี้อธิบายว่า Odoo payroll Thailand ต้องมีอะไรบ้าง จุดไหนที่ Odoo ทำได้ดีอยู่แล้ว และจุดไหนที่เราแนะนำให้ออกนอกแอปหลัก
เราไม่ได้เริ่มต้นจากการเป็นผู้ขายซอฟต์แวร์เงินเดือน เราเป็นที่ปรึกษา Odoo ที่ต้องดูแลเรื่องเงินเดือนไปด้วย เพราะงานนี้อยู่ติดกับงานบัญชี งาน HR และการปิดบัญชีสิ้นเดือนที่เราดูแลให้ลูกค้าอยู่แล้ว ความใกล้ชิดตรงนี้เองทำให้เรามีมุมมองชัดเจน ว่าเมื่อไหร่เงินเดือนควรอยู่ใน Odoo และเมื่อไหร่ไม่ควร
Odoo payroll Thailand ต้องการอะไรจริง ๆ
เงินเดือนในไทยไม่ใช่แค่เงินเดือนรวมหักค่าลดหย่อน การรันเงินเดือนให้ถูกต้องตามกฎหมายต้องมีอย่างน้อยสามอย่างทำงานร่วมกันทุกเดือน
- เงินสมทบกองทุนประกันสังคม (SSF) คำนวณจากฐานเงินเดือนที่มีเพดาน แบ่งจ่ายระหว่างลูกจ้างกับนายจ้าง และรายงานผ่านระบบของสำนักงานประกันสังคม
- ภาษีเงินได้บุคคลธรรมดาหัก ณ ที่จ่ายตามกระบวนการ PND 1 ตามอัตราภาษีแบบขั้นบันไดและค่าลดหย่อนที่พนักงานแจ้งไว้
- สลิปเงินเดือนและหนังสือรับรองภาษีประจำปี (50 ทวิ) ที่ตรงกับยอดที่ยื่นจริง ความไม่ตรงกันระหว่างบันทึกเงินเดือนกับการยื่น PND เป็นจุดแรกที่การตรวจแรงงานหรือการตรวจภาษีมักเช็ก
ไม่มีข้อไหนซับซ้อนเกินไป แต่แต่ละกฎเปลี่ยนตามประกาศของรัฐ เพดานเงินเดือนถูกปรับเป็นระยะ กฎค่าลดหย่อนก็เปลี่ยนตามรอบงบประมาณ การตั้งค่าที่ถูกต้องในวันขึ้นระบบจริงอาจคลาดเคลื่อนจากกฎหมายภายในหนึ่งปี ถ้าไม่มีใครรับผิดชอบอัปเดตต่อเนื่อง
จุดที่ Odoo payroll Thailand ทำได้ดีจริง
แอป Payroll ของ Odoo แข็งแรงในส่วนโครงสร้างของปัญหา คือการกำหนดกฎเงินเดือน สัญญาจ้าง และโครงสร้างแยกตามกลุ่มพนักงาน แอปนี้รันเครื่องคำนวณเทียบกับข้อมูลการเข้างานและวันลาที่ดึงมาจากฐานข้อมูลเดียวกับ HR สำหรับบริษัทที่ใช้ Odoo อยู่แล้วทั้งงานขาย คลังสินค้า และบัญชี การเก็บเงินเดือนไว้ในระบบเดียวกันมีข้อดีชัดเจน ต้นทุนพนักงาน ค่าใช้จ่ายเงินเดือน และงบประมาณแต่ละแผนกจะกระทบยอดกับบัญชีแยกประเภททั่วไปโดยอัตโนมัติ คุณไม่ต้องกระทบยอดไฟล์ส่งออกเงินเดือนกับผังบัญชีแยกต่างหากทุกเดือน
Odoo ยังจัดการฝั่งบัญชีได้เรียบร้อย รายการบันทึกบัญชีเงินเดือนถูกโพสต์เข้าบัญชีค่าใช้จ่ายและหนี้สินที่ถูกต้องโดยไม่ต้องทำสมุดรายวันด้วยมือ เพราะเราตั้งผังบัญชีไทยไว้ก่อน ก่อนเริ่มใช้ระบบเงินเดือนจริง รายการเหล่านั้นจึงลงในตำแหน่งที่นักบัญชีคาดหวังพอดี
สิ่งที่ยังขาดในระบบมาตรฐาน
ช่องว่างด้านการปรับให้เข้ากับไทยคือกฎตามกฎหมายโดยเฉพาะ ได้แก่ ตารางเงินสมทบ SSF การคำนวณหัก ณ ที่จ่ายตาม PND 1 และรูปแบบไฟล์ที่สำนักงานประกันสังคมกับกรมสรรพากรต้องการสำหรับการยื่นแบบอิเล็กทรอนิกส์ ไม่มีส่วนไหนมาพร้อมเป็นชุดปรับแต่งเงินเดือนไทยสำเร็จรูปใน Odoo มาตรฐาน ต่างจากโมดูล VAT และใบกำกับภาษีอิเล็กทรอนิกส์สำหรับภาษีขายที่มีมาให้แล้ว เราจึงต้องสร้างกฎเงินเดือนแบบกำหนดเองเพื่อจำลองเพดาน SSF และขั้นภาษี PND กฎเหล่านี้ต้องถูกตรวจสอบกับตารางของรัฐฉบับล่าสุดอย่างน้อยปีละครั้ง บางปีอาจบ่อยกว่านั้นถ้าเพดานเปลี่ยน
ตั้งค่า SSF และ PND สำหรับ Odoo payroll Thailand
เวลาที่เราเก็บเงินเดือนไว้ใน Odoo ขั้นตอนการสร้างระบบจะประมาณนี้
- กำหนดโครงสร้างเงินเดือนแยกตามกลุ่มพนักงาน (พนักงานรายเดือน รายวัน ผู้รับจ้างอิสระ) พร้อมชุดกฎของตัวเอง เพราะการปฏิบัติต่อ SSF แตกต่างกัน
- เพิ่มกฎเงินเดือนที่จำกัดเงินสมทบ SSF ไว้ที่เพดานของรัฐ คำนวณส่วนลูกจ้าง 5 เปอร์เซ็นต์ พร้อมส่วนนายจ้างที่เท่ากัน โดยโพสต์เข้าบัญชีเจ้าหนี้แยกกัน
- เพิ่มกฎภาษีหัก ณ ที่จ่ายที่ประมาณรายได้รายปี ใช้ขั้นภาษี PND 1 แบบขั้นบันได และหักค่าลดหย่อนมาตรฐานที่พนักงานยื่นไว้ (ค่าลดหย่อนส่วนตัว คู่สมรส บุตร เงินสะสมกองทุนสำรองเลี้ยงชีพ)
- สร้างสลิปเงินเดือนรายเดือนและรายงานภาษีหัก ณ ที่จ่ายที่กระทบยอดกับยอดที่นำส่งผ่าน PND 1 รายงานนี้ควบคู่กับรายงาน PND 3 และ PND 53 ที่เราตั้งค่าไว้แล้วสำหรับภาษีหัก ณ ที่จ่ายฝั่งผู้ขาย ซึ่งเป็นส่วนหนึ่งของบริการดูแลระบบ Odoo
- ออกหนังสือรับรองภาษีประจำปีต่อพนักงานแต่ละคนเมื่อสิ้นปี ให้ตรงกับยอดสะสมที่ยื่น PND 1 ตลอดปี
วิธีนี้ทำให้คุณได้ระบบเงินเดือนที่อยู่ในฐานข้อมูลเดียวกับบัญชี สลิปเงินเดือนและรายการบัญชีกระทบยอดกันอัตโนมัติ สิ่งที่ต้องแลกคือภาระดูแลรักษา ทุกครั้งที่เพดาน SSF หรือขั้นภาษีเปลี่ยน ต้องมีคนอัปเดตและทดสอบค่าคอนฟิกเอง ไม่ใช่แพตช์จากผู้พัฒนาที่มาเองอัตโนมัติ
เมื่อไหร่เครื่องมือเงินเดือนท้องถิ่นเป็นทางเลือกที่ดีกว่า
เราแนะนำให้เชื่อมต่อผู้ให้บริการเงินเดือนไทยโดยเฉพาะ แทนการสร้างทุกอย่างใน Odoo เมื่อเข้าเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้
- จำนวนพนักงานมากพอ หรืออัตราการเข้าออกสูงพอ จนความเสี่ยงด้านการปฏิบัติตามกฎหมายเงินเดือนมีน้ำหนักมากกว่าความสะดวกของการใช้ระบบเดียว แพลตฟอร์มเงินเดือนไทยเฉพาะทางมักอัปเดตกฎ SSF และ PND ทันทีที่เปลี่ยน เพราะนั่นคือธุรกิจหลักของเขา
- บริษัทมีสำนักงานเงินเดือนภายนอกอยู่แล้วด้วยเหตุผลด้านกฎหมายหรือการตรวจสอบ และต้องการเพียงให้รายการบัญชีที่ได้ถูกโพสต์เข้า Odoo
- นโยบาย HR ซับซ้อน เช่น ค่ากะ กองทุนสำรองเลี้ยงชีพหลายแบบ หรือข้อตกลงสหภาพแรงงาน ซึ่งเหมาะกับซอฟต์แวร์เงินเดือนที่สร้างมาเพื่อความซับซ้อนนั้นโดยเฉพาะมากกว่า
ในกรณีเหล่านี้รูปแบบการเชื่อมต่อของเราตรงไปตรงมา เครื่องมือเงินเดือนท้องถิ่นยังคงเป็นระบบหลักสำหรับการคำนวณเงินเดือนและการยื่นแบบตามกฎหมาย ส่วนเราสร้างการเชื่อมต่อ API หรือการนำเข้าข้อมูลตามรอบเวลาที่โพสต์รายการบัญชีสรุปเข้า Odoo ทุกเดือน แยกตามแผนกหรือศูนย์ต้นทุน ข้อมูลหลักของพนักงานยังคงอยู่ใน Odoo HR สำหรับผังองค์กร วันลา และการเข้างาน โดยซิงก์เฉพาะฟิลด์ที่เกี่ยวกับเงินเดือนทางเดียว
ตารางช่วยตัดสินใจ
| สถานการณ์ | แนวทางที่แนะนำ |
|---|---|
| ทีมเล็ก โครงสร้างเงินเดือนมาตรฐาน ไม่มีสวัสดิการซับซ้อน | รันเงินเดือนใน Odoo พร้อมกฎ SSF/PND แบบกำหนดเอง |
| พนักงานจำนวนมากหรือเติบโตเร็ว มีระบบเงินเดือนภายนอกอยู่แล้ว | คงเครื่องมือเงินเดือนภายนอก เชื่อมรายการบัญชีเข้า Odoo |
| หลายนิติบุคคลที่มีข้อกำหนดด้านกฎหมายต่างกัน | พิจารณาเป็นรายกรณี มักเป็นแบบผสม นิติบุคคลง่ายใช้ Odoo ซับซ้อนใช้ภายนอก |
| มีความเสี่ยงการตรวจสอบสูงหรือต้องรายงานแบบบริษัทมหาชน | ใช้ผู้ให้บริการเงินเดือนเฉพาะทาง ให้ Odoo ทำเฉพาะรวมบัญชี |
สิ่งที่ผิดพลาดเมื่อรีบทำระบบ
ข้อผิดพลาดที่เราเจอบ่อยที่สุดคือการมองเงินเดือนเป็นงานตั้งค่าครั้งเดียวจบ เหมือนที่บางทีมมองการตั้งค่า VAT เพดาน SSF และขั้นภาษี PND ไม่ใช่ค่าคงที่ เราเคยต้องแก้กฎเงินเดือนของลูกค้ามากกว่าหนึ่งครั้ง เพราะเพดานเงินเดือนเปลี่ยนกลางปี แล้วไม่มีใครอัปเดตกฎก่อนรอบเงินเดือนถัดไป ถ้าเงินเดือนยังอยู่ใน Odoo ต้องมีคนในทีมคุณหรือทีมเรากำหนดรอบตรวจสอบการปฏิบัติตามกฎหมายประจำปีไว้ในปฏิทินจริง เช็กลิสต์ตอนขึ้นระบบอย่างเดียวไม่พอ
ข้อผิดพลาดที่สองคือการข้ามการกระทบยอดระหว่างภาษีหัก ณ ที่จ่ายจากเงินเดือนกับการยื่น PND ที่ส่งผ่านฝั่งบัญชี สองงานนี้มักทำโดยคนละคนในคนละรอบเวลา ความคลาดเคลื่อนเล็กน้อยสะสมกลายเป็นความไม่ตรงกันจริงเมื่อถึงสิ้นปี เราจึงสร้างรายงานกระทบยอดไว้เป็นส่วนหนึ่งของการตั้งค่าเงินเดือนโดยเฉพาะ เพื่อให้จับความผิดพลาดได้ทุกเดือน ไม่ใช่ตอนตรวจสอบประจำปี
ข้อแนะนำของเราสำหรับ SME ไทยส่วนใหญ่
สำหรับบริษัทที่มีพนักงานต่ำกว่าประมาณ 50 คนและมีโครงสร้างเงินเดือนค่อนข้างมาตรฐาน เราแนะนำโดยทั่วไปให้สร้างระบบเงินเดือนใน Odoo พร้อมกฎ SSF และ PND แบบกำหนดเอง ประโยชน์จากข้อมูลบัญชีและเงินเดือนที่รวมเป็นหนึ่งเดียวคุ้มกว่าภาระดูแลรักษาที่ขนาดนี้ เกินขนาดนั้น หรือมีความซับซ้อนที่มีนัยสำคัญด้านสวัสดิการหรือโครงสร้างหลายนิติบุคคล เราเอนเอียงไปทางคงเครื่องมือเงินเดือนเฉพาะทางไว้ และเชื่อมเฉพาะสรุปบัญชีเข้า Odoo
ไม่ว่าจะเลือกทางไหน การตัดสินใจนี้ควรถูกทบทวนใหม่ทุกครั้งที่จำนวนพนักงานหรือความเสี่ยงด้านการปฏิบัติตามกฎหมายเปลี่ยนแปลงอย่างมีนัยสำคัญ อย่าตัดสินใจครั้งเดียวแล้วปล่อยไว้ หากคุณกำลังวางแผนสร้างระบบเงินเดือนหรือเชื่อมต่อกับผู้ให้บริการที่มีอยู่แล้ว เรายินดีให้คำปรึกษาผ่านบริการที่ปรึกษา Odoo ที่กำหนดขอบเขตเฉพาะสำหรับเงินเดือนตามกฎหมายไทยก่อนเริ่มตั้งค่าจริง
