Marketplace Settlement ไทย 2026: กระทบยอดเงินรับ TikTok Shop, Shopee, Lazada ให้รู้กำไรจริงอย่างไร

ยอดขายบนหน้าจอไม่เท่ากับเงินรับ และเงินรับไม่เท่ากับกำไร

ยอด GMV ช่วยบอกขนาดการซื้อขาย แต่ยังไม่ตอบว่าแบรนด์ได้เงินเท่าไร เพราะหนึ่งออเดอร์มีส่วนลดหลายผู้รับผิดชอบ ค่าธรรมเนียมหลายชนิด ค่าขนส่ง Affiliate, Refund และ Adjustment ที่เกิดคนละเวลา หากทีมการตลาดรายงานยอดขาย ทีมบัญชีดูเงินเข้า และทีม E-commerce ดู Seller Balance โดยไม่มีเลขอ้างอิงกลาง ทั้งสามทีมอาจถูกต้องในมุมของตนแต่ตอบคำถามกำไรคนละคำตอบ

TikTok Shop อธิบายว่าเมื่อเกิดธุรกรรม ระบบบันทึกใน Finance แบบ Accrual และเมื่อออเดอร์เสร็จสมบูรณ์จึงนำรายได้หลังหักค่าธรรมเนียมเข้าสู่ Seller Account Balance การ Settlement กับการโอนเข้าบัญชีธนาคารเป็นคนละขั้นตอน ส่วน Shopee มีคู่มือเฉพาะสำหรับเทียบ Income Report กับ Seller Balance ข้อเท็จจริงนี้ชี้ว่าการปิดยอดต้องรักษาสถานะและวันที่หลายชุด ไม่ควรจับยอดขายรายวันเทียบยอดธนาคารตรง ๆ

เป้าหมายจึงไม่ใช่บังคับให้ทุกไฟล์มียอดเท่ากันในวันเดียว แต่ทำให้ทุกส่วนต่างอธิบายได้ว่าเป็น Timing Difference, Fee, Refund, Subsidy, Adjustment หรือความผิดปกติ เมื่ออธิบายได้ รายงานกำไรและการตัดสินใจแคมเปญจึงเชื่อถือได้

เริ่มจาก Order-to-Cash Ledger ที่ละเอียดถึงหนึ่งธุรกรรม

กำหนด Grain ของตารางกลางให้ชัด แนะนำหนึ่งแถวต่อ Order Line และ Transaction Type เพราะหนึ่ง Order อาจมีหลาย SKU หลายส่วนลด หรือคืนบางชิ้น ฟิลด์ขั้นต่ำคือ Channel, Shop ID, Order ID, Order Line ID, SKU กลาง, Quantity, Order Date, Delivered Date, Completed Date, Settlement Date, Payout ID, Bank Value Date, Currency และ Tax Document Reference ที่เกี่ยวข้อง

อย่าใช้ชื่อสินค้าหรือวันที่เป็นกุญแจจับคู่ ให้รักษา Order ID และ Adjustment ID จากไฟล์ต้นทาง พร้อมสร้าง Internal Transaction ID ที่ไม่ซ้ำ ถ้าแพลตฟอร์มส่งข้อมูลระดับ Order แต่ต้นทุนสินค้าอยู่ระดับ SKU ให้กำหนด Allocation Rule ที่ตรวจสอบได้ เช่น กระจายค่าขนส่งตามน้ำหนักหรือมูลค่า และระบุเวอร์ชันของสูตร

ทุกไฟล์นำเข้าต้องมี Source File, Imported At, Row Hash และ Report Period เพื่อป้องกันโหลดซ้ำและย้อนกลับไปยังต้นฉบับได้ การแก้ไขภายหลังควรเพิ่ม Journal Entry ใหม่ ไม่เขียนทับข้อมูลเดิม เพราะทีมต้องพิสูจน์ได้ว่ายอดเปลี่ยนจากอะไร เมื่อไร และใครอนุมัติ

สร้าง Settlement Waterfall ให้เห็นทุกบาทจากราคาขายถึงยอดสุทธิ

Waterfall ต่อออเดอร์ควรเริ่มจาก Gross Item Price แล้วหัก Seller Discount บวก Platform-funded Subsidy แยก Customer Shipping, Platform Shipping Subsidy และ Seller Shipping Cost จากนั้นหัก Commission Fee, Transaction Fee, Infrastructure หรือ Growth Fee ตามช่องทาง รวม Affiliate Commission และค่าใช้จ่ายการตลาดที่ถูกหักจาก Balance ก่อนบันทึก Refund, Return Shipping, Chargeback, Compensation, Penalty และ Adjustment

เอกสาร Introduction to Seller Fees ของ TikTok Shop Thailand อัปเดต 20 เมษายน 2026 แสดงว่าฐานคำนวณของค่าธรรมเนียมแต่ละชนิดไม่เหมือนกัน และรายการปรับยอดอาจรวม Affiliate, Shipping Adjustment, Platform Compensation, Seller Co-funded Voucher และ Ads Top-up จากยอด Settled ดังนั้นการมีคอลัมน์ชื่อ Fees เพียงช่องเดียวทำให้หาสาเหตุไม่ได้และวิเคราะห์กำไรผิด

สร้าง Fee Dictionary แยก Platform, Program, Fee Code, Business Meaning, Sign Convention, Calculation Base, VAT Treatment, Effective From, Effective To และ Official Source URL เมื่อแพลตฟอร์มเปลี่ยนอัตรา ให้เพิ่ม Rule Version ใหม่และคำนวณตามวันที่ออเดอร์ ไม่ย้อนเปลี่ยนประวัติทั้งหมด

แยก Voucher และ Subsidy ตามผู้รับผิดชอบต้นทุน

ส่วนลดหน้าร้านอาจดูเหมือนกันสำหรับลูกค้า แต่ผลกำไรต่างกันมาก Seller-funded Voucher ลดรายได้หรือเป็นต้นทุนของร้าน Platform-funded Discount คือเงินสนับสนุนที่ต้องบันทึกตามรายละเอียด Settlement ส่วน Co-funded Voucher ต้องแยกสัดส่วนของร้านและแพลตฟอร์ม ห้ามหักยอดส่วนลดเต็มจำนวนจากร้านโดยอัตโนมัติ

หน้าทางการของ Lazada อธิบาย Seller Voucher Credit แบบ Co-funded และยกตัวอย่างสัดส่วนกับค่าคอมมิชชัน ขณะที่เอกสารค่าธรรมเนียมของ TikTok Shop แยก Seller Co-funded Voucher Discount, Platform Co-funded Voucher Discount และรายการ Refund ของแต่ละส่วน การออกแบบ Data Model จึงควรมี Funding Party, Campaign ID, Voucher ID, Original Discount และ Seller Cost แทนคอลัมน์ Voucher ก้อนเดียว

หลังจบแคมเปญ ให้เทียบ Incremental Orders กับ Seller-funded Discount, Media, Affiliate, Returns และ Contribution Profit ไม่ใช้ยอดใช้คูปองหรือ GMV เป็นคำตอบ หากต้องการวาง Guardrail ก่อนแคมเปญ สามารถเชื่อมหลักจากบทความ 9.9 เรื่อง Campaign P&L แล้วใช้ Settlement จริงปิดสมมติฐานอีกครั้ง

ทำ Three-way Reconciliation: Order ↔ Settlement ↔ Bank

ชั้นที่หนึ่ง Order-to-Settlement ตรวจว่าออเดอร์ที่ Complete แล้วมีธุรกรรม Settled ครบหรือไม่ และยอดสุทธิตรงกับ Waterfall ตาม Rule Version หรือไม่ ชั้นที่สอง Settlement-to-Payout รวมรายการตาม Payout ID ตรวจยอดที่แพลตฟอร์มระบุว่า Withdrawn หรือ Paid ชั้นที่สาม Payout-to-Bank จับคู่จำนวนเงิน วันที่ และเลขอ้างอิงกับ Bank Statement

อย่าบังคับ One-to-One หากแพลตฟอร์มรวมหลายออเดอร์เป็นหนึ่ง Payout หรือหัก Adjustment ข้ามรอบ ให้ทำ Bridge Table ระหว่าง Transaction ID กับ Payout ID และอนุญาต Many-to-Many โดยยอดรวมต้องสมดุล กำหนด Tolerance เฉพาะกรณีปัดเศษที่มีเหตุผล ไม่ใช้ Tolerance กลบค่าธรรมเนียมหาย

TikTok Shop แยก To Settle ซึ่งยังเป็นค่าประมาณออกจาก Settled ซึ่งเป็นยอดจริง และอนุญาต Export ไฟล์ที่มี Order Details, Report, Withdrawal Records และ Fee Explanation แนวทางที่ปลอดภัยคือใช้ Estimated Settlement เพื่อพยากรณ์ Cash แต่ใช้ Settled กับ Bank Value Date สำหรับปิดยอดจริง

จัดการ Timing Difference โดยไม่เร่งรับรู้กำไร

วันที่สั่ง วันที่ส่งมอบ วันที่ Completed วันที่ Settled วันที่ถอน และวันที่เงินเข้าธนาคารอาจอยู่คนละรอบ TikTok Shop Settlement Policy ซึ่งประกาศไว้สำหรับร้านในไทยแยก Standard, Express และ Extended Settlement ตามเกณฑ์ร้าน และเตือนว่าแพลตฟอร์มอาจปรับเงื่อนไขได้ ร้านจึงควรอ่าน Settlement Period ที่แสดงจริงใน Seller Center แทนการยึดตัวเลขจากบทความนี้เป็น SLA ถาวร

สร้าง Aging Bucket สำหรับ To Settle เช่น 0–3, 4–7, 8–15 และมากกว่า 15 วัน แต่ตั้ง Threshold ตามเงื่อนไขจริงของแต่ละร้าน รายการที่ยังอยู่ในกรอบถือเป็น Timing Difference ส่วนรายการเกิน Expected Settlement Date ต้องเข้า Exception Queue แยกจากเงินที่ Settled แล้วแต่ยังไม่เข้า Bank

สำหรับ Cash Forecast ให้เริ่มจากยอด To Settle ที่ปรับด้วยประวัติ Cancel, Return และ Hold ของร้าน แยก Expected Payout Date ออกจาก Revenue Recognition Date และให้ทีมบัญชีกำหนด Treatment ที่เหมาะกับกิจการ บทความนี้เป็นกรอบปฏิบัติการ ไม่ใช่คำแนะนำภาษีหรือบัญชีเฉพาะราย

คืนสินค้า Chargeback และ Negative Balance ต้องย้อนถึงออเดอร์เดิม

Refund หลัง Settlement อาจกลายเป็นรายการหักในรอบถัดไป หากทีมดูเฉพาะยอดโอนของวันนั้น กำไรของออเดอร์เดิมจะยังดูสูงเกินจริง ให้สร้าง Reversal Link จาก Refund หรือ Chargeback ไป Original Order Line และกลับรายการรายได้ ต้นทุนคูปอง ค่าธรรมเนียม ค่าขนส่งหรือ Affiliate ตามเงื่อนไขที่แพลตฟอร์มคืนจริง ไม่สมมติว่าทุกค่าใช้จ่ายถูกคืนพร้อมกัน

TikTok Shop ระบุว่า Refund อาจถูกหักจาก Seller Account Balance และนโยบาย Negative Balance อธิบายว่าค่าใช้จ่ายอาจมากกว่ารายรับจนยอดติดลบ พร้อมมาตรการต่อการถอนเงินหรือสิทธิประโยชน์ ขณะที่ Lazada มีแนวทาง Instant และ Fast Refund ซึ่งผู้รับผิดชอบค่าใช้จ่ายอาจต่างตามกรณี ดังนั้น Reason Code และ Funding Party ของ Refund ต้องเป็นข้อมูลบังคับ

เชื่อม Reason Code เข้ากับระบบ Returns & Refunds และ Order Fulfilment เพื่อแก้ต้นเหตุ เช่น Listing ไม่ตรง ส่งผิด ชำรุด หรือขนส่งเสียหาย หากเงินต่างถูกแก้เฉพาะในบัญชี แต่ไม่ย้อนกลับไปยังเจ้าของกระบวนการ ต้นทุนเดิมจะเกิดซ้ำทุกเดือน

ตั้ง Exception Queue ที่มีเจ้าของและเส้นตาย

Exception ที่ควรแยกอย่างน้อยคือ Missing Settlement, Amount Mismatch, Unknown Fee, Duplicate Transaction, Unmatched Payout, Bank Short Credit, Refund Without Original, Subsidy Missing, Negative Balance และ Stale To Settle แต่ละรายการต้องมี Amount at Risk, Channel, Root-cause Code, Owner, Due Date, Evidence Link และ Resolution Entry

จัดลำดับคิวจากมูลค่า อายุ และความเสี่ยง ไม่ใช่แก้รายการง่ายก่อนทั้งหมด ตัวอย่าง Priority Score อาจรวม Amount 40%, Aging 30%, Repeat Frequency 20% และ Compliance Risk 10% โดยทีมปรับน้ำหนักตามธุรกิจ รายการเล็กที่เกิดซ้ำหลายพันครั้งอาจสำคัญกว่ารายการใหญ่ครั้งเดียวเพราะชี้ว่า Mapping หรือ Rule ผิดทั้งระบบ

ก่อนเปิด Ticket กับแพลตฟอร์ม ให้แนบ Evidence Pack ได้แก่ Order Detail, Settlement Row, Fee Rule ที่ใช้, Payout Record, Bank Record, Calculation และภาพหน้าจอที่มีเวลา ปิด Ticket เมื่อมี Resolution Code และ Journal Entry แล้วเท่านั้น ไม่ใช้สถานะตอบแล้วแทนสถานะแก้ยอดแล้ว

ปิดรอบด้วย Close Calendar และ Control ที่ตรวจสอบย้อนกลับได้

Daily Close นำเข้าไฟล์ ตรวจยอดรวม และแจ้ง Exception ใหม่ Weekly Close ทบทวน Aging, Fee Variance, Refund และ Payout ที่ค้าง Monthly Close ล็อก Report Period, บันทึก Accrual/Adjustment ตามนโยบายกิจการ และส่ง Reconciliation Pack ให้ผู้อนุมัติ ทุก Close ต้องมี Sign-off ของ E-commerce Operations กับ Finance ไม่ให้ฝ่ายใดฝ่ายหนึ่งปรับยอดลำพัง

กำหนด Control Total ก่อนแปลงข้อมูล เช่น จำนวนแถว ยอด Revenue, Fees, Settlement และ Withdrawal ของไฟล์ต้นทาง หลัง Transform ต้องรวมกลับเท่าเดิม ถ้าระบบเปลี่ยนหัวคอลัมน์ เพิ่ม Fee Code หรือเปลี่ยนเครื่องหมายบวก/ลบ ให้ Pipeline หยุดและส่ง Schema Exception แทนการโหลดต่อแบบเงียบ ๆ

สิทธิ์ดาวน์โหลดรายงาน เปลี่ยนบัญชีธนาคาร อนุมัติ Adjustment และถอนเงินควรแยกตามหน้าที่ เก็บ Audit Log และทบทวนผู้มีสิทธิ์สม่ำเสมอ การตั้ง Auto-withdrawal ช่วยกระแสเงินสดแต่ไม่ได้แทนการกระทบยอด เพราะหนึ่งยอดธนาคารยังต้องย้อนถึงรายการ Settled ทุกตัวได้

วัด KPI ที่สะท้อนเงินค้าง ความถูกต้อง และกำไร

เริ่มจาก Settlement Match Rate = มูลค่ารายการที่จับคู่ถูกต้อง ÷ มูลค่า Settled ทั้งหมด, Bank Match Rate, Unsettled Aging, Unmatched Amount, Fee Variance และ Days to Reconcile เพิ่ม Refund Leakage สำหรับเงินหรือค่าธรรมเนียมที่ควรได้คืนแต่ยังไม่กลับ และ Exception Recurrence Rate เพื่อรู้ว่าทีมแก้ที่ปลายเหตุหรือแก้ Rule สำเร็จ

Contribution Profit per Order ควรรวม Net Item Revenue หัก COGS, Seller-funded Discount, Platform/Payment/Infrastructure Fees, Affiliate, Ads ที่จัดสรร, Fulfilment, Packaging, Shipping, Return และ Service Recovery การเปรียบเทียบ SKU หรือ Channel ต้องใช้ Cost Allocation เดียวกันและแสดงรายการที่ยัง Estimate แยกจาก Actual

Dashboard ผู้บริหารควรตอบห้าคำถาม: ขายเท่าไร ควรรับเท่าไร รับจริงเท่าไร ต่างเพราะอะไร และกำไรหลังต้นทุนผันแปรเท่าไร หากตอบเพียง GMV กับ ROAS แต่ไม่เห็น Unsettled, Refund และ Fee Variance ผู้บริหารอาจเพิ่มงบให้แคมเปญที่สร้างยอดแต่ใช้เงินสดและมาร์จินมากเกินไป

• Settlement Match Rate และ Bank Match Rate
• Unsettled Aging, Unmatched Amount และ Days to Reconcile
• Fee Variance, Subsidy Recovery และ Refund Leakage
• Contribution Profit ต่อ Order, SKU, Campaign และ Channel

ใช้ AI หา Pattern ได้ แต่ห้ามให้แก้ยอดเองโดยไร้การควบคุม

AI ช่วยแนะนำ Mapping ของ Fee Description ใหม่ จับคู่ Payout กับยอดธนาคารเมื่อคำอธิบายต่างรูป ตรวจ Anomaly ของ Fee Rate ทำนาย Expected Settlement Date และจัดกลุ่ม Root Cause จาก Ticket ได้ แต่ผลลัพธ์ต้องมี Confidence Score, Rule Explanation และแหล่งข้อมูล ไม่ควรอนุญาตให้โมเดลสร้าง Journal Entry หรือปิด Exception อัตโนมัติในกรณีมูลค่าสูง

เริ่มจากระบบกฎสำหรับ Exact ID, Amount และ Date Window แล้วใช้ AI เฉพาะรายการที่กฎไม่จับคู่ ตั้ง Threshold เช่น Confidence สูงเสนอ Match ให้คนอนุมัติ Confidence ต่ำส่งคิวสืบค้น เก็บ Model Version, Input, Suggestion, Reviewer และ Final Decision เพื่อวัด False Match และปรับระบบได้

ข้อมูลการเงินมีความอ่อนไหว จึงควร Mask เลขบัญชี จำกัดสิทธิ์ตามบทบาท กำหนด Retention และไม่ส่งไฟล์ Settlement เข้าเครื่องมือภายนอกโดยไม่มีข้อตกลงและการประเมินความเสี่ยง AI ที่ดีในงานนี้ไม่ใช่ AI ที่ปิดคิวได้มากที่สุด แต่เป็น AI ที่ลดเวลาโดยยังรักษาหลักฐานและการอนุมัติของมนุษย์

แผนลงมือทำ 30 วันสำหรับแบรนด์ไทย

วันที่ 1–7 ทำ Data Audit ดาวน์โหลด Order, Settlement, Withdrawal และ Bank Statement ของอย่างน้อยหนึ่งรอบ สร้าง Source Register, Fee Dictionary, SKU Mapping และ Sign Convention ตรวจว่า Order ID กับ Adjustment ID ครบเพียงใด และเลือกช่องทางที่มูลค่าสูงหรือมีปัญหามากที่สุดเป็น Pilot

วันที่ 8–14 สร้าง Order-to-Cash Ledger กับ Settlement Waterfall ทำ Rule สำหรับ Voucher Funding, Fees, Shipping, Affiliate และ Refund พร้อม Control Total วันที่ 15–21 ทำ Three-way Reconciliation, Aging และ Exception Queue ทดลองย้อนหลังกับเดือนที่ปิดแล้ว ตรวจส่วนต่างร่วมกับ Operations และ Finance

วันที่ 22–30 เชื่อม Daily Import, Dashboard และ Close Calendar ตั้ง Owner กับ SLA ของ Exception ทดสอบ Payout-to-Bank อย่างน้อยสองรอบ ลงนาม Reconciliation Pack และบันทึก Baseline KPI จากนั้นค่อยขยายไป Shopee, Lazada, TikTok Shop หรือเว็บไซต์ช่องทางอื่นทีละชุด ไม่ควรรวมทุกช่องทางก่อนที่ Rule และหลักฐานของ Pilot จะนิ่ง

• สัปดาห์ 1: Source Register, Data Audit, Fee Dictionary และ Pilot Scope
• สัปดาห์ 2: Order Ledger, Waterfall, Mapping และ Control Total
• สัปดาห์ 3: Three-way Reconciliation, Aging และ Exception Queue
• สัปดาห์ 4: Automation, Dashboard, Close Calendar และ Governance

ข้อควรระวัง: ใช้เอกสารปัจจุบันของร้านเป็นหลัก

อัตราค่าธรรมเนียม ฐานคำนวณ Settlement Period และชื่อรายงานเปลี่ยนได้ตามประเภทสินค้า โปรแกรม สถานะร้านและประกาศของแพลตฟอร์ม ตัวเลขหรือหน้าจอในเอกสารตัวอย่างอาจไม่ตรงกับร้านของคุณ จึงต้องเก็บ Official Source URL, วันที่ตรวจ และ Rule Version ทุกครั้ง พร้อมเทียบ Invoice หรือเอกสารภาษีที่แพลตฟอร์มออกให้

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

เมื่อระบบกระทบยอดนิ่ง แบรนด์จะไม่ได้เพียงรายงานที่สวยขึ้น แต่รู้ว่าเงินค้างตรงไหน แคมเปญใดกำไรจริง SKU ใดคืนแล้วขาดทุน และค่าใช้จ่ายใดควรเปิดข้อพิพาท หากต้องการออกแบบ Data Model, Dashboard, Workflow และการสื่อสารข้ามทีม BrandBandaan สามารถช่วยวางระบบการตลาดและ Commerce Operations ให้เชื่อมจากยอดขายถึงเงินสดได้