Review a supporting document’s purpose, contents and access before attaching or linking it in a UBL workflow. A readable invoice may carry additional data beyond its visible page. A filename in notes is not an embedded file, while an external URL can disclose access or become unavailable.

The UBL preparation workflow confirms the recipient’s evidence requirements and the exporter’s implemented scope. The current creator has no formal UBL attachment support. Naming a timesheet or purchase record in application notes does not add that structure.

Identify the evidence requirement

Ask what the receiver needs to substantiate the charge and how it expects the evidence. A document reference, an external link and an embedded attachment are different representations. Do not supply all of them automatically because a sample includes supporting material.

Record the purpose and authorised scope. The receiver may need an approved service summary rather than a complete internal timesheet. Preserve fuller evidence in appropriate business records instead of exposing every source detail in the invoice package.

OpenPeppol’s additional-document binding illustrates references and attachment roles in a specified context. Apply the actual target profile’s requirements rather than assuming any attached file is universally accepted.

Inspect contents before packaging

Read the complete supporting file, including additional sheets, comments and metadata where relevant. A first-page preview may not reveal internal prices, employee details or unrelated customer information. Keep the material necessary and appropriate for the receiver.

Do not embed credentials, private access tokens or documents containing unnecessary personal information. A supporting file is still part of a shared business package even if it is not visible on the main invoice page.

Use a clean authorised evidence version rather than forwarding an entire email chain. Keep the original source and approval internally where needed, while the customer receives the permitted material for the agreed purpose.

Confirm that a linked document is accessible through the intended authorised process and will remain available as required by the business workflow. Do not assume a private browser session or temporary token works for the receiver.

An access-bearing URL can disclose more than a simple document location. Review permissions and scope before including it in an invoice that may circulate widely. The creator does not authenticate external evidence or manage link access.

Keep link meaning distinct from a document identifier. A string naming a record is not the record itself, and a URL does not establish that the expected file was retrieved or accepted.

Confirm exporter capabilities

Ask the final provider how it implements the required supporting-document role, permitted types, names and size constraints. Record the exact target profile and version. A broad UBL claim does not prove every attachment scenario is supported.

Use the fictional export test plan before relying on the implementation. Do not upload real customer evidence to an unfamiliar converter simply to discover its capabilities. Testing and production handling need appropriate separate decisions.

The current application JSON and printable output do not become a formal attachment package when a filename appears in notes. Preserve the confirmed evidence requirement for a final system that genuinely implements it.

Test package integrity and references

Use a fictional supporting file with no real personal or account information. Generate the target and inspect whether the intended reference and attachment are present in their actual roles. Check the recovered contents as well as the visible invoice description.

Include a missing-file, invalid-reference or unsupported-type case under the implemented rules. Confirm clear reporting rather than silent omission. A successful XML parse does not establish that the supporting evidence was packaged correctly.

Keep names and descriptions distinguishable in tests. Two different attachments with the same generic title can make a review ambiguous. Use the actual profile’s naming constraints and confirm how the receiver identifies the intended evidence.

Retain the delivered version

Compare the final package with the approved source evidence after any revision. An earlier attachment can survive while the invoice lines change. Create a fresh output and repeat relevant checks so the package relates to the current charge.

Keep the exact generated file, evidence version, exporter configuration and validation result together. A report for the XML alone may not cover every content or privacy review. Record those scopes separately.

Formal technical validity does not decide whether disclosure was appropriate or whether the evidence proves the commercial charge. The creator’s useful role remains supported preparation; attachment implementation, authorised sharing, delivery and recipient acceptance require the appropriate final workflow and evidence.

A fictional attachment test can use a short evidence file containing only a demonstration service summary. Record its identity and expected relationship to the invoice, then recover it from the generated package or follow the authorised test link. Compare the contents with the source and inspect naming and access behaviour. Add a missing-evidence case and confirm clear reporting. This checks actual evidence handling instead of approving a package because the invoice page mentions a familiar filename.

Keep the recovered test contents with the comparison record.