Skip to main content
Glama
dennismenken

BuchhaltungsButler MCP-Server

by dennismenken

Belegdatei hochladen

bb_receipts_upload

Upload a receipt file to BuchhaltungsButler, create the receipt, and trigger text recognition; only the file and receipt type are required, with other fields read from the file.

Instructions

Lädt eine Belegdatei nach BuchhaltungsButler, legt daraus einen Beleg an und stößt die Texterkennung an; Pflicht sind nur die Datei und die Belegart, alles Weitere liest BuchhaltungsButler aus der Datei. Beispiel: eine Eingangsrechnung als PDF übergeben und die erkannten Felder danach mit bb_receipts_get prüfen. Für einen Beleg ohne Datei bb_receipts_create, für viele davon bb_receipts_create_batch. Einen Stapelupload gibt es nicht, und an einen bestehenden Beleg lässt sich nachträglich keine Datei hängen. Bei einer E-Rechnung ignoriert die API alle mitgegebenen Metadaten. Eigenes Limit: zehn Aufrufe je Minute. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig nur mit bb_receipts_delete, das den Beleg lediglich als gelöscht markiert; die API kennt keinen Endpunkt, der einen Beleg endgültig entfernt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoBelegdatum, also das Ausstellungsdatum, als YYYY-MM-DD, zum Beispiel 2026-04-26. Ohne Angabe wird es aus der Datei gelesen.
fileYesDie Belegdatei in einer von drei Formen: als base64-Zeichenkette, was immer geht, als https-Adresse oder als file-Adresse. Die beiden Adressformen nimmt der Server nur an, wenn der Betreiber sie freigegeben hat; sonst lehnt er den Aufruf ab, bevor etwas hinausgeht. Angenommene Dateiarten sind PDF, XML, JPEG, PNG, BMP und TIFF; der Typ wird am Inhalt bestimmt und nicht am Namen. Bei der base64-Form gehört der Dateiname in file_name.
amountNoBruttobetrag des Belegs. Dezimalpunkt, kein Tausendertrennzeichen, zum Beispiel 123.99. 0.00 ist kein gültiger Betrag; ein negativer Betrag kennzeichnet eine Rückabwicklung. Ohne Angabe wird er aus der Datei gelesen.
currencyNoDie Spezifikation sagt hier „Has to be 'EUR' if specified“ und widerspricht damit dem Vorrat von /receipts/add mit USD, GBP und CHF. Dass nur 'EUR' gilt, ist nicht verifiziert; dieses Werkzeug prüft den Wert deshalb nicht vorab.
vat_rateNoUmsatzsteuersatz des Belegs in Prozent als Zahl, zum Beispiel 19 oder 0. Weglassen, wenn der Beleg keinen oder mehrere Steuersätze trägt.
file_nameNoDateiname einschließlich Endung, zum Beispiel rechnung-2026-0001.pdf. Bei der base64-Form verlangt die API ihn; fehlt er, kann der Server einen Namen aus dem erkannten Dateityp bilden. Pfadanteile und Steuerzeichen werden entfernt.
counterpartyNoGegenpartei des Belegs: bei einer Eingangsrechnung der Rechnungssteller, bei einer Ausgangsrechnung der Empfänger. Ohne Angabe liest BuchhaltungsButler sie aus der Datei.
receipt_typeYesBelegart, kleingeschrieben und mit Leerzeichen. 'invoice inbound' ist eine Eingangsrechnung, 'invoice outbound' eine Ausgangsrechnung, 'credit inbound' eine Eingangsgutschrift nach § 14 UStG, 'credit outbound' eine Ausgangsgutschrift nach § 14 UStG. Der Parameter heißt in der API type; dieser Name ist dort siebenfach mit verschiedener Bedeutung belegt, deshalb der eindeutige Werkzeugname.
date_deliveryNoLeistungs- oder Lieferdatum als YYYY-MM-DD, zum Beispiel 2026-04-26. Wegen der DATEV-Kompatibilität nimmt BuchhaltungsButler kein Leistungsdatum nach dem Belegdatum an.
invoice_numberNoRechnungsnummer des Belegs, zum Beispiel ER-2026-0001, höchstens 60 Zeichen. Ohne Angabe wird sie aus der Datei gelesen.
creditor_debtorNoNummer des Personenkontos, dem der Beleg zugeordnet wird: bei Eingangsbelegen ein Kreditor, bei Ausgangsbelegen ein Debitor, zum Beispiel 70001. Nachschlagen mit bb_postingaccounts_search, das Sachkonten, Zahlungskonten, Debitoren und Kreditoren gemeinsam führt. Nutzbar nur, wenn Debitoren und Kreditoren beim Mandanten aktiviert sind, und passend zur Belegart.
date_payment_dueNoFälligkeitsdatum als YYYY-MM-DD, zum Beispiel 2026-05-26. In der Antwort der Suche heißt das Feld due_date.
payment_referenceNoTechnische Zahlungsreferenz, zum Beispiel eine Amazon-Bestellnummer oder eine Vorgangsnummer von PayPal oder Stripe. Kein Verwendungszweck als Freitext. Stimmt sie, findet BuchhaltungsButler die passende Zahlung von selbst.
payment_account_numberNoSachkontonummer, die ein Zahlungskonto bezeichnet, zum Beispiel '1200'. Nicht das Sachkonto, auf das gebucht wird. Zahlungskonten auflisten mit bb_payment_accounts_list. Der Beleg wird damit unmittelbar diesem Zahlungskonto zugeordnet. Der Parameter heißt in der API account.
link_to_receipt_id_by_customerNoDie mandantenbezogene Nummer eines anderen Belegs, zu finden über bb_receipts_search. Keine globale Kennung; hier ohne Anführungszeichen übergeben. Beide Belege werden gemeinsam einer Zahlung zugeordnet, sobald einer von ihnen von Hand zugeordnet wird.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
createdNo
messageNo
successYes
endpointNo
reversalNo
_contract_warningsNo
fields_not_returnedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Discloses behavior beyond annotations: rate limit (10 calls/minute), E-Rechnung ignores metadata, writes to real accounting data ('Schreibt in die echten Buchhaltungsdaten'), undo semantics only via bb_receipts_delete which merely marks as deleted (no endpoint for permanent removal). Annotations cover safety profile but description adds depth on irreversibility.

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?

Dense but front-loaded with action and requirements first, then routing, then caveats. Long but every clause carries operational value (rate limit, E-Rechnung, undo semantics). Slightly dense for agent parsing but no filler.

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

Completeness5/5

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

For a 15-param, non-idempotent, open-world write tool with an output schema, description covers requirements, alternatives, limitations (no batch, no attach), rate limits, and non-reversible deletion semantics. Sufficient for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so schema does most work. Description adds value by clarifying requirements ('Pflicht sind nur die Datei und die Belegart, alles Weitere liest BuchhaltungsButler aus der Datei') and flagging the E-Rechnung metadata-ignore behavior plus the currency spec contradiction.

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?

Specific verb+resource: 'Lädt eine Belegdatei nach BuchhaltungsButler, legt daraus einen Beleg an und stößt die Texterkennung an'. Explicitly distinguishes from siblings bb_receipts_create (receipt without file) and bb_receipts_create_batch (many). Also states what is NOT possible (no batch upload, no attaching file to existing receipt).

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

Usage Guidelines5/5

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

Explicit routing: 'Für einen Beleg ohne Datei bb_receipts_create, für viele davon bb_receipts_create_batch'. States the negative case (no batch upload, cannot attach to existing receipt). Example workflow (upload PDF then verify with bb_receipts_get) provided.

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