The validator covers the common e-invoicing standards exchanged on the Peppol network, plus German hybrid formats and industry-specific XML variants. UBL Peppol BIS Billing 3.0 is the international standard accepted by all connected Access Points; it is what you use by default for cross-border e-invoicing via Peppol. NLCIUS is the Dutch implementation of EN 16931 and is used for both B2G and B2B in the Netherlands, including the Dutch rules on VAT, IBAN and references.

For the German market, the validator recognises XRechnung, the XML standard that the German government mandates for B2G invoicing. Factur-X and ZUGFeRD are hybrid formats in which a PDF carries an embedded CII-XML; the validator extracts that XML layer and runs the checks for the right profile. SI-UBL 2.0 and other XML variants used in specific industries or by large customers also work.

You don't have to choose the format upfront. The validator detects it automatically from the document content and then selects the matching schema and business-rule checks. For the full overview and the application per format, see the document formats.

Validating is a check: you are told whether a document complies with the matching profile, but it is not forwarded to the Peppol network or to a recipient. Sending actually transmits a document via an Access Point to the recipient, where it is picked up by their ERP or invoice processing.

In practice, you use the validator to check a document up front, for example during an integration or when you suspect a supplier is making a mapping error. If the schema is correct and all business rules pass, you know the document will also pass the receiving side's validation when actually sent. If something is wrong, you see per line what is wrong and where in the document, so you can fix it precisely.

For production sending you need a Peppol Access Point. Through the eConnect platform or a certified software package, you send documents to the right recipient. The validator uses the same validation engine as those sending pipelines, so a document that passes here also passes in operational sending. For the technical details see the Validate API.

Yes. The validator returns two things: an isValid status and a structured list of all assertions per validation layer. First you see whether the XML structure complies with the XSD schema. Next you see, for each business rule of the detected profile (Peppol BIS, NLCIUS, XRechnung), whether that rule passes, gives a warning or fails, with a descriptive text indicating which rule it concerns and where in the document the issue is located.

Your document itself is not modified or reissued; the validator is a check tool, not a transformation tool. If you want to send the document afterwards, you can do that via your own Peppol Access Point or via the eConnect platform. For automation you can plug the same check into your pipeline or CI by calling the Validate API; the responses are identical to what the online validator shows on screen.

For eConnect customers, validation can go one step further. Within PSB and Control you can add customer-specific validation rules to the standard profile, so internal checks run as well before a document goes to a recipient.

The online validator is a check tool. An uploaded file is used to run the validation and is not forwarded to the Peppol network or to another recipient. For the details on processing and retention we follow the prevailing security and privacy policy of the eConnect platform, aligned with the ISO 27001, NEN 7510 and ISAE 3402 certifications.

For use in your own pipeline or CI you use the Validate API. The same principle applies there: the document is used to run the validation and not kept for sending. You receive the validation response synchronously and use it to build an automated check step into your software, ERP or integration pipeline, without a shadow archive being created.

If you want to integrate validation in an environment where internal audit and compliance play a role, you can do so via PSB and Control. There you can add customer-specific validation rules via predefined validation options and have insight into all validations performed via the platform logging. For the details on how processing and retention are arranged, see quality and security.