02-347-7730  |  Saeree ERP - ระบบ ERP ครบวงจรสำหรับธุรกิจไทย ติดต่อเรา

47% ของบริษัทเจอ Invoice Fraud

Invoice Fraud 47% ของบริษัทเจอในปี 2569 — วิธีป้องกัน AP Automation
  • 19
  • สิงหาคม

Invoice Fraud (การปลอม / ทุจริตใบแจ้งหนี้) คือการที่มิจฉาชีพแอบอ้างเป็นคู่ค้า ส่ง invoice ปลอมหรือเปลี่ยนเลขบัญชีปลายทาง เพื่อหลอกให้ฝ่าย AP จ่ายเงินผิดที่ รายงาน AP Automation Trends 2026 ระบุว่า 47% ของบริษัททั่วโลกเจอ fake invoice scam ในรอบปีที่ผ่านมา ขณะที่ AFP 2025 Payments Fraud Survey ระบุ 79% ขององค์กรเจอ payment fraud (พยายามหรือสำเร็จ) — บทความนี้สรุปวิธีโจมตี 3 แบบหลัก, วิธีป้องกัน 5 ระดับ, และ role ของ ระบบ AP กับ approval workflow ในการตัดวงจร fraud

สรุปง่ายๆ: Invoice fraud เป็นความเสี่ยงอันดับต้นๆ ของฝ่ายบัญชีปี 2569 — มีทั้งแบบ "ส่ง invoice ปลอม", "เปลี่ยนเลขบัญชี vendor (BEC)", และ "duplicate payment" — วิธีป้องกันที่ได้ผลคือใช้ระบบ ERP ที่บังคับ 3-way match (PO + GR + Invoice), มี approval workflow แยกอำนาจ, ตรวจสอบ vendor master เปลี่ยนเลขบัญชีโดย dual approval, และเก็บ audit trail ทุก transaction — งบลงทุนระบบมักคืนทุนภายในปีเดียวเมื่อเทียบกับ fraud loss

ตัวเลขที่ทำให้ CFO นอนไม่หลับปี 2569

ก่อนจะพูดถึงวิธีป้องกัน ต้องเข้าใจก่อนว่าปัญหา invoice fraud ในปี 2569 ใหญ่แค่ไหน:

ตัวเลข หมายความว่า แหล่ง
47% ของบริษัทเจอ fake invoice scam ในปีที่ผ่านมา Quadient AP Trends 2026
79% ขององค์กรเจอ payment fraud (พยายาม / สำเร็จ) AFP Payments Fraud Survey 2025
66% ของฝ่าย AP ยังจัดการ supplier invoice ด้วยมือเป็นหลัก Quadient AP Trends 2026
77% ของฝ่าย AP เริ่มมี automation บางส่วนแล้ว — แต่ไม่ครบ Quadient AP Trends 2026
~9% เท่านั้นที่ทำ "Touchless AP" ได้จริง — ไม่ต้องแตะใบใดเลย Industry survey 2026

ตัวเลขที่น่าตกใจคือ ช่องว่างระหว่าง "บริษัทมี automation บ้าง" (77%) กับ "ใช้ automation เต็มที่" (9%) — ส่วนใหญ่อยู่ในสถานะ "ติดตั้งแล้วแต่ใช้ไม่ครบ" ซึ่งเป็นจุดที่ fraud มักลอดผ่าน เพราะคนยังต้องตัดสินใจหลายขั้นและพึ่ง email เป็นช่องทางหลัก

3 รูปแบบการโจมตีที่พบบ่อยที่สุดในปี 2569

วิธีที่ fraudster ใช้หลอก AP ทีม มีหลายแบบ แต่ 3 รูปแบบนี้คิดเป็นมากกว่า 80% ของ case ที่รายงาน

รูปแบบที่ 1 — Fake Invoice (Vendor Impersonation)

คนร้ายแอบอ้างเป็น vendor ที่บริษัทเคยซื้อของ ส่ง invoice ปลอมพร้อมโลโก้ ลายเซ็น และเลขที่ใบกำกับภาษีที่ดูสมจริง โดยเฉพาะตอน:

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

เคสจริงที่พบ: ใบกำกับภาษีปลอมที่หน้าตาเหมือนใบจริงทุกประการ แต่เลขบัญชีปลายทางต่างกัน — บางครั้งใช้ เลขที่ใบกำกับซ้ำ กับใบจริง ทำให้ตรวจสอบยาก (ดูเพิ่ม ระบบ e-Tax Invoice และวิธีตรวจสอบ)

รูปแบบที่ 2 — Business Email Compromise (BEC) / Bank Account Change Fraud

เป็นรูปแบบที่ เติบโตเร็วที่สุด ในปี 2569 — fraudster ไม่ส่ง invoice ปลอม แต่แทรกเข้ามาในการสื่อสารกับ vendor จริง แล้วส่ง email "ขอเปลี่ยนเลขบัญชี" ก่อนวันจ่าย:

  1. Hack หรือ spoof email ของ vendor (ใช้ domain ใกล้เคียง เช่น vendor.co.thvend0r.co.th)
  2. ส่งจดหมาย "วันนี้บัญชีใหม่จะ active แล้วครับ ขอให้โอนเข้าเลขใหม่ตามแนบ"
  3. แนบ "หนังสือเปลี่ยนแปลงข้อมูลผู้รับเงิน" ปลอม
  4. AP จ่ายตามใบ invoice เดิมแต่เปลี่ยนปลายทาง — เงินไปเข้าบัญชี fraudster

ลักษณะอันตราย: Invoice ของจริง — สินค้า / บริการของจริง — vendor ของจริง — เปลี่ยนแค่เลขบัญชี ทำให้ 3-way match ผ่านหมด ถ้าระบบไม่ตรวจสอบ vendor master change เป็นพิเศษ จะหา fraud ไม่เจอจนกว่า vendor จะ follow up ว่า "ทำไมเงินยังไม่เข้า"

รูปแบบที่ 3 — Internal Fraud (Duplicate Payment / Ghost Vendor)

เป็น fraud ภายใน — พนักงานเอง (มักเป็น AP หรือ procurement) เป็นคนทำ:

  • Ghost Vendor — สร้าง vendor master ปลอมที่เลขบัญชีของตัวเองหรือคนใกล้ตัว แล้วสร้าง PO + invoice ภายใต้ vendor นี้
  • Duplicate Payment — จงใจจ่าย invoice ซ้ำ 2 ครั้งโดยใช้เลขที่ใบกำกับต่างกันเล็กน้อย (เช่น I001 กับ I001A) แล้วเก็บส่วนต่าง
  • Inflated Invoice — สมรู้ร่วมคิดกับ vendor จริง ออก invoice เกินจริงแล้วแบ่งส่วนต่าง — ตรวจเจอยากถ้าไม่มี contract pricing

Fraud ประเภทนี้ลึกที่สุด เพราะคนทำมี access จริงในระบบ — ป้องกันด้วย segregation of duties + audit trail + periodic review

5 ระดับการป้องกัน Invoice Fraud (Defense in Depth)

วิธีป้องกันที่ได้ผลคือ วาง defense หลายชั้น ไม่ใช่ชั้นเดียว เพราะ fraudster อาจหา loophole ของแต่ละชั้นได้ — ระบบที่ดีต้องมีอย่างน้อย 5 ชั้น

ระดับ มาตรการ บล็อก fraud แบบ
1. Vendor Master Dual approval สำหรับเพิ่ม / แก้ vendor + verification call Ghost vendor + BEC
2. PO Required ทุก invoice ต้องอ้างอิง PO ที่อนุมัติแล้ว — ไม่มี "non-PO invoice" Fake invoice
3. 3-Way Match PO + Goods Receipt + Invoice ต้องตรงกันทุกบรรทัด Inflated invoice + duplicate
4. Approval Workflow แยกอำนาจตามวงเงิน + ห้ามคนเดิมอนุมัติทั้ง vendor และจ่ายเงิน Internal fraud
5. Audit Trail เก็บ log ทุก action — ใครเปลี่ยนอะไร เมื่อไหร่ จาก IP ไหน ทุกประเภท (ใช้ตรวจสอบย้อนหลัง)

ระดับ 1 — Vendor Master Control

เป็นชั้นที่สำคัญที่สุดเพราะ เกือบทุก fraud เริ่มจาก vendor master — ถ้าคุมตรงนี้ได้ ลด attack surface ไปเกือบครึ่ง:

  • Dual approval — คนสร้าง / แก้ vendor และคนอนุมัติต้องเป็นคนละคน
  • Verification call — สำหรับ vendor ใหม่ ต้องโทรไปยืนยันที่เบอร์ใน master data เก่า (ไม่ใช่เบอร์ที่ระบุใน email ขอเปลี่ยน)
  • Bank account history — เก็บประวัติเลขบัญชีทุกครั้งที่เปลี่ยน + ใครเปลี่ยน + เมื่อไหร่
  • Cooling period — vendor ที่เพิ่งเพิ่มต้องรอ 24-48 ชม. ก่อนใช้ได้

ระดับ 2 — PO-Based Procurement

กฎง่ายๆ คือ "ไม่มี PO ไม่มีจ่าย" — ทุก invoice ต้องอ้างอิง Purchase Order ในระบบจัดซื้อ ที่อนุมัติแล้วก่อน — fake invoice จะ block ทันทีเพราะไม่มี PO ตรงกัน

ระดับ 3 — 3-Way Match

การจับคู่ PO ↔ Goods Receipt ↔ Invoice — ต้องตรงกัน ทั้ง 3 ใบในระดับบรรทัด ไม่ใช่แค่ยอดรวม:

  • รหัสสินค้า / บริการตรงกัน
  • จำนวนตรงกัน (หรืออยู่ใน tolerance ที่กำหนด)
  • ราคาต่อหน่วยตรงกับ contract / PO
  • ยอด tax / discount คำนวณถูกต้อง

หากผิดทั้ง 4 ข้อ ระบบต้อง block อัตโนมัติ ไม่ใช่แค่เตือน — เพราะ "เตือน" จะถูก click "ไม่สนใจ" เมื่อเร่ง

ระดับ 4 — Approval Workflow ตามวงเงิน

กำหนดอำนาจอนุมัติเป็นชั้น เช่น:

วงเงิน ผู้อนุมัติ เงื่อนไขเพิ่ม
< 50,000 บาท หัวหน้าฝ่าย PO + Invoice
50,000 - 500,000 ผู้จัดการ + ฝ่ายบัญชี 3-way match
500,000 - 5,000,000 CFO + ผู้บริหารระดับสูง Contract / quotation
> 5,000,000 กรรมการบริหาร 2 ราย มติบอร์ด

ระดับ 5 — Audit Trail และ Periodic Review

เก็บ log ทุก action ใน 12 เดือนย้อนหลังเป็นอย่างน้อย + กำหนดให้ internal audit สุ่มตรวจรายเดือน:

  • การเปลี่ยน vendor master (ใคร / เมื่อไหร่ / IP / ค่าเก่า / ค่าใหม่)
  • การ override 3-way match (มีกี่ครั้ง / โดยใคร / เหตุผล)
  • Invoice ที่จ่ายในวันหยุดหรือนอกเวลาทำการ
  • การจ่ายเข้าเลขบัญชีที่เพิ่งเปลี่ยน

Role ของ AP Automation ในการตัดวงจร Fraud

AP automation ไม่ใช่แค่เรื่อง ความเร็ว แต่เป็นเรื่อง ความสม่ำเสมอของการตรวจสอบ — มนุษย์เหนื่อยจะ skip step, ระบบไม่เหนื่อย:

งาน Manual Automation
ตรวจ PO ↔ Invoice สุ่มตรวจ — มีโอกาสพลาด ตรวจ 100% ทุกใบ
ตรวจ duplicate ตรวจจากความจำ — มักพลาด SQL query ค้นทุก hash / เลขที่
เปลี่ยน vendor data บันทึกใน Excel / ไม่บันทึก Audit log อัตโนมัติทุก field
Approval routing Email / กระดาษ — track ยาก Workflow + timestamp ทุก step
Anomaly detection ไม่มี — ต้องตา human Rule + ML alert (เช่น invoice ใหญ่กว่าค่าเฉลี่ย vendor 3x)

AI / Agentic AP — Layer ใหม่ปี 2569

เทรนด์ AP ปี 2569 เริ่มมี Agentic AI เข้ามาช่วย exception handling โดย:

  • OCR + LLM อ่าน invoice — ดึงข้อมูลจาก invoice PDF / รูป โดยไม่ต้อง key มือ
  • Pattern matching — เทียบ vendor name fuzzy เพื่อจับ vendor ปลอมที่ชื่อใกล้กับของจริง
  • Anomaly detection — flag invoice ที่ผิดปกติ (ราคาเกินค่าเฉลี่ย, สั่งซื้อนอกเวลาทำการ ฯลฯ)
  • Auto-routing exception — ส่งต่อให้คนที่เกี่ยวข้องอัตโนมัติ พร้อมเหตุผลว่าทำไม flag

แต่ AI ไม่ทดแทน control พื้นฐาน — มันเป็นเลเยอร์ที่ เพิ่ม เข้ามา ไม่ใช่ใช้แทน 3-way match หรือ approval workflow

การประเมินความเสี่ยงในบริษัทคุณ — Checklist 10 ข้อ

ลองตอบ 10 คำถามนี้ — ถ้า "ใช่" ต่ำกว่า 7 ข้อ แสดงว่ามี exposure ต่อ fraud สูง:

คำถาม เกี่ยวกับ
1. การเปลี่ยน vendor bank account ต้อง dual approval ทุกครั้งหรือไม่?BEC
2. ทุก invoice ต้องมี PO อ้างอิงเสมอ ไม่มียกเว้น "non-PO"?Fake invoice
3. มีการ match 3 ใบ (PO+GR+Invoice) ในระดับ บรรทัด ไม่ใช่ระดับยอด?Inflated invoice
4. คนสร้าง vendor และคนอนุมัติจ่ายเงินคือคนละคน?Ghost vendor
5. มี audit log ที่ตามได้ว่าใครเปลี่ยน data อะไรเมื่อไหร่?ทุกประเภท
6. มี report duplicate invoice รายเดือนหรือไม่?Duplicate payment
7. มีนโยบาย verification call สำหรับ vendor ใหม่ (ใช้เบอร์เก่า)?BEC
8. มี cooling period 24-48 ชม. ก่อน vendor ใหม่ใช้ได้?Ghost vendor
9. การ override 3-way match ต้องมีเหตุผล + ผู้อนุมัติเฉพาะ?Internal fraud
10. มี internal audit สุ่มตรวจ AP transaction ทุกเดือน?ทุกประเภท

ทำไมเรื่องนี้สำคัญกับองค์กรที่ใช้ Saeree ERP

โมดูล AP ของ Saeree ERP ออกแบบโดยมี control เหล่านี้เป็น default ไม่ใช่ option ที่ต้องเปิด — เพราะการป้องกัน fraud ต้องเริ่มจาก setup ที่ "ทำตามถูกอยู่แล้ว" ไม่ใช่ "ต้องไปกดเปิด":

  • Vendor Master Control — admin สามารถ เพิ่ม / inactive / กำหนด valid from-to ของ vendor ได้เอง โดยไม่ต้อง patch — และระบบบังคับ dual approval สำหรับการเปลี่ยน bank account
  • 3-Way Match บังคับเป็น default — invoice ที่ไม่ match กับ PO + GR จะถูก block ไม่ผ่านไปยังขั้นจ่าย — การ override ต้องมีเหตุผลและผู้อนุมัติ
  • Approval Workflow ปรับได้ — admin กำหนดได้เองว่าวงเงินเท่าไหร่ ใครอนุมัติ ผ่านกี่ขั้น — ไม่ต้องเขียนโค้ดหรือรอ vendor patch
  • Audit Trail ครบทุก field — ทุก action ถูกบันทึก IP + user + timestamp — internal audit ใช้ในการ รีวิวประจำเดือนได้ทันที
  • Duplicate Detection — ระบบเทียบ invoice number + vendor + amount + date — เตือนทันทีถ้ามี invoice คล้ายกัน
  • Approval แยกอำนาจ Vendor ↔ Payment — คนเพิ่ม vendor และคนอนุมัติจ่ายเงินต้องเป็นคนละ role โดย design — ปิดช่องทาง ghost vendor ตั้งแต่ระดับ schema

การลงทุนระบบป้องกัน fraud มักคืนทุนเร็ว — สมมติบริษัทขนาดกลางที่มี payable ปีละ 200 ล้านบาท — fraud loss แค่ 0.1% ก็คือ 200,000 บาท ในรอบปี เทียบกับค่าระบบมักต่ำกว่าและได้ benefit อื่นด้วย

หมายเหตุ: ตัวเลข fraud loss จริงในแต่ละบริษัทแตกต่างกันมาก — ขึ้นกับ volume, ประเภทอุตสาหกรรม และ control ที่มีอยู่แล้ว — ตัวเลข 0.1% เป็นเพียงตัวอย่างสำหรับคำนวณ ไม่ใช่ benchmark ของ Saeree ERP — แต่ที่แน่นอนคือ fraud loss แม้แค่ครั้งเดียวก็มักเกินค่าระบบ ERP ทั้งโครงการ

Fraud ที่ขโมย 200,000 บาทครั้งเดียว ใช้เวลานานกว่าระบบที่ทำงานทุกวันเป็นเดือนถึงจะหาเจอ — แต่ถ้ามี control ตั้งแต่ต้นทาง fraud นั้นจะถูกบล็อกในวันแรก โดยไม่ต้องอาศัยใครจะ "สังเกตเห็น" ในภายหลัง

- ทีมงาน Saeree ERP

สรุป — สิ่งที่ควรทำตอนนี้

  1. ทำ checklist 10 ข้อ — ถ้าได้ "ใช่" ต่ำกว่า 7 ข้อ คือมี exposure ต่อ fraud
  2. ตรวจสอบ vendor master change ย้อนหลัง 6 เดือน — เน้นการเปลี่ยน bank account ที่ทำในวันสุดท้ายก่อน due date
  3. กำหนดนโยบาย dual approval สำหรับการแก้ vendor bank account — แม้ยังไม่มีระบบรองรับ ให้ทำผ่านการลงนาม 2 คนก่อน
  4. เริ่ม 3-way match แบบ manual ในระดับสุ่ม ก่อน — เลือก invoice 10 ใบสุ่ม / สัปดาห์ เทียบกับ PO และ GR
  5. ประเมินระบบปัจจุบัน — ระบบบัญชีที่ใช้อยู่รองรับ 3-way match อัตโนมัติหรือไม่ — ถ้าไม่ ต้องประเมินการ upgrade

หากองค์กรของคุณกำลังประเมินความเสี่ยง invoice fraud หรือต้องการระบบ AP ที่มี control เหล่านี้ในตัว — ทีม Saeree พร้อมให้คำปรึกษาเรื่อง การออกแบบโมดูล AP, approval workflow, และการเชื่อมต่อกับ e-Tax Invoice ของกรมสรรพากร สามารถติดต่อทีมที่ปรึกษาได้โดยตรง

แหล่งอ้างอิง

สนใจระบบ ERP สำหรับองค์กรของคุณ?

ปรึกษาผู้เชี่ยวชาญจาก Grand Linux Solution

ขอ Demo ฟรี

โทร 02-347-7730 | sale@grandlinux.com

Saeree ERP Author Sureeraya Limpaibul

เกี่ยวกับผู้เขียน

สุรีระยา ลิ้มไพบูลย์

กรรมการผู้จัดการ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด และผู้ก่อตั้ง Saeree ERP พร้อมให้คำปรึกษาและบริการด้านระบบ ERP ครบวงจร