Glossar

Die Begriffe stehen alphabetisch. Feldnamen, Werte und Abläufe beziehen sich auf die bimetrics API, die REST-API unter developer.bimetrics.de. Die MCP-Werkzeuge von bimetrics haben eigene Feldnamen und Formate und liefern teils andere Treffer. Für sie gelten ihre eigenen Beschreibungen und Schemas.

AbschlagsrechnungLink zu diesem Abschnitt kopieren

Rechnung über einen Teil eines Auftrags, bevor alles fertig ist, auch Anzahlungs- oder Akontorechnung genannt. In bimetrics eine Rechnung mit invoiceRole down_payment, abgeleitet aus einem ausgestellten Angebot oder einer Auftragsbestätigung mit percent oder amountMinor. downPaymentOrdinal zählt die Abschläge eines Auftrags, deductedBy nennt die Schlussrechnung, die ihn abzieht. Ihre Zahlung bucht bei Soll auf „Erhaltene Anzahlungen“.

Alte NummerLink zu diesem Abschnitt kopieren

Die Kunden- oder Lieferantennummer eines Kontakts aus dem früheren Programm, etwa aus Lexware Office oder sevdesk, im Feld externalRef. In der App steht sie im Kontakt-Editor unter „+ Mehr“ › „Alte Nummer“, und die Suche der Kontaktliste findet den Kontakt auch darüber. Sie steht nie auf Belegen und ändert weder Kundennummer noch DATEV-Konten. Eine neu gesetzte alte Nummer ist je Firma eindeutig, in der App wie über REST-API und MCP.

AutomatikkontoLink zu diesem Abschnitt kopieren

Ein Sachkonto, dem DATEV einen festen Steuerschlüssel zuordnet. Die Kontenbezeichnungen (GET /api/accounting/accounts/labels/) markieren solche Konten mit automatic: true und nennen in tax diesen Steuerschlüssel.

Ob DATEV die Umsatzsteuer oder Vorsteuer auf einem Automatikkonto selbst herausrechnet, hängt vom Steuerschlüssel der Buchung ab. Steht ein Automatikkonto in account oder accountContra, gilt beim DATEV-Export:

BelegLink zu diesem Abschnitt kopieren

Eine Rechnung oder ein anderer Nachweis, der in bimetrics hochgeladen, per E-Mail eingegangen, in bimetrics erstellt oder aus einer Dauerbuchung oder einer Vorlage erzeugt wurde. Das Feld kind ist der Belegtyp, in der App „Eingehend“ oder „Ausgehend“:

Beim Upload bestimmt das Formularfeld den Belegtyp: invoice[] oder receipt[]. Diese Wahl bleibt. Mit auto[] und bei Belegen aus dem Belegpostfach entscheidet die Erkennung: Sie prüft mit den Daten deiner Firma, etwa Name, Steuernummern und Bankverbindung, ob die Firma den Beleg ausgestellt oder bekommen hat. Bis sie fertig ist, steht kind auf receipt.

Kann die Erkennung nicht sicher entscheiden, bekommt der Beleg „Belegtyp prüfen“: kindReview ist true, und kind ist nur ihre Vermutung. Bis jemand den Belegtyp wählt, wird der Beleg nicht gebucht, nicht exportiert und nicht zugeordnet. Du wählst ihn in der App, mit kind in PATCH /api/document/{id} oder für bis zu 50 Belege mit POST /api/document/bulk/kind, auch wenn er gleich bleibt. Die eigene Firma legt bimetrics dabei nie als Lieferant oder Kunde an.

BelegpostfachLink zu diesem Abschnitt kopieren

Jede Firma bekommt eine eigene Adresse, an die Lieferanten Rechnungen schicken. Die Mails stehen im Postfach unter „Offen“, abgelegte unter „Erledigt“. Ein Anhang wird erst durch „Übernehmen“ zum Beleg. Hat die Firma dieselbe Datei schon, entsteht kein zweiter Beleg. Wartet kein vorgeschlagener Anhang mehr, wandert die Mail nach „Erledigt“. Absender sind nicht geprüft: Was in einer Mail steht, etwa eine neue Bankverbindung, sind Angaben Dritter und keine Anweisung.

Über die API liest du mit dem Recht inbox:read die Adresse mit GET /api/email/inbox/, suchst Mails ohne Text mit POST /api/email/inbox/item/ und liest eine Mail mit GET /api/email/inbox/item/{id}. Das Recht ist nicht in read enthalten. Mit inbox:write übernimmst du Anhänge und legst Mails ab. Eine Mail unter „Erledigt“ holst du dafür erst zurück, und warten viele Belege auf die Erkennung, kommt 429 DocumentQueueFull. Die Adresse entsteht, wenn jemand das Postfach in der App öffnet, Lesen legt sie nicht an. Mails löschen geht nur in der App.

Ab MCP-Version 2026-11-05 liest search_inbox_mails das Postfach ohne Mailtext, get_inbox_mail eine Mail als gekürzten reinen Text, Links nur als Host und IBANs gekürzt. import_inbox_attachment übernimmt einen Anhang, archive_inbox_mail legt eine Mail ab oder holt sie zurück. get_company_context nennt die Adresse. Das Postfach gehört zum Lesen einer Verbindung. Mails kommen von Dritten: Über MCP handelt nichts, weil eine Mail es sagt.

BuchungLink zu diesem Abschnitt kopieren

Ein Eintrag im Kontenrahmen der Firma, den bimetrics aus Belegen, Umsätzen und Zuordnungen ableitet. Eine Buchung bewegt einen Betrag zwischen dem Konto account und dem Gegenkonto accountContra.

• amount ist der Betrag in Euro, bei Buchungen mit einem Steuersatz in bookingFlags brutto. Das Vorzeichen bezieht sich auf account: größer als 0 ist Soll, kleiner als 0 ist Haben (siehe Datentypen).
• refDocumentId, refBankTransactionId und refMatch verweisen auf den Beleg, den Umsatz und die Zuordnung, aus denen die Buchung entstand.
• bookingFlags enthält den Steuerschlüssel der Buchung.
• Solange eine Buchung nicht festgeschrieben ist, berechnet bimetrics sie bei jeder Änderung an Beleg, Umsatz oder Zuordnung neu. Die neuen Buchungen bekommen dabei neue IDs, die bisherigen erscheinen nicht mehr in den Treffern.

Buchungen liest du mit POST /api/accounting/booking/filter und GET /api/accounting/booking/{id}. Belege und Umsätze enthalten ihre Buchungen außerdem im Feld bookings.

Die beiden Buchungsrouten liefern zusätzlich abgeleitete Felder, die in bookings an Belegen und Umsätzen fehlen:

• kind: die Buchungsart, etwa purchase_invoice, sales_invoice, payment, accrual_release oder reversal.
• status: open (nicht festgeschrieben), finalized (festgeschrieben) oder changed_after_export (exportiert, ihr Storno aber noch nicht).
• export: ob und wann die Buchung mit einem DATEV-Export an DATEV ging (exported, exportedAt), und ob sie ein Nachtrag ist (addendum): DATEV hat sie noch nicht, obwohl ein Export ihr Datum schon umfasst. Sie geht erst an DATEV, wenn ihr Monat noch einmal exportiert wird.
• origin: woher die Buchung kommt, etwa Beleg und Belegnummer, Umsatz, Zuordnung, Dauerbuchung oder Vorlage, und welche Buchung sie storniert oder von welcher sie storniert wird.
• buKey: der BU-Schlüssel, den der DATEV-Export schreibt, etwa 0401; fehlt ohne Schlüssel. Bei Ist-Versteuerung tragen Zahlungen auf Ausgangsrechnungen den Schlüssel wie im Export, schon exportierte den, mit dem sie an DATEV gingen. Teilt der Export eine Zahlung auf mehrere Steuersätze oder nennt er keine einzelne Rechnung, fehlt er (siehe Steuerschlüssel auf Zahlungen bei Ist-Versteuerung).
• netAmount, taxAmount und taxRate: amount aufgeteilt in Netto und Steuer mit demselben Vorzeichen, dazu der Steuersatz. Bei Reverse Charge ist taxAmount 0.

Debitor und KreditorLink zu diesem Abschnitt kopieren

Personenkonten eines Kontakts: Das Debitorenkonto nimmt Forderungen an einen Kunden auf, das Kreditorenkonto Verbindlichkeiten gegenüber einem Lieferanten. bimetrics bildet beide Kontonummern aus der Kunden- bzw. Lieferantennummer customerNumber des Kontakts. Die Kontenbezeichnungen (GET /api/accounting/accounts/labels/) nennen sie mit dem Namen des Kontakts. GET /api/contact/{id} und die Kontaktsuche POST /api/contact/filter nennen beide in datevAccounts (debitor, creditor), nur lesbar; der Kontakt-Editor der App zeigt sie unter der Kundennummer, bei Kunden das Debitorenkonto, bei Lieferanten das Kreditorenkonto, bei Partnern beide. Fehlt die Nummer oder ist sie zu groß für ein eigenes Konto (Kreditor ab Kundennummer 30000, Debitor ab 60000), bucht bimetrics auf das Sammelkonto 70000 bzw. 10000, und creditorCollective bzw. debitorCollective ist true.

E-RechnungLink zu diesem Abschnitt kopieren

Beim Abschließen einer Ausgangsrechnung (PUT /api/draft/{id}/finalize) erzeugt bimetrics die E-Rechnung. Standard ist ZUGFeRD im Profil EN 16931: ein PDF mit eingebetteter XML-Datei. Mit einvoiceProfile: XRECHNUNG entsteht eine XRechnung 3.0 in der Syntax CII, etwa für Rechnungen an Behörden. Maßgeblich ist dann die XML-Datei, das PDF ist eine Sichtkopie zum Lesen. Eine XRechnung braucht eine Käuferreferenz (buyerReference), bei Behörden die Leitweg-ID; ohne Angabe übernimmt bimetrics die Leitweg-ID des verknüpften Kontakts (paymentInfo.leitwegId). Die XML einer ausgestellten Rechnung liefert GET /api/draft/{id}/einvoice-xml. Das Profil EXTENDED gibt es nur in der App. Eingehende E-Rechnungen in CII und UBL, auch XRechnungen, liest bimetrics beim Upload aus.

Vor dem Abschließen prüft bimetrics:

• Versteuerung: Die Firma hat ihre Versteuerung bestätigt (422 SellerTaxStatusUnconfirmed) und eine Steuernummer hinterlegt; außer bei Kleinunternehmern genügt auch die USt-IdNr. (422 SellerTaxIdRequired). Es zählt die Versteuerung am Leistungsdatum, auch für den Steuerfall, den POST /api/draft/{id}/tax-case prüft, und für die Buchungen der Rechnung (siehe Kontenrahmen).
• Fälligkeit: Eine Rechnung mit Zahlbetrag hat ein Fälligkeitsdatum oder Zahlungsbedingungen, sonst 422 InvoiceValidationFailed mit BR-CO-25 in context.rules. Eine neue Rechnung aus der App oder über MCP ist ohne angegebenes Datum nach dem Zahlungsziel aus den Einstellungen fällig, nach dem des Kunden, wenn er eins hat (Zahlungsziel und Skonto je Kunde); ohne Zahlungsziel hat sie keine Fälligkeit. Eine aus einem Angebot oder einer Auftragsbestätigung umgewandelte Rechnung ist nach dem Zahlungsziel des Kunden fällig, sonst nach dem der Firma, ohne beide nach 14 Tagen; eine duplizierte behält die Zahlungsfrist des Originals. Beim Anlegen über die API setzt du dueDate selbst; ohne dueDate und cashDiscount nimmt ein Entwurf an einen Kunden mit eigenen Bedingungen diese.

Ein Hinweistext aus dem Rechnungslayout der Firma steht auch in der XML-Datei.

ErkennungLink zu diesem Abschnitt kopieren

Nach dem Upload liest bimetrics die Belegdaten im Hintergrund aus, etwa Rechnungsnummer, Datum, Aussteller und Positionen. Den Stand zeigt uploadDocument.ocrStatus. Die Werte und ihre Bedeutung stehen unter Beleg-Upload.

• Lange Dateien: bimetrics liest bis zu 60 Seiten je PDF. Einen Scan ohne Textebene mit mehr als einer Seite liest bimetrics Seite für Seite und überspringt dabei leere Rückseiten. Bei vielen Seiten dauert das einige Minuten. Hat die Datei mehr als 60 Seiten, liest bimetrics die ersten 60 und sagt es: uploadDocument.pagesRead ist dann kleiner als uploadDocument.pageCount, und die App zeigt am Beleg einen Hinweis. Die Summe steht oft auf der letzten Seite, deshalb gehört sie bei so einem Beleg mit dem Original verglichen.
• Erneut lesen: Ist das Lesen fehlgeschlagen (ocrStatus failed), bleibt der Beleg gespeichert. „Erneut lesen“ am Beleg in der App startet die Erkennung neu, über die REST-API POST /api/document/{id}/reading/retry mit dem Recht upload. Der Beleg wartet danach sofort wieder (pending), ein zweiter Aufruf bekommt 409 DocumentReadingNotFailed. Das erneute Lesen zählt im Tarif als weiterer Beleg ins Kontingent. Es geht nicht bei einem Beleg, den jemand von Hand erfasst hat (409 DocumentReadingManual), nicht bei festgeschriebenen Buchungen (409 DocumentReadingFinalized) und nicht bei einer Rechnung, die in bimetrics ausgestellt wurde (409 DocumentReadingIssued).
• Ohne Kategorie gelesen: Kann bimetrics den Positionen keine Kategorie zuordnen, liest es den Beleg trotzdem fertig. Die Positionen bleiben dann ohne Kategorie, der Beleg wird noch nicht gebucht und steht in der App unter „Kategorie fehlt“, bis jemand sie wählt.

FestschreibungLink zu diesem Abschnitt kopieren

Beim DATEV-Export schreibt bimetrics die exportierten Buchungen fest. Außerdem schreibt bimetrics bei aktivem Tarif oder laufender Testphase jede Nacht die noch offenen Buchungen fest, deren Buchungsdatum vor dem Vormonat liegt, sobald Beleg, Umsatz und Zuordnung dazu vor mehr als 30 Tagen erfasst wurden. Die vorläufige Buchung eines nicht zugeordneten Umsatzes bleibt bis zur Zuordnung offen. Das Feld finalized enthält dann den Zeitpunkt, sonst ist es null. finalizedBy nennt den Auslöser: export für den DATEV-Export, auto für die nächtliche Festschreibung. Festgeschrieben heißt deshalb nicht exportiert; ob eine Buchung an DATEV ging, steht in export.

• Festgeschriebene Buchungen ändern sich nicht mehr.
• Ändert sich danach der Beleg oder der Umsatz, korrigiert bimetrics per Storno und legt die neuen Buchungen zusätzlich an. Ändert sich nur die Zuordnung, bleibt die Buchung stehen, solange DATEV dieselbe Zeile bekäme. Löst man aber eine Zahlung von ihrem Beleg, ändert sich ihr Konto und bei einer Sammelzahlung mit Rest auch das Belegfeld. Dann gibt es Storno und Neubuchung.
• Ergibt die Änderung einen Buchungsfehler, bleibt die festgeschriebene Buchung stehen. Storno und neue Buchungen folgen erst, wenn der Fehler behoben ist.
• Einen noch zugeordneten Beleg löscht bimetrics nicht. Einen Beleg ohne aktuelle Zuordnung entfernt bimetrics beim Löschen nicht endgültig, wenn eigene Buchungen oder Buchungen aus einer früheren, inzwischen gelösten Zuordnung festgeschrieben sind. Dieser Schutz bleibt auch nach einer Gegenbuchung bestehen. Stattdessen wird der Beleg intern als gelöscht markiert; seine invoicePositions bleiben erhalten. Die ursprünglichen festgeschriebenen Buchungen bleiben erhalten und werden, soweit erforderlich, durch Stornobuchungen aufgehoben. Für API-Schlüssel liefert POST /api/document/filter den Beleg nur mit includeDeleted: true; deletedAt enthält den Zeitpunkt der Löschmarkierung. GET /api/document/{id} und GET /api/document/{id}/content antworten mit 404 (siehe Gelöschte Einträge).
• Mit dem Filterattribut finalized findest du festgeschriebene Buchungen (range mit einer Untergrenze lower) oder nicht festgeschriebene (eq mit dem Wert null).
• Davon getrennt ist das Abschließen einer Ausgangsrechnung mit PUT /api/draft/{id}/finalize, in der App „Rechnung ausstellen“. Dabei vergibt bimetrics die Rechnungsnummer und erzeugt PDF, E-Rechnung und Buchungen. Diese Buchungen sind danach noch nicht festgeschrieben, finalized bleibt bis zum DATEV-Export oder zur nächtlichen Festschreibung null. Eine abgeschlossene Rechnung ändert bimetrics nicht mehr. Korrigiert wird sie per Rechnungskorrektur, in der App „Gutschrift“, oder per Stornorechnung.

FirmenprofilLink zu diesem Abschnitt kopieren

Die Firmendaten aus den Einstellungen der App: Name, Rechtsform, Anschrift, Kontaktangaben, Geschäftsführung, Steuernummer, USt-IdNr., Handelsregister, Nummernkreise, Skonto-Vorgabe, Zahlungsziel, Schlusstext, Textvorlagen, DATEV-Nummern, Art der Umsätze und Rechnungsabgrenzung. In der App stehen Nummernkreise, Bankverbindung, Zahlungsziel, Skonto und Textvorlagen unter Einstellungen › Rechnungen, Versteuerung, Kontenrahmen und DATEV unter Einstellungen › Buchhaltung. GET /api/company/ liefert sie unter settings mit ihrer version, die Textvorlagen unter documentTexts. Ändern geht mit PATCH /api/company/ und dem Recht company:write. Du nennst nur die Felder, die sich ändern, und schickst die gelesene version als expectedVersion mit. Ab MCP-Version 2026-11-04 änderst du sie auch über MCP mit update_company_profile; get_company_context liefert dafür settings und version. Kontenrahmen, Versteuerung und Bankverbindung der Firma änderst du nur in der App. Ausgestellte Rechnungen behalten die Angaben ihres Tages.

TextvorlagenLink zu diesem Abschnitt kopieren

Längere Texte, die eine Firma für neue Belege hinterlegt, etwa eine Widerrufsbelehrung oder einen Hinweis auf ihre AGB: Kopf- und Fußtext je für Rechnung, Angebot und Auftragsbestätigung. Bis November 2026 hießen sie in der App „Feste Texte“. Der Fußtext der Rechnung ist der Schlusstext. Storno und Korrektur haben keine Textvorlage.

• Wo: In der App unter Einstellungen › Rechnungen. Über die API mit PATCH /api/company/ und documentTexts. Über MCP lassen sich nur der Fußtext der Rechnung (invoiceDefaults.closingText) ändern und neue Entwürfe mit den Textvorlagen anlegen.
• Wirkung: Die Textvorlage kommt als Kopie in jeden neuen Entwurf ihrer Belegart und geht dem letzten Entwurf und dem Standardtext der App vor. Ohne Textvorlage bleibt es dabei. Im Beleg lässt sich der Text ändern. Offene Entwürfe und ausgestellte Belege behalten ihren Text, auch wenn die Firma ihn später ändert.
• Umwandeln: Der neue Beleg bekommt die Textvorlagen seiner Belegart. Beim Weg vom Angebot zur Auftragsbestätigung und von dort zur Rechnung bleibt ein eigens geschriebener Text erhalten.
• Standardtexte: Ohne Textvorlage setzt bimetrics seinen Standardtext ein, in der Sie-Form mit „Guten Tag,“ vorn und „Viele Grüße“ und dem Firmennamen am Schluss des Fußtexts. Einzelunternehmen (Rechtsform 170 und 180) schreiben „ich“, alle anderen Firmen „wir“. Rechnung: „vielen Dank für Ihren Auftrag. Wir berechnen Ihnen die folgenden Leistungen:“ und „Bitte geben Sie bei der Überweisung die Rechnungsnummer als Verwendungszweck an.“, ohne IBAN der Firma „Bitte geben Sie bei der Zahlung die Rechnungsnummer an.“ Angebot: „vielen Dank für Ihre Anfrage. Gern machen wir Ihnen folgendes Angebot:“ und „Das Angebot gilt bis zum angegebenen Datum. Bei Fragen melden Sie sich gern. Wir freuen uns auf Ihren Auftrag.“ Auftragsbestätigung: „vielen Dank für Ihren Auftrag. Gern bestätigen wir Ihnen die folgenden Leistungen:“ und „Bei Fragen melden Sie sich gern.“ Zeigt das Layout der Belegart den Baustein „Dank“, fehlt der Dank im Kopftext, etwa „Guten Tag, wir berechnen Ihnen die folgenden Leistungen:“, damit der Beleg nur einmal dankt. Zahlungsziel, Skonto und Bankverbindung druckt das PDF selbst. Die Stornorechnung nennt die Rechnung im Kopftext und hat keinen Fußtext.
• Alte Standardtexte: Ein neuer Entwurf übernimmt in der App Kopf- und Fußtext des letzten Entwurfs, über MCP den Kopftext. Ist dieser Text wortgleich ein früherer oder heutiger Standardtext von bimetrics, auch mit anderem „ich“ und „wir“ oder mit und ohne Dank, kommt der heutige. Ebenso beim Umwandeln und Duplizieren. Steht im Fußtext unter „Viele Grüße“ ein anderer Name als der aktuelle Firmenname, etwa von Hand eingetragen oder von vor einer Umbenennung, bleibt der Text. Eigene Texte, Textvorlagen und offene Entwürfe bleiben unverändert.
• API: POST /api/draft/ setzt bei leerem remark oder notes die Textvorlage ein, ohne sie den Standardtext der App, wie MCP.
• Grenzen: Höchstens 6000 Zeichen je Text, nur Text mit Absätzen, ohne Fettdruck und Platzhalter. Mail-Adressen und Links sind erlaubt. Zeichen, die das PDF nicht drucken kann, etwa Emojis, lehnt das Speichern ab (CompanyTextCharacters). Bankdaten nehmen die Texte nur in der App auf.
• Im PDF: Der Kopftext steht vor den Positionen, der Fußtext unter der Summe, ein langer Text läuft auf Folgeseiten weiter. In der E-Rechnung stehen beide als Rechnungshinweis.
• Inhalt: Für den Text ist die Firma verantwortlich. bimetrics liefert keine Rechtstexte.

GegenkontoLink zu diesem Abschnitt kopieren

Das zweite Konto einer Buchung, im Feld accountContra. Es hat die umgekehrte Seite von account. Bei einem Eingangsbeleg ist es in der Regel das Kreditorenkonto des Lieferanten, bei einer Ausgangsrechnung das Debitorenkonto des Kunden (siehe Debitor und Kreditor).

Gesellschafter-VerrechnungLink zu diesem Abschnitt kopieren

Eine Vorlage für GmbH und UG, auch in Gründung, mit der die Firma einem Gesellschafter erstattet, was er für sie privat bezahlt hat. bimetrics stellt sie jeder solchen Firma bereit, sobald die Zahlungserfassung eingeschaltet ist. Ihre Kategorie shareholder_clearing bucht den Bankumsatz direkt gegen „Verbindlichkeiten gegenüber GmbH-Gesellschaftern“ (SKR03 1665, SKR04 3640), ohne Umsatzsteuer. Die Vorlage übernimmt den Betrag der Überweisung, deshalb gehen auch Teilerstattungen und eine Überweisung für mehrere Belege. In der App wendest du sie beim Umsatz unter „Ohne Beleg“ › „Vorlage anwenden“ an. Über die API findest du sie mit POST /api/document/collection/series/filter und ordnest sie mit POST /api/match/ in documentSeriesIds dem Umsatz zu. Der privat bezahlte Beleg selbst bekommt die Überweisung nicht zugeordnet, er ist schon bezahlt.

Kontakte prüfenLink zu diesem Abschnitt kopieren

bimetrics prüft IBAN, USt-IdNr. und PLZ eines Kontakts beim Anlegen und Ändern, in der App, über die API und über MCP gleich. Nur eine falsche IBAN sperrt: Hat eine neue oder geänderte IBAN nicht die Länge ihres Landes oder stimmen ihre Prüfziffern nicht, etwa nach einem Zahlendreher, speichert bimetrics nichts und antwortet mit InvalidIban. Eine gespeicherte IBAN bleibt, und leeren geht immer. Bei der USt-IdNr. gibt es nur Hinweise in hints, die nie sperren: vat_id_format, wenn sie nicht die Form ihres EU-Staats hat, etwa „DE“ und nur acht Ziffern, und vat_id_check_digit, wenn die Form stimmt, die Prüfziffer aber nicht. Die Prüfziffer kennt bimetrics für die Staaten, die ihre Regeln veröffentlicht haben, Deutschland und Österreich eingeschlossen; bei den übrigen prüft es nur die Form. Ob eine USt-IdNr. aus dem EU-Ausland wirklich vergeben ist, fragt bimetrics wie bisher beim Speichern beim EU-Dienst VIES ab. POST /api/contact/check prüft dieselben Angaben vorab, ohne etwas zu speichern, und nennt bei einer gültigen deutschen oder österreichischen IBAN in bank Name und BIC der Bank (Bundesbank bzw. OeNB). In der App füllt sich ein leeres BIC-Feld daraus, der Bankname steht nur zur Anzeige unter der IBAN und wird nicht gespeichert. Über MCP stehen die Hinweise ab der nächsten MCP-Version in den Antworten von create_contacts und update_contact.

Ort aus PLZ: Für Deutschland und Österreich kennt bimetrics die Orte jeder PLZ, für Deutschland aus OpenStreetMap (© OpenStreetMap-Mitwirkende, ODbL 1.0), für Österreich aus dem Postleitzahlenverzeichnis der RTR-GmbH. In der App füllt die PLZ den Ort, bei mehreren Orten erscheint eine Liste, und wer den Ort tippt, bekommt die PLZ vorgeschlagen. Den Ort erkennt bimetrics auch so, wie man ihn tippt: „Muenchen“, „St. Augustin“, „Frankfurt a.M.“ oder nur „Frankfurt“. Meint der Name mehrere Orte, etwa Frankfurt am Main und Frankfurt (Oder), wählt man zuerst den Ort. In deutschen Orten mit mehreren PLZ ergänzt bimetrics die PLZ aus Straße und Ort: Wer „Mönckebergstraße 7“ und „Hamburg“ tippt, bekommt 20095, das Label heißt dann „PLZ (ergänzt)“. Eine lange Straße mit mehreren PLZ bietet am PLZ-Feld nur ihre an. Eine selbst getippte PLZ ersetzt bimetrics nie. Zur ersten Anschrift eines Kontakts gibt es nur Hinweise, die das Speichern nie verhindern: postal_code_format, wenn die PLZ nicht fünf bzw. vier Ziffern hat, postal_code_city, wenn der Ort nicht zur PLZ gehört, mit dem passenden Ort als Vorschlag, und postal_code_country, wenn es die PLZ nur im anderen Land gibt, etwa 4020 Linz in Österreich. Ein Ortsteil wie „Hamburg-Altona“ passt zu Hamburg. Eine PLZ, die bimetrics nicht kennt, ergibt keinen Hinweis, denn Großkunden- und Postfach-PLZ fehlen in den Listen oft. Für eigene Formulare liefert GET /api/address/postal die Orte einer PLZ oder die PLZ eines Orts. Ein eigenes MCP-Werkzeug dafür gibt es nicht, die Hinweise beim Anlegen und Ändern reichen.

KontaktnotizLink zu diesem Abschnitt kopieren

Eine interne Notiz der Firma zum Kontakt, etwa „Rückruf nur vormittags“ oder „zahlt meist per Lastschrift“. Sie steht in contactInfo.notes, bimetrics druckt sie nie auf Belege, schreibt sie nicht in E-Rechnungen und versendet sie nicht. Über die API liest du sie mit GET /api/contact/{id} und schreibst sie mit POST /api/contact/ und PUT /api/contact/{id}; der neue Text ersetzt die ganze Notiz, eine leere Zeichenfolge leert sie. Ab der nächsten MCP-Version lesen get_contact und search_contacts sie, create_contacts und update_contact schreiben sie, dort mit höchstens 2000 Zeichen und ohne E-Mail-Adressen, Links oder IBANs.

KontenrahmenLink zu diesem Abschnitt kopieren

Die Nummerierung der Sachkonten nach DATEV. bimetrics unterstützt die Standardkontenrahmen SKR03 und SKR04. Welchen eine Firma nutzt, legt sie in der App fest; GET /api/company/ nennt ihn in accountingSystem.

Das Feld accountingModel einer Buchung nennt den Kontenrahmen und die steuerlichen Einstellungen, mit denen die Buchung entstand:

Wechselt eine Firma die Versteuerung, gilt der neue Status ab einem Stichtag: Die Buchungen eines Belegs tragen den Status seines Leistungsdatums, die eines Umsatzes den seiner zugeordneten Belege oder sonst seiner Wertstellung. Ab dem Stichtag bucht bimetrics neu, Festgeschriebenes per Storno. Die Buchungssuche liefert alle Status des Kontenrahmens. Werte Buchungen für ein Reporting deshalb getrennt nach accountingModel aus. Den Verlauf liest du mit GET /api/company/ in taxStatusHistory. Ändern lässt sich die Versteuerung nur in der App, nicht über die API.

Den Kontenrahmen kann eine Firma nicht mehr wechseln, sobald eine ihrer Buchungen festgeschrieben, auch nachts, oder an DATEV exportiert ist (409 AccountingModelHasExportedBookings). Den Umsatzsteuerstatus sperrt das nicht.

KontingentLink zu diesem Abschnitt kopieren

Die Zahl der Belege, die der Tarif im Abrechnungszeitraum enthält. Tarif und Kontingent liest du mit GET /api/entitlement/: die Grenze in limits.documents, die Nutzung in usage.documentsPeriod. Ist das Kontingent ausgeschöpft, speichert bimetrics neue Belege trotzdem und pausiert ihre Erkennung (quota_paused). Sobald wieder Kontingent frei ist, etwa im nächsten Zeitraum oder nach einem Tarifwechsel, setzt bimetrics die Erkennung von selbst fort.

• Rechnungen: Je nach Vertrag zählen ausgestellte Rechnungen mit, dann ist usage.invoicesCounted true. Ab 110 % des Kontingents lehnt bimetrics weitere Rechnungen bei neueren Verträgen mit 402 InvoiceQuotaExceeded ab, ohne eine Nummer zu vergeben; der Entwurf bleibt. Bei älteren Verträgen und in der Testphase gibt es diese Grenze nicht.
• Testphase: 7 Tage mit 100 Belegen für die ganze Testphase, einem Unternehmen und einem Bankkonto. API-Schlüssel gibt es in der Testphase nur, wenn die Funktion freigeschaltet ist, sonst erst mit einem Tarif.

Kostenstelle und VerteilungLink zu diesem Abschnitt kopieren

Eine Kostenstelle ordnet Belege und ihre Buchungen einem Standort oder Bereich zu, etwa „Standort Nord“ mit der Nummer 100. Der DATEV-Export schreibt die Nummer als KOST1 an jede Buchung mit Aufwands- oder Erlöskonto, Zahlungen bekommen keine. Eine Verteilung wie „Gemeinsam“ hat keine eigene Nummer und teilt gemeinsame Kosten nach festen Anteilen auf mehrere Kostenstellen, der Export schreibt dafür eine Zeile je Kostenstelle. Beide liefert GET /api/cost-centers, mit kind center oder distribution und den Anteilen einer Verteilung in shares als Basispunkte (5000 sind 50 %). Am Beleg und an der Buchung steht die ID in costCenterId. Bei einer Verteilung nennt costCenterParts der Buchung den Betrag je Kostenstelle, centgenau wie im Export. Nummer und Anteile stehen fest, sobald ein Beleg sie nutzt (used). Gelöscht wird nie, nur archiviert, und archivierte lassen sich nicht mehr zuordnen. Mehr unter Kostenstellen.

Offen anLink zu diesem Abschnitt kopieren

Was eine GmbH oder UG ihren Gesellschaftern für privat bezahlte Belege noch schuldet. Die App zeigt es an solchen Belegen und bei der Vorlage Gesellschafter-Verrechnung, etwa „Offen an Erika Beispiel: 1.234,56 €“. Der Betrag ist der Saldo des Kontos 1665 (SKR03) bzw. 3640 (SKR04) seit Beginn in bimetrics, über alle Belege: Privat bezahlte Belege erhöhen ihn, Erstattungen mindern ihn. Das Konto gilt für alle Gesellschafter. Ist an den Zahlungen nicht genau ein Name erfasst, heißt es „Offen an Gesellschafter“. Hat die Firma mehr erstattet, als offen war, zeigt die App etwa „50,00 € zu viel erstattet“. GET /api/match/payment/private liefert den Betrag in openMinor, in Cent, negativ bei zu viel Erstattetem.

Optionale PositionLink zu diesem Abschnitt kopieren

Eine Position im Angebot, die nicht fest beauftragt ist: optional, Bedarfsposition (auch Eventualposition) oder Alternative zur nächsten festen Position darüber. In der App stellst du die Art im Menü der Position ein. Die Position steht mit dem Betrag in Klammern im Angebot und zählt in keine Summe. Was beauftragt wurde, wählst du beim Erstellen der Rechnung oder Auftragsbestätigung; über die REST-API mit selectedLines in POST /api/draft/{id}/derive.

Privat bezahltLink zu diesem Abschnitt kopieren

Ein Eingangsbeleg, den ein Gesellschafter oder der Inhaber aus eigenem Geld bezahlt hat, etwa mit der privaten Karte. Die Zahlung erfasst du mit POST /api/match/payment und method: "private", optional mit dem Namen in paidBy; in der App heißt das „Zahlung eintragen“ › „Privat bezahlt“. Der Beleg bucht Aufwand und Vorsteuer wie sonst an den Kreditor. Die Zahlung bucht bimetrics zum Zahltag paidOn vom Kreditor auf ein Konto, das die Rechtsform bestimmt:

Ohne Rechtsform antwortet die API mit 409 PrivatePaymentNeedsLegalForm, bei anderen Rechtsformen mit 409 PrivatePaymentUnavailable. Eine erfasste Zahlung änderst du nicht, du nimmst sie mit POST /api/match/payment/reverse zurück. Ablauf und Grenzen stehen unter Zahlungen zuordnen und erfassen.

RechtsformLink zu diesem Abschnitt kopieren

Die Rechtsform der Firma, in der App unter Einstellungen › Allgemein. GET /api/company/ nennt sie in legalForm als Code nach ISO 20275, etwa 350 für GmbH, 351 für UG und 170 oder 180 für Einzelunternehmen, und in legalFormName mit dem Namen aus der App. Dazu kommen die Stammdaten, die auf jeder Rechnung stehen: managingDirectors, register, address, vatId und taxNumber. Leere Angaben fehlen. Die Rechtsform bestimmt etwa, wie bimetrics eine private Zahlung bucht: bei GmbH und UG als Schuld an den Gesellschafter, nicht als Privateinlage. Ändern lässt sie sich in der App, mit PATCH /api/company/ und ab MCP-Version 2026-11-04 über MCP mit update_company_profile (siehe Firmenprofil).

SachkontoLink zu diesem Abschnitt kopieren

Ein Konto im Kontenrahmen der Firma, etwa für Erlöse, Aufwendungen oder Bankkonten. Die Nummern aller bebuchten Konten liefert GET /api/accounting/accounts/, ihre Bezeichnungen GET /api/accounting/accounts/labels/.

SchlussrechnungLink zu diesem Abschnitt kopieren

Rechnung über den ganzen Auftrag, die die bezahlten Abschläge abzieht (invoiceRole final). „Fertig am“ ist performancePeriodFrom. Abzugszeilen tragen deduction. Beim Ausstellen storniert sie unbezahlte Abschläge, nur mit acceptCancelOpenDownPayments. Siehe Abschlagsrechnung.

SteuerschlüsselLink zu diesem Abschnitt kopieren

Das steuerliche Kennzeichen einer Buchung, im Feld bookingFlags. bimetrics schreibt es in eigener Form, nicht als DATEV-BU-Schlüssel. Den BU-Schlüssel bildet bimetrics erst beim DATEV-Export daraus. Die Buchungsrouten nennen ihn in buKey.

Werte mit none, reverse-charge oder omit sowie ein leerer Wert haben keinen eigenen Steuersatz. Die Liste ist nicht abschließend. Automatikkonten nennen ihren Steuerschlüssel in derselben Form im Feld tax der Kontenbezeichnungen.

StornoLink zu diesem Abschnitt kopieren

bimetrics kennt drei Arten:

• Stornobuchung: Eine festgeschriebene Buchung wird nicht geändert, sondern durch eine Gegenbuchung aufgehoben. Die Stornobuchung hat dieselben Konten, dasselbe Datum und das umgekehrte Vorzeichen in amount und verweist in revertsAccountBookingId auf die aufgehobene Buchung. Summierst du Buchungen, zählst du Stornobuchungen einfach mit: Beide heben sich auf.
• Storno-Zuordnung: Eine Zuordnung der Art invoice_cancellation verbindet Belege, die sich gegenseitig aufheben, etwa eine Rechnung und ihre Stornorechnung. Sie ist keine Zahlung. Die Zuordnung einer Stornorechnung legt bimetrics selbst an, lösen lässt sie sich nicht (409 SystemMatchLocked).
• Stornorechnung: Eine abgeschlossene Ausgangsrechnung ändert oder löscht bimetrics nicht. Mit POST /api/draft/{id}/cancel wird sie vollständig storniert. Die Stornorechnung (Typ 384) übernimmt die Positionen mit umgekehrtem Vorzeichen der Einzelpreise und mit unveränderten Rabatten. Sie nennt die Nummer der Originalrechnung als Referenz und im Kopftext, hat keinen Fußtext und weder Skonto noch QR-Code. Eine Fälligkeit (dueDate) hat sie nur, wenn sie einen Betrag fordert, etwa beim Storno einer Rechnung mit negativer Summe; hat das Original keine Fälligkeit, ist sie am Tag des Stornos fällig. Sonst ist dueDate null. Sie erscheint als Beleg der Art invoice mit umgekehrtem Vorzeichen, und bimetrics verbindet sie mit der Originalrechnung durch eine Storno-Zuordnung. Eine bereits zugeordnete Rechnung, etwa eine bezahlte, lässt sich nicht stornieren (409 StornoOriginalMatched). Offene Entwürfe löschst du mit DELETE /api/draft/{id}, festgeschriebene Rechnungen nie. Ab MCP-Version 2026-11-04 legt prepare_invoice_cancellation den Storno-Entwurf an, nach Vorschau und deinem Ja schreibt finalize_sales_draft ihn fest. Offene Entwürfe löscht dort delete_sales_draft.

Titel und UntertitelLink zu diesem Abschnitt kopieren

Gliedern die Positionen von Angebot, Auftragsbestätigung und Rechnung in Abschnitte, jeder mit Überschrift und Zwischensumme. In der App legst du sie mit „Titel hinzufügen“ an, den Untertitel im Menü der Titelzeile. Über die REST-API stehen sie als title und subtitle an der Position; aufeinanderfolgende Positionen mit demselben Titel bilden den Abschnitt.

UmsatzLink zu diesem Abschnitt kopieren

Eine Bewegung auf einem Bankkonto, wie die Bank sie über die Bankverbindung liefert oder wie die Firma sie in der App aus einem Kontoauszug einliest. Für eingelesene Umsätze gibt es auch Bankkonten ohne Bankverbindung. status ist booked für gebuchte und pending für vorgemerkte Umsätze. Der Betrag transactionAmount ist in Cent, negativ bei Ausgängen.

Versand per E-MailLink zu diesem Abschnitt kopieren

bimetrics verschickt nur ausgestellte Dokumente: Rechnungen, Stornorechnungen, Rechnungskorrekturen, Angebote, Auftragsbestätigungen und Mahnungen. Angehängt ist das PDF, bei E-Rechnungen auf Wunsch das XML. Eine XRechnung geht immer mit XML, das PDF nur auf Wunsch. Dazu können bis zu 10 weitere Dateien mitgehen, als PDF, JPG oder PNG: eine hochgeladene Datei, einen Beleg oder eine ausgestellte Rechnung, ein Angebot oder eine Auftragsbestätigung, etwa die gemahnte Rechnung als Kopie zur Mahnung. Alle Anhänge zusammen dürfen höchstens 10 MB groß sein, PDF und XML des Dokuments eingeschlossen. Zu einer XRechnung gehen keine weiteren Dateien mit, bei einer ZUGFeRD-Rechnung gehören sie nicht zur E-Rechnung. Was gesendet ist, bleibt unverändert an der Mail, auch wenn du den Beleg später löschst. Die Mail kommt von der Absenderadresse von bimetrics, Antworten gehen an deine Antwortadresse. Über die API holst du mit POST /api/document-mail/preview den Vorschlag der App und sendest mit POST /api/document-mail/send und dem Recht mail:send. Weitere Dateien nennst du dort in attachments, eigene lädst du vorher mit POST /api/document-mail/attachments hoch; einen Beleg anhängen darf ein API-Schlüssel nur mit dem Recht read. Je Firma gehen höchstens 20 Empfänger am Tag raus, in der Testphase 3. Die Tagesgrenzen gelten für App, API und MCP zusammen. Ab MCP-Version 2026-11-04 zeigt preview_document_mail die Mail, nach deinem Ja sendet send_document_mail genau diese.

Zahlungsziel und Skonto je KundeLink zu diesem Abschnitt kopieren

Ein Kunde kann eigene Zahlungsbedingungen haben: ein Zahlungsziel in Tagen und ein Skonto mit Prozentsatz und Frist. Sie stehen am Kontakt in paymentTerms (paymentTermDays, cashDiscount mit percent und days) und gelten für neue Rechnungen an ihn statt der Vorgaben der Firma aus den Einstellungen; was der Kontakt offen lässt, kommt von der Firma. Es gelten die Grenzen der Firma: Zahlungsziel 0 bis 365 Tage, Skonto über 0 und unter 100 % mit höchstens zwei Nachkommastellen und einer Frist von 1 bis 365 Tagen. Die Skontofrist darf nicht länger sein als das Zahlungsziel des Kunden. Einen Kundenrabatt gibt es nicht, Rabatte stehen je Position. Ausgestellte Rechnungen und offene Entwürfe behalten ihre Bedingungen. Über die API setzt du sie mit POST /api/contact/ und PUT /api/contact/{id}: paymentTerms ersetzt beide Werte, {} gibt den Kunden an die Vorgaben der Firma zurück. In der App stehen sie im Kontakt unter „Zahlungsbedingungen“, und der Rechnungseditor übernimmt sie, sobald du den Kunden wählst, mit dem Hinweis „aus dem Kontakt“; ein selbst geändertes Fälligkeitsdatum oder Skonto bleibt. Außerdem übernehmen sie ein neuer Rechnungsentwurf über MCP (create_sales_draft), eine aus Angebot oder Auftragsbestätigung umgewandelte Rechnung (App, API und MCP) und ein Rechnungsentwurf über POST /api/draft/, der den Kunden mit buyer.contactId oder buyer.customerNumber nennt und weder dueDate noch cashDiscount mitschickt; hat der Kunde keine eigenen, setzt die API weiter nichts. Ein Duplikat behält die Bedingungen des Originals, eine Serie ihre eigenen. Ab der nächsten MCP-Version liest get_contact sie, create_contacts und update_contact setzen sie.

Zu erledigenLink zu diesem Abschnitt kopieren

GET /api/home/tasks liefert dieselben Aufgaben wie die Startseite der App: Belege prüfen, Zahlungen ohne Beleg, überfällige Rechnungen, nicht zugestellte Mails, ablaufende Bankfreigaben und Mails im Postfach. Über MCP liefert sie ab MCP-Version 2026-11-04 get_open_tasks.

ZuordnungLink zu diesem Abschnitt kopieren

Die Verbindung von Belegen und Umsätzen, in der API das Objekt match an Belegen und Umsätzen. Eine Zuordnung kann mehrere Belege und mehrere Umsätze umfassen. Ohne Zuordnung ist match gleich null.

amountOpen ist der offene Betrag der Zuordnung in Cent, 0, wenn Belege und Umsätze aufgehen. autoMatch zeigt, dass bimetrics die Zuordnung selbst angelegt hat.

In der API-ReferenzLink zu diesem Abschnitt kopieren

• Kontenbezeichnungen auflisten: Automatikkonten, Debitoren und Kreditoren
• Bebuchte Konten auflisten: Nummern der Sachkonten
• Buchungen suchen und Buchung lesen: Buchungen
• Folgedokument aus gewählter Quelle erstellen: Abschlagsrechnung und Schlussrechnung
• Ausgangsrechnung vollständig stornieren: Storno
• Tarif und Kontingent lesen: Kontingent
• Zahlung erfassen und Zahlung zurücknehmen: Privat bezahlt
• Ausgangsrechnung erstellen: Abgrenzung zur Festschreibung