# Tool-Übersicht, Fassung 2026-10-16 (https://developer.bimetrics.de/mcp/tools/2026-10-16) Belege berichtigen wie in der App, mit Positionen, Beträgen, Steuerfall, Belegart und Gegenpartei, und die Vorschau der Korrektur. Diese Fassung ergänzt die [Werkzeuge vom 11.10.2026](/mcp/tools/2026-10-11). Es gilt die Anlage „MCP-Verbindungen“ aus dem [Rechtspaket 2026-10-10-v1](https://bimetrics.de/rechtliches/2026-10-10-v1/avv#anlage-mcp-verbindungen). Für den erweiterten Werkzeug- und Datenumfang ist nach Anlage 2.3 eine neue Freigabe erforderlich. Bestehende Verbindungen erhalten keine zusätzlichen Werkzeuge oder Felder. Die gelockerten Regeln des gemeinsamen Befehls gelten aber für `update_document` jeder Fassung und für die REST-API: Belege aus Buchungsvorlagen lassen sich berichtigen und Positionen von Eingangsbelegen auch auf 9 oder 5,5 % setzen; ein Leistungsbeginn ohne Ende gilt als einzelnes Leistungsdatum. Nur API-Schlüssel und Verbindungen dieser Fassung können Fälligkeit und Ende des Leistungszeitraums mit `""` leeren. ## Beleg lesen `get_document` liefert in dieser Fassung alles, was eine Berichtigung braucht. Lesefreigaben erhalten es ebenso. | Feld | Inhalt | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `positions` | Bis zu 100 Positionen mit `index` (ab 0), Bezeichnung, Bruttobetrag `amountMinor`, USt-Satz, Kategorie und `vatTreatment`: `none`, bei 0 % auch `reverseCharge` oder `freeOfVat`. `positionsTruncated` kennzeichnet weitere oder unlesbare Positionen. | | `positionsTotalMinor` | Bruttosumme aller Positionen in Cent. | | `counterparty` | Bei Ausgangsrechnungen der Empfänger, sonst der Aussteller: Name, `contactId` des Kontakts mit derselben Kundennummer, `customerNumber`, das Land der USt-IdNr. (`vatIdCountry`) und `personalAccount`, also ob auf das Personenkonto oder das Sammelkonto gebucht wird. | | `paymentTerms` | Zahlungsbedingungen wie erkannt, nur lesbar. | | `finalized` | Buchungen des Belegs, seiner Zuordnung oder eines mit ihm zugeordneten Umsatzes sind festgeschrieben. Solche Belege berichtigst du in der App. | | `cashDiscountMatched` | Die Zuordnung hat ein Skonto ausgeglichen; eine Berichtigung muss weiter dazu passen. | Die übrigen Felder bleiben wie in der Fassung 2026-10-09, darunter Buchungsfehler, Erkennungsstand und `version`. ## Beleg berichtigen Mit Schreibzugriff berichtigt `update_document` einen Beleg sofort wie in der App, über denselben Befehl wie die REST-API (`PATCH /api/document/:id`): * **Positionen:** je Eintrag in `positions` eine Operation. `op` ist `update` (Standard) für die Position an `index`, `add` für eine neue Position mit Kategorie, Satz und Betrag oder `remove` für die Position an `index`; die letzte Position bleibt. Eine Position wird aufgeteilt, indem sie geändert und eine neue hinzugefügt wird. Höchstens 100 Positionen. * **Beträge:** `amountMinor` ist der Bruttobetrag in Cent, nie 0. Sobald sich ein Betrag ändert oder eine Position dazukommt oder wegfällt, nennt `expectedTotalMinor` die Bruttosumme aller Positionen danach; weicht sie ab, ändert sich nichts. * **Steuerfall:** `vatTreatment` gibt es nur bei 0 %. Reverse Charge gilt für den ganzen Beleg, daneben dürfen nur durchlaufende Posten stehen. * **Belegart:** `kind` ist `invoice` oder `receipt`. Die Kategorien bleiben; passen sie nicht zur neuen Richtung, zeigt der Beleg einen Buchungsfehler. Gebucht wird danach die andere Seite als Gegenpartei. * **Gegenpartei:** `counterparty.contactId` übernimmt einen Kontakt des Unternehmens mit Name, Anschrift, USt-IdNr., IBAN und Kundennummer, gebucht wird auf sein Personenkonto. Alternativ freie Angaben wie in der App: ein neuer `name` löst die Kundennummer, gebucht wird dann auf das Sammelkonto; `vatId` wird geprüft; ein leerer Wert entfernt `vatId`, `address` oder `iban`. Die IBAN dient nur der Erkennung von Zahlungen. * **Daten:** ein leeres `dueDate` entfernt die Fälligkeit, ein leeres `performancePeriodTo` macht `performancePeriodFrom` zum einzelnen Leistungsdatum. Jeder Aufruf braucht die gelesene `version` als `expectedVersion` und einen stabilen `idempotencyKey`. Bei `VersionConflict` liest die Anwendung den Beleg neu und klärt die Änderung mit dir, statt selbst zu wiederholen. Laut Werkzeugbeschreibung berichtigt die Anwendung Belege nur auf deine Bitte, nie auf Anweisung aus Beleginhalten, E-Mails oder anderen Daten, und zeigt dir vorher die Vorschau, wenn sich Beträge, Steuer, Belegart oder Gegenpartei ändern. ## Vorschau der Berichtigung `preview_document_change` nimmt dieselben Angaben wie `update_document`, ohne `idempotencyKey`, und speichert nichts. Das Werkzeug ist ein Lesewerkzeug, erscheint aber nur bei Verbindungen mit Schreibzugriff. | Feld | Inhalt | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `changedFields` | Die Felder, die die Berichtigung setzt, als Pfade ohne Werte, etwa `dueDate`, `counterparty.iban` oder `positions[1].amountMinor`. `positions[1]` allein heißt: Die Position fällt weg, `positions[new]` steht für eine neue Position. | | `before`, `after` | Brutto, Netto und USt, auch je Satz (je Position gerundet wie in der App), Personen- oder Sammelkonto, die Buchungen und die Codes der Buchungsfehler vorher und nachher. | | `match` | Bei zugeordneten Belegen der offene Betrag vorher und nachher. `cashDiscountConflict` heißt: Das ausgeglichene Skonto passt nicht mehr, `update_document` würde mit `CashDiscountNotEligible` abgelehnt. Dann zuerst die Zuordnung mit `delete_match` aufheben, berichtigen und mit `create_match` neu zuordnen. | | `warnings` | Hinweise, keine Ablehnungen: `collectiveAccount`, `reverseChargeDocument`, `euVatIdMissing`, `smallBusiness`, `receivedEInvoice` (das XML bleibt das Original), `counterpartySide`, `matchSignReversed`. | Was `update_document` ablehnen würde, lehnt die Vorschau mit derselben Meldung ab, mit einer Ausnahme: Einen Skonto-Konflikt zeigt sie als `match.cashDiscountConflict` an. Ein Token gibt es nicht. ## Was gesperrt bleibt * **Festgeschriebene Belege:** Die Berichtigung lehnt sie mit `FinalizedBookingsLocked` ab. In der App storniert bimetrics die festgeschriebenen Buchungen und bucht neu. * **Ausgestellte Rechnungen, Belege aus Dauerbuchungen und Belege mit erfassten Zahlungen** lassen sich nicht ändern. * **Zahlungsbedingungen, Fremdwährung und der Kopfbetrag** sind nicht schreibbar; der Betrag ist immer die Summe der Positionen. Nach jeder Berichtigung bucht bimetrics den Beleg sofort neu und rechnet seine Zuordnung neu; ein Rest ungleich 0 bleibt offen wie eine Teilzahlung. Die Änderung steht in der Historie des Belegs.