Create realistic e-invoice test data from a real XML

Why generic samples miss invoice bugs

Import failures often depend on a precise combination of namespaces, optional groups, references, allowances, tax categories, rounding or line-item cardinality. A tiny example from documentation may be valid but still fail to reproduce the customer’s case.

Starting from the affected XML preserves that shape. The goal is data minimization: remove the identifiers that are not necessary for the investigation while keeping the elements that trigger the behavior.

What to replace and what to consider keeping

• Replace company names, contacts, postal addresses, party IDs, tax IDs, bank accounts and invoice references.
• Keep namespaces, element ordering and optional groups when they may affect parsing.
• Keep amounts, currencies, tax categories and quantities only when they are necessary to reproduce the calculation.
• Remove attachments, free-text notes and embedded documents unless they are directly relevant.
• Use an unmistakable filename such as failing-credit-note-safe.xml and mark it as test data in the ticket.

Build a small regression fixture

After anonymization, confirm that the issue still reproduces. Then remove unrelated invoice lines or optional blocks one at a time. The smallest file that still triggers the problem is easier to understand, review and keep in an automated test suite.

Store the fixture with the code or test system—not in the production accounting record. Document which behavior it covers and avoid restoring live identifiers during later edits.

Validate for the purpose of the test

First check that the output is well-formed XML and still opens in the target parser. Run business-rule validation only if the defect depends on conformance. InvoiceVeil recalculates MOD-97 check digits for replacement IBANs, but other synthetic identifiers may still fail business rules, so a privacy-safe fixture is not automatically suitable for end-to-end network submission tests.