--- title: "E-invoicing validator" slug: "e-invoicing-validator" tags: ["BIS Billing", "XRechnung", "ZUGFeRD"] status: "new" updated: 2026-10-27T09:03:09Z published: 2026-10-27T09:03:09Z canonical: "docs.lobstersoftware.com/e-invoicing-validator" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.lobstersoftware.com/llms.txt > Use this file to discover all available pages before exploring further. # E-invoicing validator With the "E-invoicing validator", you can check electronic invoices for formal, structural, and technical accuracy. This ensures that your invoices comply with official requirements before you send or process them further. The validator supports the following standards: - BIS Billing - XRechnung - ZUGFeRD The installed validation configuration determines which standard and which version are checked. ## How the check works The validator first automatically identifies the standard, version, and Document type. It then checks the document in two stages. ### Structure validation against XSD XML schema validation (XSD) checks whether: - The XML has the correct syntax. - The document contains the expected elements and attributes. - The correct order is followed. - Data types are used correctly. - It corresponds to the underlying UBL/CEN structures. This validation ensures that the document formally conforms to the expected XML model. ### Technical validation using Schematron XSD validation alone is not sufficient for e-invoices. Therefore, Schematron is also used. Schematron rules validate business and semantic requirements, for example: - Required fields in certain business contexts. - Dependencies between fields. - Consistency of totals. - Valid codes from code lists. - Rules from EN 16931. - Peppol-specific business rules. The validator then returns the result as a validation report; if there are errors in the invoices, it includes an error code and error message. ZUGFeRD and XRechnung invoices can be in PDF/A-3 format with an embedded XML file. In this case, the validator automatically extracts the XML file before the validation process. BIS Billing is validated exclusively as XML. ## Installation You can install the validator as a template from the template gallery (see [Start from template](/v1/docs/en/start-from-template-details-window)). There is a separate template available for each standard. During installation, the template automatically sets up all the necessary components: - **Validation profile** – In the `Connectors and Templates` group, create the `E-Invoicing Validation` profile. It contains one Subprofile per installed standard that performs the validation. - **HTTP endpoint** – The corresponding REST endpoint is created in the [API Manager](/v1/docs/en/integration-modules-rest-api). - **Validation files** – the Configuration Files are stored in the [File manager](/v1/docs/en/administration-system-file-manager) under `./E-invoicing_validation/`. The required Java libraries are provided in the `<install-dir>/lib` directory. To view the files that have been uploaded in the file manager, you need the **Super user** role. ![](https://cdn.document360.io/4be90b94-ec83-41d8-963e-962df16110d4/Images/Documentation/image-K95BQ2F8.png) ## **Access options** There are two ways to check an invoice. ### About the validation profile For each standard, the template provides a profile that performs the validation: - BIS Billing: `TEMPLATE_BIS-Billing_Validation` - ZUGFeRD: `TEMPLATE_ZUGFeRD_Validation` - XRechnung: `TEMPLATE_XRechnung_Validation` The profile receives the invoice to be validated as input. The subprofile performs the actual check for the respective standard. Before the call, the profile sets the variable `MSG_CALL_var__validator` to the name of the validation directory. This name is stored as a fixed value in the target structure field `config_validator_directory_name`. In this way, the profile specifies which standard and which version are to be checked. ![](https://cdn.document360.io/4be90b94-ec83-41d8-963e-962df16110d4/Images/Documentation/image-GDE6W3SV.png) The profile evaluates the Response from the subprofile call. If the document is valid, it sets the variable `var__is_document_valid` to `true`; otherwise, it sets it to `false`. The profile uses this variable to control two response paths: - **Response 1** is executed only when `var__is_document_valid = true` and forwards valid documents. - **Response 2** is executed only when `var__is_document_valid = false` and does not forward invalid documents. In this profile, both responses serve solely as a backup for the target data. You can view the validation results in the log overview: - **Display 1** shows the validation status. - **Display 2** shows the validation message. - The **Additional info** tab displays the complete validation results, including the individual messages. ![](https://cdn.document360.io/4be90b94-ec83-41d8-963e-962df16110d4/Images/Documentation/image-UOVMV76F.png) ### About the HTTP endpoint Each standard provides a REST endpoint: `http(s)://<your-server-name>/api/validation/v1/<standard>/<version>` Send the invoice to the endpoint via a POST request. You will receive the validation result as JSON. The endpoints for ZUGFeRD and XRechnung process both PDF/A-3 and XML. ![](https://cdn.document360.io/4be90b94-ec83-41d8-963e-962df16110d4/Images/Documentation/image-BYL3LUH9.png) At the end point, the action block calls the profile `E-INVOICING_VALIDATOR` and passes the name of the validation directory via the variable `MSG_CALL_var__validator`. ![](https://cdn.document360.io/4be90b94-ec83-41d8-963e-962df16110d4/Images/Documentation/image-KR7ZS35T.png) > [!NOTE] > **NOTE:** > > Anonymous access is enabled for all endpoints upon delivery. ## Standard-specific values | | BIS Billing | ZUGFeRD | XRechnung | | --- | --- | --- | --- | | **Version** | 3.0.21 | 2.5.2 | 3.0.2 | | **Directory in File manager** | ./E-invoicing_validation/validation-configuration-up-to-3.0.21 | ./E-invoicing_validation/validation-configuration-zugferd-2.5.2 | ./E-invoicing_validation/xrechnung-3.0.2-validator-configuration-2026-01-31 | | **HTTP endpoint (URI)** | `/bis-billing/3.0.21` | `/zugferd/2.5.2` | `/xrechnung/3.0.2` | | **Input format** | XML | PDF/A-3 or XML | PDF/A-3 or XML | | **Validation profile** | `TEMPLATE_BIS-Billing_Validation` | `TEMPLATE_ZUGFeRD_Validation` | `TEMPLATE_XRechnung_Validation` | | **Source of the validation files** | [KoSIT / OpenPeppol](https://github.com/itplr-kosit/validator-configuration-bis/releases) | [mustangproject](https://github.com/ZUGFeRD/mustangproject) | [KoSIT](https://github.com/itplr-kosit/validator-configuration-xrechnung/releases) | ## Update To update a standard to a new version, follow these steps: 1. Upload the new validation directory to [File manager](/v1/docs/en/administration-system-file-manager) under `./E-invoicing_validation/`. 2. For ZUGFeRD only: Customize the `scenarios.xml` file – it maps the documents to the appropriate validation files. Enter the paths to the new validation files and upload the file to the directory. 3. In the [API Manager](/v1/docs/en/integration-modules-rest-api), add a new endpoint or update the version in the URI of an existing endpoint. 4. Adjust the directory name in the variable `MSG_CALL_var__validator`— in the API Manager (`VALIDATOR_<Default>`) and in the validation profile (`TEMPLATE_<Default>_Validation`). German format for electronic invoices. ZUGFeRD embeds an XML data set with machine-readable invoice data in a PDF file. It meets the EU standard EN 16931 and is generated in the Lobster Data Platform via the Integration unit. Configuration in Phase 2, which determines the format of the input data. The document type determines how the parser reads the data and transfers it to the source tree. Examples: EDIFACT, XML, JSON, CSV, X12. XML (Extensible Markup Language) is a structured text format for storing and exchanging data. Content is enclosed within freely definable tags such as `<order>`. XML is human-readable, machine-processable, and platform-independent. In the Lobster Data Platform, you can receive, parse, and generate XML data. European network for the standardized exchange of electronic business documents. Peppol uses AS4 as a transmission protocol and is mandatory for e-invoicing in public procurement in the EU. Profile that is embedded in another profile and called as a substep. Subprofiles allow processing logic to be reused. The parent profile passes data to the subprofile and optionally receives results back. Files that store Lobster Data Platform settings. This includes profile configurations (`.lop`), system and tenant configurations, as well as XML or JSON-based mapping and connector configurations. The response determines how a profile sends processed data. In Phase 6, a response determines how and where the output data is sent or stored, e.g., via FTP, HTTP or e-mail. A profile can use several responses in parallel. JSON (**J**ava**S**cript **O**bject **N**otation) is a lightweight text format for data exchange. The Lobster Data Platform handles JSON in integration profiles, web resources, and API interfaces. Value resolvers convert JSON data to internal objects and vice versa. A module for configuring custom REST interfaces and MCP servers directly on the Lobster Data Platform. The API Manager administers endpoints, controls access via authentication and mapping criteria, and does not require an external middleware layer. ## Related - [Start from template](/start-from-template-details-window.md) - [API Manager](/integration-modules-rest-api.md) - [File manager](/administration-system-file-manager.md)