Choose a UBL document type from the actual business event and recipient requirements. Invoice and CreditNote are distinct document structures with different roots and associated fields. Changing a title or inserting a negative amount into an ordinary invoice is not implementation of a credit-note message.

The UBL preparation workflow confirms that choice before mapping. The current creator prepares ordinary positive invoices only. It does not generate either UBL structure or manage formal credit-note and correction relationships.

Establish what the document does

Use the accepted transaction and appropriate business process to determine whether the document is an invoice, credit note or another required type. Do not let the available form choose the event. A correction to an issued invoice can require more than editing a local draft.

Keep references to the original document where the final process requires them. A preceding invoice relationship is not the same as reusing the old invoice number as the new document’s identity. Preserve the roles separately in preparation records.

If the event is uncertain, obtain the responsible accounting or legal review. This guide explains technical preparation, not a universal rule for when a credit note is required in every jurisdiction.

Confirm the target root and namespace

UBL defines separate invoice and credit-note document schemas. The root’s namespace is part of its identity. A matching local name without the intended namespace is not sufficient to establish the expected vocabulary.

The final exporter must generate the actual chosen structure and use the applicable schema and profile. A download named credit-note.xml can still contain the wrong document root. Inspect the output rather than relying on the filename.

Use the namespace review to identify what needs checking. Prefix wording is shorthand; the namespace and local name determine the element identity. A cosmetic prefix change is different from changing the document vocabulary.

Do not assume a credit-note document is an invoice with one renamed outer tag. The target has its own line structures and applicable rules. The mapper must implement the chosen document’s semantics under the receiver’s profile.

A generic source model may also lack the required type, reasons or preceding-document relationships. Identify those gaps before generation. Text written in notes does not create a typed reference or ensure the final totals follow the correct model.

The current creator rejects negative quantities and prices outside its ordinary model. Do not work around that behaviour to imitate a corrective document. Use final software that genuinely supports the required event and its representation.

Confirm profile support for the document

Ask the final provider whether the exact target profile supports the intended document type and scenarios. Broad UBL support does not establish that every document family, release or correction workflow is implemented.

OpenPeppol’s published billing material distinguishes invoice and credit-note bindings. Treat those as the specified profile context, not evidence that any UBL-shaped file is a compatible network document. The required version and rules still need checking.

Record the target type, syntax version, profile and validation configuration together. A report for an invoice schema cannot be assumed to validate a credit-note document, and an earlier sample may not cover the current scenario.

Test document selection explicitly

Use fictional invoice and corrective-event cases with distinct identifiers and clearly specified expected roots. Inspect the actual exported document identity and relevant line groups. A correct visible heading is only one part of the evidence.

Include a negative case where a target or required relationship is unsupported. The workflow should report that gap rather than silently generate an ordinary invoice under a changed filename. Clear rejection is more useful than a misleading successful download.

Keep source-fact review separate from technical checks. A correctly structured credit note can still refer to the wrong preceding invoice or use an unsupported commercial amount. Verify the relationship from the appropriate records.

Retain the complete event record

After edits, regenerate and validate the exact final file. Earlier outputs and reports retain their earlier scope. Keep the original relationship evidence, final document and delivery status distinguishable under your business process.

The creator’s current JSON, CSV and printable output remain preparation outputs for its supported positive invoices. They do not provide a UBL adapter, credit-note ledger or submission integration. Choose an implemented final workflow and report only the document and operational checks actually performed.

A practical document-selection test can use a fictional ordinary sale and a separately specified corrective event. Give them different identifiers and expected roots in the test plan. Confirm that the provider generates the intended document for each rather than changing only its filename or visible title. Next, omit the required preceding-document relationship in a controlled corrective case and inspect the actual response. Keep the expected business event and target representation separate in the record. This makes it possible to establish whether the provider supports the process, rejects it clearly or silently produces a different document that merely looks plausible.

The test should also preserve the new document identity and the intended preceding-document reference as separate facts.