Connect an LLM to your accounting data

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 fourteen ready-made tools — ten read, four write — 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) → GET $BASIS_URL/saldenliste?fiscal_year=…
#   list_open_items(type)        → GET $BASIS_URL/open-items?type=…
#   post_journal_entry(...)      → POST $BASIS_URL/journal-entries
#
# The call your code runs when the model invokes get_saldenliste(2025):
curl "$BASIS_URL/saldenliste?fiscal_year=2025" \
  -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: post a manual journal entry, Storno a booking, issue an outgoing invoice, book an incoming invoice.
• 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 are time-limitable, revocable and shown once.

Be honest about the edges: the API is bookkeeping data and postings only. 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, submits an E-Bilanz or completes a tax return — those steps stay 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.