Changelog

12.11.2026: Kostenstelle beim Verschieben zu einem anderen KontaktLink zu diesem Abschnitt kopieren

• POST /api/document/bulk/counterparty, POST /api/contact/{id}/merge und counterparty.contactId in PATCH /api/document/{id}: Trägt der Beleg genau die Kostenstelle, die am alten Kontakt für neue Belege hinterlegt ist (defaultCostCenterId), oder hat er keine, bekommt er beim Wechsel die des neuen Kontakts oder keine. Bisher behielt er die alte, und der DATEV-Export trug sie weiter. Jede andere Kostenstelle bleibt, auch eine, die dieselbe Änderung mit costCenterId setzt.
• Löst counterparty mit freien Angaben den Beleg vom Kontakt, entfällt dessen Kostenstelle für neue Belege ebenso.

12.11.2026: Zwölf neue KategorienLink zu diesem Abschnitt kopieren

• Neu in GET /api/category/ und list_categories: material_purchase (Materialeinkauf, SKR03 3000, bei 7 % 3010, bei 19 % 3030; SKR04 5100, 5110, 5130), machine_rental, machine_purchase, rent_ancillary_costs, office_equipment_leasing, customs_duties, sales_commissions, fines_penalties und statutory_accident_insurance für Belege, dazu die direkt gebuchten Vorlagen-Kategorien security_deposit, insurance_compensation und sick_pay_reimbursement.
• Neuer Titel, der Schlüssel bleibt: technical_equipment_leasing heißt „Leasing von Maschinen und Anlagen“.

12.11.2026: Belege zu einem anderen Kontakt verschiebenLink zu diesem Abschnitt kopieren

• Neu: POST /api/document/bulk/counterparty verschiebt bis zu 50 Belege zum Kontakt contactId, wie die Massenaktion „Kontakt ändern“ in der App. Jeder Beleg bekommt Name, Anschrift, USt-IdNr., IBAN und Nummer des Kontakts, und bimetrics bucht ihn auf dessen Personenkonto um. Festgeschriebene Buchungen storniert bimetrics und bucht sie neu, reversedFinalizedMonths nennt die Monate. Ausgestellte Rechnungen, an DATEV exportierte Belege und Belege aus Dauerbuchungen bleiben und stehen mit Grund in skipped. Erst mit dryRun, dann mit expectedVersions, Recht documents:write.
• Neu: POST /api/contact/{id}/merge führt zwei Kontakte zusammen: Die Belege des Kontakts {id} kommen zum Kontakt targetContactId, je Aufruf die ältesten 50, und remaining nennt, was danach noch beim Kontakt bleibt. Mit deleteSource löscht bimetrics den leeren Kontakt danach, wenn nichts mehr auf ihn verweist (sourceDeleted). Über einen API-Schlüssel braucht das zusätzlich das Recht contacts:write.
• Über MCP folgen preview_contact_merge, merge_contacts und die Aktion counterparty in preview_bulk_document_change und apply_bulk_document_change mit der nächsten MCP-Version.

12.11.2026: Kostenstellen an Belegen und BuchungenLink zu diesem Abschnitt kopieren

• Neu: costCenterId an Belegen, Buchungen und Dauerbuchungen nennt die Kostenstelle oder Verteilung. Buchungen tragen sie nur mit Aufwands- oder Erlöskonto, Zahlungen nie. Bei einer Verteilung nennt costCenterParts den Betrag je Kostenstelle, centgenau wie die Zeilen im DATEV-Export. costCenterRelevant sagt, ob eine Buchung eine Kostenstelle tragen kann. accountIsIncomeStatement und accountContraIsIncomeStatement nennen die Seite mit dem Erfolgskonto.
• costCenterId in PATCH /api/document/{id} setzt die Kostenstelle eines Belegs, ein leerer String entfernt sie. Das geht auch bei ausgestellten und bezahlten Belegen, weil sich kein Betrag ändert. In festgeschriebenen Monaten storniert bimetrics die Buchungen und bucht sie neu.
• defaultCostCenterId in POST /api/contact/ und PUT /api/contact/{id}: Neue Belege des Kontakts bekommen diese Kostenstelle, solange sie noch keine haben.
• Kostenstellen und Verteilungen verwaltest du jetzt auch per API, wie in den Einstellungen der App. Dafür gibt es fünf Routen: GET /api/cost-centers, POST /api/cost-centers, PUT /api/cost-centers/{id}, POST /api/cost-centers/{id}/archive und POST /api/cost-centers/{id}/unarchive. Zum Lesen reicht read, alles andere braucht company:write. Nummer und Anteile stehen fest, sobald ein Beleg sie nutzt. Gelöscht wird nie, nur archiviert.
• POST /api/document/bulk/cost-center setzt eine Kostenstelle an bis zu 50 Belegen auf einmal, mit dryRun und expectedVersions wie bei der Kategorie. Festgeschriebene Belege überspringt die Route; änderst du sie einzeln, bucht bimetrics sie neu.
• POST /api/document/filter und POST /api/accounting/booking/filter filtern jetzt auch nach costCenterId. Mit eq und dem Wert null findest du Einträge ohne Kostenstelle.
• Über MCP kommen Kostenstellen mit der nächsten MCP-Version.

11.11.2026: Möglicher DoppelbelegLink zu diesem Abschnitt kopieren

• Neu: possibleDuplicateOfId in GET /api/document/{id} und POST /api/document/filter. Es nennt einen älteren Beleg mit gleichem Inhalt, meist dasselbe Papier als zweiter Scan. Siehe Möglicher Doppelbeleg. Nur ein Hinweis, er sperrt und löscht nichts.

11.11.2026: Beschreibungen zu Nachträgen und FestschreibungLink zu diesem Abschnitt kopieren

• Die Beschreibungen von GET /api/export/datev/addenda, von export und export.addendum einer Buchung und von origin.matchId sagen genauer, was ein Nachtrag ist und welche Zuordnung matchId nennt. Verhalten, Anfrage und Antwort bleiben gleich.
• finalizedBookings und exportedBookings in GET /api/match/{id}/cash-discount-preview und GET /api/match/{id}/reminder-charges-preview sowie exportedBookings in GET /api/match/{id}/euro-amount-preview beschreiben, was in der App geschieht: Skonto, Mahnkosten und Zinsen kommen mit dem Datum der Zahlung als neue Buchungen dazu, festgeschriebene Buchungen bleiben stehen.
• DELETE /api/match/{id} nennt, wann beim Lösen Storno und Neubuchung entstehen: bei einer festgeschriebenen Zahlung immer, bei den Belegen nur bei einer Sammelzahlung mit Rest.

11.11.2026: Lange PDFs vollständig lesen, „Erneut lesen“Link zu diesem Abschnitt kopieren

• bimetrics liest jetzt bis zu 60 Seiten je PDF. Bisher waren es bei einem Scan die ersten 5 Seiten und bei einer PDF-Datei mit Text die ersten 20. Einen Scan ohne Textebene mit mehr als einer Seite liest bimetrics Seite für Seite und überspringt dabei leere Rückseiten. Eine einzelne langsame Seite lässt die Erkennung nicht mehr scheitern, bei vielen Seiten dauert das Lesen aber einige Minuten.
• Neu in uploadDocument: pageCount (Seitenzahl der PDF-Datei) und pagesRead (gelesene Seiten). Ist pagesRead kleiner als pageCount, hat die Datei mehr als 60 Seiten und die Seiten danach fehlen. Beide sind 0 bei Bildern, E-Rechnungen und früher gelesenen Belegen.
• Neu: POST /api/document/{id}/reading/retry startet mit dem Recht upload die Erkennung eines Belegs neu, dessen Lesen fehlgeschlagen ist (ocrStatus failed), wie „Erneut lesen“ in der App. Der Beleg wartet danach sofort wieder (pending). Das erneute Lesen zählt im Tarif als weiterer Beleg ins Kontingent. Neue Fehler: 409 DocumentReadingNotFailed (gelesen, wartet oder wird gelesen, auch beim zweiten Aufruf), 409 DocumentReadingManual (von Hand erfasst), 409 DocumentReadingFinalized (festgeschriebene Buchungen) und 409 DocumentReadingIssued (in bimetrics ausgestellte Rechnung).
• Kann bimetrics den Positionen keine Kategorie zuordnen, endet die Erkennung nicht mehr mit failed: Der Beleg ist gelesen (success), seine Positionen haben keine category, und er wird erst gebucht, wenn jemand sie wählt.
• Über MCP folgen retry_document_reading und der Hinweis auf nur zum Teil gelesene Dateien mit der nächsten MCP-Version.

11.11.2026: Leistung an einem Grundstück, Kleinunternehmer im AuslandLink zu diesem Abschnitt kopieren

• Neu: items[].kind in POST /api/draft/ und PUT /api/draft/{id} nimmt property_service, eine Leistung an einem Grundstück. Ihre Umsatzsteuer richtet sich nach dem Land des Grundstücks: delivery.countryId, ohne Lieferadresse das Land der Kundenanschrift. taxCase.facts.deliveryCountry nennt es.
• Grundstück in Deutschland: standard, auch für Kunden im Ausland. Grundstück in einem anderen EU-Land und Unternehmen mit gültiger USt-IdNr.: neuer Fall eu_property_service (Reverse Charge, Konto 8339 bzw. 4339, keine Zusammenfassende Meldung). Grundstück im Drittland: neuer Fall third_country_property_service (8338 bzw. 4338).
• Kleinunternehmer: Eine Leistung an ein Unternehmen in einem anderen EU-Land mit gültiger USt-IdNr. ist jetzt eu_reverse_charge_service auf 8339 bzw. 4339, eine an ein Unternehmen im Drittland third_country_service. Bisher war jede Position small_business. Ohne gültige USt-IdNr. bleibt es bei § 19 mit einer Warnung.
• Neue Codes in POST /api/draft/{id}/tax-case: tax_case_property_eu_private und tax_case_property_partly_marked sperren. property_reverse_charge_check, property_abroad_registration und small_business_eu_business_without_vat_id warnen, ohne zu sperren.
• Neue Kategorie sales_income_eu_not_taxable (8339 bzw. 4339) in GET /api/category/. taxHintTexts in PATCH /api/company/ nimmt die beiden neuen Fälle an. Hinweistexte kennen den Platzhalter {propertyCountry}, etwa „in Österreich“.
• ruleVersion ist jetzt 3. Ausgestellte Rechnungen behalten ihren Steuerfall.
• Verschärfungen:
  • Ein Grundstück im EU-Ausland sperrt bei einer Privatperson (tax_case_property_eu_private) und bei einem Unternehmen ohne gültige USt-IdNr. (tax_case_buyer_vat_id_required oder tax_case_buyer_vat_id_invalid). acceptStandardVatWithoutVatId hilft hier nicht.
  • Liegen Positionen nur deshalb steuerlich auseinander, weil ein Teil als Grundstück gekennzeichnet ist, sperrt tax_case_property_partly_marked statt tax_case_mixed_reverse_charge oder tax_case_outside_scope_mixed.
  • Hat delivery Straße, PLZ oder Ort, aber kein countryId, sperrt eine Grundstücksposition mit tax_case_delivery_country_invalid. Das Land der Kundenanschrift gilt dann nicht.
  • Ein Satz über 0 % auf einem Grundstück im Ausland sperrt mit tax_case_rate_conflicts_case. Bei anderen Positionen ohne deutsche Umsatzsteuer bleibt es beim Hinweis tax_case_override_standard.
  • Ein Kleinunternehmer mit salesKind both braucht kind je Position, wenn der Fall daran hängt (tax_case_position_kind_required).
  • Eine nicht steuerbare Leistung im Drittland neben § 19 sperrt mit tax_case_outside_scope_mixed.
  • Ein eigener Hinweistext eines Kleinunternehmers für Reverse Charge braucht „Steuerschuldnerschaft des Leistungsempfängers“, sonst sperrt tax_hint_text_invalid.
• MCP setzt property_service noch nicht. get_sales_document liest eine solche Position ohne kind und den Entwurf mit editable: false.

11.11.2026: Skonto automatisch ausgleichenLink zu diesem Abschnitt kopieren

• Bucht ein Lieferant genau den Belegbetrag abzüglich des Skontos ab, das die Zahlungsbedingungen des Eingangsbelegs nennen (genau ein Satz bis 5 %), ordnet bimetrics Beleg und Abbuchung automatisch zu und gleicht die Differenz als erhaltenes Skonto aus. Das gilt auch für Belege aus POST /api/document/. Eine Zuordnung mit autoMatch: true kann damit ein cashDiscount tragen; Anfragen und Antworten bleiben gleich.
• DELETE /api/match/{id} macht es rückgängig: Beleg und Abbuchung sind wieder offen, eine festgeschriebene Skonto-Buchung wird storniert, und bimetrics ordnet die Kombination nicht noch einmal automatisch zu. Sind Buchungen schon an DATEV exportiert, geht das nur in der App.
• Über MCP zeigt get_match solche Zuordnungen schon jetzt mit automatic und cashDiscount, und delete_match hebt sie auf. Die Texte der Werkzeuge folgen mit der nächsten MCP-Version.

11.11.2026: Skonto bei einer SammelzahlungLink zu diesem Abschnitt kopieren

• Bezahlt eine Abbuchung mehrere Eingangsbelege desselben Lieferanten mit einem Umsatzsteuersatz und liegt höchstens 5 % unter ihrer Summe, gleicht POST /api/match/ mit confirmCashDiscount die Differenz als erhaltenes Skonto aus, nachträglich auch POST /api/match/{id}/cash-discount. Das Skonto verteilt sich nach Betrag auf die Belege; cashDiscount.documents nennt den Anteil jedes Belegs, reference.documents ihre Nummern. Im DATEV-Export trägt jede Bank- und Skontozeile die Nummer ihres Belegs.
• Gibt es trotz einer solchen Differenz kein Skonto, nennt POST /api/match/util/amountopen den Grund in cashDiscountRefusal und GET /api/match/{id}/cash-discount-preview in reason: supplier, category, taxRates oder documentAmount.
• Maut, die ein Lieferant mit 19 % Umsatzsteuer berechnet, sperrt erhaltenes Skonto nicht mehr, auch bei einem einzelnen Beleg. Maut ohne Umsatzsteuer bleibt ausgeschlossen.
• Über MCP gleicht create_match mit confirmCashDiscount mehrere Belege schon jetzt aus, Anteile und Gründe kommen mit der nächsten MCP-Version.

09.11.2026: Zuordnung nach der FestschreibungLink zu diesem Abschnitt kopieren

• Ändert sich bei einer festgeschriebenen Buchung nur die Zuordnung, etwa wenn du einer Rechnung eine Zahlung zuordnest, bleibt die Buchung stehen. Storno und Neubuchung gibt es nur noch, wenn sich für DATEV etwas ändert, etwa das Konto eines Umsatzes oder bei einer Sammelzahlung mit Rest. Das gilt für POST /api/match/, DELETE /api/match/{id}, POST /api/match/{id}/extend, POST /api/match/{id}/cash-discount und POST /api/match/{id}/reminder-charges. Anfrage und Antwort bleiben gleich; reversedFinalizedMonths nannte eine reine Zuordnung schon bisher nicht.
• origin.matchId in POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} nennt bei einer geltenden Buchung die aktuelle Zuordnung von Beleg bzw. Umsatz. refMatch bleibt die Zuordnung, aus der die Buchung entstand; beide unterscheiden sich, wenn eine festgeschriebene Buchung beim Zuordnen stehen blieb.
• Über MCP gilt dasselbe, die Texte der Werkzeuge folgen mit der nächsten MCP-Version.

09.11.2026: Späte Belege nach dem DATEV-ExportLink zu diesem Abschnitt kopieren

• GET /api/export/datev/addenda zählt jede Buchung, die DATEV noch nicht hat, wenn ihr Datum im Zeitraum eines zugestellten Exports liegt. Bisher zählte die Route nur bis zum letzten Buchungstag, den der Export im Monat geliefert hatte. Ein Beleg vom 31.10., der erst nach dem Export des Oktobers kam, wurde deshalb nicht mitgezählt. Nach einem Export vom 01. bis 20.10. zählt ein später Beleg vom 18.10., einer vom 25.10. nicht. Exporte ohne gespeicherten Zeitraum (vor dem 04.11.2026) gelten für die ganzen Monate ihrer Buchungen. Anfrage und Antwort bleiben gleich.
• Buchungen aus POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} nennen nach derselben Regel neu export.addendum.
• Für MCP gilt die Änderung ab der nächsten MCP-Version.

09.11.2026: Zahlungsziel und Skonto je KundeLink zu diesem Abschnitt kopieren

• Kontakte kennen paymentTerms mit Zahlungsziel (paymentTermDays) und Skonto (cashDiscount), lesbar mit GET /api/contact/{id}, änderbar mit POST /api/contact/ und PUT /api/contact/{id}. Statt der Vorgaben der Firma nehmen sie neue Rechnungsentwürfe über MCP, aus Angebot oder Auftragsbestätigung umgewandelte Rechnungen und Rechnungsentwürfe über POST /api/draft/ mit Kunde, aber ohne dueDate und cashDiscount, siehe Kontakte.

09.11.2026: Abschlags- und SchlussrechnungenLink zu diesem Abschnitt kopieren

• POST /api/draft/{id}/derive leitet aus einem ausgestellten Angebot oder einer ausgestellten Auftragsbestätigung mit invoiceRole down_payment einen Abschlag ab, mit percent oder amountMinor und optional expectedPerformance, und mit final die Schlussrechnung. Antworten neu mit 409 DownPaymentsExist und 422 DownPaymentTaxCaseUnsupported, siehe Abschlags- und Schlussrechnung.
• PUT /api/draft/{id} nimmt an einem Abschlag downPayment: bimetrics baut dann Positionen und Preisart aus dem Auftrag neu.
• PUT /api/draft/{id}/finalize nimmt bei einer Schlussrechnung acceptCancelOpenDownPayments und expectedSettlementRevision. POST /api/draft/{id}/tax-case nennt dazu settlement mit Abzügen, Stornos, Korrekturen und dem Betrag „Noch zu zahlen“ (dueMinor). Die Schlussrechnung bekommt die nächste freie Nummer, ihre Stornos und Korrekturen die folgenden.
• Neue Lesefelder: billing an GET /api/draft/{id} eines ausgestellten Angebots oder einer ausgestellten Auftragsbestätigung, die abschließende Rechnung darin mit Beträgen und Storno (closing.netMinor, closing.grossMinor, closing.cancelledBy), billingSummary in POST /api/draft/filter, an Entwürfen invoiceRole (auch als Filter), downPaymentOrdinal, deductedBy und settledByFinalDraftId, je Position deduction, an Belegen invoiceRole. Neue Buchungsarten down_payment und down_payment_clearing. Bei einer Schlussrechnung nennt GET /api/draft/{id}/correction-capacity in remainingGrossMinor höchstens den Rest ihres Steuersatzes nach den Abzügen.
• Über MCP mit der nächsten MCP-Version.

09.11.2026: Debitoren- und Kreditorenkonto am KontaktLink zu diesem Abschnitt kopieren

• GET /api/contact/{id}, POST /api/contact/, PUT /api/contact/{id} und je Treffer POST /api/contact/filter nennen datevAccounts: das Debitoren- und das Kreditorenkonto des Kontakts im DATEV-Export, aus der Kundennummer abgeleitet wie die Buchungen und nur lesbar. debitorCollective bzw. creditorCollective sagen, dass die Nummer fehlt oder zu groß für ein eigenes Konto ist und auf das Sammelkonto gebucht wird.
• externalRef heißt in der App „Alte Nummer“, etwa die Kundennummer aus dem früheren Programm. Sie steht nie auf Belegen.
• Über MCP nennt get_contact datevAccounts mit der nächsten MCP-Version.

09.11.2026: Logo immer änderbarLink zu diesem Abschnitt kopieren

• GET /api/company/logos nennt enabled immer true. Die Antwort 404 LogoSetDisabled auf Änderungen am Logo gibt es nicht mehr; Anfrage und Antwort bleiben sonst gleich.

09.11.2026: Angebote annehmen, ablehnen und nach Ergebnis filternLink zu diesem Abschnitt kopieren

• Neu: POST /api/draft/{id}/proposal-outcome hält mit invoices:draft fest, ob der Kunde ein ausgestelltes Angebot angenommen (accepted) oder abgelehnt (rejected) hat, eine Ablehnung mit Grund. open nimmt das Ergebnis zurück. Angebot und PDF bleiben unverändert. Neue Fehler: 409 ProposalNotIssued, 409 ProposalOutcomeUnchanged und 409 ProposalConverted, letzterer, solange zum Angebot eine Auftragsbestätigung oder Rechnung besteht.
• POST /api/draft/{id}/derive setzt ein Angebot automatisch auf angenommen, auch nach einer Ablehnung.
• POST /api/draft/filter filtert mit proposalStates ausgestellte Angebote nach ihrem Ergebnis: open, expired (gültig bis vor heute), accepted oder rejected. Das Feld geht nur mit einem Filter auf kind proposal, sonst kommt 400.
• Jedes ausgestellte Angebot trägt in POST /api/draft/filter und GET /api/draft/{id} neu das Objekt proposal mit outcome, outcomeAt, outcomeReason, outcomeBy (Person, API-Schlüssel oder MCP-Client), outcomeVia (app, api oder mcp) und sentAt (letzter Versand per E-Mail).
• POST /api/draft/list/count zählt mit einem Filter auf kind proposal die Reiter der Angebotsliste: all, draft, open, expired, accepted und rejected, die vier letzten mit Bruttobetrag. Für Rechnungen bleibt die Antwort gleich.

09.11.2026: Notiz am KontaktLink zu diesem Abschnitt kopieren

• contactInfo.notes ist die interne Notiz zum Kontakt. GET /api/contact/{id} liest sie, POST /api/contact/ und PUT /api/contact/{id} schreiben sie wie bisher. Sie steht nie auf Belegen. Über MCP kommt sie mit der nächsten MCP-Version.

09.11.2026: Bank und BIC aus der IBANLink zu diesem Abschnitt kopieren

• POST /api/contact/check nennt bei einer gültigen deutschen oder österreichischen IBAN neu bank mit name und bic, aus den Bankleitzahl-Verzeichnissen der Deutschen Bundesbank und der Oesterreichischen Nationalbank. Das Feld fehlt bei anderen Ländern und bei unbekannter Bankleitzahl.

09.11.2026: Wording „Zahlung eintragen“Link zu diesem Abschnitt kopieren

• POST /api/match/payment/bulk heißt jetzt „Zahlungen für mehrere Belege eintragen“, wie die Aktion in der App. Nur Titel und Beschreibung ändern sich, Anfrage und Antwort bleiben gleich.

08.11.2026: Ort aus PLZLink zu diesem Abschnitt kopieren

• Neu: GET /api/address/postal liefert mit contacts:read für Deutschland und Österreich die Orte einer PLZ oder die PLZ eines Orts, siehe Kontakte prüfen.
• POST /api/contact/, PUT /api/contact/{id} und POST /api/contact/check nennen in hints auch Hinweise zur PLZ der ersten Anschrift: postal_code_format, postal_code_city und postal_code_country. Sie sperren nie, eine unbekannte PLZ ergibt keinen. Die Prüfung vorab nimmt dafür postalCode und city.

08.11.2026: Rechnungen nach Zahlstand filtern und zählenLink zu diesem Abschnitt kopieren

• POST /api/draft/filter filtert ausgestellte Rechnungen nach Zahlstand, wie die Reiter der Rechnungsliste: paymentStates mit open (offen, auch überfällig, wie der Reiter „Offen“), overdue (nur die überfälligen), unknown, paid oder cancelled, dazu partiallyPaid, reminded, reminderLevels, reminderHold, dueFrom/dueTo und lastPaymentFrom/lastPaymentTo. Die Felder gehen nur mit einem Filter auf kind invoice, sonst kommt 400.
• Jede ausgestellte Rechnung trägt in POST /api/draft/filter und GET /api/draft/{id} neu das Objekt payment mit Zahlstand (state: open, unknown, paid oder cancelled), overdue, offenem Betrag, letzter Zahlung, Mahnstufe und Mahnsperre. Es fehlt, solange der Zahlstand noch berechnet wird.
• Neu: POST /api/draft/list/count zählt alle Reiter in einer Abfrage, mit offenem Betrag bei open und overdue und dem Rechnungsbetrag nach Gutschriften bei unknown und paid, mit sales:read.
• Solange bimetrics die Zahlstände einer Firma zum ersten Mal berechnet, antworten der Zähler und die Zahlstand-Filter mit 409 ReceivableStatesPending. Sende die Anfrage dann gleich noch einmal.

08.11.2026: Grund eines abgelehnten StornosLink zu diesem Abschnitt kopieren

• GET /api/receivable/ und GET /api/receivable/{id} nennen neu cancellationBlockReason, wenn ein Storno mit POST /api/draft/{id}/cancel abgelehnt würde: cancelled (schon storniert), corrected (per Gutschrift gemindert), paid (bezahlt) oder matched (eine Zahlung ist zugeordnet). Solange ein Storno möglich ist, fehlt das Feld.
• correctionBlockReason ist jetzt auch cancelled, wenn die Rechnung per Storno-Zuordnung (invoice_cancellation) aufgehoben ist, etwa mit einer hochgeladenen Stornorechnung. Eine Gutschrift lehnte bimetrics in diesem Fall schon bisher ab.

08.11.2026: Kontakte prüfenLink zu diesem Abschnitt kopieren

• Neu: POST /api/contact/check prüft IBAN und USt-IdNr. eines Kontakts mit contacts:read, ohne etwas zu speichern, siehe Kontakte prüfen.
• POST /api/contact/ und PUT /api/contact/{id} nennen in hints Hinweise, die nie sperren, etwa eine USt-IdNr. mit falscher Prüfziffer.
• Verschärfung: PUT /api/contact/{id} lehnt eine neue IBAN ohne die Länge ihres Landes oder mit falscher Prüfziffer mit 400 InvalidIban ab, wie die App. Eine gespeicherte IBAN bleibt, leeren geht immer.

08.11.2026: Standardtexte neuer BelegeLink zu diesem Abschnitt kopieren

• Zeigt das Layout der Belegart den Baustein „Dank“, setzen POST /api/draft/ und MCP bei leerem remark den Standard-Kopftext ohne Dank ein, etwa „Guten Tag, wir berechnen Ihnen die folgenden Leistungen:“. Ebenso beim Umwandeln und Duplizieren. So dankt der Beleg nur einmal.
• Übernimmt ein neuer Entwurf einen Standard-Fußtext, ersetzt bimetrics ihn nur noch, wenn unter „Viele Grüße“ der aktuelle Firmenname oder kein Name steht. Ein anderer Name bleibt stehen, etwa ein von Hand eingetragener oder einer von vor einer Umbenennung.

08.11.2026: Sammelzahlung zählt als bezahltLink zu diesem Abschnitt kopieren

• Bezahlt ein Bankumsatz mehrere Ausgangsrechnungen zusammen und geht genau auf, liefern GET /api/receivable/ und GET /api/receivable/{id} für jede dieser Rechnungen paymentKnown: true, paidMinor gleich dem Rechnungsbetrag, openMinor 0, reminderBlockReason settled sowie lastPaymentOn und lastPaymentTransactionId des Umsatzes. Bisher kam paymentKnown: false mit payment_unknown.
• Genau aufgehen heißt: kein Rest in der Zuordnung, keine Mahnkosten, kein Skonto, keine erfasste Zahlung, Rechnungskorrektur oder Storno an einer der Rechnungen, der Umsatz gebucht, in Euro und in keiner anderen Zuordnung. Sonst bleibt es bei paymentKnown: false.
• Die Prüfliste review=reminders führt solche Rechnungen nicht mehr, POST /api/reminder/bulk überspringt sie mit Grund settled statt payment_unknown, und paidSince nennt sie ab dem Zuordnen. Eine Zahlung erfassen lässt sich bei ihnen weiterhin nicht (409 DocumentWriteLocked).

08.11.2026: Behoben: Mahnen bei unklarer ZahlungLink zu diesem Abschnitt kopieren

• Ist die Zahlung einer Rechnung unklar, antworten POST /api/reminder/, POST /api/reminder/{id}/preview und POST /api/reminder/{id}/issue wie beschrieben mit 409 ReminderNotAllowed und context.reason payment_unknown. Bisher kam 409 DocumentWriteLocked.
• POST /api/reminder/bulk führt eine solche Rechnung unter skipped mit Grund payment_unknown statt unter failed mit DocumentWriteLocked.

08.11.2026: Serien mit Zwischenüberschriften über MCPLink zu diesem Abschnitt kopieren

• get_recurring_invoice meldet eine Serienvorlage mit Zwischenüberschriften, Untertiteln oder optionalen Positionen als nicht bearbeitbar (editable: false) und nennt den Grund. update_recurring_invoice lehnt sie ab. Bisher gingen diese Angaben beim Ändern ohne Meldung verloren. Solche Vorlagen bearbeitest du in der App.

08.11.2026: Abgelehnte USt-IdNr. nicht mehr per API bestätigenLink zu diesem Abschnitt kopieren

• Verschärfung: POST /api/draft/, PUT /api/draft/{id}, POST /api/recurringinvoice/ und PUT /api/recurringinvoice/{id} lehnen acceptUnverifiedVatId: true mit 400 und dem Code VatIdConfirmationNotAllowed ab, wenn der Entwurf oder die Serienvorlage die Bestätigung nicht schon trägt. Wie in der App und über MCP sperrt eine von VIES abgelehnte USt-IdNr. das Ausstellen. Korrigiere die USt-IdNr. am Kontakt. Eine gespeicherte Bestätigung darfst du unverändert zurückschicken, false nimmt sie zurück.

08.11.2026: Befreiungsgründe lesenLink zu diesem Abschnitt kopieren

• Neu: GET /api/tax-case/exempt-reasons liefert die Befreiungsgründe für eine Rechnung, die nach § 4 UStG steuerfrei ist, wie die Auswahl unter „Steuerfall anpassen“ in der App, mit sales:read. shortcut ist der Wert für taxException.reason bei kind exempt_4, dazu kommen der Name und das Erlöskonto in SKR03 und SKR04.

08.11.2026: Steuersätze je PositionLink zu diesem Abschnitt kopieren

• POST /api/draft/{id}/tax-case nennt neu allowedRates und je Position lines[].allowedRates: die Steuersätze, die der Steuerfall erlaubt und das Ausstellen annimmt.
• Mit § 13b oder § 4 in taxException speichern POST /api/draft/ und PUT /api/draft/{id} jede Position mit Satz als 0 % und merken sich ihren Satz. Bisher blieb der Satz stehen, und das Ausstellen lehnte mit 422 tax_case_rate_conflicts_case ab.
• Entfernst du die Ausnahme, bekommt eine Position mit 0 % ihren Satz zurück, solange sie an derselben Stelle mit demselben Namen und derselben Beschreibung steht und der Kunde in Deutschland sitzt. Bei Kunden im Ausland bleibt 0 % (Reverse Charge, Ausfuhr). Für andere Positionen sendest du den Satz mit.
• Das gilt nur für Rechnungen. Angebote, Auftragsbestätigungen und Stornos behalten ihre Sätze wie gesendet.
• Bei priceType gross gilt der Preis unter der Ausnahme ohne Umsatzsteuer. Soll der Kunde netto zahlen, rechnest du ihn selbst um.

08.11.2026: Freundlichere StandardtexteLink zu diesem Abschnitt kopieren

• POST /api/draft/ setzt bei leerem remark oder notes ohne Textvorlage der Firma jetzt den Standardtext der App ein, wie MCP. Bisher blieb der Text dann leer.
• Die Standardtexte beginnen mit „Guten Tag,“ und enden im Fußtext mit „Viele Grüße“ und dem Firmennamen. Einzelunternehmen schreiben „ich“, alle anderen „wir“. Die Auftragsbestätigung hat neu einen Fußtext. Den Wortlaut nennt das Glossar.
• Übernimmt ein neuer Entwurf einen Standardtext von bimetrics, beim Umwandeln, Duplizieren oder über MCP aus dem letzten Entwurf, kommt der heutige mit aktuellem Firmennamen. Eigene Texte und Textvorlagen bleiben.
• POST /api/draft/{id}/cancel legt die Stornorechnung ohne Fußtext an. Der Kopftext nennt die Rechnung wie bisher.
• MCP liest Einleitungs- und Fußtext ohne Absätze. update_sales_draft, amend_invoice_draft und update_recurring_invoice behalten den gespeicherten Text, wenn er fehlt oder so zurückkommt, wie er gelesen wurde. Ein geänderter Text gilt wie gesendet, auch wenn der gespeicherte Absätze hat. Abgelehnt wird er nur noch, wenn die Lesung eine IBAN kürzt oder den Text abschneidet.

08.11.2026: Weitere Dateien beim Versand per E-MailLink zu diesem Abschnitt kopieren

• Neu: POST /api/document-mail/attachments lädt eine Datei für Mails hoch, PDF, JPG oder PNG bis 10 MiB, mit mail:send. Den Typ erkennt bimetrics am Inhalt und passt die Endung an. Die Datei wird kein Beleg.
• POST /api/document-mail/preview und POST /api/document-mail/send nehmen attachments: bis zu 10 weitere Dateien als uploadId, documentId (Beleg) oder draftId (ausgestellte Rechnung, Angebot oder Auftragsbestätigung). Alle Anhänge zusammen dürfen höchstens 10 MiB groß sein, PDF und XML eingerechnet. Zu einer XRechnung gehen keine weiteren Dateien. Einen Beleg (documentId) hängt ein Schlüssel nur mit read an. Die Vorschau nennt die Grenzen in attachmentLimitBytes und maxExtraAttachments.
• Weitere Dateien einer gesendeten Mail haben kind file mit source und sourceId. Jede weitere Datei bleibt als Kopie an der Mail, auch wenn ihre Quelle später gelöscht wird.

08.11.2026: Grund einer gesperrten GutschriftLink zu diesem Abschnitt kopieren

• GET /api/receivable/ und GET /api/receivable/{id} nennen neu correctionBlockReason, wenn canCorrect false ist: cancelled, fully_corrected, no_amount, cash_discount, reminder_charges oder booking_error. Solange eine Gutschrift möglich ist, fehlt das Feld.

08.11.2026: Mahnung vor dem Mahnlauf ansehenLink zu diesem Abschnitt kopieren

• Neu: GET /api/receivable/{id}/reminder-preview zeigt die Mahnung, die der Mahnlauf für eine Rechnung jetzt ausstellen würde, als PDF und Bildseiten, mit sales:read. Die Nummer vergibt erst das Ausstellen. Bekäme die Rechnung keine Mahnung, antwortet die Route mit 409 ReminderNotAllowed und nennt den Grund.

08.11.2026: Rechnungen und Angebote duplizierenLink zu diesem Abschnitt kopieren

• Neu: POST /api/draft/{id}/copy dupliziert eine Rechnung oder ein Angebot als neuen Entwurf mit heutigem Datum, wie „Duplizieren“ in der App, mit invoices:draft. Eine Rechnung behält die Zahlungsfrist des Originals in Tagen, ein Angebot seine Gültigkeit.
• Dieselbe Regel gilt jetzt in der App und für copy_sales_document über MCP. Bisher übernahm die Kopie Datum, Fälligkeit und Leistungszeitraum des Originals.

07.11.2026: MahnlaufLink zu diesem Abschnitt kopieren

• Neu: POST /api/reminder/bulk stellt für bis zu 25 Rechnungen je eine Mahnung der nächsten Stufe aus, wie der Mahnlauf in der App, mit invoices:draft. Mit dryRun zeigt die Route Stufe, Frist, Gebühren, Zinsen und Gesamtbetrag je Rechnung und eine version, ohne etwas auszustellen.
• Zum Ausstellen gibst du die Versionen als expectedVersions zurück. Übersprungen werden Rechnungen mit Mahnsperre, laufender Frist, in den 3 Tagen danach, mit ungeklärter Zahlung und weitere, je mit Grund. Eine inzwischen geänderte Rechnung kommt mit VersionConflict in failed. Ein Idempotency-Key gilt für den ganzen Lauf; eine Wiederholung stellt nichts doppelt aus.

07.11.2026: Wartezeit nach der MahnfristLink zu diesem Abschnitt kopieren

• Nach der Frist einer ausgestellten Mahnung wartet die Prüfliste review=reminders von GET /api/receivable/ noch 3 Tage, weil Zahlungen nachlaufen. Erst dann schlägt sie die Rechnung wieder vor, und erst dann zählt overdue in GET /api/home/tasks sie mit.
• Forderungen nennen diesen Tag unter remindAgainOn. canRemind bleibt unberührt.

07.11.2026: MahnsperreLink zu diesem Abschnitt kopieren

• Neu: PUT /api/receivable/{id}/reminder-hold sperrt eine Rechnung für Mahnungen, mit optionalem Grund und letztem Tag (until). DELETE /api/receivable/{id}/reminder-hold hebt die Sperre auf. Beide mit invoices:draft.
• Kontakte kennen noReminders („Nicht mahnen“), lesbar mit GET /api/contact/{id} und änderbar mit PUT /api/contact/{id}.
• Forderungen nennen eine geltende Sperre unter reminderHold. reminderBlockReason kennt den neuen Wert reminder_hold. review=reminders lässt gesperrte Rechnungen weg, Anlegen und Ausstellen einer Mahnung antworten mit 409 ReminderNotAllowed.

07.11.2026: Mahnungen als ZIP, Mails des TagesLink zu diesem Abschnitt kopieren

• Neu: GET /api/reminder/pdfs liefert die Original-PDFs von bis zu 50 ausgestellten oder zurückgezogenen Mahnungen in einer ZIP-Datei, mit sales:read. Mehr als 50: 400 BulkLimitExceeded.
• POST /api/document-mail/preview nennt unter sender neu sentToday: die Empfänger, an die die Firma heute (UTC) schon gesendet hat. Mit companyDailyLimit siehst du, wie viele heute noch gehen.

07.11.2026: BU-Schlüssel der Zahlungen bei Ist-VersteuerungLink zu diesem Abschnitt kopieren

• Bei Ist-Versteuerung nennen POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} in buKey einer Zahlung auf eine Ausgangsrechnung denselben Schlüssel wie der DATEV-Export: 0101 bei 19 %, 0102 bei 7 % und 0040 ohne deutsche Umsatzsteuer. Bisher fehlte buKey dort. Schon exportierte Zahlungen zeigen den Schlüssel, mit dem sie an DATEV gingen. Teilt der Export die Zahlung auf mehrere Steuersätze oder nennt er keine einzelne Rechnung, fehlt buKey weiter.
• Bei Soll-Versteuerung bleiben die Antworten wie bisher.

07.11.2026: Kontakte nach Ort suchenLink zu diesem Abschnitt kopieren

• POST /api/contact/filter kennt das Attribut addresses.city, die Orte der Anschriften eines Kontakts. Mit in findet es auch einen Teil des Orts. Sortieren lässt sich danach nicht.

07.11.2026: Referenz: Rechnungsentwürfe ohne gelöschte EinträgeLink zu diesem Abschnitt kopieren

• Die Referenz beschreibt POST /api/draft/filter jetzt richtig: Gelöschte Entwürfe liefert die Route nicht, auch nicht mit includeDeleted, und deletedAt ist dort immer null. Das Verhalten der API ändert sich nicht.

07.11.2026: Firmenname bleibt gefülltLink zu diesem Abschnitt kopieren

• PATCH /api/company/ antwortet auf einen leeren name mit 400 CompanyNameRequired, wenn die Firma einen Namen hat. Bisher wurde der leere Name gespeichert. update_company_profile über MCP prüft dasselbe.

06.11.2026: Nachträge in schon exportierten MonatenLink zu diesem Abschnitt kopieren

• GET /api/export/datev/addenda nennt Buchungen, die DATEV noch nicht hat, in Monaten, die ein zugestellter DATEV-Export schon enthält, außerhalb von from bis to: Anzahl und Monate. Ein Export des Zeitraums gibt sie nicht weiter, erst ein Export dieser Monate mit „Nur noch nicht exportierte“. Lesbar mit read.

06.11.2026: Referenz: fehlende Fehlerantworten ergänztLink zu diesem Abschnitt kopieren

• Zehn Endpunkte nennen jetzt auch die Fehlerantworten, die ihre Beschreibung schon nannte, etwa 417 CannotDeleteMatchedDocument bei DELETE /api/document/{id} und 422 ReminderChargesNotEligible bei POST /api/match/{id}/extend. Das Verhalten der API ändert sich nicht.
• Die Liste der Codes unter Fehler ist vollständig für alle Codes, die Referenz und Leitfäden nennen.

06.11.2026: Belege in FremdwährungLink zu diesem Abschnitt kopieren

• Ist ein Beleg in einer anderen Währung als Euro, nennt ihn GET /api/document/{id} mit documentCurrency, dem Betrag vom Beleg in originalTotalAmount und, sobald der Euro-Betrag feststeht, euroAmountSource. Gebucht wird er wie bisher vorerst mit dem Betrag vom Beleg; die App zeigt dann „Euro-Betrag fehlt“.
• Neu: POST /api/match/{id}/euro-amount übernimmt den Euro-Betrag der Zahlungen für den Beleg einer Zuordnung, mit matching:write und den expectedVersions aus GET /api/match/{id}/euro-amount-preview.
• Neu: PATCH /api/document/{id} nimmt euroTotalAmount, den Euro-Betrag in EUR-Cent, und rechnet die Positionen anteilig darauf um. Außerdem documentCurrency und euroAmountsConfirmed.
• Skonto für solche Belege lehnt bimetrics mit 400 CashDiscountForeignCurrency ab.

06.11.2026: Zahlungen bei Ist-Versteuerung prüfenLink zu diesem Abschnitt kopieren

• GET /api/export/datev/cash-basis nennt für eine Firma mit Ist-Versteuerung die Zahlungen eines Zeitraums, bei denen DATEV die Umsatzsteuer keiner Rechnung zuordnen kann: Zahlungseingänge ohne Zuordnung und Zahlungen für mehrere Rechnungen ohne Rechnungsnummer. Bei Soll-Versteuerung ist applies false.
• Die Meldungen.csv des DATEV-Exports nennt dieselben Zahlungen bei Ist-Versteuerung als Hinweis. Bei Soll bleibt sie unverändert.

06.11.2026: Mehrbetrag als Mahnkosten und Zinsen buchenLink zu diesem Abschnitt kopieren

• Zahlt ein Kunde nach einer Mahnung mehr als die Rechnung, bucht POST /api/match/{id}/reminder-charges den Mehrbetrag als Mahnkosten und Verzugszinsen der zuletzt ausgestellten Mahnung, ohne die Zuordnung aufzuheben, mit matching:write und den expectedVersions aus GET /api/match/{id}/reminder-charges-preview. Erst die Kosten, dann die Zinsen, je eine Buchung ohne Umsatzsteuer.
• POST /api/match/ nimmt confirmReminderCharges, POST /api/match/util/amountopen nennt dazu reminderCharges. Die Zuordnung trägt danach reminderCharges, Buchungen die Art reminder_charges.
• Neuer Fehler 422 ReminderChargesNotEligible.

06.11.2026: Mahngebühr, Verzugszinsen und PauschaleLink zu diesem Abschnitt kopieren

• Mahnungen fordern neben dem offenen Betrag eine Mahngebühr, Verzugszinsen und die Pauschale von 40 € nach § 288 BGB, wenn die Firma sie eingeschaltet hat; standardmäßig ist alles aus. Gefordert wird erst ab Verzug, also nach der Frist der ersten ausgestellten Mahnung der Rechnung. Die Pauschale gibt es nur gegenüber Unternehmen und einmal je Rechnung, sie schließt die Mahngebühren ein. Nichts davon wird gebucht.
• Mahnungen haben neu chargeFee, chargeInterest und chargeFlatRate: false lässt den Vorschlag auf dieser Mahnung weg, ein PUT ohne die Felder behält die Wahl. charges nennt Zustand und Betrag je Posten, totalChargesMinor und totalMinor; beim Entwurf aus GET /api/reminder/{id}, POST /api/reminder/, PUT /api/reminder/{id} und der Vorschau aktuell gerechnet, beim Ausstellen eingefroren. In der Liste fehlt es bei Entwürfen.
• GET /api/reminder/settings liefert je Stufe feeEnabled und feeMinor (Vorschlag 250 je Mahnung, 0 bis 5000), dazu interestEnabled, flatRateEnabled und den heutigen baseRatePercent. PUT /api/reminder/settings/{level} nimmt feeEnabled und feeMinor, ohne sie bleibt die Gebühr. Neu schaltet PUT /api/reminder/settings/charges Zinsen und Pauschale, nur für den Inhaber.
• Neuer Platzhalter {Gesamtbetrag}: offener Betrag plus Gebühren und Zinsen. Die Standardtexte der Mahnungen nennen ihn.
• Neuer Fehler 422 ReminderBaseRateMissing, wenn für einen Zinstag der Basiszinssatz fehlt.
• MCP: create_payment_reminder und update_payment_reminder nehmen ab Version 2026-10-11 chargeFee, chargeInterest und chargeFlatRate, die Mahnungswerkzeuge lesen charges. Rechte bleiben gleich.

06.11.2026: Zahlung nach dem DATEV-Export erfassenLink zu diesem Abschnitt kopieren

• POST /api/match/payment nimmt eine Zahlung jetzt auch an, wenn Buchungen des Belegs schon an DATEV exportiert sind. Bisher kam dann 409 FinalizedBookingsLocked. Die exportierten Buchungen bleiben unverändert, es gibt kein Storno. Die Zahlung ist eine neue Buchung zum Zahltag und geht mit dem nächsten DATEV-Export ihres Monats an die Kanzlei.
• Über MCP gilt dasselbe für record_document_payment. get_document_payment liefert exported weiter, eine Zahlung geht trotzdem.
• POST /api/match/payment/bulk bleibt, wie es ist: Es bucht zum Belegdatum und überspringt an DATEV exportierte Belege weiter (exported).

06.11.2026: VersteuerungsartLink zu diesem Abschnitt kopieren

• GET /api/company/ liefert vatCashBasis: true, wenn die Firma nach vereinnahmten Entgelten versteuert (Ist-Versteuerung). Bei der Soll-Versteuerung, dem Standard, fehlt das Feld, die Antwort bleibt wie bisher.
• Ändern lässt sich die Versteuerungsart nur in der App, wie die Versteuerung. PATCH /api/company/ antwortet auf accounting.vatCashBasis mit 400 CompanyFieldNotChangeable.
• DATEV-Export bei Ist-Versteuerung: Jede Zahlung auf eine Ausgangsrechnung oder Rechnungskorrektur trägt im Buchungsstapel den Steuerschlüssel des Steuersatzes der Rechnung, 0101 bei 19 %, 0102 bei 7 % und 40 ohne deutsche Umsatzsteuer. Hat die Rechnung mehrere Sätze, teilt der Export die Zahlung in eine Zeile je Satz. Rechnungen, Skonto und Eingangsbelege bleiben unverändert. buKey der Zahlungsbuchung bleibt leer, den Schlüssel setzt nur der Export. Die Kanzlei stellt den Mandanten in DATEV auf Istversteuerung. Bei Soll-Versteuerung bleibt der Export wie bisher.

06.11.2026: Belegtyp prüfenLink zu diesem Abschnitt kopieren

• Bei einem Upload mit auto[] entscheidet die Erkennung die Belegart mit den Daten deiner Firma. Kann sie nicht sicher entscheiden, trägt der Beleg kindReview: true und wird nicht gebucht, nicht exportiert und nicht zugeordnet, bis jemand die Belegart wählt. Zuordnen und Zahlung erfassen antworten dann mit 409 DocumentKindUnconfirmed. Siehe Belegart ohne Wahl.
• Neuer Filter kindReview an POST /api/document/filter.
• kind in PATCH /api/document/{id} beendet „Belegtyp prüfen“, auch mit demselben Wert.
• Neu: POST /api/document/bulk/kind setzt die Belegart für bis zu 50 Belege, mit documents:write, dryRun und expectedVersions wie die Kategorie.

05.11.2026: Skonto nachträglich ausgleichenLink zu diesem Abschnitt kopieren

• POST /api/match/{id}/cash-discount gleicht den offenen Betrag einer Zuordnung als Skonto aus, ohne sie vorher aufzuheben, mit matching:write und den expectedVersions aus GET /api/match/{id}/cash-discount-preview. Die Vorschau nennt, was der Nutzer vergleicht, und antwortet mit eligible: false, wenn die Zuordnung nicht passt.
• POST /api/match/util/amountopen liefert zu cashDiscount neu cashDiscountReference: Belegnummer, Verwendungszweck und abweichende Nummern im Verwendungszweck.

05.11.2026: Feste Texte je BelegartLink zu diesem Abschnitt kopieren

Eine Firma hinterlegt längere feste Texte für neue Rechnungen, Angebote und Auftragsbestätigungen, etwa eine Widerrufsbelehrung.

• Hinterlegen: PATCH /api/company/ nimmt documentTexts, GET /api/company/ liefert sie. Je Text und für invoiceDefaults.closingText gelten höchstens 6000 Zeichen.
• Neue Entwürfe: POST /api/draft/ setzt den festen Text ein, wo die Anfrage remark oder notes leer lässt. Das gilt auch für einen vorhandenen closingText.
• Neuer Fehler: 400 CompanyTextCharacters bei einem Zeichen, das das PDF nicht drucken kann.

Neue Entwürfe über MCP übernehmen sie, wenn der Aufruf keinen Text nennt. Offene Entwürfe und ausgestellte Belege behalten ihren Text.

05.11.2026: Optionale Positionen und TitelLink zu diesem Abschnitt kopieren

• Positionen in items haben neu option (optional, demand oder alternative, nur im Angebot), title und subtitle. Optionale Positionen stehen mit dem Betrag in Klammern im PDF und zählen in keine Summe und keine XML. Titel gliedern das PDF in Abschnitte mit Zwischensumme, die XML bleibt flach (siehe Ausgangsrechnungen).
• POST /api/draft/{id}/derive nimmt selectedLines: die beauftragten optionalen Positionen als Index in items der Quelle. Ohne Angabe kommen nur die festen Positionen mit.

05.11.2026: MahnstufenLink zu diesem Abschnitt kopieren

• Mahnungen haben neu level: 0 ist die Zahlungserinnerung, 1 bis 3 sind Mahnungen. Der Titel auf dem PDF folgt der Stufe, zum Beispiel „2. Mahnung“. kind geht weiter und passt immer zu level.
• Forderungen nennen in nextReminderLevel die vorgeschlagene nächste Stufe, activeReminder nennt level. Zurückgezogene Mahnungen zählen nicht.
• GET /api/reminder/settings und PUT /api/reminder/settings/{level} lesen und ändern Frist und Text je Stufe. Der Text darf Platzhalter wie {Frist} nutzen, das PDF füllt sie aus.
• POST /api/reminder/settings/{level}/preview zeigt Frist und Text einer Stufe als PDF mit Beispieldaten, auch ungespeichert.
• POST /api/reminder/ nimmt ohne level, paymentDeadline und text die nächste Stufe mit deren Frist und Text.
• GET /api/reminder/ filtert auch nach sourceDraftIds.
• MCP: create_payment_reminder und update_payment_reminder nehmen ab Version 2026-10-11 level, search_receivables, get_receivable und die Werkzeuge für Mahnungen lesen die Stufe.

05.11.2026: MCP-Version 2026-11-05Link zu diesem Abschnitt kopieren

Neue Verbindungen bekommen die MCP-Version 2026-11-05. Bestehende behalten ihren Umfang, bis sie neu verbinden.

• Postfach: search_inbox_mails und get_inbox_mail lesen das Belegpostfach, auch ohne Schreibzugriff, preview_inbox_attachment zeigt einen Anhang, import_inbox_attachment übernimmt ihn, archive_inbox_mail legt die Mail ab. Der Text einer Mail kommt gekürzt und als reiner Text, Links nur als Host, IBANs gekürzt. get_company_context nennt die Adresse des Postfachs. Mail löschen bleibt in der App.
• Belege löschen: preview_document_deletion zeigt, was passiert, delete_document löscht genau das nach dem Ja des Nutzers, höchstens 20 je Firma am Tag. search_document_duplicates und delete_document_duplicates lesen und entfernen Duplikat-Einträge.
• Kontoauszug einlesen: prepare_statement_upload, inspect_bank_statement, preview_bank_statement und apply_bank_statement lesen eine Datei der Bank ein, für den Inhaber und immer mit Vorschau. get_statement_imports und retry_statement_import wie in der App. search_transactions und get_transaction nennen source.
• Vorlagen und Dauerbuchungen: save_document_template und delete_document_template für eigene Vorlagen, list_recurring_bookings, preview_recurring_booking und apply_recurring_booking für Dauerbuchungen. list_document_templates nennt auch Zeilen, system und updatedAt.
• Sammelaktionen: preview_bulk_document_change zeigt für bis zu 50 Belege, was „Kategorie setzen“ oder „Als bezahlt markieren“ ändert und was bleibt, apply_bulk_document_change führt genau das nach dem Ja des Nutzers aus.
• Zuordnungen: get_match_suggestions nimmt documentIds und transactionIds für bis zu 20 Belege und Umsätze in einem Aufruf. Neu ist restore_match_suggestion. create_match nimmt suggestionId; ohne sie lernt bimetrics aus der Zuordnung eine Regel wie in der App, mit ihr nicht.

05.11.2026: Registernummer für § 13b ohne USt-IdNr.Link zu diesem Abschnitt kopieren

• Kontakte haben neu paymentInfo.registrationNumber, Entwürfe buyer.registrationNumber: Handelsregister-, Handwerksrollen- oder Wirtschafts-Identifikationsnummer, höchstens 100 Zeichen und eine Zeile. Ohne Angabe im Entwurf gilt die des verknüpften Kontakts; über die API gilt mit buyer.contactId immer die des Kontakts.
• Eine Bauleistung nach § 13b im Inland geht jetzt auch ohne USt-IdNr., wenn der Kunde eine Registernummer hat. In der E-Rechnung steht sie als BT-47. Fehlt beides, meldet POST /api/draft/{id}/tax-case den neuen Code tax_case_buyer_vat_id_or_registration_required als blockierend, und PUT /api/draft/{id}/finalize antwortet mit 422 TaxCaseInvalid. Der bisherige Code tax_case_buyer_vat_id_required bleibt für die anderen Steuerfälle, dort genügt die Registernummer nicht.
• MCP: update_contact pflegt ab Version 2026-10-05 auch registrationNumber, get_contact, search_contacts und die Antworten von update_contact und create_contacts liefern sie. Rechte bleiben gleich.

05.11.2026: Kontoauszug auch als CAMT und MT940Link zu diesem Abschnitt kopieren

• „Kontoauszug einlesen“ liest neben CSV jetzt camt.052 und camt.053 (Versionen .02 bis .08, als XML oder ZIP) und MT940, siehe Dateien für den Kontoauszug. Eine Zuordnung von Spalten braucht nur CSV, bei den anderen Dateien zählt mapping auch beim Übernehmen per API nicht.
• Neue Fehlercodes: BankStatementCamt054 für camt.054 und BankStatementZipRefused für ein ZIP über den Grenzen. BankStatementCamtNotYet entfällt.

05.11.2026: Kontoauszüge per API einlesenLink zu diesem Abschnitt kopieren

• POST /api/bankstatement/upload nimmt eine Datei der Bank an, POST /api/bankstatement/inspect schlägt Spalten und Konto vor, POST /api/bankstatement/preview vergleicht mit den vorhandenen Umsätzen, POST /api/bankstatement/apply übernimmt genau das. Dafür gibt es die neue Berechtigung statements:import (in der App „Kontoauszüge einlesen“). Bestehende Schlüssel erhalten sie nicht.
• Ohne Vorschau geht nichts: Übernehmen verlangt eine Vorschau mit demselben Konto und derselben Zuordnung aus den letzten 60 Minuten, sonst 409 BankStatementPreviewRequired.
• Umsätze nennen jetzt source: bank aus der Bankverbindung, statement aus einem eingelesenen Kontoauszug, dazu bankImportId. Bankkonten nennen connected.

05.11.2026: Belegpostfach per APILink zu diesem Abschnitt kopieren

• Neu: Mails im Belegpostfach lesen, mit der neuen Berechtigung inbox:read (in der App „Postfach lesen“). Sie ist nicht in read enthalten, und bestehende Schlüssel erhalten sie nicht. GET /api/email/inbox/ liefert die Adresse und legt keine an, POST /api/email/inbox/item/ sucht Mails ohne Text, GET /api/email/inbox/item/{id} liest eine Mail, GET /api/email/inbox/item/{id}/attachment/{aid}/preview zeigt eine Seite eines Anhangs.
• Neu: Mit inbox:write („Postfach bearbeiten“) übernimmt POST /api/email/inbox/item/{id}/attachment/{aid}/import einen Anhang als Beleg, POST /api/email/inbox/item/{id}/archive und POST /api/email/inbox/item/{id}/unarchive legen eine Mail ab oder holen sie zurück. Warten viele Belege auf die Erkennung, kommt 429 DocumentQueueFull. Mails löschen geht nur in der App.

05.11.2026: Belege per API löschenLink zu diesem Abschnitt kopieren

• DELETE /api/document/{id} löscht einen Beleg wie „Löschen“ in der App, mit der neuen Berechtigung documents:delete (in der App „Belege löschen“). Bestehende Schlüssel erhalten das Recht nicht. GET /api/document/{id}/delete-preview sagt vorher mit read, was passiert. Weicht etwas von der Vorschau ab, wird nichts gelöscht (409). Belege mit an DATEV exportierten Buchungen löscht die API nicht, das geht nur in der App.
• GET /api/document/duplicates liest Duplikat-Einträge, POST /api/document/duplicates/delete entfernt sie. Beleg, Datei und Buchungen bleiben stehen.
• Berichtigt: Ein beim Löschen stornierter Beleg behält seine invoicePositions; die Doku sagte, sie seien null.

05.11.2026: Zuordnungsvorschläge per APILink zu diesem Abschnitt kopieren

• POST /api/match/suggestions liest mit read die Vorschläge der App für bis zu 20 Belege und Umsätze auf einmal, mit denselben Treffern in derselben Reihenfolge wie einzeln. Die Route hat ein eigenes Budget, siehe Limits.
• POST /api/match/dismiss blendet mit matching:write einen Vorschlag aus, wie „Vorschlag ausblenden“ in der App. DELETE /api/match/dismiss/{id} holt ihn zurück, auch eine Kombination, die ausgeblendet ist, weil ihre Zuordnung aufgehoben wurde.
• Zuordnungen über die API lernen weiter keine Regel.

05.11.2026: Sammelaktionen per APILink zu diesem Abschnitt kopieren

• Neu: POST /api/document/bulk/category setzt eine Kategorie für bis zu 50 Belege, POST /api/match/payment/bulk markiert bis zu 50 Eingangsbelege als bar oder privat bezahlt, wie die Mehrfachauswahl der App. Mit dryRun siehst du vorher, was sich ändert und was mit welchem Grund bleibt, und bekommst die version je Beleg, die das Ausführen als expectedVersions verlangt. Jeder Beleg zählt einzeln auf die Tagesgrenze. Siehe Mehrere Belege auf einmal.

05.11.2026: Vorlagen und Dauerbuchungen per APILink zu diesem Abschnitt kopieren

• Neue Berechtigung collections:write (in der App „Vorlagen und Dauerbuchungen ändern“), bestehende Schlüssel erhalten sie nicht. Eigene Buchungsvorlagen legst du mit POST /api/document/collection/series/ an, änderst sie mit PUT /api/document/collection/series/{id} und löschst sie mit DELETE /api/document/collection/series/{id}. Standardvorlagen von bimetrics lassen sich lesen und zuordnen, aber nur in der App ändern oder löschen.
• Dauerbuchungen gehen genauso: POST /api/document/collection/contract/, PUT /api/document/collection/contract/{id}, DELETE /api/document/collection/contract/{id}. POST /api/document/collection/contract/preview zeigt vorher, welche Belege entstehen, sich ändern oder entfallen.
• Lesen mit read: POST /api/document/collection/contract/filter, GET /api/document/collection/contract/{id}, GET /api/document/collection/contract/{id}/delete-preview, GET /api/document/collection/contract/{id}/document/, GET /api/document/collection/series/{id} und GET /api/document/collection/series/{id}/document/.
• Ändern und Löschen brauchen Idempotency-Key und expectedUpdatedAt. Die Regeln des App-Formulars gelten jetzt im Server für alle Wege.

04.11.2026: MCP-Version 2026-11-04Link zu diesem Abschnitt kopieren

Neue Verbindungen bekommen die MCP-Version 2026-11-04. Bestehende behalten ihren Umfang, bis sie neu verbinden. Mit Schreibzugriff:

• Stornieren und Entwürfe löschen: prepare_invoice_cancellation legt den Storno-Entwurf an, preview_sales_document zeigt ihn, finalize_sales_draft schreibt ihn fest. delete_sales_draft löscht offene Entwürfe von Rechnungen, Stornorechnungen, Angeboten und Auftragsbestätigungen.
• Per E-Mail senden: preview_document_mail zeigt die Mail zu einem ausgestellten Dokument, send_document_mail sendet genau diese nach dem Ja des Nutzers. Die Tagesgrenze gilt für App, API und MCP zusammen.
• Zuordnung erweitern: extend_match nimmt weitere Belege oder Umsätze auf, etwa die zweite Teilzahlung, wie POST /api/match/{id}/extend. get_match liefert dafür versions.
• Firmendaten: update_company_profile ändert sie wie PATCH /api/company/. get_company_context liefert dafür settings und version.
• Rechnungslayouts: create_invoice_layout, update_invoice_layout, assign_invoice_layout und archive_invoice_layout arbeiten wie der Layout-Editor, jede Änderung als Version, rückgängig mit restore. baseVersionId ist Pflicht, ein Hinweistext braucht confirmed. Die Vorschau preview_invoice_layout gibt es nur mit Schreibzugriff.
• Logo: prepare_logo_upload lädt ein Rechnungslogo oder App-Zeichen über einen Upload-Link hoch, fix_company_logo macht einen Vorschlag („Mach es passend“), apply_company_logo_fix übernimmt oder verwirft ihn oder holt das Original zurück, remove_company_logo löscht. Hochladen und Löschen nur mit confirmed und dem gelesenen expectedLogoId.

Neu zum Lesen: get_open_tasks („Zu erledigen“ und Monatsstand der Startseite), list_invoice_layouts, get_invoice_layout und get_company_logos. search_sales_documents filtert nach Art, Stand, Kunde und Rechnungsdatum, download_sales_document liefert mit format: "xml" die E-Rechnung, search_bookings und get_booking zeigen Art, Stand, DATEV-Export und Herkunft.

04.11.2026: Änderungsprotokoll nennt Schlüssel und VerbindungLink zu diesem Abschnitt kopieren

• Das Änderungsprotokoll im DATEV-Export (Aenderungsprotokoll.csv) hat am Ende die neue Spalte via. Bei Änderungen und Uploads per API steht dort der API-Schlüssel mit Name und ID, bei Änderungen über MCP die Anwendung mit Name und Client-ID. Auch frühere Änderungen bekommen den Eintrag, soweit Schlüssel oder Verbindung noch bekannt sind. Die übrigen Spalten bleiben unverändert.

04.11.2026: Hinweis auf ein Datum vor der letzten RechnungLink zu diesem Abschnitt kopieren

• Liegt das Rechnungsdatum vor deiner letzten Rechnung, meldet POST /api/draft/{id}/tax-case das jetzt als IssueDateBeforeLastInvoice, ohne zu blockieren, und PUT /api/draft/{id}/finalize nennt es im neuen Feld warnings. Das ist erlaubt, fällt aber bei einer Betriebsprüfung auf; die App zeigt denselben Hinweis vor dem Ausstellen. Bei einer Wiederholung mit demselben Idempotency-Key fehlt das Feld.
• Über MCP nennen check_sales_draft, preview_sales_document und finalize_sales_draft den Hinweis ebenso, in allen Versionen. Die Werkzeugtexte und Rechte bleiben gleich.

04.11.2026: Logo per APILink zu diesem Abschnitt kopieren

• Neu: Die API liest und ändert das Logo der Firma wie unter Einstellungen in der App. Lesen geht mit read: GET /api/company/logos. Mit layout:write lädst du das Rechnungslogo und ein eigenes App-Zeichen hoch, nutzt „Mach es passend“, übernimmst oder verwirfst den Vorschlag, holst das Original zurück und löschst ein Logo. Mit expectedLogoId ersetzt oder löscht die API nur das Logo, das du gelesen hast. Siehe Logo.

04.11.2026: Firmendaten ändernLink zu diesem Abschnitt kopieren

• PATCH /api/company/ ändert die Firmendaten wie die Einstellungen der App, mit der neuen Berechtigung company:write (in der App „Firmendaten ändern“): Name, Rechtsform, Anschrift, Kontaktangaben, Geschäftsführung, Steuer- und Registerangaben, Nummernkreise, Skonto-Vorgabe, Zahlungsziel, DATEV-Nummern, Art der Umsätze und Rechnungsabgrenzung. Siehe Firmendaten ändern. Bestehende Schlüssel erhalten das Recht nicht.
• GET /api/company/ liefert dafür zusätzlich settings und version. Haben sich die Firmendaten seit dem Lesen geändert, antwortet PATCH mit 409 CompanyVersionConflict. Kontenrahmen, Versteuerung und Bankverbindung bleiben in der App (400 CompanyFieldNotChangeable). Firmentexte, die auf Rechnungen stehen, nehmen keine Bankdaten auf (400 CompanyTextBankDetails).

04.11.2026: Per E-Mail sendenLink zu diesem Abschnitt kopieren

• POST /api/document-mail/send verschickt ausgestellte Rechnungen, Stornorechnungen, Rechnungskorrekturen, Angebote, Auftragsbestätigungen und Mahnungen wie „Per E-Mail senden“ in der App, mit der neuen Berechtigung mail:send (in der App „E-Mails senden“). Den Vorschlag der App mit Empfänger, Betreff und Text liefert POST /api/document-mail/preview mit sales:read. Siehe Per E-Mail senden.
• Je Firma gehen höchstens 20 Empfänger am Tag raus, in der Testphase 3, für App und API zusammen (siehe Limits). Bestehende Schlüssel erhalten das Recht nicht.

04.11.2026: Rechnungslayouts per APILink zu diesem Abschnitt kopieren

• Neu: Die API liest und ändert Rechnungslayouts wie der Layout-Editor der App, mit denselben Prüfungen. Lesen geht mit sales:read: GET /api/layouts, die erlaubten Werte mit GET /api/layouts/catalog, Versionen, Vorschau und Miniaturen. Ändern geht mit dem neuen Recht layout:write („Layouts und Logo ändern“), das du beim Anlegen eines Schlüssels auswählst: PATCH /api/layouts/{id}, anlegen, kopieren, je Belegart zuweisen, archivieren und frühere Versionen wiederherstellen. Siehe Layouts.

04.11.2026: Hinweistext ohne LinksLink zu diesem Abschnitt kopieren

• Im Hinweis-Baustein des Rechnungslayouts lehnt bimetrics jetzt auch Links und Mailadressen ab, wie bisher Bankdaten und Zahlungsstand: 400 LayoutInvalidChange mit layout_note_link in context.code. Gespeicherte Hinweise bleiben und blockieren keine anderen Änderungen.

04.11.2026: Stornierte Monate festgeschriebener BuchungenLink zu diesem Abschnitt kopieren

• Storniert eine Änderung festgeschriebene Buchungen, nennt die Antwort jetzt die Monate in reversedFinalizedMonths (YYYY-MM): bei PATCH /api/document/{id}, beim Zuordnen, Aufheben und Erweitern einer Zuordnung. bimetrics storniert wie bisher im ursprünglichen Monat und bucht mit den geänderten Werten neu, auch bei nachts festgeschriebenen Buchungen. Genannt werden Monate, in denen sich Datum, Leistungszeitraum, Konto, Steuerkennzeichen oder Betrag ändern, nicht reine Änderungen von Buchungstext oder Zuordnung. Hast du die Umsatzsteuer-Voranmeldung für einen dieser Monate oder, bei geändertem Datum, für den neuen Monat schon abgegeben, musst du sie womöglich berichtigen. Bei einer Wiederholung mit demselben Idempotency-Key fehlt das Feld. An DATEV exportierte Buchungen bleiben für API-Schlüssel gesperrt.
• Über MCP nennen update_document, create_match und delete_match die Monate ebenso, in allen Versionen ab 2026-10-05; der nächste Schritt im Ergebnis weist auf die Umsatzsteuer-Voranmeldung hin. Ab Version 2026-10-16 warnt preview_document_change vorher (finalizedBookingsReversed), und get_document meldet mit finalized auch die nächtliche Festschreibung; ob Buchungen an DATEV exportiert sind, sagt das neue Feld exported. Es gibt keine neuen Rechte.

04.11.2026: Fälligkeit in den MCP-WerkzeugtextenLink zu diesem Abschnitt kopieren

• Über MCP nennen copy_sales_document und create_sales_draft die Fälligkeit jetzt richtig, in allen Versionen: Eine aus einem Angebot umgewandelte Rechnung ist nach dem Zahlungsziel der Firma fällig, ohne Zahlungsziel nach 14 Tagen. Ein neuer Rechnungsentwurf ist nach dem Zahlungsziel fällig, ohne Zahlungsziel hat er keine Fälligkeit. Geändert hat sich nur der Text, bimetrics rechnet wie bisher.

02.11.2026: Offene Entwürfe per API löschenLink zu diesem Abschnitt kopieren

• DELETE /api/draft/{id} löscht mit invoices:draft einen offenen Entwurf einer Rechnung, Stornorechnung, eines Angebots oder einer Auftragsbestätigung, wie „Löschen“ in der App. Im Anfrageinhalt steht das gelesene expectedUpdatedAt. Ausgestellte Belege bleiben geschützt (409 DraftFinalized), Entwürfe von Rechnungskorrekturen löscht nur die App (403). Bisher war die Route für API-Schlüssel gesperrt.

02.11.2026: „Zu erledigen“ lesenLink zu diesem Abschnitt kopieren

• Neu zum Lesen, mit read: GET /api/home/tasks liefert dieselben Aufgaben wie die Startseite der App unter „Zu erledigen“: Belege prüfen, Zahlungen ohne Beleg, überfällige Rechnungen, nicht zugestellte Mails, ablaufende Bankfreigaben und Mails im Postfach, je Art mit Anzahl, dazu den Monatsstand der Belege und Zahlungen. Die Zahlen sind dieselben wie in den Listen der App.

01.11.2026: Die API liest, was MCP liestLink zu diesem Abschnitt kopieren

• Neu zum Lesen, mit read: GET /api/company/ (Firma mit Kontenrahmen, Versteuerung und Nummernkreisen), GET /api/category/ (Kategorien), POST /api/document/collection/series/filter (Buchungsvorlagen für documentSeriesIds) und GET /api/bankaccount/connections (Stand der Bankzugänge). Es sind dieselben Angaben wie über MCP in get_company_context, list_categories, list_document_templates und list_bank_accounts.
• GET /api/match/payment/private sagt, wie die Firma privat bezahlte Belege bucht und was sie dem Gesellschafter noch schuldet. Wie die Erfassung nur mit eingeschalteter Zahlungserfassung, sonst 403 ManualPaymentUnavailable.
• POST /api/match/{id}/extend erweitert eine Zuordnung um weitere Belege oder Umsätze, etwa eine zweite Teilzahlung, mit matching:write und den expectedVersions aus delete-preview.
• POST /api/draft/ legt mit invoiceKind: "SalesProposal" und ohne typeCode Angebote an, wie über MCP. PUT /api/draft/{id}/finalize stellt sie aus, die Antwort nennt das Angebot in salesProposal.
• PUT /api/contact/{id} ändert Kontakte nach den Regeln des Kontaktformulars, wie über MCP: Bankverbindung, customerKind, USt-IdNr., Land, Name und Anschrift auch bei verwendeten Kontakten. Die Kundennummer nur, solange der Kontakt in keinem Beleg steht (409 CustomerNumberInUse). Bisher kam dafür 400 InvalidContactWrite oder 409 ContactChangeRequiresApp.

01.11.2026: Vorlagen und Rücknahmen wie in der AppLink zu diesem Abschnitt kopieren

• POST /api/match/ lehnt eine Vorlage aus documentSeriesIds, die die Firma in ihren Listen nicht sieht, mit 409 DocumentTemplateUnavailable ab. Das betrifft „Gesellschafter-Verrechnung“, solange die Zahlungserfassung aus ist, und mit ihr „Privatentnahme“ und „Privateinlage“ bei GmbH und UG. Zugeordnet und gebucht wird dann nichts. Über MCP gilt das für create_match.
• POST /api/match/payment/reverse braucht reversedOn nicht mehr. Ohne Datum bucht bimetrics die Gegenbuchung auf den Zahltag, solange dessen Buchung offen ist, sonst auf heute nach deutscher Zeit, wie es auch die App vorschlägt. Über MCP gilt das für reverse_document_payment.

01.11.2026: KI-Assistenten und API in der TestphaseLink zu diesem Abschnitt kopieren

• API-Schlüssel und MCP-Verbindungen stehen auch in der kostenlosen Testphase bereit, mit Tagesgrenzen für Abfragen, Änderungen und Festschreibversuche. Für Tarife ändert sich kein Wert.
• Neue Verbindungen nennen die Version 2026-11-01. Sie hat dieselben Werkzeuge wie 2026-10-23, mit eingeschalteter Zahlungserfassung dazu die drei Werkzeuge für Zahlungen (siehe unten); get_company_context nennt in der Testphase zusätzlich trial, prepare_document_upload die 100 Belege. Bestehende Verbindungen behalten ihren Umfang.
• Ein Upload über die 100 Belege der Testphase antwortet mit 402 LimitReached, nennt den Grund in detail und speichert nichts (siehe Beleg-Upload).
• Ein API-Schlüssel richtet in der Testphase keine ausstellende Serie ein: generationMode: "issue" antwortet mit 403 APIKeyPermissionDenied.
• Nach dem Ende der Testphase antworten Schlüssel mit 403 APIUnavailable, Werkzeugaufrufe mit einem Hinweis. In der App bleiben Schlüssel und Verbindungen sichtbar und lassen sich widerrufen.

01.11.2026: Privat bezahltLink zu diesem Abschnitt kopieren

Alles hier gilt nur mit eingeschalteter Zahlungserfassung (manualPaymentsEnabled). Sie ist noch aus.

• POST /api/match/payment nimmt method: "private" an: Ein Gesellschafter oder der Inhaber hat einen Eingangsbeleg privat bezahlt. Optional nennt paidBy, wer bezahlt hat; der Name steht im Buchungstext. Das Konto wählt der Server nach Rechtsform und Kontenrahmen: GmbH und UG 1665 bzw. 3640, Einzelunternehmen, GbR und OHG die Privateinlage 1890 bzw. 2180. Ohne Rechtsform antwortet die API mit 409 PrivatePaymentNeedsLegalForm, bei anderen Rechtsformen mit 409 PrivatePaymentUnavailable (siehe Zahlungen zuordnen und erfassen).
• Erfasste Zahlungen haben neu paidBy. Neue Zahlungsbuchungen haben deutsche Buchungstexte, etwa „Bar bezahlt RE-0042“ oder „Privat bezahlt von Erika Beispiel RE-0042“, ihre Rücknahmen „Rücknahme …“. Ältere Buchungen behalten ihren Text.
• POST /api/match/payment antwortete bisher in jedem Fall mit 500. Jetzt bucht der Aufruf, ohne eingeschaltete Zahlungserfassung kommt 403 ManualPaymentUnavailable.
• Über MCP gibt es ab der Version 2026-11-01 get_document_payment, record_document_payment und reverse_document_payment: Zahlungsstand lesen, bar, privat oder über einen anderen Weg bezahlt erfassen und wieder zurücknehmen, über dieselben Prüfungen wie App und API.

31.10.2026: Rechnung nur mit Fälligkeit oder ZahlungsbedingungLink zu diesem Abschnitt kopieren

• PUT /api/draft/{id}/finalize lehnt eine Rechnung mit positivem Zahlbetrag ohne dueDate und ohne Skonto mit 422 InvoiceValidationFailed ab, in rules steht BR-CO-25. Die Norm EN 16931 verlangt eines von beiden. Der Entwurf bleibt erhalten. Über MCP gilt das für finalize_sales_draft.
• POST /api/draft/{id}/tax-case meldet den Fall vorher als blockierendes Problem mit code InvoiceValidationFailed und field dueDate, über MCP ebenso check_sales_draft und preview_sales_document.
• Rechnungen ohne Zahlbetrag, Rechnungen mit negativer Summe und Rechnungskorrekturen brauchen keine Fälligkeit. Serien setzen sie bei jedem Lauf aus dueDays. Der Storno einer negativen Rechnung ohne Fälligkeit ist am Tag des Stornos fällig.

27.10.2026: Rücknahmen bei an DATEV exportierten BelegenLink zu diesem Abschnitt kopieren

• POST /api/match/correction-settlement/reverse lehnt die Rücknahme einer Erstattung oder Verrechnung mit 409 FinalizedBookingsLocked ab, wenn einer der beteiligten Belege Buchungen hat, die schon an DATEV exportiert sind. Über MCP gilt das für record_correction_settlement mit reverse. Zurücknehmen lässt sich die Erfassung dann in der App.
• Das Erfassen lehnen API und MCP in diesem Fall schon ab. Was nur nachts festgeschrieben, aber nicht exportiert ist, nimmst du weiter über API und MCP zurück.
• POST /api/match/payment/reverse bleibt unverändert, auch nach einem Export: Für erfasste Zahlungen ist die API der einzige Weg zur Rücknahme.

26.10.2026: Höchstens 200 offene Belege je FirmaLink zu diesem Abschnitt kopieren

• Eine Firma kann höchstens 200 Belege gleichzeitig in der Verarbeitung haben, über API, App und MCP zusammen. Ein Upload darüber antwortet mit 429 DocumentQueueFull und Retry-After, ohne etwas zu speichern. Wiederhole ihn nach der Wartezeit mit derselben X-Upload-Request-Id (siehe Limits).
• Über MCP gilt dasselbe für den PUT auf den Upload-Link von prepare_document_upload. Schick die Datei nach der Wartezeit an denselben Link; ist er nach 15 Minuten abgelaufen, hol mit prepare_document_upload einen neuen. Das steht jetzt auch in der Beschreibung des Werkzeugs.
• context.available nennt, wie viele Belege gerade noch passen. Belege, deren Verarbeitung auf den nächsten Tag verschoben ist, zählen nicht mit. Belege aus dem Mail-Postfach zählen mit, werden aber nie abgelehnt.

25.10.2026: Name des BankkontosLink zu diesem Abschnitt kopieren

• Bankkonten haben neu displayName: den Namen, unter dem bimetrics das Konto zeigt. Hat jemand das Konto in der App umbenannt, ist es dieser Name. Sonst heißen Konten bei PayPal, Stripe und Wise „PayPal-Konto“, „Stripe-Konto“ und „Wise-Konto“, die übrigen wie in productName, ohne Bezeichnung „Bankkonto“. Eine andere Währung als Euro steht dahinter, etwa „PayPal-Konto USD“. productName bleibt, wie die Bank es liefert.
• Das Feld steht in GET /api/bankaccount/{id}, POST /api/bankaccount/filter und am Bankkonto der Umsätze, über MCP in list_bank_accounts und get_bank_account. Werkzeugnamen und Rechte bleiben gleich.

24.10.2026: Nächtliche FestschreibungLink zu diesem Abschnitt kopieren

• bimetrics schreibt jede Nacht die offenen Buchungen fest, deren Buchungsdatum bis zum Ende des vorvorigen Monats reicht, am 1. November also bis zum 30. September. Buchungen, deren Beleg, Umsatz, Zuordnung oder Zahlung vor höchstens 30 Tagen erfasst wurde, und Buchungen zu Belegen oder Umsätzen mit einem Buchungsfehler warten auf eine spätere Nacht. Die vorläufige Buchung eines nicht zugeordneten Umsatzes bleibt offen, bis der Umsatz zugeordnet ist; die Buchungen der Zuordnung warten dann 30 Tage. Nachts festgeschrieben werden nur Buchungen von Unternehmen mit aktivem Tarif oder laufender Testphase; der DATEV-Export schreibt wie bisher alle exportierten Buchungen fest.
• Buchungen haben neu finalizedBy: export für den DATEV-Export, auto für die nächtliche Festschreibung. Festgeschrieben heißt damit nicht mehr exportiert; ob eine Buchung exportiert ist, steht in export. status ist changed_after_export, wenn die Buchung exportiert ist und ihr Storno noch nicht.
• PATCH /api/document/{id}, POST /api/match/ und DELETE /api/match/{id} sperren nur noch Buchungen, die schon an DATEV exportiert sind, ebenso update_document, create_match und delete_match über MCP. Andere festgeschriebene Buchungen storniert bimetrics wie in der App und bucht neu.
• POST /api/match/payment, POST /api/match/correction-settlement/refund und POST /api/match/correction-settlement/offset fügen nur Buchungen hinzu und sperren ebenfalls nur noch bei Buchungen, die schon an DATEV exportiert sind. disabledReason finalized heißt dort „exportiert“.

23.10.2026: Neue Freigabeseite (MCP-Version 2026-10-23)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-23. Sie hat dieselben Werkzeuge wie 2026-10-16 und dieselbe Anlage aus dem Rechtspaket 2026-10-10-v1; neu ist nur die Freigabeseite.
• Statt des Häkchens Schreibzugriff erlauben steht dort der Schalter Ändern wie in der App, an, wo Ändern möglich ist. Ein einziges Unternehmen ist vorausgewählt.
• Sind für ein Unternehmen schon zehn Verbindungen aktiv, antwortet die Freigabe mit 400 und {"code":"McpConnectionLimit","companyId":"…"}. companyId nennt eines der gewählten Unternehmen.
• Bestehende Verbindungen behalten ihren Umfang.

23.10.2026: Netto, Steuer und Steuersatz je BuchungLink zu diesem Abschnitt kopieren

• POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} liefern je Buchung neu taxRate, den Steuersatz in Prozent, sowie netAmount und taxAmount, den Netto- und den Steueranteil von amount. Alle drei sind Dezimalzahlen als String. Bei Reverse Charge ist taxAmount 0, weil DATEV die Steuer dort über den BU-Schlüssel bucht.

22.10.2026: Versteuerung vor der ersten RechnungLink zu diesem Abschnitt kopieren

• PUT /api/draft/{id}/finalize schließt Rechnungen und Rechnungskorrekturen nur noch ab, wenn die Versteuerung der Firma bestätigt ist und ihre Steuernummer vorliegt; bei Regelbesteuerung genügt die USt-IdNr. Sonst antwortet die API mit 422 und dem Code SellerTaxStatusUnconfirmed bzw. SellerTaxIdRequired, context.field nennt die Angabe. Beides ergänzt du in der App.
• Bei Firmen, die vor dem 22.10.2026 angelegt wurden, gilt die Versteuerung als bestätigt. Stornos sind nicht betroffen.
• POST /api/draft/{id}/tax-case meldet beides vorab als blockierendes Problem.

22.10.2026: Nächste Mahnungsnummer in der VorschauLink zu diesem Abschnitt kopieren

• POST /api/reminder/{id}/preview nennt bei Entwürfen neu nextNumber, die Nummer, die das Ausstellen jetzt vergeben würde. Reserviert ist sie nicht.

21.10.2026: XRechnungLink zu diesem Abschnitt kopieren

• POST /api/draft/ und PUT /api/draft/{id} nehmen einvoiceProfile an: EN16931 (Standard, ZUGFeRD) oder XRECHNUNG für eine XRechnung 3.0 (CII). Dazu kommen buyerReference (Käuferreferenz, bei Behörden die Leitweg-ID), orderReference (Bestellnummer) und supplierNumber (Lieferantennummer). Die XML lädst du nach dem Abschließen mit GET /api/draft/{id}/einvoice-xml herunter (siehe Ausgangsrechnungen).
• Fehlt einer XRechnung eine Pflichtangabe, meldet die Prüfung des Entwurfs sie als blockierend (xrechnung_…), und PUT /api/draft/{id}/finalize antwortet mit 422 XRechnungDataRequired; context.field nennt die Angabe.
• Leitest du mit POST /api/draft/{id}/derive eine Rechnung aus einem Angebot oder einer Auftragsbestätigung ab, wird sie zur XRechnung, wenn der Kontakt eine gültige Leitweg-ID hat.
• Kontakte haben neu paymentInfo.supplierNumber (Lieferantennummer). Eine neue oder geänderte Leitweg-ID (paymentInfo.leitwegId) wird auf Format und Prüfziffern geprüft; eine ungültige lehnt die API mit 400 InvalidLeitwegId ab.
• MCP: Ab Version 2026-10-09 legen create_sales_draft und update_sales_draft mit Schreibzugriff auch XRechnungen an und setzen die drei Referenzen; get_sales_document liefert sie mit. update_contact pflegt ab Version 2026-10-05 auch die Lieferantennummer. Werkzeugnamen und Rechte bleiben gleich.

17.10.2026: BU-Schlüssel, Storno-Verweis und ZahlungenLink zu diesem Abschnitt kopieren

• Buchungen aus POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} haben neu buKey, den BU-Schlüssel des DATEV-Exports, etwa 0401. origin.reversedById nennt die Buchung, die diese storniert.
• Forderungen aus GET /api/receivable/ und GET /api/receivable/{id} haben neu lastPaymentOn, das Datum der jüngsten Zahlung, und lastPaymentTransactionId, den Bankumsatz dazu; bei einer erfassten Zahlung fehlt er.
• GET /api/match/correction-settlement/{correctionDocumentId} liefert in bankPayments die Bankumsätze, die allein der Rechnungskorrektur zugeordnet sind, etwa eine Erstattung per Überweisung. Eine Verrechnung nennt in targetDraftId den Entwurf der Zielrechnung.

12.10.2026: Laufende Mahnung an der ForderungLink zu diesem Abschnitt kopieren

• GET /api/receivable/{id} und GET /api/receivable/ liefern neu activeReminder: die ausgestellte Mahnung, deren Frist noch läuft, mit Nummer, Art, Ausstellungsdatum und Frist. Die Frist läuft bis einschließlich des Fristtags. canRemind behält seine Bedeutung; lass eine weitere Mahnung während der Frist ausdrücklich bestätigen.
• receivableVersion ändert sich, sobald zur Rechnung eine Mahnung ausgestellt wird, eine laufende zurückgezogen wird oder ihre Frist abläuft. Eine ältere Vorschau lehnt POST /api/reminder/{id}/issue dann mit 409 ReceivablePreviewChanged ab (siehe Forderungen und Mahnungen).

12.10.2026: Art, Stand und Herkunft je BuchungLink zu diesem Abschnitt kopieren

• POST /api/accounting/booking/filter und GET /api/accounting/booking/{id} liefern je Buchung neu die Buchungsart kind (etwa purchase_invoice oder payment) und den Stand gegenüber DATEV status (open, finalized oder changed_after_export). export sagt, ob und wann die Buchung an DATEV ging, origin verweist auf Beleg, Umsatz, Zuordnung, Buchungsvorlage und stornierte Buchung.
• In den Buchungen eines Belegs oder Umsatzes fehlen diese Felder.

10.10.2026: Rückfrage vor dem Ändern von Mahnungs- und KorrekturentwürfenLink zu diesem Abschnitt kopieren

• update_payment_reminder und update_invoice_correction sind ab Version 2026-10-11 als destruktiv gekennzeichnet (destructiveHint), auch in bestehenden Verbindungen. Die Anwendung kann damit nachfragen, bevor sie einen gespeicherten Entwurf ändert. Namen, Parameter und Rechte bleiben gleich.

10.10.2026: Regeln der App auch für API und MCPLink zu diesem Abschnitt kopieren

• PUT /api/draft/{id}/finalize schließt Angebote und Auftragsbestätigungen nur nach den Regeln des Editors ab: Der Leistungszeitraum endet nicht vor seinem Beginn, Skonto und Steuerausnahme sind nicht eingetragen. Sonst antwortet die API mit 400, context.field nennt das Feld (siehe Ausgangsrechnungen).
• PUT /api/reminder/{id} und update_payment_reminder behalten ohne layoutId das gespeicherte Layout der Mahnung.
• create_recurring_invoice legt Serienvorlagen mit den Standardwerten der App an: Einleitungs- und Fußtext, QR-Code und das Skonto aus den Firmeneinstellungen, sofern es innerhalb der Zahlungsfrist endet. update_recurring_invoice lehnt unveränderte Texte, Lieferanschrift und USt-Bestätigungen aus der App nicht mehr ab.

10.10.2026: Gekürzte IBANs in Mahnungstexten und KorrekturgründenLink zu diesem Abschnitt kopieren

• Die Mahnungswerkzeuge, etwa get_payment_reminder und search_payment_reminders, geben den Mahnungstext wie die Texte von Rechnungen aus: IBANs gekürzt ([IBAN DE…3000]), Zeilenumbrüche als Leerzeichen. Dasselbe gilt für correctionReason von Rechnungskorrekturen. PDF-Vorschau und Download zeigen den Text vollständig.
• Kommt text bei update_payment_reminder oder reason bei update_invoice_correction so zurück, wie er gelesen wurde, bleibt der gespeicherte Text samt IBAN und Absätzen erhalten. Einen geänderten Text lehnen beide ab, wenn der gespeicherte eine IBAN oder Zeilenumbrüche enthält; solche Texte änderst du in bimetrics.

10.10.2026: MCP-Verbindungen ohne erneute FreigabeLink zu diesem Abschnitt kopieren

• Jede Anwendung mit Grant-Typ refresh_token erhält bei der Freigabe offline_access, auch wenn sie nur mcp:read anfragt; die Token-Antwort nennt es in scope. ChatGPT bleibt damit bis zu 30 Tage verbunden, statt nach Ablauf des Access-Tokens eine neue Freigabe zu brauchen.
• Beim Erneuern eines Tokens darf resource fehlen: Die neuen Tokens bleiben an die MCP-Adresse der Freigabe gebunden. Eine andere Adresse lehnt der Server weiterhin mit invalid_target ab.

10.10.2026: Belege berichtigen wie in der App (MCP-Version 2026-10-16)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-16 mit der Anlage aus dem Rechtspaket 2026-10-10-v1. Mit Schreibzugriff berichtigt update_document Belege wie in der App, auch Beträge, Steuerfall (vatTreatment), Belegart und Gegenpartei; Positionen lassen sich hinzufügen und entfernen.
• Neu ist preview_document_change (nur mit mcp:write). Es zeigt vor der Berichtigung die gesetzten Felder, Summen je Steuersatz, Buchungen, Buchungsfehler und den offenen Betrag der Zuordnung, ohne zu speichern.
• get_document liefert dafür bis zu 100 Positionen mit index und vatTreatment, die Gegenpartei mit Kontakt, Kundennummer und Konto, die Zahlungsbedingungen und ob der Beleg festgeschrieben ist.
• PATCH /api/document/{id} nimmt neue optionale Felder an: kind, counterparty, expectedTotalMinor und je Position op, label, amountMinor und vatTreatment. Ein leerer String in dueDate oder performancePeriodTo entfernt die Fälligkeit bzw. das Ende des Leistungszeitraums. Belege aus Buchungsvorlagen lassen sich jetzt berichtigen und Positionen von Eingangsbelegen auch auf 9 oder 5,5 % setzen; beides gilt auch für update_document in älteren MCP-Versionen. Festgeschriebene Belege bleiben gesperrt (siehe Belege gezielt korrigieren).

09.10.2026: Rechnungen im DokumentkontingentLink zu diesem Abschnitt kopieren

• Jede festgeschriebene Rechnung (Typ 380) wird einmal als verarbeitetes Dokument erfasst, egal ob aus der App, über die API, MCP oder eine Serie; Stornos und Korrekturen nie. Ob Rechnungen zum Kontingent zählen, hängt vom Vertrag ab: GET /api/entitlement/ nennt das in usage.invoicesCounted.
• Ist das Kontingent nach einer Rechnung ausgeschöpft, enthält die Antwort von PUT /api/draft/{id}/finalize quotaNotice mit limit, usage und nextStep. Die Rechnung ist trotzdem ausgestellt.
• Bei Verträgen ab der Fassung 2026-10-10-v1 lehnt PUT /api/draft/{id}/finalize weitere Rechnungen ab, sobald 110 % des Kontingents erreicht sind: 402 InvoiceQuotaExceeded mit context.limit, context.usage und context.nextStep. Es wird keine Nummer vergeben, der Entwurf bleibt erhalten. Stornos blockiert das Kontingent nie.

09.10.2026: Forderungen, Mahnungen, Rechnungskorrekturen und Serien (MCP-Version 2026-10-11)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-11. Schon mit Lesefreigabe lesen sie Forderungen, Mahnungen, den Korrekturumfang ausgestellter Rechnungen, Erstattungsstände und Serienvorlagen; download_payment_reminder lädt ausgestellte Mahnungen als PDF.
• Mit Schreibzugriff erstellen sie Zahlungserinnerungen und Mahnungen und stellen sie nach der PDF-Vorschau aus, bereiten Rechnungskorrekturen vor, die wie Rechnungen nach der Vorschau ausgestellt werden, halten bereits erfolgte Erstattungen und Verrechnungen fest und richten Serien für Rechnungsentwürfe ein. Versendet, überwiesen oder automatisch ausgestellt wird dabei nichts.
• Die API bietet dieselben Abläufe: GET /api/receivable/, POST /api/reminder/, POST /api/draft/{id}/correction, POST /api/match/correction-settlement/refund und POST /api/recurringinvoice/ (siehe Schreiboperationen).

07.10.2026: Auftragsbestätigungen und PDF-Download (MCP-Version 2026-10-10)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-10. Auch ohne Schreibzugriff lesen sie Rechnungen, Angebote und Auftragsbestätigungen, prüfen Entwürfe, zeigen die Druckvorschau und laden mit download_sales_document das PDF.
• Mit Schreibzugriff erstellt derive_sales_document aus einem ausgestellten Angebot eine Auftragsbestätigung oder aus Angebot bzw. Auftragsbestätigung einen Rechnungsentwurf; delete_order_confirmation_draft verwirft offene AB-Entwürfe. Eine Auftragsbestätigung bucht nichts.
• In der API: POST /api/draft/{id}/derive und GET /api/orderconfirmation/{id}.

05.10.2026: Cursor verfügbarLink zu diesem Abschnitt kopieren

• Cursor verbindet sich mit dem MCP-Server über die hinterlegte Client-ID bimetrics-cursor. Die Schritte und das Plugin-Paket stehen unter Verbinden.
• bimetrics steht im Verzeichnis der Konnektoren von Claude (In Claude verbinden).

04.10.2026: ChatGPT und Codex verfügbarLink zu diesem Abschnitt kopieren

• ChatGPT und Codex verbinden sich mit dem MCP-Server, beide ohne Client-ID über die automatische Einrichtung. Die Schritte stehen unter Verbinden. Cursor folgt.

04.10.2026: Upload-Links über files.bimetrics.deLink zu diesem Abschnitt kopieren

• Die Upload-Links von prepare_document_upload laufen über https://files.bimetrics.de. In Claude erlaubst du diesen Host einmalig unter claude.ai/settings/capabilities für die Code-Ausführung. Erreicht die Anwendung den Host nicht, öffnet appUrl die Belege des Unternehmens mit der Dateiauswahl, und du wählst den Beleg in bimetrics selbst aus (siehe Belege per Claude hochladen).

04.10.2026: Belege hochladen, Suche und Monatsabschluss (MCP-Version 2026-10-09)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-09 mit der Anlage aus dem Rechtspaket 2026-10-09-v1. Verbindungen älterer Versionen behalten ihren Umfang, bis sie neu verbunden werden; die Anwendung erwähnt das Neu-Verbinden einmal, wenn du nach einer neuen Funktion fragst.
• Neu sind prepare_document_upload (Belege per Upload-Link hochladen, nur mit mcp:write), search, get_export_check, preview_document und copy_sales_document.
• get_document, get_transaction, search_documents, get_company_context und list_bank_accounts liefern neue Felder und Filter, etwa Buchungsfehler, Erkennungsstand und den Zustand der Bankverbindung.
• create_sales_draft, update_sales_draft und check_sales_draft arbeiten wie der Editor, auch an Entwürfen aus der App, mit Rabatt und Art je Position, Fußtext, Kundenreferenz, Leistungszeitraum, Skonto und § 13b/§ 4.

04.10.2026: MCP wie in der App (MCP-Version 2026-10-05)Link zu diesem Abschnitt kopieren

• Neue Verbindungen nennen die Version 2026-10-05 mit der Anlage aus dem Rechtspaket 2026-10-05-v1. Verbindungen älterer Versionen behalten ihren Umfang, bis sie neu verbunden werden.
• create_match, delete_match und update_document wirken sofort wie in der App, statt einen Vorschlag unter Freigaben anzulegen. Sie nehmen idempotencyKey statt requestId; Zuordnen und Aufheben arbeiten wie in der App über die IDs, Belegkorrekturen weiter mit expectedVersion. Werkzeuge mit spürbaren Folgen tragen destructiveHint.
• Neu sind preview_sales_document (eine Seite als Bild, so wie bimetrics sie druckt, mit Vorschau-Nachweis) und finalize_sales_draft (Rechnungsentwurf festschreiben oder Angebot ausstellen, nur im Stand der Vorschau), beide nur mit mcp:write. Festschreiben ist endgültig, versendet wird nichts (siehe Schreibzugriff).
• Jede zugelassene Anwendung erhält dieselben Werkzeuge und denselben Schreibzugriff, ob Claude, ChatGPT, Codex oder eine andere; es gibt keine Liste schreibberechtigter Anwendungen mehr. Anwendungen, die nur in Testumgebungen von nicht gelisteten Hosts kommen, bleiben lesend. preview_sales_document liefert immer den vollständigen Text mit allen Positionen und Zahlungsbedingungen, ein Bild nur Anwendungen mit Bildanzeige (siehe Gleicher Umfang für jede Anwendung).
• Neu sind außerdem list_document_templates und dismiss_match_suggestion. search_documents filtert nach Betrag, search_transactions nach Betrag und Richtung. create_sales_draft und update_sales_draft legen auch Angebotsentwürfe an (kind, validUntil). update_contact ändert alle Felder des Kontaktformulars, auch Kundennummer, Kundentyp, IBAN und BIC; Kontakte lesen dazu Kundentyp, gekürzte IBAN und BIC. get_match nennt die aus Belegvorlagen erzeugten Belege (generatedDocumentIds).

04.10.2026: Tagesbudgets für SchreibaufrufeLink zu diesem Abschnitt kopieren

• Die Schreiboperationen haben Tagesbudgets je Firma: insgesamt, für Festschreiben und Vollstorno zusammen und für neue Kontakte. Die Werte stehen unter Limits. Ist ein Budget aufgebraucht, antwortet die API mit 429 WriteBudgetExceeded, Retry-After nennt die Sekunden bis Mitternacht UTC.

04.10.2026: MCP für TeammitgliederLink zu diesem Abschnitt kopieren

• Ein Inhaber kann Teammitgliedern unter Einstellungen › Team das MCP-Recht geben (MCP: nur lesen oder MCP: lesen und schreiben). Sie verbinden ihre KI-Anwendung dann selbst, sehen und widerrufen ihre eigenen Verbindungen und bestätigen die Vorschläge aus ihren Verbindungen. Inhaber sehen alle Verbindungen und erhalten bei jeder neuen Verbindung eines Teammitglieds eine Mail (siehe Berechtigungen und Freigabe). Das gilt ab der Version 2026-10-04.

04.10.2026: MCP-Schreibzugriff vorausgewählt, vollständige LinksLink zu diesem Abschnitt kopieren

• Auf der Freigabeseite ist Schreibzugriff erlauben vorausgewählt, auch wenn die Anwendung nur mcp:read anfragt. Ohne Häkchen bleibt die Verbindung lesend. Neue Verbindungen nennen die Version 2026-10-04, bestehende behalten ihre Version.
• MCP-Ergebnisse mit appPath enthalten zusätzlich appUrl, den vollständigen Link in die App; ausgenommen sind get_company_context und Verbindungen älterer Versionen. Assistenten können ihn direkt anzeigen. Der Link nennt das Unternehmen (company), die App wechselt dorthin (siehe Tools und Vorlagen).
• get_sales_document liefert für Verbindungen der Version 2026-10-04 zusätzlich Datumsangaben, Preisart, Bemerkung sowie je Position Rabatt und Betrag nach Rabatt, damit ein Assistent einen gelesenen Entwurf unverändert zurückschreiben kann. Die Suche liefert diese Felder nicht.
• Ein Schreibaufruf, den bimetrics für die Anwendung oder das Unternehmen nicht zulässt, erhält ein Tool-Ergebnis mit Fehler und Grund statt 403 (siehe Schreibzugriff). Nachtrag: Seit dem 04.10.2026 hängt Schreiben nicht mehr von der Anwendung ab.

03.10.2026: Rechnungen abschließen und stornierenLink zu diesem Abschnitt kopieren

• PUT /api/draft/{id}/finalize verlangt für Rechnungen (Typ 380) die vollständige Anschrift von Absender und Empfänger: Straße, PLZ, Ort und Land der Firma sowie Name, Straße, PLZ, Ort und Land des Kunden. Fehlt eine Angabe, antwortet die API mit 422 InvoiceAddressRequired, context.field ist company.address, buyer.name oder buyer.address. Es wird keine Rechnungsnummer vergeben. Die Entwurfsprüfung POST /api/draft/{id}/tax-case meldet fehlende Anschriften und einen fehlenden Firmennamen schon vorher als blockierende Probleme (InvoiceAddressRequired, company_name_required).
• POST /api/draft/{id}/cancel setzt als Referenz immer die Nummer der Originalrechnung, auch wenn das Original eine eigene Referenz wie eine Bestell- oder Angebotsnummer trug. Bisher brach der Storno dann mit 422 InvoiceValidationFailed ab. Kopf- und Fußtext nennen die stornierte Rechnung; Skonto und QR-Code entfallen. Die Fälligkeit bleibt nur, wenn der Storno einen Betrag fordert, etwa beim Storno einer Rechnung mit negativer Summe.
• Ein Positionsrabatt (discount) unter 0 oder über 100 ergibt beim Anlegen, Ändern und Abschließen 400 BadRequest mit context.field, etwa items[0].discount. Bisher wirkte ein negativer Rabatt als Aufschlag, und ein Rabatt über 100 ergab eine negative Position. Stornos übernehmen die Rabatte der Originalrechnung unverändert.

03.10.2026: MCP mit mehreren UnternehmenLink zu diesem Abschnitt kopieren

• Eine MCP-Verbindung kann mehrere Unternehmen umfassen. Jedes Werkzeug nimmt das optionale Argument company (ID oder genauer Name); neu ist list_companies. Neue Verbindungen nennen die Version 2026-10-03.

03.10.2026: SchreibzugriffLink zu diesem Abschnitt kopieren

SchreibzugriffLink zu diesem Abschnitt kopieren

• Sieben zusätzliche API-Berechtigungen: contacts:read, sales:read, contacts:write, invoices:draft, invoices:finalize, matching:write und documents:write. Bestehende Schlüssel erhalten keine Schreibrechte. read umfasst zusätzlich Zuordnungen, Ausgangsrechnungen und Entwürfe einschließlich ausgestelltem XML (siehe Authentifizierung).
• Neue Endpunkte zum Anlegen und Ändern von Kontakten, Erstellen und Prüfen von Rechnungsentwürfen, Abschließen gespeicherter Entwürfe und Erzeugen eines Vollstornos. Das ausgestellte XML lässt sich herunterladen. Entwürfe werden nicht per API gelöscht.
• Zuordnungen lassen sich anlegen und nach einer Löschvorschau mit unveränderter Versionsmap aufheben. Belegfelder und vorhandene Positionen lassen sich gezielt korrigieren. Schreibaufrufe verwenden Idempotency-Key und die jeweiligen Versionsbedingungen (siehe Schreiboperationen).
• Die Erfassung bereits erfolgter Bar- oder Verrechnungszahlungen bleibt standardmäßig ausgeschaltet. Eine vorhandene Zahlung lässt sich über den Rücknahme-Endpunkt durch Gegenbuchung korrigieren. Dieser Release führt keine neue Kontingentbelastung erzeugter Rechnungen ein.

Löschungen und ZuordnungenLink zu diesem Abschnitt kopieren

• Die Filterrouten nehmen includeDeleted an. Mit true liefern sie auch gelöschte Einträge, erkennbar am neuen Feld deletedAt, dem Zeitpunkt, seit dem ein Eintrag als gelöscht gilt. Nach deletedAt lässt sich filtern und sortieren (siehe Filtern und Paginieren). Ohne das Feld liefern die Routen wie bisher nur Einträge, die nicht gelöscht sind.
• Belege, die bimetrics beim Löschen behält, etwa wegen festgeschriebener Buchungen, gelten in der API als gelöscht: POST /api/document/filter liefert sie nur noch mit includeDeleted, GET /api/document/{id} und GET /api/document/{id}/content antworten mit 404. Bisher kamen sie ohne Kennzeichen in den Treffern.
• Zuordnen, das Aufheben einer Zuordnung und ein neuer offener Betrag (match.amountOpen) ändern updatedAt der betroffenen Belege und Umsätze.
• Der Delta-Sync gleicht Löschungen in einem zweiten Durchgang ab und gilt jetzt auch für Buchungen.

27.09.2026: FilterLink zu diesem Abschnitt kopieren

• Ein Filterwert, der nicht zum Typ des Attributs passt, und ein not ohne children ergeben 400 BadRequest statt 500. Das gilt auch für Zahlen mit Nachkommastellen bei Ganzzahl-Attributen, die bisher abgeschnitten wurden, und für Zeitpunkte in einer Schreibweise außerhalb von ISO 8601. Die Datenbank las davon manche, etwa 05.06.2026 als 6. Mai.
• not verneint seine Ausdrücke als Ganzes. Bisher lieferte ein not um ein and die Treffer eines not um ein or.

26.09.2026: Erste öffentliche VersionLink zu diesem Abschnitt kopieren

• Dokumentation der API unter developer.bimetrics.de mit Leitfäden und Referenz für 15 Endpunkte.
• Maschinenlesbare Beschreibung als OpenAPI 3.0 unter app.bimetrics.de/api/openapi.json.
• Fehlerantworten haben einheitlich die Felder code, status, detail und context.
• Eine unbekannte Filterart (kind) und sort nach einem nicht sortierbaren Attribut ergeben 400 BadRequest statt 500.
• POST /api/accounting/booking/groupfilter ist nicht mehr mit API-Schlüsseln erreichbar. Buchungen liefern POST /api/accounting/booking/filter und GET /api/accounting/booking/{id}.