Automate German bookkeeping with n8n, Zapier & Make

No marketplace app — and that is fine

Set expectations straight before you build.

None of these platforms has a published, one-click integration for your bookkeeping. What they all share is a generic HTTP building block — the HTTP Request node in n8n and Make, the Webhooks or custom-request action in Zapier. That block is all you need to reach the REST API.

So the setup is honest and portable: point the node at the endpoint, add the Bearer key header, and map the fields. Nothing is hidden behind a proprietary connector, which also means your process is easy to audit and to move between platforms. The same three ingredients — a method, a URL and an Authorization header — are all any of the three platforms needs to reach the ledger.

Read on a schedule

Trigger a run, call a read endpoint, route the data onward.

• Fetch the trial balance every month-end and drop it into a sheet or a report.
• Pull open payables daily and post a reminder to your team channel.
• Read bank transactions and compare them against booked entries downstream.
• Export the chart of accounts once so the rest of your process can map codes.

Write from a workflow

With a write-scope key, a process can post real bookings.

• When a new sale lands elsewhere, POST an outgoing invoice with revenue and VAT.
• When a supplier document arrives, POST an incoming invoice with input VAT.
• Post a manual journal entry for a recurring accrual on the first of the month.
• Reverse a wrong booking with a Storno call — never a delete.

The generic HTTP node, configured

The same three things everywhere: method, URL, Authorization header.

# n8n → HTTP Request node   |   Zapier → Webhooks (custom request)   |   Make → HTTP module
#
# Read the bank lines for a fiscal year:
# Method:  GET
# URL:     $BASIS_URL/bank-transactions?fiscal_year=2025
# Header:  Authorization: Bearer jab_live_…
#
# Post from a process (needs write scope):
# Method:  POST
# URL:     $BASIS_URL/journal-entries
# Header:  Authorization: Bearer jab_live_…
# Body (JSON):
#   {"date":"2025-04-01","account":"1200","contra_account":"1800","amount":500.00,"text":"Transfer"}

Keep automations safe

The same guardrails as any other client.

• Give a read process a read-only key; only posting processes get read-plus-write.
• Use time-limited keys and rotate them; each one is bound to a single company.
• Every write runs through the GoBD booking core — append-only, Festschreibung, Storno, Soll equals Haben.
• The API never files an annual report, an E-Bilanz or a tax return; a process only prepares and posts bookkeeping data, and the app itself owns the compilation and the filing.

Frequently asked questions

Is there an n8n, Zapier or Make app for this?

No official published app exists. You connect through the generic HTTP-request or webhook node against the REST API — set the URL and the Authorization Bearer header, and you are done.

How do I authenticate the node?

Add a header named Authorization with the value Bearer followed by your jab_live_ key. No separate apikey header is required, and the company is derived from the key.

Can a process post bookings automatically?

Yes, with a read-plus-write key. It can post journal entries and invoices or reverse a booking via Storno, all through the same GoBD booking core the app uses.

How do I limit risk in an automation?

Use a read-only key wherever you only read, prefer time-limited keys you can revoke, and remember each key is scoped to exactly one company.

Can a workflow file my annual accounts?

No. The API handles bookkeeping data and postings only. A process can prepare the figures, but the annual accounts are compiled and filed inside the app, not via the API.