Holt einen Beleg oder eine Zahlung samt allen zugeordneten Gegenstücken in einem Aufruf und beantwortet damit 'welcher Beleg gehört zu dieser Abbuchung' und 'welche Zahlung hängt an dieser Rechnung'. Genau eines der beiden Kennungsfelder setzen. Ersetzt das Paar bb_receipts_get und bb_receipts_list_transactions sowie das Paar bb_transactions_get und bb_transactions_list_receipts. Konnte die Zuordnungsliste nicht geholt werden, steht dort null und nicht das leere Array; 'keine Zuordnung' wird nur behauptet, wenn die API es gesagt hat. Die Belegdatei kommt nie mit, dafür bb_receipts_get. Höchstens 5 Aufrufe an die API.

Liefert das Kontenblatt eines Kontos mit fortgeschriebenem Saldo und beantwortet damit 'stimmt mein Kassenbestand' und 'wie viel ist gerade auf PayPal'. account nimmt eine Kontonummer oder den Namen eines Zahlungskontos; die Nummer eines Sachkontos liefert bb_masterdata_search. Der Saldo steht in der letzten Zeile und enthält gemessen auch den Bestand vor date_from; gekürzt wird deshalb in der Mitte und nie am Ende. Ersetzt bb_reports_get_ledger für die Frage nach dem Kontostand; alle 24 Felder je Buchungszeile liefert weiterhin nur dieses Einzelwerkzeug. Ein leeres Kontenblatt ist kein Saldo von 0,00. Höchstens 2 Aufrufe an die API.

Hängt einen Kommentar an einen Beleg oder an eine Zahlung in BuchhaltungsButler. Gedacht für einen Hinweis an die Buchhaltung, etwa warum ein Beleg noch offen ist. Genau eine der beiden Kennungen receipt_id_by_customer und transaction_id_by_customer angeben; die API lehnt den Aufruf sonst ab. Der Kommentar ist für alle Nutzer des Mandanten sichtbar. Die API kennt keinen Endpunkt, Kommentare zu lesen, zu ändern oder zu entfernen, und die Antwort nennt auch keine Kennung des angelegten Kommentars. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Legt eine Kostenstelle in BuchhaltungsButler an, mit einem selbst gewählten code von höchstens 10 Zeichen und einer Bezeichnung. Gedacht für eine neue Abteilung oder ein neues Projekt, auf das Buchungszeilen verteilt werden sollen. Die Kostenstelle steht danach in den Positionsfeldern cost_location und cost_location_two der Buchungswerkzeuge zur Verfügung. Welche Codes schon belegt sind, zeigt bb_cost_locations_search. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_cost_locations_delete.

Löscht eine Kostenstelle in BuchhaltungsButler über ihren code. Gedacht für eine versehentlich angelegte oder nicht mehr benutzte Kostenstelle. Was mit Buchungen geschieht, die auf diese Kostenstelle verweisen, ist nicht dokumentiert und nicht verifiziert: Die Zuordnung kann verloren gehen. Welche Buchungen betroffen sind, zeigt bb_postings_search. Entfernt Daten aus dem echten Mandanten von BuchhaltungsButler: eine Kostenstelle samt ihrer Bezeichnung. Die betroffenen Datensätze vorher lesen und dem Nutzer vorlegen.

Listet die Kostenstellen des Mandanten in BuchhaltungsButler auf oder holt mit code genau eine. Gedacht zum Nachschlagen, bevor eine Buchungszeile über cost_location einer Kostenstelle zugeordnet wird. Eine numerische Kennung gibt es nicht, der code ist der Schlüssel. Geliefert werden nur code und name, keine Auswertung und keine Summen. Höchstens 1000 Zeilen je Aufruf.

Überschreibt die Bezeichnung einer Kostenstelle in BuchhaltungsButler. Gedacht für eine berichtigte Bezeichnung. Der code bleibt unverändert; er ist der Identifikator und lässt sich nicht ändern. Buchungen, die auf diese Kostenstelle verweisen, bleiben erhalten und erscheinen danach unter der neuen Bezeichnung. Die Antwort bestätigt die neue Bezeichnung nicht, deshalb den Stand vorher und nachher mit bb_cost_locations_search lesen. Überschreibt Stammdaten im echten Mandanten von BuchhaltungsButler. Die API liefert die vorherigen Werte nicht zurück; ohne vorher gelesenen Datensatz ist die Änderung nicht rückgängig zu machen.

Legt ein Kreditorenkonto, also ein Lieferantenkonto, in BuchhaltungsButler an. Gedacht für einen neuen Lieferanten, bevor eine Eingangsrechnung kreditorisch erfasst wird. Ohne postingaccount_number vergibt BuchhaltungsButler die nächste freie Nummer und nennt sie in der Antwort. Mehrere Konten in einem Aufruf legt bb_creditors_create_batch an; Kunden sind Debitoren und gehören zu bb_debtors_create. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Legt mehrere Kreditorenkonten in BuchhaltungsButler in einem Aufruf an. Gedacht für die Übernahme einer Lieferantenliste. Ein Element trägt dieselben Felder wie bb_creditors_create, allerdings ohne email. Die Antwort meldet Teilerfolg: Das Array errors nennt jeden abgelehnten Eintrag. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Listet die Kreditorenkonten des Mandanten in BuchhaltungsButler auf, also die Lieferantenkonten, mit Kontonummer, Name und Anschrift. Gedacht zum Nachschlagen, bevor eine Eingangsrechnung einem Lieferanten zugeordnet wird. Sachkonten, Zahlungskonten und Debitoren liefert dieser Endpunkt nicht; dafür bb_postingaccounts_search. Einen Filter kennt er nicht, und die Zahlungsfrist due_in_days liefert er nicht mit. Ohne ausdrückliches limit liefert die API nur 25 Zeilen.

Überschreibt die Stammdaten eines Kreditorenkontos in BuchhaltungsButler, die Bankverbindung eingeschlossen. Gedacht für eine geänderte Anschrift oder IBAN eines Lieferanten. Angesprochen wird das Konto über postingaccount_number; die Nummer selbst lässt sich nicht ändern. Ob ein weggelassenes Feld unverändert bleibt, ist nicht dokumentiert — im Zweifel den vollständigen Datensatz senden, vorher gelesen mit bb_creditors_search. Überschreibt Stammdaten im echten Mandanten von BuchhaltungsButler. Die API liefert die vorherigen Werte nicht zurück; ohne vorher gelesenen Datensatz ist die Änderung nicht rückgängig zu machen.

Legt ein Debitorenkonto, also ein Kundenkonto, in BuchhaltungsButler an. Gedacht für einen neuen Kunden, bevor ihm eine Ausgangsrechnung zugeordnet wird. Ohne postingaccount_number vergibt BuchhaltungsButler die nächste freie Nummer und nennt sie in der Antwort. Mehrere Konten in einem Aufruf legt bb_debtors_create_batch an; Lieferanten sind Kreditoren und gehören zu bb_creditors_create. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Legt mehrere Debitorenkonten in BuchhaltungsButler in einem Aufruf an. Gedacht für die Übernahme einer Kundenliste. Ein Element trägt dieselben Felder wie bb_debtors_create, allerdings ohne email. Die Antwort meldet Teilerfolg: Das Array errors nennt jeden abgelehnten Eintrag. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Listet die Debitorenkonten des Mandanten in BuchhaltungsButler auf, also die Kundenkonten, mit Kontonummer, Name, Kundennummer und Anschrift. Gedacht zum Nachschlagen, bevor eine Ausgangsrechnung einem Kunden zugeordnet wird. Sachkonten, Zahlungskonten und Kreditoren liefert dieser Endpunkt nicht; dafür bb_postingaccounts_search. Einen Filter kennt er nicht, gesucht wird in der gelieferten Liste. Ohne ausdrückliches limit liefert die API nur 25 Zeilen.

Überschreibt die Stammdaten eines Debitorenkontos in BuchhaltungsButler, Anschrift und Bankverbindung eingeschlossen. Gedacht für eine geänderte Adresse oder IBAN eines Kunden. Angesprochen wird das Konto über postingaccount_number; die Nummer selbst lässt sich nicht ändern. Ob ein weggelassenes Feld unverändert bleibt, ist nicht dokumentiert — im Zweifel den vollständigen Datensatz senden, vorher gelesen mit bb_debtors_search. Überschreibt Stammdaten im echten Mandanten von BuchhaltungsButler. Die API liefert die vorherigen Werte nicht zurück; ohne vorher gelesenen Datensatz ist die Änderung nicht rückgängig zu machen.

Erzeugt in BuchhaltungsButler eine endgültige Ausgangsrechnung, eine Gutschrift oder ein Angebot: nummeriert, als PDF und als Ausgangsbeleg der Buchhaltung. Zu nehmen, sobald der Vorgang final ist, etwa 10 Std. Beratung zu 120.00 je Stunde; bb_invoices_create_draft erzeugt stattdessen einen Entwurf ohne Nummernvergabe, bb_invoices_create_einvoice eine E-Rechnung mit Steuerart je Position. Die API kennt keinen Pfad, eine Rechnung oder ihr PDF zu lesen; nachsehen lässt sich das Ergebnis nur in der Weboberfläche. Einen Währungsparameter gibt es nicht, Rechnungen über die API laufen in Euro. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Erzeugt in BuchhaltungsButler einen Rechnungsentwurf: ohne endgültige Nummer, ohne PDF, aber als sichtbares Objekt in der Rechnungsstellung des Mandanten. Zu nehmen, solange der Vorgang noch abgestimmt wird, etwa ein Angebot zur internen Durchsicht; bb_invoices_create erzeugt die endgültige, nummerierte Rechnung, bb_invoices_create_einvoice die E-Rechnung. Die Antwort trägt ausschließlich success und message: keine id_by_customer, keine invoicenumber, und die API kennt keinen Pfad, den Entwurf später zu lesen. Die Felder invoicenumber, due_days und payment_reference führt dieser Endpunkt nicht. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Erzeugt in BuchhaltungsButler eine E-Rechnung: endgültig, nummeriert, mit PDF und strukturiertem Datensatz nach EN 16931. Zu nehmen für Empfänger, die eine E-Rechnung verlangen, etwa öffentliche Auftraggeber; bb_invoices_create erzeugt die gewöhnliche Rechnung, bb_invoices_create_draft einen Entwurf. Strengste Feldprüfung der API: Die Käuferreferenz e_invoice_id sowie street, zip, city, country und email des Empfängers sind Pflicht, und je Position stehen item_tax_type und item_tax_amount an der Stelle von item_vat. Die API kennt keinen Pfad, eine Rechnung zu lesen; nachsehen lässt sich das Ergebnis nur in der Weboberfläche. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Findet ein Zahlungskonto, ein Sachkonto, einen Debitor, einen Kreditor oder eine Kostenstelle über den Namen oder die Nummer, ohne dass man vorher wissen muss, in welcher Liste der Eintrag geführt wird. Ohne query kommt stattdessen der Arbeitskontext für den Sitzungsanfang: Zahlungskonten und Kostenstellen als Liste, der Kontenrahmen als Zusammenfassung. Ersetzt für die Frage nach einer Nummer bb_payment_accounts_list, bb_cost_locations_search, bb_postingaccounts_search, bb_debtors_search und bb_creditors_search; Adresse und Bankverbindung liefern weiterhin nur diese Einzelwerkzeuge. Die Einzelkonten des Kontenrahmens kommen nie vollständig mit, er wiegt grob 60.000 Token. Höchstens 5 Aufrufe an die API; die Antwort sagt in bundle.complete, wenn dabei etwas offen geblieben ist.

Legt ein manuell geführtes Zahlungskonto in BuchhaltungsButler an, etwa eine Kasse oder ein Kreditkartenkonto. Gedacht für ein Konto ohne Bankanbindung. Die postingaccount_number muss zur gewählten Art passen; die bestehenden Konten und ihre Nummern zeigt bb_payment_accounts_list. Ein Aufwands- oder Ertragskonto ist kein Zahlungskonto und gehört zu bb_postingaccounts_create. is_revision_safe wirkt nur bei einer Kasse und legt dauerhaftes Verhalten fest. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Listet die Zahlungskonten des Mandanten in BuchhaltungsButler auf, also Kassen, Bank- und Kreditkartenkonten. Je Konto kommen genau zwei Felder: name und postingaccount_number. Diese Nummer ist eine Sachkontonummer und bezeichnet trotzdem ein Zahlungskonto; genau dieser Wert gehört in das Feld payment_account_number von bb_receipts_create, bb_receipts_upload und bb_transactions_create. Gedacht zum Nachschlagen, bevor eine Zahlung oder ein Beleg einem Konto zugeordnet wird. Der Endpunkt kennt weder limit noch offset und liefert immer alle Konten. Kontoart, Kontostand und Währung liefert er nicht: Die Kontoart steht als subtype in bb_postingaccounts_search, die Währung gibt die API an keiner Stelle preis.

Legt ein neues Sachkonto im Kontenrahmen des Mandanten in BuchhaltungsButler an. Gedacht für ein eigenes Aufwandskonto, etwa 4931 für Softwarelizenzen. Das neue Konto erbt seine Eigenschaften, darunter die Steuerbehandlung, vom Vorlagekonto parent_postingaccount_number; dieses vorher mit bb_postingaccounts_search heraussuchen. Kundenkonten legt bb_debtors_create an, Lieferantenkonten bb_creditors_create, Zahlungskonten bb_payment_accounts_create. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Durchsucht den Kontenrahmen des Mandanten in BuchhaltungsButler. Die Liste ist eine Vereinigung: Sachkonten, Zahlungskonten, Debitoren und Kreditoren stehen darin nebeneinander und sind nur an type und subtype zu unterscheiden, etwa 'postingaccount' gegen 'account'. Beide Felder liefert dieses Werkzeug deshalb immer mit. Gedacht zum Nachschlagen einer Sachkontonummer, bevor gebucht wird. Nur die Zahlungskonten mit ihrer zugehörigen Sachkontonummer liefert bb_payment_accounts_list; ein neues Sachkonto legt bb_postingaccounts_create an. Kontostände und Buchungen liefert dieses Werkzeug nicht, dafür bb_reports_get_ledger. Ohne ausdrückliches limit liefert die API 1000 Zeilen; eine Obergrenze dokumentiert sie nicht.

Überschreibt die Bezeichnung eines Sachkontos in BuchhaltungsButler. Gedacht für eine berichtigte Kontobezeichnung. Mehr als den Namen ändert dieser Endpunkt nicht: Nummer, Vorlagekonto und Steuerbehandlung bleiben, wie sie sind. Bestehende Buchungen verweisen weiter auf dieses Konto und erscheinen danach unter dem neuen Namen; die Buchungen selbst bleiben unverändert. Den alten Namen vorher mit bb_postingaccounts_search lesen. Überschreibt Stammdaten im echten Mandanten von BuchhaltungsButler. Die API liefert die vorherigen Werte nicht zurück; ohne vorher gelesenen Datensatz ist die Änderung nicht rückgängig zu machen.

Bindet in BuchhaltungsButler einen vorhandenen Beleg an eine vorhandene freie Buchung. Zu nehmen, wenn eine freie Buchung nachträglich ihren Beleg bekommen soll, etwa weil bb_postings_create_free ohne Belegbezug gebucht hat; die Zuordnung eines Belegs zu einer Zahlung leistet stattdessen bb_transactions_assign_receipt. Ändert den Buchungssatz nicht, sondern nur die Verknüpfung, und legt keine Buchung an. posting_id_by_customer muss auf eine freie Buchung zeigen, sonst lehnt die API mit error_code 10 ab. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Storniert in BuchhaltungsButler eine einzelne Buchungszeile. Zu nehmen, wenn eine festgeschriebene Buchung zu korrigieren ist; eine nicht festgeschriebene entfernen bb_postings_unconfirm_for_receipt, bb_postings_unconfirm_for_transaction und bb_postings_unconfirm_free rückstandslos. War die Buchung festgeschrieben, entsteht eine dauerhaft sichtbare Stornobuchung, sonst verschwindet sie; die Antwort unterscheidet beides nicht, deshalb vorher fixed mit bb_postings_search lesen. Storniert genau eine Zeile: eine Splitbuchung mit fünf Zeilen braucht fünf Aufrufe, und ein Zwischenstand ist ein unausgeglichener Buchungsstand. Entfernt Daten aus dem echten Mandanten von BuchhaltungsButler: die genannte Buchungszeile. Die betroffenen Datensätze vorher lesen und dem Nutzer vorlegen.

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.

Legt die Buchungssätze zu mehreren vorhandenen Belegen in BuchhaltungsButler in einem Aufruf an. Zu nehmen, wenn viele Belege zu buchen sind, etwa ein Monat Eingangsrechnungen; für einen einzelnen Beleg bb_postings_create_for_receipt. Der Stapel ist nicht transaktional: success auf oberster Ebene sagt nichts über die einzelnen Einträge, das Array errors der Antwort nennt die gescheiterten. 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.

Legt die Buchungssätze zu einer bereits vorhandenen Zahlung in BuchhaltungsButler an. Zu nehmen, wenn die id_by_customer einer Zahlung vorliegt und diese gebucht werden soll; bb_postings_create_for_receipt, wenn stattdessen ein Beleg der Ausgangspunkt ist, und bb_postings_create_free, wenn weder Beleg noch Zahlung vorliegt. Je Position lässt sich ein offener Posten ausgleichen. Buchungsdatum, Gegenkonto und Buchungsrichtung kommen von der Zahlung und sind keine Argumente. 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.

Legt die Buchungssätze zu mehreren vorhandenen Zahlungen in BuchhaltungsButler in einem Aufruf an. Zu nehmen, wenn ein ganzer Kontoauszug zu buchen ist; für eine einzelne Zahlung bb_postings_create_for_transaction. Der Stapel ist nicht transaktional: success auf oberster Ebene sagt nichts über die einzelnen Einträge, das Array errors der Antwort nennt die gescheiterten. 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.

Legt in BuchhaltungsButler eine freie Buchung an, also einen vollständigen Buchungssatz ohne Beleg- und Zahlungsbezug, etwa eine Umbuchung zwischen zwei Sachkonten. Zu nehmen, wenn weder ein Beleg noch eine Zahlung vorliegt; liegt ein Beleg vor, ist bb_postings_create_for_receipt richtig, liegt eine Zahlung vor, bb_postings_create_for_transaction. Der Aufruf erzeugt genau eine Buchungszeile; eine Splitbuchung über mehrere Zeilen nehmen die beiden genannten Werkzeuge über ihre Positionsliste entgegen. Soll- und Habenkonto werden hier ausdrücklich angegeben. Die Antwort nennt die erzeugte id_by_customer nicht. 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.

Legt in BuchhaltungsButler mehrere freie Buchungen in einem Aufruf an, also vollständige Buchungssätze ohne Beleg- und Zahlungsbezug. Zu nehmen, wenn viele Umbuchungen auf einmal anfallen, etwa Abgrenzungen zum Jahreswechsel; für eine einzelne bb_postings_create_free. Jeder Eintrag erzeugt genau eine Buchungszeile, eine Klammer über mehrere Zeilen gibt es nicht. Der Stapel ist nicht transaktional: success auf oberster Ebene sagt nichts über die einzelnen Einträge, das Array errors der Antwort nennt die gescheiterten. 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.

Liest die Buchungssätze eines Zeitraums aus der Buchhaltung von BuchhaltungsButler. Zu nehmen, um vorhandene Buchungen zu sehen, etwa alle Buchungen des ersten Quartals auf dem Sachkonto 4980, oder um nach einem Schreibvorgang nachzusehen, ob er gewirkt hat. date_from und date_to sind Pflicht; einen unbegrenzten Abruf gibt es nicht. Liefert weder Belege noch Zahlungen, sondern die Buchungszeilen selbst: Belege holt bb_receipts_search, Zahlungen bb_transactions_search. Die Felder mit dem Namensanfang receipts_assigned sind keine Listen, sondern verkettete Zeichenketten und taugen zur Anzeige, nicht zur Weiterverarbeitung. Höchstens 1000 Zeilen je Aufruf; rows ist die Zeilenzahl dieser Antwort und nie eine Gesamttrefferzahl, weiter geht es über offset. Die Schreibweise von order unterscheidet Groß- und Kleinschreibung.

Hebt in BuchhaltungsButler die Bestätigung der Buchungen eines Belegs auf und entfernt sie damit. Zu nehmen, um eine falsche Belegbuchung zurückzunehmen, solange sie nicht festgeschrieben ist; hängen die Buchungen an einer verknüpften Zahlung, ist bb_postings_unconfirm_for_transaction zuständig, bei einer freien Buchung bb_postings_unconfirm_free. Entfernt immer alle Zeilen des Belegs, nie eine einzelne Zeile einer Splitbuchung, und lässt den Beleg selbst unverändert. Festgeschriebene Buchungen bleiben stehen; dort hilft nur bb_postings_cancel. Entfernt Daten aus dem echten Mandanten von BuchhaltungsButler: alle nicht festgeschriebenen Buchungszeilen des genannten Belegs. Die betroffenen Datensätze vorher lesen und dem Nutzer vorlegen.

Hebt in BuchhaltungsButler die Bestätigung der Buchungen einer Zahlung auf und entfernt sie damit. Zu nehmen, um eine falsche Zahlungsbuchung zurückzunehmen, solange sie nicht festgeschrieben ist; ist ein Beleg der Ausgangspunkt, ist bb_postings_unconfirm_for_receipt zuständig, bei einer freien Buchung bb_postings_unconfirm_free. Entfernt immer alle Zeilen der Zahlung, nie eine einzelne Zeile einer Splitbuchung, und lässt die Zahlung selbst unverändert. Festgeschriebene Buchungen bleiben stehen; dort hilft nur bb_postings_cancel. Entfernt Daten aus dem echten Mandanten von BuchhaltungsButler: alle nicht festgeschriebenen Buchungszeilen der genannten Zahlung. Die betroffenen Datensätze vorher lesen und dem Nutzer vorlegen.

Hebt in BuchhaltungsButler die Bestätigung einer einzelnen freien Buchung auf und entfernt sie damit. Zu nehmen, um eine falsche freie Buchung zurückzunehmen, solange sie nicht festgeschrieben ist; für die Buchungen eines Belegs ist bb_postings_unconfirm_for_receipt zuständig, für die einer Zahlung bb_postings_unconfirm_for_transaction. Adressiert wird die Buchung selbst, deshalb posting_id_by_customer und nicht die Nummer eines Belegs. Zeigt der Wert auf eine Beleg- oder Zahlungsbuchung, lehnt die API mit error_code 7 ab; ist die Buchung festgeschrieben, hilft nur bb_postings_cancel. Entfernt Daten aus dem echten Mandanten von BuchhaltungsButler: die genannte freie Buchung. Die betroffenen Datensätze vorher lesen und dem Nutzer vorlegen.

Legt in BuchhaltungsButler einen Beleg ohne Datei an, zum Beispiel den Datensatz einer Eingangsrechnung aus einem Vorsystem; Belegart, Gegenpartei, Rechnungsnummer, Belegdatum, Betrag und Währung sind Pflicht. Gibt es eine Belegdatei, stattdessen bb_receipts_upload nehmen: Nachträglich lässt sich an einen Beleg keine Datei mehr hängen. Mehrere Belege auf einmal legt bb_receipts_create_batch an. Erzeugt weder eine Buchung noch eine Zahlung. 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.

Legt in BuchhaltungsButler bis zu 50 Belege ohne Datei an, beim Import aus einem Vorsystem; höchstens ein Aufruf je fünf Sekunden. Einzeln legt bb_receipts_create an, Belege mit Datei bb_receipts_upload. Erzeugt keine Buchung; Teilerfolg ist der Normalfall. 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.

Markiert einen Beleg in BuchhaltungsButler als gelöscht, zum Beispiel einen versehentlich doppelt angelegten Beleg. Der Beleg bleibt erhalten und ist über bb_receipts_search mit deleted true weiter zu finden; für die laufende Buchhaltung zählt er nicht mehr. Entfernt keine Buchung und keine Zuordnung zu einer Zahlung: Hängt eine bestätigte Buchung am Beleg, lehnt die API den Aufruf ab. Die Zuordnung zwischen Beleg und Zahlung löst bb_transactions_unassign_receipt. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_receipts_restore.

Holt genau einen Beleg aus BuchhaltungsButler über seine mandantenbezogene Belegnummer und liefert mehr Felder als die Suche: Buchungs- und Originalwährung, Umrechnungskurs, Steuersatz, Zahlungsreferenz und auf Wunsch die Belegdatei. Beispiel: den Beleg prüfen, den bb_receipts_search mit id_by_customer 4711 geliefert hat. Zum Suchen nach Zeitraum oder Gegenpartei bb_receipts_search, für die zugeordneten Zahlungen bb_receipts_list_transactions. Liefert keine Buchungssätze und keine Liste: Ein Aufruf holt einen Beleg, und die Feldnamen weichen von denen der Suche ab. amount_paid und amount_paid_fixed sind auch hier gemessen stets '0.00'; den Zahlungsstand trägt allein payment_date.

Listet die Zahlungen, die in BuchhaltungsButler einem bestimmten Beleg zugeordnet sind, etwa um zu prüfen, ob eine Eingangsrechnung schon bezahlt wurde. Die umgekehrte Richtung liefert bb_transactions_list_receipts, den Beleg selbst bb_receipts_get. Liefert keine Belegfelder und keinen Zuordnungsstand: Ob eine Zuordnung bestätigt ist, zeigt erst der Vergleich zweier Aufrufe mit confirmed_only true und false.

Nimmt in BuchhaltungsButler die Löschmarkierung eines Belegs zurück, sodass er wieder für die Buchhaltung zählt; typischer Fall ist ein versehentlich als gelöscht markierter Beleg. Als gelöscht markierte Belege findet bb_receipts_search mit deleted true. Legt keinen Beleg an und stellt keine Datei wieder her: Der Beleg war nie weg, nur markiert. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_receipts_delete.

Durchsucht die Belege eines Mandanten in BuchhaltungsButler, also Eingangs- und Ausgangsrechnungen samt Gutschriften, und liefert sie seitenweise. Beispiel: alle Eingangsbelege eines Monats über list_direction 'inbound' zusammen mit date_from und date_to. Einen einzelnen Beleg samt Fremdwährungsfeldern holt bb_receipts_get, die einem Beleg zugeordneten Zahlungen listet bb_receipts_list_transactions, Buchungssätze liefert bb_postings_search. Liefert keine Belegdatei und keinen Filter nach Belegart: Gutschriften sind erst am Feld type der Antwort zu erkennen. amount_paid und amount_paid_fixed sind gemessen stets '0.00', auch bei bezahlten Belegen: keine Teilzahlung, kein offener Betrag. Bezahlt sagt payment_date. Höchstens 500 Zeilen je Aufruf, Vorgabe 100, weitere Seiten über offset. Eine Gesamttrefferzahl nennt die API nicht; weniger Zeilen als limit bedeutet Ende des Ergebnisses.

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.

Läuft serverseitig über alle Seiten von Belegen, Zahlungen oder Buchungen und liefert Anzahl und Summe statt aller Zeilen; Einzelzeilen erst ab max_rows. Beantwortet 'wie viele offenen Eingangsrechnungen gibt es', 'was ist im März über PayPal gelaufen' und 'finde Rechnung 4711 in beiden Richtungen'. Ersetzt für Zählen und Summieren bb_receipts_search, bb_transactions_search und bb_postings_search; für einzelne Felder, Sortierung oder weitere Filter bleiben diese Werkzeuge zuständig. Summen erscheinen nur, wenn der Bestand vollständig gelesen wurde. Höchstens 10 Aufrufe an die API, list_direction 'both' verdoppelt sie; der Token-Eimer ist prozesslokal, zwei Clients auf demselben Mandanten teilen ihn nicht.

Stößt in BuchhaltungsButler die Erzeugung einer Betriebswirtschaftlichen Auswertung für einen Zeitraum an und liefert deren id_by_customer zurück. Die Berechnung läuft im Hintergrund; abgeholt wird das Ergebnis danach mit bb_reports_get_bwa und report_id_by_customer, das bis zum Abschluss mit error_code 8 antwortet. Ein zweiter Aufruf vor dem Abschluss scheitert mit error_code 12. Dateien kann dieser Endpunkt nicht anfordern, anders als bb_reports_create_sums. Ersetzt die zuvor in BuchhaltungsButler erzeugte Auswertung desselben Typs. Buchungsdaten ändern sich dabei nicht, und die Auswertung lässt sich jederzeit neu erzeugen.

Stößt in BuchhaltungsButler die Erzeugung einer Summen- und Saldenliste über alle Konten des Mandanten an und liefert deren id_by_customer zurück; wahlweise entstehen dabei PDF, CSV und ein ZIP-Archiv mit den Kontenblättern. Die Berechnung läuft im Hintergrund; abgeholt wird das Ergebnis danach mit bb_reports_get_sums und report_id_by_customer, das bis zum Abschluss mit error_code 8 antwortet. Ein zweiter Aufruf vor dem Abschluss scheitert mit error_code 12. Eine Filterung auf einzelne Konten kennt die API nicht. Ersetzt die zuvor in BuchhaltungsButler erzeugte Auswertung desselben Typs. Buchungsdaten ändern sich dabei nicht, und die Auswertung lässt sich jederzeit neu erzeugen.

Holt eine zuvor in BuchhaltungsButler erzeugte Betriebswirtschaftliche Auswertung ab, auf Wunsch samt Dateien. Vorbedingung ist ein Lauf von bb_reports_create_bwa; dessen id_by_customer ist hier einzusetzen. Bei aktivem BB_MCP_READ_ONLY ist dieser erste Schritt gesperrt, dann liefert nur bb_reports_get_ledger eine Auswertung. error_code 8 heißt: Erzeugung läuft noch, einige Sekunden warten. error_code 7 heißt: kein Bericht zu dieser Kennung.

Liefert das Kontenblatt eines Sachkontos aus BuchhaltungsButler für einen Zeitraum, also dessen Buchungen mit laufendem Saldo. Anders als bb_reports_get_bwa und bb_reports_get_sums braucht es keinen Erzeugungsschritt und bleibt auch bei aktivem BB_MCP_READ_ONLY nutzbar. Weder limit noch offset: Ein stark bebuchtes Konto liefert alles auf einmal, lange Zeiträume also in Monatsfenster zerlegen. Ein leeres Kontenblatt ist kein Fehler, sondern ein Konto ohne Buchung.

Holt eine zuvor in BuchhaltungsButler erzeugte Summen- und Saldenliste ab, auf Wunsch samt Dateien. Vorbedingung ist ein Lauf von bb_reports_create_sums; dessen id_by_customer ist hier einzusetzen. Bei aktivem BB_MCP_READ_ONLY ist dieser erste Schritt gesperrt, dann liefert nur bb_reports_get_ledger eine Auswertung. Die Salden stehen im Objekt sums, geschlüsselt nach Kontonummer. error_code 8 heißt: Erzeugung läuft noch. error_code 7 heißt: kein Bericht zu dieser Kennung.

Erzeugt eine BWA oder eine Summen- und Saldenliste für einen Zeitraum, wartet auf die serverseitige Berechnung und liefert die fertige Auswertung im selben Aufruf zurück. Dabei wird geschrieben: /reports/create/bwa beziehungsweise /reports/create/sums ersetzt den zuvor erzeugten Bericht desselben Typs im ganzen Mandanten, und ein gleichzeitig arbeitender zweiter Nutzer verliert damit seinen Bericht. Ersetzt die zuvor in BuchhaltungsButler erzeugte Auswertung desselben Typs. Buchungsdaten ändern sich dabei nicht, und die Auswertung lässt sich jederzeit neu erzeugen. Viele Clients brechen den Aufruf nach rund 60 Sekunden ab; erzeugt und ersetzt ist der Bericht dann trotzdem und nur noch mit bb_reports_get_bwa oder bb_reports_get_sums abzuholen. Bei aktivem BB_MCP_READ_ONLY gesperrt; lesend bleiben diese beiden und bb_reports_get_ledger. Dateien wie PDF oder CSV liefert es nie.

Ordnet in BuchhaltungsButler einen Beleg einer Zahlung zu. Zu nehmen, wenn Beleg und Zahlung denselben Vorgang betreffen, zum Beispiel eine Eingangsrechnung und die Überweisung über denselben Betrag. Mehrere Paare in einem Aufruf stellt bb_transactions_assign_receipt_batch her. Gebucht wird dabei nichts: Die Zuordnung allein erzeugt keinen Buchungssatz, den legt bb_postings_create_for_transaction an. Welche Belege bereits an einer Zahlung hängen, zeigt bb_transactions_list_receipts. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_transactions_unassign_receipt.

Stellt bis zu 50 Zuordnungen aus Beleg und Zahlung in BuchhaltungsButler in einem Aufruf her. Fachlich gleich bb_transactions_assign_receipt, dessen Beschreibung die Einzelheiten trägt; für ein einzelnes Paar dieses Werkzeug nicht nehmen. Gebucht wird dabei nichts. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_transactions_unassign_receipt.

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.

Legt bis zu 50 Zahlungen in BuchhaltungsButler in einem Aufruf an. Fachlich gleich bb_transactions_create, dessen Beschreibung die Felder erklärt; für eine einzelne Zahlung dieses Werkzeug nicht nehmen. Die API erlaubt nur einen Aufruf je fünf Sekunden. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Holt genau eine Zahlung aus BuchhaltungsButler über ihre mandantenbezogene Nummer. Zu nehmen, sobald die id_by_customer einer Zahlung vorliegt, etwa aus einem Ergebnis von bb_transactions_search. Dieser Einzelabruf liefert 13 Felder, darunter account, currency und die Bankdaten der Gegenseite; die Liste aus bb_transactions_search führt nur sechs davon. Er sucht nicht und blättert nicht: genau eine Zahlung je Aufruf.

Listet die Belege auf, die in BuchhaltungsButler einer bestimmten Zahlung zugeordnet sind. Zu nehmen, um vor einer Buchung zu prüfen, ob eine Zahlung schon einen Beleg trägt. Die Gegenrichtung, also die Zahlungen eines Belegs, liefert bb_receipts_list_transactions. Geliefert werden je Beleg nur id_by_customer und filename, keine Beträge; den Beleg selbst holt bb_receipts_get.

Sucht Zahlungen, also Kontoumsätze, in BuchhaltungsButler und liefert sie seitenweise. Zu nehmen, um den Umsatz zu einem Beleg zu finden, zum Beispiel alle Zahlungen eines Zahlungskontos zwischen date_from 2026-01-01 und date_to 2026-01-31. Eine einzelne, schon bekannte Zahlung holt bb_transactions_get kürzer; die zugeordneten Belege liefert bb_transactions_list_receipts. Diese Liste führt sechs Felder und darunter kein account: Auf welchem Zahlungskonto eine Zahlung liegt, zeigt erst bb_transactions_get. Höchstens 500 Zeilen je Aufruf, danach mit offset weiterblättern; eine Gesamttrefferzahl nennt die API zu keinem Zeitpunkt. date_from und date_to schließen den genannten Tag ein, id_by_customer_from und id_by_customer_to den genannten Wert dagegen nicht.

Löst in BuchhaltungsButler die Zuordnung zwischen einem Beleg und einer Zahlung. Zu nehmen, wenn ein Beleg der falschen Zahlung zugeordnet wurde. Welche Belege an einer Zahlung hängen, zeigt bb_transactions_list_receipts. Der Beleg selbst bleibt erhalten; als gelöscht markiert wird er mit bb_receipts_delete, und die Zahlung bleibt ohnehin unberührt. Hängt an der Zuordnung eine bestätigte Buchung, lehnt BuchhaltungsButler den Aufruf ab; die Buchung zuerst mit bb_postings_unconfirm_for_transaction entfernen. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Rückgängig zu machen mit bb_transactions_assign_receipt.