# Matching guidelines
The six Google Docs and Sheets that teach Cortena how to match booking accounts, VAT codes, creditors, and cost centers.
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.
**Who this is for:** Finance admins and AP leads who maintain a client’s booking rules, and the Cortena team that sets the documents up and supports them. The documents are ordinary Google Docs and Sheets in the tenant’s Drive folder. There is no special editor in Cortena: you edit the file itself.
## The six documents at a glance
| **#** | **Document** | **Type** | **The question it answers** | **Read by (pipeline step)** | **Client-
specific?** |
| --- | --- | --- | --- | --- | --- |
| 1 | **Chart of Account Matching Guide** | Google Doc | Who is the client, and which general rules apply to every invoice? | Extraction (system prompt) and booking-account matching | Only the client name and legal entities |
| 2 | **Chart of Accounts** | Google Sheet | Which booking account does this line item go to? | Booking-account matching, account dropdown, export account names | Fully |
| 3 | **BU Code Matching Guidelines** | Google Sheet | Which VAT treatment (BU code) applies to this line item? | BU / VAT code matching | Fully (only the codes the client actually uses) |
| 4 | **Invoice Completeness Guideline** | Google Doc | Does this invoice carry every field it legally needs? | Completeness check | Starts as the Cortena standard, can be customised per client |
| 5 | **Creditor and Debitor Allocation** | Google Sheet | Which supplier account (creditor number) is this invoice from? | Creditor matching | Fully |
| 6 | **Cost Center Allocation** | Google Sheet | Which cost center (KOST1 / KOST2) does this invoice belong to? | Cost center matching | Fully, or headers only if the client has no cost centers |
## How the documents fit into the pipeline
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](#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.
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.
## 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:
| **Exact file name** | **Type** |
| --- | --- |
| `Chart of Account Matching Guide` (also accepted: `Extraction and Matching Guidelines`) | Google Doc |
| `Chart of Accounts` | Google Sheet |
| `BU Code Matching Guidelines` (also accepted: `VAT Code Matching Guidelines`) | Google Sheet |
| `Invoice Completeness Guideline` | Google Doc |
| `Creditor and Debitor Allocation` | Google Sheet |
| `Cost Center Allocation` | Google Sheet |
- 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](https://help.cortena.ai/guides/get-started/instructing-agents-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:
| **Column** | **What goes in it** |
| --- | --- |
| **Booking Account** | The account number exactly as in the client’s chart, stored as text (leading zeros kept). |
| **Booking Account Name** | The account name exactly as in the accounting system, not translated or edited. |
| **USE FOR** | One or two plain sentences on what kind of invoice line belongs here. Non-payables accounts carry exactly `(Do not use)`. |
| **DO NOT USE IF/FOR** | Only where two accounts compete for the same kind of line: `Route to .` Often empty, which is fine. |
| **Good Examples** | Positive examples only, as `Typical purchases: …` and `Suppliers: A | B | C`. Never an instruction. |
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](https://help.cortena.ai/guides/invoices/matching-correction) and [Matching learns from your corrections](https://help.cortena.ai/guides/invoices/matching-learns-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.
| **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% |
### 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:
| | **As a guideline** | **As reference data** |
| --- | --- | --- |
| **What it is** | The sheet itself, read whole: every column, header row included | A structured list Cortena builds from the sheet: code and name (for BU codes also description and rate) |
| **Used by** | The AI matching steps | The pick lists in the app (for example the booking-account and cost center dropdowns) and the account name sent with the export |
| **When it updates** | Live: an edit counts from the next invoice | Rebuilt automatically whenever any guideline file in the tenant changes (all four lists together), or by hand with **Synchronise reference data** in Settings |
- 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.
| **Problem** | **Edit this** | **Editing this does nothing** |
| --- | --- | --- |
| Wrong booking account for a type of line | Chart of Accounts (USE FOR, DO NOT USE IF/FOR, Good Examples) | Creditor sheet |
| Wrong BU / VAT code | BU Code Matching Guidelines | Chart of Account Matching Guide |
| Invoice wrongly flagged as incomplete | Invoice Completeness Guideline | Chart of Account Matching Guide |
| Supplier not recognised or wrong creditor | Creditor and Debitor Allocation (add an Alternative Name) | Chart of Accounts |
| Wrong or missing cost center | Cost Center Allocation (owner names, cost center names) | Chart of Accounts |
| Client not recognised as the recipient, or a new legal entity | Chart of Account Matching Guide, section B | Any sheet |
| One supplier’s line items extracted wrongly | A supplier-specific guideline doc (see below) | Any of the six |
---
## 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](https://help.cortena.ai/guides/get-started/how-cortena-reads-an-invoice), [Instructing agents on booking accounts](https://help.cortena.ai/guides/get-started/instructing-agents-booking-accounts), [Matching correction](https://help.cortena.ai/guides/invoices/matching-correction).
---
## Quick reference
| **Task** | **Where** |
| --- | --- |
| Open the documents | **Settings → Accounting preferences → Matching Guidelines & Instructions**, or the Drive folder link there |
| Edit rules | The Google Doc or Sheet itself, in the tenant’s Drive folder |
| Update the dropdowns after a sheet change | Automatic; or **Synchronise reference data** in Settings |
| Apply a change to invoices already processed | **Reprocess** the invoice, or edit it by hand on the invoice detail |
| First-time setup | Create the tenant from a template or generate the six with the onboarding skill, keep the exact file names, share the files with the Cortena service account |
| Find which document to fix | [Where does a fix belong?](#where-does-a-fix-belong) |