การแทนการทำบัญชีคู่ด้วยกราฟมีทิศทาง
(matheusportela.com)- แม้คำศัพท์ทางบัญชีจะไม่คุ้นเคย ก็สามารถเข้าใจการทำบัญชีคู่ในฐานะโมเดลการไหลของเงินได้ หากมองเป็นโครงสร้างที่ติดตาม บัญชี และ ยอดคงเหลือ ตามเวลา
- ตารางที่เขียนทับเฉพาะยอดคงเหลือปัจจุบันจะสูญเสียกระบวนการเปลี่ยนแปลงไป แต่ สมุดบัญชีแยกประเภท จะเพิ่มรายการทุกครั้งที่เกิดธุรกรรม จึงเก็บประวัติและร่องรอยการแก้ไขไว้
- การทำบัญชีเดี่ยวอาจเพียงพอสำหรับการบันทึกการเปลี่ยนแปลงแยกตามบัญชี แต่เมื่อหลายบัญชีเคลื่อนไหวร่วมกัน ต้องรวมรายการที่เกี่ยวข้องเป็น ธุรกรรม เพื่อแสดงแหล่งที่มาและปลายทาง
- ในการทำบัญชีคู่ ทุกธุรกรรมต้องมีจำนวนเงินที่ออกและจำนวนเงินที่เข้าเท่ากัน และเงื่อนไขสมดุลนี้ช่วยจับข้อผิดพลาดในการทำบัญชีด้วยมือได้เหมือน checksum
- หากมองบัญชีและธุรกรรมเป็นโหนด และมองรายการเดบิต·เครดิตเป็นเส้นเชื่อมแบบมีทิศทาง สมุดบัญชีจะกลายเป็น กราฟมีทิศทาง ที่เติบโตขึ้นตามเวลา และงบการเงินก็สามารถมองได้ว่าเป็นการทำให้กราฟนั้นมองเห็นได้
ข้อมูลที่สูญเสียไปเมื่อบันทึกเฉพาะยอดคงเหลือ
- การบัญชีคือการติดตามสิ่งที่นับได้ตามเวลา โดยในที่นี้จะเน้นที่การไหลของเงิน
- ในตัวอย่าง เริ่มจากวันที่ 1 มกราคม 2024 โดย Alice มี $100 และ Bob มี $50
- เมื่อ Alice จ่ายค่าหนังสือ $20 ให้ Bob ยอดคงเหลือของ Alice จะเป็น $80 และยอดคงเหลือของ Bob จะเป็น $70
- ในที่นี้ บัญชี (account) คือสถานที่ที่เก็บเงิน และ ยอดคงเหลือ (balance) คือจำนวนเงินที่อยู่ในบัญชี ณ เวลาหนึ่ง
- หากเขียนทับเฉพาะยอดคงเหลือปัจจุบัน ก็ยากที่จะรู้ว่าเหตุใด Alice จึงมี $80
- เป็นเพราะเริ่มจาก $0 แล้วได้รับ $80 หรือไม่
- หรือเป็นเพราะเริ่มจาก $10,000 แล้วใช้ไป $9,920 ก็แยกไม่ออก
- วิธีที่เหลือไว้เฉพาะสแนปช็อตของยอดคงเหลือจะลบกระบวนการที่ทำให้เกิดการเปลี่ยนแปลงทิ้งไป
สมุดบัญชีแยกประเภทแบบบัญชีเดี่ยวและบันทึกที่ไม่เปลี่ยนรูป
- หากต้องการเก็บประวัติการเปลี่ยนแปลง ควรเพิ่มแถวใหม่ทุกครั้งที่เกิดธุรกรรม แทนที่จะแก้ค่าที่มีอยู่
- รายการในสมุดบัญชีแยกประเภทโดยทั่วไปมีข้อมูลต่อไปนี้
- Description: คำอธิบายธุรกรรม ผู้รับเงิน หมายเลขอ้างอิง เป็นต้น ซึ่งเป็นคำอธิบายที่มนุษย์อ่านได้
- Date: วันที่เกิดธุรกรรม และใช้สำหรับการจัดกลุ่มตามช่วงเวลา เช่น รายงานรายเดือน ได้ด้วย
- Balance: ยอดคงเหลือของบัญชีหลังธุรกรรม เป็นข้อมูลซ้ำซ้อนแต่มีประโยชน์ในการตรวจสอบข้อมูล
- แต่ละแถวคือ รายการ (entry) และชุดรายการของบัญชีหนึ่งคือ สมุดบัญชีแยกประเภท (ledger)
- สมุดบัญชีของ Alice บันทึก opening balance $100 ในวันที่ 1 มกราคม 2024 และ bought book -$20 ในวันที่ 1 กุมภาพันธ์ 2024
- สมุดบัญชีของ Bob บันทึก opening balance $50 และ sold book $20
- วิธีนี้คือระบบ การทำบัญชีเดี่ยว (single-entry bookkeeping)
- แต่ละบัญชีมีสมุดบัญชีแยกประเภทของตนเอง
- บันทึกรายการที่ส่งผลต่อบัญชีเดียวในแต่ละครั้ง
- อาจเหมาะกับธุรกิจขนาดเล็กหรือการเงินส่วนบุคคล
สมุดบัญชีแยกประเภททำงานคล้าย event sourcing
- คุณลักษณะสำคัญของสมุดบัญชีแยกประเภทคือข้อมูลเป็นแบบ ไม่เปลี่ยนรูป (immutable)
- เมื่อเขียนรายการไปแล้ว จะไม่แก้ไขเพื่อรักษาประวัติทั้งหมดไว้
- หากบันทึกค่าหนังสือผิดเป็น $20 แต่ราคาจริงคือ $30 การแก้แถวเดิมจะทำให้สูญเสียจำนวนเงินเดิมและข้อเท็จจริงว่ามีการแก้ไข
- วิธีที่ดีกว่าคือเพิ่มรายการใหม่เพื่อหักล้างรายการเดิม แล้วใส่รายการที่ถูกต้องอีกครั้ง
- ยกเลิกรายการ -$20 ด้วย +$20
- จากนั้นบันทึกรายการ -$30 ใหม่
- ยอดคงเหลือสุดท้ายยังเป็น $70 เช่นเดิม แต่ข้อผิดพลาดและเหตุผลในการแก้ไขยังคงอยู่
- วิธีนี้คล้ายกับ event sourcing ในวิทยาการคอมพิวเตอร์
- เก็บเหตุการณ์ที่เกิดขึ้นในระบบ
- เล่นเหตุการณ์ซ้ำเพื่อคำนวณสถานะปัจจุบัน
- สามารถสร้างสถานะ ณ เวลาหนึ่งขึ้นมาใหม่ได้
ช่วงเวลาที่ต้องใช้การทำบัญชีคู่
- ในธุรกรรมที่หลายบัญชีเคลื่อนไหวร่วมกัน การทำบัญชีเดี่ยวเพียงอย่างเดียวทำให้เข้าใจความสัมพันธ์ได้ไม่ชัดเจน
- -$20 ของ Alice และ +$20 ของ Bob คือเงินก้อนเดียวกัน แต่ถ้าดูเพียงสมุดบัญชีแยกประเภทธรรมดา ก็แยกไม่ออกจากกรณีที่ Bob อาจได้รับเงินจาก Charlie
- หากรวมรายการที่เกี่ยวข้องเป็น ธุรกรรม (transaction) ก็สามารถระบุได้ว่ารายการเหล่านั้นอยู่ในเหตุการณ์เดียวกัน
- Transaction 1: opening balance ของ Alice
- Transaction 2: opening balance ของ Bob
- Transaction 3: Alice ซื้อหนังสือจาก Bob
- ธุรกรรมคือชุดของรายการที่เกี่ยวข้องกันซึ่งส่งผลต่อบัญชีต่าง ๆ
- การทำบัญชีคู่เชื่อมรายการที่เกี่ยวข้องกันในระดับธุรกรรม เพื่อให้เห็นการไหลของเงินระหว่างบัญชี
เดบิต เครดิต และเงื่อนไขสมดุล
- การบัญชีแบบดั้งเดิมแสดงการไหลของเงินด้วยสองคอลัมน์คือ debit และ credit
- Credit: รายการที่เงินออกจากบัญชี
- Debit: รายการที่เงินเข้าบัญชี
- เมื่อ Alice จ่าย $20 ให้ Bob บัญชีของ Alice จะบันทึกเป็น credit $20 และบัญชีของ Bob จะบันทึกเป็น debit $20
- คำว่า credit/debit ในบัตรธนาคารถูกใช้ต่างจากคำว่า debit/credit ในการบัญชี
- ในสมุดบัญชีกระดาษ เคยใช้รูปแบบ T-account ที่แบ่งด้านซ้ายเป็น debit และด้านขวาเป็น credit
- ในระบบคอมพิวเตอร์ ไม่จำเป็นต้องคงไว้สองคอลัมน์เสมอไป
- อาจใส่ Debit หรือ Credit ในคอลัมน์
Typeแล้วแยกAmountไว้ต่างหาก - หรือใช้อีกแบบคือคอลัมน์จำนวนเงินคอลัมน์เดียว โดยกำหนดให้ credit เป็นค่าลบและ debit เป็นค่าบวก
- อาจใส่ Debit หรือ Credit ในคอลัมน์
- เมื่อเทียบกับศัพท์ดั้งเดิม คำว่า incoming money และ outgoing money อาจทำให้สับสนน้อยกว่า
ธุรกรรมไม่ได้จำกัดอยู่ที่สองรายการ
- หลักการสำคัญของการทำบัญชีคู่คือ หลังแต่ละธุรกรรม ผลรวมเงินทั้งระบบจะไม่เปลี่ยน
- ยอดคงเหลือของบัญชีใดบัญชีหนึ่งอาจเพิ่มหรือลดได้ แต่ผลรวมยอดคงเหลือของทุกบัญชีต้องคงที่
- แม้แต่ opening balance หากต้องการให้สมดุล เงินก็ต้องมาจากที่ใดที่หนึ่ง
- ในตัวอย่าง เพิ่มบัญชี Bank และบันทึกว่า $100 ของ Alice และ $50 ของ Bob ออกจาก Bank
- บัญชี Bank นี้เป็นบัญชีชั่วคราวชนิดหนึ่งเพื่อรักษากฎ และในศัพท์บัญชีจัดว่าเป็น contra account
- ทุกธุรกรรมต้องมีเงินที่ออกและเงินที่เข้าเท่ากัน ซึ่งทำงานเหมือน checksum สำหรับจับข้อผิดพลาดในการทำบัญชีด้วยมือ
- ธุรกรรมที่ซับซ้อนก็สามารถสร้างโมเดลด้วยหลักการเดียวกันได้
- Alice จ่าย $20 ให้ Bob และจ่ายค่าธรรมเนียมแลกเปลี่ยนเงินตรา $2 ให้บริษัทบัตรเครดิต
- Bob ได้รับ $20 จาก Alice และจ่ายภาษีขาย $2 ให้หน่วยงานภาษี รวมถึงจ่ายค่าธรรมเนียม $1 ให้บริษัทบัตรเครดิต
- บริษัทบัตรเครดิตได้รับ $2 จาก Alice และ $1 จาก Bob
- หน่วยงานภาษีได้รับ $2 จาก Bob
- ในกรณีนี้ Transaction 3 รายการเดียวมี 8 รายการ พอดี
- “Double-entry” ไม่ได้หมายความว่าธุรกรรมมีเพียงสองรายการ แต่หมายความว่ามี สองด้าน คือด้านที่เงินออกและด้านที่เงินเข้า
มองสมุดบัญชีเป็นกราฟมีทิศทาง
- การทำบัญชีคู่สามารถมองได้ว่าเป็นการสร้างโมเดลการไหลของเงินด้วย กราฟมีทิศทาง
- ความสัมพันธ์ที่สอดคล้องกับกราฟมีดังนี้
- บัญชีคือ โหนด ของกราฟ
- ธุรกรรมก็เป็นโหนดแยกต่างหาก
- รายการ Credit คือเส้นเชื่อมขาออกจากบัญชีไปยังธุรกรรม
- รายการ Debit คือเส้นเชื่อมขาเข้าจากธุรกรรมไปยังบัญชี
- จำนวนเงินของรายการคือค่าของเส้นเชื่อม
- ยอดคงเหลือของบัญชีคือผลรวมของเส้นเชื่อมขาเข้า ลบด้วยผลรวมของเส้นเชื่อมขาออก
- Transaction 1 ย้าย $100 จาก Bank ไปยัง Alice
- Transaction 2 ย้าย $50 จาก Bank ไปยัง Bob
- Transaction 3 ย้าย $20 จาก Alice ไปยัง Bob
- ในการแสดงแบบนี้ ยอดคงเหลือของ Alice เป็น $80 และยอดคงเหลือของ Bob เป็น $70
ตัวเลือกการสร้างโมเดลโดยแบ่งธุรกรรมที่ซับซ้อน
- หากใส่ทั้งค่าธรรมเนียมและภาษีไว้ในธุรกรรมเดียวทั้งหมด เส้นเชื่อมของ Transaction 3 จะมีจำนวนมากและซับซ้อนขึ้น
- สามารถแบ่งการไหลของเงินเดียวกันออกเป็นธุรกรรมที่เล็กลงได้ด้วย
- เงิน $22 ออกจากบัญชีของ Alice
- Bob ได้รับ $19
- ส่วนที่เหลือ $3 ไปยังบริษัทบัตรเครดิต
- ภาษีขาย $2 ของ Bob ถูกจัดการเป็น Transaction 4 แยกต่างหาก
- ไม่ว่าจะจัดกลุ่มธุรกรรมและรายการอย่างไร ยอดคงเหลือสุดท้ายของบัญชีอาจเท่ากันได้
- Alice: $78
- Bob: $67
- หน่วยงานภาษี: $2
- บริษัทบัตรเครดิต: $3
- ระบบบัญชีมีความยืดหยุ่นพอรองรับความต้องการหลากหลาย และควรกำหนดวิธีจัดกลุ่มธุรกรรมกับรายการให้เหมาะกับธุรกิจ
งบการเงินคือการทำให้กราฟมองเห็นได้
- กราฟจะเติบโตขึ้นตามเวลาเมื่อมีธุรกรรมใหม่เพิ่มเข้ามา
- คุณสมบัติพื้นฐานของกราฟยังคงอยู่เสมอ
- บัญชียังคงเป็นโหนด
- ธุรกรรมยังคงเป็นโหนดที่บังคับการไหลของเงิน
- ในแต่ละธุรกรรม ผลรวมจำนวนเงินที่ออกและผลรวมจำนวนเงินที่เข้าต้องเท่ากัน
- Balance sheet, income statement, cash flow statement สามารถมองได้ว่าเป็นการทำให้กราฟนี้มองเห็นได้
- การจัดประเภท เช่น assets, liabilities, equity, income, expenses สามารถมองเป็น กลุ่มโหนด ภายในกราฟได้
- เมื่อมองจากมุมของกราฟ จะเข้าใจได้อย่างเป็นธรรมชาติมากขึ้นว่า credit และ debit ทำให้ยอดคงเหลือของแต่ละประเภทเพิ่มหรือลดอย่างไร
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
การอธิบาย การทำบัญชีคู่ ว่าเป็น “รายการหนึ่งของ Alice และอีกรายการหนึ่งของ Bob” ดูเป็นการเลือกที่แปลก
ถ้ามีคู่สัญญาสองฝ่าย การบันทึกไว้สองที่ก็เป็นเรื่องแน่นอนอยู่แล้ว แต่ประเด็นสำคัญคือแต่ละฝ่ายของธุรกรรมต้องมีสองรายการ หาก Alice ซื้อหนังสือจาก Bob ก็จะเกิดรายการขึ้นสี่รายการ
เข้าใจว่าเป็นการทำให้ง่ายเพื่อการสอน แต่ผมมองว่าเป็นการทำให้ง่ายเกินไปจนตัดแก่นสำคัญออกไป
เช่น เมื่อจ่ายเจ้าหนี้การค้าด้วยเงินสด ก็เหมือนส่งข้อความพร้อมกันไปยังตัวละคร Accounts Payable และตัวละคร Cash โดยแต่ละตัวจะแปลเหตุการณ์นั้นเป็นเดบิต/เครดิตตามลักษณะของตนเองเพื่อรักษายอดคงเหลือไว้ จากมุมมองนี้ การทำบัญชีคู่ใกล้เคียงกับความหมายว่าแต่ละเหตุการณ์ต้องถูกดูดซับโดยตัวละครจำนวนคู่ อย่างละหนึ่งครั้งพอดี
หากกำลังสร้าง payment rails ตัวเหตุการณ์นั้นเองก็อาจเป็นหนึ่งในเหตุการณ์คู่หนึ่งที่สืบทอดมาจาก meta-event สำหรับติดตามเจตนาของธุรกรรม ในทางบัญชี การมอง edge ของกราฟว่าไม่ใช่เงิน แต่เป็นข้อมูลในลำดับชั้นของเหตุการณ์ที่สืบทอดกันมา น่าจะมีประโยชน์กว่า
อย่างไรก็ตาม ต้นฉบับไม่ได้ทำให้ชัดว่าอุปมานี้มีไว้เพื่ออะไร และกังวลว่าจะเพิ่มความสับสนมากกว่าลดลง
ผมไม่สนใจสมุดบัญชีของ Bob แต่อยากติดตามแค่สมุดของตัวเอง ถ้าผมซื้อหนังสือ ผมอยากรู้ว่าธุรกรรมนี้ควรถูกบันทึกในสมุดบัญชีของผมแบบบัญชีคู่อย่างไร
อีกอย่าง Bob ไม่ได้กำลังทำบัญชี เขากำลังขายหนังสืออยู่ ;-)
ถ้าจะแก้บทความนี้เพื่ออธิบายส่วน “double” ให้ถูกต้อง ควรทำอย่างไร? จะทำได้ไหมโดยใช้มุมมองของ Bob หรือ Alice เพียงฝ่ายเดียว?
เช่น ธนาคารอาจประเมินว่าผมน่าจะชำระหนี้ไม่ได้ จึงลดมูลค่าในสมุดบัญชีของธนาคารให้เป็น 0 ได้ ส่วนผมยังตั้งใจจะชำระหนี้ จึงยังคงบันทึกหนี้สินไว้ในสมุดบัญชีของผม ธนาคารสร้างรายการที่เกี่ยวข้องในระบบของตนเองและเดบิต/เครดิตก็สมดุลกัน ส่วนผมไม่ต้องทำอะไรเลย สมุดบัญชีของผมก็ยังคงสมดุลอยู่
การทำบัญชีคู่ ไม่เกี่ยวกับอีกฝ่ายหนึ่ง แต่เกี่ยวกับสมุดบัญชีของตัวเองเท่านั้น
ผมคิดว่าความงดงามและอิทธิพลของบัญชียังถูกประเมินต่ำเกินไป
ด้วยสูตรจำนวนน้อยมาก นั่นคือ สมการบัญชี และงบการเงินอย่างงบกำไรขาดทุนกับงบแสดงฐานะการเงิน เราสามารถแสดงสิ่งที่เกิดขึ้นในองค์กรใด ๆ ได้ในลักษณะที่พอจะเปรียบเทียบกันได้ ให้ความรู้สึกคล้ายทฤษฎีบทมูลฐานของแคลคูลัสหรือ central dogma ของชีววิทยา
บัญชียังเป็นต้นกำเนิดของทั้งคณิตศาสตร์และภาษาเขียนด้วย อารยธรรมเมโสโปเตเมียโบราณแรกเริ่มใช้ “โทเค็นบัญชี” ที่เลียนแบบรูปร่างของสิ่งของเพื่อติดตามสินค้า และอาจมองได้ว่าสิ่งนั้นพัฒนาไปเป็นภาษาเขียน เช่น อักษรภาพ
ต่อมา Al-Khwarizmi สร้าง Al-Jabr หรือ algebra เพื่อแก้ปัญหากฎหมายมรดกอิสลาม และเมื่อกฎการแบ่งมรดกกลายเป็นสมการ จึงเกิดความจำเป็นต้องแก้ให้ได้รวดเร็วและแม่นยำ วิธีแก้สมการกำลังสองของ Al-Khwarizmi กลายเป็นที่มาของชื่อ “algorithm”
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
จำนวนลบ ถูกใช้ครั้งแรกในจีนราวศตวรรษที่ 3 และในยุโรปก็ยังไม่แพร่หลายจนถึงศตวรรษที่ 16 การทำบัญชีคู่สมัยใหม่เกิดขึ้นในยุโรปศตวรรษที่ 14
ดังนั้นวิธีดั้งเดิมที่แยกคอลัมน์เดบิตกับเครดิต และมีนิยามที่ดูแปลกอยู่บ้าง จึงเป็นวิธีที่ดีที่สุดในการทำให้ระบบทำงานได้โดยใช้แต่จำนวนบวกเท่านั้น
แง่มุมสำคัญหลายอย่างของการออกแบบองค์กรมีความสัมพันธ์กับงบการเงินเพียงหลวม ๆ เท่านั้น
หลังจากการทำบัญชีหยั่งรากลงในทุกระดับของสังคมแล้ว จำนวนลบจึงถูกยอมรับว่าเป็นสิ่งที่เป็นจริงได้พอ ๆ กับจำนวนบวก
การบัญชีแบบลงบัญชีคู่จะเข้าใจง่ายมากถ้าตัดคำศัพท์ “credit” และ “debit” ที่ชวนตลกออกไป
แก่นสำคัญคือการทำให้ สมการบัญชี เป็นจริงอยู่เสมอ สูตรพื้นฐานคือ Equity = Assets - Liabilities และกำไรสุดท้ายก็เข้าไปอยู่ในส่วนของเจ้าของ ดังนั้นจึงกลายเป็น Equity + Income - Expenses = Assets - Liabilities เมื่่อจัดรูปเพื่อกำจัดค่าติดลบ จะได้ Equity + Income + Liabilities = Assets + Expenses
สมการนี้ต้องเป็นจริงเสมอ มิฉะนั้นก็เท่ากับว่าเงินเกิดขึ้นหรือหายไปจากที่ไหนก็ไม่รู้ ดังนั้นถ้าเพิ่มเงินในบัญชีฝั่งซ้ายของสมการ ก็ต้องเพิ่มจำนวนเท่ากันในบัญชีฝั่งตรงข้าม หรือหักจำนวนเท่ากันออกจากฝั่งเดียวกัน
ตัวอย่างเช่น ถ้าขายน้ำมะนาวได้ 5 ดอลลาร์ ก็เพิ่ม 5 ดอลลาร์ใน Sales(Income) และเพิ่ม 5 ดอลลาร์ใน Current Account(Assets) ด้วย
เหตุผลที่ “credit” และ “debit” ชวนตลกก็เพราะคำจำกัดความของมันสลับไปมาตามประเภทบัญชี และการใช้ภาษาที่ไร้เหตุผลแบบนี้คือสาเหตุหลักที่ทำให้ผู้คนสับสน
อาจารย์คอร์สบัญชีระดับ 100 พูดไว้ค่อนข้างกระชับว่า Debit คือรายการในคอลัมน์ซ้าย และ Credit คือรายการในคอลัมน์ขวา ส่วนธุรกรรมนั้นมีความหมายอย่างไรต่อธุรกิจขึ้นอยู่กับบัญชีนั้น ๆ
สำหรับคนที่ไม่เคยเรียนบัญชี การใช้คำเหล่านี้ทำให้สับสนอย่างมาก และคำตอบหลาย ๆ อันที่ตอบคนที่กำลังงงอยู่ ถึงจะถูกทางเทคนิค แต่ก็ไม่ได้ช่วยอะไรนัก เพราะตั้งสมมติฐานไว้แล้วว่าผู้อ่านรู้คำศัพท์อยู่ก่อน
คำถามอย่าง “ยอดคงเหลือเพิ่มขึ้น แล้วทำไมบัญชีธนาคารถึงถูก debited? debit ไม่ใช่ค่าติดลบเหรอ? ยอดเงินสดจะแสดงเป็นค่าติดลบหรือเปล่า?” เป็นคำถามที่ดีจริง ๆ ตามสัญชาตญาณแล้ว direct debit คือเงินไหลออก ใช้จ่ายเงินด้วย debit card และคำว่า debit ก็ฟังคล้าย debt จึงทำให้คิดว่า debit ต้องเป็นค่าติดลบเสมอ
ภาพที่คนใช้คำเดียวกันแต่เหมือนพูดกันคนละภาษาเป็นเรื่องน่าสนุกแต่ก็น่าหงุดหงิด บางทีก็ไหลไปเป็นการจับผิดถ้อยคำเล็ก ๆ เพื่อแสดงว่าตัวเองถูก
เพราะจากมุมมองของคนที่จ่าย 5 ดอลลาร์ซื้อน้ำมะนาว เขาไม่ได้ใส่ 5 ดอลลาร์ลงในรายการ Sales ของตัวเองเลย ผมยังไม่เข้าใจอย่างสมบูรณ์ว่าความสับสนที่บทความนี้และคอมเมนต์พูดถึงคืออะไรกันแน่
credit หมายถึงแหล่งที่มา, debit หมายถึงปลายทาง
ถ้าเรียกเก็บเงินลูกค้า 10,000 ยูโร ก็จะเกิดคำมั่นสัญญามูลค่า 11,000 ดอลลาร์ตามอัตราแลกเปลี่ยนปัจจุบัน จากนั้นก็ credit บัญชี “Income: Customer A” ซึ่งเป็นแหล่งที่มา 11,000 ดอลลาร์ และ debit “Assets: Accounts Receivable” 11,000 ดอลลาร์
ต่อมาลูกค้าจ่ายเงิน แต่ค่าเงินเปลี่ยนไปจนได้รับเพียง 10,500 ดอลลาร์ เมื่อคำมั่นสัญญาที่บันทึกไว้เดิม 11,000 ดอลลาร์เป็นแหล่งที่มา ก็ credit Accounts Receivable 11,000 ดอลลาร์ รับเงินสดมา 10,500 ดอลลาร์จึง debit cash 10,500 ดอลลาร์ และเพื่อให้เดบิตกับเครดิตสมดุลกัน ก็ debit “Expenses: Loss on Foreign Exchange” 500 ดอลลาร์
โดยปกติบริษัทไม่ได้ชำระบัญชีเลิกกิจการทุกวันทำการ แล้วจะพยายามยัด 500 ดอลลาร์นั้นเข้าไปในสถานการณ์ชำระบัญชีทันทีแบบสมมติไปทำไม แค่บันทึกให้ credit กับ debit สมดุลกันก็พอ
มีกราฟจำนวนมากเกินไปที่เอาตัวแปรอิสระไว้บนแกน Y
“Credit คือรายการที่เงินออกจากบัญชี ส่วน Debit คือรายการที่เงินเข้าบัญชี” ไม่ถูกต้อง
ความหมายของ debit และ credit เปลี่ยนไปตามประเภทบัญชี: https://en.wikipedia.org/wiki/Debits_and_credits
อาจมีเหตุผลที่การจะเป็น CPA ต้องเรียนมากกว่าหนึ่งวิชา: https://www.accounting.com/careers/cpa/how-to-become/
ในมุมมองของผม มันดูเหมือนวิธีเพิ่มงานเป็นสองเท่าเพื่อจับข้อผิดพลาดบางอย่างในยุคที่คนเป็นผู้ป้อนรายการและคำนวณเอง ซึ่งตัวมันเองก็พอมีเหตุผล
แต่เพราะผมโตมาในโลกที่คอมพิวเตอร์ทำการคำนวณทั้งหมด มันจึงดูเหมือนละเมิดหลักการที่ว่าอย่าทำเรื่องเดียวกันซ้ำ ถ้าเขียนสิ่งเดียวกันไว้สองที่ สุดท้ายที่ใดที่หนึ่งก็ต้องผิด
ถ้าการบัญชีถูกออกแบบขึ้นในยุคปัจจุบัน ผมไม่คิดว่าจะทำแบบนี้ การที่ผมไม่ใช่นักบัญชีและไม่เข้าใจ ไม่ได้หมายความว่าระบบผิด แต่ความสับสนที่รู้สึกเมื่อได้ยินว่า “credit ทำให้บัญชีสินทรัพย์ลดลง” เหมือนเป็นสัญญาณว่ามีบางอย่างผิดที่ผิดทางในระดับพื้นฐาน
รายการ CR คือสิ่งที่บริษัทเป็นหนี้อยู่ หรือภาระต่อเจ้าหนี้หรือผู้ถือหุ้นที่เพิ่มขึ้น และ รายการ DR คือสิ่งที่บริษัทมีอยู่เพิ่มขึ้น
ความสัมพันธ์กับสมการบัญชีดูได้ที่นี่: https://news.ycombinator.com/item?id=32501707
ดูเหมือนมีความสับสนกันมากเกี่ยวกับคำว่า credit/debit
ถ้าจะคิดให้เรียบง่ายขึ้นในมุมมองสมัยใหม่ แค่นึกไว้ว่าการบัญชีมีมาก่อน การใช้จำนวนลบอย่างแพร่หลาย นานมาก ถ้าบัญชีถูกคิดค้นขึ้นวันนี้ ก็น่าจะใช้บัญชีบวก/ลบแทนบัญชี debit/credit มากกว่า
พีชคณิตบนการบวกดูเป็นเรื่องธรรมชาติสำหรับเราในตอนนี้ แต่สำหรับพ่อค้าทั่วไปในปี 1604 มันไม่ใช่เรื่องแน่นอน และจำนวนลบก็ยังไม่ได้รับการยอมรับเท่าไรนัก
สิ่งสำคัญคือธุรกรรมมีสองด้านเสมอ และเป็นการดำเนินการผกผันกัน credit กับ debit สุดท้ายแล้วก็คือการดำเนินการผกผันต่อจำนวน
ดังนั้นจึงตั้งกฎได้ว่าเมื่อ credit = debit ธุรกรรมนั้นสมดุล ในแบบสมัยใหม่อาจมองได้ว่า debit + credit = 0 แต่ตอนที่ระบบนี้ถูกสร้างขึ้น ผู้คนไม่ชอบจำนวนลบ ดังนั้นนี่จึงใกล้เคียงกับเรื่องบังเอิญที่น่ายินดีซึ่งเป็นจริงเสมอ มากกว่าจะเป็นเป้าหมายตั้งแต่แรก
ถ้ามองเงินสดในมือเป็นบัญชีที่มีลักษณะเป็นบวกมากที่สุด หรือเป็นฝั่ง debit แล้วคิดย้อนกลับ ก็สมเหตุสมผลดี เมื่อต้องบันทึกค่าใช้จ่าย ต้องบันทึกบัญชีเงินสดในทิศตรงข้ามจึงเป็น credit และที่ที่เงินไหลไปก็ลงเป็นรายการตรงข้ามคือ debit ดังนั้นบัญชีค่าใช้จ่ายจึงมักมียอดคงเหลือฝั่ง debit
แล้วเงินสดมาจากไหน? มาจากรายได้ และถ้าต้องการให้เงินสดมีลักษณะเป็น debit แหล่งที่มาก็ต้องมีลักษณะเป็น credit เพื่อไม่ให้ธุรกรรมเสียสมดุล ดังนั้นบัญชีรายได้จึงมักเป็นบัญชี credit กล่าวคือโดยทั่วไปมียอดคงเหลือติดลบ หรือเป็น “credit normal”
จุดที่ยอดเยี่ยมของระบบนี้คือ ธุรกรรมในชีวิตประจำวันทั้งหมดสรุปลงเป็นธุรกรรมที่สมดุล และบัญชีที่เป็นไปได้แต่ละประเภทก็มีลักษณะยอดคงเหลือที่สอดคล้องกันว่าโดยปกติเป็น credit หรือ debit สง่างามจริง ๆ
แค่จำสิ่งนั้นกับสมการบัญชีได้ ก็อนุมานยอดคงเหลือปกติของบัญชีประเภทอื่นทั้งหมดได้
ประมาณเดือนก่อน ผมเริ่มคุยใน PTA subreddit เรื่องการทำให้ไวยากรณ์ของ PTA เข้าใจง่ายขึ้น มีคนเสนอให้ใช้ลูกศรแสดง “from” คือบัญชี credit/ลบ และ “to” คือบัญชี debit/บวก ตัวเลขไม่มีเครื่องหมาย และไม่ใช้คำว่า “credit” กับ “debit” เลย จึงรู้สึกเข้าใจง่ายกว่ามาก
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
เบื้องหลังเกี่ยวกับจำนวนลบน่าสนใจดี
ยังซับซ้อนเกินไปอยู่ดี เริ่มผิดทางตั้งแต่ “เพิ่มคอลัมน์ Transaction ลงในตาราง” แล้ว
ไม่ควรเก็บ ข้อมูลบัญชี แต่ควรเก็บ ธุรกรรม บัญชีค่อยคำนวณจากตรงนั้น ตาราง “Transactions” ควรมีฟิลด์ Date, Amount, SourceAccount, TargetAccount, Description ก็พอ
ในมุมมองของผม ตรงนี้แหละที่มันสวยงาม ต้องเลิกนิสัยคิดแบบยึดบัญชีเป็นศูนย์กลางเพียงเพราะคุ้นกับรายการเดินบัญชีธนาคาร แล้วคิดแบบกระแสเงินสดแทน
แน่นอนว่าสำหรับงานภาษีมันเรียบง่ายเกินไป เพราะบางครั้งธุรกรรมมีหลายแหล่งที่มาหรือหลายปลายทาง สคีมาข้างต้นจึงต้องปรับ แต่ประเด็นคือวิธีคิดควรต้องต่างออกไป
มันเป็นสัญญาณว่าโปรแกรมเมอร์พยายามฉลาดเกินไป โดยรักษา ผลรวมสะสม แทนที่จะคำนวณจากธุรกรรมต้นทาง ตรงนั้นมีมังกรอยู่
การออกแบบที่ดีกว่าคือมีตารางหัวรายการและตารางรายละเอียด
Header: TransactionID, Date, Description, ฟิลด์ที่จำเป็นอย่าง posting status หรือ reconciliation status
Detail: TransactionID, LineNumber, Account, Amount, Description, ฟิลด์ที่จำเป็นอย่างหมายเลขอ้างอิง subledger
แบบนี้ธุรกรรมหนึ่งรายการสามารถส่งผลต่อบัญชีจำนวนเท่าใดก็ได้ สุดท้ายธุรกรรมก็จะสะท้อนธุรกรรมทางธุรกิจที่อาจกระทบหลายบัญชี
ในรายละเอียดจะซับซ้อนกว่านั้นเล็กน้อย เช่น เอาต์พุตของแต่ละการโอนต้องมีที่อยู่ต้นทางรวมอยู่ด้วย แต่แนวคิดเหมือนกัน อย่างที่พูดไว้ที่อื่นในเธรดนี้ ธุรกรรมแต่ละรายการต้องมีอินพุตหลายรายการและเอาต์พุตหลายรายการ
มีธุรกรรมทั้งหมดอยู่ในไฟล์ข้อความล้วน และเมื่อจำเป็นต้องประเมิน ก็สร้างสมุดบัญชีทั้งหมดขึ้นมาทันทีจากข้อมูลนั้น
ผมไม่ใช่นักบัญชี แต่เมื่อก่อนเคยตั้งใจศึกษาบัญชีคู่และการบัญชีพื้นฐาน และได้เรียนรู้จากหลายที่ รวมถึงเธรดดี ๆ บน HN
บทความนี้อธิบายว่า บัญชีคู่ทำงานอย่างไร และกระบวนการที่ทำให้ตระหนักว่ามันคือ กราฟมีทิศทาง บน HN มีคนคลั่งบัญชีอยู่เยอะ ถ้ามีส่วนไหนผิดก็ขอให้ช่วยวิจารณ์หรือเสนอแก้ไขด้วย
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
อยากให้ controllers ของผมทำผลประกอบการฝ่ายขายให้ออกมาเป็น กระแสแบบกราฟิก แบบนี้ เมื่อถึงขนาดหนึ่ง การบัญชีจะค่อนข้างยาก และถึงขั้นต้องมีคนระดับอาจารย์ในทีม accounting policy
สิ่งที่ได้เรียนจากสถิติคือกราฟิกสำคัญมาก หากใช้นามธรรมที่เหมาะสม ตัวเลขใด ๆ ก็สามารถแสดงเป็นกราฟขององค์ประกอบต่าง ๆ ได้ ชั่วขณะนั้นเหมือนความเข้าใจเปิดโล่งขึ้นทันที
ฝั่งหนึ่งคือเงินที่เข้าหรือออก อีกฝั่งคือสินค้าหรือบริการ นี่คือการบันทึกบัญชีแบบคู่ของการบัญชี มันอาจดูชัดเจนและเรียบง่าย แต่ในสายงานของผมมีคนไม่มากที่เข้าใจสิ่งนี้
เป็นบทความที่เขียนดี แต่เวลานิยามคำศัพท์ที่มีความหมายซึ่งเป็นที่ยอมรับโดยทั่วไปใหม่ ควรระมัดระวัง
การเปลี่ยน Debit/Credit เป็น Incoming/Outgoing ดูเหมือน ศัพท์เฉพาะ อีกชุดหนึ่ง และอาจทำให้สับสนได้ bookkeeper คนไหนก็เข้าใจว่า credit cash และ debit expense คืออะไร
การเปลี่ยนเป็น incoming/outgoing ไม่ได้ช่วยคนที่ทำงานจริงหรือคนที่ต้องอธิบายงานนั้น การเรียนรู้ระบบชื่อเรียกที่มีประโยชน์มาหลายร้อยปีมีคุณค่ากว่าการพึ่งพาอุปมา
ทุกครั้งที่มีการถกเถียงแบบนี้บน HN มักจะมีใครสักคนพูดว่า “มันง่ายมาก credit ก็แค่…” แล้วก็จะมีคำตอบตามมาทันทีว่า “เข้าใจกลับด้านแล้ว มันง่ายมาก credit คือ…”
สำหรับผม ทิ้งคำเหล่านั้นไปตลอดกาลก็ไม่เป็นไรเลย
เวลามีเงินถูก credited หรือใช้ credit card จะรู้สึกดีเหมือนมีเงินโผล่มาจากที่ไหนสักแห่ง ส่วน debit ฟังเหมือน debt และทำให้รู้สึกไม่ดีเหมือนเงินของตัวเองลดลง
จริง ๆ แล้วผมรู้ว่าชื่อเหล่านั้นมีเหตุผล แต่ถ้าวงการหนึ่งยืนกรานใช้ศัพท์เฉพาะที่ไม่สอดคล้องกับสัญชาตญาณและขัดกับทุกการใช้งานที่คนนอกเคยพบ ก็น่าจะใช้ถ้อยคำอื่นที่ซ้ำซ้อนน้อยกว่าได้
ถ้าพูดคุยโดยใช้ศัพท์เฉพาะที่ถูกต้องได้อย่างเหมาะสม ความน่าเชื่อถือจะเพิ่มขึ้นมาก
ผมไม่ค่อยเข้าใจว่าการอธิบาย debit/credit ซึ่งเป็นศัพท์บัญชีด้วยภาษาของคนทั่วไป ทำไมถึงดูเหมือนศัพท์เฉพาะ อาจเป็นเพราะผมเป็นคนทั่วไปก็ได้
การอธิบาย credit/debt ให้คนที่ไม่มีพื้นฐานบัญชีว่า “เงินเข้า, เงินออก” ในบริบทของบทความนี้ดูโอเคพอแล้ว นิยาม “จริง ๆ” ของ credit/debit ทำงานต่างออกไปอย่างมีนัยสำคัญตรงไหนหรือ?
David P. Ellerman เสนอแนวทางเชิงคณิตศาสตร์ต่อการบัญชี โดยอิงกับสิ่งที่เขาเรียกว่า Pacioli group
องค์ประกอบชั่วคราวของ Pacioli group มีรูปแบบเหมือน x//y โดย x และ y เป็นจำนวนเต็มไม่ลบ x//y และ u//v ถือว่าเทียบเท่ากัน หากผลบวกไขว้ x+v และ y+u เท่ากัน
การดำเนินการของกรุ๊ปคือ x//y + u//v = (x+u)//(y+v) อินเวอร์สของ x//y คือ y//x และเอกลักษณ์คือ 0//0 รายละเอียดเพิ่มเติมดูได้เช่นเอกสารนี้: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
เหมือนผมกำลังพลาดอะไรบางอย่างตรงนี้ การมองประวัติธุรกรรมเป็น กราฟมีทิศทาง ช่วยอะไรได้?
มันมีอะไรที่ดีขึ้นกว่าการปฏิบัติแบบบัญชีคู่ที่มีมาหลายร้อยปีหรือ?
ในตัวอย่างของเล่นที่มีธุรกรรมไม่กี่รายการ ดูเหมือนจะพอทำงานได้ แต่ลองจินตนาการว่ากราฟจะหน้าตาอย่างไรเมื่อมีเส้นเชื่อมหลายสิบหรือหลายร้อยเส้นระหว่างคู่โหนด การจะเอาอัลกอริทึมกราฟทั่วไปไปใช้ตรงไหนก็ยังไม่เห็น
ให้ความรู้สึกเหมือนใช้คีมแทนค้อน แน่นอนว่าทำได้ แต่ทำไปทำไม?
อย่างแรก มันเป็นอีกวิธีหนึ่งในการทำความเข้าใจแนวคิด ส่วนใหญ่แล้วอาจไม่เกี่ยวข้อง แต่ใครจะรู้ว่าปัญหาบัญชียาก ๆ อาจแก้ได้ด้วยการประยุกต์ใช้ทฤษฎีกราฟ หรือในทางกลับกัน ปัญหาทฤษฎีกราฟอาจถูกแก้ได้จากการบัญชี
อย่างที่สอง มันเป็นอีกวิธีหนึ่งในการทำให้กระแสไหลเวียนมองเห็นได้ ไม่ใช่ทุกคนจะมีความรู้ทางการเงินหรือเซนส์ด้านตัวเลขดี ดังนั้นแทนที่จะให้ตารางที่มีคอลัมน์ตัวเลขแล้วให้อนุมานกระแสจากตัวเลข ก็สามารถแสดงเชิงพื้นที่ได้ ไม่ใช่ทุกเครื่องมือมีไว้สำหรับผู้เชี่ยวชาญเท่านั้น
การมองประวัติสะสมทั้งหมดเป็นกราฟเดียวอาจมากเกินไป แต่แค่เพิ่มตัวกรองวันที่ธุรกรรม ก็อาจให้ข้อมูลเชิงลึกที่ visualization แบบอื่นพลาดไปได้ หาก cross-reference กับข้อมูลอื่นอย่างตำแหน่งที่ตั้ง ก็อาจยิ่งมีประโยชน์ขึ้น
ผู้เขียนสร้างความชอบธรรมไม่ได้ และคำกล่าวของผู้เขียนที่ว่า visualization นี้ช่วยให้เข้าใจชัดขึ้นก็อ่อนลง เพราะ category error ที่ปรากฏในกระบวนการอธิบายบัญชีคู่แบบ geek ตั้งแต่ต้น
แถมยังแสดงแค่ธุรกรรมที่เรียบง่ายมากรายการเดียว ผมไม่รู้ว่าจะใช้ visualization แบบกราฟเพื่อดึงสิ่งที่เป็นนามธรรมกว่านี้อย่างไร เช่น กรณีค่าเสื่อมราคาทางภาษีกับค่าเสื่อมราคาทางบัญชีต่างกัน การปรับกำไรขาดทุนจากอัตราแลกเปลี่ยน การจัดสรร franked dividends, PAYG, เงินที่ถือไว้แทนผู้อื่น หรือการรับรู้รายได้รอตัดบัญชีบางส่วน
เป็นลักษณะที่วิศวกรค้นพบหลักการพื้นฐานซึ่งมีอยู่แล้วในสาขาอื่นอย่างล่าช้า เมื่อซอฟต์แวร์เริ่มจำลองสาขานั้นขึ้นมา