Häufige Fragen

prekonto verwandelt Eingangsrechnungen in Buchungssätze und erzeugt daraus einen DATEV-Buchungsstapel. Sie hinterlegen einmal die Kreditorenliste und die Gegenkontenliste eines Mandanten, laden dann Rechnungen hoch (PDF, Scan, XRechnung, ZUGFeRD) und bekommen kontierte Buchungssätze zurück: Kreditorenkonto, Gegenkonto, Steuerschlüssel, Belegdatum, Rechnungsnummer als Belegfeld 1. Am Ende ziehen Sie eine EXTF-Datei für einen Zeitraum, die in DATEV eingelesen wird.

Nein. prekonto führt keine Bücher, kennt keine Bilanz, keine Umsatzsteuervoranmeldung und keinen Jahresabschluss. Gebucht wird weiterhin in DATEV. prekonto arbeitet genau eine Strecke ab: von der eingegangenen Rechnung zum kontierten, geprüften Buchungssatz und zum Stapel, den die Kanzlei importiert.

Nein, und es ist nicht darauf angelegt. Ein Kontierungsvorschlag ist ein Vorschlag. Die fachliche Verantwortung liegt bei dem, der die Buchung freigibt. Deshalb ist der Bestätigungsschritt bewusst nicht wegoptimiert und der Export bewusst nicht festgeschrieben: Wo Bewertungsfragen anfangen — Anlage oder Aufwand, Bewirtung oder Repräsentation, Vorsteuerabzug — entscheidet ein Mensch mit Fachkunde.

Nein. prekonto erzeugt eine EXTF-Datei, die Sie oder Ihre Kanzlei in DATEV importieren. Wir haben keinen Zugang zu Ihrem DATEV-Bestand und brauchen keinen. Der Import, seine Freigabe und die Festschreibung sind Handlungen in DATEV und bleiben dort.

Für drei Gruppen. Steuerkanzleien, die viele Mandanten mit unterschiedlichen Kontierungskonventionen betreuen und die Vorkontierung beschleunigen wollen. Unternehmen mit eigener Buchhaltung, die vorkontiert an die Kanzlei übergeben. Und Mittelstand mit ERP oder SAP, der die Kontierung headless in bestehende Abläufe einbaut — über REST-API, MCP-Server oder Webhooks.

Für den Export ja, dort ist EXTF das Zielformat. Die Kontierung selbst funktioniert unabhängig davon: Sie können Buchungssätze über die API lesen und in ein anderes System übernehmen. Die DATEV-Kopfdaten eines Mandanten (Beraternummer, Mandantennummer, Wirtschaftsjahr, Sachkontenlänge) werden aber verlangt, weil sie in den Stapelkopf gehören und die Kontolängen bestimmen.

Beide. Der Kontenrahmen wird je Mandant gesetzt, erlaubt sind SKR03 und SKR04, und er geht sowohl in den Stapelkopf als auch in die Kontierung ein. Praktisch wichtiger als der Kontenrahmen ist ohnehin Ihre Gegenkontenliste: Kontiert wird ausschließlich auf Konten, die dort stehen — auch wenn das ein eigener, abweichender Kontenplan ist.

Nein. Der Gegenstand sind Eingangsrechnungen, also Kreditorenbuchungen. Die Kaskade, die den Lieferanten einem Personenkonto zuordnet, und die Gegenkonto-Findung für den Aufwand sind darauf zugeschnitten. Gutschriften und Storni zu einer Eingangsrechnung werden über das Soll-Haben-Kennzeichen abgebildet.

Das hängt fast ausschließlich an den Stammdaten. Wenn Sie eine Kreditorenliste mit Standard-Gegenkonten hochladen, ist die Hauskontierung ab dem ersten Beleg bekannt und muss nicht erraten werden. Ohne diese Vorinformation muss jeder Lieferant einmal durch die Prüfung, bevor er automatisch läuft — der Aufwand fällt dann einmal je Lieferant an, nicht einmal je Beleg.

Das hängt vom Belegformat ab, und der Unterschied ist erheblich. Eine XRechnung oder ein ZUGFeRD-PDF wird aus der eingebetteten XML gelesen — dabei ist kein Sprachmodell beteiligt, die Datei verlässt die Verarbeitung nicht. Ein PDF oder ein Scan ohne XML muss dagegen ausgelesen werden: Dann wird die Belegdatei an das Sprachmodell übertragen. Wer das vermeiden will, arbeitet mit E-Rechnungen — was ohnehin der genauere Weg ist.

Anthropic. Als Standardmodell ist Claude Haiku konfiguriert, weil es PDFs direkt verarbeiten kann und günstig ist. Anthropic ist damit ein Auftragsverarbeiter, den Sie in Ihrem Verzeichnis der Verarbeitungstätigkeiten führen müssen. Ein zweiter Anbieter ist im Code vorgesehen, aber ausdrücklich nicht implementiert — eine entsprechende Einstellung führt zu einem klaren Fehler und nicht zu einem stillen Wechsel.

Bei der Extraktion aus einem PDF: die Belegdatei selbst, dazu die aktiven Extraktions-Anweisungen des Mandanten. Bei der Kontierung kein PDF, sondern strukturierte Daten — das ausgelesene Rechnungsmodell, Name und Konto des Kreditors, dessen Standard-Gegenkonto, Ihre Gegenkontenliste und einige bestätigte Buchungssätze als Beispiele. Die Kreditorenliste als Ganzes wird nicht übertragen.

finisma ist ein Prüfdienst für E-Rechnungen. Ist ein Zugang konfiguriert, wird ein ZUGFeRD-PDF dort gegen die Norm EN 16931 geprüft und das Urteil erscheint als zusätzlicher Prüfpunkt am Beleg. Die Nutzung ist optional: Ohne Zugang läuft die Verarbeitung unverändert weiter, der Prüfpunkt fehlt dann einfach. Wenn Sie ihn nutzen, wird die PDF-Datei an finisma übertragen — dann ist finisma ein weiterer Auftragsverarbeiter, den Sie vertraglich einbinden müssen. Reines XRechnungs-XML wird nicht übertragen, der Dienst nimmt nur PDFs an.

Ja. prekonto verarbeitet in Ihrem Auftrag personenbezogene Daten — auf Rechnungen stehen Namen, Adressen, Bankverbindungen, bei Reisekostenabrechnungen sogar Beschäftigtendaten. Sie brauchen einen AVV mit uns, und der muss die eingesetzten Unterauftragsverarbeiter benennen: das Sprachmodell (Anthropic), den optionalen Prüfdienst (finisma, nur wenn aktiviert) und das Hosting. Der Stand des AVV und die vollständige Liste stehen auf der Seite Datenschutz.

Hochgeladene Dateien werden abgelegt, damit ein Beleg nachvollziehbar bleibt und ein Verarbeitungslauf wiederholbar ist. Eine verbindliche Aufbewahrungs- und Löschfrist ist Teil des Auftragsverarbeitungsvertrags und noch nicht abschließend festgelegt — bitte fragen Sie danach, statt hier eine Zahl zu vermuten. Was wir nicht tun: Belege für das Training von Modellen verwenden.

Nicht durch prekonto. Es gibt in prekonto kein Training, kein Feintuning und kein zweites Modell, das aus Ihren Daten lernt. Was gelernt wird, ist eine einfache, nachlesbare Regel: das Standard-Gegenkonto eines Kreditors, wenn zwei bestätigte Buchungen es nahelegen. Das bleibt in Ihrem Mandanten und wirkt bei niemand anderem. Wie der KI-Anbieter mit übertragenen Daten umgeht, regelt der Vertrag mit ihm; diese Angabe gehört in den AVV und nicht in eine FAQ.

Nein. Jeder fachliche Zugriff ist an einen Mandanten gebunden, und jede Abfrage filtert zusätzlich auf das Konto, dem das Credential gehört. Ein Mandant eines anderen Kontos ist nicht nur gesperrt, er wird auch nicht als existierend bestätigt: Die Antwort ist 404 und nicht 403.

Auf einem eigenen Server mit eigener Datenbank, nicht in einer fremden Buchhaltungs-Cloud. Der genaue Standort des Hostings und der Rechenzentrumsbetreiber gehören in den AVV und stehen auf der Seite Datenschutz. Zu beachten ist unabhängig davon: Beim PDF-Weg wird die Belegdatei an den KI-Anbieter übertragen, und diese Verarbeitung findet nicht auf unserem Server statt.

Ein DATEV-Buchungsstapel im EXTF-Format, Version 700, Formatkategorie 21, Formatversion 13. Die Datei besteht aus einer Header-Zeile mit 31 Feldern, einer Überschriftenzeile und je einer Buchungszeile mit 125 Feldern. Trennzeichen ist das Semikolon, Zeilenende CRLF, Zeichensatz ISO-8859-1.

Weil das Belegdatum in der Buchungszeile kein Jahr trägt: Es steht als TTMM darin, und DATEV leitet das Jahr aus dem Stapelzeitraum im Header ab. Reicht ein Stapel über die Wirtschaftsjahr-Grenze, wäre der 3. Januar nicht mehr eindeutig einem Jahr zuzuordnen. prekonto lehnt einen solchen Zeitraum deshalb ab, statt eine Datei zu erzeugen, die beim Import scheitert oder mit falschem Jahr durchläuft. Praktisch heißt das: pro Periode exportieren.

Weil DATEV sie als ISO-8859-1 liest. Wird die Datei nach UTF-8 umgeschrieben, kommen alle Umlaute falsch an. Die Datei wird byteweise so ausgeliefert, wie sie erzeugt wurde — laden Sie sie direkt in eine Datei und leiten Sie sie nicht durch Werkzeuge, die Text erkennen und anfassen. Auch ein Editor, der beim Speichern auf UTF-8 wechselt, genügt, um den Stapel zu ruinieren.

Nein, die Festschreibung ist ausnahmslos 0 — im Header und in jeder Buchungszeile. Ein festgeschriebener Stapel ist in DATEV nicht mehr korrigierbar, und diese Entscheidung gehört dem Steuerberater und nicht einem Export. Es ist deshalb eine Konstante im Code und keine Einstellung, die man versehentlich umstellt.

Er wird auf das DATEV-Maximum gekürzt und die Kürzung im Schreibprotokoll des Stapels vermerkt. Das ist die bessere Reihenfolge der Übel: Ein gekürzter Text ist ärgerlich, eine abgelehnte Zeile hält den ganzen Import auf. Die Grenzen sind 60 Zeichen für den Buchungstext, 36 für Belegfeld 1 und 12 für Belegfeld 2. Bei Belegfeld 1 sollten Sie hinsehen, wenn Ihre Lieferanten lange Rechnungsnummern verwenden — dieses Feld trägt die offene-Posten-Verwaltung.

Bei einem Automatikkonto ist der Steuerschlüssel im Konto schon enthalten. Deshalb darf dort kein BU-Schlüssel gesetzt sein — sonst rechnet DATEV die Steuer zweimal oder lehnt die Zeile ab. Das Kennzeichen kommt aus Ihrer Gegenkontenliste, und der Widerspruch wird beim Bestätigen und beim Export abgewiesen, nicht stillschweigend geglättet.

Ja, KOST1 und KOST2 werden geschrieben, sofern sie am Buchungssatz gesetzt sind, jeweils bis 36 Zeichen. Sie lassen sich beim Korrigieren setzen.

Nein. Das Feld für den Beleglink bleibt leer — die Verknüpfung mit dem Belegbild gehört zur Belegbild-Ablage in DATEV und wird von prekonto nicht geschrieben. Der Beleg selbst bleibt in prekonto abrufbar.

Ja, das ist der vorgesehene Weg. DATEV-KRexport-Dateien werden an ihrem Dateinamen oder an der Kopfzeile erkannt und ohne Sprachmodell eingelesen — für Kreditoren, Sachkonten und Mandantenstammdaten. Widersprechen sich Dateiname und Kopfzeile, gewinnt die Kopfzeile, weil der Inhalt die verlässlichere Auskunft ist.

Eine ehrliche Antwort muss zwei Dinge trennen. Das Auslesen der Rechnungsdaten ist bei einer E-Rechnung exakt, weil dort nichts erkannt werden muss. Die Kontierung dagegen hängt an Ihren Stammdaten: Steht bei einem Kreditor ein Standard-Gegenkonto, ist das Ergebnis deterministisch und stabil. Ist der Lieferant unbekannt, ist der Vorschlag ein Vorschlag und geht durch die Prüfung. Eine allgemeine Prozentzahl für Ihren Betrieb können wir nicht seriös nennen — sie hängt von der Zusammensetzung Ihrer Belege und der Vollständigkeit Ihrer Listen ab.

„Automatisch“ heißt: alle blockierenden Prüfungen sind grün und die Gesamtconfidence liegt bei mindestens 0,85. Ein Mensch muss nicht hinsehen. „Zu prüfen“ heißt: mindestens eine blockierende Prüfung ist offen oder die Confidence liegt darunter. Nur „automatisch“ und „bestätigt“ gehen in den Export; alles in der Prüfung bleibt liegen, bis jemand entscheidet.

Weil eine Selbsteinschätzung kein Beweis ist. Ein Sprachmodell ist bei einer falsch gelesenen Zahl genauso überzeugt wie bei einer richtigen. Deshalb liegt die Obergrenze für einen Gegenkonto-Vorschlag aus dem Modell bei 0,84 — knapp unter der Auto-Schwelle von 0,85 —, und weil die Gesamtconfidence das Minimum der Einzelfelder ist, zieht dieses eine Feld den ganzen Satz unter die Schwelle. Das Modell kann seine eigene Bewertung nicht anheben, weil die Grenze erst nach seiner Antwort angewendet wird.

Das ist der Angriff, gegen den die Obergrenze von 0,84 gesetzt ist. Freitextfelder eines Belegs — Notizen, Positionsbezeichnungen, Verwendungszweck — stehen im Prompt, und der Beleg gehört dem Absender. Wer sie füllt, könnte darin Anweisungen unterbringen und damit beides beeinflussen: das vorgeschlagene Konto und die gemeldete Sicherheit. Weil der Deckel unter der Auto-Schwelle liegt, führt das im schlechtesten Fall zu einem falschen Vorschlag, der einem Menschen vorgelegt wird — nicht zu einer Buchung. Zusätzlich stammen Anweisungen ausschließlich aus Ihrer Mandantenkonfiguration und nie aus einem Dokument.

Vorschlagen ja, buchen nein. Das Gegenkonto wird nicht als freier Text erzeugt, sondern als Auswahl aus Ihrer Gegenkontenliste — technisch ein Enum im Antwortschema. Danach prüft ein deterministischer Check die Antwort noch einmal gegen dieselbe Liste. Ein Konto außerhalb der Liste führt nie zu einer Buchung, sondern in die Prüfung, und wird beim Bestätigen abgewiesen.

Dann greift keine Historie und kein Standard-Gegenkonto, und der Vorschlag entsteht aus dem Rechnungsinhalt gegen Ihre Kontenliste. Ein solcher Vorschlag geht immer einmal durch die Prüfung. Der Kreditor selbst wird dabei nicht automatisch angelegt: Ein neuer Lieferant ist eine Entscheidung über Ihren Kontenplan, nicht ein Nebeneffekt eines Belegs.

Weil sie so auf der Rechnung stehen. Stimmt der Betrag nicht, ist das Auslesen falsch — und die richtige Antwort darauf ist ein neuer Verarbeitungslauf, nicht ein überschriebener Wert, der mit dem Beleg nicht mehr übereinstimmt. Ein Versuch wird deshalb ausdrücklich abgewiesen und nicht stillschweigend verworfen: Eine Erfolgsmeldung auf eine ignorierte Änderung würde vortäuschen, der Betrag sei geändert.

Die fachliche Verantwortung für eine Buchung bleibt bei dem, der sie freigibt und bei dem, der den Abschluss verantwortet — daran ändert ein Vorschlagssystem nichts. Genau deshalb ist der Bestätigungsschritt ein eigener Schritt, wird zwischen Bestätigung und Korrektur unterschieden, bleibt jedes Prüfergebnis am Buchungssatz nachlesbar und ist der Stapel nicht festgeschrieben. Die vertraglichen Haftungsregelungen stehen in den Nutzungsbedingungen, nicht hier.

Sie kann es sein, solange Vorschlag, Buchung und Festschreibung getrennt bleiben und jede Änderung nachvollziehbar ist. prekonto trägt dazu bei: Der Stapel hat Festschreibung 0 und ist in DATEV weiterhin korrigierbar, Korrektur und Bestätigung sind unterscheidbar, Prüfergebnisse und Confidence bleiben am Satz, Anweisungen werden zum Abschalten deaktiviert statt gelöscht (Löschen bleibt möglich, ist aber ein eigener Schritt hinter einer Rückfrage), und jeder Stapel ist protokolliert. Ob Ihr Gesamtverfahren samt Verfahrensdokumentation GoBD-konform ist, entscheidet nicht ein einzelnes Werkzeug in der Kette — das beurteilt Ihr Steuerberater.

Dann wird nicht geraten. Das Ergebnis ist „zu prüfen“ mit beiden Kandidaten, und ein Mensch entscheidet. Bei Namensähnlichkeit gelten zwei Treffer als gleich gut, wenn ihre Werte weniger als 0,01 auseinanderliegen — „der eine passt zu 0,941, der andere zu 0,938“ ist keine Entscheidung, die eine Maschine treffen sollte. Findet sich gar kein Kreditor, bekommt die Prüfliste bis zu drei Beinah-Treffer als unverbindliche Vorschläge.

Ja, eine vollständige REST-API unter /api/v1 — alles, was die Oberfläche kann, ist auch programmgesteuert erreichbar: Stammdaten einliefern, Rechnungen hochladen, Buchungssätze lesen, korrigieren und bestätigen, Buchungsstapel erzeugen und herunterladen, Webhooks verwalten. Die maschinenlesbare Beschreibung liegt ohne Authentifizierung unter /api/v1/openapi.json. Die Referenz steht auf der Seite API.

Über den Header „Authorization: Bearer“, auf zwei Wegen. Ein API-Key mit dem Präfix pk_live_ für eigene Skripte und Server; angelegt wird er im angemeldeten Bereich über den Punkt „API-Keys“ (Seite „API-Zugänge“), der Klartext erscheint genau einmal, gespeichert wird nur sein Hash. Oder OAuth 2.0 mit PKCE für Anwendungen, die im Namen eines prekonto-Nutzers arbeiten — nur der Authorization-Code-Flow, PKCE ist Pflicht und ausschließlich S256, Redirect-URIs werden exakt verglichen.

Ja, unter /api/v1/mcp, als Streamable HTTP und zustandslos. Es gibt elf Werkzeuge: Mandanten und Stammdaten lesen, Listen einliefern, Rechnungen hochladen und abfragen, Buchungssätze lesen, korrigieren und bestätigen, Export erzeugen. Clients, die OAuth beherrschen, brauchen nur die URL — bei 401 nennt der WWW-Authenticate-Header die Metadaten, und der Client startet den Anmeldeablauf selbst. Einzelheiten stehen auf der Seite MCP-Server.

Nein. Kein Werkzeug löscht etwas, keines legt einen Mandanten an, keines verwaltet Webhook-Ziele, keines legt einen Kreditor an, und keines ändert Betrag oder Belegdatum. Auch ein Stammdaten-Upload löscht nichts. Was ein Modell versehentlich tun kann, wird es irgendwann versehentlich tun — deshalb gibt es diese Handlungen im MCP-Kanal gar nicht. Und Freigeben ist ein eigener Schritt mit eigenem Scope: Vergeben Sie „buchungssaetze:write“ nicht, dann kann der Assistent lesen, erklären und einliefern, aber nichts freigeben.

Ja, drei Ereignisse: „invoice.processed“, wenn eine Rechnung durch ist (auch bei einem Fehler, damit sich ein hängender Beleg von einem gescheiterten unterscheiden lässt), „buchungssatz.review_needed“, wenn dabei ein Satz eine menschliche Entscheidung braucht, und „export.created“ für einen erzeugten Stapel. Jede Zustellung ist mit HMAC-SHA256 über den Rohkörper signiert; das Secret bekommen Sie einmalig beim Anlegen des Abos.

Rechnen Sie über die empfangenen Bytes, nicht über neu serialisiertes JSON. Schon eine andere Reihenfolge der Schlüssel ändert den HMAC. prekonto serialisiert den Körper genau einmal und signiert exakt den String, der gesendet wird. Quittieren Sie schnell — das Zeitlimit ist 10 Sekunden, und der Empfänger soll bestätigen, nicht verarbeiten. Wiederholt wird bis zu dreimal, aber nur bei Netzwerkfehlern, Zeitüberschreitung, 5xx und 429; ein 401 oder 404 wird nicht wiederholt.

Weil die Verarbeitung dauert. Bei einem PDF wird ein Sprachmodell gerufen, und bei mehrseitigen Belegen sind zehn Sekunden und mehr normal — das reißt jeden Proxy-Timeout. Die Antwort enthält deshalb eine statusUrl. Entweder fragen Sie die ab oder Sie abonnieren „invoice.processed“ und lassen sich benachrichtigen.

Die Handlung, die der Fehler verlangt. 400 heißt: die Eingabe ist unbrauchbar, und das war ohne Ihre Stammdaten entscheidbar — Pflichtfeld fehlt, Zeitraum verdreht, gesperrtes Feld in der Korrektur. Schicken Sie einen anderen Request. 422 heißt: die Eingabe ist verstanden, aber für diesen Mandanten nicht buchbar — Konto nicht in der Kontenliste, Kontolänge passt nicht, Zeitraum verlässt das Wirtschaftsjahr. Ändern Sie Stammdaten oder Werte; ein Retry hilft nie. Zusätzlich trägt jede fachliche Ablehnung einen maschinenlesbaren code.

Absicht. Ein 403 würde bestätigen, dass die ID existiert — das ist eine Auskunft über einen fremden Mandanten, und die gibt es nicht. Nicht gefunden und nicht berechtigt sind deshalb bewusst nicht unterscheidbar.

Ja. Beide Stammdaten-Endpunkte nehmen alternativ ein JSON-Array, bis zu 20 000 Sätze. Das ist der Weg für Aufrufer, die die Liste schon strukturiert haben — ein ERP-Export, ein Workflow, ein MCP-Client. Dabei ist kein Sprachmodell beteiligt, und es entsteht kein Upload-Datensatz.

40 MB, für Belege und für Stammdatenlisten. Darüber antwortet die API mit 413. Bei Tabellen gilt zusätzlich eine Zeilengrenze von 200 000 Zeilen; das alte .xls-Format wird nicht unterstützt, .xlsx dagegen schon.

Ja, das ist der headless-Anwendungsfall. Sie brauchen nichts von der Oberfläche: Stammdaten kommen als Datei oder JSON, Belege gehen per Upload hinein, Buchungssätze lesen Sie als JSON, und die EXTF-Datei ziehen Sie über den Download. Webhooks ersparen das Pollen. Für einen Nachtlauf ist ein API-Key mit knapp gesetzten Scopes das richtige Credential; für eine Anwendung, die mehrere prekonto-Nutzer bedient, OAuth.

Das steht noch nicht fest. Es gibt derzeit kein veröffentlichtes Preismodell — die Abrechnung ist im Produkt vorbereitet, aber nicht in Betrieb. Wir schreiben hier bewusst keinen Preis hin, den wir später ändern müssten: Sprechen Sie uns an, dann bekommen Sie eine belastbare Auskunft zum aktuellen Stand statt einer Zahl aus einer Landingpage.

Zu Testzugängen und Konditionen können wir hier nichts Verbindliches sagen, solange das Preismodell nicht steht. Fragen Sie uns direkt — die Antwort hängt davon ab, ob Sie einen einzelnen Mandanten ausprobieren oder eine Kanzlei umstellen wollen.

Ohne Passwort: E-Mail-Adresse eingeben, den Link aus der Mail anklicken. Es gibt kein Passwort, das man verlieren, wiederverwenden oder erraten kann. Eine Sitzung hält 30 Tage.

Über die Links in der Fußzeile jeder Seite. Beide Seiten sind derzeit als Platzhalter gekennzeichnet und werden vervollständigt; die Datenschutzseite beschreibt den technischen Teil aber schon vollständig — welche Auftragsverarbeiter beteiligt sind und wann Daten an sie gehen — und benennt ausdrücklich, was noch fehlt. Wenn Sie diese Angaben für eine Entscheidung brauchen, fragen Sie uns direkt danach.