Elke Cortena-tenant heeft zes richtlijndocumenten in de Google Drive-map. Ze vertellen de AI van Cortena hoe ze de facturen van die klant moet lezen, controleren en boeken: wie de klant is, welke boekingsrekeningen en btw-codes bestaan, bij welke leverancier en kostenplaats een factuur hoort en wanneer een factuur als compleet geldt.
Ze zijn in de eerste plaats geschreven voor een AI-classifier en in de tweede plaats voor mensen. Daarom bestaan de regels uit korte IF/THEN-zinnen die zijn gebaseerd op wat zichtbaar is op de factuur, zoals leverancier, land, btw-id, btw-tarief en regelomschrijving, zonder “meestal” of “in de meeste gevallen”.
Scope: alleen te betalen posten en kosten, zoals leveranciersfacturen, werknemerskosten en activa-aankopen. Vorderingen, loonadministratie, beginbalansen en bankboekingen vallen voor alle zes documenten buiten scope.
De zes documenten in één oogopslag
| # | Document | Type | Welke vraag beantwoordt het? | Gelezen door (pipeline-stap) | Klant- specifiek? |
|---|---|---|---|---|---|
| 1 | Chart of Account Matching Guide | Google Doc | Wie is de klant en welke algemene regels gelden voor elke factuur? | Extractie (systeemprompt) en matching van boekingsrekeningen | Alleen de klantnaam en juridische entiteiten |
| 2 | Chart of Accounts | Google Sheet | Naar welke boekingsrekening gaat deze regel? | Matching van boekingsrekeningen, account-dropdown, export van accountnamen | Volledig |
| 3 | BU Code Matching Guidelines | Google Sheet | Welke btw-behandeling (BU-code) geldt voor deze regel? | Matching van BU-/btw-codes | Volledig (alleen de codes die de klant daadwerkelijk gebruikt) |
| 4 | Invoice Completeness Guideline | Google Doc | Bevat deze factuur elk veld dat wettelijk nodig is? | Compleetheidscontrole | Begint als de Cortena-standaard en kan per klant worden aangepast |
| 5 | Creditor and Debitor Allocation | Google Sheet | Van welke leveranciersrekening (crediteurnummer) komt deze factuur? | Crediteurmatching | Volledig |
| 6 | Cost Center Allocation | Google Sheet | Bij welke kostenplaats (KOST1 / KOST2) hoort deze factuur? | Matching van kostenplaatsen | Volledig, of alleen kopteksten als de klant geen kostenplaatsen heeft |
Hoe de documenten in de pipeline passen
Uit deze afbeelding volgen vier dingen:
- Elke stap ziet alleen zijn eigen document. De BU-code-stap leest nooit de Matching Guide en de compleetheidscontrole leest nooit het Chart of Accounts. Een regel die in het verkeerde document staat, wordt simpelweg genegeerd, ook als de regel voor een menselijke lezer correct lijkt.
- Sheets worden volledig en live gelezen. Elke sheet wordt bij elke run als volledige tabel aan de AI doorgegeven, inclusief alle kolommen en de koptekstrij. Een wijziging geldt vanaf de volgende factuur; opnieuw synchroniseren is niet nodig. Gebruik één tabblad per sheet, omdat er geen instelling is waarmee je kiest welk tabblad wordt gelezen.
- Sommige documenten zijn verplicht. Als de Matching Guide, het Chart of Accounts, het BU Code-blad, de Completeness Guideline of het Cost Center-blad niet kan worden gevonden, mislukt de verwerking. Een ontbrekend Creditor-blad zorgt ervoor dat de verwerking stilzwijgend doorgaat: de crediteur valt terug op het crediteurnummer van de hoofdleverancier of blijft leeg.
- Wijzigingen gelden alleen voor de toekomst. De documenten worden automatisch toegepast op elke factuur die wordt verwerkt en op elke factuur die opnieuw wordt verwerkt. Facturen die al zijn verwerkt, behouden hun resultaten totdat ze opnieuw worden verwerkt of handmatig worden bewerkt. Opnieuw verwerken voert extractie en matching opnieuw uit en vervangt handmatige boekingswijzigingen op die factuur. Controleer bewerkte facturen daarom daarna opnieuw.
Waar je ze in Cortena vindt
Open Settings → Accounting preferences → Matching Guidelines & Instructions voor de tenant. Je ziet daar:
- een link om de Google Drive-map van de tenant te openen;
- één kaart per document met een korte beschrijving, het tijdstip van de laatste update en het Drive-versienummer, zodat je kunt zien wanneer een bestand voor het laatst is gewijzigd;
- een knop Refresh master list voor beheerders. Totdat de masterlijst bestaat, toont deze sectie “No master definitions yet” in plaats van de kaarten. Een beheerder kan de lijst met deze knop opbouwen; anders gebeurt dat tijdens de dagelijkse synchronisatie;
- een knop Synchronise reference data waarmee je de referentiegegevens handmatig opnieuw opbouwt vanuit de sheets (zie Richtlijnen en referentiegegevens hieronder).
Als de kaarten ontbreken, is de masterlijst nog niet opgebouwd of is de functie niet ingeschakeld voor die tenant.
De lijst toont ook Booking History: een optionele sheet met eerdere boekingen die de matchers voor boekingsrekeningen en kostenplaatsen als historie gebruiken. Deze sheet is geen onderdeel van de zes richtlijndocumenten en de verwerking gaat zonder deze sheet door.
Toegang: Cortena leest de bestanden via het Google-serviceaccount pre-accounting-upload@cortena-main.iam.gserviceaccount.com. Elk bestand dat Cortena moet gebruiken, moet met dat account zijn gedeeld. Wanneer een klant een eigen kopie van een bestand toevoegt, moet je die dus met het account delen. Leestoegang is voldoende voor de verwerking. Een sheet die door een synchronisatie vanuit het boekhoudsysteem wordt overschreven, heeft Editor-toegang nodig.
Bestandsnamen vormen de koppeling
De Drive-map van de tenant is gekoppeld via een ID, maar elk document daarin wordt op naam gevonden, via een overeenkomst waarbij de naam de opgegeven tekst bevat. De onderstaande namen moeten teken voor teken worden gebruikt:
| Exacte bestandsnaam | Type |
|---|---|
Chart of Account Matching Guide (ook geaccepteerd: Extraction and Matching Guidelines) | Google Doc |
Chart of Accounts | Google Sheet |
BU Code Matching Guidelines (ook geaccepteerd: VAT Code Matching Guidelines) | Google Sheet |
Invoice Completeness Guideline | Google Doc |
Creditor and Debitor Allocation | Google Sheet |
Cost Center Allocation | Google Sheet |
- Iets aan een naam toevoegen is veilig (“Chart of Accounts (2026)”). De naam wijzigen is dat niet (“CoA”, “Chart of Account”, “Chart_of_Accounts”).
- Bewaar nooit een oude kopie naast de nieuwe. “Chart of Accounts OLD” wordt ook gevonden en Cortena kiest dan willekeurig een van de twee. Verplaats oude versies in plaats daarvan naar een submap; submappen worden niet doorzocht.
- Elk documenttype kan ook naar een eigen map verwijzen en één entiteit kan het bestand van een andere entiteit gebruiken in plaats van het eigen bestand. Zo kunnen dochterondernemingen bijvoorbeeld allemaal het Chart of Accounts van de moedermaatschappij lezen. Een wijziging in een gedeeld bestand verandert dan de matching voor elke entiteit die het gebruikt.
1. Chart of Account Matching Guide
Doel: de AI vertellen wie de klant is, zodat de klant altijd wordt herkend als de ontvanger van een factuur, nooit als de leverancier, onder elke juridische naam die de klant gebruikt.
Wat het is
Een korte Google Doc. Voor Duitse klanten is het de goedgekeurde Cortena-template, ongewijzigd gekopieerd met alleen {CLIENT_NAME} ingevuld. Het document heeft twee secties:
- A. General rules: één 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: één opsommingsteken per juridische entiteit waaronder de klant factureert, bijvoorbeeld een GmbH en de handelsnaam daarvan. Een factuur die aan een van deze entiteiten is gericht, geldt als een factuur aan de klant.
Hoe het werkt
- Het document wordt ingevoegd als de systeemprompt van de extractiestap, zowel voor factuurgegevens als voor factuurregels. Daardoor weegt het zwaarder dan de algemene extractieregels en de leveranciersspecifieke documenten, die in de user prompt staan.
- Het is ook de eerste bron die de matcher voor boekingsrekeningen leest. Een regel die hier als STOP is gemarkeerd, overschrijft de boekingshistorie en al het andere. De standaardtemplate bevat bewust geen dergelijke regel.
- De BU-code-stap, de compleetheidscontrole, de crediteur-stap en de kostenplaats-stap lezen dit document niet.
Houd rekening met het volgende
- Houd het document minimaal. Omdat het in de extractiesysteemprompt staat, kan één losse zin de extractie van elke factuur veranderen. Een echt voorbeeld: een regel als “skip rows in the totals block” zorgde ervoor dat verzendkosten uit de factuurregels werden weggelaten.
- Voeg niets klantspecifieks toe behalve de naam en entiteiten: geen btw- of verleggingsregels, geen doorbelastingsregels, geen leverancierslijsten, geen rekeningnummers en geen BU-codes. Accountlogica hoort in het Chart of Accounts en btw-logica in het BU Code-blad.
- Dit geldt ook voor leveranciers-naar-accountregels, zoals “all items from Supplier X go to 4400”. In dit document zou zo’n regel in de extractieprompt van elke factuur staan. Als de regel als STOP-regel wordt geschreven, overschrijft hij voor elke regel de boekingshistorie. Zet leveranciersroutering in het Chart of Accounts: vermeld de leverancier onder Good Examples bij de juiste rekening of voeg een routeringszin toe onder DO NOT USE IF/FOR.
- Als de klant onder een nieuwe juridische naam begint te factureren, voeg je een opsommingsteken toe aan sectie B.
Zie voor de schrijfstijl van de Matching Guide en het chart sheet ook Agents instrueren over boekingsrekeningen.
2. Chart of Accounts
Doel: de lijst met toegestane boekingsrekeningen voor deze klant, plus uitleg in gewone taal over wat op elke rekening hoort. Dit is de bron van waarheid voor de boekingsrekening op elke factuurregel.
Wat het is
Een Google Sheet met één rij per rekening in het rekeningschema van de klant (DATEV Kontenplan, Twinfield / Exact Grootboekrekeningen) en precies vijf kolommen:
| Column | What goes in it |
|---|---|
| Booking Account | Het rekeningnummer exact zoals in het rekeningschema van de klant, opgeslagen als tekst (voorloopnullen blijven behouden). |
| Booking Account Name | De rekeningnaam exact zoals in het boekhoudsysteem, niet vertaald of bewerkt. |
| USE FOR | Eén of twee zinnen in gewone taal over het soort factuurregel dat hier thuishoort. Niet-betalingsrekeningen bevatten exact (Do not use). |
| DO NOT USE IF/FOR | Alleen wanneer twee rekeningen concurreren voor hetzelfde soort regel: Route <signal> to <account number>. Vaak leeg, wat prima is. |
| Good Examples | Alleen positieve voorbeelden, als Typical purchases: … en `Suppliers: A |
Rijen zijn verdeeld over drie niveaus:
- Tier 1: betalingsrekeningen waarop de klant daadwerkelijk heeft geboekt. Alle begeleidingskolommen zijn ingevuld op basis van de boekingshistorie.
- Tier 2: betalingsrekeningen waarop nog niet is geboekt. Alleen de naam is ingevuld; de begeleidingskolommen zijn leeg.
- Tier 3: rekeningen die niet voor betalingen zijn bedoeld, zoals bank, btw, eigen vermogen, omzet en vorderingen. USE FOR =
(Do not use).
Voorbeeld van een Tier 1-rij: 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”.
Hoe het werkt
De matcher voor boekingsrekeningen draait één keer per factuurregel en werkt de bronnen in deze volgorde af:
- De Chart of Account Matching Guide (eventuele STOP-regels).
- De boekingshistorie: hoe de regels van deze leverancier eerder zijn geboekt.
- Het Chart of Accounts: eerst Good Examples, daarna USE FOR en vervolgens de accountnaam.
- Geen duidelijke match: de rekening blijft leeg voor controle.
Booking Account Learned Guidelines, regels die Cortena leert van correcties door gebruikers, worden als aanvulling toegevoegd. Er worden vijf runs uitgevoerd en minstens drie moeten het met elkaar eens zijn. Nadat alle regels zijn gematcht, controleert een tweede pass het resultaat en vult lege regels aan vanuit vergelijkbare regels op dezelfde factuur wanneer dat logisch is. Zie Matching corrigeren en Matching leert van je correcties.
De sheet voedt ook Cortena’s referentiegegevens: de account-dropdown in de app en de accountnaam die met de export wordt meegestuurd.
Houd rekening met het volgende
(Do not use)is de belangrijkste beveiliging die voorkomt dat de AI een leveranciersfactuur op een bank-, btw- of eigenvermogensrekening boekt. Laat dit op elke Tier 3-rij staan.- De boekingshistorie weegt zwaarder dan gewone USE FOR-tekst. Als een bepaald type regel vanuit de historie steeds de verkeerde rekening overneemt, gebruik dan een routeringszin onder DO NOT USE IF/FOR.
- Gebruik geen dubbele rekeningnummers: een regel die verwijst naar een nummer dat twee keer voorkomt, is dubbelzinnig.
- Voeg geen extra tekstkolommen toe. De synchronisatie van referentiegegevens gebruikt AI om telkens te bepalen welke kolom de accountnaam bevat wanneer een richtlijndocument verandert. Een extra kolom kan per ongeluk worden gekozen. Het verkeerde label verschijnt dan in de dropdown en in de export.
3. (VAT) BU Code Matching Guidelines
Doel: de lijst met btw-behandelingen die deze klant gebruikt, met één duidelijke trigger per code, zodat elke factuurregel de belastingcode krijgt waarmee het boekhoudsysteem de btw correct verwerkt.
Wat het is
Een Google Sheet met precies drie kolommen: BU Code, Description en Tax Rate / VAT Rate. Er is één rij per BU-code die de klant daadwerkelijk in de boekingshistorie heeft gebruikt, nooit de volledige DATEV-catalogus. Elke extra rij biedt een extra kans op een verkeerde keuze. Voor Nederlandse klanten bevat dezelfde sheet de btw-codes uit het boekhoudsysteem.
| BU Code | Description | Tax Rate / VAT Rate |
|---|---|---|
| (left empty) | If the invoice recipient is incomplete. BU-Code is empty | 0% |
| 8 | If the invoice is complete and German 7% VAT is stated. | 7% |
| 9 | If the invoice is complete and German 19% VAT is stated. | 19% |
| 19 | If the invoice is complete, the item is goods, the supplier has a non-DE but EU VAT-ID, and no VAT is charged because the supply is an intra-community supply. | 0% |
| 94 | If the invoice is complete, no VAT is charged, the invoice is a service from a company based outside Germany, or the invoice states ‘Reverse Charge’ or ‘Steuerschuldnerschaft des Leistungsempfängers’. | 0% |
| 490 | If the invoice is complete but input VAT is non-deductible. | 0% |
Hoe het werkt
- De BU-code-matcher draait één keer per factuurregel, parallel aan de matcher voor boekingsrekeningen. Hij leest deze sheet, de BU Code Learned Guidelines, de geëxtraheerde factuurgegevens (land van leverancier en ontvanger, btw-id’s) en het btw-tarief van de regel. Er worden drie runs uitgevoerd en minstens twee moeten het met elkaar eens zijn.
- Hij matcht het btw-tarief op de regel exact met de tariefkolom. Daarom bevat de tariefkolom het tarief dat op de factuur staat, niet het interne tarief van DATEV: verlegging (§13b), intracommunautaire verwerving (§1a), BU 490 en de lege code zijn allemaal
0%, omdat op deze facturen geen Duitse btw staat en DATEV de belasting zelf berekent aan de hand van de code. - De matcher ziet nooit de boekingsrekening en leest de Matching Guide niet.
- De stap heeft ook enkele ingebouwde eigen regels. Een voorbeeld voor Duitse klanten: als de ontvanger van de factuur geen Duitse entiteit is, retourneert de stap geen BU-code.
Houd rekening met het volgende
- Elke Description is één gewone IF-zin over dingen die zichtbaar zijn op de factuur. Geen wetsverwijzingen, rekeningnummers of lijsten met voorbeelden.
- BU 8 en 9 zijn vergrendeld. De formulering en het tarief zijn voor elke klant gelijk en worden nooit bewerkt.
- Een regel als “if account X, then BU code Y” kan niet werken, omdat deze stap de rekening niet kent.
- Een regel zonder geëxtraheerd btw-tarief krijgt meestal geen BU-code. Controleer eerst de extractie.
- Om een verkeerde BU-code te corrigeren, bewerk je deze sheet. Het bewerken van de Matching Guide heeft geen effect op BU-codes.
4. Invoice Completeness Guideline
Doel: bepalen of een factuur elk veld bevat dat wettelijk nodig is (UStG §14) om de voorbelasting aftrekbaar te maken. Onvolledige facturen gaan naar handmatige controle in plaats van rechtstreeks naar de boeking.
Wat het is
Een Google Doc die begint met de Cortena-standaard voor het land van de klant, met een Duitse en een Nederlandse versie. Het document heeft meestal drie secties, ingedeeld naar het land waar de leverancier is gevestigd, omdat dat bepaalt welke btw-gegevens een factuur moet bevatten. In de Duitse versie:
- A. Invoices from German suppliers
- B. Invoices from non-EU suppliers
- C. Invoices from EU suppliers outside Germany
De vereisten in elke sectie zijn flexibel en kunnen per klant worden aangepast: een veld kan worden toegevoegd, verwijderd of voorwaardelijk worden gemaakt, bijvoorbeeld om een leverancier te accepteren die nooit een vermelding van verleggingsregeling afdrukt.
Hoe het werkt
De compleetheidscontrole leest alleen dit document en de geëxtraheerde factuurgegevens. De controle ziet de pdf, de Matching Guide en geen enkele sheet. De controle schrijft “complete: yes / no” met een reden en de workflow stuurt elke “no” naar Require Manual Review.
Houd rekening met het volgende
- Vraag alleen om velden die de extractie daadwerkelijk vastlegt: namen, adressen, btw-id’s, datums, factuurregels, btw-tarieven en bedragen en de vlag voor verleggingsregeling. Een vereiste die de controle niet kan zien, zoals het belastbare bedrag per btw-tarief of specifieke vrijstellingstekst, leidt tot onterechte markeringen als “incomplete”.
- Als een tenant een uitzondering nodig heeft, bijvoorbeeld voor een leverancier die nooit een vermelding van verleggingsregeling afdrukt, is dit de enige plek waar dat werkt. Beperk de uitzondering tot iets in de geëxtraheerde gegevens, zoals het btw-id van de leverancier. Omdat dit een Doc is, overschrijven synchronisaties vanuit het boekhoudsysteem het document nooit.
5. Creditor and Debitor Allocation
Doel: de leveranciersstamgegevens. Het document beantwoordt één vraag: van welke crediteurrekening, oftewel subadministratie van de leverancier, komt deze factuur en onder welke andere namen komt die leverancier voor?
Wat het is
Een Google Sheet met precies drie kolommen, één rij per leverancier uit de leverancierslijst van de klant (DATEV Kreditorenliste, Crediteurenlijst):
- Account number: het crediteurnummer, als tekst.
- Name: de leveranciersnaam zoals die in het boekhoudsysteem staat.
- Alternative Names: andere schrijfwijzen, korte namen of handelsnamen. Leeg als die er niet zijn.
Als de klant geen leverancierslijst kan leveren, wordt de sheet opgebouwd uit de crediteurnummers in de boekingshistorie, waarbij Name en Alternative Names leeg blijven. Namen worden nooit geraden.
Hoe het werkt
- Een filter maakt een shortlist van rijen die lijken op de geëxtraheerde leveranciersnaam. Het filter doorzoekt elke kolom, inclusief Alternative Names.
- De AI kiest één crediteurnummer uit die shortlist. De AI ziet alleen de leveranciersnaam en de shortlist.
- Geen overtuigende match: Cortena gebruikt het crediteurnummer dat op de gekoppelde hoofdleverancier is opgeslagen, als dat er is. Anders blijft de crediteur leeg voor de beoordelaar.
Het gekozen crediteurnummer koppelt de factuur ook aan de leveranciersregistratie in Cortena.
Houd rekening met het volgende
- Alternative Names is de belangrijkste knop waaraan je kunt draaien. Als een leverancier factureert als “DB Fernverkehr AG”, maar het boekhoudsysteem de naam “Deutsche Bahn” gebruikt, voeg je de alias toe en wordt de leverancier gematcht.
- Eén leverancier per rekeningnummer en elke rij heeft een nummer nodig.
- Voeg geen kolommen voor boekingsrekeningen of btw toe. Accountroutering hoort in het Chart of Accounts en btw-logica in het VAT Code-blad. Een extra kolom die op een rekening lijkt, wordt verward met het crediteurnummer.
- Matching kiest alleen een bestaande crediteur; er wordt nooit een rij aan deze sheet toegevoegd. Een ontbrekende crediteur aanmaken in het boekhoudsysteem gebeurt alleen bij de export: DATEV Rechnungswesen heeft een instelling voor het automatisch aanmaken van crediteuren, die standaard uitstaat, en Twinfield-exports proberen ook een nog niet bestaande crediteur aan te maken. Geen van beide schrijft terug naar deze sheet. Nieuwe leveranciers komen in de sheet via een bijgewerkte leverancierslijst of, voor Exact Online- en Twinfield-tenants, via de dagelijkse synchronisatie.
6. Cost Center Allocation
Doel: de juiste kostenplaats toewijzen, KOST1 / KOST2 in DATEV of een dimensie in Twinfield, zodat kosten op de juiste afdeling, persoon of het juiste project terechtkomen.
Wat het is
Een Google Sheet met precies vier kolommen: Employee - Cost Center Owner, Type (KOST1 / KOST2), Cost Center number en Cost Center Name. De sheet bevat de kostenplaatsen die de klant daadwerkelijk in de boekingshistorie heeft gebruikt. Als de klant geen kostenplaatsen gebruikt, bevat de sheet alleen kopteksten; kostenplaatsen worden nooit verzonnen.
Voorbeeldrij: Jane Doe · KOST1 · 1000 · Marketing
Hoe het werkt
De kostenplaatsmatcher leest de volledige sheet, de boekingshistorie van de leverancier, de factuurregels en de contactpersonen op de factuur. De volgorde van het bewijs is:
- Aan welke kostenplaats deze leverancier eerder is geboekt.
- Namen van afdelingen, personen of doelen in de factuurregels.
- Andere contactpersonen op de factuur.
- Contactpersonen.
De matcher draait parallel aan de matching van boekingsrekeningen en kent de gekozen boekingsrekening dus niet. Kostenplaatsen per factuurregel zijn een optie die per tenant kan worden ingeschakeld.
Houd rekening met het volgende
- Namen van eigenaren zijn belangrijk: een naam op de factuur, zoals “Attn: Jane Doe”, wordt gematcht met de personen in de sheet. De instructies van de matcher zoeken naar kolommen “First name” en “Last name”, maar de standaardsheet heeft die niet. Controleer daarom kostenplaatsen die op basis van een persoon zijn toegewezen.
- Een regel als “if account X, then cost center Y” kan in deze sheet worden vertaald, bijvoorbeeld als extra kolom met instructies of vereisten per kostenplaats. Geef de kolom een duidelijke koptekst en beschrijf wat zichtbaar is op de factuur, zoals het soort aankoop, de leverancier of de regel, in plaats van het rekeningnummer. De matcher weet namelijk niet welke rekening is gekozen.
- De AI kan soms een code retourneren die niet in de sheet staat. Beoordelaars moeten ongebruikelijke codes controleren.
- Kostenplaatsen kunnen per tenant worden uitgeschakeld met Deactivate cost centers in Accounting preferences. Hierdoor wordt de kostenplaatsregel op de factuur verborgen en worden kostenplaatsen niet in de export opgenomen. De sheet moet nog steeds bestaan, want een ontbrekende Cost Center-sheet stopt de verwerking.
Richtlijnen en referentiegegevens
Cortena gebruikt de vier sheets, Chart of Accounts, BU Code, Creditor en Cost Center, op twee verschillende manieren:
| Als richtlijn | Als referentiegegevens | |
|---|---|---|
| Wat het is | De sheet zelf, volledig gelezen: elke kolom, inclusief de koptekstrij | Een gestructureerde lijst die Cortena uit de sheet opbouwt: code en naam (voor BU-codes ook beschrijving en tarief) |
| Gebruikt door | De AI-matchingstappen | De keuzelijsten in de app, zoals de dropdowns voor boekingsrekeningen en kostenplaatsen, en de accountnaam die met de export wordt meegestuurd |
| Wanneer het wordt bijgewerkt | Live: een wijziging geldt vanaf de volgende factuur | Automatisch opnieuw opgebouwd wanneer een richtlijndocument in de tenant verandert (alle vier lijsten tegelijk), of handmatig met Synchronise reference data in Settings |
- Bij elke nieuwe opbouw bepaalt een AI opnieuw welke kolom de code bevat en welke de naam. Een extra tekstkolom kan per ongeluk worden gekozen. De waarden daarvan verschijnen dan in de dropdown en de export totdat de volgende opbouw plaatsvindt. Daarom hebben de sheets vaste kolommen.
- Extra kolommen worden wel aan de matching-AI doorgegeven, omdat die de volledige sheet leest. Ze worden nooit gestructureerde referentiegegevens.
- De boekhoudintegratie levert nog steeds de stamgegevens wanneer Cortena ermee synchroniseert. De richtlijnen voegen daar de bedrijfslogica aan toe: welke rekening bij welk soort regel past, welke BU-code bij welke situatie past en welke andere namen een leverancier gebruikt.
Hoe de documenten worden aangemaakt
- Tijdens de onboarding genereert de boekhoudconfiguratievaardigheid van Cortena alle zes documenten uit drie exports van de klant: het rekeningschema, de crediteuren-/debiteurenlijst en de boekingshistorie. Er is één vaardigheid voor Duitse klanten op DATEV en één voor Nederlandse klanten op Twinfield of Exact Online.
- Duitse klanten op DATEV: Cortena leest de beschikbare rekeningen en leveranciers uit het boekhoudsysteem, samen met de boekingshistorie van de klant. De BU-codes worden afgeleid uit die boekingshistorie: de sheet bevat de codes die de klant daadwerkelijk heeft gebruikt. Hiervoor is een verbinding met DATEV Datenservice Export Rechnungswesen nodig.
- Nederlandse klanten op Twinfield of Exact Online: Cortena leest de beschikbare rekeningen, btw-codes en leveranciers uit het boekhoudsysteem en verrijkt deze gegevens met de boekingshistorie van de klant.
- Er wordt niets verzonnen. Elke rekening, BU-code, leverancier en kostenplaats is terug te voeren op een rij in de eigen bestanden van de klant.
- De Chart of Account Matching Guide en de Completeness Guideline zijn bij het aanmaken hetzelfde voor elke klant. De andere vier richtlijnen, de sheets, zijn volledig klantspecifiek.
- Een tenant die vanuit een template in de app wordt aangemaakt, krijgt kopieën van de templatebestanden met dezelfde namen. Duitsland (DATEV SKR04) is de standaardtemplate.
Voor tenants die met Exact Online of Twinfield zijn verbonden, werkt een dagelijkse synchronisatie de vier sheets bij vanuit het boekhoudsysteem. Handgeschreven tekst, zoals USE FOR, DO NOT USE IF/FOR en de markeringen (Do not use), blijft behouden wanneer de gesynchroniseerde waarde niet is veranderd. De synchronisatie kan nog steeds cellen overschrijven of de inhoud van kolommen verwisselen. Twinfield kan bovendien rijen verwijderen waarvan de codes niet langer in Twinfield bestaan, ook rijen die handmatig zijn toegevoegd. De twee Docs worden nooit aangepast. Controleer de versiegeschiedenis van een sheet voordat je ervan uitgaat dat de richtlijnen er nog in staan.
Waar hoort een correctie thuis?
Terugkerende correcties in de controlewachtrij zijn het beste signaal dat er een regel ontbreekt. Loop deze wekelijks door en herstel het document dat door de gecorrigeerde stap wordt gelezen. Schrijf regels rond wat zichtbaar is op de factuur: leveranciersnamen en regelomschrijvingen zoals ze zijn afgedrukt.
| Probleem | Bewerk dit | Dit bewerken doet niets |
|---|---|---|
| Verkeerde boekingsrekening voor een bepaald type regel | Chart of Accounts (USE FOR, DO NOT USE IF/FOR, Good Examples) | Creditor-sheet |
| Verkeerde BU-/btw-code | BU Code Matching Guidelines | Chart of Account Matching Guide |
| Factuur ten onrechte gemarkeerd als onvolledig | Invoice Completeness Guideline | Chart of Account Matching Guide |
| Leverancier niet herkend of verkeerde crediteur | Creditor and Debitor Allocation (voeg een Alternative Name toe) | Chart of Accounts |
| Verkeerde of ontbrekende kostenplaats | Cost Center Allocation (namen van eigenaren, namen van kostenplaatsen) | Chart of Accounts |
| Klant niet herkend als ontvanger of nieuwe juridische entiteit | Chart of Account Matching Guide, sectie B | Elke sheet |
| Factuurregels van één leverancier verkeerd geëxtraheerd | Een leveranciersspecifiek richtlijndocument (zie hieronder) | Geen van de zes |
Naast de zes: leveranciersspecifieke extractiedocumenten
Wanneer de factuurregels van één leverancier op elke factuur verkeerd worden verwerkt, bijvoorbeeld doordat regels worden gemist of samengevoegd, vrachtkosten wegvallen of bruto als netto wordt gelezen, ligt de oplossing niet in de zes documenten van de tenant maar in een leveranciersspecifiek richtlijndocument:
- Het is een Google Doc in de centrale leveranciersrichtlijnenbibliotheek van Cortena, met de leveranciersnaam in hoofdletters en zonder leestekens als titel. “Google Ireland Limited” wordt
GOOGLE IRELAND LIMITED. - Voor die leverancier vervangt het document de algemene extractieregels voor factuurregels volledig. Alles uit de algemene regels dat nog steeds van toepassing moet zijn, moet er dus ook in staan. De Chart of Account Matching Guide blijft van toepassing, omdat die in de systeemprompt staat.
- Het document geldt voor die leverancier in elke tenant. De submappen per land zijn alleen bedoeld voor ordening.
- Het beschrijft de lay-out van de facturen van de leverancier, nooit de items van één specifieke factuur. De generator voor leveranciersspecifieke richtlijnen maakt een eerste versie op basis van een probleemfactuur.
Gerelateerd: Hoe Cortena een factuur leest, Agents instrueren over boekingsrekeningen, Matching corrigeren.
Snel overzicht
| Taak | Waar |
|---|---|
| De documenten openen | Settings → Accounting preferences → Matching Guidelines & Instructions, of de Drive-maplink daar |
| Regels bewerken | De Google Doc of Sheet zelf, in de Drive-map van de tenant |
| De dropdowns bijwerken na een wijziging in een sheet | Automatisch, of Synchronise reference data in Settings |
| Een wijziging toepassen op al verwerkte facturen | Reprocess de factuur of bewerk de factuur handmatig in de factuurdetails |
| Eerste configuratie | Maak de tenant aan vanuit een template of genereer de zes documenten met de onboardingvaardigheid, behoud de exacte bestandsnamen en deel de bestanden met het Cortena-serviceaccount |
| Bepalen welk document je moet aanpassen | Waar hoort een correctie thuis? |