DurianTradeX
TH中EN
ขอชมระบบ
โต๊ะควบคุม Commercial Invoice ในสำนักงานล้งทุเรียน มองเห็นการบรรจุทุเรียนขึ้นตู้รีเฟอร์ด้านหลัง
EXPORT INVOICE CONTROL · PRACTICAL GUIDE

Commercial Invoice ทุเรียน: คุมราคา–Incoterms–เงินให้ตรง

คู่มือทำ Commercial Invoice ทุเรียนส่งออกด้วย Invoice Control Sheet 20 ช่อง เทียบสัญญา Packing List ใบขน Incoterms สกุลเงิน และยอดรับชำระก่อนออกฉบับจริง

โดย · ปรับปรุง · ใช้เวลาอ่าน 14 นาที
EXECUTIVE TAKEAWAYS

คำค้นหลัก: Commercial Invoice ทุเรียนส่งออก

  • คำตอบสั้น: Commercial Invoice ที่ใช้ได้จริงต้องสร้างจากสัญญาและยอดบรรจุจริง แล้วเทียบผู้ขาย–ผู้ซื้อ สินค้า ปริมาณ ราคา สกุลเงิน Incoterms สถานที่อ้างอิง เงื่อนไขชำระ และยอดรวมกับ Packing List ใบขน Shipping Instruction และเอกสารธนาคารก่อนอนุมัติ
  • กรมศุลกากรระบุ Invoice เป็นเอกสารที่ผู้ส่งออกควรจัดเตรียม และให้ส่งข้อมูล Invoice ทุกรายการร่วมกับข้อมูลใบขนสินค้าขาออกทางอิเล็กทรอนิกส์ จึงไม่ควรทำ Invoice เป็นไฟล์แยกที่แก้ตัวเลขโดยไม่อัปเดต Shipment master
  • Incoterms® แบ่งต้นทุน ความเสี่ยง และหน้าที่บางส่วนของผู้ซื้อ–ผู้ขาย แต่ไม่แทนเงื่อนไขราคา เครดิต การรับชำระ กรรมสิทธิ์ หรือข้อกำหนดคุณภาพทั้งหมด ต้องเขียนแต่ละเรื่องให้ชัดในสัญญาและ Invoice ตามที่คู่ค้าตกลง
01

คำตอบก่อน: Invoice คือจุดเชื่อม Contract–Customs–Cash

Commercial Invoice ไม่ใช่เพียงเอกสารเรียกเก็บเงิน แต่เป็นจุดที่ข้อมูลการขายถูกนำไปใช้ต่อโดยฝ่ายศุลกากร บัญชี ธนาคาร ผู้ซื้อ และทีมปฏิบัติการ กรมศุลกากรไทยระบุบัญชีราคาสินค้า (Invoice) ในเอกสารที่ควรจัดเตรียมสำหรับการส่งออกทางเรือ และอธิบายว่าผู้ส่งออกหรือตัวแทนส่งข้อมูลใบขนพร้อม Invoice ทุกรายการเข้าสู่ระบบอิเล็กทรอนิกส์ ดังนั้น Invoice ควรออกจากข้อมูลชุดเดียวกับ Shipment master และต้องมี Release Gate ก่อนส่งออกนอกองค์กร

  • Contract truth: ราคา สกุลเงิน Incoterms เงื่อนไขชำระ และผู้ซื้อฉบับที่อนุมัติ
  • Physical truth: สินค้า Lot จำนวนกล่อง น้ำหนัก และยอดโหลดจริงจาก Packing List
  • Customs truth: รายละเอียดสินค้า ราคา หน่วย และคู่ค้าที่ใช้ในใบขน
  • Banking truth: ผู้รับเงิน บัญชี Reference และเงื่อนไขเอกสารตามวิธีชำระ
  • Cash truth: ยอดที่ต้องรับ ยอดหักที่อนุมัติ และสถานะการรับชำระที่กระทบลูกหนี้

Invoice ไม่ใช่ Packing List

Packing List อธิบายสิ่งที่บรรจุและโหลดจริง ส่วน Commercial Invoice อธิบายมูลค่าการค้าและเงื่อนไขเรียกเก็บเงิน ทั้งสองต้องอ้างอิง Shipment เดียวกัน แต่ไม่ควรคัดลอกกันแบบไม่มีการตรวจ เพราะหน่วยขายอาจเป็นกิโลกรัม กล่อง หรือจำนวนผล ขณะที่หน่วยบรรจุอาจต่างออกไป

Pro forma ไม่ใช่ Final Commercial Invoice

Pro forma ใช้เสนอราคา ขออนุมัติ หรือประกอบการเตรียมธุรกรรมได้ตามบริบท แต่ Final Commercial Invoice ควรออกจากยอดจริงตาม Cut-off ที่กำหนด หากต้องแก้หลังออกฉบับจริงให้ใช้ Revision หรือ Credit/Debit Note ตามนโยบายและข้อกำหนดคู่ค้า ไม่เขียนทับไฟล์เดิม

02

สร้าง Invoice Control Sheet 20 ช่องก่อนออกฉบับจริง

ใช้ Control Sheet หนึ่งชุดต่อ Commercial Invoice และผูกกับ Shipment ID ที่ไม่ซ้ำ แต่ละช่องต้องระบุ Source of truth ผู้รับผิดชอบ และสถานะ Draft–Checked–Approved–Issued เพื่อให้ย้อนกลับได้ว่าใครอนุมัติข้อมูลใดเมื่อไร รายการต่อไปนี้เป็น Internal Control Template ไม่ใช่รายการกฎหมายตายตัวสำหรับทุกประเทศหรือวิธีชำระ

  • 1 Invoice number, issue date, revision และ Shipment ID
  • 2 Seller legal name, address, Tax ID และข้อมูลติดต่อ
  • 3 Buyer/Consignee/Bill-to พร้อมรหัสคู่ค้า
  • 4 Purchase order, sales contract และ contract revision
  • 5 Booking, container, seal และ transport reference เมื่อจำเป็น
  • 6 ประเทศต้นทาง ปลายทาง และสถานที่ส่งมอบ
  • 7 Product description ภาษาและคำเรียกที่อนุมัติ
  • 8 Variety, grade, size/spec และ Lot reference ที่จำเป็น
  • 9 HS code หรือรหัสภายใน โดยให้ผู้เชี่ยวชาญตรวจพิกัด
  • 10 Quantity, sales unit และ conversion rule
  • 11 Net/Gross weight และหน่วย
  • 12 Unit price พร้อมฐานคำนวณ
  • 13 Currency ตามรหัสที่ตกลง
  • 14 Line amount, subtotal และ rounding rule
  • 15 Discount, rebate, commission หรือ charge ที่อนุมัติ
  • 16 Incoterms® rule, named place/port และ version
  • 17 Payment term, due trigger และ banking/document reference
  • 18 Freight/insurance/other cost ที่รวม–ไม่รวมตามสัญญา
  • 19 Declaration/signature requirement ตามคู่ค้าและปลายทาง
  • 20 Checker, approver, timestamp และ distribution log
03

ล็อก Price Basis ก่อนคำนวณยอด Invoice

ข้อผิดพลาดมักไม่ได้เกิดจากเครื่องคิดเลข แต่เกิดจากนิยามราคาไม่ตรงกัน เช่น ราคาต่อกิโลกรัมน้ำหนักสุทธิ แต่ระบบคูณน้ำหนักรวม หรือราคาเป็นต่อกล่องมาตรฐานแต่กล่องจริงมีน้ำหนักต่างกัน กำหนด Price Basis ในสัญญาและ Shipment master ก่อนรับสินค้าเข้าล้ง แล้วให้ระบบคำนวณจากหน่วยฐานเดียว ไม่พิมพ์ยอดรวมด้วยมือ

  • ระบุว่า Unit price ใช้ kg net, carton, piece, pallet หรือ shipment
  • กำหนดแหล่ง Quantity: Contracted, Packed, Loaded หรือ Accepted at destination
  • กำหนดทศนิยมและ Rounding ที่ระดับ Line และ Invoice total
  • แยก Discount, Quality adjustment, Commission และ Freight เป็นคนละรายการ
  • บล็อกยอดติดลบหรือส่วนลดเกินสิทธิ และให้ผู้มีอำนาจอนุมัติ Exception

อย่าให้ราคาใน Invoice ลอยจาก Purchase Order

เมื่อ Buyer แก้ PO หรือยืนยันราคาใหม่ ให้เปิด Contract/PO revision และบันทึก Effective time ก่อนสร้าง Invoice ระบบควรเตือนเมื่อราคา สกุลเงิน หรือหน่วยไม่ตรงกับ Revision ที่ผูกกับ Shipment

Estimated quantity ต้องเปลี่ยนเป็น Actual ตาม Gate

ช่วงจองตู้หรือเตรียมเอกสารอาจใช้ประมาณการได้ แต่ Final Invoice ต้องมีนโยบายชัดว่าจะ Freeze เมื่อใดและอ้าง Actual loaded จากระบบใด หากธุรกรรมตกลงให้ชำระตามน้ำหนักหรือผลตรวจปลายทาง ต้องแยก Provisional กับ Final settlement ให้ตรวจสอบได้

04

เขียน Incoterms® ให้ครบ Rule–Named Place–Version

ICC อธิบายว่า Incoterms® 2020 ช่วยจัดสรรต้นทุน ความเสี่ยง และหน้าที่ระหว่างผู้ซื้อกับผู้ขาย การเขียนเพียง ‘FOB’ หรือ ‘CIF’ จึงยังไม่พอสำหรับควบคุมงาน ควรระบุ Rule ตามด้วย Named port/place ที่ชัดและ ‘Incoterms® 2020’ แล้วตรวจว่าค่า Freight, Insurance, Export clearance และค่าใช้จ่ายอื่นใน Invoice สอดคล้องกับสัญญา

  • ตัวอย่างรูปแบบ: FCA [สถานที่ส่งมอบที่ระบุ], Incoterms® 2020
  • ใช้ Named place/port เดียวกันใน Contract, Invoice และ Shipping instruction เมื่อบริบทต้องตรงกัน
  • ตรวจว่า Charge ที่บวกใน Invoice ไม่ซ้ำกับต้นทุนที่อีกฝ่ายรับผิดชอบ
  • อย่าใช้ Incoterms® เป็นคำตอบแทน Payment term, Transfer of title หรือ Quality acceptance
  • หากเส้นทางหรือผู้จัดการขนส่งเปลี่ยน ให้ฝ่ายการค้าทบทวน Rule ไม่แก้โดยฝ่ายเอกสารลำพัง
05

คุม Currency, Exchange-rate Context และบัญชีรับเงิน

Commercial Invoice ต้องแสดงสกุลเงินที่คู่ค้าตกลงอย่างไม่กำกวม ใช้รหัสสกุลเงินมาตรฐานในระบบและห้ามอาศัยสัญลักษณ์อย่าง ¥ หรือ $ เพียงอย่างเดียว เพราะอาจตีความได้หลายสกุล หากฝ่ายบัญชีต้องแปลงเป็นเงินบาท ให้เก็บอัตรา แหล่งอ้างอิง วันที่ เวลา และวัตถุประสงค์ของอัตรานั้นแยกจาก Face currency บน Invoice ไม่ควรเปลี่ยนยอด Invoice เพียงเพราะอัตราบัญชีเปลี่ยน

  • Face currency ต้องตรง Contract/PO และวิธีรับชำระ
  • เก็บ Exchange-rate source สำหรับบัญชีและ P&L โดยไม่เขียนทับยอดการค้าเดิม
  • Bank beneficiary ต้องมาจาก Master data ที่อนุมัติ ไม่รับคำขอเปลี่ยนบัญชีผ่านอีเมลเดียว
  • การเปลี่ยนบัญชีรับเงินต้องใช้ Dual control และยืนยัน Out-of-band กับผู้มีอำนาจ
  • บันทึก Bank charge, Withholding หรือ deduction แยกจากยอด Invoice และต้องมีเหตุผล

ป้องกัน Business Email Compromise

คำขอเปลี่ยนบัญชีธนาคารเป็นเหตุการณ์ความเสี่ยงสูง ให้หยุดการออก Invoice ตรวจผู้ร้องขอด้วยช่องทางที่เคยยืนยันไว้ และให้ผู้อนุมัติสองคนทบทวน Master data ระบบไม่ควรคัดลอกเลขบัญชีจากไฟล์แนบหรือข้อความใหม่โดยอัตโนมัติ

06

ทำ Five-way Match ก่อนกด Issue

ตั้ง Release Gate ให้ Commercial Invoice ผ่านการจับคู่ 5 แหล่ง ได้แก่ Contract/PO, Packing List, Shipment master, Customs draft และ Payment instrument จุดประสงค์ไม่ใช่บังคับให้ทุกช่องเหมือนกัน แต่ให้ช่องที่ควรสอดคล้องมีค่าเดียวและอธิบายความต่างที่ตั้งใจไว้

  • Contract/PO ↔ Invoice: Buyer, Product, Price basis, Currency, Incoterms และ Payment term
  • Packing List ↔ Invoice: Lot, Quantity, Sales unit, Net/Gross weight และ Container reference
  • Shipment master ↔ Invoice: Booking, Container, Seal, Route และ Cut-off revision
  • Customs draft ↔ Invoice: Exporter, Consignee, Description, Quantity, Unit, Value และ Currency
  • L/C, Collection หรือ Remittance instruction ↔ Invoice: Beneficiary, Reference, Due event และชุดเอกสาร

Match แบบมี Tolerance แต่ห้ามเงียบ

กำหนด Tolerance ตามสัญญาและประเภทข้อมูล เช่น ความต่างจากการปัดเศษอาจยอมรับได้ แต่ชื่อผู้ซื้อหรือสกุลเงินไม่ควรมี Tolerance ทุกความต่างต้องแสดงค่า Source–Target เหตุผล ผู้อนุมัติ และผลกระทบ ไม่ใช้คำเตือนกว้างว่า ‘ข้อมูลไม่ตรง’

07

ออก Revision โดยรักษา Audit Trail

เมื่อ Invoice ถูกส่งให้ Buyer, Broker หรือธนาคารแล้ว การแก้ไขต้องไม่ทำลายฉบับเดิม ใช้สถานะ Draft, Approved, Issued, Superseded, Cancelled และ Settled พร้อมเลข Revision ที่ต่อเนื่อง ระบุเหตุผลและผู้รับผลกระทบ กรมศุลกากรอธิบายว่าการแก้ข้อมูลบางรายการหลัง Matching หรือหลังส่งออกอาจต้องยื่นคำร้องและพิจารณาเป็นกรณี จึงควรตัดความผิดพลาดก่อน Submission gate

  • ห้ามแก้ PDF ที่ Issued แล้วโดยใช้ชื่อไฟล์เดิม
  • เก็บ Hash หรือ Version ID ของไฟล์ที่ส่งจริง
  • ทำ Impact list: ใบขน Packing List B/L C/O ใบรับรอง และรายการลูกหนี้
  • ส่ง Revision พร้อมคำว่า Supersedes และเรียกคืนฉบับเก่าจาก Distribution list
  • หากมูลค่าเปลี่ยนหลังรับชำระ ให้ฝ่ายบัญชีและการค้าตัดสินใจ Credit/Debit workflow
08

ส่งต่อสู่ Accounts Receivable และ Container P&L

Invoice ที่ Issued ควรสร้างลูกหนี้จากข้อมูลเดียวกัน ไม่คีย์ยอดใหม่ในระบบบัญชี ผูก Due date กับ Trigger ที่ระบุจริง เช่น วันออก Invoice วันส่งเอกสาร หรือเหตุการณ์ที่สัญญากำหนด แล้วแยกสถานะ Document accepted, Payment due, Partially paid, Paid, Disputed และ Overdue เพื่อให้ผู้บริหารเห็น Cash conversion ของแต่ละตู้

  • Invoice total ↔ AR open amount ต้องตรวจสอบย้อนกลับได้
  • Cash receipt ต้อง Match ด้วย Invoice number, Buyer, Currency และ Amount
  • Partial payment และ deduction ต้องสร้าง Reason code
  • Unrealized/realized FX ใช้นโยบายบัญชี ไม่แก้ยอดต้นฉบับ
  • Container P&L ต้องเห็น Revenue revision และ Credit note ล่าสุดก่อนปิด Shipment
09

ใช้ AI ตรวจ Invoice โดยไม่ให้ AI อนุมัติเงิน

AI เหมาะกับ OCR, Field extraction, การเทียบเอกสาร และการชี้ความผิดปกติ เช่น ราคาไม่ตรง PO สกุลเงินเปลี่ยน หรือยอด Line รวมไม่เท่ากับ Total แต่การออก Invoice การเปลี่ยนบัญชีรับเงิน และการอนุมัติส่วนลดเป็นการตัดสินใจที่กระทบเงินและสัญญา ต้องให้คนที่มีอำนาจตรวจหลักฐานและยืนยันเสมอ

  • แสดง Source snippet และตำแหน่งหน้าของทุกค่าที่ AI ดึง
  • คำนวณยอดด้วยกฎ Deterministic แล้วใช้ AI อธิบาย Exception
  • ตั้ง Confidence threshold และส่งค่าความมั่นใจต่ำให้คนตรวจ
  • บล็อกการเรียนรู้จากข้อมูลธนาคารหรือข้อมูลส่วนบุคคลนอกขอบเขตที่อนุมัติ
  • เก็บ Prompt/model version, Input hash, ผลตรวจ และ Human decision ใน Audit log

AI ที่ดีต้องตอบว่าไม่ตรงตรงไหน

แทนข้อความ ‘Invoice อาจผิด’ ให้ระบบแสดง เช่น Contract Rev.4 = USD 68/carton แต่ Invoice Draft = USD 66/carton พร้อมลิงก์ไปยังแหล่งข้อมูลและผู้รับผิดชอบ การแจ้งเตือนจึงแก้ได้ก่อน Cut-off

10

KPI ที่ทำให้ Invoice Control วัดผลได้

วัดทั้งความถูกต้อง ความเร็ว และผลกระทบเงินสด โดยแยกสาเหตุจาก Sales, Packing, Documentation, Broker, Buyer และ Master data เพื่อไม่ให้ทีมเอกสารถูกวัดเพียงจำนวนไฟล์ที่ออก

  • Invoice First-pass Match Rate
  • Draft-to-Approved Lead Time
  • Invoice issued after Actual-ready Rate
  • Post-issue Revision Rate และสาเหตุ
  • Value/Quantity mismatch before Customs submission
  • Credit note rate จาก Document error
  • Days Sales Outstanding แยก Buyer และ Shipment
  • Unapplied cash และ Deduction aging
11

แผนนำไปใช้ 7 วันในล้งหรือทีมส่งออก

เริ่มจากตู้จริงหนึ่งตู้และเลือกเอกสารที่ความเสี่ยงสูง ไม่ต้องรื้อระบบทั้งหมดในครั้งเดียว เป้าหมายสัปดาห์แรกคือมี Source of truth, Field owner, Five-way Match และ Issue gate ที่ทุกฝ่ายใช้ร่วมกัน

  • วัน 1: เก็บ Contract, PO, Invoice, Packing List, ใบขน และ Payment instruction ของตู้ตัวอย่าง
  • วัน 2: ทำ Data dictionary สำหรับ 20 ช่องและกำหนด Owner
  • วัน 3: สร้าง Price basis, Currency, Incoterms และ Rounding rules
  • วัน 4: ตั้ง Five-way Match พร้อม Critical/Tolerance classification
  • วัน 5: ทดลอง Draft–Check–Approve–Issue–Revision และ Distribution log
  • วัน 6: ผูก Invoice กับ AR, Cash receipt และ Container P&L
  • วัน 7: ทบทวน Exception ปรับ SOP และอบรมผู้อนุมัติ
FAQ · คำตอบพร้อมใช้

คำถามที่พบบ่อย

Commercial Invoice ทุเรียนส่งออกควรมีข้อมูลอะไรบ้าง?

อย่างน้อยควรระบุผู้ขาย ผู้ซื้อ เลขที่และวันที่ Invoice เอกสารอ้างอิง รายละเอียดสินค้า ปริมาณ หน่วย ราคา สกุลเงิน ยอดรวม Incoterms พร้อมสถานที่และเวอร์ชัน เงื่อนไขชำระ และข้อมูลอื่นตามกฎหมาย ประเทศปลายทาง วิธีชำระ และข้อตกลงจริง ใช้รายการ 20 ช่องในบทความเป็น Internal Control Template ไม่ใช่ข้อกำหนดตายตัวทุก Shipment

Invoice กับ Packing List ต้องมียอดน้ำหนักเท่ากันหรือไม่?

ค่าที่นิยามเหมือนกันควรตรงกัน เช่น Net weight ของ Lot เดียวกัน แต่เอกสารอาจมีวัตถุประสงค์และหน่วยต่างกัน ต้องกำหนด Data dictionary ว่าช่องใดเทียบกันได้ หากต่างให้มีเหตุผล Source และผู้อนุมัติ ไม่ควรบังคับเท่ากันด้วยการแก้เลขปลายทาง

ควรใส่ Incoterms ใน Invoice อย่างไร?

ระบุ Rule, Named place/port และเวอร์ชัน เช่น FCA [สถานที่ที่ตกลง], Incoterms® 2020 แล้วตรวจให้ตรงสัญญาและรายการต้นทุนที่รวมในราคา อย่าใช้เพียงคำย่อโดยไม่มีสถานที่ และอย่าใช้ Incoterms แทน Payment term หรือเงื่อนไขคุณภาพ

ถ้า Invoice ออกแล้วแต่ยอดโหลดเปลี่ยนต้องทำอย่างไร?

หยุดการส่งฉบับเดิม ประเมินผลต่อ Packing List ใบขน B/L C/O เอกสารธนาคาร และลูกหนี้ จากนั้นออก Revision หรือเอกสารปรับมูลค่าตามขั้นตอนที่อนุมัติ เก็บฉบับเดิมเป็น Superseded และแจ้งทุกคนใน Distribution list หากยื่นศุลกากรหรือ Matching แล้วให้ตรวจขั้นตอนกับตัวแทนออกของและเจ้าหน้าที่ที่เกี่ยวข้อง

AI สามารถสร้าง Commercial Invoice อัตโนมัติได้หรือไม่?

AI ช่วยดึงและเทียบข้อมูล สร้าง Draft และชี้ Exception ได้ แต่ยอดเงิน สกุลเงิน ส่วนลด บัญชีรับเงิน และการออกฉบับจริงต้องผ่านกฎคำนวณที่ตรวจสอบได้กับ Human approval เก็บหลักฐานต้นทางและ Audit log ทุกครั้ง

อ่านต่อและนำไปใช้

Packing List ทุเรียนส่งออก: คุม Carton–น้ำหนัก–Lot ให้ตรง↗Draft B/L ตู้ทุเรียน: คุม 12 จุดก่อนออกเอกสาร↗AI ตรวจเอกสารตู้ทุเรียน: จับข้อมูลไม่ตรงก่อนยื่น↗Document Control สำหรับการส่งออกทุเรียน↗คำนวณกำไรรายตู้ทุเรียนให้เห็นก่อนปิด Shipment↗FOB หรือ FCA ตู้ทุเรียน: เลือก Incoterms ให้ต้นทุนไม่รั่ว↗

แหล่งข้อมูลทางการ

ตรวจสอบข้อมูลล่าสุด ณ วันที่ 11 กันยายน 2569

  1. พิธีการศุลกากรส่งออกสินค้าทางเรือกรมศุลกากร · ปรับปรุง 27 กันยายน 2559 · ตรวจสอบ 11 กันยายน 2569
  2. Recommendation No. 6 — Aligned Invoice Layout Key for International TradeUNECE / UN/CEFACT · ตรวจสอบ 11 กันยายน 2569
  3. Recommendation No. 1 — United Nations Layout Key for Trade DocumentsUNECE / UN/CEFACT · ฉบับปรับปรุง 2017 · ตรวจสอบ 11 กันยายน 2569
  4. Incoterms® 2020International Chamber of Commerce (ICC) · ตรวจสอบ 11 กันยายน 2569
  5. United Nations Convention on Contracts for the International Sale of Goods (CISG)UNCITRAL · ตรวจสอบ 11 กันยายน 2569
  6. ISO 4217 — Currency codesInternational Organization for Standardization (ISO) · ตรวจสอบ 11 กันยายน 2569
  7. GS1 Global Traceability StandardGS1 · ตรวจสอบ 11 กันยายน 2569
← ดูบทความทั้งหมดทดลองใช้ระบบ ↗