Check whether the recipient requires a particular profile within the named invoice format. A broad syntax can allow more structures and values than the receiving workflow accepts. An exporter supporting the syntax generally is not automatically an implementation of the required profile.
The format-selection workflow records the profile alongside the format and version. The current creator does not implement formal profiles. Its country context and application field checks do not establish a national usage specification or verified business-process binding.
Ask what the profile controls
A profile or usage specification can constrain how the broader model is used. It may affect required fields, code lists, references, calculations or process identifiers. The exact scope depends on the actual specification, so obtain its documentation rather than relying on a generic definition.
Ask the customer for the precise profile name and identifier where relevant. Keep the expected version and source instruction with it. A phrase such as “standard profile” is incomplete if several different implementations use similar marketing language.
Do not infer the requirement solely from country. Two recipients in one country may operate different workflows, while a cross-border network may use a shared billing specification. The receiver’s actual instruction and applicable requirements should control the decision.
Distinguish format support from profile support
A software provider might create a broad UBL document without implementing the constraints needed by a particular billing profile. Another tool might create a hybrid PDF under one data profile but lack another profile’s coverage. Ask for the specific implemented combination.
A matching file extension cannot resolve this distinction. Two XML files may use different profiles, while two PDFs may differ in whether and how structured data is embedded. Inspect the actual output and documented scope rather than the icon shown in a download menu.
The recognised format’s own documentation is the appropriate source for its profile definitions. The creator’s current formats page describes application capability, not a promise that every educationally mentioned profile is available as an export.
Compare data requirements
Make a small requirement table showing each profile-specific fact and where the confirmed source value will come from. Identify gaps before entering dozens of rows. An endpoint scheme, exemption code or typed reference may have no equivalent in the current creator’s model.
Do not treat an extra sentence in notes as completion of a missing structured field. The final mapper needs the correct role and representation. A broad description can preserve context for a person without satisfying a typed profile requirement.
If the profile excludes or restricts a source feature, establish the appropriate representation rather than silently dropping information. The final document must still describe the intended transaction. A converter should report unsupported cases clearly instead of producing a plausible but changed invoice.
Confirm implementation evidence
Ask the final provider which profile release it supports and which validation it runs. Request representative fictional examples covering the kinds of conditions your transaction needs. A generic sample with one standard line may not exercise the relevant restrictions.
Inspect actual identifiers and fields in the generated document. A visual badge is not evidence of an implemented profile, and a declaration inside the file is not sufficient if the data violates its rules. The implementation and validation must support the claim.
Use the version-confirmation process to keep the profile and its release identifiable. Do not record only “latest”, since it cannot establish which rule set was tested or which production requirement the receiver confirmed.
Keep business meaning in view
A profile-valid structure can still contain an incorrect customer identifier or a wrong commercial quantity. Automated checks do not establish every factual input. Preserve the source evidence and review the transaction separately from the technical result.
Likewise, an accepted delivery route does not broaden the profile the receiver processes. Document and transport requirements need to agree. A successful submission event should not be used as the only evidence that the invoice’s underlying treatment and amounts are correct.
The current app can help organise supported data locally, but its JSON is application-owned and its printable output is not a formal profile implementation. Use a suitable final system if the confirmed requirement exceeds those capabilities.
Record the decision clearly
Keep the recipient, format, profile, version, source-data gaps, validator and delivery owner together. That record lets a later reviewer distinguish an implemented capability from a planned one and a current instruction from an obsolete example.
For a fictional test, prepare two invoices that differ only in a conditional reference required by the chosen profile. Check whether the final workflow detects the missing value. This tests a meaningful restriction rather than merely confirming that both files have the same extension.
After any profile or source revision, repeat the affected checks and retain the exact tested file. Accurate selection is a documented match between receiver requirements and real software behaviour, not a general assurance that a familiar format family will work everywhere.
Keep profile examples labelled with the exact release they demonstrate, so a convenient test file cannot silently become a permanent requirement after the receiving workflow changes.