A Peppol billing document and Peppol delivery are different parts of a workflow. The document must implement the required format and business rules. Delivery needs an actual supported transmission process and the correct recipient information. Completing one part does not prove the other has happened.
The format-selection workflow records both requirements. The current creator produces neither a verified Peppol billing document nor a Peppol transmission. Its application JSON, CSV and printable output are not network submissions.
Identify the required document
Ask which billing specification, profile and version the receiver expects. Record the implemented syntax and relevant validation rules. A request saying only “use Peppol” leaves important document and operational questions unresolved.
OpenPeppol’s billing documentation specifies document structures, code lists and business rules. That is why a file containing seller, buyer and totals is not automatically a compatible billing document. The fields need the correct meanings, locations and relationships.
Do not infer conformance from a UBL-looking sample alone. UBL provides a broader message structure; the intended billing profile constrains how it is used. A successful XML parse is narrower evidence than the required schema and business-rule validation.
Identify the actual recipient role
Collect the technical recipient information from a confirmed source. A customer email address and an electronic delivery identifier have different roles. A buyer reference used inside an invoice is also not automatically the network destination.
Preserve identifier value, scheme and intended role separately where the workflow requires them. Do not paste an endpoint into a billing-email field and assume a delivery connection exists. The creator does not perform endpoint discovery or verify network service capabilities.
If the receiving instructions are unclear, ask the responsible customer or provider to confirm them. A value copied from an unrelated invoice or public example is not evidence that it identifies your actual destination.
Confirm the sending capability
An operational route requires an implemented provider or integration appropriate to the workflow. Ask who performs transmission, which documents it supports and what evidence it returns. A local export button does not establish those capabilities.
The creator has no access-point connection, network credentials or delivery queue. It does not send the file when JSON is downloaded, and it does not know whether another service later submits it. Keep product wording limited to the actual preparation and export functions.
Do not add production credentials to an invoice, note or static repository to simulate integration. A future transmission feature needs its own secure implementation and validation. It should not be represented by a nonfunctional button or a badge.
Keep validation and delivery evidence separate
A document validation report describes checks on a particular file and configuration. A transmission receipt or status concerns an operational event. Customer processing or business acceptance may be another stage. Do not collapse all of them into one unsupported claim of success.
Record which file was validated and which version was sent. A corrected draft created after validation may need retesting before transmission. A successful send of an earlier file does not establish the status of the current revision.
The guide to extensions and compatibility evidence explains why a familiar file label is insufficient. The same principle applies to delivery labels: a page saying submitted is meaningful only when an implemented process and corresponding evidence support it.
Test the complete handoff safely
Use fictional data to test the mapping and any authorised test environment before handling real invoices. Include the references and conditional fields the intended transaction needs. A one-line example may not expose missing reasons or routing details.
Inspect the generated document and required validation result, then verify the operational status returned by the actual delivery provider. Do not assume a screenshot of the invoice demonstrates transmission. Keep the evidence for each stage identifiable.
Protect customer information and credentials in the process. Browser-local preparation and an external delivery service have different data flows. Confirm the authorised handling rather than silently sending invoice contents to a third party.
Finalise the receiver-led decision
If Peppol is required, identify the final document-producing software and actual transmission provider. Assign responsibility for source-data gaps, formal validation and delivery monitoring. Keep the required identifier and profile confirmation with that record.
The current creator can help organise supported fields and calculations before a separate handoff. It cannot promise Peppol compliance, delivery, receipt or acceptance. Use a workflow that genuinely implements those capabilities, and report the observed evidence at its actual scope rather than treating a local file download as a completed network transaction.
A useful handoff log can have separate statuses for source preparation, document generation, formal validation, transmission and recipient response. Mark each only from evidence of that stage. A validation report should not populate the transmission column, and a provider receipt should not be used as the sole evidence for a tax decision. This simple separation prevents one successful technical event from being reported as completion of the whole transaction.
Keep provider status wording with the corresponding evidence so later reporting does not overstate what the event established.