# XRechnung Validator and Generator (EN 16931) (`omargnagy/einvoice-en16931`) Actor

Returns a pass or fail verdict and every failing rule ID for XRechnung 3.0.2 and EN 16931 e-invoices (UBL or CII) and ZUGFeRD or Factur-X PDFs in the EN 16931 profile, using the official KoSIT validator. Also generates XRechnung XML and Factur-X PDFs from JSON, and extracts invoices to JSON.

- **URL**: https://apify.com/omargnagy/einvoice-en16931.md
- **Developed by:** [Omar Nagy](https://apify.com/omargnagy) (community)
- **Categories:** Developer tools, Business, Automation
- **Security:** Limited permissions
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $14.00 / 1,000 validated documents

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## XRechnung Validator and Generator (EN 16931)

This XRechnung validator checks e-invoices against the official KoSIT rules and returns a pass or fail verdict with every failing rule ID, its message and its XPath. It covers XRechnung 3.0.2 and EN 16931 invoices in UBL or CII, and ZUGFeRD or Factur-X PDFs in the EN 16931 profile. The same actor also generates XRechnung XML and Factur-X (ZUGFeRD) PDFs from plain JSON, and extracts an existing e-invoice back into JSON.

Auf Deutsch: E-Rechnungen per API prüfen (XRechnung und ZUGFeRD) mit dem offiziellen KoSIT-Validator, mit Regel-ID für jeden Fehler, und XRechnung oder ZUGFeRD aus JSON erstellen.

It runs the reference implementations, unmodified: the **KoSIT Validator 1.6.3** with the **XRechnung 3.0.2 configuration released 2026-08-31**, and **Mustang 2.26.0** for Factur-X and ZUGFeRD PDFs. Every answer names those versions, so a verdict can be reproduced later.

> **Not legal or tax advice.** This is technical validation against the published rule sets. Sending an invoice to a buyer, a tax authority or a Peppol Access Point is outside this actor, and so is deciding what your business is required to do.

### Who it is for

- **Billing and ERP developers** who must send XRechnung or ZUGFeRD invoices and want to catch BR-DE-15 (missing Leitweg-ID) or BR-CO-16 (wrong amount due) before the buyer does.
- **Accounts payable teams** who receive e-invoices and need to know, rule by rule, why one was rejected.
- **Tax advisers and bookkeepers** who check many client invoices at once and want a written verdict per file.
- **AI agents** that need a deterministic e-invoice check as a tool, through MCP or the Apify API.

### What it does

| Operation | Input | Output | Price |
|---|---|---|---|
| `validate` | UBL or CII XML, or a ZUGFeRD or Factur-X PDF | `valid`, the matched profile, and every failing rule with its ID, severity and XPath | from $0.02 per document |
| `generate` | canonical invoice JSON | XRechnung or EN 16931 XML, validated before it is returned | from $0.03 per document |
| `generate-pdf` | canonical invoice JSON, optionally your own visual PDF | PDF/A-3 with the invoice XML embedded (Factur-X, also known as ZUGFeRD 2) | from $0.05 per document |
| `extract` | UBL or CII XML, or a ZUGFeRD or Factur-X PDF | canonical invoice JSON, each field named after its EN 16931 business term | from $0.01 per document |

`generate` validates its own output at no extra charge. If the document it would produce breaks a rule, you get the failing rules instead of an invoice your buyer would reject.

### How to use the XRechnung validator

1. Put one or more documents in **Documents**: a `url`, the XML as a string in `xml`, or any file (PDFs included) as `base64`.
2. Pick the **Operation**. A single document can override it with its own `operation`, and set its own `profile`, `pdfProfile` or `language`.
3. Start the run and read the dataset: one row per document, in input order.

The smallest input, which is also the prefilled example:

```json
{
  "operation": "validate",
  "documents": [
    {
      "name": "xrechnung-ubl-valid.xml",
      "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml"
    }
  ]
}
```

A mixed batch:

```json
{
  "operation": "validate",
  "documents": [
    { "name": "1001.xml", "url": "https://example.com/invoices/1001.xml" },
    { "name": "1002.pdf", "base64": "JVBERi0xLjcK..." },
    { "name": "1003", "operation": "generate", "profile": "xrechnung-ubl", "invoice": { "number": "1003" } },
    { "name": "1004.xml", "operation": "extract", "url": "https://example.com/invoices/1004.xml" }
  ]
}
```

- Generated files are saved in the run's key-value store. The dataset row carries the key in `fileKey`, plus `xmlFileKey` for `generate-pdf`. Two documents with the same `name` never overwrite each other: the second file gets a numbered key such as `inv-1-2.xml`.
- The run also writes an `OUTPUT` record: documents delivered, charged events per type, documents not evaluated, and whether the run stopped at your maximum cost.

### Output example

These rows come from a real run on build 0.1.6 (2026-10-08). A document that breaks a rule:

```json
{
  "index": 1,
  "name": "broken-payable-amount.xml",
  "operation": "validate",
  "ok": true,
  "charged": false,
  "result": {
    "valid": false,
    "profile": "EN16931 XRechnung (UBL Invoice)",
    "syntax": "ubl",
    "errors": [
      {
        "ruleId": "BR-CO-16",
        "severity": "error",
        "message": "[BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
        "xpath": "/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]/Q{urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2}LegalMonetaryTotal[1]",
        "step": "val-sch.1"
      }
    ],
    "warnings": [],
    "notices": [
      {
        "ruleId": "BR-DE-TMP-32",
        "severity": "information",
        "message": "[BR-DE-TMP-32] Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums entweder BT-72 \"Actual delivery date\", BG-14 \"Invoicing period\" oder in jeder Rechnungsposition BG-26 \"Invoice line period\" enthalten.",
        "xpath": "/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]",
        "step": "val-sch.2"
      }
    ],
    "steps": [
      { "id": "val-xsd", "valid": true },
      { "id": "val-sch.1", "valid": false },
      { "id": "val-sch.2", "valid": true },
      { "id": "val-xml", "valid": true }
    ],
    "validatorVersions": {
      "kositValidator": "1.6.3",
      "xrechnungConfiguration": "xrechnung-3.0.2 release 2026-08-31",
      "xrechnungSpecification": "3.0.2",
      "en16931Schematron": "as bundled in the KoSIT XRechnung configuration 2026-08-31",
      "mustang": "2.26.0",
      "actor": "0.1.6"
    },
    "specificationId": "urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0",
    "durationMs": 47,
    "source": "xml",
    "document": {
      "name": "broken-payable-amount.xml",
      "bytes": 6743,
      "sha256": "f19a443b30559134824b6adcf8cf3a524cbb5cc02629d3dd5ea5030d3b00582d"
    }
  }
}
```

A generated XRechnung, from the same run (`validatorVersions` left out here):

```json
{
  "index": 4,
  "name": "2026-0001",
  "operation": "generate",
  "ok": true,
  "charged": false,
  "result": {
    "profile": "xrechnung-ubl",
    "profileLabel": "XRechnung 3.0.2, UBL syntax",
    "syntax": "ubl",
    "bytes": 4632,
    "sha256": "8366555eeca12c411e7f991e74ef960d26d12007b843b437b4aff3b220f2b2ee",
    "validation": { "valid": true, "matchedProfile": "EN16931 XRechnung (UBL Invoice)", "warnings": [], "notices": [] },
    "fileKey": "2026-0001.xml"
  }
}
```

`charged` tells you whether the row was billed. That sample run was a test run without billing, so it reads `false`; on your runs it is `true` for every evaluated document.

`valid` is the KoSIT report's own verdict, not one this actor computes. Some rules are classified as warnings in the XRechnung configuration and still make the report reject the document. When that happens you get `valid: false` with an empty `errors` array and the reason in `warnings`.

#### When a document fails

A failed document gets a row with `ok: false` and an `error` object. It is not charged, and the run carries on with the next document.

| `error.code` | Meaning |
|---|---|
| `fetch_failed` | the `url` could not be downloaded, answered an HTTP error (the status is in the message), or did not finish downloading within 120 seconds |
| `invalid_url` | the `url` is not an http or https address |
| `invalid_document` | the document is not well-formed XML, not valid base64, or empty |
| `invalid_xml`, `unknown_syntax` | `extract` was given XML that is broken, or that is not a UBL or CII invoice |
| `no_embedded_invoice` | `extract` was given a PDF that carries no invoice XML |
| `document_too_large` | the document is over 32 MB |
| `invalid_entry` | an entry in `documents` is not an object |
| `unknown_operation`, `unknown_profile` | the entry's `operation` or `profile` is not one this actor knows |
| `missing_field`, `invalid_number`, `invalid_line`, `invalid_invoice` | the `invoice` JSON for `generate` or `generate-pdf` lacks a required field or holds a value that is not a number; the message names the field |
| `generated_document_invalid` | the invoice you sent for `generate` would produce a document the rule set rejects; the failing rules are in `error.details` |

### Which profiles are validated

The bundled configuration carries **XRechnung 3.0** (UBL and CII, invoice and credit note, plus the Extension and CVD variants) and **EN 16931 core** (UBL and CII). A ZUGFeRD or Factur-X PDF is validated when its embedded XML declares one of those, which in practice means the EN 16931 (COMFORT) or XRechnung profile.

A document that declares anything else, such as Factur-X **MINIMUM**, **BASIC WL** or **BASIC**, or an XRechnung version before 3.0, matches no scenario. You get `valid: false` with the rule ID `no_matching_scenario` and the specification the document declares in `specificationId`, and **you are not charged**, because no rule was evaluated. A PDF that carries no invoice at all answers `no_embedded_invoice`, also free.

### The canonical invoice JSON

One shape for `generate`, `generate-pdf` and `extract`. Every field is named after its EN 16931 business term, so you map your own system against the standard rather than against this actor.

```json
{
  "number": "2026-0001",
  "issueDate": "2026-09-01",
  "dueDate": "2026-10-01",
  "typeCode": "380",
  "currency": "EUR",
  "buyerReference": "04011000-12345-03",
  "deliveryDate": "2026-08-31",
  "seller": {
    "name": "Nordlicht Elektrotechnik GmbH",
    "vatId": "DE123456789",
    "electronicAddress": { "value": "rechnung@nordlicht-elektro.example", "schemeId": "EM" },
    "address": { "line1": "Werftstrasse 14", "city": "Kiel", "postcode": "24143", "country": "DE" },
    "contact": { "name": "Buchhaltung", "phone": "+49 431 1234567", "email": "rechnung@nordlicht-elektro.example" }
  },
  "buyer": {
    "name": "Stadtwerke Musterstadt AoeR",
    "vatId": "DE987654321",
    "electronicAddress": { "value": "erechnung@musterstadt.example", "schemeId": "EM" },
    "address": { "line1": "Rathausplatz 1", "city": "Musterstadt", "postcode": "12345", "country": "DE" }
  },
  "payment": {
    "meansCode": "58",
    "iban": "DE79000000001234567890",
    "terms": "Zahlbar innerhalb von 30 Tagen ohne Abzug."
  },
  "lines": [
    {
      "name": "Schaltschrankmontage",
      "quantity": 12,
      "unitCode": "HUR",
      "unitPrice": "78.50",
      "vat": { "categoryCode": "S", "rate": 19 }
    }
  ]
}
```

- **Required:** `number`, `issueDate`, `currency`, `seller` and `buyer` (each with a `name` and an `address`) and at least one line. XRechnung also needs `buyerReference` (BT-10, the Leitweg-ID for German public buyers), `payment`, and a seller `contact` with name, phone and email. The example above carries every field XRechnung asks for; leave one out and `generate` returns the failing rule instead of an invoice.
- **Optional:** `orderReference`, `contractReference`, `projectReference`, `precedingInvoiceReference` (for a credit note), `invoicePeriod`, `deliverTo` and `note`.
- **Computed when you leave them out:** line net amounts, the VAT breakdown (grouped by category code and rate) and every total. The arithmetic is decimal with two places and half-up rounding, because float arithmetic on money is what makes a total miss by a cent and fail BR-CO-15. Supply any of them and your value is used, which is how you model an allowance, a charge, a prepayment or a rounding line.
- **Credit notes** use type code `381`, which produces a UBL CreditNote and sets the CII type code accordingly.
- The test set behind this actor covers two VAT rates in one invoice, reverse charge, a credit note, a foreign currency, zero rated and intra-community supplies, a partial payment, a price base quantity and a rounding amount.

| `profile` for `generate` | What it writes |
|---|---|
| `xrechnung-ubl` | XRechnung 3.0.2, UBL 2.1 Invoice or CreditNote |
| `xrechnung-cii` | XRechnung 3.0.2, UN/CEFACT CII D16B |
| `en16931-ubl` | EN 16931 core, UBL 2.1 |
| `en16931-cii` | EN 16931 core, CII D16B |

| `pdfProfile` for `generate-pdf` | What it writes |
|---|---|
| `facturx-xrechnung` | PDF/A-3 with CII carrying the XRechnung profile |
| `facturx-en16931` | PDF/A-3 with CII carrying the EN 16931 (COMFORT) profile |

If you do not send your own visual PDF to `generate-pdf` (as `visualPdfBase64` on the document), a page is rendered from the invoice in English, German or French. The German and French templates come from Mustang and have not been reviewed by a native speaker.

### Pricing

You pay per document, by event. There is no start fee, and the platform compute is included in the event price.

| Event | Price |
|---|---|
| Validated document (`validate`) | from $0.02 |
| Generated XML invoice (`generate`) | from $0.03 |
| Generated Factur-X PDF (`generate-pdf`) | from $0.05 |
| Extracted invoice (`extract`) | from $0.01 |

Prices are lower on the Bronze, Silver and Gold plans. A batch of 100 XML invoices validated costs at most $2.00.

**Not charged:** a document that errors, a validation that never reached a rule set (`no_matching_scenario`, `no_embedded_invoice`), and the validation that `generate` and `generate-pdf` run on their own output. A document that is evaluated and fails is charged, because the failing rules are the answer you paid for.

**Your maximum cost is respected.** Before each document the actor checks that the run's maximum cost still covers that document's event. When it does not, the run stops, keeps what it finished, and says so in its status message, for example "Stopped at your maximum cost: 12 of 40 documents delivered, 12 charged."

### Use it from Claude, Cursor or any MCP client

Add this URL as a remote MCP server in Claude, Cursor, VS Code or any MCP client:

```
https://mcp.apify.com?tools=omargnagy/einvoice-en16931
```

For clients configured with JSON:

```json
{
  "mcpServers": {
    "einvoice": {
      "url": "https://mcp.apify.com?tools=omargnagy/einvoice-en16931"
    }
  }
}
```

Connect your Apify account when the client asks. The agent then sees one tool, `omargnagy--einvoice-en16931`, that takes `operation` and `documents` and returns the rows above.

From any HTTP client, one call runs the actor and returns the rows:

```bash
curl -X POST "https://api.apify.com/v2/acts/omargnagy~einvoice-en16931/run-sync-get-dataset-items" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"operation": "validate", "documents": [{"url": "https://example.com/invoice.xml"}]}'
```

From Python:

```python
from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("omargnagy/einvoice-en16931").call(run_input={
    "operation": "validate",
    "documents": [{"name": "1001.xml", "url": "https://example.com/invoices/1001.xml"}],
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(row["name"], row.get("result", {}).get("valid"), row.get("error"))
```

The run-sync endpoint waits up to 300 seconds. For PDF batches, start the run normally and read the dataset when it finishes.

### Speed and limits

- **XML is fast once the validator is up.** Each run starts the KoSIT validator once. On 2026-10-08 that took between 5 and 95 seconds, depending on how busy the host was. The first document after the start can take several seconds while the validator warms up. After that, an XML document usually takes well under a second: a valid XRechnung in 227 ms, a broken one in 47 ms. Put many documents in one run rather than one run per document.
- **PDFs are slower.** Every Mustang step starts its own Java process, and CPU on Apify scales with memory. At the default 1024 MB, validating a ZUGFeRD PDF took about 45 to 60 s and `generate-pdf` about 100 s; at 2048 MB, `generate-pdf` took 32 s. For PDF batches, set the run memory to 2048 MB.
- **Documents up to 32 MB** each. A `url` download stops at 32 MB, has to finish within 120 seconds, and fails if the server sends nothing for 60 seconds.
- **No Peppol BIS Billing 3.0 and no French national rules (BR-FR).** Only XRechnung 3.0 and EN 16931 core are carried, so Peppol and French CTC checks are not done.
- **No Factur-X MINIMUM, BASIC WL or BASIC scenario, and no XRechnung before 3.0.** These are read and extracted, not validated (see above).
- **No transmission.** No Peppol Access Point, French PDP, KSeF, myDATA or SdI, and no digital signatures or archiving.
- **Allowances and charges** at document or line level are carried through the totals if you supply them, but there is no structured `allowances` array yet.
- German rule messages are passed through exactly as the validator wrote them, because that wording is what you look up.

### How your documents are handled

- **What the actor writes.** A `validate` row carries the file name, the byte count, a sha256 and the verdict, never the whole document. An `extract` row does contain the invoice content (seller, buyer, bank details, lines), because returning it is what `extract` is for. Files from `generate` and `generate-pdf` are stored in the run's key-value store so you can download them.
- **What the actor never writes.** Document content never goes to the log. Java stack traces and raw validator process output are never passed through; they are mapped to an error code. The rule messages in a verdict come from the validator and can quote the value that broke a rule, for example an invalid date or IBAN, so a validate row can hold short fragments of your invoice. The KoSIT report's HTML rendering of your invoice is stripped before parsing.
- **What the Apify platform stores.** Apify keeps every run's input as the `INPUT` record of that run's key-value store. If you send invoices as `xml` or `base64`, that record holds them. Your dataset, key-value store and run input follow your Apify account's data retention. If that matters for your data, pass `url` instead of the document itself, or delete the run when you are done.

### Why now

| When | Where | What |
|---|---|---|
| since 1 January 2025 | Germany | every business must be able to receive an e-invoice; a plain PDF no longer counts as one ([BMF FAQ](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)) |
| 1 January 2027 | Germany | issuing e-invoices becomes mandatory above EUR 800,000 turnover |
| 1 January 2028 | Germany | issuing becomes mandatory for every business |

Running the Java reference validators yourself means a JVM, a rule set to keep current twice a year, and a scenario configuration to load. This actor does that part and tells you which version answered.

### FAQ

**Is this the official KoSIT validator?**
Yes. It runs the KoSIT Validator 1.6.3 with the official XRechnung 3.0.2 configuration released 2026-08-31, unmodified, and every row echoes those versions.

**Can it validate a ZUGFeRD PDF?**
Yes, when the embedded XML declares the EN 16931 (COMFORT) or XRechnung 3.0 profile. MINIMUM, BASIC WL and BASIC documents answer `no_matching_scenario` and are not charged.

**What does `valid: false` with an empty `errors` list mean?**
The XRechnung configuration rejected the document over a rule it classifies as a warning. The rule is in `warnings`.

**Am I charged for an invoice that fails?**
Yes, if it was evaluated: the failing rules are the result. Errors and documents that matched no rule set are free.

**Does it send my invoice to the buyer or to Peppol?**
No. It validates, generates and extracts. Transmission needs a Peppol Access Point or, in France, a registered PDP.

**How do I keep invoices out of Apify storage?**
Pass a `url` instead of `xml` or `base64`, and delete the run when you are done. `validate` rows never contain the whole document, but a rule message can quote the value that broke a rule.

**How do I cap what a run costs?**
Set a maximum cost per run. The actor checks it before each document and stops cleanly when the next one would not fit.

**Does it support Peppol BIS Billing 3.0?**
Not in this version. It is planned as a second scenario set.

**How often are the rules updated?**
XRechnung publishes in January and July. Each update ships as a new build, and every row names the configuration that produced it.

### Licences

The bundled validators are open source and unmodified: the KoSIT Validator, its XRechnung configuration and Mustang under Apache 2.0, and the EN 16931 Schematron under EUPL 1.2.

### Changelog

- **0.1.10 (2026-10-09)** a `url` download now stops at 32 MB as it arrives instead of being read whole first, and has to finish within 120 seconds. A document's own `pdfProfile` is used by `generate-pdf`, and a field the actor does not know is named in the log instead of being ignored silently. The README now says that a rule message can quote the value that broke the rule.
- **0.1.6 (2026-10-08)** documentation and listing. Document downloads now identify the actor and its Store page in the User-Agent.
- **0.1.5 (2026-10-08)** billing and error handling. The run respects its maximum cost and reports the real charged counts in an `OUTPUT` record. Validations that never reached a rule set are not charged, and every row says whether it was charged. A failed download is `fetch_failed` with the HTTP status, text that is not XML is `invalid_document`, one malformed entry no longer stops the run, and generated files with the same name no longer overwrite each other.
- **0.1.2 (2026-09-06)** five third-party Factur-X and ZUGFeRD PDFs added to the test set. A document whose specification matches no scenario answers `no_matching_scenario`, and rows carry `specificationId`.
- **0.1.0 (2026-09-06)** first version: validate, generate, generate-pdf and extract for XRechnung 3.0.2 and EN 16931 core, in UBL and CII, plus Factur-X PDF/A-3.

# Actor input Schema

## `operation` (type: `string`):

What to do with each document. validate returns the verdict and every failing rule ID. generate and generate-pdf build an invoice from canonical JSON. extract reads an invoice back into JSON. A document can set its own operation.

## `documents` (type: `array`):

One entry per document. For validate and extract, give url, xml (the XML as a string) or base64 (any file, PDFs included). For generate and generate-pdf, give invoice (the canonical JSON in the README). Optional per entry: name, operation, profile (for generate), pdfProfile, language and visualPdfBase64 (for generate-pdf). Other fields are ignored and named in the log.

## `profile` (type: `string`):

XML profile that generate writes. XRechnung is the German version of EN 16931, required by German public buyers and accepted for B2B. EN 16931 core is the European base. UBL and CII are the two allowed syntaxes.

## `pdfProfile` (type: `string`):

Factur-X (ZUGFeRD) profile that generate-pdf embeds in the PDF/A-3.

## `language` (type: `string`):

Language of the PDF page that generate-pdf renders when you do not send your own visual PDF. English is the default; German and French come from the Mustang templates.

## Actor input object example

```json
{
  "operation": "validate",
  "documents": [
    {
      "name": "xrechnung-ubl-valid.xml",
      "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml"
    }
  ],
  "profile": "xrechnung-ubl",
  "pdfProfile": "facturx-xrechnung",
  "language": "en"
}
```

# Actor output Schema

## `verdicts` (type: `string`):

No description

## `files` (type: `string`):

No description

## `summary` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "operation": "validate",
    "documents": [
        {
            "name": "xrechnung-ubl-valid.xml",
            "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("omargnagy/einvoice-en16931").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "operation": "validate",
    "documents": [{
            "name": "xrechnung-ubl-valid.xml",
            "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml",
        }],
}

# Run the Actor and wait for it to finish
run = client.actor("omargnagy/einvoice-en16931").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "operation": "validate",
  "documents": [
    {
      "name": "xrechnung-ubl-valid.xml",
      "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml"
    }
  ]
}' |
apify call omargnagy/einvoice-en16931 --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,omargnagy/einvoice-en16931"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/ZtoxnkMy3CXZOyReF/builds/K7rAdz7ldr2q087mZ/openapi.json