Hóa đơn và hóa đơn điện tử

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

Tổng quan nhanh

Một hóa đơn hiện đại gồm hai tài liệu trong cùng một tệp: một trang để con người đọc và một payload XML mà hệ thống thuế có thể đọc bằng máy. Trang này lần theo toàn bộ kịch bản hóa đơn lai, từ nghĩa vụ đến đầu ra: ZUGFeRD và Factur-X yêu cầu gì, NextPDF đính kèm và kiểm tra payload có cấu trúc như thế nào, và ở điểm nào trách nhiệm về sự phù hợp không còn nằm ở engine mà chuyển sang bạn.

Vì sao điều này quan trọng

Nhiều khu vực pháp lý hiện nay bắt buộc dùng hóa đơn có cấu trúc trong giao dịch giữa doanh nghiệp với doanh nghiệp hoặc giữa doanh nghiệp với cơ quan nhà nước. Điểm dễ vấp là một hóa đơn lai có thể trông hoàn hảo trên màn hình mà vẫn bị từ chối. Việc từ chối xảy ra với XML được nhúng, chứ không phải với các điểm ảnh. Nếu payload có cấu trúc thiếu định danh quy cách, khai báo sai profile, hoặc được đính kèm với mối quan hệ sai, nền tảng tiếp nhận sẽ loại nó. Về phía bạn, lỗi này thường diễn ra âm thầm và chỉ xuất hiện vài ngày sau đó, kéo theo một khoản thanh toán bị giữ lại.

Làm đúng ngay từ đầu, tại lớp tạo tệp, rẻ hơn nhiều so với việc lần theo sự cố trên từng hóa đơn sau khi đã đưa vào luồng xử lý.

Phiên bản ngắn gọn

• Một hóa đơn lai tuân thủ là một vật mang PDF/A với một payload XML phù hợp được nhúng dưới dạng tệp liên kết. Metadata của vật mang phải khai báo profile.
• Trường thường có tính quyết định đối với việc được chấp nhận là BT-24, định danh quy cách. Quy tắc nghiệp vụ BR-1 của EN 16931 yêu cầu mọi hóa đơn đều phải mang trường này. Giá trị là một URN định danh chính xác profile — ví dụ, với profile EN 16931 (COMFORT), giá trị là urn:cen.eu:en16931:2017.
• Vai trò của NextPDF là nhúng và kiểm tra cấu trúc đối với XML do bên gọi cung cấp. Nó không tạo nội dung hóa đơn và không phải là trình kiểm tra của cơ quan thuế.
• Bên phát hành vẫn chịu trách nhiệm về tính đúng đắn pháp lý và tài chính. Một kết quả kiểm tra không có lỗi là một đầu vào cho quyết định đó, chứ không phải một chứng nhận.

Cách NextPDF tiếp cận vấn đề này

NextPDF xem hóa đơn có cấu trúc là một hợp đồng xuyên tầng, chứ không phải một tính năng đơn lẻ. Engine core định nghĩa các interface — một embedder, một profile descriptor, một validator — và bậc Premium cung cấp các phần triển khai. Sự tách biệt đó là có chủ đích. Giao diện công khai được cố định trong core, nên các vị trí gọi và kiểm thử tham chiếu đến profile và kết quả một cách nhất quán, bất kể phía sau là bậc nào.

Quy trình có bốn giai đoạn, và thứ tự là quan trọng vì mỗi giai đoạn phụ thuộc vào giai đoạn trước đó.

1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. 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.
3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. 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.

Kịch bản hóa đơn điện tử lai từ đầu đến cuối: bạn tạo XML và chịu trách nhiệm về tính đúng đắn pháp lý của nó; NextPDF mang và kiểm tra cấu trúc của nó; nền tảng tiếp nhận đưa ra quyết định chấp nhận cuối cùng.

Hợp đồng của embedder là byte vào, byte ra: một vật mang PDF/A và một payload XML đi vào, còn các byte PDF lai được trả ra. Trước khi đính kèm bất cứ thứ gì, XML được phân tích qua một lớp bảo vệ được gia cố, lớp này từ chối DOCTYPE, giới hạn kích thước đầu vào, và không chấp nhận các ký tự điều khiển bị cấm trong XML 1.0. Thiết kế này loại bỏ các cuộc tấn công XML External Entity và Billion-Laughs ngay từ đầu, vì XML hóa đơn thường đến từ bên ngoài ranh giới tin cậy của bạn.

Profile descriptor trả lời bốn câu hỏi mà một hệ thống hạ nguồn đặt ra: URN profile chuẩn tắc, giá trị BT-24 cần khẳng định, một tên ổn định cho log, và một yếu tố phân biệt độc lập với bậc để các kiểm thử tương đương có thể gom nhóm kết quả. Descriptor phản ánh trung thực các khoảng trống. Profile ZUGFeRD MINIMUM không mang định danh quy cách BT-24, và descriptor trả về null cho nó thay vì tự dựng một giá trị. Đó cũng là lý do vì sao MINIMUM và BASIC WL không phù hợp với EN 16931. Engine mã hóa thực tế về số lượng (cardinality) thay vì giấu nó đi.

Human-factors note: Human-factors note

Validator có hai chế độ, và chế độ mặc định là chế độ thận trọng hơn. Ở chế độ mặc định, việc thiếu BT-24 được báo cáo dưới dạng cảnh báo để một pipeline sẵn có vốn chặn dựa trên một giá trị boolean không âm thầm đổi hành vi theo hướng xấu. Chế độ strict nâng phát hiện đó lên thành lỗi nghiêm trọng, khớp với ngữ nghĩa của các validator bên ngoài. Chế độ là một lựa chọn có chủ đích mà bạn đưa ra cho từng lần gọi. Engine không chọn thay bạn mức chấp nhận rủi ro, và nó cho bạn biết mức nào đang được áp dụng thay vì để bạn phải tự suy đoán.

Bằng chứng cho thấy điều gì

Hành vi nêu trên được neo vào ba nơi, và mỗi nơi mang một loại bằng chứng khác nhau.

Bản thân tiêu chuẩn đặt ra nghĩa vụ. Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 quy định mọi hóa đơn đều phải có định danh quy cách. Phụ lục kỹ thuật của Factur-X cố định các giá trị URN theo từng profile, bao gồm, với profile EN 16931, giá trị urn:cen.eu:en16931:2017. Bản thân vật mang là một vấn đề của PDF: Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 lưu ý rằng khả năng kết xuất đáng tin cậy và dự đoán được nhất đạt được khi tất cả phông chữ đều được nhúng — điều này liên quan trực tiếp, vì một hóa đơn cần đọc được trong mười năm tới không thể phụ thuộc vào môi trường phông chữ của trình đọc.

Chính Mã nguồn mới là thứ duy trì hợp đồng này. Evidence { } Code-backed Evidence: Code-backed Các EmbedderInterface, ProfileInterface, và ValidatorInterface trong core là những interface thực, không phụ thuộc vào bậc. ProfileType::isEn16931Conformant() mã hóa việc loại trừ MINIMUM / BASIC WL ngay trong hệ thống kiểu. ValidationResult là một DTO bất biến, trong đó isValid kết hợp “không có phát hiện lỗi” và “không có vi phạm quy tắc nghiêm trọng”.

Còn hành vi thì được tài liệu hóa ở mức năng lực cho bậc Premium: Evidence § Standard-backed Evidence: Standard-backed embedder đính kèm XML do bên gọi cung cấp ZUGFeRD 2.4 / Factur-X 1.08 CII hoặc XML UBL Peppol vào một vật mang PDF/A-4f hoặc PDF/A-3b với mối quan hệ tệp liên kết đúng. Validator kiểm tra mô hình ngữ nghĩa EN 16931 và định danh BT-24. Giai đoạn Schematron chạy các tập quy tắc CEN đã được biên dịch sang XSLT. Không bước nào trong số đó tạo ra hay sửa nội dung hóa đơn.

Ví dụ thực tế

Đoạn dưới đây minh họa điểm ghép nối, không phải là một bản tích hợp để sao chép và dán nguyên xi. Phần dựng vật mang và embedder đến từ bậc Premium, còn XML là của bạn.

<?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);
}

Thứ tự là điểm mấu chốt. Việc kiểm tra rẻ hơn nhiều so với một hóa đơn bị từ chối và một khoản thanh toán bị trì hoãn, nên nó chạy trước khi payload được đính kèm.

Hiểu lầm thường gặp

Hiểu lầm tốn kém nhất là “NextPDF làm cho hóa đơn của tôi tuân thủ.” Không phải vậy. Trang này nói rõ điều đó. Engine nhúng và kiểm tra cấu trúc của XML do bạn tạo. Một kết quả kiểm tra cấu trúc đạt có nghĩa là payload có hình thái mà EN 16931 mong đợi và khai báo profile mà bạn yêu cầu. Nó không có nghĩa là hóa đơn đủ điều kiện về mặt pháp lý, được cơ quan thuế phê duyệt, hay được bất kỳ nền tảng thông quan nào bảo đảm chấp nhận. Các phần mở rộng cấp quốc gia và các kênh truyền nhận thông quan nằm ngoài phạm vi của engine. Như chính EN 16931-1 diễn đạt, mô hình lõi mang thông tin cần thiết để hỗ trợ việc tuân thủ. Bên phát hành chịu trách nhiệm đáp ứng các quy định pháp luật liên quan.

Cạm bẫy thứ hai, khó thấy hơn: hỗ trợ một tiêu chuẩn không phải là tuân thủ tiêu chuẩn đó. Tuân thủ là một thuộc tính của tệp cuối cùng cộng với một validator, không phải thuộc tính của thư viện đã tạo ra nó.

Giới hạn và ranh giới

• NextPDF không tạo hay sửa nội dung hóa đơn. Bên gọi cung cấp XML hợp lệ và vẫn là bên phát hành hóa đơn. Danh sách phát hiện rỗng không làm cho một payload không phù hợp trở nên phù hợp.
• Việc nhúng có cấu trúc và kiểm tra Schematron là các năng lực thuộc bậc Premium. Core định nghĩa các hợp đồng; các phần triển khai đòi hỏi gói thương mại. Xem ranh giới bên dưới.
• Validator chỉ kiểm tra mô hình ngữ nghĩa EN 16931 và vùng chứa ZUGFeRD / Factur-X / UBL. Nó không phải là trình kiểm tra của cơ quan thuế. Truyền qua SDI, Chorus Pro và XRechnung nằm ngoài phạm vi ở mức truyền tải.
• Các profile MINIMUM và BASIC WL không phù hợp với EN 16931 và không mang định danh quy cách BT-24 — đây là chủ đích, phản ánh số lượng (cardinality) của tiêu chuẩn, chứ không phải là một giới hạn của engine.
• Engine Schematron cần ext-xsl. Các tập quy tắc được biên dịch tại thời điểm build. Runtime chỉ thực thi XSLT đã được biên dịch sẵn, trong khi tải tài nguyên qua mạng và hệ thống tệp đều bị vô hiệu hóa.
• Trang này mô tả hành vi ở mức năng lực. Nó không khẳng định rằng tệp sẽ được bất kỳ cơ quan hay nền tảng cụ thể nào chấp nhận.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ Core định nghĩa các hợp đồng xuyên tầng (EmbedderInterface, ProfileInterface, ValidatorInterface) nhưng không kèm theo phần triển khai hóa đơn có cấu trúc nào. Một vật mang PDF thuần không có payload có cấu trúc là kết quả khi chỉ dùng Core.
Pro	○ Việc nhúng CII Factur-X 1.08 vào một vật mang PDF/A và các profile descriptor EN 16931 đều có sẵn.
Enterprise	○ Bổ sung việc nhúng UBL Peppol BIS 3.0, CIUS B2G XRechnung, kiểm tra XML COMPAT/STRICT, và engine quy tắc Schematron chạy trong tiến trình.

Tài liệu liên quan

• Lưu trữ và PDF/A — vì sao vật mang hóa đơn là một tệp PDF/A và điều đó bảo đảm gì cho khả năng đọc lâu dài.
• Hướng dẫn quyết định tích hợp — gói nào trong hệ sinh thái phù hợp với một pipeline lập hóa đơn (tạo theo hàng đợi, cầu nối framework, hay Connect).
• Vận hành NextPDF trong môi trường production — cách theo dõi các phát hiện và lỗi kiểm tra khi hóa đơn được xử lý ở quy mô lớn.

Thuật ngữ

• Hóa đơn lai — một tệp PDF duy nhất vừa là trang để con người đọc vừa là payload hóa đơn XML nhúng đọc được bằng máy.
• ZUGFeRD / Factur-X — tên tiếng Đức và tiếng Pháp cho cùng một cách tiếp cận hóa đơn lai: một payload XML Cross Industry Invoice (CII) theo UN/CEFACT được nhúng trong một vật mang PDF/A.
• EN 16931 — tiêu chuẩn châu Âu định nghĩa mô hình dữ liệu ngữ nghĩa của các phần tử cốt lõi trong một hóa đơn điện tử.
• BT-24 (Định danh quy cách) — thuật ngữ nghiệp vụ của EN 16931 với giá trị là một URN định danh chính xác profile mà hóa đơn tuân theo. Được yêu cầu bởi quy tắc nghiệp vụ BR-1.
• Profile — còn gọi là mức độ tuân thủ (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Xác định những thuật ngữ nghiệp vụ mà một hóa đơn phải mang theo.
• Tệp liên kết — một tệp được đính kèm bên trong một PDF với một mối quan hệ được khai báo (AFRelationship) mô tả cách nó liên hệ với tài liệu hiển thị; cơ chế mang theo XML hóa đơn.
• Schematron — một ngôn ngữ quy tắc dùng để diễn đạt các quy tắc nghiệp vụ của EN 16931. NextPDF chạy các tập quy tắc CEN đã được biên dịch sang XSLT.