Skip to main content
Glama

create_invoice

Erstellt aus strukturierten Daten eine gültige E-Rechnung, als ZUGFeRD-PDF (PDF/A-3 mit eingebettetem XML) oder als XRechnung-XML. Unterstützt mehrere Positionen, durchlaufende Posten, Rabatte und Zuschläge, Leistungszeitraum, schon gezahlte Beträge, Steuernummer, SEPA-Lastschrift und Anlagen. Anlagen stecken Base64-kodiert in der Rechnung und machen Aufruf und Antwort groß; schicken Sie hier nur kleine. Mit Anlagen enthält die ZUGFeRD-Antwort nur pdf_base64, das XML steckt in der PDF (extract_xml holt es). Wir speichern nichts.

Input Schema

NameRequiredDescriptionDefault
dateYesBelegdatum (YYYY-MM-DD)
noteNoFreitext-Hinweis
buyerYesKäufer / Rechnungsempfänger
linesYesRechnungspositionen (mindestens eine)
formatYes'zugferd' = PDF/A-3 mit eingebettetem XML, 'xrechnung' = reines XML
numberYesBelegnummer
sellerNoVerkäufer / Rechnungssteller. Weglassen, wenn im Konto feste Absenderdaten hinterlegt sind — sie werden dann eingesetzt.
currencyNoWährung (Standard EUR)
due_dateNoFälligkeitsdatum (YYYY-MM-DD)
type_codeNoRoher UNTDID-1001-Code (überschreibt document_type; für seltene Typen wie 875-877 Bauleistung)
self_checkNoWenn true, wird die erzeugte Rechnung sofort gegen EN 16931 geprüft (langsamer). Standard: false.
attachmentsNoAnlagen (BG-24): PDF, PNG, JPEG, CSV, XLSX oder ODS, höchstens 10 Dateien, zusammen höchstens 5 MB, jeder Dateiname nur einmal. Ab zwei Anlagen warnt die Prüfung mit CII-SR-476; die Rechnung bleibt gültig.
seller_logoNoLogo als Base64 (PNG/JPG) — nur im Pro/Ultra-Tarif
direct_debitNoSEPA-Lastschrift (BG-19) mit Mandatsreferenz, Gläubiger-ID und IBAN Ihres Kunden. Setzt die Zahlungsart 59; ein Empfängerkonto kommt dann nicht ins XML (BR-DE-25-b).
delivery_dateNoLeistungsdatum (BT-72, YYYY-MM-DD). Ohne Angabe: Ende von billing_period, bei einer Vorschussrechnung (prepayment) keins, sonst das Belegdatum.
document_typeNoRechnungsart (BT-3), Standard invoice. credit_note = Rechnungskorrektur (Storno), corrected = Korrektur, self_billed = Gutschriftverfahren, prepayment = Vorschuss- oder Anzahlungsrechnung (XRechnung warnt mit BR-DE-17, die Rechnung bleibt gültig), partial = Teilrechnung, debit_note = Belastungsanzeige.
payment_meansNoZahlungsangaben (IBAN etc.)
payment_termsNoZahlungsbedingungen (Freitext)
billing_periodNoLeistungszeitraum (BG-14, BT-73/74), jeweils YYYY-MM-DD, Ende nicht vor Anfang. Ohne delivery_date gilt das Ende als Leistungsdatum (BT-72).
buyer_referenceNoLeitweg-ID / Käuferreferenz (BT-10, bei XRechnung Pflicht)
preceding_invoiceNoBezug auf eine frühere Rechnung (BG-3, BT-25/26), etwa bei einer Rechnungskorrektur (Storno). Für mehrere Bezüge preceding_invoices, nicht beides.
prepaid_vat_centsNoUmsatzsteuer im schon gezahlten Betrag, in Cent. Nur mit prepaid_amount_cents; der Hinweis nennt dann Entgelt und Steuer des Abzugs (§ 14 Abs. 5 UStG).
allowances_chargesNoRabatte/Zuschläge auf Dokumentebene
preceding_invoicesNoBezüge auf frühere Rechnungen (BG-3), etwa Vorschussrechnungen, höchstens 20. Ins XML kommt in beiden Formaten nur der erste als BG-3; alle weiteren nennt der Hinweis (BT-22).
prepaid_amount_centsNoSchon gezahlt, etwa ein Vorschuss, brutto in Cent (BT-113). Wir ziehen es vom Zahlbetrag ab (BR-CO-16); höher als der Gesamtbetrag geht nicht. Dazu kommt ein Hinweis (BT-22) mit dem Abzug und den Bezügen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / direct_debit / description
      Previous value: -"SEPA-Lastschrift (BG-19) mit Mandatsreferenz, Gläubiger-ID und IBAN deines Kunden. Setzt die Zahlungsart 59; ein Empfängerkonto kommt dann nicht ins XML (BR-DE-25-b)."New value: +"SEPA-Lastschrift (BG-19) mit Mandatsreferenz, Gläubiger-ID und IBAN Ihres Kunden. Setzt die Zahlungsart 59; ein Empfängerkonto kommt dann nicht ins XML (BR-DE-25-b)."
    • changedInput schema / properties / direct_debit / properties / creditor_id / description
      Previous value: -"Deine Gläubiger-ID (BT-90), z.B. DE98ZZZ09999999999. Fehlt sie, nehmen wir die aus dem Absenderprofil."New value: +"Ihre Gläubiger-ID (BT-90), z.B. DE98ZZZ09999999999. Fehlt sie, nehmen wir die aus dem Absenderprofil."
    • changedInput schema / properties / direct_debit / properties / debtor_iban / description
      Previous value: -"IBAN deines Kunden (BT-91). Bei ZUGFeRD auch gekürzt (DE89**************3000), bei XRechnung nur voll."New value: +"IBAN Ihres Kunden (BT-91). Bei ZUGFeRD auch gekürzt (DE89**************3000), bei XRechnung nur voll."
  2. Changed46 schema fields changed
    • removedInput schema / properties / allowances_charges / items / properties / vat_category / $ref
      Removed value: -"#/properties/lines/items/properties/vat_category"
    • addedInput schema / properties / allowances_charges / items / properties / vat_category / enum
      Added value: +[
      +  "S",
      +  "Z",
      +  "E",
      +  "AE",
      +  "K",
      +  "G",
      +  "O"
      +]
    • addedInput schema / properties / allowances_charges / items / properties / vat_category / type
      Added value: +"string"
    • addedInput schema / properties / attachments
      Added value: +{
      +  "description": "Anlagen (BG-24): PDF, PNG, JPEG, CSV, XLSX oder ODS, höchstens 10 Dateien, zusammen höchstens 5 MB, jeder Dateiname nur einmal. Ab zwei Anlagen warnt die Prüfung mit CII-SR-476; die Rechnung bleibt gültig.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "content_base64": {
      +        "description": "Inhalt der Datei, Base64-kodiert",
      +        "type": "string"
      +      },
      +      "description": {
      +        "description": "Beschreibung (BT-123), höchstens 200 Zeichen",
      +        "type": "string"
      +      },
      +      "filename": {
      +        "description": "Dateiname mit Endung .pdf, .png, .jpg, .jpeg, .csv, .xlsx oder .ods, höchstens 100 Zeichen",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "filename",
      +      "content_base64"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / billing_period / description
      Previous value: -"Leistungszeitraum (BG-14, BT-73/74) bei laufenden Leistungen, jeweils YYYY-MM-DD. Ersetzt delivery_date."New value: +"Leistungszeitraum (BG-14, BT-73/74), jeweils YYYY-MM-DD, Ende nicht vor Anfang. Ohne delivery_date gilt das Ende als Leistungsdatum (BT-72)."
    • removedInput schema / properties / buyer / properties / city / $ref
      Removed value: -"#/properties/seller/properties/city"
    • addedInput schema / properties / buyer / properties / city / description
      Added value: +"Ort"
    • addedInput schema / properties / buyer / properties / city / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / contact_name / $ref
      Removed value: -"#/properties/seller/properties/contact_name"
    • addedInput schema / properties / buyer / properties / contact_name / description
      Added value: +"Ansprechpartner"
    • addedInput schema / properties / buyer / properties / contact_name / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / country / $ref
      Removed value: -"#/properties/seller/properties/country"
    • addedInput schema / properties / buyer / properties / country / description
      Added value: +"ISO-3166 Alpha-2 Ländercode, Standard DE"
    • addedInput schema / properties / buyer / properties / country / maxLength
      Added value: +2
    • addedInput schema / properties / buyer / properties / country / minLength
      Added value: +2
    • addedInput schema / properties / buyer / properties / country / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / email / $ref
      Removed value: -"#/properties/seller/properties/email"
    • addedInput schema / properties / buyer / properties / email / description
      Added value: +"E-Mail / elektronische Adresse (für XRechnung Pflicht)"
    • addedInput schema / properties / buyer / properties / email / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / name / $ref
      Removed value: -"#/properties/seller/properties/name"
    • addedInput schema / properties / buyer / properties / name / description
      Added value: +"Firmenname / Name"
    • addedInput schema / properties / buyer / properties / name / minLength
      Added value: +1
    • addedInput schema / properties / buyer / properties / name / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / phone / $ref
      Removed value: -"#/properties/seller/properties/phone"
    • addedInput schema / properties / buyer / properties / phone / description
      Added value: +"Telefon (Kontakt)"
    • addedInput schema / properties / buyer / properties / phone / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / street / $ref
      Removed value: -"#/properties/seller/properties/street"
    • addedInput schema / properties / buyer / properties / street / description
      Added value: +"Straße und Hausnummer"
    • addedInput schema / properties / buyer / properties / street / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / vat_id / $ref
      Removed value: -"#/properties/seller/properties/vat_id"
    • addedInput schema / properties / buyer / properties / vat_id / description
      Added value: +"USt-IdNr. (z.B. DE123456789)"
    • addedInput schema / properties / buyer / properties / vat_id / type
      Added value: +"string"
    • removedInput schema / properties / buyer / properties / zip / $ref
      Removed value: -"#/properties/seller/properties/zip"
    • addedInput schema / properties / buyer / properties / zip / description
      Added value: +"Postleitzahl"
    • addedInput schema / properties / buyer / properties / zip / type
      Added value: +"string"
    • changedInput schema / properties / delivery_date / description
      Previous value: -"Leistungs-/Lieferdatum (BT-72, YYYY-MM-DD). In Deutschland Pflichtangabe; ohne Angabe gilt das Belegdatum."New value: +"Leistungsdatum (BT-72, YYYY-MM-DD). Ohne Angabe: Ende von billing_period, bei einer Vorschussrechnung (prepayment) keins, sonst das Belegdatum."
    • addedInput schema / properties / direct_debit
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "SEPA-Lastschrift (BG-19) mit Mandatsreferenz, Gläubiger-ID und IBAN deines Kunden. Setzt die Zahlungsart 59; ein Empfängerkonto kommt dann nicht ins XML (BR-DE-25-b).",
      +  "properties": {
      +    "creditor_id": {
      +      "description": "Deine Gläubiger-ID (BT-90), z.B. DE98ZZZ09999999999. Fehlt sie, nehmen wir die aus dem Absenderprofil.",
      +      "type": "string"
      +    },
      +    "debtor_iban": {
      +      "description": "IBAN deines Kunden (BT-91). Bei ZUGFeRD auch gekürzt (DE89**************3000), bei XRechnung nur voll.",
      +      "type": "string"
      +    },
      +    "mandate_reference": {
      +      "description": "Mandatsreferenz (BT-89), höchstens 35 Zeichen",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / document_type / description
      Previous value: -"Dokumenttyp (Standard invoice). credit_note=Gutschrift/Storno, corrected=Korrektur, self_billed=Gutschriftverfahren, prepayment=Anzahlung, partial=Teilrechnung, debit_note=Belastungsanzeige. Mappt auf BT-3."New value: +"Rechnungsart (BT-3), Standard invoice. credit_note = Rechnungskorrektur (Storno), corrected = Korrektur, self_billed = Gutschriftverfahren, prepayment = Vorschuss- oder Anzahlungsrechnung (XRechnung warnt mit BR-DE-17, die Rechnung bleibt gültig), partial = Teilrechnung, debit_note = Belastungsanzeige."
    • addedInput schema / properties / lines / items / properties / pass_through
      Added value: +{
      +  "description": "true = durchlaufender Posten (§ 10 Abs. 1 UStG) ohne Umsatzsteuer: vat_rate 0, vat_category weglassen oder E. Im XML Kategorie E mit Grund und Code VATEX-EU-79-C. Nicht zusammen mit anderen Positionen der Kategorie E (BR-E-01). Standard false.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / lines / items / properties / vat_category / description
      Previous value: -"USt-Kategorie (Standard S). Z=0%, E=befreit, AE=Reverse-Charge"New value: +"USt-Kategorie (Standard S). Z = 0 %, E = befreit, AE = Reverse Charge, K, G. Durchlaufende Posten über pass_through."
    • changedInput schema / properties / payment_means / properties / type_code / description
      Previous value: -"BT-81 UNTDID-4461-Code (z.B. 58 = SEPA-Überweisung)"New value: +"BT-81: 58 = SEPA-Überweisung; für eine Lastschrift direct_debit angeben (59)."
    • changedInput schema / properties / preceding_invoice / description
      Previous value: -"Bezug auf die Ursprungsrechnung (BT-25/26) — bei Storno, Korrektur oder Gutschrift angeben"New value: +"Bezug auf eine frühere Rechnung (BG-3, BT-25/26), etwa bei einer Rechnungskorrektur (Storno). Für mehrere Bezüge preceding_invoices, nicht beides."
    • addedInput schema / properties / preceding_invoices
      Added value: +{
      +  "description": "Bezüge auf frühere Rechnungen (BG-3), etwa Vorschussrechnungen, höchstens 20. Ins XML kommt in beiden Formaten nur der erste als BG-3; alle weiteren nennt der Hinweis (BT-22).",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "date": {
      +        "description": "Datum der früheren Rechnung (BT-26, YYYY-MM-DD)",
      +        "type": "string"
      +      },
      +      "number": {
      +        "description": "Nummer der früheren Rechnung (BT-25), höchstens 100 Zeichen",
      +        "maxLength": 100,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "number"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / prepaid_amount_cents
      Added value: +{
      +  "description": "Schon gezahlt, etwa ein Vorschuss, brutto in Cent (BT-113). Wir ziehen es vom Zahlbetrag ab (BR-CO-16); höher als der Gesamtbetrag geht nicht. Dazu kommt ein Hinweis (BT-22) mit dem Abzug und den Bezügen.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / prepaid_vat_cents
      Added value: +{
      +  "description": "Umsatzsteuer im schon gezahlten Betrag, in Cent. Nur mit prepaid_amount_cents; der Hinweis nennt dann Entgelt und Steuer des Abzugs (§ 14 Abs. 5 UStG).",
      +  "type": "integer"
      +}
    • addedInput schema / properties / seller / properties / tax_number
      Added value: +{
      +  "description": "Steuernummer (BT-32, z.B. 21/815/08150), wenn keine USt-IdNr. vorliegt. Ohne USt-IdNr. steht sie auch als Kennung des Verkäufers im XML (BT-29), denn EN 16931 verlangt eine (BR-CO-26).",
      +  "type": "string"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / properties / billing_period
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Leistungszeitraum (BG-14, BT-73/74) bei laufenden Leistungen, jeweils YYYY-MM-DD. Ersetzt delivery_date.",
      +  "properties": {
      +    "end": {
      +      "type": "string"
      +    },
      +    "start": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "start",
      +    "end"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / delivery_date
      Added value: +{
      +  "description": "Leistungs-/Lieferdatum (BT-72, YYYY-MM-DD). In Deutschland Pflichtangabe; ohne Angabe gilt das Belegdatum.",
      +  "type": "string"
      +}
    • changedInput schema / properties / seller / description
      Previous value: -"Verkäufer / Rechnungssteller"New value: +"Verkäufer / Rechnungssteller. Weglassen, wenn im Konto feste Absenderdaten hinterlegt sind — sie werden dann eingesetzt."
    • changedInput schema / required
      Previous value: -[
      -  "format",
      -  "number",
      -  "date",
      -  "seller",
      -  "buyer",
      -  "lines"
      -]New value: +[
      +  "format",
      +  "number",
      +  "date",
      +  "buyer",
      +  "lines"
      +]
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does add real behavioral context: base64 attachments inflate both request and response, only small attachments should be sent here, and with attachments the ZUGFeRD response contains only pdf_base64 with the XML embedded in the PDF. It also states 'Wir speichern nichts', disclosing statelessness. It omits permission/tier constraints and the response shape for the no-attachment case, which the schema only partly implies.

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

Conciseness5/5

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

Five sentences, front-loaded with what is produced and in which formats, followed by capability scope, then the attachment caveats. Every sentence adds information; nothing is redundant with the schema.

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 25-parameter mutation tool with no output schema, the description supplies the essential behavioral facts: output format choice, response composition with attachments, size limits, and that nothing is persisted. A minor gap is that the return payload for the plain (no-attachment) case is only implied, not stated.

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 description coverage is 100%, so the schema already documents all 25 parameters in detail. The description adds only marginal parameter meaning — the feature list (line items, pass-through items, allowances/charges, billing period, prepaid amounts, tax number, SEPA direct debit, attachments) maps loosely to parameters and the attachment size caveat is useful, but no new syntax or format semantics beyond the schema.

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?

The description opens with a specific verb and artifact: it creates a valid e-invoice from structured data, and immediately names the two concrete output formats (ZUGFeRD PDF/A-3 with embedded XML, or XRechnung XML). It is clearly distinguishable from siblings such as validate_invoice or validation_report because it is the only tool that produces an invoice rather than checking one.

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?

It establishes the input context (structured data) and the format decision, and explicitly routes the agent to extract_xml when the XML is needed from a ZUGFeRD PDF with attachments. It does not explicitly say when to prefer validate_invoice or check_consistency instead, though the self_check parameter covers the in-line validation case.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources