An invoice that reaches its recipient over Peppol has to clear three checks at once: the UBL 2.1 schema, the European standard EN 16931, and the Peppol BIS Billing 3.0 overlay that the network adds on top. This form builds all three into every document it produces, so you can hand over a sendable invoice without opening a specification.
What the form takes care of
Routing addresses. A Peppol invoice cannot be delivered without electronic addresses for both the seller and the buyer (BT-34 and BT-49), each paired with a scheme such as 0088 (GLN), 0192 (Norwegian organisation number) or 9930 (EU VAT). These sit at the front of the form rather than buried in an advanced panel, because without them the network has nowhere to send the document.
Tax totals that add up. Give each line a VAT category and rate, and the totals, the per-category breakdown, and the document sums are calculated for you, so the rule that ties the VAT total to the category amounts is satisfied without any manual arithmetic.
The reference the buyer expects. Most accounts-payable systems match an incoming invoice on a buyer reference (BT-10) or a purchase order (BT-13). The form asks for both, so your invoice lands in the right place instead of bouncing back.
Already have the data somewhere else?
If your invoice exists as a PDF, let the converter read it into UBL rather than retyping it. If you have it as UN/CEFACT CII XML (the syntax used by hybrid formats such as Factur-X and ZUGFeRD), the CII to UBL converter maps it across. Once you have a UBL file, you can run it through the validator or render it as a readable PDF.
Want the bigger picture first? Our guide to how Peppol works explains the network, access points, and where a document like this one fits.
Your entries are sent to our API only to build the XML, then discarded. We do not store invoice content and never pass it to anyone else.