In the published Peppol UBL billing binding, CustomizationID identifies the applicable specification context, while ProfileID identifies the business-process context. They are different declarations. Neither is the invoice number, and entering them does not make a document obey the rules they name.

The UBL preparation workflow confirms the required target context before generation. The current creator does not produce these formal UBL fields or implement the profile they would declare. Its application JSON is not a standards adapter.

Confirm the receiving context

Ask the recipient and final provider for the exact supported specification, process and release. Do not assume values copied from a sample apply to every UBL invoice. A national usage specification or another workflow can require a different combination.

Record the source instruction and production status. A draft or archived example may remain available online without being the current destination requirement. Avoid a mapping sheet that records only latest or standard profile.

Use the applicable official documentation to identify the required declarations. The provider should explain what it implements and how the generated data satisfies that context, rather than merely offering a field in which the identifiers can be pasted.

Keep the specification identifier separate

CustomizationID’s role in the referenced binding concerns the specification governing semantic content and rules. It is not a place for a seller’s branding, internal software version or commercial invoice identifier.

Do not edit a recognised declaration to add a company suffix without checking the actual profile rules. The string is technical context, not marketing copy. An apparently harmless change can make the receiving workflow interpret it differently or reject it.

A valid-looking declaration is still only a claim unless the output actually follows its requirements. Review fields, code lists, calculations and applicable conditions with the required validator. Do not treat the declaration itself as validation evidence.

Keep the process identifier separate

ProfileID describes a business-process context in the referenced billing profile. It is not automatically the same value as CustomizationID and should not be used as a substitute for a document type or payment reference.

Read the exact target documentation to establish how the process is identified and what it means. A broad UBL schema alone does not establish every receiver’s business-process requirements. The combination needs to match the actual workflow.

The guide to document roots and types explains another distinct role. Invoice or CreditNote structure, specification declaration and process declaration answer different questions; one cannot be changed cosmetically to implement the others.

Review source and mapping gaps

The creator has no dedicated formal declaration fields or UBL exporter. Writing the identifiers in notes preserves text for a person but does not generate the correct target elements. Keep the technical requirement in the final provider’s implementation record.

Do not let a declaration hide absent source facts. A file can name a profile while lacking the required endpoint, reason or typed reference. Resolve data and model gaps separately rather than assuming the declared context supplies missing values.

Likewise, a successful file parse cannot establish compliance with all declared rules. Use the schema, business-rule and recipient checks applicable to the target, and retain their scope accurately.

Test the declaration and behaviour

Use a fictional document generated by the actual final implementation. Inspect both declarations and compare them with the confirmed requirement. Then run the required validation and review critical mapped values.

A meaningful negative test uses a mismatched or unsupported declaration in a controlled test file and checks the response of the intended workflow. Do not experiment by sending altered production documents to a customer’s live system.

Record which component reported the failure and what it established. A declaration mismatch, missing required fact and wrong commercial value are different issues. The test evidence should help diagnose them rather than collapse every result into a generic failure label.

Retain a reproducible production record

Keep target context, generated declarations, exporter configuration, file and validation report together. If a profile or provider changes, repeat affected tests rather than assuming an earlier result transfers automatically.

Review the actual delivered file after revisions. Earlier downloads retain their earlier declarations and data. A matching filename cannot establish that the intended version was validated or sent.

The creator can support local preparation, but it does not provide these UBL declarations, formal validation or transmission. A reliable final workflow needs accurate source facts, implemented rules and appropriate evidence. Specification and process identifiers help identify that workflow; they do not substitute for its implementation or guarantee recipient acceptance.

A useful provider record has separate rows for specification declaration, process declaration, implemented rule sets and observed validation. Do not populate the implementation rows solely because the two declaration strings are present. In a fictional test, remove a required business fact while leaving the declarations unchanged and confirm the intended validator reports the defect. This demonstrates why the identifiers describe a claimed context but do not certify the contents. Keep the exact target release with the result.

Compare the generated declarations with the confirmed recipient instruction.