Teach your AI the back office

---
name: receipt-routine
description: Monthly receipt routine for small businesses in Germany and Austria. Use when the user says "receipt routine" or "Belegroutine", asks which receipts are missing, or hands over a month folder or ZIP with bank, card or PayPal statements (CSV or PDF) and receipts (PDF or photos). Renames copies of the receipts to YYYY-MM-DD_Supplier_Amount without asking, matches them to the statement lines, lists the payments without a receipt for each payment stream and writes a missing-receipts CSV. Never changes, moves or deletes an original.
---

# Monthly receipt routine

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only the files the user gives. Needs an AI app that can read and write files: for example Claude with code execution or a shared folder, Codex, Gemini CLI or Grok Build.

Work through every step on your own. Do not stop to ask between steps; ask only at the very end (step 9). Answer in the user's language. Show amounts the way the statements show them (38,90 € or €38.90).

## Folder structure

The user prepares one folder per month. German and English names both work:

```
Belege-2026-09/            or  Receipts-2026-09/
  Kontoauszuege/           or  Statements/    one file per payment stream, CSV or PDF
    Girokonto.csv                             the file name is the stream's name
    Kreditkarte.pdf
    PayPal.csv
  Belege/                  or  Receipts/      every receipt of the month, PDF or photo, any names
```

You create, next to the inputs:

```
  Belege-umbenannt/        or  Receipts-renamed/
    <payment stream>/                         renamed copies of the matched receipts
    Ohne-Zahlung/          or  No-payment/    renamed copies without a payment
  Fehlende-Belege.csv      or  Missing-receipts.csv
```

Use the German names if the user's folders are German, otherwise the English ones.

- **Month:** from the folder name (`Belege-YYYY-MM` / `Receipts-YYYY-MM`), else the month the user names, else last month.
- **A ZIP:** unpack it into a working folder first.
- **Loose files without the subfolders:** treat statement exports (CSV, or PDFs that list bookings) as statements and everything else as receipts; say so in one line.
- **No statement at all:** rename the receipts, then say that matching needs the statements and stop.

## Rules

- **Never change, move or delete an original.** Rename and sort copies only.
- **Never invent** a date, supplier or amount. If a receipt cannot be read, write "unreadable" and keep its file name.
- **One receipt, one payment.** Never match a receipt to two payments, or two receipts to one payment unless they add up to it exactly.
- **No tax advice.** For a specific case, point to the user's tax adviser.

## 1. Read the statements

Each statement file is one **payment stream**, named after the file (`Girokonto`, `Kreditkarte`, `PayPal`). Read every payment of the month: booking date, payee, reference, amount, currency.

## 2. Read the receipts

For every file: issue date, supplier, gross total, currency, kind of document. Flag order confirmations and delivery notes: they are usually not an invoice.

## 3. Rename (without asking)

Scheme: `YYYY-MM-DD_Supplier_Amount.ext`, e.g. `2026-09-14_Hetzner_38,90.pdf` (decimal comma for German, point for English).

- Date: the receipt's issue date.
- Supplier: short, no legal form, hyphens instead of spaces (`Deutsche-Bahn`, not `Deutsche Bahn AG`).
- Amount: gross, two decimals, no currency sign. A credit note gets a minus: `-12,00`.
- Photos keep their extension. Same name twice: add `_2`, `_3`.

## 4. Match

For each receipt, find the payment that fits:

1. **Amount** equal to the cent. In a foreign currency, up to 3 % off is fine (exchange rate and fees); say so.
2. **Date:** from 10 days before to 5 days after the booking (card payments often book a few days later).
3. **Name:** the supplier fits the payee or the reference.

All three fit: matched. Only amount and date fit: **unsure**, keep it for step 9.

**No receipt needed** (mark them, do not list them as missing): transfers between the user's own accounts, private withdrawals, tax payments, salaries, and the debit of the credit card or PayPal on the bank account when that stream has its own statement in the folder (its payments are matched there).

Put each renamed copy into `Belege-umbenannt/<payment stream>/`, receipts without a payment into `Ohne-Zahlung/` (English: `Receipts-renamed/…`, `No-payment/`).

## 5. Report in the chat

1. For **each payment stream**, a table **"Payments without a receipt"**: date, payee, amount.
2. A table **"Receipts without a payment"**: file, date, supplier, amount (paid in cash, from another account, or not paid yet).
3. A **summary per payment stream**: payments, with receipt, without receipt, unsure, no receipt needed.
4. Unreadable files, if any.

## 6. Missing-receipts CSV

Write `Fehlende-Belege.csv` / `Missing-receipts.csv` with the columns payment stream, date, payee, amount, reference, sorted by payment stream and date. Semicolon as separator, UTF-8 with BOM, so Excel opens it cleanly.

## 7. Requests for the missing receipts

Offer one short e-mail per supplier asking for the invoice; the user sends it. Nothing to get back, like a parking machine: point to a self-made receipt (Eigenbeleg). It can support the expense but gives no input VAT.

## 8. Month folder

Zip the statements, the renamed receipts and the CSV into one file for the bookkeeper, e.g. `Belege-2026-09_Buchhaltung.zip`, and offer it for download.

## 9. Only now: questions

Show the unsure matches (receipt, payment, why unsure) and ask which ones are right. Update the folders, the CSV and the ZIP with the answers. End with one line: payments matched, receipts missing, still unsure. The originals stay untouched.

---
name: month-end-checklist
description: Month-end checklist for small businesses in Germany and Austria. Use when the user says "month-end", "Monatsabschluss" or "month-end checklist", asks what is still open for last month, or wants to get a month ready for the bookkeeper. Walks through the 30-minute routine (collect, upload, match, chase what is missing, hand over) in the same month folder as the receipt routine, runs the receipt-routine skill for the matching, checks issued invoices and bank statements for gaps, and ends with one list of what is still open. Never changes, moves or deletes an original.
---

# Month-end checklist

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only what the user gives. Works in any AI chat as a guided checklist. The matching in step 3 is done by the receipt-routine skill from the same library, which needs an AI app that can read and write files (for example Claude with code execution or a shared folder, Codex, Gemini CLI or Grok Build).

Checked on 16/10/2026 against the monthly receipt routine (the receipt-routine skill and our guide) and the VAT return dates in § 18 UStG (Germany) and § 21 UStG (Austria).

Answer in the user's language. Keep it short: one step at a time, the user says "done" or hands over files.

## When and how long

Once a month, in the first week of the following month: last month's statements are available and the bookkeeper has time before the VAT return. Plan 30 minutes, about 20 with the receipt routine.

## Month folder

The same folder as the receipt routine. German and English names both work:

```
Belege-2026-09/            or  Receipts-2026-09/
  Kontoauszuege/           or  Statements/          one file per payment stream, CSV or PDF
  Belege/                  or  Receipts/            every receipt of the month, PDF or photo
  Ausgangsrechnungen/      or  Invoices-issued/     optional: the invoices you sent this month
```

The receipt routine adds `Belege-umbenannt/` / `Receipts-renamed/` and `Fehlende-Belege.csv` / `Missing-receipts.csv`. This skill adds `Offene-Punkte.csv` / `Open-items.csv`.

- **Month:** from the folder name, else the month the user names, else last month.

## Rules

- **Never change, move or delete an original.** Work on copies only. Never overwrite an existing file: if `Offene-Punkte.csv` / `Open-items.csv` exists, ask before replacing it or add a number.
- **Never invent** a receipt, amount or date.
- **Do not duplicate the receipt routine.** Renaming, matching and the missing-receipts list belong to the receipt-routine skill. If it is not installed, say so and point to the free download at back-bone.io/en/tools/skill-library; carry on with the other steps.
- **No tax advice.** For a specific case, point to the user's tax adviser. Say once in your answer that this is not tax advice.

## The five steps

### 1. Collect (8 minutes)

Give the user this list and wait for "done":

- Inbox: search last month for "Rechnung", "Invoice", "Beleg" and "receipt".
- Customer accounts of subscriptions and online shops: download the invoices.
- Paper receipts from the wallet: photograph them flat and fully legible.
- Statements of **every** payment stream: business accounts, credit card, PayPal, Stripe, a savings account if it holds business money. CSV if the bank offers it, else PDF.
- The invoices the user sent last month.

### 2. Upload (4 minutes)

Everything into the month folder: statements into `Kontoauszuege/`, receipts into `Belege/`, issued invoices into `Ausgangsrechnungen/`. One file per payment stream; the file name is the stream's name.

### 3. Match (10 minutes)

Run the **receipt-routine** skill on the month folder. It renames copies of the receipts, matches them to the statements, lists the payments without a receipt for each payment stream and writes the missing-receipts CSV. Take its summary over as is.

### 4. Chase what is missing (6 minutes)

From the receipt routine's list:

- Software, subscriptions, online orders: download from the customer account, or ask the supplier for the invoice (the receipt routine drafts the emails).
- Nothing to get back (e.g. a parking machine): a self-made receipt (Eigenbeleg) with date, amount, payee, business reason, why there is no original, date and signature. It can support the expense but gives no input VAT. Keep it the exception.

Then check what the receipt routine does not cover:

- **Statements complete:** every payment stream has a statement for the whole month, and each statement's opening balance equals last month's closing balance. Name any gap.
- **Issued invoices:** the invoice numbers of the month run on from last month without unexplained gaps; list every invoice still unpaid (match incoming payments in the statements by amount and invoice number, else ask the user).

### 5. Hand over (2 minutes)

One folder per month goes to the bookkeeper: issued invoices, receipts, statements, plus the list of what is still open. Use the receipt routine's ZIP (e.g. `Belege-2026-09_Buchhaltung.zip`) and add `Ausgangsrechnungen/` and `Offene-Punkte.csv` to it, or offer a new ZIP with the same content.

Remind the user of the VAT return date if they file monthly: Germany, the 10th of the following month (one month later with a permanent extension); Austria, the 15th of the second month after the period.

## Output

1. A checklist of the five steps: done, open, or skipped (with why).
2. **Open items** in one table: type (missing receipt, unpaid invoice, statement gap, unsure match), date, who, amount, next action.
3. `Offene-Punkte.csv` / `Open-items.csv` with the same columns, semicolon-separated, UTF-8 with BOM.
4. One closing line: receipts matched, receipts missing, invoices unpaid, statements complete yes or no.

---
name: invoice-check
description: Invoice checker for Germany and Austria. Use when the user says "invoice check" or "Rechnung prüfen", asks whether an invoice is complete or correct, or hands over an invoice they wrote or received (PDF, photo or pasted text). Checks it against the German mandatory details (§ 14 Abs. 4 UStG, small-amount invoice up to 250 euros under § 33 UStDV, small business under § 34a UStDV, reverse charge under § 14a UStG) or the Austrian ones (§ 11 UStG, simplified invoice up to 400 euros, Kleinunternehmer, customer UID above 10,000 euros) and lists what is missing, what is wrong and what is fine. Never changes the file.
---

# Invoice checker DE/AT

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only the invoice the user gives. Works in any AI chat that can read a PDF or a photo; pasted text works everywhere.

Checked on 16/10/2026 against § 14, § 14a and § 19 UStG, §§ 31, 33 and 34a UStDV (Germany) and § 11 UStG (Austria).

Work through the steps on your own. Ask only when the case cannot be read from the invoice (step 2). Answer in the user's language.

## Rules

- **Read, never edit.** Do not change, re-save or delete the user's file. Suggest corrections as text.
- **Never invent** a detail. If something is unreadable, say "unreadable", not "missing".
- **Only what the law asks.** Separate "must" (mandatory) from "should" (good practice). Do not call a should a must.
- **No tax or legal advice.** You check against the rules below. For a specific case, point to the user's tax adviser. Say once in your answer that this is a check, not tax or legal advice. Figures, thresholds and deadlines are as of the check date; if today is later or a figure matters for a decision, tell the user to verify it (official source or tax adviser).

## 1. Read the invoice

Note every detail you find: issuer name and address, recipient name and address, tax number, VAT ID (USt-IdNr. / UID), issue date, invoice number, description of the goods or service, service date or period, net amounts per VAT rate, VAT rate and amount, total, notes (small business, reverse charge, Gutschrift), payment terms.

## 2. Find the case

Decide from the invoice, ask only if it really cannot be told:

- **Country:** the issuer's country decides the rules (Germany or Austria).
- **Kind:** normal invoice, small-amount invoice (DE: total up to 250 euros gross, AT: up to 400 euros gross), small-business invoice (Kleinunternehmer), reverse-charge invoice (no VAT, client in another EU country or a domestic § 13b case), correction or cancellation.
- **Client:** business or private person.

## 3. Check: Germany

**Normal invoice, § 14 Abs. 4 UStG.** Must have:

1. Full name and address of the issuer and of the client
2. Issuer's tax number or VAT ID (one is enough)
3. Issue date
4. A unique invoice number (in Germany it does not have to be gap-free)
5. Quantity and type of goods, or scope and type of the service
6. Date of the service, or the period (the calendar month is enough, § 31 Abs. 4 UStDV). The issue date does not replace it.
7. Net amount broken down by VAT rate, plus any reduction agreed in advance (e.g. early-payment discount)
8. VAT rate and VAT amount, or a note on the exemption
9. Only for property-related work for a private person: a note on the client's duty to keep the invoice (§ 14b Abs. 1 Satz 5 UStG)
10. Only for self-billing: the word "Gutschrift"

**Small-amount invoice up to 250 euros gross, § 33 UStDV.** Enough: issuer's name and address, issue date, quantity and type of the service, the total including VAT and the VAT rate (or the exemption note). Not for reverse charge.

**Small business, § 34a UStDV.** Must have: names and addresses of both sides, tax number or VAT ID (or the small-business ID), issue date, quantity and type of service, the amount as one sum, a note that the § 19 UStG exemption applies. Must **not** show VAT. An invoice number is not required, but recommend one.

**Reverse charge to an EU business, § 14a UStG.** Must have: the issuer's and the client's VAT ID, the wording "Steuerschuldnerschaft des Leistungsempfängers" (adding "Reverse charge" is fine), no VAT amount and no "0 % VAT" line. Issue by the 15th of the month after the service.

## 4. Check: Austria

**Normal invoice, § 11 UStG.** Must have:

1. Name and address of the issuer
2. Name and address of the client
3. Quantity and commercial description of the goods, or type and scope of the service
4. Date or period of the service
5. The net fee
6. VAT rate, or a note on the exemption
7. VAT amount
8. Issue date and a sequential invoice number
9. Issuer's UID number
10. Only if the total is **over** 10,000 euros gross and the client is a business: the client's UID number

**Simplified invoice up to 400 euros gross, § 11 Abs. 6 UStG.** Enough: issuer's name and address, quantity and description, date of the service, issue date, the gross total and the VAT rate. Not for supplies to businesses in other EU countries.

**Small business (Kleinunternehmer).** No VAT shown, a note that the exemption under § 6 Abs. 1 Z 27 UStG applies. Since 2025 a small business may use the simplified invoice at any amount. Its own UID is not required.

**Reverse charge to an EU business.** Must have: the issuer's and the client's UID number, a note that the tax liability passes to the client (common: "Übergang der Steuerschuld auf den Leistungsempfänger (Reverse Charge)"), no VAT amount. Issue by the 15th of the month after the service.

## 5. Common mistakes to flag

- Service date or period missing (most common).
- VAT shown by a small business, or on a reverse-charge invoice: it is owed anyway until corrected (DE § 14c UStG, AT § 11 Abs. 12 UStG).
- A wrong VAT rate (DE 19 % / 7 %, AT 20 % / 13 % / 10 %): flag it as "check the rate", do not decide the rate.
- The old small-business sentence "Gemäß § 19 UStG wird keine Umsatzsteuer berechnet": accepted in practice, but since 2025 the exemption wording fits better ("Steuerbefreit nach § 19 UStG (Kleinunternehmer).").
- A correction called "Gutschrift": in German VAT law that word means self-billing. Use "Rechnungskorrektur" or "Stornorechnung".
- Germany, invoice between two German businesses: a PDF is an "other invoice", not an e-invoice. Point to the e-invoice deadlines only if asked; for the details the user can use the e-invoice-check skill.

## 6. Report

1. One line: country, kind of invoice, business or private client.
2. A table: detail, status (ok / missing / wrong / unreadable), what to fix.
3. "Must fix" first, then "Should fix".
4. One line at the end: "Complete" or "X of Y mandatory details missing".

Offer a corrected text block for the missing parts (e.g. the exemption note or the service period). The user corrects the invoice in their own tool; an issued invoice is corrected with a correction or cancellation invoice, not by editing the old one.

---
name: e-invoice-check
description: E-invoice check for Germany and Austria. Use when the user says "e-invoice check" or "E-Rechnung prüfen", asks whether a file they received is a real e-invoice, or hands over an invoice file (PDF, XML or a ZIP of them). Finds out whether it is a ZUGFeRD or Factur-X PDF with embedded XML, an XRechnung (UBL or CII) or just a PDF, names the profile, checks that the XML and the visible invoice agree, and says which German or Austrian rules apply (German receiving duty since 2025, sending duty for supplies from 2027 or 2028, Austria only for federal bodies). Never changes the file.
---

# E-invoice check

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only the files the user gives. Needs an AI app that can read files and run code, to open the XML inside a PDF: for example Claude with code execution or a shared folder, Codex, Gemini CLI or Grok Build.

Checked on 16/10/2026 against § 14 and § 27 Abs. 38 UStG, §§ 33 and 34a UStDV, §§ 3 to 5 ERechV, the BMF letter of 15/10/2025 (Germany) and § 11 UStG, § 5 IKTKonG and the USP page on e-invoices to the federal government (Austria).

Work through the steps on your own and answer in the user's language.

## Rules

- **Read, never edit.** Never change, re-save, convert or delete the user's file. Extract the XML into a separate working copy.
- **Never invent** a value. If the XML cannot be read, say so.
- **No full validation claim.** You read the file and check the points below. A full EN 16931 / XRechnung validation needs a validator (for example the KoSIT validator); say so when the user needs a certain answer.
- **No tax or legal advice.** For a specific case, point to the user's tax adviser. Say once in your answer that this is a check, not tax or legal advice. Figures, thresholds and deadlines are as of the check date; if today is later or a figure matters for a decision, tell the user to verify it (official source or tax adviser).

## 1. What kind of file is it?

- **PDF:** list the embedded files. An embedded invoice XML (usually `factur-x.xml`; ZUGFeRD 2.0 used `zugferd-invoice.xml`, an embedded XRechnung `xrechnung.xml`; other tools may use another name) means a hybrid e-invoice. No embedded XML: it is a plain PDF, an "other invoice", not an e-invoice.
- **XML:** root element `Invoice` or `CreditNote` (namespace `urn:oasis:names:specification:ubl:schema:xsd:Invoice-2` or `...:CreditNote-2`): UBL. Root element `CrossIndustryInvoice`: CII.
- **Photo, scan, Word, Excel:** not an e-invoice.

## 2. Which profile?

Read the specification identifier:

- CII: `ExchangedDocumentContext / GuidelineSpecifiedDocumentContextParameter / ID`
- UBL: `cbc:CustomizationID`

Quote the identifier exactly as found, then name it. Typical patterns (check in this order, the list is not complete; if nothing fits, give the identifier and say the profile is unclear):

- contains `xrechnung` (e.g. `urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0`): XRechnung
- contains `minimum` or `basicwl`: MINIMUM or BASIC WL profile
- contains `extended`: EXTENDED profile
- ends in `:basic`: BASIC profile
- exactly `urn:cen.eu:en16931:2017`: EN 16931 (in ZUGFeRD: profile EN 16931)

**Germany:** ZUGFeRD from version 2.0.1 counts as an e-invoice, **except the MINIMUM and BASIC WL profiles**. Those are "other invoices", like a PDF.

## 3. Does the content add up?

- The XML has the mandatory details: seller and buyer name and address, seller VAT ID or tax number, invoice number, issue date, service date or period, line items, net amounts per VAT rate, VAT rate and amount, total.
- For a hybrid PDF: the XML and the visible PDF show the same number, date, totals and VAT. If they differ, say so clearly: in Germany the **XML counts** for tax purposes.
- XRechnung to a German federal body: a Leitweg-ID (buyer reference) is present.

## 4. Which rules apply?

**Germany** (both sides established in Germany, business to business):

- **Receiving:** every business must be able to receive e-invoices since 01/01/2025, small businesses included. An email inbox is enough.
- **Sending:**
  - Supplies made in 2025 and 2026: paper, or PDF with the client's consent, is still fine.
  - Supplies made in 2027: paper or PDF still allowed only if the issuer's total turnover in 2026 was at most 800,000 euros (EDI invoices agreed with the client stay allowed for everyone in 2027).
  - Supplies from 01/01/2028: e-invoice only.
  - These transition rules (§ 27 Abs. 38 UStG) can still change; tell the user to confirm the current dates with their tax adviser.
- **Exceptions:** small-amount invoices up to 250 euros (§ 33 UStDV), invoices from small businesses (§ 34a UStDV), invoices to private persons, invoices to clients abroad.
- **Keep** the XML (or the PDF with embedded XML) unchanged for eight years. A printout or a re-saved PDF without the XML is not enough.
- If a PDF arrives where an e-invoice was required, it is not a proper invoice; the client may lose the input VAT deduction. Suggest asking the supplier for an e-invoice.

**Austria:**

- No e-invoice duty between businesses (as of the check date). A PDF by email is an electronic invoice if the client agrees.
- Invoices to **federal government bodies** must be structured e-invoices since 01/01/2014: ebInterface or UBL, through the USP portal (e-rechnung.gv.at) or PEPPOL, with the order reference and supplier number.
- Austrian businesses selling to German businesses are not covered by the German duty; ZUGFeRD is still a good choice because German businesses can receive it.

## 5. Report

1. **Verdict in one line:** "E-invoice: yes (ZUGFeRD 2.x, profile EN 16931)", "No: plain PDF" or "Unclear: …".
2. A short table: format, syntax (CII / UBL), profile, XML and PDF agree (yes / no / no PDF), mandatory details found.
3. **What applies** to this invoice, from step 4, in two or three lines.
4. **What to do:** e.g. "Keep the original file with its XML", "Ask the supplier for an e-invoice", "Have a validator confirm it".

---
name: invoice-writer
description: Writes invoice drafts for businesses in Germany and Austria. Use when the user says "write an invoice", "Rechnung schreiben" or "Rechnung erstellen", hands over notes, a timesheet or hours to bill, or asks to turn work into invoice lines. Groups the notes into clear line items and builds a complete draft with the mandatory details (Germany § 14 Abs. 4 UStG, Austria § 11 UStG 1994), including the small-business (Kleinunternehmer) and reverse-charge notes. On first use it asks once for the company details and saves them, so it never asks again. Never invents an invoice number, amount or tax detail. Drafts only, the user reviews and issues.
---

# Invoice writer DE/AT

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only what the user gives and the saved company details. Works with any AI chat. If Backbone's AI connector is connected, it reads and saves the company details in Backbone and can put the draft there.

Checked on 20/10/2026 against § 14 and § 14a UStG, § 19 UStG, §§ 31, 33 and 34a UStDV (Germany) and § 11 and § 6 Abs. 1 Z 27 UStG 1994 (Austria).

Answer in the user's language. Write the invoice in the language the client reads (German or English).

## Rules

- **Draft only.** Never issue, number, send or post an invoice. The user reviews it and issues it in their invoicing software.
- **Never invent** a number, date, amount, tax ID, address or bank detail. Leave a placeholder like `[Rechnungsnummer]` and list it at the end.
- **No invoice number.** Numbering is done by the user's software or by the user (one unique number per invoice; in Austria sequential). Always leave `[Rechnungsnummer]`.
- **Copy the facts exactly.** Client name, hours, rates and dates stay as given. Ask about anything unclear instead of guessing.
- **No tax or legal advice.** The draft follows the rules below; it is not a guarantee. For a special case (a client outside the EU, goods instead of services, a construction service under § 13b UStG), point to the user's tax adviser.

## 0. First run: your setup

Before the first invoice, the skill needs the user's company details. Look for them in this order and stop at the first place that has them:

1. **This file:** the section **Your setup** at the end of this SKILL.md. If it holds the details, use them and do not ask.
2. **Backbone connected:** call `get_settings`. If company name, address, a tax ID and bank details are there, use them and do not ask.
3. **Saved earlier:** the assistant's memory, the project's instructions or files, or a `company-profile.md` the user attached.
4. **Nothing found:** ask once, before the first invoice, in one short message:

   > To write your invoices I need your company details once. I'll save them so I won't ask again:
   > 1. Company name (as on the invoice)
   > 2. Address
   > 3. Country: Germany or Austria
   > 4. VAT ID (USt-IdNr. / UID) or tax number (Steuernummer)
   > 5. Small business (Kleinunternehmer)? yes / no
   > 6. Bank: IBAN and BIC
   > 7. Contact email
   > 8. Optional: logo, payment terms (e.g. "14 days, no deduction")
   > 9. Optional: the language of your invoices (German, English or per client) and anything that should be on every invoice

   If the user answers only in part, ask only for what is still missing. If they have no VAT ID and no tax number, say that one of them must be on a German invoice (Austria: the UID, unless a small business) and leave a placeholder.

**Confirm before saving.** Show the details back as a short list and ask "Save like this?". Save only after a yes.

**Where to save** (every place that applies):

- **In this file, if your AI tool can edit files** (for example Claude Code, Codex, Gemini CLI or Grok Build, with the skill in a folder on your computer): replace the text under **Your setup** at the end of this SKILL.md with the confirmed details, in the company-profile format below, and say that you did. The skill is then set up for this person and never asks again. Never write passwords or logins into it. A skill uploaded to a chat app usually cannot change itself; then use the next options.
- **Backbone connected:** `update_business_info` (name, address, postal code, city, country, VAT ID, tax number, IBAN, BIC, contact email) and `update_tax_scheme` for the small-business setting. On newer connections both are one tool, `update_company`. Only fields the user gave; set `no_tax_id` only if the user said they have neither and want none. The logo is uploaded in Backbone under Settings; payment terms are set per invoice (default 14 days).
- **Otherwise:** save them where the AI app keeps things across chats, and say where:
  - **ChatGPT:** in memory (if the user has it on), or in the instructions or files of a Project.
  - **Claude:** in memory (if the user has it on), or in a Project's instructions or knowledge.
  - **Always also** give the details as a small `company-profile.md` block to copy, so the user can keep it, add it to a Project or attach it next time. If the app cannot remember anything, say so honestly: the user pastes the block under **Your setup** in their own copy of this skill, or attaches `company-profile.md` to the next chat. Without either, the skill asks each time.

```markdown
# Company profile (invoice-writer)
Company: …
Address: …
Country: Germany | Austria
VAT ID / UID: …
Tax number: …
Small business: yes | no
IBAN: … · BIC: …
Contact email: …
Payment terms: …
Logo: yes (file) | no
```

**Never ask again** once the details are saved. Use them for every invoice. If the user says "change company details" ("Firmendaten ändern") or gives a new detail (new address, new IBAN), show the change, confirm it and save it the same way, in the same place (including **Your setup** in this file). If the user moves from small business to standard VAT (or back), update that setting and mention it on the next invoice.

## 1. Collect the facts for this invoice

From the user, their notes or Backbone (`list_unbilled_time` for open hours, `get_client` for the client): client name and address, business or private client, the client's country and VAT ID (needed for reverse charge, and in Austria above 10,000 euros gross for a business client), service period, what was done, hours or quantities, rate or price. Ask only for what is missing, in one message.

## 2. Find the case

- **Country:** the user's country decides the rules (from the company details).
- **Small business:** no VAT. Germany: "Steuerbefreit nach § 19 UStG (Kleinunternehmer)." Austria: "Umsatzsteuerfrei aufgrund der Kleinunternehmerregelung gemäß § 6 Abs. 1 Z 27 UStG."
- **Reverse charge:** a business client in another EU country, for a service. No VAT line and no "0 % VAT" line. Both VAT IDs on the invoice. Germany: "Steuerschuldnerschaft des Leistungsempfängers"; Austria: "Übergang der Steuerschuld auf den Leistungsempfänger (Reverse Charge)". Issue by the 15th of the month after the service. For details the eu-reverse-charge skill helps.
- **Small amount:** Germany up to 250 euros gross (§ 33 UStDV), Austria up to 400 euros gross (§ 11 Abs. 6 UStG): fewer details are enough, but a full invoice is never wrong. Write the full one unless the user asks.
- **Standard:** VAT at the rate the user names. Germany 19 % or 7 %, Austria 20 %, 13 % or 10 %. Do not choose the rate; if the user did not name one, ask, or if Backbone is connected leave it to the workspace default.

## 3. Write the line items

- Group the notes by project or kind of work. One line per group: a clear description of the service (what was done, not how long the notes were), quantity (hours or pieces), unit, unit price.
- Turn raw entries ("call", "call 2", "wireframes v2") into plain, factual text. No marketing words.
- Flag entries with no description or no hours instead of dropping them.
- Hours: keep the hours as given; if the user rounds, round the total, not each entry, and say so.

## 4. Build the draft

**Germany, standard invoice (§ 14 Abs. 4 UStG):** issuer's name and address; client's name and address; issuer's tax number or VAT ID; issue date; `[Rechnungsnummer]`; quantity and type of the service; service date or period (the calendar month is enough, § 31 Abs. 4 UStDV); net amount per VAT rate; VAT rate and VAT amount (or the exemption note). Should: payment terms, bank details, the payment reference. For a private client in Germany, suggest adding: "Sie kommen spätestens 30 Tage nach Fälligkeit und Zugang dieser Rechnung in Verzug." (§ 286 Abs. 3 BGB; without it the 30-day rule does not apply to private clients).

**Austria, standard invoice (§ 11 UStG 1994):** issuer's name and address; client's name and address; quantity and description of the service; date or period of the service; net amount; VAT rate (or the exemption note); VAT amount; issue date; `[Rechnungsnummer]` (sequential); issuer's UID; above 10,000 euros gross for a business client also the client's UID.

**Amounts:** quantity × unit price per line, net total, VAT and gross total. Show the calculation so the user can check it. If Backbone is connected, the software calculates; do not put your own totals into Backbone.

## 5. Output

1. The invoice draft as a clean block: header (issuer, client), `[Rechnungsnummer]`, dates, the line items in a table, totals, the tax note, payment terms and bank details.
2. A short list: placeholders still to fill and anything that looked unclear in the notes.
3. Optional on request: a short cover email in the user's tone.

**Backbone connected:** offer to create the draft there (`create_invoice`, on newer connections `create_document`, or `add_time_to_document` for open hours). It stays an unnumbered draft; Backbone gives it its number when the user issues it after checking. Never issue or send without the user's explicit OK.

**Without a connected invoicing tool:** the user copies the draft into their invoicing software, which gives the number. A text, Word file or plain PDF is not an e-invoice: in Germany, invoices between German businesses must be e-invoices (ZUGFeRD, XRechnung) from 2027 or 2028; point to the e-invoice-check skill if the user asks.

In German, call it "Rechnungsentwurf", the lines "Positionen" and the period "Leistungszeitraum".

## Your setup

Not set up yet. The first run fills this in (step 0), if the AI tool can edit this file.

---
name: reminder-writer
description: Writes payment reminders in the user's own tone, in German or English, for businesses in Germany and Austria. Use when the user says "payment reminder", "Zahlungserinnerung" or "Mahnung", asks how to chase an unpaid invoice, or hands over an overdue invoice or a list of open invoices. Writes three levels (a friendly reminder, a second reminder and a final notice) with default interest and the 40 euro flat fee where the law allows them (Germany § 288 BGB, Austria § 456 and § 458 UGB, § 1000 ABGB). Drafts only, never sends anything.
---

# Payment reminders in your tone

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only what the user gives. Works with any AI chat.

Checked on 16/10/2026 against § 286 and § 288 BGB (Germany), § 456 and § 458 UGB and § 1000 ABGB (Austria); § 907a ABGB and § 6a KSchG (Austria) added on 20/10/2026. Base rates as of that day: Germany 1.52 % (from 01/07/2026), Austria 1.53 % (for the half-year from 01/07/2026).

Answer in the user's language. Write the reminders in the language the client reads (German or English).

## Rules

- **Draft only.** Never send, schedule or post anything. The user sends.
- **Never invent** an amount, date, invoice number or bank detail. Leave a placeholder like `[IBAN]` instead.
- **Stay polite at every level.** Firm, never rude, no threats beyond what the law allows (interest, the flat fee, a collection agency or court).
- **No legal advice.** For a dispute, a disputed invoice or a client abroad with a contract under foreign law, point to the user's lawyer or tax adviser.

## 0. First run: your setup

Look at **Your setup** at the end of this SKILL.md first. If it is filled in, use it and do not ask these questions again.

If it says "Not set up yet", ask once, before the first reminder, in one short message:

> So your reminders sound like you, a few questions once:
> 1. Your country: Germany or Austria
> 2. Your name or company, and how you sign off
> 3. du, Sie or English? Or paste two or three emails you wrote to clients
> 4. Your clients: mostly businesses, mostly private, or both
> 5. The new deadline you usually give in a first reminder (for example 14 days)
> 6. Are your bank details in your email signature? yes / no

Show the answers back as a short list and ask "Save like this?". Then:

- **If your AI tool can edit files** (for example Claude Code, Codex, Gemini CLI or Grok Build, with the skill in a folder on your computer): replace the text under **Your setup** with the answers, as a short list, and say that you did. Later runs read it from there. Keep only the tone notes from the sample emails, never client names or amounts.
- **Otherwise:** save the answers in the app's memory or a Project's instructions, if the user has them, and give the list to copy into **Your setup** in their own copy of this skill. If the app cannot remember anything, say so honestly: the skill asks again next time.

If the user says "change my setup" or gives a new detail (new sign-off, new country), update it the same way.

## 1. Learn the tone

If **Your setup** holds the tone, use it. If the user gives earlier emails or texts they wrote (two or three are enough), copy their tone: du/Sie or first names, greeting, sentence length, sign-off. Otherwise ask once, in one message: "du or Sie (or English)? Formal or relaxed? How do you sign off? Or paste two emails you wrote to clients." Then keep that tone for all three levels. Unless the samples say otherwise: short, friendly, no legalese.

## 2. Collect the facts

From the invoice or the user: client name, business or private client, country of the user (Germany or Austria), invoice number and date, amount, due date, what was agreed on payment, earlier reminders and their dates, bank details. Ask only for what is missing, before writing; use placeholders only if the user wants the draft right away. Keep the facts exactly as given. If the user says the bank details are in their signature, do not repeat them in the text.

## 3. When is the client in default?

**Germany (§ 286 BGB):**
- With the first reminder after the due date, or without one if a calendar date for payment was agreed.
- At the latest 30 days after the due date and receipt of the invoice. For a **private client** only if the invoice pointed this out.

**Austria:** in default as soon as the money is not in the user's account on the due date (§ 907a Abs. 2 ABGB). A private client only has to order the transfer by then (§ 6a Abs. 2 KSchG). No reminder is needed for default.

## 4. Interest and the flat fee

| | Business client | Private client |
| --- | --- | --- |
| Germany | base rate + 9 points (10.52 % a year from 01/07/2026), plus a 40 euro flat fee (§ 288 BGB) | base rate + 5 points (6.52 % a year), no flat fee |
| Austria | base rate + 9.2 points (10.73 % a year for 01/07 to 31/12/2026, § 456 UGB), plus a 40 euro flat fee (§ 458 UGB) | 4 % a year (§ 1000 ABGB), no flat fee |

- Interest runs from the first day of default. Per day: amount × rate ÷ 100 ÷ 365 × days. Show the formula and the result; the user checks it.
- The base rates change on 1 January and 1 July. If today is after 31/12/2026, tell the user to check the current base rate (Deutsche Bundesbank, OeNB) before sending. Backbone's free late-payment interest calculator does it to the day (back-bone.io/en/tools/late-payment-interest-calculator).
- Client abroad: the German or Austrian rates only apply if the contract is under that law. In the EU, business to business, the Late Payment Directive sets a floor of the reference rate + 8 points and 40 euros. Name the law and currency, and suggest checking with an adviser.
- Never pick a rate or add a fee beyond this table. If the user's invoicing software calculates the interest (if Backbone is connected: `calculate_late_interest`, on newer connections part of `get_document`), take its figure.
- Interest and the flat fee are optional. Many users leave them out of the first reminder to keep the relationship; suggest that.

## 5. Before you write: what stays with the user

Ask, or point it out, before writing a level 2 or 3:

- **Disputed invoice:** do not chase. Suggest pausing the reminders and calling the client first.
- **Long-standing client:** suggest a call before the second reminder; a call often works better.
- **The last step** (collection agency or court) is the user's decision. Write level 3 only when the user asks for it.

## 6. Write the three levels

If the user asks for one reminder only (for example "a friendly payment reminder"), write that level only.

**Level 1: friendly reminder (Zahlungserinnerung).** Short and friendly, assumes an oversight. Invoice number and date, amount, original due date, bank details and payment reference, "if you have already paid, please ignore this". If the user gives a new deadline, add it as a friendly "please pay by [date]" (often 14 days). No interest, no fees, no legal steps.

**Level 2: second reminder (Mahnung).** Clear: still open after the reminder of [date], now [x] days overdue. A new deadline, 7 to 14 days. Mention default interest from the start of default (and for business clients the flat fee). Offer to talk if something about the invoice is unclear.

**Level 3: final notice (Letzte Mahnung).** Amount, interest for [x] days, flat fee (business clients only) and the new total in a small table. A last deadline. Say what happens next: handing the claim to a collection agency or taking legal steps, with further costs. No other threats.

Every level has: a subject line with the invoice number, the open amount, the due date, the new deadline (levels 2 and 3), bank details and payment reference, a contact for questions, the user's sign-off.

## 7. Output

1. The three texts (or the one level asked for), each ready to copy, in the client's language.
2. Under level 3: the interest calculation in one line.
3. A short list of what the user still has to fill in (placeholders).

In English, call the levels "payment reminder", "second reminder" and "final notice"; in German "Zahlungserinnerung", "Mahnung" and "Letzte Mahnung".

## Your setup

Not set up yet. The first run fills this in (step 0), if the AI tool can edit this file.

---
name: small-business-note
description: Small-business exemption wording for invoices in Germany and Austria (Kleinunternehmerregelung). Use when the user says "Kleinunternehmer", "small-business note" or "§ 19 UStG", asks what to write on an invoice without VAT, or hands over an invoice or invoice template to check. Checks or writes the exemption note (Germany § 19 UStG with § 34a UStDV, Austria § 6 Abs. 1 Z 27 UStG), checks the 2025 thresholds against the turnover the user gives, and flags VAT shown by mistake. Never changes the user's file.
---

# Small-business exemption wording

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only what the user gives. Works with any AI chat.

Checked on 16/10/2026 against § 19 UStG and § 34a UStDV (Germany, thresholds read on 28/08/2026) and § 6 Abs. 1 Z 27 and § 11 UStG (Austria, thresholds from WKO, read on 28/08/2026).

Answer in the user's language. Write the invoice note in the invoice's language.

## Rules

- **Read, never edit.** Do not change the user's file; give corrected text to copy.
- **Never invent** turnover figures. Work only with the numbers the user gives.
- **No tax advice.** Whether the user may use the exemption, or should opt out of it, is for their tax adviser. You explain the rules and the wording. Say once in your answer that this is not tax advice. Figures, thresholds and deadlines are as of the check date; if today is later or a figure matters for a decision, tell the user to verify it (official source or tax adviser).

## 1. Find the country and the task

- Germany or Austria: the user's place of business decides.
- Task: check an existing note or invoice, write a new note, or check the thresholds. Do what the user asks; if unclear, do all three briefly.

## 2. The note

Neither country prescribes exact wording. It must say clearly that the small-business exemption applies.

**Germany.** Since 2025 small-business sales are tax-exempt; § 34a UStDV asks for a note that the § 19 UStG exemption applies.

- German, short: `Steuerbefreit nach § 19 UStG (Kleinunternehmer).`
- German, long: `Für diese Lieferung/sonstige Leistung gilt die Steuerbefreiung für Kleinunternehmer nach § 19 UStG. Es wird keine Umsatzsteuer ausgewiesen.`
- English invoice: add `VAT-exempt small business under § 19 UStG.`
- The widely copied old sentence `Gemäß § 19 UStG wird keine Umsatzsteuer berechnet.` comes from the rules before 2025. It is accepted in practice; suggest the exemption wording when the user edits the template anyway. Do not call it invalid.

**Austria.**

- German: `Umsatzsteuerfrei aufgrund der Kleinunternehmerregelung gemäß § 6 Abs. 1 Z 27 UStG.`
- English invoice: add `VAT-exempt under the small-business scheme, § 6 (1) no. 27 UStG.`

## 3. The rest of the invoice

**Germany (§ 34a UStDV):** names and addresses of both sides, tax number or VAT ID, issue date, quantity and type of the service, the amount as one sum, the exemption note. No VAT rate, no VAT amount, no "0 % VAT" line. An invoice number is not required, but recommend a sequential one for the books. Small businesses do not have to issue e-invoices, but must be able to receive them since 2025.

**Austria:** no VAT shown, the exemption note. Since 2025 a small business may use the simplified invoice at any amount (issue date, own name and address, quantity and type of service, date of the service, the total). Its own UID is not required.

**VAT shown by mistake** (a VAT line, a rate, "incl. 19 % VAT"): flag it first. On an invoice to a business the VAT shown is owed until the invoice is corrected (Germany § 14c UStG, Austria § 11 Abs. 12 UStG). Suggest a correction invoice.

## 4. Thresholds (from 2025)

| | Germany (§ 19 UStG) | Austria (§ 6 Abs. 1 Z 27 UStG) |
| --- | --- | --- |
| Previous year | at most 25,000 euros, net | at most 55,000 euros, gross |
| Current year | at most 100,000 euros, net | at most 55,000 euros, gross; up to 10 % over (60,500 euros) the exemption runs to year-end |
| Over the limit | the sale that crosses 100,000 euros is already taxable | above 60,500 euros: the sale that crosses it is already taxable |

- If the user gives turnover figures, say which side of each limit they are on, and how much room is left this year.
- Close to a limit (say within 10 %): suggest talking to the tax adviser before a large job.
- Do not decide about opting out of the exemption; name it as an option for the tax adviser.

## 5. Output

1. **Verdict** in one line: "Note fits", "Note missing" or "Note outdated, still accepted".
2. The note to copy, in the invoice's language (both lines for a bilingual invoice).
3. What else is missing or wrong on the invoice, if an invoice was given.
4. The threshold check, if figures were given.

---
name: eu-reverse-charge
description: EU client and reverse-charge check for service businesses in Germany and Austria. Use when the user says "reverse charge" or "Steuerschuldnerschaft", invoices a client in another country, asks whether to charge VAT to a foreign client, or hands over a cross-border invoice to check. Sorts the case (EU business with VAT ID, EU private client, client outside the EU), says whether German or Austrian VAT applies, gives the invoice wording (§ 14a UStG, § 13b UStG; Austria § 11 Abs. 1a and § 19 Abs. 1 UStG), the VAT ID check in VIES, the invoice deadline and the recapitulative statement. Services only. Never changes the user's file.
---

# EU client and reverse-charge check

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone: it uses only what the user gives. Works with any AI chat.

Checked on 16/10/2026 against § 3a, § 13b, § 14a and § 18a UStG (Germany) and § 3a, § 11 and § 19 UStG (Austria).

Answer in the user's language. Give invoice wording in the invoice's language.

## Rules

- **Services only.** Selling goods, construction, services tied to property, events and passenger transport, and VAT registration abroad are not covered: say so and point to the user's tax adviser.
- **Read, never edit.** Do not change the user's file; give corrected text to copy.
- **Never invent** a VAT ID or a check result. The user checks the VAT ID; you explain how.
- **No tax advice.** You sort the standard case. For anything unusual, point to the user's tax adviser. Say once in your answer that this is not tax advice. Figures, thresholds and deadlines are as of the check date; if today is later or a figure matters for a decision, tell the user to verify it (official source or tax adviser).

## 1. Sort the case

Find out, from the invoice or by asking in one message:

- Where the user is based: Germany or Austria. Small business (Kleinunternehmer) or not.
- Where the client is: another EU country, or outside the EU (e.g. Switzerland, the UK, the USA).
- Business or private client. An EU business shows it with a valid VAT ID.
- What the service is. Flag automated digital services (downloads, software as a service, streaming) to private clients.

## 2. EU business client with a VAT ID: reverse charge

A service to a business is taxed where the client is established (Germany § 3a Abs. 2 UStG, Austria § 3a Abs. 6 UStG). The client owes the VAT in their country. The user charges **no** German or Austrian VAT.

**The invoice:**

- Both VAT IDs: the user's and the client's.
- **Germany:** the wording `Steuerschuldnerschaft des Leistungsempfängers` (§ 14a Abs. 1 UStG). Add `Reverse charge` for a foreign client; write both.
- **Austria:** a note that the tax liability passes to the client (§ 11 Abs. 1a UStG). No fixed wording; common is `Übergang der Steuerschuld auf den Leistungsempfänger (Reverse Charge)`.
- No VAT amount and no "0 % VAT" line. The net amount is the total.
- All other details of a normal invoice (number, dates, service period, addresses).
- **Deadline:** by the 15th of the month after the service.

**Check the VAT ID** before the first invoice, in the EU's VIES service (ec.europa.eu, "VIES VAT number validation"); in Germany also with the Federal Central Tax Office's confirmation service, in Austria via FinanzOnline. Keep the result with its date. Invalid or no VAT ID: treat the client as a private client until it is fixed.

**Recapitulative statement (Zusammenfassende Meldung, ZM):** report the sale. Germany: by the 25th day after the end of the quarter (§ 18a UStG). Austria: by the end of the month after the reporting period.

**Small business:**
- Germany: reverse charge applies too, because the sale is taxed in the client's country. Small businesses do not have to file the ZM. Whether the client's VAT ID must be on the invoice is not clear for small businesses: ask the tax adviser.
- Austria: to invoice an EU business the user usually needs their own UID number, also as a small business. Check with the tax office.

**Section numbers, not mixed up:** in Germany § 13b UStG is reverse charge (and the case where the user buys a service from abroad and owes the VAT); § 19 UStG is the small-business exemption. In Austria § 19 UStG is reverse charge.

## 3. EU private client

- Most services: the user's own VAT applies (Germany 19 % / 7 %, Austria 20 % / 13 % / 10 %), as at home. A small business stays exempt.
- **Automated digital services:** taxed in the client's country once the user's cross-border sales of this kind (with distance sales of goods) exceed 10,000 euros a year EU-wide, usually through the One-Stop-Shop. Flag it and point to the tax adviser.

## 4. Client outside the EU

- **Business client:** no German or Austrian VAT; the service is taxed where the client is. No EU VAT ID needed; keep proof that the client is a business (e.g. its company registration). The client's country may tax it on its side; usually the client handles that. Invoice note, German: `Nicht im Inland steuerbare Leistung.` English: `Not subject to German VAT (place of supply outside the EU).` (Austria: `Austrian VAT`).
- **Private client:** for advice, IT, data processing, marketing, licences and similar services the place of supply is where the client lives, so no German or Austrian VAT. Other services: the user's own VAT. Some countries (e.g. the UK, Switzerland) expect foreign sellers of digital services to register: flag it, not covered here.

## 5. Output

1. **The case** in one line: e.g. "Service to an EU business with a VAT ID: reverse charge, no German VAT."
2. **VAT:** charge it or not, and why (one or two sentences).
3. **Invoice note** to copy, in the invoice's language.
4. **Checklist:** VAT IDs on the invoice, VIES check saved, invoice by the 15th, ZM, and anything missing on the invoice the user gave.
5. What is not covered, if the case touches it.

---
name: data-redactor
description: Removes or pseudonymises personal data in texts and documents before they are shared with any AI. Use when the user says "redact", "anonymise", "pseudonymise" or "Daten schwärzen", wants to share a client email, contract, invoice, PDF or CSV with an AI tool without personal data, or wants names put back into an AI's answer. Replaces names, addresses, emails, phone numbers, IBANs, tax and VAT IDs, dates of birth and similar with placeholders like [PERSON_1], writes a redacted copy plus a local mapping table so the names can be re-inserted later, and explains what it cannot catch. Never changes the original, never uploads or sends anything.
---

# Data redactor

Free skill from the Backbone skill library (back-bone.io/en/tools/skill-library). Works without Backbone. Pasted text works in any AI chat. For documents (PDF, Word, CSV, Excel) and the mapping table it needs an AI app that can read and write files: for example Claude with code execution or a shared folder, Codex, Gemini CLI or Grok Build.

Checked on 16/10/2026.

Answer in the user's language.

## Know the limit first

Tell the user once, at the start, in two sentences: **the app this skill runs in sees the original.** Run it where the original may go (a plan your business uses for client data, or a coding agent on the user's own computer with script mode, below), then share only the redacted copy with any other AI.

## Rules

- **Never change, move or delete an original.** Write a redacted copy next to it. Never overwrite an existing file: if the name is taken, add a number (`_2`).
- **Never upload, send or look anything up.** No web search, no other service, no sharing link. Everything stays in the files and the chat the user already uses.
- **The mapping table stays with the user.** Never include it in the redacted copy, never in a summary meant for sharing.
- **When in doubt, redact.** A name too many is cheaper than one too few.
- **No legal advice.** Whether data may be shared at all (GDPR, a processing agreement, professional secrecy) is for the user and their data protection or legal adviser. Say once in your answer that this is not legal advice.

## 1. What to replace

Use numbered placeholders that keep the meaning, the same placeholder for the same value everywhere:

| Data | Placeholder |
| --- | --- |
| People's names, also in email addresses and signatures | `[PERSON_1]` |
| Company and client names (if the user wants them out) | `[COMPANY_1]` |
| Street addresses (street, number, postcode, city) | `[ADDRESS_1]` |
| Email addresses | `[EMAIL_1]` |
| Phone numbers | `[PHONE_1]` |
| IBAN, BIC, account and card numbers | `[IBAN_1]`, `[CARD_1]` |
| Tax numbers, VAT IDs (USt-IdNr., UID), social security numbers, ID card and passport numbers | `[TAXNO_1]`, `[VATID_1]`, `[ID_1]` |
| Dates of birth | `[BIRTHDATE_1]` |
| Health, religion, union membership and other special data | `[SPECIAL_1]`, and tell the user |
| Customer numbers, contract numbers, URLs or user names that point to a person | `[REF_1]` |

Keep what the task needs and is not personal: amounts, invoice dates, due dates, item descriptions, the user's own business data if they say so. Ask once, in one message, what may stay (e.g. "keep company names and amounts?"); then work on your own.

## 2. Texts

1. Replace as above.
2. Show the redacted text, ready to copy.
3. Show the mapping table separately, marked "keep, do not share".

## 3. Documents

- **PDF:** extract the text (and the text of each page). A scan or photo without a text layer: say so; you can redact the extracted text, but do not promise a clean PDF. Write the redacted copy as a new text or Markdown file, or as a new PDF if the app can make one. Never overlay black boxes on the original: the text underneath stays readable.
- **Word, text, email files:** a redacted copy in the same format where possible, else as text.
- **CSV and Excel:** keep the columns. Redact whole columns that hold personal data (name, email, IBAN) and personal data inside free-text columns. Keep amounts and dates.
- **Also check:** headers and footers, email signatures, file metadata (author, title) and the file name itself. Name the copy without personal data, e.g. `Contract_redacted.pdf`.

**Script mode** (coding agents on the user's own computer): write a small local script that replaces the patterns (emails, IBANs, phone numbers, VAT IDs, postcodes) and a list of names the user gives, run it on the files, and only then read the redacted copies. That way the raw content is read as little as possible. Show the script so the user can see what it does.

## 4. Mapping table

Write `Mapping_<file>.csv` next to the redacted copy (in the same folder as the original, never inside the redacted copy): placeholder, original value, type. Semicolon-separated, UTF-8 with BOM. Tell the user to keep it local and delete it when no longer needed.

## 5. Put names back

When the user brings back an AI's answer with placeholders, replace each placeholder with its original from the mapping table. List any placeholder you could not find and any new one the other AI invented.

## 6. Check and limits

Before you hand over, scan the redacted copy once more for anything that still looks personal (capitalised names, @, digits that look like an IBAN or phone number) and fix it.

Then say plainly what redaction cannot do:

- Context can still identify a person ("the only dentist in town", a rare job title, a unique project).
- Images, logos, signatures and handwriting inside documents are not redacted.
- Scans without a text layer can hide text you could not read.
- Pseudonymised data is still personal data under the GDPR as long as the mapping table exists.

## Output

1. The redacted text or the path of the redacted copy.
2. The mapping table (or its path), marked "keep, do not share".
3. A count per type (e.g. 4 people, 2 IBANs, 1 address) and the limits from step 6 that apply to this file.