How a WISO Steuer tax case is reachable: the buhl:Konto sync layer and the ELSTER retrieval path

Every WISO Steuer return is a Steuerfall — a tax case — and the case does not live on the phone. It lives in a buhl:Konto, encrypted on Buhl's servers in Germany, with the phone, tablet, desktop and Steuer-Web clients all pointed at the same cloud copy. That single fact decides the integration. You do not integrate a device; you integrate an account-bound dossier that the German tax office partly fills in by itself.

For an integrator the interesting part is what flows into that case. WISO's Steuer-Abruf pulls structured records straight from the tax administration — wage-tax certificates, pension notices, insurance contributions — and the app recomputes an expected refund after each entry. The authorized way to that data is to work the account's own sync traffic against a consenting buhl:Konto, with the ELSTER side modelled on the tax administration's documented client. Below is exactly what is reachable and what we hand over.

What the account holds

These are the surfaces WISO Steuer actually exposes once a buhl:Konto is signed in. Names follow how Buhl and the German tax administration label them.

Authorized routes into a WISO Steuer tax case

Route A — Protocol analysis of the buhl:Konto sync layer

The app authenticates a buhl:Konto and synchronises the case to and from Buhl's German servers. We map that authenticated traffic against a consenting account. This reaches the whole case: declared figures, Steuer-Abruf results, uploaded receipts and the running refund number. Effort is moderate. Durability is good, because the desktop, web and mobile clients share one sync contract and Buhl has a reason to keep it stable. The consenting account and the capture environment are set up with you during onboarding.

Route B — The ELSTER/ERiC retrieval and submission path

Steuer-Abruf and the actual filing run through ELSTER's ERiC client, the German tax administration's own toolkit. The open-source Erica wrapper documents the operation set in the open — submit a declaration, request, activate and revoke an activation code — and uses a certificate file plus a Swagger-described API. We implement against that documented protocol with the user's ELSTER certificate. This is the route when an integrator needs the official acknowledgement or the certificate-backed retrieval rather than the app's cached copy. Effort is higher because of certificate handling and the postal Freischaltcode; durability is high because the interface is official and versioned.

Route C — Native cross-device export

WISO already exchanges case data between desktop, Steuer-Web and the app. A consenting user's exported case file is the lowest-effort fallback for a one-off migration, not a live sync. We would reach for it only when a single snapshot is all a project needs.

In practice Route A is the working core for anything ongoing — it sees the case the way the user does — and Route B is added on top wherever an integrator must prove a return was lodged or pull tax-office certificates directly. We would say so plainly in the scoping call rather than bury it in a matrix.

A look at the session and sync calls

Endpoint paths and field names below are illustrative; the exact shapes are confirmed during the authorized build against a consenting buhl:Konto.

# 1. Authenticate the buhl:Konto (token/cookie chain reconstructed during the build)
POST /account/v1/session
  { "email": "<user>", "secret": "<user-supplied>", "device": "studio-capture" }
-> 200 { "access_token": "...", "konto_id": "k_…", "sync_cursor": "…" }

# 2. List the tax cases bound to that account
GET /steuer/v1/cases?year=2024
  Authorization: Bearer <access_token>
-> 200 [ { "case_id": "c_…", "year": 2024, "status": "in_progress",
           "refund_estimate": { "amount": "…", "currency": "EUR" } } ]

# 3. Pull the Steuer-Abruf records the tax office returned into the case
GET /steuer/v1/cases/c_…/abruf
-> 200 { "lohnsteuer": [ … ], "renten": [ … ], "versicherung": [ … ],
         "kapitalertraege_freistellung": [ … ], "retrieved_at": "…" }

# 4. ELSTER side — submission acknowledgement (modelled on the ERiC operation set)
GET /steuer/v1/cases/c_…/transfer
-> 200 { "transferticket": "…", "elster_protocol": "…", "filed_at": "…" }

# Error handling we wire in: re-auth on 401, respect the single-writer
# lock the konto enforces (no concurrent device edits), back off on Abruf
# pending until the postal Freischaltcode is active.
      

What the build hands you

• An OpenAPI/Swagger specification of the reconstructed buhl:Konto endpoints — session, case list, case detail, Steuer-Abruf pull, transfer acknowledgement.
• A protocol and auth-flow report covering the token/cookie chain for the account and the certificate handling for the ELSTER/ERiC path.
• Runnable source in Python or Node.js for login, case enumeration, case fetch, the Steuer-Abruf read and capture of the ELSTER acknowledgement.
• Automated tests run against a consenting account so behaviour is pinned, including the single-writer lock and the Abruf-pending state.
• Interface documentation, plus data-retention and minimisation guidance written for German tax data specifically.

Each deliverable is tied to a surface above — nothing generic, nothing you cannot run on day one.

German tax-data law and how we work inside it

This is not open banking and there is no AIS regime in play; a tax case is not a payment account. The governing frame is GDPR/DSGVO together with the Abgabenordnung. Section 2a AO widens the data-protection scope around tax records, and Section 87d AO requires prior identification before a digitally signed return is transmitted — which is why the Steuer-Abruf activation uses a postal Freischaltcode or an existing ELSTER certificate. We work only with a consenting account holder's own case, keep consent and access records, sign an NDA where the client needs one, and minimise to the case fields the integration actually uses. Tax data is among the most sensitive a person holds; Buhl itself encrypts it at rest on German servers, and our handling matches that posture.

What we account for on this build

Two things on WISO specifically shape how we engineer it.

First, the buhl:Konto enforces a single-writer rule — it deliberately blocks simultaneous edits from two devices to keep the cloud case consistent. We design the sync to cooperate with that lock rather than fight it, so the integration reads cleanly and never races a user who has the app open.

Second, Steuer-Abruf has an activation gate: a first retrieval depends on the postal Freischaltcode arriving, or on an already-active ELSTER certificate. We stage the build so the live data path comes online when the consenting account's retrieval is actually active, and the access setup is arranged with you during onboarding rather than left as a loose end.

One more: WISO ships a yearly product line and the German tax year changes field sets per Veranlagungszeitraum, so we wire a maintenance check that re-validates the schema when the year rolls and when ELSTER versions its forms.

Where this gets used

• A payroll or HR platform reconciling its own records against the Lohnsteuerbescheinigung figures a user pulled via Steuer-Abruf.
• A lending or advisory product reading the case's computed refund as a soft income signal, with the user's consent.
• A document pipeline ingesting the receipt photos a user uploaded into the account.
• An accounting product capturing the ELSTER transfer ticket as machine-readable proof a return was filed.

Working with us on this

Source-code delivery for a WISO build starts at $300, inside a one-to-two-week cycle: you receive the runnable integration, the OpenAPI spec, the protocol report, tests and documentation, and you pay only after delivery once you are satisfied with it. If you would rather not run it yourself, our pay-per-call hosted API is the other model — we operate the integration and you are billed per call with no upfront fee. You give us the app name and what you want out of a WISO tax case; the consenting account, certificate setup and compliance paperwork are handled with you as part of the engagement. Start the conversation at /contact.html.

Screens from the app

What was checked, and when

This mapping was put together on 19 May 2026 from Buhl's own product documentation for the Steuer-Abruf data set and the buhl:Konto cloud model, the German tax administration's ERiC client as documented in the open-source Erica wrapper (its GitHub repository was archived 23 July 2025), the Federal Ministry of Finance line on data protection in tax administration, and the app's Play Store listing for the package identifier and vendor. Citations: Buhl — Steuer-Abruf data set, digitalservicebund/erica (ERiC wrapper), BMF — data protection in tax administration, Google Play listing.

OpenBanking Studio · integration desk notes, May 2026.

Other German tax apps in the same orbit

An integrator rarely cares about one tax app in isolation; a unified tax-data layer usually has to speak to several. Named here for ecosystem context only, not ranked:

• ELSTER — the tax administration's own filing portal; the certificate and submission backbone every German tax tool ultimately touches.
• Taxfix — conversational, question-led filing aimed at employees, with server-side answer state per user.
• SteuerGo — English-capable web filing covering cross-border cases, account-bound returns.
• Wundertax — guided filing geared to specific occupations and immigration-related deductions.
• Smartsteuer — web-based filing for standard and moderately complex returns held in an account.
• CHECK24 Steuer — free filing with photo document upload and an assistant, account-stored cases.
• Lohnsteuer kompakt — browser-based return preparation with stored multi-year history.
• Steuerbot — chat-style return assistant for salaried filers with server-side session data.
• Zasta — connects a user to a tax adviser who prepares the return on their behalf.

Questions integrators ask about WISO Steuer

Does the Steuer-Abruf data come from WISO or from the tax office, and can it be pulled programmatically?

The Steuer-Abruf records originate at the German tax office, not inside WISO. The app requests them through the tax administration's interface and stores the resulting Lohnsteuerbescheinigung, pension, insurance and capital-gains figures inside the buhl:Konto case. We reach them from the case side, against a consenting account whose Steuer-Abruf is already activated, so the integration reads what the user could already see in the app.

A user keeps the same tax case on the phone and in Steuer-Web — does the integration follow the device or the account?

It follows the buhl:Konto. The case is held encrypted on Buhl's servers in Germany and the phone, tablet, desktop and Steuer-Web clients are all views onto that one cloud copy. Our integration reads the account-side case, so it does not matter which device the user last opened.

Can you capture the ELSTER acknowledgement after a return is filed?

Yes. The submission path runs through ELSTER's ERiC client, which returns a transfer protocol and ticket per filing. We model that path on the documented ERiC operation set and capture the acknowledgement so a downstream system has a proof-of-filing record tied to the case.

We already operate a buhl:Konto we use for testing — how does that factor into a build?

It helps. A consenting account you control becomes the build target — we capture the authenticated sync against it during onboarding. If you would rather we set one up, that is arranged with you as part of the work; either way the app name and what you want from the case is all we need to begin.