LLM + function calling
Connect an LLM to your accounting data
If your LLM can call functions, it can read and write your German bookkeeping. Define one tool per REST endpoint, give it a Bearer key, and the model can pull the trial balance, list open items or post an entry from natural language. For MCP-capable clients the MCP server makes this even easier, but the REST API is the universal path any model can take. Scope and GoBD stay in your hands.
Last reviewed: 2026-07-03
Function calling maps to endpoints
The mental model is one tool per route.
Modern LLMs expose tool or function calling: you describe a function, the model decides when to call it, and your code executes the call. Map each function onto a REST endpoint — get_saldenliste onto the trial balance, list_open_items onto open items, post_journal_entry onto a manual booking — and the model can drive your books through plain language.
The read routes make excellent tools because they are safe by construction: the worst a read tool can do is fetch data for the one company its key belongs to. Add the write tools only when you want the model to post.
MCP is the shortcut for MCP clients
Same data, less wiring.
If your client speaks the Model Context Protocol, you skip the hand-wiring entirely. The MCP server publishes 91 ready-made tools — 43 read, 45 write, one to send invoices, one to lock periods, one to file with ELSTER whose right is not granted yet — over a hosted transport, so the model discovers them automatically. It is a thin adapter over the same REST API, with the same key, scopes and GoBD rules. For non-MCP models, the REST API below is the path.
A minimal tool and call
Describe the tool, then let it hit the endpoint.
# Describe one tool per endpoint, e.g.: # get_saldenliste(fiscal_year_id) → GET $BASIS_URL/saldenliste?fiscal_year_id=… # list_open_items(kind) → GET $BASIS_URL/open-items?kind=debitor|kreditor # post_journal_entry(...) → POST $BASIS_URL/journal-entries # # The call your code runs when the model invokes get_saldenliste for 2025: curl "$BASIS_URL/saldenliste?fiscal_year_id=<id from GET /fiscal-years>" \ -H "Authorization: Bearer jab_live_…"
Read and write surface
The endpoints your tools wrap.
- Read: entity, fiscal years, accounts, journal entries, trial balance, open items, outgoing and incoming invoices, bank transactions.
- Write, for example: post a manual journal entry, Storno a booking, issue an outgoing invoice, book an incoming invoice. The write scope also covers payments, receipts, bank matching and the other ledgers; sending invoices needs send, locking periods needs finalize.
- The company is derived from the key, so no tool can reach another company.
- No SQL and no free query — the tools wrap a fixed endpoint allowlist.
Scope, safety and honest limits
The model is only as powerful as the key you give it.
Choose the scope deliberately. A read key turns your LLM into a fast analyst over real numbers; a read-plus-write key lets it post, always through the GoBD booking core with append-only history, Storno instead of delete and Soll equal to Haben. Keys always expire (after 30, 90 or 365 days), are revocable and shown once.
Be honest about the edges: the API covers bookkeeping data and postings, tax checks and reading issued annual accounts — it compiles no annual accounts. An LLM can prepare and tidy the figures that later become your annual accounts in the app, but the API never files an annual report, an E-Bilanz or a tax return by itself — it can check and prepare tax filings, and you release them inside the app.
Frequently asked questions
Which LLMs can connect?
Any model with tool or function calling. You define one function per REST endpoint and execute the calls in your code. MCP-capable clients get an even easier path through the MCP server.
Do I need MCP to use an LLM here?
No. MCP is the shortcut for MCP-capable clients. Every other model drives the REST API directly with a Bearer key — the data and the rules are identical either way.
How do I keep a model read-only?
Give it a read-scope key and only wrap the read endpoints as tools. It can fetch and reason over the numbers but cannot post anything, whatever the prompt asks.
Can a tool reach another company?
No. The company is derived from the key, never a tool argument, so one key equals one company and cross-company access is impossible.
Can an LLM produce my filed accounts?
No. It can prepare the bookkeeping figures, but the annual accounts and any tax filing are done inside the app. The API exposes bookkeeping data and postings only.