An AI agent for your bookkeeping

Delegate the routine

The repetitive parts of FiBu are exactly what an agent is good at.

• Categorise and draft postings for incoming invoices, then post on your confirmation.
• Chase and summarise open items so nothing slips through month-end.
• Reconcile bank lines against booked entries and surface the gaps.
• Explain the trial balance in plain language before you review it.
• Prepare and tidy the figures that later become your annual accounts in the app.

MCP or REST — pick per client

Two transports, one data model.

Read versus write

Control is a property of the key, not a promise.

Start with a read-scope key. The agent can pull the trial balance, journal entries, accounts, open items, invoices and bank lines, but it cannot change a thing. That is often enough — an agent that reads and explains already saves hours.

When you trust the flow, upgrade to read-plus-write. Now the agent can post manual entries, issue or book invoices, and reverse bookings via Storno. The key stays bound to one company, remains revocable at any time, and every write passes through the GoBD booking core.

Give the agent access

One command for MCP; one call to prove a write works.

# Give an MCP client access (read + write scope on the key):
claude mcp add --transport http --scope user buchhaltung \
  "$MCP_URL" --header "Authorization: Bearer jab_live_…"

# Reverse a wrong booking — a Storno, never a delete (a reason is required):
curl -X POST "$BASIS_URL/journal-entries/{id}/storno" \
  -H "Authorization: Bearer jab_live_…" \
  -H "Content-Type: application/json" \
  -d '{"reason":"Wrong account","idempotency_key":"<new UUID, reuse on retry>"}'

Where the agent stops

Clear limits are what make delegation comfortable.

• It works on bookkeeping data and postings and can check and prepare tax filings — the API never files annual accounts, an E-Bilanz or a tax return by itself.
• It cannot run SQL or a free query; the endpoints are a fixed allowlist.
• It cannot cross into another company; the company is derived from the key.
• It cannot bypass GoBD; the booking core is the same one the UI uses.
• It cannot reach the product's own AI or internal logic — those are not bookkeeping resources.

Frequently asked questions

What is the safest way to start?

Hand the agent a read-only, time-limited key. It can analyse and explain your books without any ability to post, and you can revoke it instantly. Upgrade to write only when you are ready.

Do I have to use MCP?

No. MCP is the easiest route for MCP-capable clients, but any function-calling model or script can drive the REST API directly. Choose per client; the data and rules are identical.

How does the agent post safely?

Every write runs through the same booking core as the manual UI. Reversals are Storno operations, deletes are impossible, and Soll must equal Haben — GoBD applies to the agent exactly as to a human.

Can the agent see another company's books?

No. The company is derived from the key, never a request parameter, so a key can only ever reach the one company it was created for.

Can the agent do my tax return?

Not on its own. With a write key the agent checks a VAT return or a tax return with ELSTER's official validation and prepares the transmission; you then file in the app through the approval link, with your PIN. The annual accounts are drawn up in the app as well.