Settlement และ Reconciliation ใน EWA ต่างกันอย่างไร?

Settlement และ Reconciliation เป็นชั้นงานที่เกี่ยวข้องกันแต่มีวัตถุประสงค์ต่างกัน ในสถาปัตยกรรม EWA นั้น Settlement ทำให้ผลทางการเงินของธุรกรรมหรือรอบการชำระเสร็จสมบูรณ์และบันทึกผล ขณะที่ Reconciliation เปรียบเทียบแหล่งข้อมูลอิสระเพื่อยืนยันว่าบันทึกเวลาทำงาน ธุรกรรมธนาคาร และระบบเงินเดือนบันทึกผลเดียวกัน

ก่อนอื่น: ทั้งคู่เกี่ยวข้องกับเงินแต่ตอบคนละคำถาม

คำสองคำนี้มักใช้แทนกัน เพราะทั้งคู่เกิดขึ้นหลังจากมีการสร้างธุรกรรม

อย่างไรก็ตาม สามารถแยกได้ชัดเจนว่า:

• Settlement: “ภาระทางการเงินนี้เสร็จสมบูรณ์และถูกบันทึกในท้ายที่สุดอย่างไร?”
• Reconciliation: “ระบบอิสระแต่ละระบบบันทึกผลเดียวกันหรือไม่?”

หากรวมทั้งสองงานเข้าด้วยกัน ระบบอาจถือว่าผลที่บันทึกไว้ถูกต้อง ทั้งที่ยังไม่ได้ตรวจสอบกับข้อมูลอิสระ

Settlement ในบทความนี้หมายถึงอะไร?

ธนาคาร เกตเวย์การชำระเงิน และระบบเงินเดือนอาจใช้คำว่า “settlement” ต่างกัน

ในบทความนี้ Settlement หมายถึง ขั้นตอนที่กำหนดผลทางการเงินสุดท้ายของธุรกรรมหรือรอบดำเนินงาน

ตัวอย่างสำหรับธุรกรรม EWA:

• มีการสร้างคำขอ;
• ธนาคารยืนยันผล;
• ระบบระบุจำนวนเงินที่จ่ายจริง;
• บัญชีธุรกรรมบันทึกยอดที่ได้รับ;
• มีการปรับปรุงค่าจ้างคงเหลือ

ในระดับรอบเงินเดือน Settlement ยังรวมถึง:

• การรวมยอดการจ่าย EWA ที่ยืนยันแล้ว;
• การลงยอดรวมที่ถูกต้องในระบบเงินเดือน;
• การกำหนดยอดคงเหลือที่ต้องจ่ายในรอบ;
• การปิดภาระที่เสร็จสมบูรณ์แล้ว

ดังนั้น Settlement จึงเน้นที่ การทำให้ภาระทางการเงินเสร็จสมบูรณ์

Reconciliation หมายถึงอะไร?

Reconciliation คือกระบวนการ เปรียบเทียบแหล่งข้อมูลอิสระตั้งแต่สองแหล่งขึ้นไป เพื่อดูว่าตรงกันหรือไม่

ตัวอย่างเช่น:

• บัญชี EWA บันทึกการจ่าย 500,000 ดองเวียดนาม;
• รายการเดินบัญชีธนาคารควรมีธุรกรรมที่สอดคล้องกัน;
• เงินเดือนปลายรอบควรสะท้อนยอดที่ได้รับไปแล้ว;
• สลิปเงินเดือนไม่ควรหักซ้ำ

หากข้อมูลทุกแหล่งตรงกัน ธุรกรรมหรือรอบนั้นถือว่ากระทบยอดแล้ว

หากไม่ตรงกัน ความแตกต่างต้องเข้าสู่คิวข้อยกเว้น

Reconciliation ไม่ได้สร้างธุรกรรม และไม่ควรเปลี่ยนตัวเลขเพียงเพื่อทำให้รายงานตรงกัน

ตารางเปรียบเทียบ Settlement และ Reconciliation

เกณฑ์	Settlement	Reconciliation
คำถามหลัก	ภาระทางการเงินเสร็จสมบูรณ์อย่างไร?	บัญชีแต่ละชุดตรงกันหรือไม่?
ช่วงเวลา	ระหว่าง/หลังวงจรธุรกรรมหรือเมื่อสิ้นรอบ	หลังมีข้อมูลจากหลายแหล่ง
ข้อมูลหลัก	สถานะธุรกรรม จำนวนเงิน รอบ	บัญชี EWA ธนาคาร เงินเดือน
ผลลัพธ์	ยอดที่จ่าย/ชำระ/คงเหลือ	ตรงกันหรือเป็นข้อยกเว้น
สร้างธุรกรรมหรือไม่?	อาจมีส่วนในการทำธุรกรรมให้เสร็จ	ไม่
หาความแตกต่างหรือไม่?	อาจพบ แต่ไม่ใช่เป้าหมายหลัก	ใช่ เป็นเป้าหมายหลัก
ปิดรอบหรือไม่?	อาจช่วยปิดภาระ	ยืนยันข้อมูลก่อนปิด
เมื่อไม่ชัดเจน	รักษาสถานะที่เหมาะสม	ส่งไปคิวข้อยกเว้น/สอบสวน

สองชั้นนี้ต้องเชื่อมกัน แต่ใช้แทนกันไม่ได้

ธุรกรรมผ่าน Settlement อย่างไร?

กระบวนการทั่วไปอาจเป็นดังนี้:

1. คำขอผ่านเงื่อนไข;
2. Payment Orchestration สร้างธุรกรรม;
3. ธนาคารประมวลผล;
4. มีการกำหนดสถานะสุดท้าย;
5. ธุรกรรมสำเร็จถูกลงบัญชี “ได้รับแล้ว”;
6. ยอดที่เกี่ยวข้องถูกล็อกไม่ให้นำกลับมาใช้ซ้ำ;
7. ภาระของธุรกรรมถือว่าเสร็จสมบูรณ์

หากสถานะจากธนาคารไม่แน่นอน Settlement ไม่ควรสรุปผลเอง

นี่คือจุดที่ใช้หลัก fail-closed: หากผลยังไม่ชัดเจน อย่าปิดเป็นสำเร็จหรือล้มเหลว

ธุรกรรมผ่าน Reconciliation อย่างไร?

เมื่อมีข้อมูลอิสระ ระบบจะเปรียบเทียบ:

1. รหัสธุรกรรมภายใน;
2. รหัสหรือเลขอ้างอิงธนาคาร;
3. จำนวนเงิน;
4. ผู้รับเงิน;
5. เวลา;
6. สถานะ;
7. รอบเงินเดือน;
8. จำนวนเงินที่ลงในระบบเงินเดือน

หากทุกอย่างตรงกัน สามารถทำเครื่องหมายว่ากระทบยอดสำเร็จ

หากมีข้อมูลหนึ่งรายการต่างกัน ระบบจะสร้างข้อยกเว้น

ประเด็นสำคัญคือ Reconciliation ใช้ แหล่งข้อมูลอิสระ เพื่อตรวจสอบผลที่ระบบบันทึกไว้

เหตุใดคำตอบจาก API จึงยังไม่เพียงพอที่จะถือว่ากระทบยอดแล้ว?

API ของธนาคารอาจตอบว่า “สำเร็จ” ระหว่างการประมวลผล

นี่เป็นสัญญาณสำคัญ แต่ระบบการเงินยังควรกระทบยอดอย่างอิสระภายหลัง

เหตุผลได้แก่:

• คำตอบแบบเรียลไทม์อาจสูญหายหรือผิดพลาด;
• ระบบภายในอาจบันทึกสถานะผิด;
• ธุรกรรมอาจถูกบันทึกสองครั้ง;
• รายการเดินบัญชีอาจมีธุรกรรมที่ระบบภายในไม่มี;
• ระบบเงินเดือนอาจใช้รอบผิด

Reconciliation เป็นการตรวจยืนยันขั้นสุดท้าย

Settlement ปลายรอบต่างจาก Settlement รายธุรกรรมอย่างไร?

Settlement มีได้สองระดับ

ระดับธุรกรรม

กำหนดว่าการจ่ายรายการหนึ่งเกิดขึ้นหรือไม่ เป็นจำนวนเท่าใด และบันทึกลงบัญชีธุรกรรม

ระดับรอบเงินเดือน

รวมธุรกรรมทั้งหมดในรอบและกำหนด:

• ยอดรวมที่ได้รับแล้ว;
• เงินคืนหรือรายการปรับปรุง;
• ยอดที่ต้องสะท้อนในระบบเงินเดือน;
• ค่าจ้างคงเหลือ

ทั้งสองระดับต้องมีข้อมูลที่ตรวจสอบย้อนกลับได้

เหตุใดจึงไม่ควร “กระทบยอดด้วยการแก้ตัวเลขให้ตรงกัน”?

ข้อผิดพลาดที่อันตรายคือ เมื่อบัญชีสองชุดต่างกัน ผู้ปฏิบัติงานแก้ตัวเลขฝั่งหนึ่งด้วยตนเองเพื่อให้ยอดรวมตรงกัน

การทำเช่นนี้ทำลายหลักฐานของสาเหตุ

กระบวนการที่ถูกต้องคือ:

1. เก็บข้อมูลต้นทาง;
2. สร้างข้อยกเว้น;
3. หาสาเหตุ;
4. ระบุว่าบัญชีใดผิด;
5. ทำรายการปรับปรุงทางธุรกิจที่ตรวจสอบย้อนกลับได้;
6. ขออนุมัติ;
7. กระทบยอดใหม่

การปรับปรุงทุกครั้งต้องมีร่องรอยการตรวจสอบ

ข้อยกเว้นที่พบบ่อยระหว่าง Settlement และ Reconciliation

ระบบบันทึกว่าสำเร็จ แต่รายการเดินบัญชีธนาคารไม่มี

ตรวจสอบธุรกรรมและหลักฐานจากธนาคาร

รายการเดินบัญชีแสดงว่าเงินออก แต่ระบบยังเป็น pending

คำตอบ API อาจสูญหาย อย่าส่งคำสั่งจ่ายใหม่

ธุรกรรมสำเร็จ แต่ระบบเงินเดือนไม่สะท้อนยอด

ยอดที่ได้รับแล้วอาจถูกจ่ายซ้ำเมื่อสิ้นรอบ

ระบบเงินเดือนหักยอดแล้ว แต่ธุรกรรมล้มเหลว

ค่าจ้างของพนักงานอาจลดลงทั้งที่ยังไม่ได้รับเงิน

ธุรกรรมอยู่ผิดรอบ

ตรวจสอบกฎ cut-off และรอบเงินเดือนที่เกี่ยวข้อง

มีธุรกรรมซ้ำ

เก็บทั้งสองบันทึก ระบุสาเหตุ และจัดการตามกระบวนการที่ถูกต้อง

ใครควรเป็นเจ้าของงานสองชั้นนี้?

ไม่จำเป็นต้องเป็นทีมเดียวกัน

สามารถแบ่งความรับผิดชอบได้ดังนี้:

• Payment Operations: ติดตาม Settlement ระดับธุรกรรม;
• Accounting/Reconciliation: กระทบยอดกับธนาคาร;
• Payroll: Settlement และการกระทบยอดปลายรอบ;
• Engineering: ดูแลการจัดการสถานะ idempotency และบันทึกระบบ;
• Product Operations: ประสานงานข้อยกเว้น

เมื่อเกิดความแตกต่าง ต้องระบุผู้รับผิดชอบให้ชัดเจน

ต้องมีข้อมูลใดเพื่อเชื่อมสองชั้นนี้?

อย่างน้อยต้องเก็บ:

• รหัสธุรกรรม;
• รหัสพนักงาน;
• บัญชีรับเงิน;
• จำนวนเงิน;
• เวลา;
• ลูกค้า;
• รอบเงินเดือน;
• สถานะธุรกรรม;
• เลขอ้างอิงธนาคาร;
• จำนวนเงินที่ลงในระบบเงินเดือน

Reconciliation ไม่ควรพึ่งชื่อหรือคำอธิบายการโอนแบบข้อความอิสระเป็นหลัก

เมื่อใดจึงถือว่ารอบหนึ่ง “ปิด” ได้?

ไม่ควรปิดรอบเพียงเพราะประมวลผลเงินเดือนแล้ว

ก่อนปิด นายจ้างควรทราบว่า:

• บันทึกเวลาทำงานมีสถานะสุดท้ายแล้ว;
• ธุรกรรมสำเร็จถูกรวมยอดแล้ว;
• ธุรกรรม pending มีแผนจัดการ;
• บัญชีธนาคารและบัญชีภายในกระทบยอดแล้ว;
• ระบบเงินเดือนสะท้อนจำนวนเงินที่ถูกต้อง;
• ข้อยกเว้นที่เหลือมีผู้รับผิดชอบ;
• เก็บรายงานเชื่อมโยงแล้ว

ไม่จำเป็นที่ทุกข้อยกเว้นจะหายไปทันที แต่ข้อยกเว้นที่ยังเปิดอยู่ทุกข้อจะต้องถูกระบุและควบคุม

KPI ที่ควรติดตามแยกกันสำหรับ Settlement และ Reconciliation

Settlement

• เวลาที่ใช้กำหนดสถานะสุดท้าย;
• จำนวนธุรกรรม pending;
• สัดส่วนธุรกรรมที่ต้องแทรกแซง;
• จำนวนธุรกรรมที่ลองใหม่;
• จำนวนธุรกรรมซ้ำ

Reconciliation

• อัตราการจับคู่อัตโนมัติ;
• จำนวนข้อยกเว้น;
• อายุของข้อยกเว้น;
• จำนวนความแตกต่างกับธนาคาร;
• จำนวนความแตกต่างกับเงินเดือน;
• เวลาที่ใช้ปิดการกระทบยอด

หากรวมตัวชี้วัดเหล่านี้เป็น KPI เดียว นายจ้างจะระบุได้ยากว่าปัญหาอยู่ที่การประมวลผลธุรกรรมหรือการเปรียบเทียบบัญชี

บทสรุป

Settlement และ Reconciliation เป็นคนละส่วนของห่วงโซ่ควบคุมเดียวกัน Settlement ทำให้ภาระทางการเงินเสร็จสมบูรณ์และบันทึกผล ส่วน Reconciliation ใช้แหล่งข้อมูลอิสระเพื่อพิสูจน์ว่าผลสอดคล้องกัน การแยกสองชั้นช่วยให้จัดการธุรกรรม pending ความแตกต่าง cut-off และเงินเดือนได้ง่ายขึ้น พร้อมรักษาการตรวจสอบย้อนกลับตั้งแต่ธุรกรรมถึงสลิปเงินเดือน

ผู้เขียน: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

คำปรึกษาเรื่องการเข้าถึงค่าจ้างที่ทำได้แล้วสำหรับนายจ้าง: สายด่วน 0937.022.655 · อีเมล info@nhankiet.vn · บริการเข้าถึงค่าจ้างที่ทำได้แล้วสำหรับนายจ้าง