How to Prepare Invoice Data for a UBL Export

Prepare a UBL export by confirming the recipient’s required document, profile and version, then giving an implemented exporter accurate source facts and a reviewable mapping. UBL is not a visual invoice template. The generated XML must use the correct structure and meanings, and the required validation must be run on the actual output.

You can prepare supported invoice data locally with the creator, but it does not generate UBL invoices or credit notes. Its JSON belongs to its own application model, CSV contains line items and browser printing supplies readable output. This guide explains preparation for a separate, verified UBL implementation.

Define the target document

Ask the receiver which production specification, syntax version and profile it accepts. Do not assume the newest general UBL release is the required binding. The European Commission’s syntax guidance illustrates why bindings identify particular versions rather than an unrestricted format family.

Confirm whether the business event needs an invoice, credit note or another document. These have different roots and structures. A negative price or changed heading does not implement a credit-note workflow, and the current creator only prepares ordinary positive invoices.

Use the Invoice and CreditNote root comparison before choosing a final adapter. Record the source event and required target type together so a later provider does not infer document semantics from a filename alone.

Build a source-to-target record

List the confirmed party, document, reference, line, tax and payment facts. For each, identify its role, source and intended target representation. A generic reference field cannot reliably supply every buyer, order, payment and preceding-document relationship.

Keep unsupported facts separately in preparation records. The creator lacks some typed endpoint, identifier, period, code and financial structures that a target profile may require. A note can preserve a reminder, but it does not create the formal field.

Do not invent required values to make generation succeed. Obtain identifiers and reasons from the appropriate party or reviewer. A structurally plausible string can still identify the wrong customer or express an incorrect tax determination.

Confirm namespaces and component roles

UBL uses defined namespaces for its document and shared components. XML identifies an element through its namespace and local name, not merely the visible prefix. A copied tag with a changed namespace can therefore become a different element.

Use the namespace review to understand that distinction. The familiar cbc and cac prefixes in examples are shorthand tied to declarations. Their labels alone do not establish that the intended UBL vocabulary is being used.

A final exporter should generate the correct structure through a deliberate implementation, not by concatenating arbitrary source keys into XML-shaped tags. Inspect actual namespace declarations and component locations when reviewing output.

Preserve party and line relationships

Seller and buyer groups must carry the facts of their intended parties. A payment recipient may have another role. Do not merge names and identifiers simply because the source interface has fewer panels than the target model.

For lines, keep description, quantity, unit, price basis and net amount connected. Screen position is not automatically an external line identifier. Different target fields can share the same local name while having different meanings because of their parent context.

The line tracing workflow helps review those relationships. Use fictional values that are visibly different across lines, so a swapped quantity or reference cannot hide behind equal totals.

Review units, prices and adjustments

Confirm whether the target needs a coded unit and a separate price-base quantity. The creator’s editable unit text does not perform code mapping or pack conversion. Its prices use two decimals and quantities up to four, which may not preserve every source agreement.

Keep allowance, charge and payment roles separate. A percentage line discount is not a complete model for document-level adjustments or prepaid amounts. A matching final total does not prove that the target’s monetary relationships were implemented.

Use final software that genuinely supports the required financial model. Do not alter a quantity or tax category solely to force a narrower preview to match the expected balance. Preserve the accepted commercial facts and appropriate treatment decisions.

Handle XML safely

Text content must be serialised so characters are preserved without becoming unintended markup. Use a suitable XML library and review escaping, encoding and invalid-character handling in the final implementation. Visual HTML escaping is not a verified UBL serialiser.

Use the XML escaping test guide with fictional names and descriptions containing punctuation. Check the parsed values as well as the raw file. A file that appears to contain an ampersand can still be malformed or double-escaped.

Do not hand-edit production XML casually to silence a validation error. Repair the source or mapping rule and regenerate where practical. Keep the change traceable and repeat affected checks on the final version.

Validate structure and business rules

UBL schema validation addresses defined structural requirements such as element relationships and order. The applicable profile can add business rules, code restrictions and conditions. A successful parse is not evidence that every required layer was tested.

Keep the exact target version, profile and validation configuration with the output. A report for another release or earlier revision cannot establish the current file’s status. Source-fact review remains necessary alongside technical checks.

The current creator does not perform these formal layers. Its application field checks are useful within their documented scope, but should not be reported as UBL validation or recognised standards conformance.

Treat supporting evidence carefully

If attachments or external supporting references are needed, confirm the receiver’s rules and what the exporter actually implements. A filename in notes is not an embedded document. A private link with an access token is not automatically safe customer-facing evidence.

Use fictional files for technical tests and minimise unnecessary customer or personal information in real supporting material. A readable invoice can carry less visible information in attachments or metadata, so review the complete final package.

Keep creation and transmission separate. The creator has no Peppol or government submission integration. Generating or validating XML in another tool does not by itself prove delivery or customer acceptance.

Finish with a reproducible handoff

Use the software-provider handoff checklist to assign source-data completion, mapping, formal validation and delivery. Include representative positive and negative cases, known unsupported scenarios and the exact receiver instruction. A provider should be able to explain the implemented scope without relying on a generic XML support claim.

For a practical test, use different fictional values for invoice number, buyer reference and payment reference, plus two lines with different units. Trace each through the generated target and compare its role with the source. Remove one required fact and confirm the workflow reports the gap instead of silently defaulting it.

Retain the source record, exporter configuration, actual file and validation evidence together. The useful preparation result is an accurate, reviewable implementation brief. UBL conformance, legal validity, transmission and acceptance require their own genuine implementation and evidence rather than an XML-looking output or a completed source form.

For an implementation handoff, separate three records: the source facts, the mapping rules and the generated-file checks. A fact can be correct while its mapping is absent; a mapping can be correct while an old file is delivered. Keeping the records distinct makes those failures diagnosable. Ask a colleague to trace one fictional buyer reference through all three without relying on a private explanation. Then repeat with an unsupported fact. They should be able to identify the missing capability and its owner instead of assuming the current preview completed it. This tests the handoff’s clarity before a real invoice depends on it.