สิ่งที่ทำให้ Workflow ล้มเหลว
หลายองค์กรพยายามแก้คอขวดด้วยการเพิ่มระบบอนุมัติ แต่ไม่แก้ข้อมูลต้นทาง ทำให้เอกสารผิดหรือไม่ครบยังคงไหลเข้าคิวและสร้างงานแก้ซ้ำใบแจ้งหนี้หนึ่งใบเดินทางผ่านหลายบทบาท ตั้งแต่ผู้ขอซื้อ ผู้รับของ ฝ่ายบัญชี ไปจนถึงผู้อนุมัติงบประมาณ หากขั้นตอนไม่ชัด เอกสารจะค้างในอีเมลและการตามงานจะขึ้นกับความจำของคน
แนวทางที่แข็งแรงคือ capture ข้อมูลก่อน ตรวจความถูกต้องและความซ้ำ จับคู่กับคำสั่งซื้อหรือใบรับของ แล้วค่อย route ตาม approval matrix เมื่อผ่านการอนุมัติจึงส่งข้อมูลเข้า ERP พร้อมเอกสารต้นฉบับและ audit trail
6 ขั้นตอนของ Invoice Approval ที่ควรออกแบบ
แยกให้ชัดระหว่างการรับเอกสาร การอ่านข้อมูล การตรวจเงื่อนไข การตัดสินใจ และการบันทึกเข้าระบบ เพราะแต่ละขั้นมีความเสี่ยงและผู้รับผิดชอบต่างกัน
Three-way match ช่วยหยุดการจ่ายที่ไม่ควรจ่าย
การเทียบ invoice กับ purchase order และ receiving report ช่วยตอบสามคำถาม: สั่งจริงหรือไม่ รับของจริงหรือไม่ และยอดกับราคาตรงกันหรือไม่ ถ้าไม่ตรงควรส่งเข้า exception queue พร้อมเหตุผล ไม่ใช่ให้ผู้อนุมัติเดาเองจากไฟล์หนึ่งใบ
กรณีไม่มี PO, คู่ค้าใหม่, เลขที่เอกสารซ้ำ หรือยอดต่างจากใบรับของ ควรกำหนดเส้นทางตรวจเฉพาะและผู้รับผิดชอบ การบังคับให้ทุกใบใช้เส้นทางเดียวจะทำให้รายการปกติช้าและรายการเสี่ยงหลุด
- ตรวจ vendor, invoice number, date และ amount ซ้ำ
- กำหนด tolerance ของยอดและจำนวนสินค้า
- บังคับตรวจเมื่อไม่มี PO หรือไม่มีหลักฐานรับของ
- เก็บเหตุผลของการ override และผู้อนุมัติ
Approval matrix ต้องอ่านง่ายและไม่ผูกกับคนเดียว
กำหนดกติกาตามวงเงิน หน่วยงาน ประเภทค่าใช้จ่าย และความเสี่ยง เช่น ยอดไม่เกินวงเงินให้หัวหน้าทีมอนุมัติ ยอดสูงหรืออยู่นอกงบให้ผู้บริหารตรวจ และรายการที่มีข้อมูลผิดให้ย้อนกลับเจ้าของเอกสาร
เพิ่ม SLA, escalation และ delegation เมื่อผู้อนุมัติไม่อยู่ ระบบควรแสดง context ที่จำเป็น เช่น PO, ใบรับของ, ประวัติคู่ค้า และยอดสะสม ไม่ใช่ส่งลิงก์ใบแจ้งหนี้เพียงไฟล์เดียว
- มีผู้อนุมัติสำรองและ delegation ตามช่วงเวลา
- แจ้งเตือนก่อนครบ SLA และ escalate เมื่อเกินกำหนด
- แยก operational approval กับ financial approval
- บันทึก approve, reject, return และ comment ทุกครั้ง
ส่งเข้า ERP อย่างปลอดภัยด้วย idempotency และ recovery
หลังอนุมัติ ระบบควรสร้างเลขอ้างอิงและส่งข้อมูลไป ERP เพียงครั้งเดียว หากการเชื่อมต่อขัดข้องต้อง retry ได้โดยไม่สร้างรายการซ้ำ และต้องเห็นสถานะว่าการส่งสำเร็จ รอส่ง หรือผิดพลาด
เก็บ payload ที่ส่ง ฟิลด์ที่ถูกแก้ ผลการตอบกลับ และลิงก์กลับไปยังเอกสารต้นฉบับ เพื่อให้ฝ่ายบัญชีตรวจได้ว่าข้อมูลใน ERP มาจากใบใดและใครเป็นผู้ยืนยัน
เช็กลิสต์ก่อนเริ่มใช้งาน
- มีสถานะตั้งแต่รับเข้าจนถึงบันทึกบัญชี
- ตรวจ duplicate และ three-way match
- มี exception queue ที่บอกเหตุผล
- approval matrix มีผู้แทนและ SLA
- ส่ง ERP แบบกันรายการซ้ำและ retry ได้
- audit trail เชื่อมกลับเอกสารต้นฉบับ
คำถามที่พบบ่อย
OCR อ่านถูกแล้วต้องอนุมัติอีกไหม
ต้อง เพราะ OCR ยืนยันได้เพียงข้อมูลที่อ่านจากภาพ ไม่ได้ยืนยันว่ารายการสั่งซื้อ รับของ หรืออยู่ในงบประมาณจริง
ถ้าไม่มี PO จะจ่ายไม่ได้เลยหรือไม่
ขึ้นกับนโยบาย อาจมีเส้นทาง non-PO ที่ต้องระบุเหตุผลและผู้อนุมัติสูงขึ้น แต่ไม่ควรปล่อยผ่านโดยไม่มีหลักฐาน
ควรวัดผล Workflow ด้วยอะไร
วัดเวลารับถึงอนุมัติ อัตรารายการที่ผ่านอัตโนมัติ จำนวน exception เวลาค้างต่อขั้น และอัตราการส่ง ERP สำเร็จโดยไม่ต้องแก้ซ้ำ
อ่านต่อจากแหล่งอ้างอิง: InvoicesOCR: approval workflow steps · Nexus AP: workflow controls · DUNA: OCR to ERP reliability