Give your software provider the exact UBL target, confirmed source facts, known model gaps and required test evidence. Do not hand over a screenshot with a general request to make it compliant. The provider needs a concrete implementation brief that can be checked against the receiving workflow.
The UBL preparation workflow separates source preparation from formal export. The current creator does not generate UBL, validate recognised profiles or transmit invoices. Its JSON, CSV and printable output retain their documented application roles.
Specify the receiver and target
Identify the receiving entity and system, document type, syntax version, profile and accepted production release. Keep the actual instruction and confirmation date. Do not rely only on an unrelated sample or the word latest.
State any required delivery route and recipient identifiers separately. A correct file format does not perform submission. Identify the system or provider responsible for transport and the evidence expected from that action.
If a readable copy or supporting evidence is also required, record the relationship and consistency expectations. The receiver should not have to choose between conflicting representations of the same invoice.
Provide confirmed source facts
Include party roles, identifiers, addresses, document identity, dates, references, lines, tax decisions and payment instructions. Preserve values with their meanings and sources. A field accepting text does not establish which role the string serves.
Keep buyer routing, purchase orders, preceding invoices and payment references distinct. Preserve address components and identifier schemes where the target requires them. A combined description should not be the only source of several typed facts.
Use the appropriate review for tax and commercial decisions before mapping. The provider can implement representation without establishing every real-world determination. Make the boundary explicit so no required decision is silently assumed.
Identify current model gaps
List missing typed fields, precision limits, unsupported financial structures and absent validation behaviour. The creator lacks some formal endpoints, line periods, code mappings, price bases and adjustment relationships. Check which ones the actual target needs.
A note naming a requirement is not implementation. Give the provider confirmed components separately and require clear reporting of unsupported scenarios. Do not approve silent defaults or invented identifiers merely because generation succeeds.
If the transaction needs credit notes, document allowances or prepaid reconciliation, identify the final system that implements those models. Do not force them through positive-line prices or an unrelated discount field.
Require a mapping explanation
The provider should connect source facts to target roles, transformations and conditions. Inspect critical paths and amount relationships. A broad promise to export XML is insufficient evidence of an implemented UBL binding.
Confirm root and namespace handling, coded values, optional groups and required field dependencies. Keep the exact schema and profile context. A file opening in an editor does not establish those checks.
Ask how the implementation repairs a mapping failure and regenerates output. Repeated manual edits to downloaded XML can become hidden logic that is lost on the next invoice. The intended production process should be reproducible.
Agree representative tests
Use the fictional UBL test plan to cover distinct party and reference values, nontrivial lines, punctuation, conditional fields and negative cases. Keep expected results separate from what the exporter happens to produce.
Request actual output and validation evidence for the relevant cases. Do not accept screenshots or one simple example as proof of every supported scenario. Preserve known limitations in the handoff record.
Use fictional account and supporting-document information during technical demonstrations. Production invoice data needs an appropriate handling decision before it is sent to an external service. Local preparation does not authorise every later upload.
Assign final review and delivery
Identify who confirms source facts, reviews mapped meaning, runs technical validation and sends the final file. Keep each result tied to the exact version. An earlier report cannot approve edits made afterwards.
You can prepare and revise supported source data locally while those final responsibilities are organised. That remains useful preparation, but the current export must not be presented as a completed UBL document or successful network submission.
After final corrections, regenerate, retest and retain the intended delivered output with its evidence. Record any actual submission or recipient response separately from generation and validation.
A successful handoff makes the remaining implementation work explicit and reviewable. It does not guarantee legal validity, tax correctness or acceptance. Those broader claims need the appropriate factual, technical and operational evidence rather than a complete-looking form or reassuring standards label.
Before closing the handoff, ask the provider to repeat the target requirement, known unsupported cases and final responsibilities in its own implementation record. Compare that with the source brief. A discrepancy is easier to resolve before real documents are generated. Keep a simple acceptance checklist showing which output was inspected, which rule sets ran and who owns delivery. This prevents an earlier demonstration file from being mistaken for the final invoice and gives the next person enough evidence to repeat the workflow without reconstructing the original conversation.
Confirm the exact file intended for production delivery.