- 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 "ขอเปลี่ยนเลขบัญชี" ก่อนวันจ่าย:
- Hack หรือ spoof email ของ vendor (ใช้ domain ใกล้เคียง เช่น
vendor.co.th→vend0r.co.th) - ส่งจดหมาย "วันนี้บัญชีใหม่จะ active แล้วครับ ขอให้โอนเข้าเลขใหม่ตามแนบ"
- แนบ "หนังสือเปลี่ยนแปลงข้อมูลผู้รับเงิน" ปลอม
- 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
สรุป — สิ่งที่ควรทำตอนนี้
- ทำ checklist 10 ข้อ — ถ้าได้ "ใช่" ต่ำกว่า 7 ข้อ คือมี exposure ต่อ fraud
- ตรวจสอบ vendor master change ย้อนหลัง 6 เดือน — เน้นการเปลี่ยน bank account ที่ทำในวันสุดท้ายก่อน due date
- กำหนดนโยบาย dual approval สำหรับการแก้ vendor bank account — แม้ยังไม่มีระบบรองรับ ให้ทำผ่านการลงนาม 2 คนก่อน
- เริ่ม 3-way match แบบ manual ในระดับสุ่ม ก่อน — เลือก invoice 10 ใบสุ่ม / สัปดาห์ เทียบกับ PO และ GR
- ประเมินระบบปัจจุบัน — ระบบบัญชีที่ใช้อยู่รองรับ 3-way match อัตโนมัติหรือไม่ — ถ้าไม่ ต้องประเมินการ upgrade
หากองค์กรของคุณกำลังประเมินความเสี่ยง invoice fraud หรือต้องการระบบ AP ที่มี control เหล่านี้ในตัว — ทีม Saeree พร้อมให้คำปรึกษาเรื่อง การออกแบบโมดูล AP, approval workflow, และการเชื่อมต่อกับ e-Tax Invoice ของกรมสรรพากร สามารถติดต่อทีมที่ปรึกษาได้โดยตรง
