Kategorie für mehrere Belege setzen
Benötigte Berechtigung:documents:write(Nicht an DATEV exportierte Belege ändern)
Echte Wirkung
/api/document/bulk/categoryKein Testversand aus der Dokumentation: Dieser Aufruf ist nicht als rein lesend gekennzeichnet. Nutze das Codebeispiel.
Setzt eine Kategorie auf alle Positionen jedes Belegs, samt dem Steuersatz, den die Kategorie vorgibt, wie „Kategorie setzen“ in der Mehrfachauswahl der App. bimetrics bucht jeden geänderten Beleg sofort neu. Übersprungen werden wie in der App festgeschriebene Belege und ausgestellte Rechnungen (finalized), Belege mit mehreren Kategorien (multiple), aus Dauerbuchungen oder Vorlagen (linked), stornierte (deleted), mit erfasster Zahlung (paid), noch nicht gelesene (unread), Belege, zu deren Art die Kategorie nicht passt (otherKind), und Belege ohne Positionen (other). Dazu unchanged, notFound und notPreviewed. Ein Beleg kommt in failed, wenn PATCH /api/document/{id} ihn ablehnen würde, etwa bei einem Steuersatz, den die Kategorie nicht erlaubt. Höchstens 50 Belege je Aufruf (400 BulkLimitExceeded). Die Antwort nennt je Beleg, was geschah: change geändert, skipped mit Grund übersprungen, failed mit Code abgelehnt. Das ist ein Teilerfolg wie in der App: Ein abgelehnter Beleg hält die anderen nicht auf, und die Route antwortet mit 200. Mit dryRun ändert sie nichts und zeigt, was geschähe, mit einer version je Beleg. Zum Ausführen gibst du diese als expectedVersions zurück, sonst antwortet die Route mit 400 ExpectedVersionRequired. Es ändert sich nur, was unter change stand und seitdem unverändert ist: Ein geänderter Beleg kommt mit VersionConflict in failed, die übrigen laufen, und ein Beleg ohne Eintrag bleibt mit notPreviewed in skipped. Jeder Beleg läuft als eigener Befehl mit eigenem Eintrag im Protokoll und zählt einzeln auf die Tagesgrenzen der Firma und der Testphase. Der ganze Aufruf zählt einmal auf die Grenzen je Minute. Eine Wiederholung mit gleichem Idempotency-Key ändert nichts doppelt und erledigt, was noch offen ist. Sie klärt auch den Stand, wenn ein Aufruf abbricht: OutcomeUnknown heißt, der Beleg kann schon gebucht sein.
Benötigt einen Schlüssel mit der Berechtigung documents:write.
AuthentifizierungBearer <bm_…>Empfohlen: Authorization: Bearer bm_…. Der Schlüssel wird nur einmal angezeigt; nie in URLs, Logs oder Frontend-Code ablegen.
Idempotency-Key*stringStabiler Schlüssel für genau diese Änderung: 1–128 druckbare ASCII-Zeichen ohne Leerzeichen. Bei Wiederholungen denselben Schlüssel und unveränderten Inhalt senden; das Ergebnis wird nicht nochmals erzeugt.
^[!-~]+$1 <= length <= 128Belege, Kategorie und Probelauf
application/json- body
Belege und die Kategorie, die alle ihre Positionen bekommen.
category?stringSchlüssel der Kategorie.
documentIds?array<>|IDs der Belege, 1 bis 50.
dryRun?booleanNur zeigen, was geschähe; nichts ändern.
expectedVersions?Ohne dryRun Pflicht: die version aus change eines dryRun je Beleg-ID. Es ändert sich nur, was seitdem unverändert ist; ein Beleg ohne Eintrag bleibt (notPreviewed).
Erfolg.
application/json- response
Was mit jedem Beleg geschah oder bei dryRun geschähe.
change?array<>|Belege, die sich ändern oder geändert haben.
dryRun?booleanTrue, wenn nichts geändert wurde.
failed?array<>|Belege, die der Server abgelehnt hat oder ablehnen würde oder deren Stand er nicht bestätigen konnte. Eine Ablehnung ändert nichts.
notice?stringDer Satz zu einer Grenze, die Belege aufgehalten hat, falls es einen gibt.
reversedFinalizedMonths?array<string>Monate (YYYY-MM), in denen bimetrics festgeschriebene Buchungen storniert und mit geändertem Datum, Leistungszeitraum, Konto, Steuerkennzeichen oder Betrag neu gebucht hat. Ändert sich nur der Buchungstext oder die Zuordnung, fehlt der Monat. 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. Fehlt, wenn nichts storniert wurde, und bei einer Wiederholung mit demselben Idempotency-Key.
skipped?array<>|Belege, die bleiben, wie sie sind.
totalMinor?integerSumme von change in Cent.
curl --fail-with-body "https://app.bimetrics.de/api/document/bulk/category" \ -H "Authorization: Bearer $BIMETRICS_API_KEY" \ -H "Idempotency-Key: rechnung-2026-001" \ -H "Content-Type: application/json" \ -d '{}'{ "change": [ { "amountMinor": 11900, "categoryBefore": "office_supplies", "counterparty": "Beispiel Bürobedarf GmbH", "id": "a129ef0a-da5d-4204-804c-764d751bca95", "invoiceNumber": "RE-2026-0142" } ], "dryRun": false, "failed": [], "skipped": [ { "id": "a2543540-c7ca-413d-8bcc-1ef3427e8aa4", "reason": "finalized" } ], "totalMinor": 11900}Beleg hochladen POST
Lädt genau eine Datei als neuen Beleg hoch und stößt die Erkennung an. Die Antwort ist ein Array mit genau einem Beleg. Das Formularfeld bestimmt die Belegart: `invoice[]` Ausgangsrechnung, `receipt[]` Eingangsbeleg, beides bindend; bei `auto[]` entscheidet die Erkennung mit den Daten deiner Firma. Kann sie nicht sicher entscheiden, bekommt der Beleg „Belegtyp prüfen“ (`kindReview`) und wird nicht gebucht, bis du den Belegtyp wählst. Unterstützt werden PDF, PNG, JPEG und XML-E-Rechnungen. `X-Upload-Request-Id` macht Wiederholungen sicher: Dieselbe ID mit identischer Datei, identischem Dateinamen und Feld liefert denselben Beleg, ohne weiteres Kontingent; dieselbe ID mit anderem Inhalt ergibt `409 UploadRequestConflict`. Für jeden neuen Beleg eine neue ID verwenden. Ist das Belegkontingent ausgeschöpft, wird der Beleg trotzdem gespeichert (`uploadDocument.ocrStatus` = `quota_paused`); dann keinen weiteren Upload mit neuer ID starten. Benötigt einen Schlüssel mit der Berechtigung `upload`.
Kostenstelle für mehrere Belege setzen POST
Setzt an jedem genannten Beleg eine Kostenstelle oder Verteilung wie der Button „Kostenstelle“ in der Mehrfachauswahl der App; ein leerer String entfernt sie, ohne `costCenterId` antwortet die Route mit `400`. Weil sich kein Betrag ändert, geht das auch bei ausgestellten und bezahlten Belegen. bimetrics bucht jeden geänderten Beleg sofort neu. Übersprungen werden festgeschriebene (`finalized`), an DATEV exportierte (`exported`), gelöschte (`deleted`) und noch nicht gelesene Belege (`unread`) sowie Belege, die sie schon haben (`unchanged`); dazu kommen `notFound` und `notPreviewed`. Die Kostenstelle festgeschriebener Belege lässt sich einzeln mit `PATCH /api/document/{id}` trotzdem ändern, solange sie nicht an DATEV exportiert sind; dann storniert bimetrics die Buchungen und bucht sie neu. Eine archivierte oder unbekannte Kostenstelle lehnt die Route für alle Belege ab (`409 CostCenterRejected` bzw. `404 CostCenterNotFound`). Höchstens 50 Belege je Aufruf (`400 BulkLimitExceeded`). Die Antwort nennt je Beleg, was geschah: `change` geändert, `skipped` mit Grund übersprungen, `failed` mit Code abgelehnt. Das ist ein Teilerfolg wie in der App: Ein abgelehnter Beleg hält die anderen nicht auf, und die Route antwortet mit `200`. Mit `dryRun` ändert sie nichts und zeigt, was geschähe, mit einer `version` je Beleg. Zum Ausführen gibst du diese als `expectedVersions` zurück, sonst antwortet die Route mit `400 ExpectedVersionRequired`. Es ändert sich nur, was unter `change` stand und seitdem unverändert ist: Ein geänderter Beleg kommt mit `VersionConflict` in `failed`, die übrigen laufen, und ein Beleg ohne Eintrag bleibt mit `notPreviewed` in `skipped`. Jeder Beleg läuft als eigener Befehl mit eigenem Eintrag im Protokoll und zählt einzeln auf die Tagesgrenzen der Firma und der Testphase. Der ganze Aufruf zählt einmal auf die Grenzen je Minute. Eine Wiederholung mit gleichem Idempotency-Key ändert nichts doppelt und erledigt, was noch offen ist. Sie klärt auch den Stand, wenn ein Aufruf abbricht: `OutcomeUnknown` heißt, der Beleg kann schon gebucht sein. Benötigt einen Schlüssel mit der Berechtigung `documents:write`.