ERP ลงบัญชีอัตโนมัติ แล้วทำไมยัง DIF?

Sathit Jittanupat

5 ก.ย.

ยาว 2 นาที

อัปเดตเมื่อ 6 วันที่ผ่านมา

มีคำถามหนึ่งจากฝ่ายบัญชีที่ผมคิดว่าน่าสนใจมาก

ไม่ใช่เพราะเป็นคำถามที่ตอบยาก แต่เพราะเป็นคำถามที่ดูเหมือนง่ายมาก

“ในเมื่อ ERP ลงบัญชีอัตโนมัติแล้ว ทำให้มันไม่ DIF ได้ไหม?”

ต้นเหตุของคำถามนี้มีเพียง 0.01 บาท ไม่คุ้มค่าความยุ่งยากสำหรับคนบัญชี

แต่สำหรับคนทำ ERP ผมคิดว่า 0.01 บาทนี้น่าสนใจกว่าที่เห็น

เพราะมันทำให้ต้องย้อนกลับไปถามว่า

ตัวเลขที่ ERP กำลังบอกเราอยู่นั้น เป็นตัวเลขของเหตุการณ์ไหน?

และเมื่อมีตัวเลขสองชุดที่ไม่ตรงกัน เราควรรีบแก้ให้มันเท่ากัน หรือควรทำความเข้าใจก่อนว่าทำไมมันจึงต่างกัน

เรื่องเริ่มจากสินค้าที่มาคนละเวลา

กรณีนี้เป็นการซื้อสินค้าจากต่างประเทศ

ERP ของที่นี่ไม่ได้รอให้เอกสารซื้อเสร็จทุกอย่างแล้วค่อยบันทึกทีเดียว แต่พยายามบันทึกตามเหตุการณ์จริงของธุรกิจ

เมื่อสินค้ามาถึง สโตร์จะตรวจสินค้าและรับเข้าคลังด้วยเอกสาร GR — Goods Receipt

ส่วนฝ่ายบัญชี เมื่อได้รับข้อมูลและตรวจสอบความถูกต้องของธุรกรรมแล้ว จึงนำรายการเหล่านั้นมาตั้งหนี้ด้วยเอกสาร AP — Account Payable

จึงมีสองจังหวะ

GR = ของมาถึงแล้ว

AP = ตรวจสอบแล้ว และเกิดเจ้าหนี้ที่ต้องชำระ

สำหรับเคสนี้ สินค้าถูกส่งมาสองครั้ง

ครั้งแรกเป็น GR-0001

MAT-A     USD  7,582.40
MAT-B     USD 37,225.60
------------------------
รวม       USD 44,808.00

ครั้งที่สองเป็น GR-0002

GOODS-C   USD    327.30
GOODS-D   USD    327.30
------------------------
รวม       USD    654.60

ทั้งสอง GR ใช้อัตราแลกเปลี่ยนเดียวกัน

USD/THB = 33.3605

เมื่อระบบลงบัญชีแต่ละ GR จึงได้

GR-0001
USD 44,808.00 × 33.3605
= THB 1,494,817.2840
→ THB 1,494,817.28

และ

GR-0002
USD 654.60 × 33.3605
= THB 21,837.7833
→ THB 21,837.78

ดังนั้น GL รอตั้งหนี้ ที่เกิดขึ้นต่างกรรมต่างวาระ จาก GR สองใบจึงเป็น

GR-0001       THB 1,494,817.28
GR-0002       THB    21,837.78
--------------------------------
รวม            THB 1,516,655.06

ถึงตรงนี้ไม่มีอะไรผิด

แต่เมื่อถึงเวลาตั้งหนี้ เรื่องกลับไม่เหมือนเดิม

ฝ่ายบัญชีนำ GR ทั้งสองใบมาตั้งหนี้เป็น AP-0001

รายการใน AP คือ

[@GR-0001] MAT-A       USD  7,582.40
[@GR-0001] MAT-B       USD 37,225.60
[@GR-0002] GOODS-C     USD    327.30
[@GR-0002] GOODS-D     USD    327.30
--------------------------------------
รวม                      USD 45,462.60

ถ้ามองจากฝ่ายบัญชี AP กำลังตอบคำถามใหม่ว่า

“หนี้ก้อนนี้มีมูลค่าเท่าไร?”

จึงนำยอดรวม USD มาคำนวณใหม่

USD 45,462.60 × 33.3605
= THB 1,516,655.0673
→ THB 1,516,655.07

แล้วปัญหาก็เกิดขึ้น

GL รอตั้งหนี้ บันทึกจาก GR รวมกันได้

THB 1,516,655.06

แต่ AP กลับเป็น

THB 1,516,655.07

ต่างกัน 0.01 บาท

แล้วใครคำนวณผิด?

คำตอบคือ

ไม่มีใครผิด

GR-0001 ถูกต้อง

GR-0002 ก็ถูกต้อง

AP-0001 ก็ถูกต้อง

สิ่งที่เกิดขึ้นคือ การปัดเศษเกิดขึ้น คนละจังหวะ

ถ้าเราคำนวณแล้วปัดเศษทีละเอกสาร

Round(GR-0001) + Round(GR-0002)
=THB 1,516,655.06

แต่ถ้าเราเอายอดทั้งหมดมารวมก่อนแล้วค่อยปัด

Round(GR-0001 + GR-0002)
=THB 1,516,655.07

ผลลัพธ์จึงต่างกันหนึ่งสตางค์

ในทางคณิตศาสตร์ เรื่องแบบนี้เป็นเรื่องธรรมดา

เพราะโดยทั่วไป

การปัดเศษของผลรวม ไม่จำเป็นต้องเท่ากับผลรวมของค่าที่ปัดเศษแล้ว

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

“แต่ทำให้มันไม่ DIF ได้ไหม?”

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

“ได้ครับ แต่ขออธิบายก่อนว่า DIF นี้เกิดขึ้นอย่างไร”

เพราะผมไม่อยากรีบแก้โปรแกรมเพียงเพื่อให้ตัวเลข 0.01 บาทหายไป

ในกรณีเฉพาะหน้า ฝ่ายบัญชีสามารถใช้การ override การลงบัญชีแบบ manual เพื่อปรับยอดให้ตรงก่อน

ไม่ได้หมายความว่าเราพอใจกับการทำงานแบบ manual

แต่หมายความว่า

เราไม่ควรเอาเหตุการณ์หนึ่งครั้ง ไปเปลี่ยนกติกาของระบบทั้งระบบโดยที่ยังไม่เข้าใจต้นเหตุ

นี่เป็นสิ่งที่ผมคิดว่าสำคัญมากสำหรับ ERP

โดยเฉพาะเรื่องที่เกี่ยวข้องกับ accounting policy

แก้ให้ไม่ DIF กับทำให้ DIF หาย เป็นคนละเรื่องกัน

ถ้าโจทย์มีเพียงว่า

“ทำอย่างไรก็ได้ให้ AP กับ GR เท่ากัน”

โปรแกรมเมอร์สามารถทำได้หลายวิธี

เช่น เอา 0.01 ไปบวกหรือลบกับรายการใดรายการหนึ่ง

หรือเอาไปลงบัญชีบางบัญชี

แล้วหน้าจอก็จะสวย

Debit เท่ากับ Credit

ยอด AP เท่ากับ ยอด GR

DIF = 0.00

จบ

แต่คำถามคือ

0.01 บาทนั้นหายไปไหน?

และที่สำคัญกว่า

ทำไมมันจึงเกิดขึ้น?

สำหรับผม ระบบบัญชีที่ดีไม่ควรมีเป้าหมายเพียงว่า

“ทำอย่างไรก็ได้ให้ไม่ DIF”

แต่ควรเป็น

“ถ้ามี DIF ระบบต้องอธิบายได้ว่ามันเกิดจากอะไร”

จึงเป็นที่มาของการปรับโปรแกรม

แนวทางที่ผมเลือกจึงไม่ใช่การบังคับให้ทุก calculation path ให้ผลเหมือนกัน

แต่กำหนด กติกาการคำนวณให้ชัดเจน

ในกรณีที่ AP ดึงรายการมาจากเอกสารต้นทาง เช่น GR

ระบบจะคำนวณ “ยอดรวมและปัดเศษ” จาก แต่ละ source document ก่อน

ในตัวอย่างนี้

GR-0001 → THB 1,494,817.28
GR-0002 → THB    21,837.78
--------------------------------
รวม       THB 1,516,655.06

ยอดนี้จะถูกใช้เป็นฐานในการล้างยอดรอตั้งหนี้

วิธีคิดนี้ทำให้เรารักษาความสัมพันธ์ระหว่าง AP กับเอกสารต้นทางเอาไว้

เพราะ AP ไม่ได้เป็นการเอารายการ USD ทั้งหมดมาคำนวณใหม่โดยไม่สนใจว่าแต่ละรายการมาจากไหน

แต่เป็นการ รวบรวมความจริงจากเอกสารที่เกิดขึ้นก่อนหน้า

แล้วถ้ามีรายการที่ไม่ได้มาจาก source document ล่ะ?

นี่ก็เป็นรายละเอียดเล็ก ๆ ที่ทำให้การออกแบบระบบจริงต่างจากการแก้ตัวอย่างในกระดาษ

เพราะในโลกจริง AP อาจมีรายการที่ไม่ได้มาจาก GR โดยตรง แต่อาจเป็นค่าใช้จ่ายที่เกิดพร้อมกับการตั้งหนี้

ดังนั้น algorithm ไม่ควรตั้งสมมติฐานว่า

“ทุกอย่างต้องมาจาก source document”

แต่ควรมีอีกชั้นหนึ่งสำหรับรายการที่ไม่มีต้นทางให้จับกลุ่ม

จึงนำยอดเหล่านั้นเข้าสู่การคำนวณสุทธิแล้วปัดเศษอีกครั้งตามกติกาที่กำหนดไว้

ประเด็นสำคัญจึงไม่ใช่สูตรเพียงอย่างเดียว

แต่คือ

เรากำลังบอกระบบว่า ถ้ามีข้อมูลหลายระดับ ระบบควรให้ความสำคัญกับข้อมูลระดับไหนก่อน

แล้ว 0.01 บาทที่ต่างกันล่ะ?

เมื่อระบบคำนวณยอดตามเอกสารต้นทางแล้วได้

GR-0001        THB 1,494,817.28
GR-0002        THB    21,837.78
--------------------------------
รวม            THB 1,516,655.06

ขณะที่ยอดสุทธิของ AP จาก USD 45,462.60 เมื่อนำมาแปลงและปัดเศษที่ระดับยอดรวม ได้

AP-0001        THB 1,516,655.07

จึงเกิดส่วนต่างขึ้น 0.01 บาท

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

จึงมีการออกแบบบัญชีพิเศษ *XCHDIF สำหรับรองรับส่วนต่างลักษณะนี้

กล่าวคือ *XCHDIF ไม่ได้หมายความว่า

“ระบบรู้แล้วว่า 0.01 บาทนี้ต้องเป็นค่าใช้จ่าย”

และไม่ได้หมายความว่าเป็นบัญชีสำหรับกำไรขาดทุนจากอัตราแลกเปลี่ยนโดยอัตโนมัติ

มันเป็นเพียง บัญชีพักสำหรับระบุและแยกส่วนต่างที่เกิดจากกลไกการคำนวณและการปัดเศษ

ดังนั้นในตัวอย่างนี้ หากยอดที่ต้องทำให้สมดุลอยู่ที่

THB 1,516,655.07

แต่ยอดจากการรวมมูลค่าที่คำนวณและปัดเศษตามเอกสารต้นทางได้

THB 1,516,655.06

ส่วนต่าง THB 0.01 จะถูกแสดงแยกเป็น *XCHDIF

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

จากนั้นผู้วางระบบจึงสามารถกำหนด mapping ของ *XCHDIF ไปยังรหัสบัญชีจริงตามนโยบายของแต่ละองค์กรได้

จุดสำคัญคือ

ERP เป็นผู้ระบุว่า “มีส่วนต่างเกิดขึ้น” แต่ไม่ได้เป็นผู้ตัดสินว่า “ส่วนต่างนั้นต้องถือเป็นบัญชีอะไร”

การจัดประเภททางบัญชีจึงยังคงเป็นเรื่องที่องค์กรต้องกำหนดเอง

ผมเริ่มมอง 0.01 บาทต่างไปจากเดิม

ตอนแรกเรามองมันเป็นปัญหา

เพราะมันทำให้เกิด DIF

แต่เมื่อย้อนกลับไปดูเหตุการณ์ทั้งหมด จะเห็นว่า 0.01 บาทนี้ไม่ได้เกิดจากใครทำผิด

มันเกิดจากการที่

GR กับ AP กำลังมองธุรกรรมเดียวกันจากคนละจังหวะ

GR มองเหตุการณ์ที่สินค้าเข้าคลัง

AP มองเหตุการณ์ที่เกิดเจ้าหนี้

และเมื่อสองเหตุการณ์นี้ใช้วิธีคำนวณและปัดเศษคนละจังหวะ ตัวเลขก็สามารถต่างกันได้

ดังนั้น 0.01 บาทจึงเป็นเหมือน ร่องรอยของวิธีที่ ERP มองเหตุการณ์

เพราะ ERP ไม่ควรแค่ทำให้ตัวเลขตรง

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

เราไม่ควรพอใจกับระบบเพียงเพราะ

“มันลงบัญชีเองได้”

แต่ควรถามด้วยว่า

“ถ้าตัวเลขไม่ตรงกัน ระบบอธิบายได้หรือไม่ว่าทำไม?”

เพราะความผิดพลาดกับความแตกต่างไม่ใช่สิ่งเดียวกัน

และการทำให้ตัวเลขเท่ากัน ก็ไม่จำเป็นต้องหมายความว่า เราเข้าใจความแตกต่างนั้นแล้ว

บางครั้งตัวเลขต่างกันเพียงหนึ่งสตางค์

แต่สิ่งที่มันกำลังบอกเรา อาจสำคัญกว่านั้นมาก

ว่าในระบบ ERP ของเรา

มีความจริงมากกว่าหนึ่งชุด

และหน้าที่ของระบบที่ดี อาจไม่ใช่การทำให้ความจริงเหล่านั้นเหมือนกันทั้งหมด

แต่อาจเป็นการทำให้เรา

รู้ว่ามันต่างกันเพราะอะไร