BuchhaltungsButler MCP-Server

Overview Schema Source Related Servers Discussions Admin

Zahlung anlegen

bb_transactions_create

Creates a payment transaction on a payment account in BuchhaltungsButler for payments not retrieved from bank feeds, like cash entries. Writes to real accounting data; cannot be undone.

Instructions

Legt in BuchhaltungsButler eine Zahlung auf einem echten Zahlungskonto an, also einen Kontoumsatz. Zu nehmen für Vorgänge, die kein Bankabruf einspielt, zum Beispiel eine Barzahlung über 47.60 auf dem Kassenkonto. Buchungssätze entstehen dabei nicht: Die legt bb_postings_create_for_transaction an, und einen Beleg verknüpft bb_transactions_assign_receipt. payment_account_number bezeichnet das Zahlungskonto und nicht das Sachkonto der Buchung. Der Umsatz verändert Kontostand und Abstimmung sofort. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes	Betrag der Zahlung, positiv für einen Eingang und negativ für einen Ausgang. Dezimalpunkt, kein Tausendertrennzeichen, als Zeichenkette übergeben, zum Beispiel "123.99". 0.00 ist kein gültiger Betrag.
`purpose`	No	Verwendungszweck der Zahlung. Soll er leer bleiben, das Feld weglassen: Dieser Server lehnt leere Strings an jedem Feld ab, auch wo die Spezifikation sie zulässt.
`to_from`	Yes	Zahlender oder Empfänger der Zahlung, zum Beispiel 'Muster GmbH'.
`currency`	No	Ohne Angabe bucht BuchhaltungsButler in der Währung des Zahlungskontos; die Spezifikation beschreibt den Betrag ausdrücklich als Betrag in der Kontowährung. Welche Währung ein Zahlungskonto führt, gibt die API an keiner Stelle preis — diesen Wert also nur setzen, wenn er aus dem Vorgang bekannt ist.
`bank_code`	No	Bankleitzahl oder BIC der Gegenseite, zum Beispiel 'BYLADEM1001'.
`bank_name`	No	Name der Bank der Gegenseite.
`value_date`	No	Wertstellungsdatum der Zahlung als YYYY-MM-DD HH:MM:SS, zum Beispiel 2026-04-26 13:45:00. Ein reines Datum YYYY-MM-DD gilt als 23:59:59 dieses Tages. Ein leerer String wird abgelehnt; das Feld stattdessen weglassen. Ohne Angabe übernimmt BuchhaltungsButler den Wert von booking_date.
`booking_date`	Yes	Buchungsdatum der Zahlung als YYYY-MM-DD HH:MM:SS, zum Beispiel 2026-04-26 13:45:00. Ein reines Datum YYYY-MM-DD gilt als 23:59:59 dieses Tages. Ein leerer String wird abgelehnt; das Feld stattdessen weglassen.
`booking_text`	No	Buchungstext der Zahlung, zum Beispiel 'SEPA-Überweisung'. Soll er leer bleiben, das Feld weglassen.
`account_number`	No	Kontonummer oder IBAN der Gegenseite, zum Beispiel 'DE02120300000000202051'.
`transaction_type`	No	Art der Zahlung als Freitext, zum Beispiel 'Direct debit'. Der Body-Parameter der API heißt type; dieser Name ist in der Spezifikation mehrfach mit anderer Bedeutung belegt.
`payment_reference`	No	Zahlungsreferenz des Vorgangs. Trifft sie zu, ordnet BuchhaltungsButler die angelegte Zahlung dem passenden Beleg selbst zu.
`payment_account_number`	Yes	Sachkontonummer, die ein Zahlungskonto bezeichnet, zum Beispiel '1200'. Nicht das Sachkonto, auf das gebucht wird. Zahlungskonten auflisten mit bb_payment_accounts_list. Das Konto muss im Mandanten als Zahlungskonto vorhanden sein. Der Body-Parameter der API heißt account.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`created`	No
`message`	No
`success`	Yes
`endpoint`	No
`reversal`	No
`_contract_warnings`	No
`fields_not_returned`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A5/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that no Buchungssätze are produced, that Kontostand and Abstimmung change immediately, that it writes into live accounting data, and that the API offers no endpoint to reverse it. These are exactly the operational facts an agent needs and none are in readOnlyHint/openWorldHint/destructiveHint.

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?

Dense and front-loaded: purpose first, then the use case, then the downstream-consequence and irreversibility clauses. Every sentence carries information, with 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?

An output schema exists, so return values need no explanation, and the description fills the remaining gaps: irreversible write, immediate balance impact, no posting created, and parameter disambiguation. Nothing needed to call it safely is missing.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds real meaning: payment_account_number refers to the Zahlungskonto and not the posting account (a point the schema's own wording muddies), and it points to bb_payment_accounts_list. This resolves genuine ambiguity beyond the schema text.

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?

Names a specific verb+resource (legt eine Zahlung/Kontoumsatz auf einem echten Zahlungskonto an) and pins the scope: it is for transactions that no bank fetch supplies, with a cash-payment example. It explicitly distinguishes itself from bb_postings_create_for_transaction and bb_transactions_assign_receipt, so an agent can route correctly without opening other schemas.

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?

States when to use it (Vorgänge, die kein Bankabruf einspielt, z.B. Barzahlung über 47.60 auf dem Kassenkonto), when not to expect postings, and names the sibling tools for posting and receipt-linking. Exclusions and alternatives are both explicit.

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

Deploy Server