KaFE Refund Application -- Response

KaFE Refund Application Response -- a module of the OpenFASTER family,

This version:
https://openfaster.org/kafe/response
Issue Tracking:
GitHub
Editor:
Julian Nalenz

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2 September 2026, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

This document is for developers implementing a KaFE integration against this platform -- banks never see this raw decision notice directly. It documents kafe-va.xsd, the payload BZSt uses to communicate the actual tax-assessment decision (approval or clawback) on a submitted KaFE refund application. This document describes payload shape only, not a working retrieval flow -- see the disclosure below.

1. Not yet retrievable: a disclosure

BZSt has not yet published the transport for this payload. Per the official DIP-KAFE v1.4.0 communication handbook, section 6.2: The DIP envelope scheme for the notification of administrative files is not available yet. Only kafe-va.xsd’s payload shape is published (schemaVersion 1.0.0, unrevised since its 2023-11-20 creation, even as the request-side schema has gone through five revisions). This document describes that payload shape so implementers know what to expect once retrieval becomes possible -- it is not a working integration today.

2. The KaFE Refund Application Response format

One KAFE-VA delivery batches one or more Steuerbescheid (decision notice) entries; each answers exactly one prior Erstattungsantrag, correlated via the Bezugsantrag back-reference block — four distinct fields (TransferticketId, AntragId, RegistrierNr, KennNr), a richer correlation than KAFE-RM’s own single-AntragId correlation documented in the Request document.

2.1. Source schema

This document’s field definitions and enumerations are generated directly from BZSt’s published kafe-va.xsd — regenerating from an updated XSD keeps this document in lock-step with the BZSt source, the same way the Request document is generated from kafe.xsd.

2.2. Approval and clawback semantics

SummeAbrechnung’s sign carries the decision: a positive amount is a refund in the applicant’s favour; a negative amount is a payment debit (clawback). Faelligkeit (a due date) is only present when the amount is negative — BZSt’s own documentation warns that late-payment penalties apply if the debit isn’t settled by that date. BescheidArt distinguishes a first decision (ERSTBESCHEID) from a corrected one (KORREKTUR) for the same application, but is not chained to the specific earlier notice it corrects — only back to the original Erstattungsantrag, via Bezugsantrag. Hinweise is only a boolean flag recording whether the notice carries additional remarks; the substantive legal reasoning for any decision, in every case, exists only inside BescheidPdf (a base64-encoded PDF) — never as structured XML.

3. Decision notice fields

One KAFE-VA delivery batches one or more Steuerbescheid (decision notice) entries; each answers exactly one prior Erstattungsantrag, correlated via the Bezugsantrag back-reference block. Fields below are grouped by where they appear in that structure.

3.1. Decision notice envelope

Field Requiredness Type / Allowed values Description
BescheidId Optional UUID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) UUID, die den Bescheid eindeutig kennzeichnet.
BescheidArt Required Text Kennzeichnung, ob es sich um einen erstmaligen oder korrigierten Bescheid handelt.
SummeAbrechnung Required Decimal (2 decimals) Abrechnungsbetrag. Negativer Betrag bei Zahllast (Rückforderung).
Faelligkeit Optional Date (YYYY-MM-DD) Fälligkeit der Forderung (nur bei Rückforderung)
Hinweise Required Boolean (true / false) Kennzeichnung, ob der Bescheid Hinweise enthält.

3.2. Reference back to the original application

Field Requiredness Type / Allowed values Description
TransferticketId Required Text (1-170 characters) TransferticketId der Lieferung, in der der Antrag enthalten war.
AntragId Required UUID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) In der Lieferung angegebene UUID des Antrages.
RegistrierNr Required Text (9 characters, BZSt-assigned) Aktenzeichen unter der der Antrag beim BZSt registriert wurde (Registriernummer).
KennNr Required Numeric string (8-digit BZSt withholding-tax number) Kenn-Nummer des BZSt

3.3. Per-income refund breakdown

Field Requiredness Type / Allowed values Description
ErtragId Required Integer Im Bezugsantrag angegebene ErtragId (laufende Nummer des Ertrags).
ErstattungKapESt Required Decimal (2 decimals) Erstattungsbetrag Kapitalertragsteuer
ErstattungSolZ Required Decimal (2 decimals) Erstattungsbetrag Solidaritätszuschlag

4. Enumerations

Every value that an enum-typed field in the decision notice may carry, with its meaning.

4.1. BescheidArt

Value Meaning
ERSTBESCHEID First (initial) decision notice for a given Erstattungsantrag.
KORREKTUR Corrected decision notice superseding an earlier one for the same Erstattungsantrag -- not chained to which specific earlier notice it corrects (only back to the original application, via Bezugsantrag).

5. Known gaps in this schema

Worth disclosing rather than silently working around: kafe-va.xsd’s own schemaVersion has been fixed at 1.0.0 since its creation on 2023-11-20, unrevised even as the request-side kafe.xsd has gone through five revisions (through 1.4.0). There is no PreviousBescheidId-style field chaining a KORREKTUR notice to the specific earlier Bescheid it corrects — only Bezugsantrag’s reference back to the original application. And unlike MiKaDiv’s own Response document, which at least had one real sample XML to verify against, no real BescheidPdf/Steuerbescheid sample has been examined during this module’s research — this document’s coverage is derived entirely from the schema’s own structure, not confirmed against a real example.