Validation

A preflight check of UBL XML against EN 16931 + Peppol BIS Billing 3.0 and the Slovak Financial Administration overlay, via POST /v1/partner/einvoice/validate. Use it before sending your own XML, to catch errors before you send the document to the network.

This endpoint is part of the partner portal and authenticates via session (a portal login), not the X-API-Key header. That's why you send partnerId in the body. It's meant for pre-validating XML you assemble yourself; invoices issued via POST /v1/agent/invoices generate UBL automatically.

If you integrate via the Agent API (X-API-Key key), use Preflight instead (POST /v1/agent/peppol/preflight): the same validation without a session, plus an SMP lookup of the recipient and normalized BIS 3.0 UBL, still with no DB write and no credit deduction.

Endpoint

Method	Path	Authentication
POST	`/v1/partner/einvoice/validate`	Partner session (portal)

Request body

Field	Type	Required	Description
`partnerId`	UUID	Yes	The ID of the partner you have access to.
`xml`	string (1–4,000,000 characters)	Yes	UBL Invoice / CreditNote XML to validate.

POST /v1/partner/einvoice/validate
Content-Type: application/json

{
  "partnerId": "7b8d…",
  "xml": "<?xml version=\"1.0\"?><Invoice …>…</Invoice>"
}

Response

The validator has 3 layers (EN 16931 / Peppol + SK Financial Administration overlay). If the validation runtime is unavailable, the response indicates it via available: false instead of a 5xx error.

{
  "data": {
    "available": true,
    "valid": false,
    "errorCount": 2,
    "warningCount": 1,
    "issues": [
      {
        "layer": "sk-fs-overlay",
        "severity": "error",
        "code": "SK-BT-35-REQUIRED",
        "message": "Seller address line is mandatory for Slovak e-invoice export.",
        "location": "Invoice/AccountingSupplierParty/Party/PostalAddress/StreetName",
        "businessTerm": "BT-35"
      }
    ]
  }
}

Field	Type	Description
`available`	boolean	Whether the validation runtime was available. When false, the other fields are empty / null.
`valid`	boolean \| null	true if there are no errors (errorCount === 0). null if available is false.
`errorCount`	int	Number of errors (severity error): these block sending.
`warningCount`	int	Number of warnings (severity warning): these don't block, but we recommend fixing them.
`issues`	array of objects	The list of findings. See the table below.

The issue object

Field	Type	Description
`layer`	`en16931-peppol` \| `sk-fs-overlay`	The layer that generated the finding.
`severity`	`error` \| `warning`	error blocks sending, warning doesn't.
`code`	string	A machine-readable code (e.g. SK-BT-35-REQUIRED).
`message`	string	A human-readable description.
`location`	string (optional)	An XPath to the problematic location in the document.
`businessTerm`	string (optional)	The EN 16931 business term (e.g. BT-35).

When to validate

Run validation whenever you generate UBL XML with your own logic and want to verify completeness before sending. The SK Financial Administration overlay only activates for invoices with a Slovak seller (Country/IdentificationCode = SK); inbound invoices from foreign suppliers are validated only against EN 16931 / Peppol. The most common errors involve a missing seller/buyer address (SK-BT-35/37/38, SK-BT-50/52/53) and a missing schemeID on the registration identifier (SK-BT-30/47), the same rules that block sending. More context in the Invoices section.