Test-data decision · 6 min guide
Synthetic or anonymized invoice test data?
A clean synthetic fixture is safer and easier to understand. An anonymized copy of the failing invoice is more useful when the bug depends on a customer document’s real-world shape. The right choice depends on what the test must prove.
When should you use a synthetic invoice?
Use a generated or hand-built fixture when you control the scenario: required-field parsing, a specific VAT category, rounding behavior, a missing buyer reference or a known validation rule. Synthetic data is easy to label, review, version and regenerate without involving customer information.
It is also the better starting point for network and conformance tests. Official Peppol examples and test services define known inputs and expected outcomes; a privacy-safe support copy is not automatically valid for those workflows.
When should you anonymize a real invoice?
Use a real-document duplicate when the defect survives only in the customer file: unusual namespaces, optional groups, extensions, line cardinality, document-level charges, embedded content or a combination that generic samples do not contain.
Replace party, contact, tax, payment, address and document identifiers before the file leaves its authorized system. Keep only the structure and values needed to reproduce the issue, and review every replacement rather than treating automated detection as complete.
How do you choose between the two?
Ask whether a synthetic fixture reproduces the same parser, calculation or validation failure. If yes, use it. If no, make a protected duplicate of the affected XML and move through anonymization and minimization before sharing or committing it to a test suite.
- Prefer synthetic data when the expected rule and document shape are already known.
- Prefer an anonymized duplicate when the unknown structure is the evidence you are investigating.
- Do not preserve names, addresses, account identifiers or free text merely because the XML still parses.
- Re-run the original failure after every minimization step so the fixture stays diagnostically useful.
A safe two-stage workflow
- Reproduce with a small synthetic file first; InvoiceForge can create a local Peppol UBL starting point.
- If it fails to reproduce, copy—not overwrite—the affected UBL, Peppol, XRechnung or CII XML.
- Anonymize the duplicate locally and inspect the replacement receipt.
- Remove unrelated lines, attachments, comments and optional blocks while repeatedly checking the defect.
- Label the final file as test data and store the reproduction purpose beside it.