Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@einvoice-mcp validate this invoice XML for XRechnung 3.0 compliance"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-Server for German e-invoice compliance — XRechnung 3.0 & ZUGFeRD 2.x
An MCP server that enables AI agents (Claude, Cursor, Copilot) to validate, generate, parse, and check compliance of electronic invoices per EN 16931 — without a single line of integration code.
Germany mandated e-invoice reception for B2B as of January 2025 (BMF 2024-11-15). Issuance mandates follow in 2027 (Vorjahresumsatz > 800K) and 2028 (all businesses). Every German company needs tooling — this MCP server gives AI agents that capability.
Related MCP server: buchpilot-mcp
675 tests | 100% coverage (2106 stmts) | 0 failures | lint clean (ruff + mypy strict)
Run make test to verify.
Every mandatory Business Term is tested in generated XML output:
BT | Field | Test | Result |
BT-1 | Invoice number |
| PASS |
BT-2 | Issue date |
| PASS |
BT-3 | Invoice type code (380/381/384) |
| PASS |
BT-5 | Currency code (EUR) |
| PASS |
BT-10 | Buyer reference / Leitweg-ID |
| PASS |
BT-27 | Seller name |
| PASS |
BT-31 | Seller VAT ID (schemeID=VA) |
| PASS |
BT-32 | Seller tax number (schemeID=FC) |
| PASS |
BT-34 | Seller electronic address (schemeID=EM) |
| PASS |
BT-35..38 | Seller address |
| PASS |
BT-39 | Seller country subdivision |
| PASS |
BT-40 | Seller country code |
| PASS |
BT-41 | Seller contact name (BR-DE-5) |
| PASS |
BT-42 | Seller contact phone |
| PASS |
BT-43 | Seller contact email (BR-DE-7) |
| PASS |
BT-44 | Buyer name |
| PASS |
BT-49 | Buyer electronic address (schemeID=EM) |
| PASS |
BT-50..53 | Buyer address |
| PASS |
BT-54 | Buyer country subdivision |
| PASS |
BT-55 | Buyer country code |
| PASS |
BT-71 | Delivery date (§14 Abs. 4 Nr. 6 UStG) |
| PASS |
BT-20 | Payment terms text |
| PASS |
BT-22 | Invoice note |
| PASS |
BT-73/74 | Service period start/end |
| PASS |
BT-11 | Project reference |
| PASS |
BT-12 | Contract reference |
| PASS |
BT-13 | Purchase order reference |
| PASS |
BT-25 | Preceding invoice number |
| PASS |
BT-81 | Payment means type code |
| PASS |
BT-83 | Remittance information |
| PASS |
BT-84 | IBAN (SEPA credit transfer) |
| PASS |
BT-9 | Due date |
| PASS |
BT-14 | Sales order reference |
| PASS |
BT-29 | Seller registration ID (GLN) |
| PASS |
BT-36/37 | Seller address lines 2/3 |
| PASS |
BT-44 | Buyer contact name |
| PASS |
BT-46 | Buyer contact phone |
| PASS |
BT-47 | Buyer contact email |
| PASS |
BT-51/52 | Buyer address lines 2/3 |
| PASS |
BT-70..80 | Delivery location |
| PASS |
BT-127 | Line item note |
| PASS |
BT-155 | Seller item identifier |
| PASS |
BT-156 | Buyer item identifier |
| PASS |
BT-157 | Standard item ID (GTIN) |
| PASS |
BG-20/21 | Document-level allowances/charges |
| PASS |
BG-27/28 | Line-level allowances/charges |
| PASS |
BT-16 | Despatch advice reference |
| PASS |
BT-18 | Invoiced object identifier |
| PASS |
BT-23 | Business process type |
| PASS |
BT-89 | SEPA mandate reference (BG-19) |
| PASS |
BT-91 | Buyer IBAN (BG-19) |
| PASS |
BT-120 | VAT exemption reason text (BR-E-10) |
| PASS |
BT-121 | VAT exemption reason code |
| PASS |
BT-28 | Seller trading name |
| PASS |
BT-45 | Buyer trading name |
| PASS |
BT-17 | Tender or lot reference |
| PASS |
BT-133 | Buyer accounting reference |
| PASS |
BT-134/135 | Line-level billing period |
| PASS |
BT-147/148 | Gross price / price discount |
| PASS |
BT-158 | Item classification (CPV, etc.) |
| PASS |
BG-11 | Seller tax representative (BT-62..65) |
| PASS |
BG-10 | Payee party (BT-59..61) |
| PASS |
BG-18 | Payment card (BT-87/88) |
| PASS |
BT-159 | Item country of origin |
| PASS |
BG-30 | Item attributes (BT-160/161) |
| PASS |
BT-15 | Receiving advice reference |
| PASS |
BT-71 | Delivery location identifier |
| PASS |
BT-82 | Payment means text |
| PASS |
BG-24 | Supporting documents (BT-122..125) |
| PASS |
Skonto | Payment discount terms |
| PASS |
Rule | Description | Test | Result |
BR-CO-14 | TaxTotalAmount = sum of per-group CalculatedAmount |
| PASS |
BR-CO-14 | PDF/XML/API totals use identical per-group rounding |
| PASS |
BR-CO-10 | Line item LineTotalAmount quantized to 0.01 |
| PASS |
BR-DE-23 | IBAN mandatory when PaymentMeansCode=58 |
| PASS |
§14/4/2 | BT-31 or BT-32 must be present |
| PASS |
§14/4/6 | BT-71 or BT-73/74 must be present |
| PASS |
BT-3 | TypeCode validated against EN 16931 codes |
| PASS |
BT-25 | Credit note (381) must reference preceding invoice |
| PASS |
384-BT-25 | Corrective invoice (384) must reference preceding invoice |
| PASS |
RC-COUNTRY | Reverse charge: seller ≠ buyer country advisory |
| PASS |
IC-COUNTRY | Intra-community: seller ≠ buyer country required |
| PASS |
§13b UStG | Reverse charge: seller+buyer VAT IDs, 0% rate |
| PASS |
§4/1b UStG | Intra-community (K): buyer VAT ID, 0% rate |
| PASS |
§19 UStG | Kleinunternehmer: exemption note advisory |
| PASS |
LW-FMT | Leitweg-ID format advisory |
| PASS |
VAT-FMT | German USt-IdNr. format advisory (DE + 9 digits) |
| PASS |
§4/1a UStG | Export (G): 0% tax rate |
| PASS |
§33 UStDV | Kleinbetragsrechnung advisory (≤250€) |
| PASS |
BR-E-10 | Exemption reason required for TaxCategory E |
| PASS |
BR-DE-24 | SEPA DD: mandate (BT-89) + buyer IBAN (BT-91) |
| PASS |
BR-DE-15 | Payment terms (BT-20) required for XRechnung |
| PASS |
BR-DE-20 | Max one payment instruction type (no mix CT+DD) |
| PASS |
CC-BT-87 | Credit card PAN required when code=48 |
| PASS |
REP-BT-63 | Tax rep VAT ID required when BG-11 present |
| PASS |
IBAN | IBAN format validation (ISO 13616) |
| PASS |
BIC | BIC format validation (ISO 9362) |
| PASS |
Scenario | Description | Test | Result |
SchemeID stripping |
|
| PASS |
Numeric schemeID |
|
| PASS |
Description text |
|
| PASS |
Unicode safety |
|
| PASS |
BT-32 roundtrip | Steuernummer FC generate → parse |
| PASS |
TypeCode roundtrip | 381 Gutschrift generate → parse |
| PASS |
Delivery date roundtrip | BT-71 generate → parse |
| PASS |
Service period roundtrip | BT-73/74 generate → parse |
| PASS |
Electronic address roundtrip | BT-34 generate → parse |
| PASS |
Invoice note roundtrip | BT-22 generate → parse |
| PASS |
Payment terms roundtrip | BT-20 generate → parse |
| PASS |
Payment terms override | BT-20 text overrides days |
| PASS |
Purchase order roundtrip | BT-13 generate → parse |
| PASS |
Contract roundtrip | BT-12 generate → parse |
| PASS |
Project roundtrip | BT-11 generate → parse |
| PASS |
Preceding invoice roundtrip | BT-25 generate → parse |
| PASS |
Remittance roundtrip | BT-83 generate → parse |
| PASS |
Empty scheme stripping |
|
| PASS |
Roundtrip invoice | Generate → Parse → Verify key fields |
| PASS |
Due date roundtrip | BT-9 generate → parse |
| PASS |
Address line 2/3 roundtrip | BT-36/37, BT-51/52 generate → parse |
| PASS |
Buyer contact roundtrip | BT-44/46/47 generate → parse |
| PASS |
Registration ID roundtrip | BT-29 generate → parse |
| PASS |
Sales order roundtrip | BT-14 generate → parse |
| PASS |
Item identifiers roundtrip | BT-155/156/157 generate → parse |
| PASS |
Line item note roundtrip | BT-127 generate → parse |
| PASS |
Delivery location roundtrip | BT-70..80 generate → parse |
| PASS |
Allowance roundtrip | BG-20 generate → parse |
| PASS |
Charge roundtrip | BG-21 generate → parse |
| PASS |
Line allowance roundtrip | BG-27 generate → parse |
| PASS |
Despatch advice roundtrip | BT-16 generate → parse |
| PASS |
Invoiced object roundtrip | BT-18 generate → parse |
| PASS |
Business process roundtrip | BT-23 generate → parse |
| PASS |
SEPA direct debit roundtrip | BG-19 generate → parse |
| PASS |
Skonto roundtrip | PaymentDiscountTerms generate → parse |
| PASS |
BT-133 roundtrip | Buyer accounting reference generate → parse |
| PASS |
Trading names roundtrip | BT-28/BT-45 generate → parse |
| PASS |
Tender reference roundtrip | BT-17 generate → parse |
| PASS |
Exemption reason roundtrip | BT-120/BT-121 generate → parse |
| PASS |
Line period roundtrip | BT-134/BT-135 generate → parse |
| PASS |
Seller tax rep roundtrip | BG-11 generate → parse |
| PASS |
Payee roundtrip | BT-59/60/61 generate → parse |
| PASS |
Payment card roundtrip | BT-87/88 generate → parse |
| PASS |
Gross price roundtrip | BT-147/148 generate → parse |
| PASS |
Classification roundtrip | BT-158 generate → parse |
| PASS |
Country of origin roundtrip | BT-159 generate → parse |
| PASS |
Item attributes roundtrip | BT-160/161 generate → parse |
| PASS |
Receiving advice roundtrip | BT-15 generate → parse |
| PASS |
Delivery location ID roundtrip | BT-71 generate → parse |
| PASS |
Payment means text roundtrip | BT-82 generate → parse |
| PASS |
Supporting docs roundtrip | BG-24 generate → parse |
| PASS |
Supporting docs + tender ref | BG-24 + BT-17 coexistence |
| PASS |
Country subdivision roundtrip | BT-39/BT-54 generate → parse |
| PASS |
Payment means type code roundtrip | BT-81 generate → parse |
| PASS |
Buyer reference roundtrip | BT-10 generate → parse |
| PASS |
Tax rep subdivision roundtrip | BG-11 BT-39 generate → parse |
| PASS |
Combined item features | BT-159 + BG-30 + BT-148 together |
| PASS |
Multi-reference coexistence | BT-17 + BT-18 in same invoice |
| PASS |
Non-ASCII party names | Cyrillic/Chinese names |
| PASS |
All type codes | 380, 381, 384, 389, 875, 876, 877 |
| PASS |
All tax categories | S, Z, E, AE, K, G, O, L, M |
| PASS |
50 line items | Large invoice build + parse |
| PASS |
Mixed tax categories | S + G items in same invoice |
| PASS |
Unicode safety (umlauts) | ÄÖÜäöüß in all text fields |
| PASS |
High-value invoice | 50 line items with high amounts |
| PASS |
Mixed tax rates | 7% + 19% with exact rounding |
| PASS |
Classification version | BT-158-2 version roundtrip |
| PASS |
UBL detection | UBL Invoice/CreditNote rejected |
| PASS |
Defensive handlers | Exception in buyer_reference/tax_rep/payee/exemption |
| PASS |
Pydantic BT mapping | Validation errors show BT numbers |
| PASS |
Category | Code | Description | Result |
Standard | S | 19% / 7% USt | PASS |
Zero | Z | 0% rated | PASS |
Exempt | E | Exempt | PASS |
Reverse charge | AE | Reverse charge (Umkehr der Steuerschuld) | PASS |
Intra-community | K | EU supply (innergemeinschaftliche Lieferung) | PASS |
Export | G | Outside EU (Drittlandslieferung) | PASS |
Not subject | O | No VAT | PASS |
Canary Islands | L | IGIC | PASS |
Ceuta/Melilla | M | IPSI | PASS |
Attack Vector | Protection | Test | Result |
XXE entity expansion | defusedxml pre-screen |
| PASS |
Billion laughs (entity bomb) | defusedxml pre-screen |
| PASS |
External entity injection | defusedxml pre-screen |
| PASS |
XML bomb (>10 MB) | Size limit |
| PASS |
PDF bomb (>50 MB base64) | Size limit |
| PASS |
Decoded PDF bomb (>50 MB) | Post-decode guard |
| PASS |
KoSIT response bomb | 10 MB + 512 KB cap |
| PASS |
Input reflection in errors | Sanitized |
| PASS |
Error detail leakage | Generic messages |
| PASS |
SSRF via redirect |
| Defense-in-depth | HARDENED |
Supply chain (Docker) | SHA-256 checksum verification |
| HARDENED |
Container privilege | Non-root user (both containers) |
| HARDENED |
Port exposure | KoSIT bound to 127.0.0.1 only |
| HARDENED |
Supply chain (Python) |
|
| HARDENED |
IBAN injection | ISO 13616 format validation |
| HARDENED |
BIC injection | ISO 9362 format validation |
| HARDENED |
Profile | Generate | Parse | Validate | Compliance |
XRechnung 3.0 | PASS | PASS | PASS | PASS |
ZUGFeRD EN16931 | PASS | PASS | PASS | PASS |
ZUGFeRD Basic | PASS* | - | - | - |
ZUGFeRD Extended | PASS* | - | - | - |
* Generation produces XML with correct guideline URI; full parse/validate/compliance support planned.
Module | Lines | Description |
| 16 | Pydantic settings |
| 36 | Custom exceptions |
| 600+ | Pydantic models (invoice, party, line items, results, enums) |
| 633 | 14 German tax scenario prompts |
| 511 | 8 advanced prompts (EU trade, recurring, Schlussrechnung, Proforma, Drittland, Gutschrift) |
| 304 | 5 additional prompts (Berichtigung, RC+Steuervertreter, Teilrechnung, IG deep, Skonto) |
| 1200+ | 24 resources (schemas, reference codes, compliance, SEPA, CPV, BT-23, VAT exemptions, UNCL 5189) |
| 576 | CII XML generation via drafthorse |
| 320 | Flat parameter builder |
| 457 | Party, item, attribute extraction |
| 80 | KoSIT HTTP client |
| 182 | Visual PDF + factur-x embed |
| 720 | CII/ZUGFeRD XML parser |
| 217 | Compliance orchestration |
| 795 | BR-DE/BR-CO field checks |
| 230 | BR-CO-10/11/12/13/14/15/16 math checks |
| 50 | Generate tools |
| 39 | Parse tool |
| 33 | Validation tools |
server.py excluded — FastMCP Context cannot be unit-tested; helpers tested in test_server_helpers.py.
Tool | Description |
| Validates XRechnung XML against the KoSIT Validator |
| Validates ZUGFeRD PDF (extracts + validates embedded XML) |
| Generates an XRechnung-compliant CII XML invoice |
| Generates a ZUGFeRD hybrid PDF (visual + machine-readable) |
| Parses e-invoices (XML or PDF) into structured data |
| Checks mandatory fields + KoSIT validation with German suggestions |
Resource URI | Description |
| JSON-Schema für Rechnungspositionen (items-Array) |
| JSON-Schema für Zu-/Abschläge |
| JSON-Schema für Artikelmerkmale (BG-30) |
| JSON-Schema für Belegdokumente (BG-24) |
| Vollständiges JSON-Schema für InvoiceData |
| Rechnungstyp-Codes (380, 381, 384, 389, 875, 876, 877) |
| Zahlungsart-Codes (58=SEPA, 59=Lastschrift, 48=Kreditkarte, …) |
| EU-USt-Kategorien (S, Z, E, AE, K, G, O, L, M) mit Erklärungen |
| Mengeneinheiten-Codes (H87=Stück, HUR=Stunde, KGM=kg, …) |
| Elektronische Adress-Schemata (EM=E-Mail, 9930=USt-IdNr., …) |
| On-demand KoSIT-Validator Statusabfrage |
| Zeitplan E-Rechnungspflichten 2020–2028 mit Rechtsgrundlagen |
| Deutsche Geschäftsregeln (BR-DE-1..24) mit Lösungshinweisen |
| SKR04-Kontenzuordnung für häufige Rechnungsarten (DATEV) |
| Gutschrift-Gründe und Korrektur-Codes mit Empfehlungen |
| Leitweg-ID Aufbau (Grobadresse-Feinadresse-Prüfziffer), Regex, Beispiele |
| Steuerkategorie-Entscheidungsbaum (S/Z/E/AE/K/G/O/L/M) mit Szenarien |
| SEPA-Mandatstypen (CORE/B2B), Sequenztypen (FRST/RCUR/OOFF), Gläubiger-ID |
| CPV-Codes für öffentliche Vergabe (BT-158), IT/Bau/Beratung/Gesundheit |
| BT-23 Geschäftsprozesstyp-Kennungen (Peppol BIS, XRechnung) |
| USt-Befreiungsgründe (BT-120/BT-121) — §19, §4, §13b UStG mit Texten |
| UNCL 5189 Zu-/Abschlagsgrund-Codes (Rabatt, Skonto, Zuschläge) |
Prompt | Description |
| Schritt-für-Schritt: Gutschrift (381) erstellen |
| Checkliste: Reverse Charge (§13b UStG, Kategorie AE) |
| Schnellstart: XRechnung für öffentliche Auftraggeber |
| Anleitung: Korrekturrechnung (384) erstellen |
| Abschlagsrechnung / Teilrechnung (TypeCode 875/876/877) |
| Rechnung mit Ratenzahlung erstellen |
| Handwerkerrechnung nach §35a EStG |
| Entscheidungshilfe: Welcher TypeCode für welchen Anlass? |
| Checkliste: B2B E-Rechnungspflicht ab 2027 vorbereiten |
| E-Rechnungen für Betriebsprüfung vorbereiten (GoBD, §147 AO) |
| Kleinunternehmer (§19 UStG) — E-Rechnung ohne Umsatzsteuer |
| Bauleistungen / §13b UStG — Reverse Charge im Baugewerbe |
| Differenzbesteuerung (§25a UStG) für Gebrauchtwarenhändler |
| Stornierung: 381 vs 384 vs neue 380 — Entscheidungsbaum |
| Reiseleistungen (§25 UStG) — Margenbesteuerung |
| Innergemeinschaftliche Lieferung (§4 Nr. 1b / §6a UStG) |
| Dauerrechnung / Monatsrechnung für wiederkehrende Leistungen |
| Steuernummer vs. USt-IdNr. — Entscheidungshilfe (BR-DE-26) |
| Schlussrechnung nach Abschlagszahlungen (prepaid_amount, BT-113) |
| Proforma-Rechnung — rechtliche Einordnung, E-Rechnungs-Behandlung |
| Export außerhalb EU (§4 Nr. 1a UStG, Steuerkategorie G, Incoterms) |
| Gutschriftverfahren / Self-Billing (TypeCode 389, §14 Abs. 2) |
| 381 vs 384: Gutschrift, Korrektur oder Storno? Entscheidungsbaum |
| Reverse Charge + Steuervertreter (BG-11): Kombiniertes Szenario |
| 875 → 877 Lifecycle: Abschlag, Teilrechnung, Schlussrechnung |
| IG Lieferung: Gelangensbestätigung, ZM, Nachweispflichten, eVatR |
| Skonto: Berechnung, BT-20 Kodierung, §17 UStG Steuerbehandlung |
Python 3.11+
Docker (for the KoSIT Validator)
git clone https://github.com/Mavengence/einvoice-mcp.git
cd einvoice-mcp
pip install -e ".[dev]"make docker-upStarts the KoSIT Validator (v1.6.2, XRechnung scenarios v2026-01-31) on port 8081.
make dev{
"mcpServers": {
"einvoice": {
"command": "python",
"args": ["-m", "einvoice_mcp"],
"env": {
"KOSIT_URL": "http://localhost:8081"
}
}
}
}claude mcp add einvoice -- python -m einvoice_mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"einvoice": {
"command": "python",
"args": ["-m", "einvoice_mcp"],
"env": {
"KOSIT_URL": "http://localhost:8081"
}
}
}
}Variable | Default | Description |
|
| KoSIT Validator URL |
|
| Log level (DEBUG, INFO, WARNING, ERROR, CRITICAL) |
Validiere diese XRechnung: [XML einfügen]
Erstelle eine Rechnung von TechCorp GmbH (DE123456789) an ClientCorp GmbH
für 40 Stunden Software-Beratung à 150€/Stunde mit 19% USt.
Parse diese E-Rechnung und zeig mir die Positionen.
Prüfe ob diese Rechnung XRechnung-konform ist und gib Verbesserungsvorschläge.Erstelle eine Gutschrift (TypeCode 381) für Rechnung RE-2025-099 über
200€ netto mit 19% USt.
Erstelle eine Rechnung mit Reverse Charge (§13b UStG, Kategorie AE):
Verkäufer DE123456789, Käufer ATU12345678, Dienstleistung 5.000€.
Erstelle eine Rechnung mit 2% Skonto bei Zahlung innerhalb von 10 Tagen.
Erstelle eine Rechnung mit SEPA-Lastschrift (PaymentMeansCode 59),
Käufer-IBAN DE89370400440532013000, Mandatsreferenz MREF-2025-001.
Erstelle eine Rechnung mit Lieferort: Lager Hamburg, Hafenstraße 42,
20457 Hamburg.
Erstelle eine innergemeinschaftliche Lieferung (Kategorie K) an
einen französischen Kunden (FR12345678901).
Erstelle eine steuerbefreite Rechnung (§19 UStG, Kleinunternehmer)
mit Befreiungsgrund und Code vatex-eu-132.
Erstelle eine Rechnung für ein Vergabeverfahren mit Losnummer VERGABE-2026-42
und Kontierungsreferenz KST-4711 pro Position.
Erstelle eine Korrekturrechnung (TypeCode 384) für die fehlerhafte Rechnung
RE-2026-001 mit korrigiertem Steuersatz.[AI Client] --> stdio --> [FastMCP Server]
|-- drafthorse (CII XML generation/parsing)
|-- factur-x (PDF/A-3 embedding/extraction)
|-- reportlab (Visual PDF rendering)
|-- defusedxml (XXE protection on all parse paths)
'-- httpx --> [KoSIT Validator :8081]Component | Version | Source |
KoSIT Validator | v1.6.2 (SHA-256 verified) | |
XRechnung Scenarios | v2026-01-31 (SHA-256 verified) | |
Java Runtime | Eclipse Temurin 17 | OpenJDK |
make install # Install dependencies
make test # Run tests with coverage
make lint # Ruff + mypy strict
make fmt # Format code
make docker-up # Start Docker stackBT/BG | Field | Generate | Parse | Compliance |
BT-1 | Invoice number | Yes | Yes | Yes |
BT-2 | Issue date | Yes | Yes | Yes |
BT-3 | Type code (380/381/384) | Yes | Yes | Yes |
BT-5 | Currency code | Yes | Yes | Yes |
BT-9 | Due date | Yes | Yes | — |
BT-10 | Buyer reference / Leitweg-ID | Yes | Yes | Yes |
BT-11 | Project reference | Yes | Yes | — |
BT-12 | Contract reference | Yes | Yes | — |
BT-13 | Purchase order reference | Yes | Yes | — |
BT-14 | Sales order reference | Yes | Yes | — |
BT-16 | Despatch advice reference | Yes | Yes | — |
BT-17 | Tender or lot reference | Yes | Yes | — |
BT-18 | Invoiced object identifier | Yes | Yes | — |
BT-20 | Payment terms text | Yes | Yes | — |
BT-22 | Invoice note | Yes | Yes | — |
BT-23 | Business process type | Yes | Yes | — |
BT-25 | Preceding invoice (credit notes) | Yes | Yes | Yes |
BT-27..40 | Seller party + address (incl. lines 2/3, subdivision) | Yes | Yes | Yes |
BT-28 | Seller trading name | Yes | Yes | — |
BT-29 | Seller registration ID (GLN) | Yes | Yes | — |
BT-31 | Seller VAT ID (schemeID=VA) | Yes | Yes | Yes |
BT-32 | Seller tax number (schemeID=FC) | Yes | Yes | Yes |
BT-34 | Seller electronic address | Yes | Yes | Yes |
BT-41 | Seller contact name | Yes | Yes | Yes |
BT-42 | Seller contact phone | Yes | Yes | Yes |
BT-43 | Seller contact email | Yes | Yes | Yes |
BT-44..55 | Buyer party + address (incl. lines 2/3, subdivision) | Yes | Yes | Yes |
BT-45 | Buyer trading name | Yes | Yes | — |
BT-46 | Buyer registration ID (GLN) | Yes | Yes | — |
BT-49 | Buyer electronic address | Yes | Yes | Yes |
BT-70..80 | Delivery location (name + address) | Yes | Yes | — |
BT-71 | Delivery date | Yes | Yes | Yes |
BT-73/74 | Service period | Yes | Yes | Yes |
BT-81 | Payment means type code | Yes | Yes | — |
BT-83 | Remittance information | Yes | Yes | — |
BT-84 | Seller IBAN | Yes | Yes | Yes |
BT-86 | BIC | Yes | Yes | — |
BT-89 | SEPA mandate reference | Yes | Yes | Yes |
BT-91 | Buyer IBAN (SEPA direct debit) | Yes | Yes | Yes |
BT-120 | VAT exemption reason text | Yes | Yes | Yes |
BT-121 | VAT exemption reason code | Yes | Yes | — |
BT-127 | Line item note | Yes | Yes | — |
BT-155 | Seller item identifier | Yes | Yes | — |
BT-156 | Buyer item identifier | Yes | Yes | — |
BT-157 | Standard item ID (GTIN/EAN) | Yes | Yes | — |
BT-159 | Item country of origin | Yes | Yes | — |
BT-160/161 | Item attributes (BG-30, name/value) | Yes | Yes | — |
BG-20/21 | Document-level allowances/charges | Yes | Yes | — |
BG-27/28 | Line-level allowances/charges | Yes | Yes | — |
BT-15 | Receiving advice reference | Yes | Yes | — |
BT-71 | Delivery location identifier | Yes | Yes | — |
BT-82 | Payment means text | Yes | Yes | — |
BG-24 | Supporting documents (BT-122..125) | Yes | Yes | — |
BT-133 | Buyer accounting reference | Yes | Yes | — |
Skonto | Payment discount terms (percent, days) | Yes | Yes | — |
For credit notes (TypeCode 381), the server:
Sets XML header name to "GUTSCHRIFT" and PDF title accordingly
Requires BT-25 (preceding invoice number) in compliance checks
Shows "Bezug: [Rechnungsnummer]" in the PDF header
Validates against EN 16931 type code whitelist (380, 381, 384, 389, 875, 876, 877)
Example: type_code="381", preceding_invoice_number="RE-2025-099"
Profile | Use Case | Guideline URI |
| German public sector (B2G), Leitweg-ID required |
|
| B2B invoices (default for ZUGFeRD PDF) |
|
| Simplified B2B invoices |
|
| Extended B2B invoices with additional fields |
|
See docs/GERMAN_COMPLIANCE_GUIDE.md for:
TypeCode decision tree (380/381/384/875/876/877)
Tax category decision tree (S/Z/E/AE/K/G/O/L/M)
Leitweg-ID format and sources
Reverse charge vs. intra-community supply
Handwerkerrechnung §35a EStG
Pflichtfelder-Checkliste for XRechnung 3.0
ZUGFeRD Basic/Extended: Generation produces XML with correct guideline URIs, but parsing, validation, and compliance checks are tested for XRechnung 3.0 and ZUGFeRD EN16931 only.
Batch processing: Each tool call processes one invoice. For bulk operations, call the tools in sequence.
Fehler: KoSIT-Validator nicht erreichbar. Bitte prüfen Sie die Verbindung.Start the Docker containers: make docker-up
Wait for healthy status: docker compose -f docker/docker-compose.yml ps
Verify manually: curl http://localhost:8081/server/health
Check if port 8081 is blocked by firewall or another process
# Check logs
docker compose -f docker/docker-compose.yml logs kosit
# Common issue: port already in use
lsof -i :8081
# Restart clean
docker compose -f docker/docker-compose.yml down
docker compose -f docker/docker-compose.yml up -dFehler: UBL-Format erkannt. Dieses Tool unterstützt nur CII.The parser only supports CII (Cross Industry Invoice) XML, which is the standard for XRechnung and ZUGFeRD. If you have a UBL invoice, convert it to CII first using an external tool.
When generating invoices, field errors now reference BT numbers:
Fehler: Ungültige Rechnungsdaten:
- BT-84 (IBAN): String should match pattern ...
- BT-27 (Verkäufername): String should have at least 1 characterCheck the German Compliance Guide for field requirements.
# Install dev dependencies
pip install -e ".[dev]"
# Run unit tests only (no Docker needed)
make test
# Run integration tests (requires Docker)
make docker-up
pytest -m integrationEN 16931 — European standard for electronic invoicing
XRechnung 3.0 (Szenarien 3.0.2) — German CIUS (Core Invoice Usage Specification)
ZUGFeRD 2.x / Factur-X 1.08 — Hybrid PDF/A-3 invoice format
BMF 2024-11-15 — German Federal Ministry of Finance e-invoice mandate
§14 UStG — German VAT Act invoice requirements
§14 Abs. 4 Nr. 2 UStG — Steuernummer or USt-IdNr. required (BT-31 / BT-32)
§14 Abs. 4 Nr. 6 UStG — Delivery date or service period required (BT-71 / BT-73/74)
BR-CO-14 — Tax total must equal sum of per-group calculated amounts
BR-DE-5 — Seller contact person (mandatory for XRechnung)
BR-DE-7 — Seller contact email (mandatory for XRechnung)
BR-DE-23 — IBAN mandatory when PaymentMeansCode = 58 (SEPA)
§13b UStG — Reverse charge: seller + buyer VAT IDs required, 0% tax rate
§4 Nr. 1b UStG — Intra-community supply: buyer VAT ID required, 0% tax rate
§19 UStG — Kleinunternehmerregelung: exemption note advisory for TaxCategory E
BG-19 — SEPA direct debit (PaymentMeansCode = 59, buyer IBAN, mandate reference)
BR-DE-20 — Max one payment instruction type (no mixing credit transfer + direct debit)
BR-DE-24 — SEPA direct debit: mandate reference + buyer IBAN required
BR-E-10 — VAT exemption reason (BT-120) required for TaxCategory E
§4 Nr. 1a UStG — Export outside EU (TaxCategory G): 0% tax rate required
§33 UStDV — Kleinbetragsrechnung advisory (invoices ≤250€ gross)
Skonto — Early payment discount terms (PaymentDiscountTerms in CII)
384 Korrekturrechnung — Corrective invoice must reference preceding invoice (BT-25)
RC-COUNTRY — Reverse charge: seller/buyer country advisory (§13b allows domestic)
IC-COUNTRY — Intra-community: seller ≠ buyer country required
§632a BGB — Abschlagsrechnung for construction/service contracts
§35a Abs. 3 EStG — Handwerkerleistungen tax deduction (20% of labor, max 1.200€/year)
§271 BGB — Payment due date per agreement (Ratenzahlung)
ISO 13616 — IBAN format validation (seller + buyer)
ISO 9362 — BIC/SWIFT format validation
MIT
Prüft die Konformität einer E-Rechnung gegen XRechnung oder ZUGFeRD.
Kombiniert KoSIT-Validierung mit Pflichtfeldprüfung und gibt Verbesserungsvorschläge auf Deutsch zurück.
Geprüfte Regeln:
EN 16931 Pflichtfelder (BT-1..BT-55)
BR-DE-1..BR-DE-26 (XRechnung-Geschäftsregeln)
BR-DE-8..BR-DE-13 (Datumsformat-Prüfung)
BR-DE-25 (Bruttobetrag >= 0)
Steuerkategorie-Regeln (Reverse Charge, ig. Lieferung, Export, §19)
SEPA-Prüfungen (IBAN, Mandatsreferenz, BIC)
EAS-Code-Validierung (BR-DE-16/21/22)
Leitweg-ID Format (XRechnung)
Args: xml_content: Der CII-XML-Inhalt als String. target_profile: Zielprofil — "XRECHNUNG" oder "ZUGFERD".
| Name | Required | Description | Default |
|---|---|---|---|
| xml_content | Yes | ||
| target_profile | No | XRECHNUNG |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context by listing specific rule sets checked (e.g., EN 16931, BR-DE rules, SEPA checks) and noting the output is in German. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose statement, followed by a rule list and parameter explanations. It is somewhat long due to the detailed rule enumeration, but every section serves a purpose and it is front-loaded with the key functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and a present output schema, the description covers the tool's purpose, key rules, parameters, and output language. It does not explicitly reference sibling tools or edge cases, but the information provided is sufficient for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. The 'Args' section explains xml_content as the CII-XML string and target_profile with its allowed values ('XRECHNUNG' or 'ZUGFERD'), providing semantics the schema lacks. This is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking e-invoice compliance against XRechnung or ZUGFeRD. It specifies the exact resource (E-Rechnung) and verb (Prüft die Konformität), and distinguishes itself from siblings by mentioning combined KoSIT validation, mandatory field checks, and German improvement suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (compliance checking with rule lists and suggestions) but does not explicitly compare to sibling tools like einvoice_validate_xrechnung or state when to use this instead. It provides clear context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erstellt eine XRechnung-konforme CII-XML-Rechnung.
Die Rechnung wird automatisch gegen den KoSIT-Validator geprüft.
Args: invoice_id: Rechnungsnummer (z.B. "RE-2026-001"). issue_date: Rechnungsdatum im Format YYYY-MM-DD. seller_name: Name des Verkäufers / Rechnungsstellers. seller_street: Straße und Hausnummer des Verkäufers. seller_city: Stadt des Verkäufers. seller_postal_code: PLZ des Verkäufers. seller_country_code: Ländercode des Verkäufers (z.B. "DE"). seller_tax_id: USt-IdNr. des Verkäufers (z.B. "DE123456789"). buyer_name: Name des Käufers / Rechnungsempfängers. buyer_street: Straße und Hausnummer des Käufers. buyer_city: Stadt des Käufers. buyer_postal_code: PLZ des Käufers. buyer_country_code: Ländercode des Käufers (z.B. "DE"). items: JSON-Array der Positionen. seller_street_2: Adresszeile 2 des Verkäufers (BT-36). seller_street_3: Adresszeile 3 des Verkäufers (BT-37). seller_country_subdivision: Bundesland Verkäufer (BT-39, z.B. 'BY'). buyer_street_2: Adresszeile 2 des Käufers (BT-51). buyer_street_3: Adresszeile 3 des Käufers (BT-52). buyer_country_subdivision: Bundesland Käufer (BT-54, z.B. 'NW'). buyer_tax_id: USt-IdNr. des Käufers (optional). currency: Währungscode (Standard: "EUR"). payment_terms_days: Zahlungsziel in Tagen (optional). leitweg_id: Leitweg-ID (optional). buyer_reference: Käuferreferenz BT-10 (optional). profile: Rechnungsprofil. seller_electronic_address: Elektronische Adresse (BT-34). seller_electronic_address_scheme: EAS-Code (EM/9930). buyer_electronic_address: Elektronische Adresse (BT-49). buyer_electronic_address_scheme: EAS-Code (EM/9930). seller_contact_name: Ansprechpartner (BT-41). seller_contact_email: E-Mail (BT-43). seller_contact_phone: Telefon (BT-42). buyer_contact_name: Ansprechpartner Käufer (BT-44). buyer_contact_email: E-Mail Käufer (BT-47). buyer_contact_phone: Telefon Käufer (BT-46). seller_iban: IBAN (BT-84). seller_bic: BIC (BT-86). seller_bank_name: Bankname. type_code: Rechnungsart (BT-3): 380/381/384. seller_tax_number: Steuernummer (BT-32). delivery_party_name: Lieferort Name (BT-70). delivery_street: Lieferort Straße (BT-75). delivery_city: Lieferort Stadt (BT-77). delivery_postal_code: Lieferort PLZ (BT-78). delivery_country_code: Lieferort Land (BT-80). delivery_date: Lieferdatum (BT-71, YYYY-MM-DD). service_period_start: Leistungszeitraum Beginn (BT-73). service_period_end: Leistungszeitraum Ende (BT-74). due_date: Fälligkeitsdatum (BT-9, YYYY-MM-DD). invoice_note: Freitext-Bemerkung (BT-22). payment_terms_text: Zahlungsbedingungen (BT-20). purchase_order_reference: Bestellnummer (BT-13). sales_order_reference: Auftragsbestätigung (BT-14). contract_reference: Vertragsnummer (BT-12). project_reference: Projektreferenz (BT-11). preceding_invoice_number: Vorige Rechnungsnr. (BT-25). preceding_invoice_date: Datum der vorigen Rechnung (BT-26, YYYY-MM-DD). despatch_advice_reference: Lieferscheinnummer (BT-16). invoiced_object_identifier: Abrechnungsobjekt (BT-18). business_process_type: Geschäftsprozesstyp (BT-23). seller_registration_id: Handelsregister/GLN (BT-29). buyer_registration_id: GLN des Käufers (BT-46). buyer_iban: IBAN des Käufers (BT-91, SEPA-Lastschrift). mandate_reference_id: SEPA-Mandatsreferenz (BT-89). skonto_percent: Skonto-Prozentsatz (z.B. "2.00"). skonto_days: Skonto-Frist in Tagen. skonto_base_amount: Skonto-Basisbetrag (optional). payment_means_type_code: Zahlungsart (BT-81, Standard 58). remittance_information: Verwendungszweck (BT-83). allowances_charges: JSON-Array der Zu-/Abschläge (BG-20/BG-21). tax_exemption_reason: Befreiungsgrund Text (BT-120). tax_exemption_reason_code: Befreiungsgrund Code (BT-121). tender_or_lot_reference: Vergabe-/Losnummer (BT-17). seller_trading_name: Handelsname Verkäufer (BT-28). buyer_trading_name: Handelsname Käufer (BT-45). payee_name: Zahlungsempfänger Name (BT-59). payee_id: Kennung des Zahlungsempfängers (BT-60). payee_legal_registration_id: Handelsregister Zahlungsempfänger (BT-61). payment_card_pan: Kartennummer letzte Stellen (BT-87). payment_card_holder: Karteninhaber (BT-88). seller_tax_rep_name: Steuervertreter Name (BT-62). seller_tax_rep_street: Steuervertreter Straße (BT-64). seller_tax_rep_city: Steuervertreter Stadt. seller_tax_rep_postal_code: Steuervertreter PLZ. seller_tax_rep_country_code: Steuervertreter Land. seller_tax_rep_tax_id: Steuervertreter USt-IdNr. (BT-63). receiving_advice_reference: Wareneingangsreferenz (BT-15). delivery_location_id: Lieferort-Kennung (BT-71). payment_means_text: Zahlungsart Freitext (BT-82). supporting_documents: JSON-Array Belegdokumente (BG-24). prepaid_amount: Bereits gezahlter Betrag (BT-113, z.B. Abschlagszahlungen). vat_point_date_code: Steuerzeitpunkt-Code (BT-8, UNTDID 2005). 3=Rechnungsdatum, 35=Lieferdatum, 432=Zahlungsdatum. seller_additional_legal_info: Zusaetzliche rechtl. Info (BT-33). creditor_reference_id: Glaeubigeridentifikationsnr. (BT-90). buyer_accounting_reference: Kontierung Kaeufer (BT-19).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| profile | No | XRECHNUNG | |
| currency | No | EUR | |
| due_date | No | ||
| payee_id | No | ||
| type_code | No | 380 | |
| buyer_city | Yes | ||
| buyer_iban | No | ||
| buyer_name | Yes | ||
| invoice_id | Yes | ||
| issue_date | Yes | ||
| leitweg_id | No | ||
| payee_name | No | ||
| seller_bic | No | ||
| seller_city | Yes | ||
| seller_iban | No | ||
| seller_name | Yes | ||
| skonto_days | No | ||
| buyer_street | Yes | ||
| buyer_tax_id | No | ||
| invoice_note | No | ||
| delivery_city | No | ||
| delivery_date | No | ||
| seller_street | Yes | ||
| seller_tax_id | Yes | ||
| buyer_street_2 | No | ||
| buyer_street_3 | No | ||
| prepaid_amount | No | ||
| skonto_percent | No | ||
| buyer_reference | No | ||
| delivery_street | No | ||
| seller_street_2 | No | ||
| seller_street_3 | No | ||
| payment_card_pan | No | ||
| seller_bank_name | No | ||
| buyer_postal_code | Yes | ||
| project_reference | No | ||
| seller_tax_number | No | ||
| allowances_charges | No | ||
| buyer_contact_name | No | ||
| buyer_country_code | Yes | ||
| buyer_trading_name | No | ||
| contract_reference | No | ||
| payment_means_text | No | ||
| payment_terms_days | No | ||
| payment_terms_text | No | ||
| seller_postal_code | Yes | ||
| service_period_end | No | ||
| skonto_base_amount | No | ||
| buyer_contact_email | No | ||
| buyer_contact_phone | No | ||
| delivery_party_name | No | ||
| payment_card_holder | No | ||
| seller_contact_name | No | ||
| seller_country_code | Yes | ||
| seller_tax_rep_city | No | ||
| seller_tax_rep_name | No | ||
| seller_trading_name | No | ||
| vat_point_date_code | No | ||
| delivery_location_id | No | ||
| delivery_postal_code | No | ||
| mandate_reference_id | No | ||
| seller_contact_email | No | ||
| seller_contact_phone | No | ||
| service_period_start | No | ||
| supporting_documents | No | ||
| tax_exemption_reason | No | ||
| business_process_type | No | ||
| buyer_registration_id | No | ||
| creditor_reference_id | No | ||
| delivery_country_code | No | ||
| sales_order_reference | No | ||
| seller_tax_rep_street | No | ||
| seller_tax_rep_tax_id | No | ||
| preceding_invoice_date | No | ||
| remittance_information | No | ||
| seller_registration_id | No | ||
| payment_means_type_code | No | 58 | |
| tender_or_lot_reference | No | ||
| buyer_electronic_address | No | ||
| preceding_invoice_number | No | ||
| purchase_order_reference | No | ||
| buyer_country_subdivision | No | ||
| despatch_advice_reference | No | ||
| seller_electronic_address | No | ||
| tax_exemption_reason_code | No | ||
| buyer_accounting_reference | No | ||
| invoiced_object_identifier | No | ||
| receiving_advice_reference | No | ||
| seller_country_subdivision | No | ||
| seller_tax_rep_postal_code | No | ||
| payee_legal_registration_id | No | ||
| seller_tax_rep_country_code | No | ||
| seller_additional_legal_info | No | ||
| buyer_electronic_address_scheme | No | EM | |
| seller_electronic_address_scheme | No | EM |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: automatic validation against the KoSIT validator ('Die Rechnung wird automatisch gegen den KoSIT-Validator geprüft'). This goes beyond the annotations (idempotentHint=true, readOnlyHint=false) and provides useful context about expected validation behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and validation notice, then provides an organized and comprehensive parameter list. While very long, each parameter entry is concise and necessary given the 96-parameter schema with zero schema-level descriptions. There is minimal fluff, though the sheer length is a burden.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (96 params) and the presence of an output schema, the description is largely complete. It covers all parameters with semantic details and discloses validation behavior. It does not explicitly address failure cases or output format, but the output schema covers return values, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining every parameter with examples, formats, and BT codes. It clarifies that fields like 'items', 'allowances_charges', and 'supporting_documents' are JSON arrays, which the schema does not specify. This is rich semantic addition beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Erstellt eine XRechnung-konforme CII-XML-Rechnung' (Creates an XRechnung-compliant CII-XML invoice), which is a specific verb + resource. It clearly distinguishes from sibling tools like validation, parsing, and ZUGFeRD generation by specifying the XRechnung/CII format and the generation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating XRechnung invoices but does not explicitly state when to use this tool versus the ZUGFeRD variant or validation tools. No exclusions or alternatives are mentioned. The context is clear from the name and purpose, but guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erstellt eine ZUGFeRD-Hybrid-PDF (visuelle PDF + eingebettetes CII-XML).
Args: invoice_id: Rechnungsnummer. issue_date: Rechnungsdatum (YYYY-MM-DD). seller_name: Name des Verkäufers. seller_street: Straße des Verkäufers. seller_city: Stadt des Verkäufers. seller_postal_code: PLZ des Verkäufers. seller_country_code: Land des Verkäufers. seller_tax_id: USt-IdNr. des Verkäufers. buyer_name: Name des Käufers. buyer_street: Straße des Käufers. buyer_city: Stadt des Käufers. buyer_postal_code: PLZ des Käufers. buyer_country_code: Land des Käufers. items: JSON-Array der Positionen. seller_street_2: Adresszeile 2 des Verkäufers (BT-36). seller_street_3: Adresszeile 3 des Verkäufers (BT-37). seller_country_subdivision: Bundesland Verkäufer (BT-39, z.B. 'BY'). buyer_street_2: Adresszeile 2 des Käufers (BT-51). buyer_street_3: Adresszeile 3 des Käufers (BT-52). buyer_country_subdivision: Bundesland Käufer (BT-54, z.B. 'NW'). buyer_tax_id: USt-IdNr. des Käufers (optional). currency: Währungscode (Standard: EUR). payment_terms_days: Zahlungsziel in Tagen (optional). leitweg_id: Leitweg-ID (optional). buyer_reference: Käuferreferenz BT-10 (optional). profile: Rechnungsprofil. seller_electronic_address: Elektronische Adresse (BT-34). seller_electronic_address_scheme: EAS-Code (EM/9930). buyer_electronic_address: Elektronische Adresse (BT-49). buyer_electronic_address_scheme: EAS-Code (EM/9930). seller_contact_name: Ansprechpartner (BT-41). seller_contact_email: E-Mail (BT-43). seller_contact_phone: Telefon (BT-42). buyer_contact_name: Ansprechpartner Käufer (BT-44). buyer_contact_email: E-Mail Käufer (BT-47). buyer_contact_phone: Telefon Käufer (BT-46). seller_iban: IBAN (BT-84). seller_bic: BIC (BT-86). seller_bank_name: Bankname. type_code: Rechnungsart (BT-3): 380/381/384. seller_tax_number: Steuernummer (BT-32). delivery_party_name: Lieferort Name (BT-70). delivery_street: Lieferort Straße (BT-75). delivery_city: Lieferort Stadt (BT-77). delivery_postal_code: Lieferort PLZ (BT-78). delivery_country_code: Lieferort Land (BT-80). delivery_date: Lieferdatum (BT-71). service_period_start: Leistungszeitraum Beginn (BT-73). service_period_end: Leistungszeitraum Ende (BT-74). due_date: Fälligkeitsdatum (BT-9, YYYY-MM-DD). invoice_note: Freitext-Bemerkung (BT-22). payment_terms_text: Zahlungsbedingungen (BT-20). purchase_order_reference: Bestellnummer (BT-13). sales_order_reference: Auftragsbestätigung (BT-14). contract_reference: Vertragsnummer (BT-12). project_reference: Projektreferenz (BT-11). preceding_invoice_number: Vorige Rechnungsnr. (BT-25). preceding_invoice_date: Datum der vorigen Rechnung (BT-26, YYYY-MM-DD). despatch_advice_reference: Lieferscheinnummer (BT-16). invoiced_object_identifier: Abrechnungsobjekt (BT-18). business_process_type: Geschäftsprozesstyp (BT-23). seller_registration_id: Handelsregister/GLN (BT-29). buyer_registration_id: GLN des Käufers (BT-46). buyer_iban: IBAN des Käufers (BT-91, SEPA-Lastschrift). mandate_reference_id: SEPA-Mandatsreferenz (BT-89). skonto_percent: Skonto-Prozentsatz (z.B. "2.00"). skonto_days: Skonto-Frist in Tagen. skonto_base_amount: Skonto-Basisbetrag (optional). payment_means_type_code: Zahlungsart (BT-81, Standard 58). remittance_information: Verwendungszweck (BT-83). allowances_charges: JSON-Array der Zu-/Abschläge (BG-20/BG-21). tax_exemption_reason: Befreiungsgrund Text (BT-120). tax_exemption_reason_code: Befreiungsgrund Code (BT-121). tender_or_lot_reference: Vergabe-/Losnummer (BT-17). seller_trading_name: Handelsname Verkäufer (BT-28). buyer_trading_name: Handelsname Käufer (BT-45). payee_name: Zahlungsempfänger Name (BT-59). payee_id: Kennung des Zahlungsempfängers (BT-60). payee_legal_registration_id: Handelsregister (BT-61). payment_card_pan: Kartennummer letzte Stellen (BT-87). payment_card_holder: Karteninhaber (BT-88). seller_tax_rep_name: Steuervertreter Name (BT-62). seller_tax_rep_street: Steuervertreter Straße (BT-64). seller_tax_rep_city: Steuervertreter Stadt. seller_tax_rep_postal_code: Steuervertreter PLZ. seller_tax_rep_country_code: Steuervertreter Land. seller_tax_rep_tax_id: Steuervertreter USt-IdNr. (BT-63). receiving_advice_reference: Wareneingangsreferenz (BT-15). delivery_location_id: Lieferort-Kennung (BT-71). payment_means_text: Zahlungsart Freitext (BT-82). supporting_documents: JSON-Array Belegdokumente (BG-24). prepaid_amount: Bereits gezahlter Betrag (BT-113, z.B. Abschlagszahlungen). vat_point_date_code: Steuerzeitpunkt-Code (BT-8, UNTDID 2005). 3=Rechnungsdatum, 35=Lieferdatum, 432=Zahlungsdatum. seller_additional_legal_info: Zusaetzliche rechtl. Info (BT-33). creditor_reference_id: Glaeubigeridentifikationsnr. (BT-90). buyer_accounting_reference: Kontierung Kaeufer (BT-19).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| profile | No | ZUGFERD_EN16931 | |
| currency | No | EUR | |
| due_date | No | ||
| payee_id | No | ||
| type_code | No | 380 | |
| buyer_city | Yes | ||
| buyer_iban | No | ||
| buyer_name | Yes | ||
| invoice_id | Yes | ||
| issue_date | Yes | ||
| leitweg_id | No | ||
| payee_name | No | ||
| seller_bic | No | ||
| seller_city | Yes | ||
| seller_iban | No | ||
| seller_name | Yes | ||
| skonto_days | No | ||
| buyer_street | Yes | ||
| buyer_tax_id | No | ||
| invoice_note | No | ||
| delivery_city | No | ||
| delivery_date | No | ||
| seller_street | Yes | ||
| seller_tax_id | Yes | ||
| buyer_street_2 | No | ||
| buyer_street_3 | No | ||
| prepaid_amount | No | ||
| skonto_percent | No | ||
| buyer_reference | No | ||
| delivery_street | No | ||
| seller_street_2 | No | ||
| seller_street_3 | No | ||
| payment_card_pan | No | ||
| seller_bank_name | No | ||
| buyer_postal_code | Yes | ||
| project_reference | No | ||
| seller_tax_number | No | ||
| allowances_charges | No | ||
| buyer_contact_name | No | ||
| buyer_country_code | Yes | ||
| buyer_trading_name | No | ||
| contract_reference | No | ||
| payment_means_text | No | ||
| payment_terms_days | No | ||
| payment_terms_text | No | ||
| seller_postal_code | Yes | ||
| service_period_end | No | ||
| skonto_base_amount | No | ||
| buyer_contact_email | No | ||
| buyer_contact_phone | No | ||
| delivery_party_name | No | ||
| payment_card_holder | No | ||
| seller_contact_name | No | ||
| seller_country_code | Yes | ||
| seller_tax_rep_city | No | ||
| seller_tax_rep_name | No | ||
| seller_trading_name | No | ||
| vat_point_date_code | No | ||
| delivery_location_id | No | ||
| delivery_postal_code | No | ||
| mandate_reference_id | No | ||
| seller_contact_email | No | ||
| seller_contact_phone | No | ||
| service_period_start | No | ||
| supporting_documents | No | ||
| tax_exemption_reason | No | ||
| business_process_type | No | ||
| buyer_registration_id | No | ||
| creditor_reference_id | No | ||
| delivery_country_code | No | ||
| sales_order_reference | No | ||
| seller_tax_rep_street | No | ||
| seller_tax_rep_tax_id | No | ||
| preceding_invoice_date | No | ||
| remittance_information | No | ||
| seller_registration_id | No | ||
| payment_means_type_code | No | 58 | |
| tender_or_lot_reference | No | ||
| buyer_electronic_address | No | ||
| preceding_invoice_number | No | ||
| purchase_order_reference | No | ||
| buyer_country_subdivision | No | ||
| despatch_advice_reference | No | ||
| seller_electronic_address | No | ||
| tax_exemption_reason_code | No | ||
| buyer_accounting_reference | No | ||
| invoiced_object_identifier | No | ||
| receiving_advice_reference | No | ||
| seller_country_subdivision | No | ||
| seller_tax_rep_postal_code | No | ||
| payee_legal_registration_id | No | ||
| seller_tax_rep_country_code | No | ||
| seller_additional_legal_info | No | ||
| buyer_electronic_address_scheme | No | EM | |
| seller_electronic_address_scheme | No | EM |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that the tool creates a hybrid PDF with embedded CII-XML, which is useful behavioral context. However, it does not disclose behaviors such as validation failures, file output handling, or side effects beyond the annotations. It avoids contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured: a one-sentence purpose statement followed by an 'Args:' list. Every parameter earns a line because the schema lacks descriptions. It is long due to the tool's 96 parameters, but not verbose or redundant, making it efficient for the complexity involved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 96 parameters, an existing output schema, and annotations, the description covers the core purpose and all parameter semantics thoroughly. It does not explain when to use ZUGFeRD vs. XRechnung or describe profile options in depth, but the output schema covers return values and the parameter details are nearly exhaustive. Minor gaps remain in usage context and behavioral edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter understanding. It provides a comprehensive list of all 96 parameters with German explanations, BT-code mappings, and examples (e.g., type_code '380/381/384', vat_point_date_code values). This adds significant meaning beyond the schema's bare property titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the exact purpose with a specific verb and resource: 'Erstellt eine ZUGFeRD-Hybrid-PDF (visuelle PDF + eingebettetes CII-XML).' This clearly distinguishes it from sibling tools like einvoice_generate_xrechnung and einvoice_validate_* by naming the output format (ZUGFeRD) and its hybrid nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: generating a ZUGFeRD invoice. However, it does not explicitly state when to choose this tool over alternatives (e.g., einvoice_generate_xrechnung) or provide any exclusion criteria. No explicit when-to-use/when-not-to-use guidance is given, but the tool name and purpose make the primary scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parst eine E-Rechnung (XML oder PDF) und gibt strukturierte Daten zurück.
Unterstützt CII-XML (XRechnung) und ZUGFeRD/Factur-X PDFs. Gibt JSON mit allen extrahierten Feldern zurück:
Kopfdaten: invoice_id, issue_date, type_code, currency, profile
Parteien: seller, buyer (Name, Adresse, USt-IdNr., Kontakt)
Positionen: items[] mit Beschreibung, Menge, Preis, Steuersatz
Summen: totals (BT-106 net, BT-109 tax_basis, BT-112 gross, BT-113 prepaid)
Steuer: tax_breakdown[], tax_exemption_reason
Referenzen: purchase_order, contract, project, preceding_invoice
Zahlung: IBAN, BIC, payment_means, skonto
Lieferung: delivery_date, service_period, delivery_address
Args: file_content: XML-String oder Base64-kodierte PDF. file_type: Dateityp — "xml" oder "pdf".
| Name | Required | Description | Default |
|---|---|---|---|
| file_type | No | xml | |
| file_content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context by specifying that PDF input must be base64-encoded, that both XML and PDF formats are accepted, and by detailing the JSON output structure. This goes beyond the annotations and helps the agent correctly prepare input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded summary sentence, a detailed but organized bullet list of output fields, and a clear Args section. Every element provides useful information without filler, and the format makes the tool's capabilities easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input formats, parameter encoding, and the full structure of extracted data. Given the tool's complexity (multiple file types, many return fields), this is complete even though an output schema exists. It adds key details (like Base64 for PDFs) that the schema input lacks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's 'Args' section thoroughly explains both parameters: file_content accepts an XML string or base64-encoded PDF, and file_type is 'xml' or 'pdf'. This fully compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Parst eine E-Rechnung (XML oder PDF) und gibt strukturierte Daten zurück', clearly stating the tool parses e-invoices and returns structured data. It explicitly names supported formats (CII-XML, ZUGFeRD/Factur-X PDFs) and is distinct from the sibling generate/validate tools, which focus on different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting invoice data but does not explicitly state when to prefer this tool over the validation or generation siblings. It provides format scope (XML vs PDF) but lacks when-not-to-use guidance or alternative tool references, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validiert eine XRechnung (CII XML) gegen den KoSIT-Validator.
Gibt Fehler, Warnungen und das erkannte Profil zurück.
Args: xml_content: Der vollständige XRechnung-XML-Inhalt als String.
| Name | Required | Description | Default |
|---|---|---|---|
| xml_content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the KoSIT-validator scope and the return of errors/warnings/profile, but it does not disclose potential external dependencies, network usage, or rate limits. This is acceptable but not particularly rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences: purpose, return value, and parameter explanation. No fluff, well-structured, and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, output schema exists), the description covers purpose and parameter well. It lacks explicit usage guidance and does not mention potential external service behavior, but it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for xml_content (0% coverage), but the description compensates with an Args block: 'xml_content: Der vollständige XRechnung-XML-Inhalt als String.' This clarifies that the parameter expects the full XRechnung XML content as a string, adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Validiert eine XRechnung (CII XML) gegen den KoSIT-Validator.' This clearly identifies the resource (XRechnung/CII XML) and the target (KoSIT validator), distinguishing it from siblings like einvoice_validate_zugferd or einvoice_generate_xrechnung.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to validate XRechnung XML, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The sibling tool list offers context, but the description itself lacks direct guidance on choosing this validator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validiert eine ZUGFeRD-PDF, indem das eingebettete XML extrahiert und geprüft wird.
Args: pdf_base64: Die ZUGFeRD-PDF als Base64-kodierter String.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_base64 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the method of validation (extracting embedded XML) but does not disclose potential failure modes or side effects. It is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus an Args list, with no redundant text. It is front-loaded with the purpose and directly explains the parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter, a read-only annotation, and an output schema, the description covers the core purpose and input. It does not include usage comparisons, but for a basic validation tool, the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for pdf_base64, and the description's Args section provides the necessary meaning: the ZUGFeRD-PDF as a Base64-encoded string. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a ZUGFeRD-PDF by extracting and checking the embedded XML. This distinguishes it from sibling tools like einvoice_generate_zugferd and einvoice_validate_xrechnung, which deal with generation or a different validation format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validating ZUGFeRD PDFs but does not explicitly state when to prefer this over alternatives. No mention of exclusions or comparison with sibling tools like einvoice_validate_xrechnung or einvoice_check_compliance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0einvoice_check_complianceeinvoice_generate_xrechnungeinvoice_generate_zugferdeinvoice_parseeinvoice_validate_xrechnungeinvoice_validate_zugferdEach tool has a clearly distinct purpose: generating a ZUGFeRD PDF versus generating an XRechnung XML, validating each format, parsing both, and checking compliance. There is no overlap between generation, validation, parsing, or compliance checking.
All tools use the einvoice_ prefix followed by a verb. The generate and validate tools follow a consistent verb_format pattern (e.g., einvoice_generate_zugferd), while einvoice_parse and einvoice_check_compliance use verb_noun. This is a minor deviation but overall predictable.
Six tools is well-scoped for the e-invoicing domain, covering generation, validation, parsing, and compliance checking for both XRechnung and ZUGFeRD. Each tool earns its place without unnecessary redundancy.
The tool surface covers the full lifecycle of e-invoice handling: create both formats, validate both formats, parse either format, and perform compliance checks. No obvious gaps exist for the stated purpose of generating and verifying e-invoices.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
German e-invoicing: generate XRechnung 3.0, pre-check and extract (incl. ZUGFeRD PDF). Paid.
AI-native ERP MCP: ES/EU fiscal compliance (VeriFactu/TicketBAI/Facturae), invoicing, tax, banking
KoSIT-verified German e-invoices: generate & validate ZUGFeRD, Factur-X, XRechnung, EN 16931.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mavengence/einvoice-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
