คิวอนุมัติใบแจ้งหนี้ผู้ขาย: คู่มือการตั้งค่าแบบง่าย

ทำไมการอนุมัติใบแจ้งหนี้จึงติดตามได้ยาก

การอนุมัติใบแจ้งหนี้มักเริ่มจากขั้นตอนง่ายๆ ผู้ขายส่งไฟล์ PDF ทางอีเมล มีคนตรวจสอบ แล้วฝ่ายการเงินจ่ายเงิน ขั้นตอนนี้เริ่มมีปัญหาเมื่อมีใบแจ้งหนี้เข้ามาเป็นประจำ ต้องมีหลายคนอนุมัติ หรือมีการเปลี่ยนแปลงรายการซื้อหลังจากสั่งซื้อแล้ว

อีเมลไม่เหมาะกับการติดตามสถานะการจ่ายเงิน ผู้ตรวจสอบคนหนึ่งอาจตอบกลับเฉพาะผู้ส่ง อีกคนอาจส่งต่อใบแจ้งหนี้โดยไม่มีบทสนทนาก่อนหน้า และไฟล์แนบเดียวกันอาจกระจายอยู่ในกล่องจดหมายหลายแห่ง ฝ่ายการเงินจึงต้องคอยถามว่าใบแจ้งหนี้อยู่ระหว่างตรวจสอบ มีข้อโต้แย้ง อนุมัติแล้ว หรือจ่ายเงินไปแล้ว

สเปรดชีตร่วมช่วยให้เห็นข้อมูลมากขึ้น แต่ก็สร้างปัญหาอื่น ผู้ใช้อาจเขียนทับเซลล์ ลืมอัปเดตแถว หรือใช้คำว่า «รอ» «รอดำเนินการ» และ «ต้องตรวจสอบ» ในความหมายต่างกัน สเปรดชีตอาจแสดงรายการใบแจ้งหนี้ได้ แต่ไม่ค่อยบอกว่าทำไมจึงอนุมัติยอดที่สูงขึ้น หรือใครต้องทำอะไรต่อ

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

คิวยังควรเปรียบเทียบใบแจ้งหนี้กับสิ่งที่ธุรกิจตั้งใจซื้อ การตรวจสอบการจับคู่สามารถเปรียบเทียบผู้ขาย เลขที่ใบสั่งซื้อ รายการสินค้าหรือบริการ จำนวน และราคาได้ ตัวอย่างเช่น สำนักงานสั่งจอภาพ 20 เครื่อง ราคาเครื่องละ $180 แต่ใบแจ้งหนี้ระบุ 22 เครื่อง ระบบควรแจ้งส่วนต่าง $360 ก่อนมีการอนุมัติจ่ายเงิน

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

การไม่ระบุเจ้าของงานทำให้เกิดความล่าช้านานที่สุด หัวหน้าทีมอาจคิดว่าฝ่ายจัดซื้อจะตรวจสอบคำสั่งซื้อ ฝ่ายจัดซื้ออาจคิดว่าผู้ขอซื้อจะยืนยันการรับสินค้า และฝ่ายการเงินอาจรอทั้งสองฝ่าย ใบแจ้งหนี้จึงไม่ถูกแตะต้องจนกว่าผู้ขายจะถามเรื่องการจ่ายเงิน

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

เลือกข้อมูลที่คิวต้องมี

คิวอนุมัติใบแจ้งหนี้ผู้ขายทำงานได้ดีที่สุดเมื่อใบแจ้งหนี้ทุกใบมีข้อมูลพื้นฐานเหมือนกัน ผู้ตรวจสอบไม่ควรต้องเปิดหลายไฟล์หรือถามฝ่ายเจ้าหนี้การค้าหาข้อมูลที่ขาดก่อนตัดสินใจ

เริ่มจากระเบียนใบแจ้งหนี้ กำหนดรหัสภายในที่ไม่ซ้ำกันให้แต่ละรายการ แล้วเก็บชื่อผู้ขาย เลขที่ใบแจ้งหนี้ วันที่ออกใบแจ้งหนี้ ยอดรวม สกุลเงิน วันครบกำหนด และไฟล์ต้นฉบับของใบแจ้งหนี้ไว้ เลขที่ใบแจ้งหนี้จากผู้ขายควรอยู่ในฟิลด์ของตัวเอง เพราะผู้ขายต่างรายอาจใช้เลขเดียวกัน

วางรายละเอียดการซื้อไว้ข้างรายละเอียดใบแจ้งหนี้ ผู้ตรวจสอบต้องเห็นเลขที่ใบสั่งซื้อ รายการสินค้าหรือบริการ จำนวนที่สั่ง จำนวนที่รับ ราคาต่อหน่วยที่ตกลง และยอดรวมในใบสั่งซื้อ สำหรับบริการ ให้ใช้ฟิลด์อย่าง «ยืนยันงานแล้ว» แทนจำนวนที่รับ วิธีนี้ทำให้ระเบียนเหมาะกับงาน โดยไม่บังคับให้ทุกใบแจ้งหนี้มีฟิลด์รับสินค้า

ระเบียนใบแจ้งหนี้ที่ใช้งานได้จริงควรมี:

• ผู้ขาย ผู้ติดต่อของผู้ขาย เลขที่ใบแจ้งหนี้ และไฟล์แนบ
• วันที่ออกใบแจ้งหนี้ วันครบกำหนด จำนวนเงิน ภาษี สกุลเงิน และเงื่อนไขการจ่ายเงิน
• เลขที่ใบสั่งซื้อ ยอดที่สั่ง ยอดที่รับ และราคาที่ตกลง
• สถานะปัจจุบัน ผู้ตรวจสอบ วันที่ตัดสินใจ และหมายเหตุของผู้ตรวจสอบ
• ประเภทส่วนต่าง จำนวนส่วนต่าง และเอกสารประกอบ

ใช้สถานะที่อธิบายกระบวนการอนุมัติการจ่ายเงินจริง «ใหม่» หมายถึงทีมยังไม่ได้ตรวจสอบใบแจ้งหนี้ «อยู่ระหว่างตรวจสอบ» หมายถึงมีผู้รับผิดชอบแล้ว «รอการแก้ไข» หมายถึงผู้ขายหรือผู้ซื้อต้องตอบกลับ «อนุมัติแล้ว» หมายถึงฝ่ายการเงินจัดตารางจ่ายเงินได้ ส่วน «ปฏิเสธ» หมายถึงปิดคำขอพร้อมเหตุผลที่บันทึกไว้

หลีกเลี่ยงป้ายกำกวมอย่าง «รอดำเนินการ» เพราะไม่บอกว่าใบแจ้งหนี้กำลังรอผู้จัดการ การยืนยันรับสินค้า หรือราคาที่แก้ไขแล้ว สถานะเฉพาะช่วยให้หัวหน้างานกรองคิวและเห็นการดำเนินการถัดไปได้รวดเร็ว

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

ตัวอย่างเช่น ผู้ตรวจสอบคลังสินค้าสามารถยืนยันว่าได้รับเก้าอี้ 48 ตัว จากคำสั่งซื้อ 50 ตัว คิวควรแสดงส่วนต่างสองตัว คงใบแจ้งหนี้ไว้ระหว่างตรวจสอบ และส่งเรื่องให้ผู้ซื้อ ระเบียนเดียวนี้จะเก็บเหตุผลของความล่าช้าและป้องกันการจ่ายเงินก่อนเวลา

วางเส้นทางอนุมัติก่อนสร้างระบบ

เขียนเส้นทางที่ใบแจ้งหนี้ต้องผ่านให้ชัดเจนก่อนสร้างฟิลด์ หน้าจอ หรือระบบอัตโนมัติ เส้นทางที่กำหนดไว้ช่วยป้องกันไม่ให้ใบแจ้งหนี้ค้างอยู่ในกล่องจดหมายร่วม เพราะทุกคนคิดว่าคนอื่นจะจัดการ

กระบวนการเริ่มเมื่อเจ้าหน้าที่ฝ่ายเจ้าหนี้การค้าเพิ่มใบแจ้งหนี้หรืออัปโหลดไฟล์ บันทึกผู้ขาย เลขที่ใบแจ้งหนี้ วันที่ ยอดรวม แผนก เลขที่ใบสั่งซื้อ และวันครบกำหนด ตั้งสถานะเป็น «ได้รับแล้ว» และมอบหมายผู้รับผิดชอบทันที

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

เลือกผู้ตรวจสอบตามประเภทใบแจ้งหนี้

ไม่ควรใช้เส้นทางเดียวกับใบเรียกเก็บเงินทุกประเภท คำสั่งซื้ออุปกรณ์สำนักงานราคา $75 และใบแจ้งหนี้ค่าที่ปรึกษา $25,000 ต้องมีการตรวจสอบต่างกัน สร้างกฎการมอบหมายจากข้อมูลที่มีอยู่แล้วในระเบียนใบแจ้งหนี้

ตัวอย่างเช่น กระบวนการอนุมัติใบแจ้งหนี้อาจ:

• ส่งใบแจ้งหนี้การตลาดให้เจ้าของงบประมาณฝ่ายการตลาด
• ส่งใบแจ้งหนี้ที่เกินจำนวนที่กำหนดให้ผู้จัดการแผนกและฝ่ายการเงิน
• ส่งการซื้ออุปกรณ์ให้พนักงานผู้ขอรายการนั้น
• ส่งใบแจ้งหนี้ที่ไม่มีใบสั่งซื้อให้ผู้รับผิดชอบแผนกนั้น
• ส่งใบเรียกเก็บเงินประจำของผู้ขายให้ฝ่ายการเงิน หลังจากใบแจ้งหนี้แรกได้รับอนุมัติและยืนยันเงื่อนไขแล้ว

กำหนดผู้ตรวจสอบสำรองสำหรับกรณีไม่อยู่ ตั้งการแจ้งเตือนหลังช่วงเวลาที่เหมาะสม เช่น สองวันทำการสำหรับใบแจ้งหนี้ทั่วไป คิวควรแสดงว่าใครถือใบแจ้งหนี้อยู่ ได้รับเมื่อใด และได้รับเพราะอะไร

บันทึกผลการตัดสินใจจ่ายเงินให้ชัดเจน

เมื่อผู้ตรวจสอบที่จำเป็นอนุมัติครบแล้ว ให้ย้ายใบแจ้งหนี้ไปที่ «พร้อมจ่ายเงิน» จากนั้นฝ่ายการเงินบันทึกผลการตัดสินใจว่าอนุมัติให้จ่าย ระงับ หรือปฏิเสธ เก็บวันที่ตัดสินใจ ชื่อผู้ตัดสินใจ และเหตุผลสั้นๆ ไว้ในระเบียนเดียวกัน

ใบแจ้งหนี้ที่ถูกปฏิเสธควรส่งกลับไปยังเจ้าของงานที่กำหนด เช่น ฝ่ายเจ้าหนี้การค้าหรือผู้ขอซื้อ พร้อมเหตุผลที่ชัดเจน «ตรวจสอบราคาในบรรทัดที่ 3» บอกงานที่ต้องทำได้ชัดเจนกว่า «ต้องตรวจสอบ»

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

สร้างคิวทีละขั้นตอน

เริ่มจากระเบียนที่เชื่อมโยงกันสองประเภท คือ ผู้ขายและใบแจ้งหนี้ ระเบียนผู้ขายเก็บชื่อผู้จัดหา ข้อมูลติดต่อ เงื่อนไขการจ่ายเงิน และข้อมูลภาษี ระเบียนใบแจ้งหนี้เก็บเลขที่ใบแจ้งหนี้ วันที่ออก วันครบกำหนด จำนวนเงิน สกุลเงิน และเอกสารแนบ

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

ใน AppMaster ให้สร้างระเบียนเหล่านี้ใน Data Designer และเชื่อมโยงด้วยความสัมพันธ์ ผู้ขายหนึ่งรายมีใบแจ้งหนี้ได้หลายใบ และใบแจ้งหนี้หนึ่งใบอาจมีหลายบรรทัดการซื้อ เมื่อผู้ขายเรียกเก็บเงินจากคำสั่งซื้อหลายรายการ

เพิ่มฟิลด์ที่ผู้ตรวจสอบต้องใช้

กำหนดสถานะให้ใบแจ้งหนี้ทุกใบและทำตัวเลือกให้เรียบง่าย:

• ร่าง เมื่อมีคนกรอกข้อมูลแล้วแต่ยังไม่ได้ส่งตรวจสอบ
• รอตรวจสอบ เมื่อผู้ตรวจสอบที่ได้รับมอบหมายต้องดำเนินการ
• ต้องการคำชี้แจง เมื่อยอดหรือรายละเอียดการซื้อไม่ตรงกัน
• อนุมัติหรือปฏิเสธ หลังผู้ตรวจสอบบันทึกผลตัดสินใจ
• ชำระเงินแล้ว หลังฝ่ายการเงินยืนยันการจ่าย

เพิ่มผู้ตรวจสอบ วันที่ตัดสินใจ ความเห็น และเหตุผลของส่วนต่าง ผู้ตรวจสอบควรเลือกเหตุผล เช่น «ราคาต่างจากคำสั่งซื้อ» หรือ «ยังไม่ได้รับสินค้า» แทนการเขียนหมายเหตุกว้างๆ และยังเพิ่มความเห็นสั้นๆ เพื่อให้บริบทได้

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

สร้างคิวสำหรับทำงาน

สร้างมุมมองคิวสำหรับฝ่ายการเงินและผู้ตรวจสอบ แสดงผู้ขาย เลขที่ใบแจ้งหนี้ จำนวนเงิน วันครบกำหนด สถานะ ผู้ตรวจสอบ และธงส่วนต่าง เรียงใบแจ้งหนี้ที่ยังไม่ชำระตามวันครบกำหนด แล้ววางรายการที่รอตรวจสอบไว้เหนือรายการร่าง

ใช้ตัวกรองเพื่อให้ผู้ตรวจสอบเห็นเฉพาะใบแจ้งหนี้ของตน ขณะที่ฝ่ายการเงินเห็นรายการที่เปิดอยู่ทั้งหมด ใช้ธงสีแดงกับใบแจ้งหนี้เกินกำหนดได้ แต่ควรเก็บรายการที่ถูกปฏิเสธไว้ในตัวกรองสถานะแยกต่างหาก ทีมยังต้องมีประวัติการจ่ายเงินครบถ้วน

ตัวอย่างเช่น ใบแจ้งหนี้ที่ครบกำหนดวันศุกร์และมีราคาต่างจากคำสั่งซื้อควรแสดงสถานะ «ต้องการคำชี้แจง» และไม่เข้าสู่ขั้นตอนอนุมัติจ่ายจนกว่าจะมีคนแก้ไข คิวจะแสดงว่าใครรับผิดชอบการดำเนินการถัดไปและเพราะเหตุใดใบแจ้งหนี้จึงหยุดอยู่

กำหนดกฎการจับคู่และส่วนต่าง

กฎการจับคู่จะกำหนดว่าใบแจ้งหนี้ใดเดินหน้าต่อได้โดยไม่ต้องตรวจสอบด้วยตนเอง ในเวอร์ชันแรกควรทำให้เรียบง่าย เปรียบเทียบใบแจ้งหนี้กับใบสั่งซื้อและระเบียนรับสินค้า หากทีมไม่ได้บันทึกจำนวนที่รับ ให้เปรียบเทียบกับจำนวนที่สั่งและส่งรายการผิดปกติให้ผู้ซื้อก่อนจ่ายเงิน

ใช้การจับคู่สามทางเมื่อมีระเบียนครบทั้งสามประเภท คิวจะตรวจสอบสิ่งที่ธุรกิจสั่ง สิ่งที่มาถึง และสิ่งที่ผู้ขายเรียกเก็บ วิธีนี้ช่วยพบปัญหาทั่วไป เช่น ผู้ขายเรียกเก็บ 20 หน่วย ใบสั่งซื้อระบุ 20 หน่วย แต่คลังสินค้าได้รับเพียง 16 หน่วย

กำหนดค่าความคลาดเคลื่อนที่ยอมรับได้สำหรับส่วนต่างเล็กน้อย ส่วนต่างจากการปัดเศษหนึ่งเซนต์ไม่ควรหยุดใบแจ้งหนี้ แต่ราคาที่เพิ่มขึ้น 10% น่าจะต้องตรวจสอบ ฝ่ายการเงินและฝ่ายจัดซื้อควรตกลงขีดจำกัดเหล่านี้ก่อนใช้คิว

ตรวจสอบรายละเอียดเดียวกันในใบแจ้งหนี้ทุกใบ:

• จำนวนที่เรียกเก็บเทียบกับจำนวนที่รับหรือจำนวนที่สั่ง
• ราคาต่อหน่วยเทียบกับราคาในใบสั่งซื้อที่อนุมัติ
• ภาษีขาย VAT หรือภาษีอื่นเทียบกับอัตราที่คาดไว้
• ค่าขนส่ง ค่าดำเนินการ และค่าธรรมเนียมเพิ่มเติมเทียบกับเงื่อนไขการซื้อ
• ยอดรวมในใบแจ้งหนี้เทียบกับยอดที่คำนวณได้

เมื่อคิวพบส่วนต่าง อย่าใช้สถานะกว้างๆ อย่าง «ข้อผิดพลาด» ให้บันทึกเหตุผลที่อธิบายปัญหา «จำนวนที่เรียกเก็บมากกว่าจำนวนที่รับ 4 หน่วย» บอกผู้ซื้อได้ว่าต้องตรวจอะไร «ภาษีสูงกว่ายอดที่คาดไว้ $18.40» บอกฝ่ายเจ้าหนี้การค้าว่าควรเริ่มค้นหาที่ใด

กำหนดหมวดหมู่ หมายเหตุสั้นๆ เจ้าของงาน และวันครบกำหนดให้ส่วนต่างแต่ละรายการ หมวดหมู่อาจมีจำนวน ราคา ภาษี ค่าขนส่ง ใบแจ้งหนี้ซ้ำ และไม่มีใบสั่งซื้อ เจ้าของงานควรเป็นบุคคลหรือบทบาทที่ระบุชื่อ เช่น ผู้ซื้อ เจ้าหน้าที่รับสินค้า หรือผู้ติดต่อของผู้ขาย วันครบกำหนดช่วยป้องกันไม่ให้ใบแจ้งหนี้อยู่ในสถานะถูกแจ้งเตือนเป็นเวลาหลายสัปดาห์

ส่งใบแจ้งหนี้ไปตามประเภทปัญหา ส่งส่วนต่างของราคาให้ผู้ซื้อที่อนุมัติการซื้อ ส่งรายการที่ไม่มีข้อมูลการส่งมอบให้ผู้รับผิดชอบการรับสินค้า และขอใบแจ้งหนี้ฉบับแก้ไขจากผู้ติดต่อของผู้ขายเมื่อผู้ขายเรียกเก็บยอดผิดหรือเพิ่มค่าธรรมเนียมที่ไม่ได้อนุมัติ

ระงับการจ่ายเงินขณะที่ยังมีส่วนต่างสำคัญที่ไม่แก้ไข ผู้ตรวจสอบอาจอนุมัติการจ่ายบางส่วนได้หากนโยบายบริษัทอนุญาต และคิวบันทึกจำนวนเงิน เหตุผล และผลการตัดสินใจไว้ เมื่อเจ้าของงานแก้ไขปัญหาแล้ว ให้ส่งใบแจ้งหนี้กลับไปยังขั้นตอนอนุมัติพร้อมแนบข้อมูลการแก้ไข

ตัวอย่างการดำเนินการกับใบแจ้งหนี้

ผู้ประสานงานฝ่ายอาคารสั่งเก้าอี้สำนักงาน 20 ตัวสำหรับทีมที่กำลังขยาย ใบสั่งซื้อกำหนดราคาต่อตัว $180 รวมค่าสินค้า $3,600 และระบุผู้จัดการฝ่ายจัดซื้อเป็นผู้ตรวจสอบ พร้อมกำหนดเงื่อนไขการจ่ายเงิน 30 วัน

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

ข้อมูลส่วนใหญ่ตรงกัน ทั้งผู้จัดหา เลขที่คำสั่งซื้อ และจำนวนเก้าอี้ 20 ตัว แต่ใบแจ้งหนี้คิดราคาเก้าอี้ตัวละ $190 ทำให้ค่าสินค้ารวมเป็น $3,800 ส่วนต่าง $200 มากกว่าค่าความคลาดเคลื่อนด้านราคาที่ทีมยอมรับได้ ระบบจึงเปลี่ยนสถานะของกระบวนการอนุมัติใบแจ้งหนี้เป็น «ต้องตรวจสอบ»

ผู้ตรวจสอบแก้ไขส่วนต่าง

คิวมอบหมายรายการให้ผู้จัดการฝ่ายจัดซื้อซึ่งเป็นผู้สั่งซื้อ เขาเห็นใบสั่งซื้อเดิมอยู่ข้างใบแจ้งหนี้ จึงไม่ต้องค้นหาเธรดอีเมล

ผู้จัดการตรวจสอบข้อความจากผู้จัดหาและพบว่าเก้าอี้รุ่นเดิมไม่มีสินค้า จึงอนุมัติรุ่นทดแทนที่ราคาสูงกว่า แต่ไม่มีใครอัปเดตใบสั่งซื้อ เขาเพิ่มความเห็นว่า «อนุมัติเก้าอี้ทดแทนในราคาตัวละ $190 อัปเดตใบสั่งซื้อเป็น $3,800» จากนั้นเลือก «อนุมัติพร้อมแก้ไข» แทนการปฏิเสธใบแจ้งหนี้ที่ธุรกิจยังจำเป็นต้องจ่าย

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

ส่งระเบียนไปยังการจ่ายเงิน

คิวอัปเดตยอดในใบสั่งซื้อเป็น $3,800 หรือทำเครื่องหมายให้แก้ไข ตามกฎของทีม ระบบบันทึกชื่อผู้จัดการ ผลตัดสินใจ ความเห็น และเวลาตัดสินใจ ใบแจ้งหนี้มีจำนวนตรงกันและราคาที่อนุมัติแล้ว

จากนั้นคิวส่งระเบียนให้ผู้จัดตารางจ่ายเงิน เห็นยอดที่อนุมัติ วันครบกำหนด เงื่อนไขการจ่าย และหมายเหตุของผู้จัดการ เขาจัดตารางจ่ายเงิน $3,800 ตามวันที่ตกลง แล้วเปลี่ยนสถานะเป็น «จัดตารางจ่ายเงินแล้ว»

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

ข้อผิดพลาดที่ทำให้การจ่ายเงินล่าช้า

คิวอนุมัติใบแจ้งหนี้ผู้ขายจะช้าลงเมื่อปฏิบัติต่อใบแจ้งหนี้ทุกใบเหมือนกัน ใบแจ้งหนี้ทั่วไปที่ตรงกับใบสั่งซื้อและระเบียนส่งมอบไม่ควรรอการอนุมัติจากห้าคน กำหนดระดับการอนุมัติตามจำนวนเงิน แผนก ผู้ขาย หรือสถานะส่วนต่าง ส่งใบแจ้งหนี้ให้เฉพาะผู้ที่ต้องตัดสินใจ

ตัวอย่างเช่น ใบแจ้งหนี้วัสดุสำนักงานราคา $180 อาจส่งตรงไปยังเจ้าของงบประมาณหลังจับคู่สำเร็จ ส่วนใบแจ้งหนี้ที่สูงกว่าใบสั่งซื้อ $1,200 ควรส่งให้ผู้ซื้อและผู้ตรวจสอบฝ่ายการเงิน วิธีนี้ทำให้การจ่ายเงินทั่วไปเดินหน้า ขณะที่รายการผิดปกติได้รับการตรวจสอบอย่างรอบคอบ

อย่าแทนที่ยอดในใบแจ้งหนี้เดิมเมื่อพบส่วนต่าง เก็บยอดที่ผู้ขายส่งมา ยอดในใบสั่งซื้อ และยอดที่แก้ไขแล้วไว้ในฟิลด์แยกกัน ฝ่ายการเงินต้องเห็นชัดว่าอะไรเข้ามา ทีมคาดหวังอะไร และเหตุใดยอดสุดท้ายจึงเปลี่ยน

หากผู้ขายเรียกเก็บ $2,450 จากใบสั่งซื้อ $2,300 คิวควรเก็บตัวเลขทั้งสองไว้ ผู้ตรวจสอบจะได้บันทึกว่าส่วนต่าง $150 เป็นการเปลี่ยนแปลงที่อนุมัติ ค่าขนส่ง หรือข้อผิดพลาด การเขียนทับยอดเดิมทำให้ติดตามส่วนต่างของใบแจ้งหนี้ยากขึ้นและสร้างความสับสนระหว่างการตรวจสอบบัญชี

การปฏิเสธและการขอแก้ไขต้องมีเหตุผลเป็นลายลักษณ์อักษรเช่นกัน สถานะเพียงอย่างเดียวบอกคนถัดไปได้น้อยมาก กำหนดให้มีหมายเหตุสั้นๆ เช่น «จำนวนไม่ตรงกับระเบียนรับสินค้า» หรือ «โปรดแนบการอนุมัติจากผู้จัดการสำหรับชั่วโมงบริการเพิ่มเติม» ผู้ติดต่อของผู้ขาย ผู้ซื้อ และฝ่ายการเงินจะได้ดำเนินการโดยไม่ต้องเดา

กฎที่มีประโยชน์ ได้แก่:

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

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

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

ตรวจสอบอย่างรวดเร็วก่อนให้ทีมใช้งาน

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

ตรวจสอบข้อมูลที่จำเป็นสำหรับใบแจ้งหนี้แต่ละรายการ แบบฟอร์มควรป้องกันไม่ให้ส่งใบแจ้งหนี้ที่ไม่มีผู้ขาย วันครบกำหนด ยอดรวม หรือไฟล์ใบแจ้งหนี้แนบ ฟิลด์เหล่านี้ช่วยให้ผู้ตรวจสอบตัดสินใจและให้ฝ่ายการเงินตรวจสอบภายหลังได้

ตรวจสอบมุมมองคิวด้วย แต่ละแถวควรแสดงผู้ขาย จำนวนเงิน วันครบกำหนด สถานะปัจจุบัน ผู้ตรวจสอบ และการดำเนินการถัดไป ผู้ตรวจสอบควรรู้ว่าจะอนุมัติ ปฏิเสธ ขอแก้ไข หรือรอใคร โดยไม่ต้องเปิดหลายระเบียน

ใช้กรณีทดสอบสองแบบกับกระบวนการอนุมัติใบแจ้งหนี้:

• ส่งใบแจ้งหนี้ที่ผู้ขาย รายละเอียดใบสั่งซื้อ จำนวน และราคาตรงกันทั้งหมด ยืนยันว่าไปถึงผู้ตรวจสอบที่ถูกต้องและเดินหน้าไปยังการอนุมัติจ่ายได้
• ส่งใบแจ้งหนี้ที่มีส่วนต่างของราคา ยืนยันว่าคิวแจ้งส่วนต่าง บันทึกเหตุผล และป้องกันการจ่ายเงินจนกว่าผู้รับผิดชอบจะแก้ไข

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

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

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

นำคิวไปใช้ประจำวันด้วย AppMaster

เริ่มจากขอบเขตเล็กๆ นำใบแจ้งหนี้ประเภทเดียวผ่านเส้นทางเดียวก่อนเพิ่มกรณีพิเศษ แผนกอื่น หรือกฎการจ่ายหลายแบบ ตัวอย่างเช่น เริ่มจากใบแจ้งหนี้ตามใบสั่งซื้อทั่วไปที่เดินจากผู้ซื้อไปฝ่ายการเงิน แล้วไปยังผู้อนุมัติการจ่ายเงิน

AppMaster ช่วยให้ทีมสร้างแอปนี้โดยไม่ต้องเขียนโค้ด ใน Data Designer ให้สร้างระเบียนผู้ขาย ใบสั่งซื้อ ใบแจ้งหนี้ รายการในใบแจ้งหนี้ ผู้ตรวจสอบ หมายเหตุส่วนต่าง และผลการตัดสินใจจ่ายเงิน กำหนดสถานะที่ชัดเจน เช่น ร่าง รอตรวจสอบ ต้องแก้ไข อนุมัติ หรือปฏิเสธ

ใช้ Business Process Editor เพื่อกำหนดสิ่งที่จะเกิดขึ้นหลังแต่ละการดำเนินการ เมื่อเจ้าหน้าที่เพิ่มใบแจ้งหนี้ ระบบสามารถเปรียบเทียบผู้ขาย เลขที่ใบสั่งซื้อ จำนวน และยอดรวมกับรายละเอียดการซื้อที่เกี่ยวข้อง หากยอดต่างเกินขีดจำกัดที่กำหนด ระบบจะส่งไปตรวจสอบส่วนต่างแทนกระบวนการอนุมัติจ่ายตามปกติ

ทดสอบกับงานจริง

ให้คนจากฝ่ายจัดซื้อหนึ่งคนและฝ่ายการเงินหนึ่งคนทดสอบเวอร์ชันแรกด้วยใบแจ้งหนี้ที่ทีมเคยจัดการแล้ว รวมใบแจ้งหนี้ที่ข้อมูลตรงกัน ใบที่มียอดผิด และใบที่ไม่มีใบสั่งซื้อที่ตรงกัน ตัวอย่างที่คุ้นเคยช่วยให้พบข้อมูลที่ขาดได้เร็ว

ระหว่างการทดสอบ ผู้ตรวจสอบควรตอบคำถามเหล่านี้ได้โดยไม่ต้องเปิดสเปรดชีตหรือส่งอีเมล:

• ใบสั่งซื้อใดรองรับใบแจ้งหนี้นี้
• ตอนนี้ใครต้องอนุมัติ
• ทำไมคิวจึงแจ้งส่วนต่าง
• ผู้ตรวจสอบแต่ละคนตัดสินใจอย่างไร
• ฝ่ายการเงินเห็นผลการตัดสินใจจ่ายเงินครั้งสุดท้ายหรือไม่

สร้างหน้าจอเว็บสำหรับเจ้าหน้าที่สำนักงานที่ทำงานอยู่ที่โต๊ะ และเพิ่มหน้าจอมือถือหากผู้จัดการมักอนุมัติใบแจ้งหนี้นอกโต๊ะทำงาน ผู้ตรวจสอบควรเห็นรายละเอียดใบแจ้งหนี้ ผลการจับคู่ ความเห็น ไฟล์แนบ และปุ่มตัดสินใจในหน้าจอเดียว ให้หน้าจอแรกเน้นข้อมูลสำคัญ เพราะฟิลด์เสริมจำนวนมากทำให้การอนุมัติทั่วไปช้าลง

อัปเดตคิวเมื่อทีมพบข้อมูลที่ขาด

มองรุ่นแรกเป็นฉบับที่พร้อมใช้งานและปรับปรุงได้ หากฝ่ายการเงินต้องถามหารหัสภาษีอยู่เสมอ ให้เพิ่มรหัสนั้นในระเบียนใบแจ้งหนี้ หากฝ่ายจัดซื้อต้องอธิบายการเปลี่ยนราคา ให้เพิ่มเหตุผลของส่วนต่างและฟิลด์ความเห็น หากใบแจ้งหนี้มูลค่าสูงต้องมีการอนุมัติครั้งที่สอง ให้ปรับกระบวนการกำหนดเส้นทาง แทนการให้เจ้าหน้าที่จำข้อยกเว้นเอง

AppMaster จะสร้างแอปใหม่เมื่อความต้องการเปลี่ยนแปลง ทีมจึงปรับโมเดลข้อมูล ตรรกะการอนุมัติ และหน้าจอได้โดยไม่ต้องสร้างแอปใหม่ด้วยตนเอง เมื่อกลุ่มทดสอบใช้งานได้คล่องแล้ว ให้ติดตั้งคิวบน AppMaster Cloud หรือโครงสร้างพื้นฐานของคุณเอง

คิวอนุมัติใบแจ้งหนี้ผู้ขายจะได้รับความไว้วางใจเมื่อทุกการตัดสินใจมีชื่อผู้ตรวจสอบ เวลา และเหตุผลที่ชัดเจน สร้างรากฐานนี้ก่อน แล้วค่อยเพิ่มประเภทใบแจ้งหนี้และเส้นทางอนุมัติเมื่อกระบวนการประจำวันเริ่มลงตัว