Mustang से ZUGFeRD validate करना: क्या pass होता है, क्या fail, और क्यों

अगर आप 2026 में जर्मन B2B customer को e-invoice भेज रहे हैं, तो file या तो ZUGFeRD-compliant होगी या receipt पर bounce होगी। France में Factur-X के साथ भी यही है। Format एक PDF/A-3 wrapper है जिसमें EN 16931 CII XML attached होता है। इसे scratch से generate करना आसान नहीं, और validate करने के लिए reference engine चाहिए।

व्यवहार में वह engine Mustang (mustangproject.org) है। यह open-source Java project PDF/A-3 से embedded XML निकालता है और EN 16931 Schematron के खिलाफ validate करता है। ZUGFeRD और Factur-X के लिए open-source tools में इसका support सबसे गहरा है, और कई independent verifiers यही चलाते हैं।

यह post Mustang द्वारा पकड़े जाने वाले failure modes और इसे तेज तरीके से run करने का तरीका समझाती है।

Mustang असल में क्या check करता है

Factur-X या ZUGFeRD PDF देने पर Mustang लगभग यह करता है:

1. Embedded file extract करता है। PDF/A-3 attachments को /EmbeddedFiles name tree में रखता है। Mustang canonical filename खोजता है (factur-x.xml for Factur-X, zugferd-invoice.xml for ZUGFeRD 2.x) और bytes उठाता है।
2. AFRelationship check करता है। Attached file को Factur-X / ZUGFeRD baseline के अनुसार AFRelationship="Alternative" होना चाहिए। बाकी values (Source, Data, Supplement) fail हैं।
3. XMP namespace और version check करता है। Factur-X 1.0 urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# use करता है। ZUGFeRD 2.x urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# use करता है। गलत namespace या version string fail होगी।
4. XML को Cross-Industry Invoice (CII) की तरह parse करता है। XML well-formed होना चाहिए और सही CII root element (rsm:CrossIndustryInvoice) से शुरू होना चाहिए।
5. EN 16931 Schematron चलाता है। Validation का मुख्य भाग: ~200 business rules, field semantics, mandatory codes, totals math, VAT logic, party identifiers आदि।

Pass = invoice EU में किसी भी EN 16931-conformant AP system के लिए स्वीकार्य है। Fail = customer का AP automation receipt पर invoice reject करेगा और AR team को manual exception मिलेगी।

पांच failure modes जो सबसे ज्यादा दिखते हैं

Teams जब पहली e-invoices test करती हैं, validator के Mustang side में ये बार-बार आते हैं।

1. Wrong AFRelationship

ERROR: Embedded file factur-x.xml uses AFRelationship="Source",
expected "Alternative".

PDF spec attached files के लिए कई relationship types allow करती है। Factur-X / ZUGFeRD specifically Alternative मांगते हैं, यानी attached XML visible PDF content की alternative representation है। अगर आपका PDF generator Data use कर रहा है (कई libraries का default), Mustang तुरंत fail करेगा। Visible PDF ठीक render होगा, लेकिन structured payload AP system के लिए invisible रहेगा।

2. Wrong / missing XMP namespace

ERROR: XMP metadata missing fx:DocumentType or fx:DocumentFileName under
namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.

PDF के XMP packet को यह declare करना चाहिए कि यह कौन-सा Factur-X profile है (MINIMUM, BASIC, EN 16931, EXTENDED) और किस filename को खोजना है। Hand-written PDF/A-3 wrapper में यह आसानी से छूटता है; gPdf का /api/v1/e-invoice/render endpoint इसे auto-emit करता है।

3. CII XML well-formed है, पर EN 16931 Schematron fail

ERROR: BR-CO-25 — In an invoice (BR-01) the
  ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime is required when
  ram:DocumentTypeCode is 380.

Real-world failures का बड़ा हिस्सा यही है। XML syntactically valid है; business rules fail हैं। EN 16931 Schematron rules के stable IDs हैं (BR-01, BR-CO-25 आदि), जिन्हें EN 16931 specification में lookup कर सकते हैं। Common ones:

• BR-01: invoice में unique invoice number होना चाहिए।
• BR-04: invoice issue date चाहिए।
• BR-05: invoice type code चाहिए।
• BR-CO-25: document type “Commercial invoice” हो तो payment terms required।
• BR-Z-01: VAT category codes S, Z, E, AE, K, G, O, L, M में से होना चाहिए।

Source data fix करें, rebuild करें, फिर re-validate करें।

4. PDF/A wrapper validate नहीं होता

INFO: CII XML extracted and validates against EN 16931.
ERROR: PDF/A-3b conformance check failed: missing Output Intent.

यह वह case है जहां Mustang का XML check pass है, लेकिन underlying PDF/A-3 wrapper fail है। Common cause: XML सही लिखा गया, पर ordinary PDF emit हुआ, PDF/A-3 नहीं। Embedded file मौजूद है, पर archival wrapper rules पूरी नहीं होतीं। gpdf.com/validator/ parallel में veraPDF चलाकर इसे पकड़ता है: PDF/A-3 fail veraPDF column में दिखता है, जबकि Mustang XML pass दिखाता है।

5. Encoding / declaration mismatch

ERROR: XML declares <?xml version="1.0" encoding="UTF-8"?> but the
embedded byte stream is UTF-8 with BOM. Mustang strict mode rejects BOM.

यह तब common है जब XML tool UTF-8 BOM emit करता है और वही raw embed हो जाता है। Fix: embed करने से पहले BOM strip करें। gPdf का e-invoice endpoint इसे normalise करता है।

Java install किए बिना Mustang कैसे run करें

One-off check के लिए Java + Mustang CLI ठीक है। लेकिन ongoing verification — हर generated invoice, हर CI run जो e-invoice compliance assert करता है — में यह unnecessary friction है।

gpdf.com/validator/ Mustang को browser में run करता है:

1. Factur-X / ZUGFeRD PDF upload zone पर drag करें।
2. Validator embedded XML extract करता है और Mustang का Schematron engine चलाता है (JavaScript / WebAssembly में compiled, Cloudflare Worker में run)।
3. Mustang report, veraPDF PDF/A-3 report के साथ side-by-side वापस आता है, क्योंकि दोनों layers pass होनी चाहिए।
4. QA evidence के लिए JSON report download करें।

No login. No quota. Maven से install किए जाने वाले Mustang जैसी ही checking, बस free public service के रूप में।

TL;DR

Mustang 5 common failure modes पकड़ता है; उनमें से ज्यादातर का सार है कि file ऐसे tool से generated है जो fully-conformant Factur-X / ZUGFeRD PDF/A-3 emit नहीं करता। gPdf की E-invoice API एक call में compliant file emit करती है। validator result को Mustang + veraPDF से parallel verify करता है।

Mustang जिन bugs को पकड़ता है उनमें से अधिकतर wrapper या AFRelationship से जुड़े होते हैं, XML semantics से ही नहीं। File सही generate करना battle का बड़ा हिस्सा है; validator वह receipt है जो साबित करता है कि आपने सही किया।