ใบแจ้งหนี้และ e-invoicing

Spec: EN 16931-1:2026, BT-24 Spec: Factur-X 1.08 Spec: ISO 32000-2:2020, §14.13 Evidence: Mixed evidence

ภาพรวมโดยย่อ

ใบแจ้งหนี้สมัยใหม่คือเอกสารสองชั้นในไฟล์เดียว: หน้าที่คนอ่านได้ และ payload XML ที่เครื่องอ่านได้ซึ่งระบบภาษีนำไปแยกวิเคราะห์ หน้านี้ไล่เรียงกรณีใบแจ้งหนี้แบบไฮบริดตั้งแต่ภาระหน้าที่ตามข้อกำหนดไปจนถึงผลลัพธ์: สิ่งที่ ZUGFeRD และ Factur-X กำหนด วิธีที่ NextPDF แนบและตรวจสอบ payload ที่มีโครงสร้าง และจุดที่ความสอดคล้องพ้นจากขอบเขตความรับผิดชอบของเอนจินแล้วกลายเป็นหน้าที่ของคุณ

เหตุใดเรื่องนี้จึงสำคัญ

ปัจจุบันหลายเขตอำนาจศาลกำหนดให้ต้องใช้ใบแจ้งหนี้แบบมีโครงสร้างสำหรับการเรียกเก็บเงินระหว่างธุรกิจกับธุรกิจ หรือระหว่างธุรกิจกับภาครัฐ ประเด็นที่มักพลาดคือใบแจ้งหนี้แบบไฮบริดอาจดูสมบูรณ์แบบบนหน้าจอแต่ยังถูกปฏิเสธได้ การปฏิเสธเกิดขึ้นกับ XML ที่ฝังไว้ ไม่ใช่กับพิกเซล หาก payload ที่มีโครงสร้างขาดตัวระบุข้อกำหนด ประกาศโปรไฟล์ผิด หรือถูกแนบด้วยความสัมพันธ์ที่ไม่ถูกต้อง แพลตฟอร์มฝั่งรับจะปฏิเสธใบแจ้งหนี้นั้น ในมุมของคุณ ความล้มเหลวมักไม่แสดงสัญญาณชัดเจน และเกิดขึ้นหลายวันหลังจากนั้น พร้อมกับการชำระเงินที่ค้างอยู่เบื้องหลัง

การทำให้ถูกต้องเพียงครั้งเดียวในเลเยอร์ที่สร้างไฟล์มีต้นทุนต่ำกว่าการค่อย ๆ พบปัญหากับใบแจ้งหนี้แต่ละใบหลังเข้าสู่กระบวนการเคลียร์ไปแล้วมาก

ฉบับย่อ

ใบแจ้งหนี้แบบไฮบริดที่สอดคล้องคือ carrier PDF/A ที่มี payload XML ที่สอดคล้องฝังเป็น associated file เมทาดาทาของ carrier ต้องประกาศโปรไฟล์
ฟิลด์เดียวที่มักเป็นปัจจัยชี้ขาดการยอมรับมากที่สุดคือ BT-24 ตัวระบุข้อกำหนด EN 16931 มีกฎทางธุรกิจ BR-1 ที่กำหนดให้ทุกใบแจ้งหนี้ต้องมีฟิลด์นี้ ค่านี้คือ URN ที่ระบุชื่อโปรไฟล์ที่แน่ชัด — ตัวอย่างเช่น URN ของโปรไฟล์ EN 16931 (COMFORT) คือ urn:cen.eu:en16931:2017
หน้าที่ของ NextPDF คือ การฝังและการตรวจสอบเชิงโครงสร้าง ของ XML ที่ผู้เรียกใช้จัดหามา NextPDF ไม่ได้สร้างเนื้อหาใบแจ้งหนี้ และ ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี
ผู้ออกเอกสารยังคงเป็นผู้รับผิดชอบความถูกต้องทางกฎหมายและทางภาษี ผลการตรวจสอบที่ไม่พบปัญหาเป็นเพียงข้อมูลประกอบการตัดสินใจนั้น ไม่ใช่ใบรับรอง

วิธีที่ NextPDF จัดการเรื่องนี้

NextPDF ถือว่าใบแจ้งหนี้ที่มีโครงสร้างเป็น สัญญาข้ามชั้นบริการ (cross-tier contract) ไม่ใช่ฟีเจอร์เดี่ยว ๆ เอนจิน core กำหนดอินเทอร์เฟซ — ตัวฝัง (embedder) ตัวอธิบายโปรไฟล์ (profile descriptor) ตัวตรวจสอบ (validator) — และชั้นบริการ Premium จัดหาการนำไปใช้งานจริง การแยกส่วนนี้เป็นไปโดยเจตนา พื้นผิว public ถูกตรึงไว้ใน core ดังนั้นจุดเรียกใช้และเทสต์จึงเข้าถึงโปรไฟล์และผลลัพธ์ในแบบเดียวกัน ไม่ว่าชั้นบริการใดจะอยู่เบื้องหลัง

ลำดับงานมีสี่ขั้นตอน และลำดับมีความสำคัญเพราะแต่ละขั้นตอนขึ้นอยู่กับขั้นตอนก่อนหน้า

Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

สถานการณ์ e-invoice แบบไฮบริดตั้งแต่ต้นจนจบ: คุณเป็นผู้สร้าง XML และรับผิดชอบความถูกต้องทางกฎหมายของมัน; NextPDF เป็นตัวบรรจุและตรวจสอบเชิงโครงสร้าง; แพลตฟอร์มฝั่งรับเป็นผู้ตัดสินใจขั้นสุดท้ายในการยอมรับ

สัญญาของ embedder เป็นแบบรับไบต์เข้า ส่งไบต์ออก: carrier PDF/A และ payload XML เข้าไป แล้วได้ไบต์ของ PDF แบบไฮบริดออกมา ก่อนแนบสิ่งใด XML จะถูกแยกวิเคราะห์ผ่าน guard แบบเสริมความแข็งแกร่งซึ่งปฏิเสธ DOCTYPE จำกัดขนาดข้อมูลนำเข้า และปฏิเสธอักขระควบคุมต้องห้ามของ XML 1.0 วิธีนี้กำจัดการโจมตีแบบ XML External Entity และ Billion-Laughs ออกไปโดยการออกแบบ เนื่องจาก XML ใบแจ้งหนี้มักมาจากภายนอกขอบเขตความเชื่อถือของคุณ

profile descriptor ตอบคำถามสี่ข้อที่ระบบปลายทางถาม: URN โปรไฟล์แบบ canonical ค่า BT-24 ที่จะยืนยัน ชื่อคงที่สำหรับ log และตัวจำแนกที่เป็นกลางต่อชั้นบริการเพื่อให้เทสต์ความเท่าเทียมจัดกลุ่มผลลัพธ์ได้ descriptor แสดงช่องว่างที่มีอย่างตรงไปตรงมา โปรไฟล์ ZUGFeRD MINIMUM ไม่มี ตัวระบุข้อกำหนด BT-24 และ descriptor จะคืนค่า null สำหรับฟิลด์นั้น แทนที่จะสร้างค่าขึ้นมาเอง นี่คือเหตุผลที่ MINIMUM และ BASIC WL ไม่ สอดคล้องกับ EN 16931 เอนจินเข้ารหัสความเป็นจริงเรื่อง cardinality ไว้ แทนที่จะ ซ่อนมันไว้

ตัวตรวจสอบมีสองโหมด และค่าเริ่มต้นคือโหมดที่ระมัดระวัง ใน โหมดเริ่มต้น BT-24 ที่ขาดหายไปจะถูกรายงานเป็น warning เพื่อไม่ให้ไปป์ไลน์เดิม ที่ตัดสินด้วยค่า boolean ถดถอยลงอย่างเงียบ ๆ โหมด strict ยกระดับ สิ่งที่ตรวจพบเดียวกันนี้ให้เป็น hard error ซึ่งสอดคล้องกับความหมายของตัวตรวจสอบภายนอก การเลือก โหมดเป็นการตัดสินใจโดยเจตนาที่คุณกำหนดสำหรับแต่ละการเรียกใช้ เอนจินไม่เลือก ท่าทีด้านความเสี่ยงแทนคุณ และจะแจ้งว่าท่าทีใดกำลังทำงานอยู่ แทนที่จะ ปล่อยให้คุณคาดเดาเอง

หลักฐานระบุอะไร

พฤติกรรมข้างต้นยึดโยงอยู่ในสามจุด และแต่ละจุดมีหลักฐานคนละประเภท

ส่วนมาตรฐาน เป็นตัวกำหนดภาระหน้าที่ Spec: EN 16931-1:2026, BR-1 กำหนดให้ตัวระบุข้อกำหนด เป็นข้อบังคับบนทุกใบแจ้งหนี้ ภาคผนวกทางเทคนิคของ Factur-X กำหนดค่า URN ตายตัวสำหรับแต่ละโปรไฟล์ รวมถึงของโปรไฟล์ EN 16931 คือ urn:cen.eu:en16931:2017 ส่วน carrier เป็น เรื่องของ PDF: Spec: ISO 32000-2:2020, §9 ระบุไว้ว่า การเรนเดอร์ที่คาดการณ์ได้และน่าเชื่อถือที่สุดเกิดขึ้นเมื่อฟอนต์ทั้งหมดถูก ฝังไว้ — ซึ่งเกี่ยวข้องโดยตรง เพราะใบแจ้งหนี้ที่ต้อง อ่านได้ในอีกสิบปีข้างหน้าไม่สามารถพึ่งพาสภาพแวดล้อมฟอนต์ของโปรแกรมอ่านได้

ส่วนโค้ด เป็นจุดที่ตรึงสัญญาไว้ Evidence: Code-backed EmbedderInterface, ProfileInterface และ ValidatorInterface ของ core เป็นอินเทอร์เฟซจริงที่เป็นกลางต่อชั้นบริการ ProfileType::isEn16931Conformant() เข้ารหัสการแยกโปรไฟล์ MINIMUM / BASIC WL ออกไว้ในระบบชนิดข้อมูล ValidationResult เป็น DTO ที่เปลี่ยนแปลงค่าไม่ได้ ซึ่ง isValid เป็นการรวมเงื่อนไขของ “ไม่มีสิ่งที่ตรวจพบเป็น error” และ “ไม่มีการละเมิดกฎที่ร้ายแรง”

ส่วนพฤติกรรม ถูกบันทึกไว้ที่ระดับความสามารถของชั้นบริการ Premium: Evidence: Standard-backed embedder แนบ XML ที่ผู้เรียกใช้จัดหามาแบบ ZUGFeRD 2.4 / Factur-X 1.08 CII หรือ Peppol UBL XML เข้ากับ carrier PDF/A-4f หรือ PDF/A-3b พร้อมความสัมพันธ์ของ associated file ที่ถูกต้อง ตัวตรวจสอบจะตรวจสอบ โมเดลเชิงความหมายของ EN 16931 และตัวระบุ BT-24 ขั้นตอน Schematron รันชุดกฎ CEN ที่คอมไพล์เป็น XSLT ไม่มีส่วนใดที่สร้างหรือแก้ไข เนื้อหาใบแจ้งหนี้

ตัวอย่างเชิงปฏิบัติ

โครงสร้างด้านล่างใช้เพื่ออธิบายจุดเชื่อมต่อ ไม่ใช่การผสานรวมแบบคัดลอกแล้ววาง การสร้าง carrier และ embedder มาจากชั้นบริการ Premium ส่วน XML เป็นความรับผิดชอบของคุณ

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

ลำดับเป็นเรื่องสำคัญ การตรวจสอบมีต้นทุนต่ำเมื่อเทียบกับใบแจ้งหนี้ที่ถูกปฏิเสธและการชำระเงินที่ล่าช้า จึงต้องทำก่อนแนบ payload เสมอ

ความเข้าใจผิดที่พบบ่อย

ความเข้าใจผิดที่มีต้นทุนสูงที่สุดคือ “NextPDF ทำให้ใบแจ้งหนี้ของฉันสอดคล้องตามข้อกำหนด” ซึ่งไม่เป็นเช่นนั้น หน้านี้ระบุเรื่องนี้ไว้อย่างชัดเจน เอนจินฝังและตรวจสอบเชิงโครงสร้างของ XML ที่คุณเป็นผู้สร้าง การตรวจสอบเชิงโครงสร้างที่ผ่านหมายความว่า payload มีรูปแบบตามที่ EN 16931 คาดหวังและประกาศโปรไฟล์ที่คุณร้องขอ แต่ ไม่ได้ หมายความว่าใบแจ้งหนี้นั้นครบถ้วนตามกฎหมาย ได้รับการอนุมัติจากหน่วยงานภาษี หรือรับประกันว่าจะได้รับการยอมรับจากแพลตฟอร์มเคลียร์ใด ๆ ส่วนขยายระดับประเทศและการรับส่งเพื่อเคลียร์อยู่นอกขอบเขตในระดับเอนจิน ตามกรอบที่ EN 16931-1 กำหนดไว้ โมเดล core มีข้อมูลที่จำเป็นต่อการสนับสนุนความสอดคล้อง ผู้ออกเอกสารเป็นผู้รับผิดชอบในการปฏิบัติตามกฎหมายที่เกี่ยวข้อง

กับดักที่สองซึ่งสังเกตได้ยากกว่า: การรองรับมาตรฐานไม่ใช่การสอดคล้องกับมาตรฐานนั้น ความสอดคล้องเป็นคุณสมบัติของไฟล์สุดท้ายร่วมกับตัวตรวจสอบ ไม่ใช่คุณสมบัติของไลบรารีที่สร้างไฟล์นั้น

ข้อจำกัดและขอบเขต

NextPDF ไม่ได้สร้างหรือแก้ไขเนื้อหาใบแจ้งหนี้ ผู้เรียกใช้เป็นผู้จัดหา XML ที่ถูกต้องและยังคงเป็นผู้ออกใบแจ้งหนี้ การไม่มีสิ่งที่ตรวจพบไม่ได้ทำให้ payload ที่ไม่สอดคล้องกลายเป็นสอดคล้อง
การฝังแบบมีโครงสร้างและการตรวจสอบด้วย Schematron เป็นความสามารถของชั้นบริการ Premium Core กำหนดสัญญาไว้ ส่วนการนำไปใช้งานจริงต้องใช้แพ็กเกจเชิงพาณิชย์ ดูขอบเขตด้านล่าง
ตัวตรวจสอบจะตรวจสอบเฉพาะโมเดลเชิงความหมายของ EN 16931 และคอนเทนเนอร์ ZUGFeRD / Factur-X / UBL เท่านั้น ไม่ใช่ตัวตรวจสอบของหน่วยงานภาษี การขนส่งแบบ SDI, Chorus Pro และ XRechnung อยู่นอกขอบเขตในระดับการขนส่ง
โปรไฟล์ MINIMUM และ BASIC WL ไม่สอดคล้องกับ EN 16931 และไม่มีตัวระบุข้อกำหนด BT-24 — โดยการออกแบบ ซึ่งสะท้อน cardinality ของมาตรฐาน ไม่ใช่ข้อจำกัดของเอนจิน
เอนจิน Schematron ต้องใช้ ext-xsl ชุดกฎถูกคอมไพล์ในเวลา build รันไทม์เรียกใช้เฉพาะ XSLT ที่คอมไพล์ไว้ล่วงหน้าเท่านั้น โดยปิดการโหลดทรัพยากรจากเครือข่ายและระบบไฟล์
หน้านี้อธิบายพฤติกรรมในระดับความสามารถ ไม่ได้ยืนยันการยอมรับโดยหน่วยงานหรือแพลตฟอร์มใดโดยเฉพาะ

การฝังและการตรวจสอบใบแจ้งหนี้อิเล็กทรอนิกส์แบบมีโครงสร้าง — edition availability
Edition	Availability
Core	Core กำหนดสัญญาข้ามชั้นบริการ (`EmbedderInterface`, `ProfileInterface`, `ValidatorInterface`) แต่ไม่มีการนำใบแจ้งหนี้แบบมีโครงสร้าง ไปใช้งานจริง carrier PDF ธรรมดาที่ไม่มี payload แบบมีโครงสร้างจึงเป็น ผลลัพธ์ที่ได้จาก Core เพียงอย่างเดียว
Pro	การฝัง CII แบบ Factur-X 1.08 เข้ากับ carrier PDF/A และตัวอธิบายโปรไฟล์ EN 16931 พร้อมให้ใช้งาน
Enterprise	เพิ่มการฝัง UBL แบบ Peppol BIS 3.0, XRechnung B2G CIUS, การตรวจสอบ XML แบบ COMPAT/STRICT และเอนจินกฎ Schematron ที่ทำงานในโปรเซส

เอกสารที่เกี่ยวข้อง

การจัดเก็บถาวรและ PDF/A — เหตุใด carrier ของใบแจ้งหนี้จึงเป็นไฟล์ PDF/A และสิ่งนั้นรับประกันอะไรบ้างต่อการอ่านได้ในระยะยาว
คู่มือการตัดสินใจเรื่องการผสานรวม — แพ็กเกจในระบบนิเวศใดเหมาะกับไปป์ไลน์การออกใบแจ้งหนี้ (การสร้างแบบเข้าคิว, framework bridge หรือ Connect)
การใช้งาน NextPDF ในการผลิตจริง — วิธีสังเกตสิ่งที่ตรวจพบและความล้มเหลวจากการตรวจสอบเมื่อมีใบแจ้งหนี้ไหลเข้ามาปริมาณมาก

อภิธานศัพท์

ใบแจ้งหนี้แบบไฮบริด — ไฟล์ PDF ไฟล์เดียวที่เป็นทั้งหน้าที่มนุษย์อ่านได้และ payload ใบแจ้งหนี้ XML ที่ฝังไว้ซึ่งเครื่องอ่านได้
ZUGFeRD / Factur-X — ชื่อภาษาเยอรมันและภาษาฝรั่งเศสสำหรับแนวทางใบแจ้งหนี้แบบไฮบริดเดียวกัน: payload XML แบบ UN/CEFACT Cross Industry Invoice (CII) ที่ฝังไว้ใน PDF/A carrier
EN 16931 — มาตรฐานยุโรปที่กำหนดโมเดลข้อมูลเชิงความหมายของส่วนประกอบหลักของใบแจ้งหนี้อิเล็กทรอนิกส์
BT-24 (ตัวระบุข้อกำหนด) — business term ของ EN 16931 ซึ่งมีค่าเป็น URN ที่ระบุชื่อโปรไฟล์ที่แน่ชัดซึ่งใบแจ้งหนี้สอดคล้องด้วย กำหนดให้ต้องมีตามกฎทางธุรกิจ BR-1
Profile — หรือเรียกว่าระดับความสอดคล้อง (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG) เป็นตัวกำหนดว่าใบแจ้งหนี้ต้องมี business term ใดบ้าง
Associated file — ไฟล์ที่แนบอยู่ภายใน PDF พร้อมความสัมพันธ์ที่ประกาศไว้ (AFRelationship) ซึ่งอธิบายว่าไฟล์นั้นเกี่ยวข้องกับเอกสารที่มองเห็นได้อย่างไร ใช้เป็นกลไกสำหรับบรรจุ XML ใบแจ้งหนี้
Schematron — ภาษากำหนดกฎที่ใช้แสดงกฎทางธุรกิจของ EN 16931 NextPDF รันชุดกฎ CEN ที่คอมไพล์เป็น XSLT