A UBL Export Test Plan Using Fictional Invoice Data

Test a UBL exporter with fictional invoices that cover the actual roles and conditions your workflow needs. One simple file opening successfully is weak evidence. The plan should identify expected source meanings, target structure, calculations, validation and clear handling of unsupported cases.

The UBL preparation workflow assigns those tests to implemented final software. The current creator does not generate UBL or run formal standards validation. Its application tests and field checks establish current product behaviour, not a future adapter’s conformance.

Fix the target context

Record the document type, UBL version, required profile and validator configuration. Use the receiver’s actual production requirement rather than a broad latest label. Keep the source instruction with the plan.

Ask the provider which scenarios it implements and which remain unsupported. The test set should challenge that scope. Do not quietly remove a real requirement from the plan because the demo cannot express it.

Keep generation, validation and transmission separate. A local test file does not submit through Peppol or a government portal. If operational testing is needed, use an authorised test process and retain its evidence separately.

Design distinguishable source data

Give fictional seller and buyer records different names, addresses and identifiers. Use different values for invoice number, buyer reference, order and payment reference. This makes role exchanges visible without using real customer information.

Include two lines with different units, quantities and price bases appropriate to the implemented model. Equal or near-identical rows can hide a mapping that exchanges values. Record the expected facts before generation.

Keep all account and supporting-document data clearly fictional. The objective is to test document behaviour, not initiate a payment or expose a customer’s evidence to an unfamiliar service.

Check text and XML structure

Include punctuation and relevant international characters in fictional names and descriptions. Compare the parsed target text with the original source, not only raw entity spellings. Test for malformed output and double escaping.

Use the escaping review for that focused case. It should sit alongside root, namespace and schema checks, not replace them. A safely encoded string in the wrong group is still a mapping error.

Inspect optional groups the real workflow uses. A minimum file can pass while the generator appends references or payment information in an invalid position. The actual schema and profile rules should cover the generated structure.

Check financial relationships

Record expected line amounts and document totals under the implemented target model. Include nontrivial quantities and supported adjustments. Check intermediate values so a matching total cannot conceal a lost price base or duplicated discount.

Keep tax determination outside the technical test. Use clearly labelled illustrative treatment inputs to verify representation and arithmetic. Do not present a fictional rate as a recommendation for a real supply.

Where the current source lacks document allowances, prepaid reconciliation or another required model, test the final workflow’s gap reporting. An adapter should not invent the missing financial facts or silently change line prices to reach a target balance.

Add negative cases

Remove a required fact under the selected profile and confirm a clear failure. Use an invalid code, inconsistent relationship or unsupported scenario where relevant. Record expected and actual responses rather than merely checking that some error appeared.

A missing scheme, empty container and wrong namespace are different issues. Keep focused cases so the implementation’s behaviour is understandable. Combining every error into one file can hide which checks actually ran.

Do not weaken the validator or change source facts to silence a failure without resolving its cause. Repair the generation or preparation rule, regenerate and repeat affected tests. Retain the original failing case as regression evidence where useful.

Record acceptance evidence

For each case, keep input version, expected outcome, generated file, exporter configuration and validation report. Identify the specific check performed and its scope. A screenshot of a document does not establish its structured payload or rule coverage.

You can prepare supported fictional source details locally before handing them to a real UBL implementation. The current application JSON is a source model, not a ready-made standards test result. Review any transfer contract and additional required facts explicitly.

After changes to mappings, libraries or recipient requirements, repeat affected cases. Earlier success belongs to the tested version and cannot automatically approve a new configuration. Keep the final delivery file distinguishable from test and draft outputs.

A useful acceptance plan demonstrates both supported success and meaningful rejection. It does not certify tax facts, legal validity or recipient acceptance. Those need their own review and operational evidence in the appropriate final workflow.

Keep test approval separate from production approval. A fictional case establishes observed implementation behaviour under its recorded inputs and configuration. The real invoice still needs accurate party facts, treatment decisions and authorised instructions. A provider should be able to identify which evidence covers the adapter and which covers the actual transaction, without using one generic valid label for both. This distinction makes test results useful while preventing an integration demonstration from becoming an unsupported assurance about a customer invoice.