BuchhaltungsButler MCP-Server

Overview Schema Source Related Servers Discussions Admin

Buchungen zu Beleg anlegen

bb_postings_create_for_receipt

Create accounting entries for an existing receipt using its customer-specific ID. Use when you have a receipt and need to generate corresponding postings in BuchhaltungsButler.

Instructions

Legt die Buchungssätze zu einem bereits vorhandenen Beleg in BuchhaltungsButler an. Zu nehmen, wenn die id_by_customer eines Belegs vorliegt und dieser gebucht werden soll; bb_postings_create_for_transaction, wenn stattdessen eine Zahlung der Ausgangspunkt ist, und bb_postings_create_free, wenn weder Beleg noch Zahlung vorliegt. Buchungsdatum und Buchungsrichtung kommen vom Beleg und sind keine Argumente. Setzt voraus, dass im Mandanten die Kreditoren- oder Debitorenbuchung eingeschaltet ist. Die Antwort nennt die erzeugten Buchungen nicht; nachsehen mit bb_postings_search. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Eine festgeschriebene Buchung lässt sich nicht löschen, sondern nur mit bb_postings_cancel stornieren; der Storno bleibt dauerhaft sichtbar.

Input Schema

TableJSON Schema

Name	Required	Description
`debtor`	Yes	Debitorenkonto als Gegenkonto, zum Beispiel 10001. Gilt für Ausgangsrechnungen und setzt die eingeschaltete Debitorenbuchung voraus. Die Spezifikation führt das Feld als Pflicht, seine eigene Beschreibung nennt es nur bei passender Belegrichtung nötig; dieser Widerspruch ist nicht aufgelöst. Passt das Konto nicht zur Belegrichtung, antwortet die API mit error_code 8. Debitoren nachschlagen mit bb_debtors_search.
`creditor`	Yes	Kreditorenkonto als Gegenkonto, zum Beispiel 70001. Gilt für Eingangsrechnungen und setzt die eingeschaltete Kreditorenbuchung voraus. Die Spezifikation führt das Feld als Pflicht, seine eigene Beschreibung nennt es nur bei passender Belegrichtung nötig; dieser Widerspruch ist nicht aufgelöst. Passt das Konto nicht zur Belegrichtung, antwortet die API mit error_code 8. Kreditoren nachschlagen mit bb_creditors_search.
`positions`	Yes	Die Buchungssätze zu diesem Beleg, je Eintrag eine Zeile. Mehrere Einträge ergeben eine Splitbuchung; die Summe der Zeilenbeträge muss dem Belegbetrag entsprechen, sonst lehnt BuchhaltungsButler den Aufruf ab. Die BuchhaltungsButler-API nimmt diese Werte als parallele Arrays entgegen (postingaccounts, postingtexts, vats, cost_locations, cost_locations_two, amounts); dieses Werkzeug nimmt eine Positionsliste und rechnet sie um, wodurch die Arrays zwingend gleich lang sind.
`receipt_id_by_customer`	Yes	Die mandantenbezogene Nummer des Belegs, zu finden über bb_receipts_search. Keine globale Kennung. In Suchergebnissen erscheint sie als String; hier ohne Anführungszeichen übergeben.

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

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the tenant-level precondition (creditor/debtor posting must be enabled), that booking date and direction are derived from the receipt rather than supplied, that the response does NOT list created postings (must follow up with bb_postings_search), that it writes to real accounting data, and that a locked posting can only be cancelled via bb_postings_cancel with a permanently visible reversal. This is exactly the context annotations cannot carry.

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 but front-loaded: purpose first, then routing rules, then preconditions, then side effects and follow-up. Every sentence carries operative information and none is redundant.

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?

Given an output schema exists, return values need no explanation, and the description still covers the mutation's preconditions, irreversibility path, and the retrieval tool for verification. An agent has everything needed to call it correctly.

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 already 100%, so the baseline is 3, but the description adds real value by clarifying that booking date and booking direction are derived from the receipt and are deliberately not arguments, which narrows what the agent must reason about. Parameter-level detail otherwise stays in 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?

States a specific verb and resource ('Legt die Buchungssätze zu einem bereits vorhandenen Beleg an') and immediately distinguishes itself from the two closest siblings, bb_postings_create_for_transaction and bb_postings_create_free. An agent can identify the tool without opening the schema.

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?

Explicitly names the trigger condition ('Zu nehmen, wenn die id_by_customer eines Belegs vorliegt und dieser gebucht werden soll') and pairs each alternative with the condition that selects it (payment as starting point vs. neither receipt nor payment). Nothing is left to inference.

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

Deploy Server