Mustangproject · Prüfbericht · Help

Mustang: an ampersand filename breaks the XML report

Separate a broken validation report from an invalid invoice and compare identical contents under a neutral filename.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

An unreadable XML validation report is not a successful invoice validation result. In the documented Mustang case, an ampersand in the filename broke the generated report. Compare identical file bytes under a neutral test name and inspect the raw report for complete, well-formed output. Do not globally replace “&” inside invoice content; reporting failures and invoice findings require separate handling.

Source basis: Q1 · Q2

Applies to
Covers the reported Mustang 2.26.0 report-generation issue. An announced correction does not establish its release or prove that a particular installed version contains it.
How to verify the result
Tested filenames produce complete, readable reports tied to the correct file, and a deliberately invalid test document remains rejected instead of passing when results are missing.
Your first check

Does the report change when only the filename changes?

Use an identical-content copy with a neutral name. A missing summary must not be interpreted as a passed validation by the integration.

Invoice validation runs, but the result XML cannot be parsed. The parser complains about an &, and the expected summary section is missing. A Mustang report identifies version 2.26.0 and a filename containing an ampersand as the trigger. Q1 The initial investigation concerns report generation, not automatically the invoice's contents.

Keep three outcomes distinct

“Checked and valid”, “checked and invalid” and “validation or report could not be evaluated” are separate outcomes. veraPDF also distinguishes processing failures from conformance findings. Q2 An integration must not treat the absence of a readable error as proof of success.

Compare unchanged input contents

  1. Preserve input and raw output. Keep the invoice, unparsed validation report and first parser error. Record Mustang, Java and integration versions. A shortened log excerpt may omit the exact character sequence that matters.
  2. Create a neutral-name copy. Keep the file contents identical while assigning a simple test filename without special characters. Compare hashes so that the experiment changes only the name. Retain an explicit link to the original document.
  3. Parse both reports independently. Check well-formedness and completeness. Failure only with the original name narrows the reporting path, but does not establish whether the invoice itself is correct.
  4. Locate the faulty output. If the problematic name appears in the generated report, investigate safe XML serialization there. Do not globally replace ampersands inside the invoice XML: that can damage valid entities and meaningful content.
  5. Inspect the automated decision. Determine what the integration does with a parse error, empty report or missing summary. These documents need a visible unresolved validation state. They must not silently proceed as fully validated merely because the usual failure field is unavailable.

Verify the correction

The original discussion announces a forthcoming correction; that is not verification of the version installed in your system. Q1 Test an applicable update or fix with a neutral name, special characters and a deliberately invalid test invoice. The process must produce readable reports while continuing to detect genuine failures.

For handoff, provide the filename, a sanitised report excerpt, version details and the identical-content comparison. Full confidential invoices are unnecessary if a synthetic document reproduces the report-generation problem. This is a technical assessment of processing behaviour, not legal approval of the invoice. Preserve the original file and its identity throughout any temporary renaming step.

Example: Identical content, different filename, different report

Constructed diagnostic example: A synthetic test file is available as sample.pdf and sample & comparison.pdf. Their bytes should be identical. The comparison below is a test design, not a claim about observed results.

  1. Establish equality: Compare checksums for both copies. If they differ, the filename was not the only change and the comparison must be narrowed again.
  2. Preserve complete output: Use the same validator build and configuration for both files. Keep each complete raw report and its associated error separately.
  3. Classify the outcome: A complete valid report, a complete invalid report and an unreadable result are three different states. If XML parsing fails only with the special-character filename, the reporting path is implicated. That does not establish invoice validity.

Expected observation: Each report remains attributable to its input file. A missing summary is explicitly recorded as a missing result rather than silently accepted as successful validation.

Success check: After a targeted correction, both filenames produce readable, complete reports. An additional deliberately invalid test file must still be rejected. This checks reporting and acceptance logic together. Invoice contents remain unchanged during the filename comparison; replacing every ampersand in the invoice XML is not part of this test.

Technical references: Mustangproject issue 1327: Ampersand in filename breaks XML report · veraPDF: CLI validation and reports.

Frequently asked questions

Does the filename make the invoice itself invalid?

The described finding initially concerns the generated report. The invoice still requires its complete intended validation afterwards.

Can I just search the report as plain text?

That may help diagnosis, but it does not replace reliable structured interpretation and explicit failure handling.

Describe your case

Support with this issue

We can inspect report generation, parsing and invoice acceptance logic.

Describe your case →Related service: Data & improvements

Sources