ระบบตรวจวงเงินเครดิตสำหรับคำสั่งซื้อ B2B และเงื่อนไขการชำระเงินต่อแต่ละลูกค้า

ปัญหาที่เกตวงเงินเครดิตแก้ให้ (อธิบายแบบเข้าใจง่าย)

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

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

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

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

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

กำหนดข้อมูลที่ต้องเก็บต่อแต่ละลูกค้า (วงเงิน เงื่อนไข การรับภาระ)

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

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

ต่อมา เก็บเงื่อนไขการชำระเป็นข้อมูลเชิงโครงสร้าง ไม่ใช่ข้อความอิสระ ใช้ประเภทที่ชัดเจน (Prepay, COD, Net 15, Net 30, Net 60) และเก็บจำนวนวันสุทธิเมื่อจำเป็น วิธีนี้ตรรกะคำสั่งจะสามารถแตกแขนงโดยไม่ต้องเดา

ชุดข้อมูลต่อหนึ่งลูกค้าที่ใช้งานได้จริงมักมี:

• จำนวนวงเงินเครดิตและสกุลเงิน
• ประเภทเงื่อนไขการชำระและจำนวนวันสุทธิ (ถ้ามี)
• จำนวนยกเว้นชั่วคราว (optional) พร้อม timestamp หมดอายุ
• หมายเหตุการยกเว้น (เหตุผลและผู้อนุมัติ)
• สวิตช์ถือแบบแมนนวล (ปุ่ม "หยุด")

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

สุดท้าย ให้เก็บชุดสถานะคำสั่งเล็กๆ เพื่อให้การถือมองเห็นและดำเนินการได้ เช่น: Approved, On hold, Released, Cancelled

โมเดลข้อมูลที่ต้องการสำหรับวงเงิน เงื่อนไข และการถือคำสั่ง

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

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

คำสั่งควรจับทั้งตัวทริกเกอร์และผลลัพธ์ เก็บวิธีชำระ ยอดรวมคำสั่ง และสถานะที่สามารถเป็น "On hold" ได้โดยไม่ทำให้ "Pending" มีความหมายเกินไป เพิ่มเหตุผลการถือเพื่อให้คนมองออกว่าติดเพราะ "เกินวงเงินเครดิต" หรือปัญหาอื่นๆ (เช่น การยืนยันที่อยู่)

สคีมาขั้นต่ำมักรวม:

• Customers: credit_limit, payment_terms_code, hold_policy, credit_status
• Orders: total_amount, payment_method, status, hold_reason, held_at
• Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
• Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
• Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

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

เก็บการยกเว้นไว้ในตารางแยกต่างหาก เพื่อป้องกันการแก้ไขเลอะเทอะในวงเงินหลักและให้เส้นทางการอนุมัติ

วิธีคำนวณการรับภาระเครดิตและวงเงินที่เหลือ

สูตรต้องตกลงและจดไว้ แล้วใช้สม่ำเสมอในแอปและรายงานการเงิน

แนวทางพื้นฐานทั่วไปคือ:

Credit exposure = unpaid invoices + open order value

แล้ว:

Available credit = credit limit - credit exposure

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

ปรับแต่งเล็กน้อยเพื่อป้องกันความประหลาดใจ:

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

จังหวะเวลาสำคัญพอๆ กับสูตร เลือกจุดอัพเดตที่ชัดเจนเพื่อให้ตัวเลขคาดเดาได้:

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

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

ทีละขั้นตอน: สร้างกฎแบ็กเอนด์เพื่อถือคำสั่ง

เกตทำงานได้ดีที่สุดเมื่อรันอัตโนมัติทุกครั้งที่สร้างหรือมีการเปลี่ยนแปลงคำสั่ง

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

2. ดึงการรับภาระปัจจุบันของลูกค้ามา (ตามคำนิยามของคุณ) คำนวณการรับภาระที่คาดว่าจะเกิดขึ้นโดยบวกยอดคำสั่งใหม่เข้าไป

3. นำตรรกะง่ายๆ มาใช้:

• ถ้าการรับภาระที่คาดว่าจะเกิดขึ้นอยู่ในวงเงิน ให้ตั้งสถานะคำสั่งเป็น Approved
• ถ้าการรับภาระที่คาดว่าจะเกิดขึ้นเกินวงเงิน ให้ตั้งสถานะเป็น On hold

4. เมื่อต้องถือคำสั่ง ให้บันทึกรายละเอียดที่อธิบายการตัดสินใจได้ง่ายในภายหลัง:

• เหตุผลการถือ (เช่น "เกินวงเงินเครดิต $2,450")
• ผู้รับผิดชอบการดำเนินการถัดไป (เช่น "ทีม AR" หรือผู้จัดการเฉพาะคน)
• บันทึกตรวจสอบพร้อมข้อมูลอินพุตที่ใช้ (วงเงินขณะนั้น องค์ประกอบการรับภาระ ผู้ที่เรียกตรวจ เวลา)

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

การอนุมัติและการแจ้งเตือนเพื่อไม่ให้คำสั่งที่ถูกถือค้างอยู่

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

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

ควรแสดงอะไรบนหน้าจออนุมัติ

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

• วงเงินเครดิต การรับภาระปัจจุบัน และวงเงินที่เหลือ
• ยอดคำสั่งและจำนวนที่เกินวงเงิน
• เงื่อนไขการชำระที่บันทึกไว้และเงื่อนไขที่ร้องขอ (ถ้าต่างกัน)
• หมุดสถานะลูกค้าสั้นๆ (เช่น "บัญชีใหม่" หรือ "ค้างชำระครั้งหนึ่ง")
• ฟิลด์คอมเมนต์ที่ต้องกรอก

หลังการตัดสินใจ ให้เขียนบันทึกการอนุมัติ (ID คำสั่ง การตัดสินใจ ผู้อนุมัติ เวลา ความเห็น) นี่คือเส้นทางตรวจสอบที่ช่วยอธิบายความล่าช้า

การแจ้งเตือนและกรอบเวลา

แจ้งคนที่เหมาะสมทันทีเมื่อคำสั่งถูกถือ โดยใช้ช่องทางที่ทีมอ่านจริงๆ (อีเมล SMS หรือ Telegram) เพิ่มการเตือนและการยกระดับเพื่อไม่ให้การถือเงียบ หนึ่งรูปแบบปฏิบัติได้จริงคือเตือนหลัง 2 ชั่วโมง ยกระดับหลัง 24 ชั่วโมง และยกเลิกอัตโนมัติหลัง 72 ชั่วโมงถ้าไม่มีใครตรวจ

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

กระบวนการปฏิบัติการ: เกิดอะไรขึ้นหลังคำสั่งถูกถือ

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

ฝ่ายขาย ปฏิบัติการ และการเงินควรเห็นสัญญาณการถือเดียวกัน ใช้สถานะเช่น "On credit hold" พร้อมฟิลด์เหตุผล (เช่น "การรับภาระเกินวงเงิน $1,240") เพิ่มหมายเหตุภายในสั้นๆ เพื่อไม่ให้คนต้องเดา

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

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

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

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

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

ตัวอย่างสถานการณ์: คำสั่งขายส่งที่เกินเกณฑ์

ลูกค้าขายส่ง BrightSide Supplies มีเงื่อนไข Net 30 และวงเงินเครดิต 50,000

ใบแจ้งหนี้ที่ยังไม่ชำระรวม 38,000 พวกเขาสั่งสินค้าใหม่มูลค่า 15,000

การรับภาระที่คาดว่าจะเกิดขึ้นคือ 38,000 + 15,000 = 53,000 เนื่องจาก 53,000 เกินวงเงิน 50,000 คำสั่งจึงถูกตั้งเป็น On hold และส่งให้การเงินตรวจสอบ ฝ่ายขายยังเห็นคำสั่งได้แต่ไม่สามารถแพ็ค ส่ง หรือออกใบแจ้งหนี้จนกว่าจะลดความเสี่ยงได้

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

เช็คลิสต์ก่อนเปิดใช้งาน

ก่อนเปิดเกตสู่ production ให้ทำการทดสอบสั้นๆ ไม่กี่ชั่วโมงก็ช่วยประหยัดเวลาทำความสะอาดเป็นวันได้

เริ่มด้วยชุดทดสอบเล็กและหลากหลาย (5–10 ลูกค้า): หนึ่งบัญชี Net 30 วงเงินต่ำ หนึ่งวงเงินสูง หนึ่งที่ชำระล่วงหน้า หนึ่งที่มีใบแจ้งหนี้เปิดหลายรายการ และหนึ่งที่มักแก้ไขคำสั่งหลังเช็คเอาต์

ยืนยันสองอย่าง:

• การคำนวณการรับภาระตรงกับที่ฝ่ายบัญชีคาดหวัง (รวมและไม่รวมสิ่งที่คุณนับให้ชัดเจน)
• กฎการถือทำงานในเวลาที่เหมาะสม: ตอนสร้างคำสั่งและเมื่อมีการแก้ไขที่เพิ่มภาระ (เช่น การเปลี่ยนจำนวน สินค้าเพิ่ม ค่าจัดส่งเพิ่ม เอาส่วนลดออก)

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

ข้อผิดพลาดทั่วไปและวิธีหลีกเลี่ยง

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

จุดบกพร่องทั่วไป:

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

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

ขั้นตอนถัดไป: นำเกตไปใช้งานในแอปคำสั่งของคุณและปรับปรุง

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

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

รักษารีลีสแรกให้ธรรมดาและคาดเดาได้ ปรับปรุงตามสิ่งที่ฝ่ายการเงินและปฏิบัติการพบจริงในแต่ละวัน.