How to Check XML Escaping Before a UBL Export

Check XML escaping by comparing the original text with the parsed value produced by the final exporter. Characters used as XML syntax must be represented safely, while the intended business text must survive unchanged. A file can be malformed or double-escaped even when its raw text looks reassuring.

The UBL preparation workflow requires a genuine XML implementation. The current creator escapes its HTML preview and exports application JSON or CSV, but those functions do not establish a verified UBL serialiser.

Use text with meaningful punctuation

Prepare fictional names and descriptions containing an ampersand, angle-bracket characters and quotation marks where relevant. Use ordinary international characters too. The test should reflect the kinds of text your business actually handles, without using real customer data.

For example, a fictional name such as Pine & Reed tests whether the ampersand is preserved as text after XML parsing. The raw serialised form and parsed value need not look identical, because the serialisation represents some characters through XML syntax.

Do not repair the source name by deleting punctuation merely to make generation easier. That changes the business fact. The exporter should preserve valid source text according to the XML rules and report unsupported invalid content clearly.

Test the actual XML boundary

Use a suitable XML library rather than building production files through unchecked string concatenation. The implementation should distinguish text content, attributes and structure. User text must not become unintended elements or declarations.

W3C’s XML specification defines character and entity handling. Apply the relevant rules in the final implementation rather than assuming an HTML escaping function has identical behaviour in every XML context.

The creator’s preview protection has a different purpose: displaying entered content safely in HTML. A successful preview test does not prove correct UBL element creation, namespace handling or XML schema validity.

Detect double escaping

A pipeline can encode a value twice if one stage treats already escaped text as ordinary source content. The resulting file may parse but return visible entity-like characters instead of the intended name. Compare the parsed value, not only whether the file opens.

Keep the original source string in the fictional test record. After generation, parse the output with a namespace-aware XML tool and compare the intended element’s text with that source. This gives a concrete pass condition.

Do not use a raw search for one particular entity spelling as the whole test. Equivalent valid representations can exist, while a convenient-looking spelling can still sit in the wrong field or be escaped incorrectly by a later stage.

Review encoding and unsupported characters

Confirm that the declared encoding and actual bytes agree. Test characters outside simple ASCII where the workflow needs them. A readable editor view does not establish how another parser receives the file.

Define clear handling for invalid XML characters or unsupported source content. The implementation should report the issue rather than silently removing meaningful text or producing a file that only some tools can parse.

Keep this review separate from factual accuracy. Correctly encoded text can still name the wrong customer or describe the wrong supply. XML handling preserves the supplied facts; it does not verify them.

Combine escaping with structure tests

After checking parsed text, validate the actual target structure and required profile rules. A correctly escaped description in the wrong line remains a mapping error. A valid namespace does not repair a missing required value.

Use the element-order review to assess another structural requirement. Serialisation, schema order and semantic mapping are complementary concerns, so a test should not treat one successful layer as evidence of all the others.

Include two fictional lines with different punctuation and identifiers. Confirm that each parsed value remains associated with its own line. This exposes a pipeline that preserves strings but exchanges their contexts.

Retain reproducible evidence

Keep source strings, generated file, parsed results and validation configuration with the test. Repeat affected cases after a library, mapping or encoding change. A previous report belongs to the version it actually tested.

You can prepare supported source text locally, but a formal UBL export needs separate implemented generation and checks. Do not describe the current JSON, CSV or print output as standards XML because the text appears safely escaped in the preview.

Use fictional files when demonstrating parser failures and avoid uploading real invoice data to unfamiliar checkers. After production source corrections, regenerate the final output and repeat the relevant tests rather than hand-editing a downloaded file without a traceable rule change.

The useful acceptance condition is clear: the intended text survives in the correct target role, the XML is well formed and the required structural and business-rule checks pass. That technical evidence still does not establish tax correctness, legal validity, transmission or recipient acceptance.

For a parsed-value check, compare the fictional name Pine & Reed before export and after reading the intended target element with an XML parser. The comparison should use the business string, not only the raw file’s entity spelling. Retain both representations with the test so a later double-escaping regression can be diagnosed without guessing which stage changed the text.