การแมตช์สามทางแบบอัตโนมัติ: ตารางและเวิร์กโฟลว์สำหรับการถือจ่ายของ AP

ปัญหาที่การแมตช์สามทางแก้จริงๆ

การแมตช์สามทางแบบอัตโนมัติหมายถึงการจ่ายใบแจ้งหนี้เมื่อมันตรงกับสิ่งที่คุณสั่งและสิ่งที่คุณได้รับเเล้วเท่านั้น เอกสารทั้งสามคือ Purchase Order (PO), บันทึกการรับของ (receipt), และใบแจ้งหนี้จากผู้จำหน่าย

หากไม่มีการตรวจสอบนี้ ฝ่ายบัญชีเจ้าหนี้อาจจ่ายตามเอกสารฉบับเดียวที่ผิดหรือไม่สมบูรณ์ ผู้จำหน่ายอาจเรียกเก็บสินค้ามากกว่าจำนวนที่ส่ง ใช้ราคาต่างจากที่ตกลง หรือส่งใบแจ้งหนี้ซ้ำที่ดูเหมือนใหม่ในเธรดอีเมล

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

จุดประสงค์ไม่ใช่แค่อ “อนุมัติใบแจ้งหนี้” แต่เป็นการบล็อกการจ่ายจนกว่าฟิลด์สำคัญที่คุณเลือก (มักเป็นจำนวน, ราคาต่อหน่วย, และยอดรวม) จะตรงกันระหว่าง PO, receipt, และ invoice เมื่อไม่ตรง ใบแจ้งหนี้ไม่ควรหายไปในอีเมล แต่น่าจะลงไปในคิวข้อยกเว้นพร้อมรหัสเหตุผลที่ชัดเจนและฟิลด์ที่ต่างกันอย่างแม่นยำ

การแมตช์สามทางยังแบ่งหน้าที่ระหว่างทีมอย่างชัดเจน Procurement รับผิดชอบสิ่งที่สั่ง (ข้อตกลงและราคา) Receiving ยืนยันสิ่งที่มาถึง (จำนวนและวันที่) และ Finance ควบคุมสิ่งที่จะจ่าย (ตรวจสอบและปล่อยการจ่าย)

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

เอกสารและบทบาท: PO, receipt, invoice และใครรับผิดชอบอะไร

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

โมเดลความเป็นเจ้าของที่ใช้ได้จริงคือ:

• ผู้ขอ (Requester) สร้างคำขอซื้อและยืนยันความจำเป็น
• Procurement สร้างและดูแล PO (ผู้จำหน่าย ราคา ข้อตกลง)
• คลังสินค้าหรือผู้รับของ (หรือเจ้าของบริการ) บันทึกการรับของหรือการยอมรับ
• AP/Finance บันทึกใบแจ้งหนี้และควบคุมการจ่าย

แต่ละเอกสารยังต้องมีชุดฟิลด์ขั้นต่ำเพื่อให้การแมตช์ไม่ต้องเดา

PO (purchase order) ต้องมี supplier ID, หมายเลข PO, รายการบรรทัด (SKU หรือบริการ), จำนวนที่สั่ง, ราคาต่อหน่วย, สกุลเงิน, กฎภาษี และเงื่อนไขการชำระเงิน

Receipt ต้องมีการอ้างอิง PO, วันที่รับ, จำนวนที่รับแยกตามบรรทัด PO, และผู้รับ สำหรับบริการ ให้ถือเป็นการยอมรับและบันทึกผู้อนุมัติ

Invoice ต้องมีหมายเลขใบแจ้งหนี้ผู้จำหน่าย, วันที่ใบแจ้งหนี้, อ้างอิง PO (หรือวิธีที่ปลอดภัยในการหา PO), รายละเอียดบรรทัด (จำนวน ราคาต่อหน่วย), ภาษี/ค่าจัดส่ง และยอดรวม

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

1. เมื่อใบแจ้งหนี้ถูก capture (เพื่อให้ตัดสินใจจ่ายหรือถือทันที)
2. เมื่อมีการโพสต์ receipt (เพื่อให้ใบแจ้งหนี้ที่ถูกถือสามารถเป็นจ่ายได้)
3. เมื่อ PO ถูกเปลี่ยนแปลง (เพื่อให้ใบแจ้งหนี้ที่เปิดถูกเช็กใหม่)

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

กฎที่ควรตัดสินใจก่อนเริ่มสร้างอะไร

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

เลือกระดับการแมตช์ การแมตช์เฉพาะ header ตรวจสอบยอดรวมระดับเอกสาร ฟังดูง่ายแต่พังเร็วเมื่อมีการรับเป็นส่วน, สินค้าคงคลังรอส่ง, บรรทัดค่าขนส่ง หรืออัตราภาษีผสม การแมตช์ระดับบรรทัดใช้เวลานานขึ้นในการตั้งค่าแต่ปลอดภัยกว่าเพราะคุณเปรียบเทียบสิ่งเดียวกันข้าม PO, receipt, และ invoice: บรรทัดเฉพาะ จำนวน และราคาต่อหน่วย

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

จุดเริ่มต้นที่พบบ่อย:

• บล็อกแข็ง: จำนวนที่เรียกเก็บเกินกว่าจำนวนที่รับ (สำหรับสินค้า)
• บล็อกแข็ง: ราคาต่อหน่วยเกินราคา PO เกินค่าความทนได้
• คำเตือน: ความแตกต่างเล็กน้อยจากการปัดเศษ
• คำเตือน: ความแตกต่างเรื่องภาษีหรือค่าจัดส่งที่คาดไว้และมีการแยกโค้ด

เก็บกฎความทนไว้อย่างชัดเจน กำหนดวิธี (เปอร์เซ็นต์ จำนวนเงิน หรือค่าสูงสุดของทั้งสอง) และใครเป็นเจ้าของ ตัวอย่าง: อนุญาต +/- 1% หรือ +/- $5 ต่อบรรทัด โดย Finance เปลี่ยนความทนได้เฉพาะพร้อมบันทึกตรวจสอบ

ใช้ชุดสถานะเล็กๆ ที่ใช้ร่วมกัน หลีกเลี่ยงสถานะกำหนดเองต่อทีม ชุดที่สะอาดมักพอ: Matched, Hold, Exception, Approved “Hold” หมายถึงการชำระถูกบล็อก “Exception” หมายถึงต้องมีคนตรวจสอบ “Approved” หมายถึงบุคคลที่ระบุยอมรับความไม่ตรงและบันทึกเหตุผล

โมเดลข้อมูล: ตารางที่คุณต้องการ (และเหตุผล)

การแมตช์สามทางทำงานได้ก็ต่อเมื่อโมเดลข้อมูลของคุณสามารถจับคู่บรรทัด PO สิ่งที่รับ และสิ่งที่ถูกเรียกเก็บ ทุกบรรทัดของใบแจ้งหนี้ควรจับคู่กับบรรทัด PO เฉพาะ (หรือถูกทำเครื่องหมายชัดเจนว่าไม่ใช่ PO) และทุกบรรทัด receipt ควรลดจำนวนคงเหลือในบรรทัด PO นั้น

เริ่มด้วยตารางซื้อหลัก:

• Vendors: แถวเดียวต่อผู้จำหน่าย (ชื่อ เงื่อนไข ข้อมูลภาษี)
• ItemsServices: ทางเลือก แต่ช่วยความสอดคล้อง (SKU คำอธิบาย หน่วย)
• PurchaseOrders: เฮดเดอร์ PO (vendor_id, currency, requested_by, status)
• PO_Lines: สมอการแมตช์ (po_id, item_id/description, ordered_qty, unit_price)

Receiving ต้องมีเรคอร์ดของตัวเอง แม้ว่า "receipt" จะเป็นแค่การยืนยัน ก็ให้แยกจากใบแจ้งหนี้เพื่อพิสูจน์สิ่งที่มาถึงและเวลา:

• Receipts: เฮดเดอร์ receipt (vendor_id, received_date, location, status)
• Receipt_Lines: แต่ละบรรทัดอ้างอิงบรรทัด PO (receipt_id, po_line_id, received_qty, notes)

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

• Invoices: เฮดเดอร์ invoice (vendor_id, invoice_number, invoice_date, due_date, status)
• Invoice_Lines: (invoice_id, po_line_id เมื่อใช้ได้, invoiced_qty, unit_price, tax, line_total)

สุดท้าย สร้างเรคอร์ดที่ใช้สำหรับการชำระที่เวิร์กโฟลว์ของคุณสามารถบล็อก บางทีมเรียกว่า bill หรือ payment request:

• PaymentRequests (หรือ Bills): ผูกกับ invoice_id และรวม payment_hold (true/false) พร้อม hold_reason

เพื่อการตรวจสอบและการจัดการข้อยกเว้นที่ดี ให้เพิ่มฟิลด์วงจรชีวิตที่สอดคล้องกันบนเฮดเดอร์ (POs, receipts, invoices, payments): status, created_at/created_by, approved_at/approved_by, posted_at และ (ทางเลือก) source_document_id สำหรับการนำเข้า

ฟิลด์สำคัญและความสัมพันธ์ที่ทำให้การแมตช์เชื่อถือได้

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

ให้แต่ละตารางมีทั้ง ID ภายในที่เสถียรและหมายเลขภายนอกที่คนมักค้นหา:

• PO header: po_id, po_number, vendor_id, currency, status, po_date
• PO lines: po_line_id, po_id, item_id หรือ description, ordered_qty, unit_price, tax_rate, line_total
• Receipts: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Invoices: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors และ items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

ลิงก์ที่สำคัญที่สุดคือระดับบรรทัด:

• invoice_line.po_line_id ควรชี้ไปที่ PO line
• receipt_line.po_line_id ควรชี้ไปยัง PO line เดียวกัน

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

เพื่อรองรับการรับเป็นส่วน ให้คำนวณยอดสะสมต่อบรรทัด PO: received_qty (ผลรวมของ receipt lines) และ invoiced_qty (ผลรวมของ invoice lines) แล้วคำนวณ remaining_qty = ordered_qty - received_qty และ open_to_invoice_qty = received_qty - invoiced_qty ค่าพวกนี้จะบอกชัดว่าใบแจ้งหนี้นั้นมาถูกเวลา เกิน หรือเรียกเก็บมากเกิน

อย่าเขียนทับประวัติเมื่อ PO เปลี่ยน แทนที่จะลบให้เก็บหมายเลข revision ของ PO และรักษาบรรทัด PO เก่าไว้ (พร้อม active flag) หรือลงบันทึกการเปลี่ยนแปลง (who changed what, when, old value, new value)

เพิ่มเกราะพื้นฐานเพื่อป้องกันการซ้ำและการเชื่อมผิด:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number และ po_number
• Not null บนสกุลเงิน จำนวน และ unit_price
• Check constraints เช่น qty >= 0 และ unit_price >= 0
• Foreign keys จาก invoice_line และ receipt_line ไปยัง po_line

ขั้นตอนเป็นขั้นตอน: ตั้งแต่รับใบแจ้งหนี้จนถึงการถือจ่าย

การแมตช์สามทางมักมีจุดเข้าใช้งานสามแบบ: ใบแจ้งหนี้มาถึง (อีเมล อัปโหลด EDI), receipt ถูกโพสต์, หรือ PO ถูกเปลี่ยนเวอร์ชัน เวิร์กโฟลว์ควรตอบสนองต่อทุกเหตุการณ์เหล่านี้เพื่อให้ใบแจ้งหนี้สามารถออกจากการถือเมื่อชิ้นที่ขาดมาถึง

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

2) แมตช์เป็นระดับบรรทัด ไม่ใช่แค่หัวเอกสาร สำหรับแต่ละบรรทัดของใบแจ้งหนี้ ให้หา PO line ที่เกี่ยวข้องและยอดรับสะสมจนถึงปัจจุบัน แล้วเปรียบเทียบ:

• จำนวนที่เรียกเก็บเทียบกับจำนวนที่รับ (หรือรับลบกับที่เคยเรียกแล้ว)
• ราคาต่อหน่วยที่เรียกเก็บเทียบกับราคาใน PO
• กฎความทน
• ว่าบรรทัด PO นั้นยังเปิดให้เรียกเก็บหรือไม่

3) ตั้งสถานะและบังคับการบล็อก รูปแบบที่พบได้บ่อย:

• Matched: ทุกบรรทัดผ่านการตรวจ ไม่มีข้อยกเว้นเปิด
• Hold: อย่างน้อยหนึ่งบรรทัดล้มเหลว หรือข้อมูลจำเป็นขาด

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

4) บันทึกรหัสเหตุผลที่ Finance วางใจได้ หลีกเลี่ยงการเก็บเหตุผลเป็นข้อความเสรีอย่างเดียว ใช้โค้ดแบบ PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH, หรือ CURRENCY_MISMATCH พร้อมบันทึกสั้นๆ

การออกแบบคิวข้อยกเว้นสำหรับฝ่ายการเงิน (เก็บอะไรและแสดงอะไร)

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

แนวทางทั่วไปคือมีตารางเฉพาะเช่น ExceptionCases แต่ละแถวเป็นใบแจ้งหนี้ที่ถูกบล็อก (หรือบรรทัดใบแจ้งหนี้) และชี้กลับไปยัง invoice, PO, และ receipt เก็บให้ matching engine เป็นแบบอ่านอย่างเดียว คิวคือที่สำหรับการตัดสินใจและเอกสารประกอบ

ควรเก็บอะไรใน ExceptionCases

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

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) และเหตุผลที่อ่านง่าย
• Owner (บุคคลหรือทีม) และสถานะ (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• สแนปช็อตความต่างเป็นตัวเลขที่เรียงได้ (invoice amount, matched amount, price delta, quantity delta)
• ฟิลด์ SLA (due date, escalation flag, reassigned_at, reassignment_reason)

เก็บข้อมูลการร่วมมือและการตรวจสอบด้วย: ความคิดเห็น (author, timestamp) และเมตาดาต้าไฟล์แนบ (file name, type, uploaded_by, uploaded_at) แม้ไฟล์จะเก็บที่อื่น เมตาดาต้าควรอยู่ในเคสเพื่อให้ประวัติครบ

Finance ควรเห็นและทำอะไร

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

เมื่อเปิดเคส ควรเห็นสรุปแบบเปรียบเทียบข้างกัน: บรรทัด PO, ยอดรับ, บรรทัดใบแจ้งหนี้, และฟิลด์ที่ล้มเหลวอย่างชัดเจน

จำกัดการกระทำให้อยู่ปลอดภัย:

• Request receipt (ส่งไปยัง receiving และตั้งสถานะเป็น waiting)
• Request credit memo (ส่งไปยังผู้จำหน่าย และบันทึกการปรับคาดว่าจะมาถึง)
• Approve override (ต้องมีเหตุผล บันทึกผู้อนุมัติและเวลา)
• Reassign (อัปเดตเจ้าของ พร้อมเก็บประวัติการมอบหมาย)
• Close as resolved (ทำได้เฉพาะหลังการเปลี่ยนแปลงทำให้การแมตช์ผ่าน)

ตัวอย่าง: ใบแจ้งหนี้ถูกบล็อกเพราะรับ 8 หน่วยแต่เรียกเก็บ 10 หน่วย Finance สามารถขอใบรับเพิ่มเติมจาก receiver หรืออนุมัติ override สำหรับ 8 หน่วยที่รับแล้วและถือส่วนที่เหลือ 2 หน่วยไว้

ตัวอย่างสมจริง: รับเป็นส่วนและใบแจ้งหนี้ไม่ตรง

ผู้ซื้อสร้าง PO สำหรับ 100 หน่วยของสินค้า A ที่ $10.00 ต่อหน่วย ยอด PO $1,000 สองวันต่อมา คลังโพสต์ receipt สำหรับ 80 หน่วย

จากนั้นใบแจ้งหนี้มาถึงสำหรับ 100 หน่วยที่ $10.00 ต่อหน่วย การแมตช์ควรเปรียบเทียบบรรทัดใบแจ้งหนี้กับสิ่งที่รับแล้ว ไม่ใช่แค่สิ่งที่สั่ง

บนบรรทัดนั้น:

• สั่ง: 100 หน่วย
• รับ: 80 หน่วย
• เรียกเก็บ: 100 หน่วย
• จำนวนที่แมตช์: min(Received, Invoiced) = 80 หน่วย
• จำนวนที่ไม่แมตช์: Invoiced - Matched = 20 หน่วย

ใบแจ้งหนี้จะเป็น "On hold" เพราะมี 20 หน่วยที่ไม่มีใบรับ Finance จะเห็นเคสพร้อมเหตุผลชัดเจน (Quantity variance: +20) และตัวเลขสำคัญข้างกัน

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

เมื่ออีก 20 หน่วยมาถึง คลังโพสต์ receipt ที่สอง ระบบจะรันการแมตช์ซ้ำ: received เป็น 100, unmatched เป็น 0, ใบแจ้งหนี้กลายเป็น Matched และการถือจะถูกปล่อย

เพิ่มความต่างของราคา: หากผู้จำหน่ายออกใบแจ้งหนี้ 100 หน่วยที่ $10.50 แทน $10.00 ปริมาณแมตช์แต่ราคาไม่ตรง ผลลัพธ์ที่คาดไว้คือให้ใบแจ้งหนี้ยังคงถูกถือและส่งต่อพร้อมเหตุผลเช่น "Price variance: +$0.50/unit (+$50 total)"

ความผิดพลาดทั่วไปที่ทำให้เวิร์กโฟลว์แมตช์สามทางพัง

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

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

สมมติว่ามีแค่ receipt เดียวและ invoice เดียวต่อ PO การจัดซื้อจริงมีการส่งแยกและเรียกเก็บเป็นส่วน รองรับหลาย receipt และหลาย invoice ต่อบรรทัด PO และติดตามจำนวนคงเหลือต่อบรรทัด

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

ขาดการป้องกันรายการซ้ำ หมายเลขใบแจ้งหนี้ของผู้จำหน่ายอาจถูกกรอกสองครั้ง หรือ PDF ถูกอัปโหลดซ้ำโดยคนละคน เพิ่มความเป็นเอกลักษณ์ตั้งแต่ต้น (vendor + invoice number และทางเลือก date/amount) และแสดงข้อความชัดเมื่อเจอซ้ำ

เหตุผลข้อยกเว้นไม่ชัดเจน Finance ไม่ควรเดา ใช้รหัสเหตุผลที่ชัดเจนเพื่อการส่งต่อ: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch

เช็คลิสต์ด่วนก่อนเปิดการบล็อกการชำระ

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

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

เช็คลิสต์:

• ความสมบูรณ์การอ้างอิง: ทุกใบแจ้งหนี้มีผู้จำหน่ายและอ้างอิง PO และแต่ละบรรทัดของใบแจ้งหนี้สามารถแมปไปยังบรรทัด PO เฉพาะ (ไม่ใช่แค่ "ยอดรวม PO") ตัดสินใจว่าจะทำอย่างไรถ้าผู้จำหน่ายส่งแค่หมายเลขหัว PO
• คณิตศาสตร์สอดคล้อง: จำนวน ราคาต่อหน่วย และยอดรวมคำนวณเหมือนกันเสมอ ระบุเรื่องภาษี ค่าจัดส่ง ส่วนลด และการปัดเศษ (เช่น ปัดต่อบรรทัดหรือปัดที่ยอดรวม)
• สถานะบล็อกเร็วพอ: ตั้ง "on hold" ก่อนที่จะสร้าง payment request หรือเรคอร์ดการจ่ายใดๆ
• ข้อยกเว้นมีโครงสร้าง: ทุกการถือเก็บรหัสเหตุผลและเจ้าของ (AP, buyer, receiver) ใส่วันครบกำหนดเพื่อการตามงาน
• ร่องรอยตรวจสอบจริง: การอนุมัติยกเว้นบันทึกว่าใครอนุมัติ เมื่อไหร่ และอนุมัติอะไร (รวมค่าสถานะเดิม) หากอนุญาตการแก้ไข ให้บันทึกค่าก่อนและหลัง

ขั้นตอนต่อไป: ทดลองในวงเล็กและสร้างแบบภาพ

ปฏิบัติต่อการแมตช์สามทางเหมือนการควบคุมอื่นๆ: พิสูจน์ในกลุ่มเล็กก่อน แล้วค่อยขยาย

เริ่มด้วยพิลอตที่ติดตามง่าย เลือกหน่วยธุรกิจหนึ่ง กลุ่มผู้จำหน่ายเล็กๆ ที่ส่งใบแจ้งหนี้สะอาด หรือหมวดสินค้าหนึ่ง กำหนดกฎเข้มงวดตอนแรก (จำนวนและราคาตรงเป๊ะ) เพื่อให้ปัญหาคุณภาพข้อมูลปรากฏเร็ว

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

ถ้าต้องการต้นแบบเร็ว แพลตฟอร์มแบบไม่ต้องเขียนโค้ดช่วยได้เพราะคุณสามารถสร้างตาราง กฎการแมตช์ และการส่งต่อแบบภาพโดยไม่เขียนโปรแกรม ตัวอย่างเช่น ใน AppMaster (appmaster.io) คุณสามารถสร้างตาราง PO, receipt, invoice และ exception แล้วเชื่อมตรรกะการถือในกระบวนการแบบภาพเพื่อให้กฎเดียวกันทำงานทุกทริกเกอร์

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