ChatGPT for accounting: where a general assistant stops and the ledger starts

ChatGPT, Claude and similar assistants are useful in accounting for work that needs language or logic but not your books: explaining a booking rule, drafting a reminder letter, writing a spreadsheet formula, summarising a contract. They stop being the right tool once real ledger data is involved. Pasting exports into a chatbot raises GDPR questions, leaves no trace in your records and produces numbers no one can audit.

Finance teams already use AI. The question is where it sits: next to the system of record, fed with copied files, or inside it, with the same permissions, data and audit trail as everyone else.

---

What is a general AI assistant actually good at in accounting?

Most of the value comes from tasks where the assistant never sees a booking. A controller can ask it to explain the difference between an accrual and a provision, to rewrite a payment reminder in a friendlier tone, or to turn a messy Excel formula into one that a colleague can read. It is a fast way to draft a process description for the GoBD procedure documentation (Verfahrensdokumentation), the written description of how your bookkeeping works, before your tax advisor (Steuerberater) reviews it.

It also helps with thinking work. A finance lead can describe a planned pricing change and ask which accounts, VAT questions and reporting effects to check. The answer is a checklist to verify, not a result, but it often surfaces the question nobody had asked yet.

None of this needs customer names, bank data or salaries. That is the useful rule of thumb: if the task works with invented or anonymised data, a general assistant is usually fine.

Where does a general assistant stop?

It stops at three points, and each one shows up in a normal month.

It does not know your books. An assistant has no chart of accounts, no open items and no booking history unless someone gives them to it. Every answer about your numbers depends on a file that was exported at one moment, by one person, with whatever filters they set. By the next morning the file is out of date.

It does not check its own arithmetic reliably. Language models are good at plausible text and less good at summing 400 lines, carrying signs correctly or noticing that a column was cut off. Results look clean even when they are wrong. We look at what accuracy figures mean for approval in how accurate AI is on accounting work.

It cannot act in the system. A suggested journal entry in a chat window still has to be typed into the ledger by hand. That is the step where most errors in small finance teams come from, and the chatbot has not removed it, only moved it.

Connectors that let an assistant read accounting data directly solve part of the first problem. They do not decide who may see what, and they do not make the assistant's output part of your records.

What does the GDPR say about pasting finance data into a chatbot?

Finance exports are rarely free of personal data. Supplier lists name sole traders. Open-item lists name customers. Payroll and travel expenses name employees. Under the GDPR (DSGVO), all of this is personal data, and sending it to an AI provider is processing it.

That has concrete consequences. If the provider processes the data on your behalf, you need a data processing agreement under Article 28 GDPR (Auftragsverarbeitungsvertrag). If the provider sits outside the EU, the transfer rules in Articles 44 to 46 apply, which means an adequacy decision or safeguards such as standard contractual clauses. If the provider uses your inputs to train its own models, it is processing the data for its own purposes, and the data is very hard to delete later. Since February 2025, Article 4 of the EU AI Act also expects companies to make sure staff who use AI tools understand them well enough.

Many business plans of AI providers offer an agreement and exclude training. Personal accounts often do not, and they are exactly what an employee reaches for at 11 p.m. before a board meeting. Beyond personal data there is confidentiality: supplier terms, margins and bank balances are trade secrets even when no person is named.

The practical rule for a German company is simple. Aggregated figures without names can go into an approved business account. Personal data, bank data, payroll and supplier conditions stay out.

Why does a chatbot export break the audit trail?

German bookkeeping law asks for more than correct numbers. § 146 of the Fiscal Code (AO) requires bookings to be complete, correct, timely and orderly, and forbids changes that hide the original content. The GoBD (German digital bookkeeping rules) add that every figure must be traceable from the document to the booking to the report, and back. In a tax audit, the auditor can ask for data access under § 147 (6) AO.

A chatbot sits outside that chain. Consider a typical case: someone exports the open payables, asks an assistant which invoices to pay first, gets a ranked list, and pays from it. Which version of the export did the assistant see? Which rows did it drop? Who decided, and on what basis? None of that is stored in the books. The same applies to a reconciliation done in a chat window or an accrual list calculated there. The output reaches the ledger as a manual booking, and the reasoning behind it is gone.

That is not illegal in itself. People have always made decisions in spreadsheets. But it means the AI adds no traceability, and every number it touched has to be checked again by someone who can explain it.

What changes when the AI works inside the system of record?

Put the same assistant inside the ERP and the three gaps close.

The AI sees live data instead of a copy, so the question "which invoices are due this week" is answered from today's open items. It works with the user's permissions, so a team lead asking about travel costs sees their cost centre and not the payroll of the whole company. And its output is a proposal in the system: a booking, a match, an accrual, marked as suggested, waiting for a person to approve it.

Approval is the key step. The person who approves is named, the suggestion and its basis are stored, and the change to the ledger is logged like any other. That is the difference between AI that produces text and AI that produces bookings, and it is why we argue in what an AI-native ERP is that the AI layer belongs on the same data model as the ledger. A wider view of which tasks belong to AI at all is in where AI belongs in accounting.

How does Agent F keep AI inside the ledger?

In Agent F, the AI layer works on the same data model as the general ledger, payables, receivables and expenses. You can ask questions in plain language, for example "why are travel costs in sales up this quarter", and the answer comes from live bookings, filtered by your role.

When the AI does work, it proposes. It suggests the account and cost centre for an incoming invoice from your booking history, matches a bank line to an open item, or suggests an accrual at month-end. Each suggestion carries a confidence score. A person approves, corrects or rejects it, and the decision lands in the immutable audit trail with the original document. How far agents can go before they need approval is described in AI agents for finance.

The data stays in Germany, encrypted, under the GDPR and GoBD, with no export to a third-party chatbot needed. Approved bookings flow into the DATEV export for your tax advisor without being retyped.

General assistants still have a place. Keep them for drafting, explaining and thinking, on data without names. To set that up, write a one-page AI rule for the finance team that lists what may go into which tool, move everyone onto a business account with a data processing agreement, and stop pasting payables, payroll and bank exports into chat windows. Then list the three recurring tasks where people currently copy data out of the books, because those are the ones that belong inside the system.

Learn how Agent F works, or see it on your own bookings at agent-f.ai/demo.