ในหลายองค์กร เวลาพูดถึง OCR คนมักคิดว่า
“แค่ดึงข้อความจาก Invoice ออกมาได้ ก็จบแล้ว”
แต่ในโลกจริง โดยเฉพาะระบบบัญชีและภาษี
สิ่งที่ยากที่สุดไม่ใช่ OCR
แต่คือ
“ทำอย่างไรให้ข้อมูลที่ OCR อ่านมา ‘เชื่อถือได้พอ’ สำหรับใช้ในกระบวนการทางธุรกิจต่อไป”
และนี่คือหนึ่งในระบบที่ผมพัฒนาขึ้น เพื่อจัดการกับปัญหานั้น
📌 Background ของระบบ
ระบบนี้เป็นส่วนหนึ่งของ workflow สำหรับ
- Upload invoice ไปยัง OCR engine
- Download ผลลัพธ์ OCR กลับมา
- Validate ข้อมูล
- ให้ผู้ใช้งานตรวจสอบ
- Post เข้า SAP อัตโนมัติ
จากโค้ดจริงของระบบ จะเห็นชัดว่า
“Validation” ถูกออกแบบเป็น core layer ของทั้ง workflow
ไม่ใช่ขั้นตอนเสริมทีหลัง
⚠️ ปัญหาที่แท้จริงของ OCR
OCR ไม่ได้ “ผิดทั้งหมด”
แต่ปัญหาคือ
- อ่านได้ไม่ครบ
- อ่านผิดบาง field
- format ไม่คงที่
- ข้อมูลสำคัญบางตัวหาย
- บางครั้ง OCR อ่าน “ใกล้เคียง” แต่ไม่ถูกต้องเชิงธุรกิจ
ซึ่งในระบบบัญชี
“เกือบถูก” = “ผิด”
โดยเฉพาะข้อมูลอย่าง
- Company Code
- Vendor Code
- Tax ID
- Invoice Number
- VAT Amount
เพราะถ้าผิดแม้เพียงตัวเดียว
- posting ผิดบริษัท
- vendor mapping ผิด
- duplicate invoice
- VAT report ผิด
- audit trace มีปัญหา
🧠 แนวคิดหลักของระบบนี้
แทนที่จะเชื่อ OCR โดยตรง
ระบบถูกออกแบบบนแนวคิดว่า
“OCR เป็นเพียงผู้เสนอข้อมูล
แต่ระบบ validation ต้องเป็นผู้ตัดสินว่าข้อมูลนั้น ‘ใช้งานได้จริง’ หรือไม่”
ดังนั้นทุก record ต้องผ่าน
- business rule validation
- master data validation
- structural validation
- duplicate checking
ก่อนจะถูกส่งต่อไป SAP
⚙️ ตัวอย่าง Validation Logic จากระบบจริง
1. Validate Company Code
ระบบตรวจสอบว่า
- Company Code ว่างหรือไม่
- Company Code ตรงกับ business unit จริงหรือไม่
ถ้าพบว่าหาย:
- ระบบเติมค่าให้อัตโนมัติในบางกรณี
- หรือ mark สีเหลืองเพื่อให้ user ตรวจสอบ
นี่ไม่ใช่แค่ “เช็คข้อมูล”
แต่คือ
“repair + validation” ไปพร้อมกัน
2. Validate Vendor จาก Tax ID
ระบบไม่ได้เชื่อ Vendor Name จาก OCR โดยตรง
แต่ใช้
- Tax ID
- Branch
- Vendor Master
เพื่อ cross-check ความสัมพันธ์ของข้อมูล
เพราะในโลกจริง
Vendor Name OCR ผิดได้ง่าย
แต่ Tax ID มีความน่าเชื่อถือกว่า
3. Duplicate Invoice Detection
หนึ่งในปัญหาใหญ่ของ OCR workflow คือ
invoice เดิมถูก scan ซ้ำ
ระบบจึงสร้าง dictionary
- Tax ID + Invoice Number
เพื่อใช้ detect duplicate ก่อน posting
นี่ช่วยลด
- duplicate posting
- payment duplication
- accounting reconciliation issue
ได้อย่างมาก
4. Error Description Layer
ทุก validation ไม่ได้หยุดแค่ “เจอ error”
แต่ระบบเขียน
- Error_Desc
- คำอธิบาย
- สาเหตุที่แก้ไข
เก็บไว้ในไฟล์ผลลัพธ์ด้วย
สิ่งนี้สำคัญมาก เพราะ
ระบบ automation ที่ดี ต้อง explain ตัวเองได้
ไม่ใช่แค่ “ผ่าน/ไม่ผ่าน”
🔄 Human-in-the-loop Design
สิ่งที่ผมตั้งใจในระบบนี้ คือ
ไม่ใช่ replace คน
แต่ทำให้คนตรวจเฉพาะ “จุดที่มีความเสี่ยง”
ดังนั้น workflow จริงคือ
- OCR อ่าน
- ระบบ validate
- highlight anomaly
- user review เฉพาะ exception
- post เข้า SAP
แทนที่ user จะต้อง
- เปิด invoice ทุกใบ
- เช็คทุก field
- ตรวจ manual ทั้งหมด
📊 ผลลัพธ์ที่ได้จากแนวคิดนี้
หลังมี validation layer
- ลด manual checking จำนวนมาก
- ลด duplicate posting
- ลด vendor mismatch
- ลด human error
- เพิ่มความเร็วในการ prepare posting
- ทำให้ OCR data “พร้อมใช้งานจริง”
เพราะในท้ายที่สุด
สิ่งที่องค์กรต้องการ ไม่ใช่ OCR ที่อ่านได้
แต่คือ “ข้อมูลที่เชื่อถือได้”
💡 Insight Layer
🧠 System Insight
ปัญหาของ OCR ในองค์กร ไม่ใช่ accuracy อย่างเดียว
แต่คือ
“ความไม่สอดคล้องกับ business rule”
OCR อาจอ่านถูกเชิงข้อความ
แต่ผิดเชิงธุรกิจได้เสมอ
ดังนั้น
validation layer คือส่วนที่เปลี่ยน “ข้อความ” ให้กลายเป็น “ข้อมูลธุรกิจ”
👥 Behavioral Insight
หลายองค์กรพยายามแก้ OCR ด้วย
- model ที่แม่นขึ้น
- AI ที่ฉลาดขึ้น
- template ที่ละเอียดขึ้น
แต่สิ่งที่มักขาดคือ
business validation logic
ทั้งที่ในโลกจริง
- คนบัญชีไม่ได้สนใจ OCR score
- แต่สนใจว่า post เข้า SAP ได้หรือไม่
🔁 Reusable Principle
ถ้าระบบปลายทางเป็น
- ERP
- SAP
- Financial posting
- Tax reporting
อย่าเชื่อ OCR โดยตรง
แต่ต้องมี
- validation layer
- reconciliation logic
- master data checking
- explainable error handling
เสมอ
🚀 สรุป
ระบบนี้ไม่ได้ถูกออกแบบให้
“อ่าน Invoice ได้เก่ง”
แต่ถูกออกแบบให้
“ทำให้ข้อมูลจาก OCR เชื่อถือได้พอสำหรับระบบองค์กรจริง”
และในโลกของ enterprise automation
Validation คือหัวใจของความน่าเชื่อถือ
ไม่ใช่ OCR accuracy เพียงอย่างเดียว