Invoiceer e-invoicing tools

Create an e-invoice

create_einvoice

Read-only

Create a valid e-invoice from structured data: XRechnung 3.0 (UBL or CII), ZUGFeRD / Factur-X PDF (EN 16931) or Peppol BIS Billing 3.0. The file is checked with the official KoSIT validator before it is returned; if it fails, you get the rule errors instead of a file. XML comes back as text in xml, the ZUGFeRD PDF as base64 in pdf_base64. XRechnung needs a seller contact (contact, phone, email), a buyer email or Peppol ID (electronic address), a buyer_reference (Leitweg-ID for German authorities) and payment details (iban). Peppol needs peppol_id for seller and buyer.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "number": "<number>",
      "seller": "<seller>",
      "buyer": "<buyer>",
      "lines": "<lines>"
    },
    "name": "create_einvoice"
  }
}

Input Schema

Name	Required	Description	Default
`bic`	No
`iban`	No
`note`	No
`buyer`	Yes
`lines`	Yes
`format`	No		xrechnung-ubl
`number`	Yes
`seller`	Yes
`currency`	No		EUR
`due_date`	No	YYYY-MM-DD, default issue + 14 days
`issue_date`	No	YYYY-MM-DD, default today
`period_end`	No
`credit_note`	No
`paid_amount`	No	Already paid (BT-113), e.g. down payments
`skonto_base`	No	Optional base amount if Skonto applies to part of the amount due
`skonto_days`	No	Early-payment discount (Skonto): days; written into BT-20 in the XRechnung format (BR-DE-18)
`period_start`	No
`delivery_date`	No	YYYY-MM-DD delivery / service date (BT-72); default: issue date unless a period is given
`exempt_reason`	No	BT-120 text for VAT-exempt (E) lines; default for DE/FR small businesses without VAT ID: § 19 UStG / art. 293 B CGI
`payment_terms`	No
`skonto_percent`	No	Skonto percentage, e.g. 2
`buyer_reference`	No
`order_reference`	No
`payment_reference`	No
`preceding_invoice`	No	Original invoice number (credit notes)
`preceding_invoice_date`	No	YYYY-MM-DD, date of the original invoice (BT-26; required for French sellers)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / delivery_date

Added value: +{
+  "description": "YYYY-MM-DD delivery / service date (BT-72); default: issue date unless a period is given",
+  "type": "string"
+}

Changed4 schema fields changedOct 23, 2026

addedInput schema / properties / exempt_reason

Added value: +{
+  "description": "BT-120 text for VAT-exempt (E) lines; default for DE/FR small businesses without VAT ID: § 19 UStG / art. 293 B CGI",
+  "type": "string"
+}

addedInput schema / properties / preceding_invoice_date

Added value: +{
+  "description": "YYYY-MM-DD, date of the original invoice (BT-26; required for French sellers)",
+  "type": "string"
+}

addedInput schema / properties / seller / properties / supplier_id

Added value: +{
+  "description": "Seller identifier at the buyer (BT-29)",
+  "type": "string"
+}

addedInput schema / properties / seller / properties / tax_number

Added value: +{
+  "description": "Tax number (BT-32) if the seller has no VAT ID: German Steuernummer (Kleinunternehmer), French SIREN (franchise en base)",
+  "type": "string"
+}

Changed4 schema fields changedOct 22, 2026

addedInput schema / properties / paid_amount

Added value: +{
+  "description": "Already paid (BT-113), e.g. down payments",
+  "type": "number"
+}

addedInput schema / properties / skonto_base

Added value: +{
+  "description": "Optional base amount if Skonto applies to part of the amount due",
+  "type": "number"
+}

addedInput schema / properties / skonto_days

Added value: +{
+  "description": "Early-payment discount (Skonto): days; written into BT-20 in the XRechnung format (BR-DE-18)",
+  "type": "integer"
+}

addedInput schema / properties / skonto_percent

Added value: +{
+  "description": "Skonto percentage, e.g. 2",
+  "type": "number"
+}

AddedOct 21, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true already declared, the description adds real behavioral context: the file is run through the official KoSIT validator before return, and on failure the caller gets rule errors instead of a file. It also discloses the payload shape (XML as text in `xml`, ZUGFeRD as base64 in `pdf_base64`), which matters since no output schema exists. Missing only cost/latency or size limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences ordered by importance: what it produces, how it is verified and what comes back, then per-format prerequisites. The final prerequisite sentence is a compressed parameter checklist, but every clause carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 26-parameter nested tool with no output schema, it covers the essentials: output formats, validation behavior, returned fields, and the format-specific mandatory fields. The credit-note and payment-discount workflows are unaddressed, but schema-level descriptions partially cover those, leaving no blocking gap for a correct first call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38% across 26 parameters, so the description has to compensate. It successfully explains the conditional requirements for buyer_reference, peppol_id, contact/phone/email and iban, but says nothing about the credit-note flow (credit_note, preceding_invoice, preceding_invoice_date), the Skonto fields, paid_amount, period_start/end, or the format enum values, all of which are left to schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb+resource ("Create a valid e-invoice from structured data") and enumerates the exact output standards (XRechnung 3.0 UBL/CII, ZUGFeRD/Factur-X, Peppol BIS 3.0). That is clearly distinct from the sibling tools validate_einvoice, read_invoice_pdf and explain_rule, which do not produce documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete per-format preconditions: XRechnung needs seller contact, buyer electronic address, buyer_reference (Leitweg-ID) and iban; Peppol needs peppol_id on both parties. It also implies validation is built in, which is why a separate validate_einvoice exists, but it never states when not to use this tool or that validate_einvoice should be used for existing files.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Invoiceer e-invoicing tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?