Lexoffice is now called Lexware Office, and there are four ways to connect something to it. First, your bank account: transactions and balances arrive through your bank's XS2A interface, and all you need is your online banking access. Second, your tax adviser, through a separate login for the firm that is free for both sides, or through the DATEV data services. Third, ready-made partner applications from the Lexware ecosystem, which is how shops, payment providers, time tracking or inventory systems dock on. And fourth, the public API for your own software. The first three you typically set up in the browser, without a line of code. The fourth requires programming skills and sits exclusively in the XL plan, which costs 32.90 euros net per month at list price (as of September 2026); the interface itself costs nothing extra. The rule of thumb: as long as a ready-made connection exists for your case, take it. You reach for the API when your own software is supposed to create contacts, quotes or invoices.
That fourth route is the one running in my own business, because my quote and invoice process does not start in the accounting tool, it starts in the inbox and in a conversation. The path from inbox to finished draft is in AI Agent for Bookkeeping and Inbox, the concept behind it is on Hiring AI employees. This post is about which route fits your business.
The four routes at a glance
Route 1: Connecting the bank account
Lexware Office retrieves transactions and balances for most current and business accounts through the bank's XS2A interface. XS2A stands for "access to account" and is the route, regulated through the PSD2 payment services directive, on which software may read account data with your consent. You give consent once in your banking, and from then on your bank may ask for a TAN on every synchronisation.
The most important practical point: with XS2A accounts there is no retrieval in the background, you trigger the update yourself, under finances and accounts. That is not a shortcoming of the software: in the background, TAN requests would go unanswered, and several of them can lead your bank to block online banking access. The exceptions are the few accounts with their own programming interface, among them Holvi, Pleo, Pliant and PayPal; those retrieve automatically. For everything else that means syncing weekly, as a fixed habit.
Route 2: Connecting the tax adviser
Two things get mixed up here. One is tax adviser access: your firm gets its own login, set up under settings and users via "create tax adviser", for which you need the "Administration" permission; the firm receives an invitation by email. For both sides it is free. Important for the security question further down: you cannot restrict this access to individual areas. Whoever holds it sees all the information in your account, including every bank account; Lexware explains this by pointing to the access to bank transactions that bookkeeping and the annual accounts cannot do without. That makes this access a deliberate full release to a contractual partner.
The other is the data route to DATEV, in three variants: the Rechnungsdatenservice 1.0, when the firm does your bookkeeping entirely, the Buchungsdatenservice, when you book yourself and the firm prepares the annual accounts, and the classic export as a DATEV file or as CSV. Which one fits is not decided by the technology but by how you divide the work. Ask the firm first, otherwise you set up the route they do not use.
Route 3: Shops and payment providers through partner applications
This is where the biggest misconception sits: most shops and payment service providers cannot be connected to Lexware Office directly, and for Stripe, eBay, Etsy, Mollie or Amazon there is no built-in connection. You book the payouts by hand under finances and transactions, or you use a partner integration; Lexware names Billbee and recommends services like PayJoe or Miracle Sync from roughly 50 to 100 documents per payout onwards.
Directly available: PayPal as an account with its own interface, an ePages and a Shopify connection for shops and, in pilot operation, an Amazon Business import. That import pulls purchase receipts out of Amazon Business and is not a connection to the Amazon marketplace: sales and payouts you make as a seller do not reach the tool through it.
Everything else runs through the partner ecosystem, which Lexware sorts into seven categories, from banking and e-commerce through travel expenses and time tracking to CRM and industry solutions. Connecting a partner application means giving an outside provider access to your accounting data. Three things belong before the setup:
- Does your Lexware contract include the functions it needs? If it does not, the connection fails and you look for the error in the wrong place.
- What does the partner read and write? Whoever creates invoices needs more rights than whoever syncs contacts.
- Authorisations expire. When a connection stands still after months, that is usually the cause and not the software.
Route 4: The programming interface
A programming interface, usually called an API, is a door for programs instead of people: your software sends a message to an address at Lexware and gets an answer. Four terms are enough. The endpoint is the address for one particular thing, one for contacts, one for invoices. The API key is a long password your program identifies itself with on every request. The rate limit says how many requests per second are allowed: with Lexware Office it is two, and whoever asks faster gets a 429 back. A webhook is the reverse direction, Lexware contacts your software when something changes.
Through the public API you can maintain contacts and articles, create documents of every kind, from invoices and quotes through order confirmations and delivery notes to credit notes and dunning letters, and also upload files, download PDFs and subscribe to events through webhooks. You create the key in the public API administration of your account. Two prerequisites: the public API exists only in the XL plan, and you need someone who can write REST integrations, because Lexware supplies the interface and the documentation, not the finished application. That does not have to be an agency: anyone who wants to build it themselves brings their case into the community and works through it with me and the others on the call.
Which route fits you?
Three questions usually settle it. Does the thing you want to connect appear in the partner list? Then take the ready-made connection: it gets maintained, a self-built one is yours to keep up. Do you only want data out? Then an export is often enough, the DATEV route for the firm, a CSV file for analysis. Is your own software supposed to create something in Lexware Office? Only then does the API pay off, for instance when your quote is produced in a CRM, in a project tool or by an AI employee anyway. For twenty identical invoices a month, a recurring invoice in the tool is enough. The same three questions apply if your tool is sevDesk; which interfaces sevDesk offers for that is covered in its own post.
The key is as sensitive as access to your account
An API key is not a technical detail. It is a password used by a program, and to Lexware Office whoever holds it is indistinguishable from you. Depending on its permissions it can read contacts, create and download documents and upload files.
Where it belongs. Not in a document, not in a chat log, not in an email to your developer and never in a public code repository, but in a password manager or in a file outside your project folder; it reaches the program as an environment variable. Lexware shows it exactly once when you create it: do not close the window before you have copied it.
How to restrict it. When you create a key you can choose between a key with all permissions and one with individually assigned permissions. Take the individually assigned ones, and only the ones the connected service needs for its job. Lexware recommends this explicitly; the rights cannot be changed afterwards, a key keeps them until it is deleted. From that follows the rule in one piece: one key per use case, each with the minimum rights for exactly that case. Several keys on their own separate nothing, they only make replacement and revocation easy; the limit on the damage comes from the rights a single key does not have. If one of them fails, you delete that one. A deleted key cannot be restored, and that is exactly the point: deleting is your emergency exit. Keys expire after 24 months at the latest anyway.
Why draft mode is safer than sending directly. Invoices created through the public API are drafts by default: status "draft", still editable, still without a PDF. Only the explicit addition finalize=true turns it into a finalised invoice with the status "open", and from that moment it can no longer be changed. That is not red tape: the sequential number and the immutability are created at exactly that point. A faulty draft is one click away from deletion, a faulty finalised invoice is a cancellation.
So the order is: a test draft first, which you look at in the interface, then live operation. And anyone automating this leaves finalising and sending with the human. For the invoice endpoint the documentation describes no email sending anyway (as of September 2026); what it offers are deep links with which you open the created document in the interface and check it. The machine prepares, the human releases.
And once more on the tax adviser access from route 2: because it cannot be restricted by area, it is no substitute for a key with limited rights. Which data you hand to third parties, and how to handle that when AI is involved, is covered in AI and Privacy: What the AI Gets to See.
How an AI employee works on this connection
This exact connection is the working basis of Anton, my AI employee for quotes and invoices. He builds a quote PDF in my design from an evaluated first conversation, recalculates net, VAT and gross, and checks it for line breaks and leftover placeholders. When a client says yes, he creates the contact, the quote and the invoice in Lexware Office, as a draft.
Three rules are hard-wired. First: he drafts, I release, no quote and no invoice leaves the system without my click. Second: he does not finalise unasked, and even when told to, he first names the consequences, the final invoice number and the immutability, and wants a clear yes. Third: no price without a source. If he finds two prices for the same service, he lists both with their source and asks.
Before the first live run there is a connection test. A 401 points to a missing or invalid API key, a 402 to a contract or plan problem, and a 403 to missing permissions or scopes. After that, check the request and endpoint. Anyone not using Lexware Office builds the same workflow through an adapter to their own tool, with the same pattern of draft, test draft and release. You build that adapter once, and not alone: the community has people who have been down the same road, and on the calls we work through your case together. What belongs in the quote that starts this chain is in How to Write a Quote That Convinces. Why the invoice at the end is created in the tool rather than as a loose PDF is covered in German E-Invoicing: Dates and Exemptions.
Frequently asked questions
Which plan do I need for the public API?
The XL plan; in the smaller ones no API key can be generated. XL costs 32.90 euros net per month at list price (as of September 2026). Using the interface itself costs nothing extra, so you do not pay per request or per document.
Can I connect eBay, Stripe or Amazon directly?
No, for sales and payouts there is no built-in connection. You book them manually under finances and transactions, or you use a partner integration such as Billbee; with very many documents per payout, Lexware recommends services like PayJoe or Miracle Sync. The Amazon Business import in pilot operation is a different thing: it pulls in purchase receipts, not marketplace revenue.
Why do I have to retrieve my bank transactions manually?
Because the XS2A interface under PSD2 may request a TAN on every synchronisation. If retrieval ran in the background, those requests would go unanswered, and several of them can block online banking access. Accounts with their own interface, such as Holvi, Pleo, Pliant and PayPal, sync automatically.
How do I restrict an API key?
At the moment you create it, because the rights cannot be changed afterwards. Instead of a key with all permissions you assign individual ones, and only the ones the connected service genuinely needs. Create a separate key per use case as well, each with its minimum rights.
What happens if my API key falls into the wrong hands?
Delete it immediately in the public API administration, then it stops working, and create a new one. After that you check what it was allowed to do: every permission it had is a place to look. Contacts, documents and files have a modification date, which is how you find entries from the period in question. Also reckon with data that was read and downloaded, which cannot be taken back; the draft default limits only part of it.
Where to go from here
Start with the question of which data travels from one system to another by hand today. Usually there are two spots: contacts maintained twice, and invoices that are created somewhere and then typed up again. For the first there is almost always a ready-made connection; for the second it is worth asking whether the draft should be created where the information comes from. If you are looking at the API route, get three things straight: your plan, the permissions your case really needs, and a place for the key outside your project folder.
Which tasks can be handed over is covered in Which Tasks You Can Hand Off to AI, and what this looks like in a one-person business is in AI for Freelancers: What Pays Off. The finished quote and invoice employee, course included, is in my community Claude Practitioners.
