Psuedo Account Evolution

เมื่อเราพยายามแยกการคีย์ข้อมูลออกจากการตัดสินใจทางบัญชี

ถ้าถามนักบัญชีว่า

“คนคีย์ข้อมูล (Bookkeeper) ควรต้องรู้บัญชีหรือไม่”

คำตอบที่ได้รับส่วนใหญ่คงเป็น

“ก็ต้องรู้สิ”

เพราะในโลกของระบบบัญชีที่เราคุ้นเคย 

การบันทึกรายการกับการตัดสินใจว่าจะลงบัญชีอะไร 

เป็นสิ่งเดียวกันมาโดยตลอด

ค่าถ่ายเอกสาร ลงบัญชีไหน

ค่าไฟฟ้า ลงบัญชีไหน

ค่าเดินทาง ลงบัญชีไหน

แม้แต่สำนักงานบัญชีที่รับผิดชอบลูกค้าหลายราย 

ก็มักต้องจัดสรรงานให้พนักงานแต่ละคนดูแลลูกค้าประจำของตนเอง 

เพราะแต่ละกิจการมีนโยบายการลงบัญชีไม่เหมือนกัน

คนที่ไม่คุ้นกับลูกค้ารายนั้น 

อาจคีย์ข้อมูลได้ 

แต่ไม่กล้าตัดสินใจว่าจะลงบัญชีอย่างไร

หลายปีก่อน 

เราเคยตั้งคำถามกลับด้าน

ถ้าคนคีย์ข้อมูลไม่จำเป็นต้องรู้บัญชีเลย จะเกิดอะไรขึ้น

---

แนวคิดนี้เกิดขึ้นจากการออกแบบ ERP ที่ใช้ Pseudo Account

ในบทความก่อน 

ผมเคยเล่าถึงแนวคิดการ Compile Transaction 

ให้กลายเป็น Pseudo Account 

ก่อนจะแปลเป็นรหัสบัญชีจริงตามผังบัญชี

ตัวอย่างเช่น

*SALE
*AR
*VAT
*DEFERRED

แนวคิดเดิมมีเป้าหมายเพื่อลดการผูกติด

ระหว่าง Transaction กับ Chart of Accounts

แต่ระหว่างออกแบบ 

เราพบว่ามันสามารถไปได้ไกลกว่านั้น

Pseudo Account ไม่จำเป็นต้องหยุดอยู่แค่ระดับเดียว

เราสามารถแปลจาก Pseudo Account ระดับแรก 

ไปเป็น Pseudo Account ระดับที่สองได้อีกชั้นหนึ่ง

ตัวอย่างเช่น

*DEFERRED ที่เป็น general account

อาจถูกแปลเป็น

*EXPENSE ในฝั่งเอกสารซื้อ

หรือ

*SALE ในฝั่งเอกสารขาย

จากนั้นจึงค่อยแปลเป็นรหัสบัญชีจริงอีกที

---

สิ่งที่น่าสนใจคือ ระบบไม่ได้ใช้แค่รหัส

แต่ใช้บริบทที่แนบมากับรายการด้วย

เช่น

*EXPENSE Sub Account: ค่าไฟฟ้า

หรือ

*EXPENSE Sub Account: ค่าเดินทาง

หรือ

*EXPENSE Sub Account: ค่าถ่ายเอกสาร

Sub Account ไม่ได้มีหน้าที่เป็นบัญชี

มันเป็นเพียงคำอธิบายตามธรรมชาติของรายการ

เป็นข้อมูลที่พนักงานสามารถกรอกได้

โดยไม่ต้องรู้ว่าหัวหน้าบัญชีต้องการให้ลงบัญชีอะไร

ในมุมหนึ่ง

มันคือการแยก“ข้อเท็จจริง”

ออกจาก“การตีความทางบัญชี”

---

หากมองลึกลงไป 

แนวคิดนี้พยายามแก้ปัญหาพื้นฐานอย่างหนึ่ง

ทำไมคนคีย์ข้อมูลจึงต้องเป็นผู้ตัดสินใจทางบัญชีตั้งแต่ต้นทาง

เพราะเมื่อพนักงานเลือกบัญชี 

“ค่าถ่ายเอกสาร”

ให้ลงบัญชีค่าใช้จ่ายเบ็ดเตล็ด

ข้อเท็จจริงที่เหลือก็หายไปทันที

อีกหลายเดือนต่อมา 

ผู้ตรวจสอบอาจเห็นเพียงยอดค่าใช้จ่ายเบ็ดเตล็ด 

แต่ไม่รู้แล้วว่ารายการต้นทางคืออะไร

ระบบบัญชีแบบดั้งเดิมบีบให้การจัดหมวดหมู่เกิดขึ้นเร็วเกินไป

ก่อนที่เราจะรู้ด้วยซ้ำว่าผู้ใช้งานข้อมูลในอนาคตต้องการมุมมองแบบไหน

---

แนวคิดนี้ยังนำไปสู่ความเป็นไปได้อีกอย่าง

นั่นคือ การมีผังบัญชีหลายชุดจากข้อมูลชุดเดียว

ในอดีต ผมเคยมีมุมมองเชิงลบต่อคำว่า

“งบภายใน”และ“งบภายนอก”

เพราะรู้สึกว่าเป็นสัญญาณของความไม่โปร่งใส

แต่เมื่อเวลาผ่านไปจึงเริ่มเข้าใจว่า 

โลกธุรกิจจริงไม่ได้มีผู้มีส่วนได้ส่วนเสียเพียงกลุ่มเดียว

เจ้าของกิจการ

กรรมการ

เจ้าหนี้

นักลงทุน

สำนักงานบัญชี

และหน่วยงานภาครัฐ

ล้วนมองธุรกิจจากคนละมุม

ดังนั้นจึงไม่ใช่เรื่องแปลก

ที่รายงานทางการเงินหลายชุดจะถูกสร้างจากข้อเท็จจริงชุดเดียวกัน

ตราบใดที่สามารถตรวจสอบย้อนกลับถึงกันได้

Pseudo Account จึงเริ่มมีบทบาทคล้ายภาษากลาง

เป็นชั้นกลางระหว่างธุรกรรมจริงกับนโยบายทางบัญชีที่อาจแตกต่างกัน

---

แน่นอนว่าโปรเจกต์นี้ล้มเหลว

แต่ไม่ได้ล้มเหลวเพราะเทคโนโลยี

และไม่ได้ล้มเหลวเพราะแนวคิด

มันล้มเหลวเพราะธรรมชาติของงานบัญชี

นักบัญชีมีรอบการทำงานที่ชัดเจน

ช่วงปกติแทบไม่มีเหตุผลให้ลงทุนสร้าง Mapping

แต่เมื่อถึงช่วงปิดงบ 

ทุกคนจะเลือกวิธีที่มั่นใจว่าจะส่งงานทันกำหนด

การขอให้สมุหบัญชีมานั่งสร้าง Keyword Mapping

ออกแบบ Translation Rules

หรือเรียนรู้เทคนิคอย่าง Regular Expression

จึงกลายเป็นภาระเพิ่มเติม 

มากกว่าจะเป็นเครื่องมือช่วยงาน

โดยเฉพาะเมื่อผลลัพธ์ปลายทางยังเป็นสิ่งที่มองไม่เห็น

ผู้ใช้งานไม่ได้ปฏิเสธแนวคิด

พวกเขาเพียงไม่สามารถหาเวลามาสร้างอนาคตได้

ในขณะที่กำลังพยายามปิดงบของเดือนนี้

---

ทุกวันนี้ผมยังคิดว่าแนวคิดนี้มีคุณค่า

ไม่ใช่เพราะมันช่วยลดงานบัญชี

แต่เพราะมันแยก “การบันทึกข้อเท็จจริง”

ออกจาก “การตัดสินใจเชิงนโยบาย”

หากวันหนึ่ง OCR สามารถอ่านเอกสารได้เอง

หรือ AI สามารถเรียนรู้จากการตัดสินใจย้อนหลังของนักบัญชีได้

สิ่งที่ระบบต้องการอาจไม่ใช่รหัสบัญชีตั้งแต่ต้นทาง

แต่เป็นข้อเท็จจริงที่ถูกบันทึกไว้อย่างครบถ้วนที่สุด

บางทีโปรเจกต์นี้อาจไม่ได้ล้มเหลว

มันอาจเพียงเกิดขึ้นก่อนเวลาของมันเท่านั้น