TFRS 15 คืออะไร รายได้จากสัญญาที่ทำกับลูกค้า กระทบ Odoo ERP อย่างไร

TFRS 15 เป็นมาตรฐานที่เปลี่ยนวิธีรับรู้รายได้ของบริษัทจดทะเบียนไทยทั้งหมด จากเดิมที่บันทึกรายได้ตอนส่งมอบสินค้าหรือออก Invoice ได้เลย มาเป็นการวิเคราะห์สัญญาทุกฉบับผ่าน 5 ขั้นตอนก่อนว่า "จะรับรู้รายได้เท่าไหร่ เมื่อไหร่" ซึ่งส่งผลโดยตรงต่อการ Setup ระบบ Odoo ERP โดยเฉพาะบริษัทที่กำลังเตรียมเข้าตลาดหลักทรัพย์

บทความนี้จะอธิบาย TFRS 15 แบบเข้าใจง่าย พร้อมตัวอย่างจากธุรกิจจริงหลายประเภท และชี้ให้เห็นว่า Odoo มี Feature อะไรรองรับได้แล้ว ส่วนไหนต้อง Customize เพิ่ม อ้างอิงจาก สภาวิชาชีพบัญชี ในพระบรมราชูปถัมภ์ และรายงานการตรวจคุณภาพงานสอบบัญชีของ สำนักงาน กลต.

TFRS 15 คืออะไร

TFRS 15 คือ มาตรฐานการรายงานทางการเงิน ฉบับที่ 15 เรื่อง รายได้จากสัญญาที่ทำกับลูกค้า ออกตามประกาศสภาวิชาชีพบัญชี ที่ 46/2562 ประกาศในราชกิจจานุเบกษาเมื่อวันที่ 24 กันยายน 2562 แปลจาก IFRS 15 (Bound Volume 2020) ที่ออกโดย IASB

มาตรฐานนี้ บังคับใช้กับ PAEs (กิจการที่มีส่วนได้เสียสาธารณะ) ตั้งแต่วันที่ 1 มกราคม 2562 เป็นต้นไป ซึ่งรวมถึงบริษัทจดทะเบียนใน SET/mai สถาบันการเงิน และบริษัทที่อยู่ระหว่างยื่น Filing

TFRS 15 เกิดขึ้นเพราะมาตรฐานเดิมที่เกี่ยวกับรายได้มีหลายฉบับ เช่น TAS 18 เรื่องรายได้ และ TAS 11 เรื่องสัญญาก่อสร้าง ทำให้รายการที่คล้ายกันอาจรับรู้รายได้แตกต่างกัน TFRS 15 จึงรวมทุกอย่างมาไว้ในฉบับเดียว ใช้หลักเกณฑ์เดียวกันกับทุกประเภทธุรกิจ

Five-Step Model หลักการรับรู้รายได้ 5 ขั้นตอน

หัวใจของ TFRS 15 คือ Five-Step Model ซึ่งกำหนดว่ากิจการจะรับรู้รายได้อย่างไร จำนวนเท่าไหร่ และเมื่อใด โดยทุกสัญญาที่ทำกับลูกค้าต้องผ่านการวิเคราะห์ 5 ขั้นตอนนี้

ขั้นตอนที่ 1 ระบุสัญญาที่ทำกับลูกค้า

สัญญาจะอยู่ในขอบเขตของ TFRS 15 เมื่อมีผลบังคับใช้ตามกฎหมาย โดยสัญญาอาจจัดทำเป็นลายลักษณ์อักษร ด้วยวาจา หรือตามประเพณีทางธุรกิจก็ได้ เงื่อนไขสำคัญคือทั้งสองฝ่ายต้องอนุมัติสัญญา สามารถระบุสิทธิ์และภาระผูกพัน เงื่อนไขการชำระเงินได้ชัดเจน และมีความเป็นไปได้สูงที่จะเก็บเงินได้

ใน Odoo — Sale Order คือจุดเริ่มต้นของสัญญา ระบบต้อง Config ให้ SO สะท้อนเงื่อนไขสัญญาครบ รวมถึง Payment Terms, Delivery Terms และ Service Period

ขั้นตอนที่ 2 ระบุ Performance Obligation ในสัญญา

Performance Obligation คือภาระที่ต้องปฏิบัติ หมายถึงข้อตกลงในสัญญาที่จะโอนสินค้าหรือบริการที่แตกต่างกัน (Distinct) ให้ลูกค้า สินค้าหรือบริการจะถือว่า Distinct เมื่อลูกค้าได้รับประโยชน์จากสิ่งนั้นได้ด้วยตัวเอง หรือใช้ร่วมกับทรัพยากรที่มีอยู่แล้ว และข้อตกลงนั้นแยกจากข้อตกลงอื่นในสัญญาได้

ตัวอย่าง — บริษัทขายเครื่องจักรพร้อมติดตั้งพร้อม Warranty 2 ปี ถ้าลูกค้าสามารถหาคนอื่นมาติดตั้งได้ แปลว่า "เครื่องจักร" กับ "บริการติดตั้ง" เป็น Distinct แยกกัน = 2 Performance Obligations แต่ถ้าเครื่องจักรต้องติดตั้งเฉพาะทางที่ผู้ขายเท่านั้นทำได้ อาจรวมเป็น 1 Performance Obligation

ใน Odoo — ต้อง Config Product/Service ให้แยกตาม Performance Obligation แต่ละตัว ไม่ใช่ขายเป็น Bundle เดียวแล้วรับรู้รายได้ทีเดียว

ขั้นตอนที่ 3 กำหนดราคาของรายการ (Transaction Price)

Transaction Price คือจำนวนเงินที่กิจการคาดว่าจะมีสิทธิ์ได้รับจากลูกค้า ซึ่งอาจไม่เท่ากับราคาที่ระบุในสัญญาเสมอไป เพราะต้องพิจารณาส่วนลด Variable Consideration (เช่น ส่วนลดปริมาณ โบนัส เบี้ยปรับ สิทธิ์คืนสินค้า), Significant Financing Component (ถ้ามีดอกเบี้ยซ่อนอยู่), และ Non-cash Consideration

ใน Odoo — Price List และ Discount ใน Sale Order ต้อง Config ให้สะท้อน Transaction Price ที่แท้จริง ไม่ใช่แค่ราคาหน้า Catalog

ขั้นตอนที่ 4 ปันส่วนราคาให้กับ Performance Obligation

ถ้าสัญญามีหลาย Performance Obligation ต้องแบ่ง Transaction Price ให้แต่ละ Obligation ตามสัดส่วน Standalone Selling Price (ราคาขายแบบเอกเทศ) คือราคาที่จะขายสินค้าหรือบริการนั้นแยกต่างหาก

ตัวอย่างการปันส่วนราคาตาม TFRS 15

บริษัทขายรถยนต์ราคา 10,000,000 บาท พร้อมบริการดูแลรักษา 4 ปี ราคาขายแยกของรถคือ 9,000,000 บาท ค่าบริการดูแลรักษาแยกคือ 1,000,000 บาท ดังนั้นต้องปันส่วนรายได้ 9,000,000 บาทให้กับรถยนต์ (รับรู้ตอนส่งมอบ — Point in Time) และ 1,000,000 บาทให้กับค่าบริการ (ทยอยรับรู้ 4 ปี — Over Time ปีละ 250,000 บาท)

ใน Odoo — ต้อง Setup Deferred Revenue สำหรับส่วนที่รับรู้แบบ Over Time และแยก Journal Entry ให้ถูกต้องระหว่าง Revenue ที่รับรู้แล้วกับ Deferred Revenue

ขั้นตอนที่ 5 รับรู้รายได้เมื่อปฏิบัติตาม Performance Obligation เสร็จสิ้น

รายได้จะรับรู้ได้ 2 แบบ

• Point in Time — รับรู้ ณ จุดเวลาที่โอนการควบคุมสินค้าให้ลูกค้า เช่น ส่งมอบสินค้า ลูกค้ารับของแล้ว
• Over Time — รับรู้ตลอดช่วงเวลาที่ให้บริการ เช่น สัญญาบำรุงรักษา สัญญาก่อสร้าง สัญญา SaaS

ใน Odoo — Product Type ต้อง Config ให้แยกระหว่าง Storable Product (มักเป็น Point in Time) กับ Service (มักเป็น Over Time) และ Revenue Recognition Schedule ต้องตรงกับรูปแบบการส่งมอบจริง

ธุรกิจไหนได้รับผลกระทบจาก TFRS 15 มากที่สุด

TFRS 15 กระทบทุกธุรกิจที่มีรายได้จากสัญญากับลูกค้า แต่ธุรกิจที่ได้รับผลกระทบรุนแรงที่สุดคือธุรกิจที่มีสัญญาซับซ้อน หลาย Performance Obligation หรือมี Variable Consideration สูง

• อสังหาริมทรัพย์ — ขายคอนโดพร้อมแถมเฟอร์นิเจอร์ ของแถมถือเป็น Performance Obligation ต้องแยกปันส่วนราคา จากเดิมที่ลงเป็น SG&A ต้องเปลี่ยนมาลงเป็นต้นทุนขาย
• โทรคมนาคม — ขายมือถือพร้อมแพ็กเกจรายเดือน 12 เดือน ต้องแยกราคามือถือกับค่าบริการ แล้วทยอยรับรู้ค่าบริการ
• ซอฟต์แวร์และ IT — ขาย License พร้อม Implementation พร้อม Support 1 ปี ต้องแยก 3 Performance Obligations
• เครื่องจักรและอุตสาหกรรม — ขายเครื่องจักรพร้อมติดตั้ง พร้อม Warranty พร้อม Training ต้องวิเคราะห์ว่าอะไร Distinct อะไรไม่ Distinct
• ก่อสร้าง — สัญญาก่อสร้างระยะยาว ต้องรับรู้รายได้แบบ Over Time ตาม Percentage of Completion

สำหรับ Dynamics Motion ที่ Implement Odoo ให้ลูกค้าหลากหลายอุตสาหกรรม จุดที่พบบ่อยคือลูกค้ามักมีสัญญาที่รวม Product + Service + Warranty ไว้ด้วยกัน ซึ่งระบบเดิมบันทึกเป็น Invoice เดียว รับรู้รายได้ทีเดียว พอต้องเปลี่ยนมาใช้ TFRS 15 ก็ต้อง Restructure วิธีบันทึกใน Odoo ใหม่ทั้งหมด

กลต. พบปัญหาอะไรจากการตรวจ TFRS 15

จากรายงานสรุปกิจกรรมการตรวจคุณภาพงานสอบบัญชีปี 2563 ของสำนักงาน กลต. ซึ่งตรวจทานกระดาษทำการของผู้สอบบัญชีในตลาดทุน 92 คน ครอบคลุมงานสอบบัญชี 104 งาน คิดเป็น 10% ของ Market Capitalization กลต. สรุปว่า ผู้สอบบัญชียังปฏิบัติงานและบันทึกข้อมูลการตรวจสอบบัญชีรายได้ตาม TFRS 15 ไม่เพียงพอ

ซึ่งหมายความว่า กลต. ให้ความสำคัญกับ TFRS 15 เป็นพิเศษ บริษัทที่กำลังจะเข้าตลาดต้องมั่นใจว่าระบบ ERP สามารถสร้าง Audit Evidence ได้ครบถ้วนสำหรับทุกขั้นตอนของ Five-Step Model ไม่ใช่แค่ตัวเลขถูก แต่ต้อง "พิสูจน์ได้" ว่าทำไมถึงรับรู้รายได้จำนวนนี้ ในเวลานี้

Odoo ERP รองรับ TFRS 15 ได้แค่ไหน

มาดูว่า Odoo Enterprise มี Feature อะไรที่ใช้ได้ทันที และส่วนไหนต้อง Config หรือ Develop เพิ่ม

Feature ที่ Odoo Enterprise มีในตัวแล้ว

• Deferred Revenue Management — ตั้ง Revenue Recognition Schedule ทยอยรับรู้รายได้ตาม Period ได้ เหมาะกับ Performance Obligation แบบ Over Time ที่ไม่ซับซ้อน เช่น ค่าบริการรายปี
• Multiple Product Lines ใน SO — Sale Order รองรับหลาย Product/Service ใน Order เดียว ซึ่งเป็นพื้นฐานของการแยก Performance Obligation
• Service Product Type — แยก Storable Product กับ Service ได้ ช่วยแบ่ง Point in Time กับ Over Time
• Analytic Accounts — ใช้ Track รายได้ตามสัญญา ตาม Project ตาม Performance Obligation แยกกันได้
• Timesheet & Project — สำหรับธุรกิจที่รับรู้รายได้แบบ Over Time ตาม Percentage of Completion ใช้ Timesheet เป็น Basis ได้

ส่วนที่ต้อง Config หรือ Custom Develop เพิ่ม

• Multi-obligation Revenue Allocation — Odoo ไม่มี Feature ที่จะ Auto-allocate Transaction Price ตาม Standalone Selling Price ให้หลาย Performance Obligation ในสัญญาเดียว ต้อง Develop Module เพิ่มหรือ Config Manual Split
• Variable Consideration Calculation — ส่วนลดปริมาณ โบนัส สิทธิ์คืนสินค้า ต้อง Setup Logic เพิ่มเพื่อปรับ Transaction Price อัตโนมัติ
• Contract Management Module — สำหรับสัญญาระยะยาวที่ต้อง Track หลาย Performance Obligation พร้อม Revenue Schedule ของแต่ละ Obligation แยกกัน
• Revenue Recognition Report ตามมาตรฐาน — Report ที่แสดง Revenue Breakdown ตาม Performance Obligation สำหรับ Auditor ตรวจสอบ
• Percentage of Completion Automation — สำหรับธุรกิจก่อสร้างหรือ Project-based ที่ต้องคำนวณ % ความสำเร็จแล้วรับรู้รายได้อัตโนมัติ

วิธี Setup Odoo ให้รองรับ TFRS 15 เบื้องต้น

สำหรับบริษัทที่ใช้ Odoo อยู่แล้วและกำลังเตรียมเข้าตลาดหลักทรัพย์ สิ่งที่ควรทำเป็นอันดับแรก

• วิเคราะห์สัญญาทุกประเภท — List สัญญาทั้งหมดที่มีกับลูกค้า แล้วระบุว่าแต่ละสัญญามีกี่ Performance Obligation อะไร Distinct อะไรไม่ Distinct
• Restructure Product Master — แยก Product/Service ใน Odoo ให้ตรงกับ Performance Obligation ไม่ใช่ขายเป็น Bundle Product เดียว
• Setup Deferred Revenue — สำหรับ Performance Obligation แบบ Over Time ตั้ง Revenue Recognition Schedule ใน Odoo Accounting
• Config Analytic Account — ผูก Analytic Account กับแต่ละ Performance Obligation เพื่อ Track รายได้แยกตาม Obligation
• ออกแบบ Revenue Report — สร้าง Custom Report ที่แสดง Revenue ตาม Performance Obligation สำหรับ Auditor Review

สรุป TFRS 15 กับ Odoo ERP

TFRS 15 เปลี่ยนวิธีรับรู้รายได้จากเดิมที่ดูตาม Invoice มาเป็นการวิเคราะห์สัญญาผ่าน Five-Step Model ซึ่งกระทบระบบ Odoo ERP ตั้งแต่วิธีสร้าง Sale Order ไปจนถึงวิธีรับรู้ Revenue ใน Accounting

Odoo Enterprise มี Feature พื้นฐานที่รองรับ TFRS 15 ได้ระดับหนึ่ง โดยเฉพาะ Deferred Revenue และ Analytic Accounts แต่สำหรับสัญญาที่ซับซ้อน มีหลาย Performance Obligation ต้อง Config หรือ Develop เพิ่มเติม

สำหรับบริษัทที่เตรียมเข้าตลาดหลักทรัพย์ ควรเริ่มวิเคราะห์สัญญาและ Restructure ระบบ Odoo ตั้งแต่เนิ่นๆ เพราะ กลต. ให้ความสำคัญกับ TFRS 15 เป็นพิเศษ ระบบต้องไม่ใช่แค่ตัวเลขถูก แต่ต้องพิสูจน์ได้ว่าทำไมรับรู้รายได้จำนวนนี้ ในเวลานี้ Dynamics Motion ในฐานะ Odoo Enterprise Partner พร้อมช่วยวิเคราะห์ Gap และ Setup ระบบ Odoo ให้รองรับ TFRS 15 ครบทุกขั้นตอน