Matching guidelines

Every Cortena tenant has six guideline documents in its Google Drive folder. They tell Cortena’s AI how to read, check, and book that client’s invoices: who the client is, which booking accounts and VAT codes exist, which supplier and cost center an invoice belongs to, and when an invoice counts as complete.

They are written for an AI classifier first and for humans second. That is why the rules are short IF/THEN sentences built on things that are visible on the invoice (supplier, country, VAT ID, VAT rate, line description), with no “usually” or “in most cases”.

Scope: payables and expenses only (supplier invoices, employee expenses, asset purchases). Receivables, payroll, opening balances, and bank postings are out of scope for all six documents.

The six documents at a glance

How the documents fit into the pipeline

Click to enlarge

Four things follow from this picture:

• Each step only sees its own document. The BU code step never reads the Matching Guide, and the completeness check never reads the Chart of Accounts. A rule written into the wrong document is simply ignored, even if it looks correct to a human reader.
• Sheets are read whole and live. Each sheet is passed to the AI as a full table (every column, header row included) on every run. An edit counts from the next invoice; no re-sync is needed. Keep one tab per sheet, because there is no setting that chooses which tab is read.
• Some documents are required. If the Matching Guide, Chart of Accounts, BU Code sheet, Completeness Guideline, or Cost Center sheet cannot be found, processing fails. A missing Creditor sheet fails silently: the creditor falls back to the master supplier’s creditor number, or stays empty.
• Changes only apply going forward. The documents are applied automatically to every invoice that is processed, and to every invoice that is reprocessed. Invoices that were already processed keep their results until they are reprocessed or edited by hand. Reprocessing re-runs extraction and matching and replaces manual booking edits on that invoice, so check edited invoices again afterwards.

Where to find them in Cortena

Open Settings → Accounting preferences → Matching Guidelines & Instructions for the tenant. It shows:

• a link to open the tenant’s Google Drive folder,
• one card per document with a short description, the time of the last update, and the Drive version number, so you can see when a file last changed,
• a Refresh master list button for admins. Until the master list exists, the section shows “No master definitions yet” instead of the cards. An admin can build it with this button; otherwise the daily sync does,
• a Synchronise reference data button that rebuilds the reference data from the sheets by hand (see Guidelines and reference data below).

If the cards are missing, the master list has not been built yet, or the feature is not switched on for that tenant.

Click to enlarge

The list also shows Booking History: an optional sheet of past bookings that the booking-account and cost center matchers use as history. It is not one of the six guideline documents, and processing carries on without it.

Access: Cortena reads the files through the Google service account pre-accounting-upload@cortena-main.iam.gserviceaccount.com. Every file Cortena should use must be shared with that account, so when a client brings in their own copy of a file, share it with the account. Read access is enough for processing. A sheet that is rewritten by a sync from the accounting system needs Editor access.

Click to enlarge

File names are the link

The tenant’s Drive folder is linked by ID, but each document inside it is found by name (a “contains” match). The names below must be used character for character:

• Adding to a name is safe (“Chart of Accounts (2026)”). Changing it is not (“CoA”, “Chart of Account”, “Chart_of_Accounts”).
• Never keep an old copy next to the new one. “Chart of Accounts OLD” also matches, and Cortena then picks one of the two at random. Move old versions into a subfolder instead; subfolders are not searched.
• Each document type can also point to its own folder, and one entity can use another entity’s file instead of its own, for example subsidiaries that all read the parent company’s Chart of Accounts. An edit to a shared file then changes matching for every entity that uses it.

1. Chart of Account Matching Guide

Purpose: tell the AI who the client is, so it always recognises the client as the recipient of an invoice (never as the supplier) under every legal name the client uses.

What it is

A short Google Doc. For German clients it is the approved Cortena template, copied unchanged with only {CLIENT_NAME} filled in. It has two sections:

• A. General rules: one rule. “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: one bullet per legal entity the client invoices under (for example a GmbH and its trading name). An invoice addressed to any of them counts as addressed to the client.

How it works

• It is injected as the system prompt of the extraction step, both for invoice data and for line items. This gives it more weight than the global extraction rules and the supplier-specific documents, which sit in the user prompt.
• It is also the first source the booking-account matcher reads. A rule here marked as STOP would override booking history and everything else. The standard template deliberately has no such rule.
• The BU code step, the completeness check, the creditor step, and the cost center step do not read it.

Keep in mind

• Keep it minimal. Because it sits in the extraction system prompt, one stray sentence can change how every invoice is extracted. A real example: a line like “skip rows in the totals block” caused shipping costs to be dropped from line items.
• Nothing client-specific beyond the name and entities: no VAT or reverse-charge rules, no recharge rules, no supplier lists, no account numbers, no BU codes. Account logic goes into the Chart of Accounts, VAT logic into the BU Code sheet.
• That includes supplier-to-account rules such as “all items from Supplier X go to 4400”. In this document such a rule would sit in the extraction prompt of every invoice, and written as a STOP rule it would override booking history for every line. Put supplier routing in the Chart of Accounts instead: list the supplier under Good Examples on the right account, or add a DO NOT USE IF/FOR routing sentence.
• If the client starts invoicing under a new legal name, add a bullet to section B.

For writing style on the Matching Guide and chart sheet, see also Instructing agents on booking accounts.

2. Chart of Accounts

Purpose: the allow-list of booking accounts for this client, plus plain-language guidance on what belongs on each account. It is the source of truth for the booking account on every line item.

What it is

A Google Sheet with one row per account in the client’s chart of accounts (DATEV Kontenplan, Twinfield / Exact Grootboekrekeningen) and exactly five columns:

Rows come in three tiers:

• Tier 1: payables accounts the client has actually booked on. All guidance columns are filled from the booking history.
• Tier 2: payables accounts with no bookings yet. Name only, guidance columns empty.
• Tier 3: accounts that are not for payables (bank, VAT, equity, revenue, receivables, and so on). USE FOR = (Do not use).

Example Tier 1 row: 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”.

How it works

The booking-account matcher runs once per line item and works through its sources in this order:

1. The Chart of Account Matching Guide (STOP rules, if any).
2. The booking history: how this supplier’s lines were booked before.
3. The Chart of Accounts: Good Examples first, then USE FOR, then the account name.
4. No clear match: the account stays empty for review.

Booking Account Learned Guidelines (rules Cortena learns from user corrections) are added as a supplement. Five runs are made and at least three must agree. After all lines are matched, a second pass checks the result and fills empty lines from sibling lines on the same invoice where that makes sense. See Matching correction and Matching learns from your corrections.

The sheet also feeds Cortena’s reference data: the account dropdown in the app and the account name sent with the export.

Keep in mind

• (Do not use) is the main guard that keeps the AI from booking a supplier invoice to a bank, VAT, or equity account. Keep it on every Tier 3 row.
• Booking history beats plain USE FOR text. If a type of line keeps inheriting the wrong account from history, use a DO NOT USE IF/FOR routing sentence.
• No duplicate account numbers: a rule pointing at a number that appears twice is ambiguous.
• Do not add extra text columns. The reference-data sync uses AI to pick which column holds the account name, every time any guideline file changes, and an extra column can be picked by mistake. The wrong label then appears in the dropdown and in the export.

3. (VAT) BU Code Matching Guidelines

Purpose: the allow-list of VAT treatments this client uses, with one clear trigger per code, so that every line item gets the tax key that makes the accounting system post VAT correctly.

What it is

A Google Sheet with exactly three columns: BU Code, Description, and Tax Rate / VAT Rate. It has one row per BU code the client has actually used in its booking history, and never the full DATEV catalogue. Every extra row is a chance for a wrong pick. For Dutch clients the same sheet holds the BTW / VAT codes from the accounting system.

How it works

• The BU code matcher runs once per line item, in parallel with the booking-account matcher. It reads this sheet, the BU Code Learned Guidelines, the extracted invoice data (supplier and recipient country, VAT IDs), and the line’s VAT rate. Three runs are made and at least two must agree.
• It matches the VAT rate on the line exactly against the rate column. That is why the rate column holds the rate printed on the invoice, not DATEV’s internal rate: reverse-charge (§13b), intra-EU acquisition (§1a), BU 490, and the empty code are all 0%, because those invoices show no German VAT and DATEV calculates the tax from the key itself.
• It never sees the booking account and never reads the Matching Guide.
• The step also has a few built-in rules of its own. One example, for German customers: if the invoice recipient is not a German entity, it returns no BU code.

Keep in mind

• Each Description is one plain IF sentence about things visible on the invoice. No statute citations, no account numbers, no example lists.
• BU 8 and 9 are locked. Their wording and rate are the same for every client and are never edited.
• A rule like “if account X, then BU code Y” cannot work, because this step does not know the account.
• A line without an extracted VAT rate usually gets no BU code. Check extraction first.
• To fix a wrong BU code, edit this sheet. Editing the Matching Guide has no effect on BU codes.

4. Invoice Completeness Guideline

Purpose: decide whether an invoice carries every field it legally needs (UStG §14) for input VAT to be recoverable. Incomplete invoices go to manual review instead of straight to booking.

What it is

A Google Doc that starts from the Cortena standard for the client’s country (there is a German and a Dutch version). It typically has three sections, split by where the supplier is based, because that decides which VAT details an invoice must carry. In the German version:

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

The requirements in each section are flexible and can be customised per client: a field can be added, dropped, or made conditional, for example to accept a supplier that never prints a reverse-charge note.

How it works

The completeness check reads only this document plus the extracted invoice data. It does not see the PDF, the Matching Guide, or any sheet. It writes “complete: yes / no” with a reason, and the workflow sends every “no” to Require Manual Review.

Keep in mind

• Only ask for fields that extraction actually captures: names, addresses, VAT IDs, dates, line items, VAT rates and amounts, and the reverse-charge flag. A requirement the check cannot see (for example the taxable amount per VAT rate, or specific exemption wording) produces false “incomplete” flags.
• If a tenant needs an exception (for example, a supplier that never prints a reverse-charge note), this document is the only place it works. Scope it to something in the extracted data, such as the supplier’s VAT ID. Because it is a Doc, syncs from the accounting system never overwrite it.

5. Creditor and Debitor Allocation

Purpose: the supplier master. It answers one question: which creditor (supplier sub-ledger) account is this invoice from, and under which other names does that supplier appear?

What it is

A Google Sheet with exactly three columns, one row per supplier from the client’s supplier list (DATEV Kreditorenliste, Crediteurenlijst):

• Account number: the creditor number, as text.
• Name: the supplier name as in the accounting system.
• Alternative Names: other spellings, short names, or trading names. Empty if there are none.

If the client cannot provide a supplier list, the sheet is built from the creditor numbers in the booking history, with Name and Alternative Names left empty. Names are never guessed.

How it works

1. A filter shortlists rows that look similar to the extracted supplier name. It searches every column, including Alternative Names.
2. The AI picks one creditor number from that shortlist. It sees only the supplier name and the shortlist.
3. No convincing match: Cortena uses the creditor number stored on the linked master supplier, if there is one. Otherwise the creditor stays empty for the reviewer.

The chosen creditor number also links the invoice to the supplier record in Cortena.

Keep in mind

• Alternative Names is the main lever. If a supplier invoices as “DB Fernverkehr AG” but the accounting system calls it “Deutsche Bahn”, add the alias and it will match.
• One supplier per account number, and every row needs a number.
• No booking-account or VAT columns. Account routing belongs in the Chart of Accounts and VAT logic in the VAT Code sheet. An extra account-like column gets confused with the creditor number.
• Matching only picks an existing creditor; it never adds a row to this sheet. Creating a missing creditor in the accounting system only happens at export: DATEV Rechnungswesen has a creditor auto-create setting (off by default), and Twinfield exports also try to create a creditor that does not exist yet. Neither writes back to this sheet. New suppliers reach the sheet through an updated supplier list or, for Exact Online and Twinfield tenants, the daily sync.

6. Cost Center Allocation

Purpose: assign the right cost center (KOST1 / KOST2 in DATEV, a dimension in Twinfield) to an invoice, so costs land on the right department, person, or project.

What it is

A Google Sheet with exactly four columns: Employee - Cost Center Owner, Type (KOST1 / KOST2), Cost Center number, and Cost Center Name. It lists the cost centers the client actually used in its booking history. If the client does not use cost centers, the sheet ships with headers only; cost centers are never invented.

Example row: Jane Doe · KOST1 · 1000 · Marketing

How it works

The cost center matcher reads the whole sheet, the supplier’s booking history, the line items, and the contact persons on the invoice. Its order of evidence is:

1. Which cost center this supplier was booked to before.
2. Department, person, or purpose names on the line items.
3. Other contacts on the invoice.
4. Contact persons.

It runs in parallel with booking-account matching, so it does not know the booking account. Cost centers per line item exist as an option per tenant.

Keep in mind

• Owner names matter: a name on the invoice such as “Attn: Jane Doe” is matched against the people in the sheet. The matcher’s instructions look for “First name” and “Last name” columns, which the standard sheet does not have, so check cost centers that were assigned by person.
• A rule like “if account X, then cost center Y” can be translated into this sheet, for example as an extra column with instructions or requirements per cost center. Give the column a clear header, and describe what is visible on the invoice (the kind of purchase, supplier, or line) rather than the account number, because the matcher does not know which account was chosen.
• The AI can occasionally return a code that is not in the sheet. Reviewers should check unusual codes.
• Cost centers can be switched off per tenant with Deactivate cost centers in Accounting preferences. This hides the cost-center row on the invoice and leaves cost centers out of the export. The sheet must still exist, because a missing Cost Center sheet stops processing.

Guidelines and reference data

Cortena uses the four sheets (Chart of Accounts, BU Code, Creditor, Cost Center) in two different ways:

• On every rebuild an AI decides again which column holds the code and which holds the name. An extra text column can be picked by mistake, and its values then show up in the dropdown and in the export until the next rebuild. That is why each sheet keeps its fixed columns.
• Extra columns do reach the matching AI, because it reads the whole sheet. They never become structured reference data.
• The accounting integration still provides the master data where Cortena syncs with it. The guidelines add the business logic on top: which account fits which kind of line, which BU code fits which situation, and which other names a supplier uses.

How the documents are created

• At onboarding, the Cortena bookkeeping setup skill generates all six from three client exports: the chart of accounts, the creditor/debtor list, and the booking history. There is one skill for German clients on DATEV and one for Dutch clients on Twinfield or Exact Online.
• German clients on DATEV: Cortena reads the available accounts and suppliers from the accounting system, together with the client’s booking history. The BU codes are derived from that booking history: the sheet lists the codes the client has actually used. This requires a connection to DATEV Datenservice Export Rechnungswesen.
• Dutch clients on Twinfield or Exact Online: Cortena reads the available accounts, VAT codes, and suppliers from the accounting system and enriches them with the client’s booking history.
• Nothing is invented. Every account, BU code, supplier, and cost center traces back to a row in the client’s own files.
• The Chart of Account Matching Guide and the Completeness Guideline are at creation the same for every client. The other four guidelines (sheets) are fully client-specific.
• A tenant created from a template in the app gets copies of the template files with the same names. Germany (DATEV SKR04) is the default template.

For tenants connected to Exact Online or Twinfield, a daily sync updates the four sheets from the accounting system. It keeps hand-written text (USE FOR, DO NOT USE IF/FOR, the (Do not use) markers) where the synced value has not changed. It can still overwrite cells or swap the contents of columns, and Twinfield can delete rows whose codes no longer exist in Twinfield, including rows added by hand. The two Docs are never touched. Check a sheet’s version history before assuming guidance is still there.

Where does a fix belong?

Recurring corrections in the review queue are the best sign that a rule is missing. Go through them weekly and fix the document that the corrected step reads. Write rules around what is visible on the invoice: supplier names and line descriptions as they are printed.

Beyond the six: supplier-specific extraction docs

When one supplier’s line items come out wrong on every invoice (rows missed or merged, freight dropped, gross read as net), the fix is not in the tenant’s six documents but in a supplier-specific guideline doc:

• It is a Google Doc in Cortena’s central supplier-guideline library, titled with the supplier name in capitals and without punctuation: “Google Ireland Limited” becomes GOOGLE IRELAND LIMITED.
• For that supplier it replaces the global line-item extraction rules completely, so anything from the global rules that should still apply must be in it too. The Chart of Account Matching Guide still applies, because it sits in the system prompt.
• It applies to that supplier in every tenant. The country sub-folders in the library are only for filing.
• It describes the supplier’s invoice layout, never the items of one particular invoice. The supplier-specific guideline generator drafts it from a problem invoice.

Related: How Cortena reads an invoice, Instructing agents on booking accounts, Matching correction.

Quick reference