<aside> <img src="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" alt="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" width="40px" />

Delivery via API with Broker through Secure Network Channel (for example Peppol)

</aside>

An Orchestration sends the eInvoice to a broker API. The broker validates the eInvoice, delivers it to the customer over the Peppol network, and returns the response, UBL, and Peppol evidence. The orchestration then updates the eInvoice status in the eInvoicing Monitor.

<aside> <img src="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" alt="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" width="40px" />

Delivery via E-mail (for example Germany ZUGFeRD)

</aside>

This scenario does not use a broker or the Peppol network. The eInvoice is created as a ZUGFeRD invoice – a PDF/A-3 with the structured CII XML embedded – and e-mailed directly to the customer. The customer can read it as a normal PDF, and their system can read the embedded invoice data.

<aside> <img src="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" alt="notion://custom_emoji/aff1bfe0-9437-4ce0-beca-1b6cca452664/3d132e10-13ac-8141-8c2e-007ace997ee5" width="40px" />

Delivery via API with Broker through Government Portal (for example Poland KSeF, Italy SDICoop or Portugal AT)

</aside>

The eInvoice is submitted to the Polish government platform KSeF (Krajowy System e-Faktur). KSeF uses a clearance model: an invoice is legally valid only once KSeF has accepted it and assigned a unique KSeF number. The broker submits the eInvoice to KSeF and returns the KSeF number, the UPO (Urzędowe Poświadczenie Odbioru – Official Confirmation of Receipt), and the KSeF QR code. The QR code is added to the invoice PDF, which is then delivered to the customer by API.