Matching-Richtlinien

Jeder Cortena-Mandant hat sechs Richtliniendokumente in seinem Google-Drive-Ordner. Sie geben der Cortena-KI vor, wie sie die Rechnungen dieses Mandanten liest, prüft und bucht: Wer der Mandant ist, welche Buchungskonten und BU-Codes existieren, welchem Lieferanten und welcher Kostenstelle eine Rechnung zugeordnet wird und wann eine Rechnung als vollständig gilt.

Sie sind zuerst für einen KI-Klassifikator und erst danach für Menschen geschrieben. Deshalb bestehen die Regeln aus kurzen IF/THEN-Sätzen, die auf Dingen beruhen, die auf der Rechnung sichtbar sind, etwa Lieferant, Land, USt-IdNr., Steuersatz und Positionsbeschreibung. Formulierungen wie „normalerweise“ oder „in den meisten Fällen“ werden nicht verwendet.

Geltungsbereich: ausschließlich Verbindlichkeiten und Ausgaben, also Lieferantenrechnungen, Mitarbeiterausgaben und Anlagenkäufe. Forderungen, Lohnabrechnung, Eröffnungsbilanzwerte und Bankbuchungen liegen für alle sechs Dokumente außerhalb des Geltungsbereichs.

Die sechs Dokumente im Überblick

Wie die Dokumente in die Pipeline passen

Klicken zum Vergrößern

Aus dieser Darstellung ergeben sich vier Punkte:

• Jeder Schritt sieht nur sein eigenes Dokument. Der BU-Code-Schritt liest niemals den Matching Guide, und die Vollständigkeitsprüfung liest niemals den Chart of Accounts. Eine Regel, die im falschen Dokument steht, wird einfach ignoriert, selbst wenn sie für einen menschlichen Leser korrekt aussieht.
• Sheets werden vollständig und live gelesen. Jedes Sheet wird bei jedem Durchlauf als vollständige Tabelle an die KI übergeben, einschließlich aller Spalten und der Kopfzeile. Eine Änderung gilt ab der nächsten Rechnung, eine erneute Synchronisierung ist nicht erforderlich. Verwenden Sie pro Sheet nur einen Tab, da es keine Einstellung gibt, mit der ausgewählt werden kann, welcher Tab gelesen wird.
• Einige Dokumente sind erforderlich. Wenn der Matching Guide, der Chart of Accounts, das BU-Code-Sheet, die Completeness Guideline oder das Cost-Center-Sheet nicht gefunden werden kann, schlägt die Verarbeitung fehl. Ein fehlendes Kreditoren-Sheet führt still zum Fehlschlag: Der Kreditor fällt auf die Kreditorennummer des Stammlieferanten zurück oder bleibt leer.
• Änderungen gelten nur für die Zukunft. Die Dokumente werden automatisch auf jede verarbeitete und jede erneut verarbeitete Rechnung angewendet. Bereits verarbeitete Rechnungen behalten ihre Ergebnisse, bis sie erneut verarbeitet oder manuell bearbeitet werden. Beim erneuten Verarbeiten werden Extraktion und Matching erneut ausgeführt und manuelle Buchungsänderungen an dieser Rechnung ersetzt. Prüfen Sie bearbeitete Rechnungen deshalb anschließend erneut.

Wo Sie sie in Cortena finden

Öffnen Sie für den Mandanten Settings → Accounting preferences → Matching Guidelines & Instructions. Dort sehen Sie:

• einen Link zum Öffnen des Google-Drive-Ordners des Mandanten,
• eine Karte pro Dokument mit einer kurzen Beschreibung, dem Zeitpunkt der letzten Aktualisierung und der Drive-Versionsnummer, damit Sie sehen können, wann eine Datei zuletzt geändert wurde,
• eine Schaltfläche Refresh master list für Administratoren. Solange die Masterliste noch nicht existiert, wird in diesem Abschnitt „No master definitions yet“ anstelle der Karten angezeigt. Ein Administrator kann sie mit dieser Schaltfläche erstellen, andernfalls erledigt dies die tägliche Synchronisierung,
• eine Schaltfläche Synchronise reference data, die die Referenzdaten manuell aus den Sheets neu aufbaut (siehe Richtlinien und Referenzdaten weiter unten).

Wenn die Karten fehlen, wurde die Masterliste noch nicht erstellt oder die Funktion ist für diesen Mandanten nicht aktiviert.

Klicken zum Vergrößern

Die Liste zeigt außerdem den Booking History: ein optionales Sheet mit früheren Buchungen, das die Matcher für Buchungskonten und Kostenstellen als Historie verwenden. Es gehört nicht zu den sechs Richtliniendokumenten, und die Verarbeitung läuft auch ohne dieses Sheet weiter.

Zugriff: Cortena liest die Dateien über das Google-Dienstkonto pre-accounting-upload@cortena-main.iam.gserviceaccount.com. Jede Datei, die Cortena verwenden soll, muss für dieses Konto freigegeben werden. Wenn ein Mandant eine eigene Kopie einer Datei einbringt, geben Sie sie für das Konto frei. Leserechte reichen für die Verarbeitung aus. Ein Sheet, das durch eine Synchronisierung aus dem Buchhaltungssystem überschrieben wird, benötigt Editor-Rechte.

Klicken zum Vergrößern

Dateinamen sind die Verbindung

Der Drive-Ordner des Mandanten wird über seine ID verknüpft, aber jedes darin enthaltene Dokument wird anhand seines Namens gefunden, über eine Übereinstimmung mit „contains“. Die folgenden Namen müssen Zeichen für Zeichen verwendet werden:

• Das Ergänzen eines Namens ist sicher, etwa „Chart of Accounts (2026)“. Eine Änderung ist es nicht, etwa „CoA“, „Chart of Account“ oder „Chart_of_Accounts“.
• Bewahren Sie niemals eine alte Kopie neben der neuen auf. Auch „Chart of Accounts OLD“ wird gefunden, und Cortena wählt dann zufällig eine der beiden Dateien aus. Verschieben Sie alte Versionen stattdessen in einen Unterordner. Unterordner werden nicht durchsucht.
• Jeder Dokumenttyp kann außerdem auf einen eigenen Ordner verweisen, und eine Gesellschaft kann die Datei einer anderen Gesellschaft verwenden, anstatt eine eigene Datei zu nutzen. Beispielsweise können mehrere Tochtergesellschaften den Chart of Accounts der Muttergesellschaft lesen. Eine Änderung an einer gemeinsam genutzten Datei ändert dann das Matching für jede Gesellschaft, die diese Datei verwendet.

1. Chart of Account Matching Guide

Zweck: Der KI mitteilen, wer der Mandant ist, damit sie den Mandanten unter jedem verwendeten rechtlichen Namen stets als Rechnungsempfänger erkennt, niemals als Lieferanten.

Was es ist

Ein kurzes Google Doc. Für deutsche Mandanten handelt es sich um die freigegebene Cortena-Vorlage, die unverändert kopiert wird und in der nur {CLIENT_NAME} ausgefüllt wird. Sie enthält zwei Abschnitte:

• A. General rules: eine Regel. „If you find {CLIENT_NAME} on the invoice, assume it as the recipient of the invoice unless stated otherwise. The recipient identity does not by itself determine the booking account.“
• B. Client entities: ein Aufzählungspunkt pro Rechtsträger, unter dem der Mandant Rechnungen ausstellt, beispielsweise eine GmbH und ihr Handelsname. Eine an einen dieser Rechtsträger adressierte Rechnung gilt als an den Mandanten adressiert.

Wie es funktioniert

• Das Dokument wird als System-Prompt des Extraktionsschritts eingefügt, sowohl für Rechnungsdaten als auch für Positionen. Dadurch hat es mehr Gewicht als die globalen Extraktionsregeln und die lieferantenspezifischen Dokumente, die sich im User-Prompt befinden.
• Es ist außerdem die erste Quelle, die der Buchungskonto-Matcher liest. Eine hier als STOP markierte Regel würde die Buchungshistorie und alle anderen Informationen überschreiben. Die Standardvorlage enthält bewusst keine solche Regel.
• Der BU-Code-Schritt, die Vollständigkeitsprüfung, der Kreditoren-Schritt und der Kostenstellen-Schritt lesen dieses Dokument nicht.

Beachten Sie

• Halten Sie es minimal. Da das Dokument im System-Prompt der Extraktion steht, kann bereits ein einzelner unbeabsichtigter Satz beeinflussen, wie jede Rechnung extrahiert wird. Ein tatsächliches Beispiel: Eine Zeile wie „skip rows in the totals block“ führte dazu, dass Versandkosten aus den Positionen entfernt wurden.
• Keine mandantenspezifischen Inhalte über Name und Rechtsträger hinaus: keine USt.- oder Reverse-Charge-Regeln, keine Weiterbelastungsregeln, keine Lieferantenlisten, keine Kontonummern und keine BU-Codes. Kontenlogik gehört in den Chart of Accounts, Umsatzsteuerlogik in das BU-Code-Sheet.
• Dazu gehören auch Regeln zur Zuordnung von Lieferanten zu Konten wie „all items from Supplier X go to 4400“. In diesem Dokument würde eine solche Regel im Extraktions-Prompt jeder Rechnung stehen. Als STOP-Regel würde sie die Buchungshistorie für jede Position überschreiben. Legen Sie die Lieferantensteuerung stattdessen in den Chart of Accounts: Führen Sie den Lieferanten unter Good Examples beim richtigen Konto auf oder ergänzen Sie einen Routing-Satz unter DO NOT USE IF/FOR.
• Wenn der Mandant unter einem neuen rechtlichen Namen Rechnungen auszustellen beginnt, fügen Sie in Abschnitt B einen Aufzählungspunkt hinzu.

Zum Schreibstil für den Matching Guide und das Kontenblatt siehe auch Agenten zu Buchungskonten anleiten.

2. Chart of Accounts

Zweck: die Positivliste der Buchungskonten dieses Mandanten sowie allgemein verständliche Hinweise dazu, was auf welches Konto gehört. Dieses Dokument ist die maßgebliche Quelle für das Buchungskonto jeder Position.

Was es ist

Ein Google Sheet mit einer Zeile pro Konto aus dem Kontenplan des Mandanten, etwa DATEV Kontenplan oder Twinfield / Exact Grootboekrekeningen, und genau fünf Spalten:

Die Zeilen werden in drei Stufen eingeteilt:

• Stufe 1: Verbindlichkeitskonten, auf denen der Mandant tatsächlich gebucht hat. Alle Hinweisspalten werden aus der Buchungshistorie ausgefüllt.
• Stufe 2: Verbindlichkeitskonten, auf denen bisher noch nicht gebucht wurde. Nur der Name ist ausgefüllt, die Hinweisspalten bleiben leer.
• Stufe 3: Konten, die nicht für Verbindlichkeiten bestimmt sind, etwa Bank, Umsatzsteuer, Eigenkapital, Erlöse und Forderungen. USE FOR = (Do not use).

Beispiel für eine Zeile der Stufe 1: 6640 · Bewirtungskosten · USE FOR „Business meal and catering invoices. Restaurant receipts and card payments at venues.“ · Good Examples „Typical purchases: restaurant bills, catering for client meetings“.

Wie es funktioniert

Der Buchungskonto-Matcher läuft einmal pro Position und arbeitet seine Quellen in dieser Reihenfolge ab:

1. Der Chart of Account Matching Guide, sofern STOP-Regeln vorhanden sind.
2. Die Buchungshistorie: Wie wurden die Positionen dieses Lieferanten früher gebucht?
3. Der Chart of Accounts: zuerst Good Examples, danach USE FOR und anschließend der Kontoname.
4. Keine eindeutige Übereinstimmung: Das Konto bleibt zur Prüfung leer.

Booking Account Learned Guidelines, also Regeln, die Cortena aus Korrekturen durch Benutzer lernt, werden ergänzend hinzugefügt. Es werden fünf Durchläufe ausgeführt, und mindestens drei müssen übereinstimmen. Nachdem alle Positionen zugeordnet wurden, prüft ein zweiter Durchlauf das Ergebnis und füllt leere Positionen aus Schwesterpositionen derselben Rechnung, sofern dies sinnvoll ist. Siehe Matching-Korrektur und Matching lernt aus Ihren Korrekturen.

Das Sheet speist außerdem Cortenas Referenzdaten: die Kontoauswahl in der Anwendung und den mit dem Export übermittelten Kontonamen.

Beachten Sie

• (Do not use) ist die wichtigste Schutzvorkehrung, damit die KI eine Lieferantenrechnung nicht auf ein Bank-, Umsatzsteuer- oder Eigenkapitalkonto bucht. Belassen Sie den Marker in jeder Zeile der Stufe 3.
• Die Buchungshistorie hat Vorrang vor einfachem USE FOR-Text. Wenn eine bestimmte Positionsart aus der Historie immer wieder das falsche Konto erbt, verwenden Sie einen Routing-Satz unter DO NOT USE IF/FOR.
• Keine doppelten Kontonummern: Eine Regel, die auf eine Nummer verweist, die zweimal vorkommt, ist mehrdeutig.
• Fügen Sie keine zusätzlichen Textspalten hinzu. Die Synchronisierung der Referenzdaten verwendet bei jeder Änderung einer Richtliniendatei KI, um die Spalte mit dem Kontonamen auszuwählen. Eine zusätzliche Spalte kann versehentlich ausgewählt werden. Das falsche Label erscheint dann in der Kontoauswahl und im Export.

3. (USt.) BU Code Matching Guidelines

Zweck: die Positivliste der vom Mandanten verwendeten umsatzsteuerlichen Behandlungen mit einem eindeutigen Auslöser pro Code, damit jede Position den Steuerschlüssel erhält, mit dem das Buchhaltungssystem die Umsatzsteuer korrekt bucht.

Was es ist

Ein Google Sheet mit genau drei Spalten: BU Code, Description und Tax Rate / VAT Rate. Es enthält eine Zeile pro BU-Code, den der Mandant tatsächlich in seiner Buchungshistorie verwendet hat, und niemals den vollständigen DATEV-Katalog. Jede zusätzliche Zeile erhöht die Wahrscheinlichkeit einer falschen Auswahl. Bei niederländischen Mandanten enthält dasselbe Sheet die BTW-/USt.-Codes aus dem Buchhaltungssystem.

Wie es funktioniert

• Der BU-Code-Matcher läuft einmal pro Position parallel zum Buchungskonto-Matcher. Er liest dieses Sheet, die BU Code Learned Guidelines, die extrahierten Rechnungsdaten, also Lieferanten- und Empfängerland sowie USt-Ids, und den Steuersatz der Position. Es werden drei Durchläufe ausgeführt, und mindestens zwei müssen übereinstimmen.
• Er gleicht den Steuersatz der Position exakt mit der Ratenspalte ab. Deshalb enthält die Ratenspalte den auf der Rechnung aufgedruckten Steuersatz und nicht den internen DATEV-Steuersatz: Reverse Charge (§13b), innergemeinschaftlicher Erwerb (§1a), BU 490 und der leere Code sind alle 0%, weil diese Rechnungen keine deutsche Umsatzsteuer ausweisen und DATEV die Steuer anhand des Schlüssels berechnet.
• Der Matcher sieht das Buchungskonto niemals und liest den Matching Guide nicht.
• Der Schritt verfügt außerdem über einige eigene integrierte Regeln. Ein Beispiel für deutsche Kunden: Wenn der Rechnungsempfänger keine deutsche Gesellschaft ist, wird kein BU-Code zurückgegeben.

Beachten Sie

• Jede Description ist ein einfacher IF-Satz über Dinge, die auf der Rechnung sichtbar sind. Keine Gesetzesverweise, keine Kontonummern und keine Beispiellisten.
• BU 8 und 9 sind gesperrt. Ihre Formulierung und ihr Steuersatz sind für jeden Mandanten gleich und werden niemals bearbeitet.
• Eine Regel wie „Wenn Konto X, dann BU-Code Y“ kann nicht funktionieren, da dieser Schritt das Konto nicht kennt.
• Eine Position ohne extrahierten Steuersatz erhält normalerweise keinen BU-Code. Prüfen Sie zuerst die Extraktion.
• Um einen falschen BU-Code zu korrigieren, bearbeiten Sie dieses Sheet. Eine Bearbeitung des Matching Guide hat keine Auswirkung auf BU-Codes.

4. Invoice Completeness Guideline

Zweck: festzustellen, ob eine Rechnung alle gesetzlich erforderlichen Angaben für den Vorsteuerabzug gemäß UStG §14 enthält. Unvollständige Rechnungen werden zur manuellen Prüfung weitergeleitet, statt direkt gebucht zu werden.

Was es ist

Ein Google Doc, das mit dem Cortena-Standard für das Land des Mandanten beginnt, jeweils in einer deutschen und einer niederländischen Version. Es enthält üblicherweise drei Abschnitte, aufgeteilt nach dem Sitz des Lieferanten, weil davon abhängt, welche umsatzsteuerlichen Angaben eine Rechnung enthalten muss. In der deutschen Version:

• A. Invoices from German suppliers
• B. Invoices from non-EU suppliers
• C. Invoices from EU suppliers outside Germany

Die Anforderungen in den einzelnen Abschnitten sind flexibel und können pro Mandant angepasst werden. Ein Feld kann hinzugefügt, entfernt oder bedingt gemacht werden, etwa um einen Lieferanten zu akzeptieren, der niemals einen Reverse-Charge-Hinweis aufdruckt.

Wie es funktioniert

Die Vollständigkeitsprüfung liest nur dieses Dokument und die extrahierten Rechnungsdaten. Sie sieht weder das PDF noch den Matching Guide oder irgendein Sheet. Sie schreibt „complete: yes / no“ mit einer Begründung, und der Workflow sendet jedes „no“ an Require Manual Review.

Beachten Sie

• Fordern Sie nur Felder an, die tatsächlich extrahiert werden: Namen, Adressen, USt-Ids, Daten, Positionen, Steuersätze und Beträge sowie das Reverse-Charge-Flag. Eine Anforderung, die die Prüfung nicht sehen kann, etwa der steuerpflichtige Betrag pro Steuersatz oder eine bestimmte Befreiungsformulierung, führt zu falschen Markierungen als „incomplete“.
• Wenn ein Mandant eine Ausnahme benötigt, etwa für einen Lieferanten, der niemals einen Reverse-Charge-Hinweis aufdruckt, funktioniert diese nur an dieser Stelle. Begrenzen Sie sie auf etwas in den extrahierten Daten, zum Beispiel die USt-Id des Lieferanten. Da es sich um ein Doc handelt, wird es durch Synchronisierungen aus dem Buchhaltungssystem nicht überschrieben.

5. Creditor and Debitor Allocation

Zweck: der Lieferantenstamm. Das Dokument beantwortet eine Frage: Von welchem Kreditorenkonto stammt diese Rechnung und unter welchen anderen Namen erscheint dieser Lieferant?

Was es ist

Ein Google Sheet mit genau drei Spalten und einer Zeile pro Lieferant aus der Lieferantenliste des Mandanten, etwa DATEV Kreditorenliste oder Crediteurenlijst:

• Account number: die Kreditorennummer als Text.
• Name: der Lieferantenname wie im Buchhaltungssystem.
• Alternative Names: andere Schreibweisen, Kurz- oder Handelsnamen. Leer, wenn keine vorhanden sind.

Wenn der Mandant keine Lieferantenliste bereitstellen kann, wird das Sheet aus den Kreditorennummern der Buchungshistorie erstellt. Name und Alternative Names bleiben leer. Namen werden niemals geraten.

Wie es funktioniert

1. Ein Filter erstellt eine Auswahlliste von Zeilen, die dem extrahierten Lieferantennamen ähnlich sehen. Er durchsucht jede Spalte, einschließlich Alternative Names.
2. Die KI wählt aus dieser Auswahlliste eine Kreditorennummer aus. Sie sieht nur den Lieferantennamen und die Auswahlliste.
3. Keine überzeugende Übereinstimmung: Cortena verwendet die Kreditorennummer, die beim verknüpften Stammlieferanten hinterlegt ist, sofern eine vorhanden ist. Andernfalls bleibt der Kreditor für den Prüfer leer.

Die ausgewählte Kreditorennummer verknüpft die Rechnung außerdem mit dem Lieferantendatensatz in Cortena.

Beachten Sie

• Alternative Names ist der wichtigste Stellhebel. Wenn ein Lieferant als „DB Fernverkehr AG“ fakturiert, das Buchhaltungssystem ihn aber „Deutsche Bahn“ nennt, fügen Sie das Alias hinzu, und der Match wird funktionieren.
• Ein Lieferant pro Kontonummer, und jede Zeile benötigt eine Nummer.
• Keine Buchungskonto- oder USt.-Spalten. Die Kontensteuerung gehört in den Chart of Accounts und die Umsatzsteuerlogik in das VAT-Code-Sheet. Eine zusätzliche Spalte, die wie ein Konto aussieht, wird mit der Kreditorennummer verwechselt.
• Das Matching wählt nur einen vorhandenen Kreditor aus. Es fügt diesem Sheet niemals eine Zeile hinzu. Die Erstellung eines fehlenden Kreditors im Buchhaltungssystem erfolgt erst beim Export: DATEV Rechnungswesen verfügt über eine Einstellung zur automatischen Kreditorenanlage, die standardmäßig deaktiviert ist. Auch Twinfield-Exporte versuchen, einen noch nicht vorhandenen Kreditor anzulegen. Keines der Systeme schreibt in dieses Sheet zurück. Neue Lieferanten gelangen über eine aktualisierte Lieferantenliste oder bei Exact-Online- und Twinfield-Mandanten über die tägliche Synchronisierung in das Sheet.

6. Cost Center Allocation

Zweck: die richtige Kostenstelle, in DATEV KOST1 / KOST2 und in Twinfield eine Dimension, einer Rechnung zuzuordnen, damit die Kosten bei der richtigen Abteilung, Person oder dem richtigen Projekt landen.

Was es ist

Ein Google Sheet mit genau vier Spalten: Employee - Cost Center Owner, Type (KOST1 / KOST2), Cost Center number und Cost Center Name. Es führt die Kostenstellen auf, die der Mandant tatsächlich in seiner Buchungshistorie verwendet hat. Wenn der Mandant keine Kostenstellen verwendet, enthält das Sheet nur die Überschriften. Kostenstellen werden niemals erfunden.

Beispielzeile: Jane Doe · KOST1 · 1000 · Marketing

Wie es funktioniert

Der Kostenstellen-Matcher liest das gesamte Sheet, die Buchungshistorie des Lieferanten, die Positionen und die Kontaktpersonen auf der Rechnung. Seine Beweismittel wertet er in dieser Reihenfolge aus:

1. Welcher Kostenstelle dieser Lieferant zuvor zugeordnet wurde.
2. Abteilungs-, Personen- oder Zweckbezeichnungen in den Positionen.
3. Andere Kontakte auf der Rechnung.
4. Kontaktpersonen.

Er läuft parallel zum Buchungskonto-Matching und kennt daher das Buchungskonto nicht. Kostenstellen pro Position können je nach Mandant aktiviert werden.

Beachten Sie

• Namen der Verantwortlichen sind wichtig: Ein Name auf der Rechnung wie „Attn: Jane Doe“ wird mit den Personen im Sheet abgeglichen. Die Anweisungen des Matchers suchen nach Spalten „First name“ und „Last name“, die das Standardsheet nicht enthält. Prüfen Sie deshalb Kostenstellen, die nach Person zugeordnet wurden.
• Eine Regel wie „if account X, then cost center Y“ kann in dieses Sheet übertragen werden, zum Beispiel als zusätzliche Spalte mit Anweisungen oder Anforderungen pro Kostenstelle. Geben Sie der Spalte eine eindeutige Überschrift und beschreiben Sie, was auf der Rechnung sichtbar ist, etwa die Art des Kaufs, den Lieferanten oder die Position, nicht die Kontonummer, da der Matcher nicht weiß, welches Konto ausgewählt wurde.
• Die KI kann gelegentlich einen Code zurückgeben, der nicht im Sheet enthalten ist. Prüfer sollten ungewöhnliche Codes kontrollieren.
• Kostenstellen können pro Mandant mit Deactivate cost centers in Accounting preferences deaktiviert werden. Dadurch wird die Kostenstellenzeile auf der Rechnung ausgeblendet und Kostenstellen werden aus dem Export entfernt. Das Sheet muss dennoch vorhanden sein, da ein fehlendes Cost-Center-Sheet die Verarbeitung stoppt.

Richtlinien und Referenzdaten

Cortena verwendet die vier Sheets, also Chart of Accounts, BU Code, Creditor und Cost Center, auf zwei unterschiedliche Arten:

• Bei jedem Neuaufbau entscheidet eine KI erneut, welche Spalte den Code und welche den Namen enthält. Eine zusätzliche Textspalte kann versehentlich ausgewählt werden. Ihre Werte erscheinen dann bis zum nächsten Neuaufbau in der Auswahl und im Export. Deshalb behalten die Sheets ihre festen Spalten.
• Zusätzliche Spalten werden von der Matching-KI gelesen, da sie das gesamte Sheet liest. Sie werden niemals zu strukturierten Referenzdaten.
• Die Buchhaltungsintegration liefert weiterhin die Stammdaten, wenn Cortena mit ihr synchronisiert wird. Die Richtlinien ergänzen darauf aufbauend die Geschäftslogik: welches Konto zu welcher Positionsart passt, welcher BU-Code zu welcher Situation passt und welche anderen Namen ein Lieferant verwendet.

Wie die Dokumente erstellt werden

• Beim Onboarding erstellt der Cortena-Skill für die Buchhaltung alle sechs Dokumente aus drei Exporten des Mandanten: dem chart of accounts, der creditor/debtor list und der booking history. Es gibt einen Skill für deutsche Mandanten auf DATEV und einen für niederländische Mandanten auf Twinfield oder Exact Online.
• Deutsche Mandanten auf DATEV: Cortena liest die verfügbaren Konten und Lieferanten aus dem Buchhaltungssystem sowie die Buchungshistorie des Mandanten. Die BU-Codes werden aus dieser Buchungshistorie abgeleitet: Das Sheet führt die Codes auf, die der Mandant tatsächlich verwendet hat. Dafür ist eine Verbindung zu DATEV Datenservice Export Rechnungswesen erforderlich.
• Niederländische Mandanten auf Twinfield oder Exact Online: Cortena liest die verfügbaren Konten, USt.-Codes und Lieferanten aus dem Buchhaltungssystem und ergänzt sie mit der Buchungshistorie des Mandanten.
• Nichts wird erfunden. Jedes Konto, jeder BU-Code, jeder Lieferant und jede Kostenstelle lässt sich auf eine Zeile in den eigenen Dateien des Mandanten zurückführen.
• Der Chart of Account Matching Guide und die Completeness Guideline sind bei der Erstellung für jeden Mandanten gleich. Die anderen vier Richtlinien, also die Sheets, sind vollständig mandantenspezifisch.
• Ein in der Anwendung aus einer Vorlage erstellter Mandant erhält Kopien der Vorlagendateien mit denselben Namen. Deutschland (DATEV SKR04) ist die Standardvorlage.

Bei Mandanten, die mit Exact Online oder Twinfield verbunden sind, aktualisiert eine tägliche Synchronisierung die vier Sheets aus dem Buchhaltungssystem. Sie erhält manuell geschriebenen Text, also USE FOR, DO NOT USE IF/FOR und die Marker (Do not use), solange sich der synchronisierte Wert nicht geändert hat. Sie kann dennoch Zellen überschreiben oder den Inhalt von Spalten vertauschen. Twinfield kann außerdem Zeilen löschen, deren Codes in Twinfield nicht mehr existieren, einschließlich manuell hinzugefügter Zeilen. Die beiden Docs werden niemals verändert. Prüfen Sie den Versionsverlauf eines Sheets, bevor Sie davon ausgehen, dass die Hinweise noch vorhanden sind.

Wo gehört eine Korrektur hin?

Wiederkehrende Korrekturen in der Prüfwarteschlange sind das beste Zeichen dafür, dass eine Regel fehlt. Gehen Sie sie wöchentlich durch und korrigieren Sie das Dokument, das der korrigierte Schritt liest. Schreiben Sie Regeln zu dem, was auf der Rechnung sichtbar ist, etwa Lieferantennamen und Positionsbeschreibungen in der gedruckten Form.

Über die sechs Dokumente hinaus: lieferantenspezifische Extraktions-Docs

Wenn die Positionen eines Lieferanten auf jeder Rechnung falsch ausgegeben werden, etwa weil Zeilen fehlen oder zusammengeführt werden, Frachtkosten entfallen oder der Bruttobetrag als Nettobetrag gelesen wird, liegt die Korrektur nicht in den sechs Dokumenten des Mandanten, sondern in einem lieferantenspezifischen Richtlinien-Doc:

• Es ist ein Google Doc in Cortenas zentraler Bibliothek für Lieferantenrichtlinien. Der Titel enthält den Lieferantennamen in Großbuchstaben und ohne Satzzeichen: Aus „Google Ireland Limited“ wird GOOGLE IRELAND LIMITED.
• Für diesen Lieferanten ersetzt es die globalen Extraktionsregeln für Positionen vollständig. Alles aus den globalen Regeln, was weiterhin gelten soll, muss daher ebenfalls darin enthalten sein. Der Chart of Account Matching Guide gilt weiterhin, da er im System-Prompt steht.
• Es gilt für diesen Lieferanten in jedem Mandanten. Die Länderunterordner in der Bibliothek dienen nur der Ablage.
• Es beschreibt das Rechnungslayout des Lieferanten, niemals die Positionen einer einzelnen Rechnung. Der Generator für lieferantenspezifische Richtlinien erstellt einen Entwurf aus einer problematischen Rechnung.

Verwandt: Wie Cortena eine Rechnung liest, Agenten zu Buchungskonten anleiten, Matching-Korrektur.

Kurzreferenz