MiKaDiv: why the custody chain has to become visible now

MiKaDiv — the reporting duty for capital income and dividends — is one of those topics that sound technically harmless and are operationally anything but harmless. One report, one format, one date. Anyone who limits themselves to mastering the file format misses the point. The real risk sits not in the submission but in the dataset that is submitted: the custody chain behind every report.

This piece describes what is operationally difficult about MiKaDiv, why the custody chain is the sensitive point, and what can be done in the coming months without panicking.

What MiKaDiv is, in plain words

MiKaDiv is a reporting duty under which capital income and dividends are reported to a competent authority. The report concerns income arising in the context of capital gains tax and aims to make the chain of parties along the custody chain traceable. Required to report are domestically listed companies (issuers) under § 45b(9) EStG and the paying agents and credit institutions under § 45b EStG; reports go to the Bundeszentralamt für Steuern (BZSt). (Source: BZSt, DPAii)

As with other reporting duties in finance, it is not only about “whether” a report is made, but about “how exactly”. A report that arrives formally but is incomplete in content does not fulfil the duty. That is exactly where the operational problem begins.

Why the date matters for those still implementing

Reporting duties have a date from which they apply. MiKaDiv first applies to capital income credited to the creditor after 31 December 2026 (§ 52(44b) EStG); the procedure takes effect on 1 January 2027. (Source: BZSt, DPAii)

For a team still implementing, the date means two things. First, there is a hard anchor at which the report must stand — not “soon”, but at a concrete cutoff date. Second, income before that date does not fall under the duty, income afterwards does. Anyone who does not map that boundary cleanly in the system reports either too much or too little, and both are a problem.

Anyone who underestimates the deadline typically plans the format, the interface and the submission — and forgets that between “format is ready” and “data is ready” often lie months. Experience shows that data quality is the bottleneck, not the file format.

The custody chain as the sensitive point

MiKaDiv requires the chain of custodians per position and income event to be traceable. Exactly this dataset — the custody chain — is not available as a clean input dataset in many houses. It sits distributed across custodians, in reports of varying granularity, partly only in individuals’ heads.

Anyone who reports with gaps here produces two problems at once. First, they violate the reporting duty in content, even if the file arrives formally. Second — the less obvious consequence — they damage the basis for withholding-tax reclaim. Reclaim and reporting draw from the same custody chain. Anyone who builds the chain uncleanly for the report builds it uncleanly for reclaim too. An error at this point thus works twice.

From this follows a simple but often overlooked priority: anyone who wants to implement MiKaDiv cleanly should treat the custody chain as a shared input dataset for reporting and reclaim — not as two separate tasks.

Automation without a checkpoint

The temptation to fully automate the report is great. The format is known, the interface stands, the file can be generated and submitted in the background. Automation is sensible — but not without a checkpoint.

A fully automated submission without a human checkpoint has a systematic weakness: it reports even when the data situation would actually say “no”. A system that generates a file cannot decide on its own whether the custody chain is plausible in content. It can only check what was defined as a rule. What is not defined falls through.

That is why a four-eyes checkpoint before submission has proven useful: a person who holds the generated file against the custody chain in a sample before releasing it. It costs minutes, not hours. But it prevents a systematic error in the chain from carrying into the report — and afterwards being hard to take back.

Anyone who sees this checkpoint as “braking the automation” misunderstands it. It is not a contradiction to automation but its safety net. Automation takes over repetition, the checkpoint takes over plausibility. Both together are more stable than either alone.

Checklist for the coming months

Anyone implementing now still has time — but not indefinitely. A plain checklist helps put the order right.

• Name ownership of the custody chain: who in the house maintains the chain per fund and per income event?
• Map the cutoff date cleanly: where in the system is the boundary “income before/after cutoff” drawn, and who checks it?
• Clarify the interface to the custodian: in which format does the chain arrive, with which history, which granularity?
• Establish a checkpoint before submission: who releases the file, by which criteria, with which sample?
• Think reporting and reclaim together: do both draw from the same chain, or does each team maintain its own?
• Map deadlines in the system: certified reports by 31 March, other reports by 30 April, the aggregate by 31 July of the following year (§§ 45b, 45c EStG).

Anyone who works through these points has the operationally relevant levers in view. The file format is the easiest part among them.

A small order helps here: first clarify the data basis, then the interface, then the format. Anyone who reverses the order — first format, then interface, then data — builds on a foundation they have not yet checked. The result is late changes, expensive rework, and a deadline that suddenly moves closer than the plan foresaw.

What happens when the chain is reported with gaps

A gap-filled report rarely shows up immediately. It shows up when a refund is challenged the following year, when a query comes from the specialist department, or when an audit traces the chain. By then the error has settled in the system — and with it the assumption that the chain was correct.

The consequence is usually not an open error message but a creeping loss of trust in one’s own data. The team starts to secure reports additionally, builds parallel lists again, calls the custodian. Exactly what MiKaDiv was supposed to reduce through standardisation is recreated through gap-filled data. The automation runs, the work remains.

That is why the checkpoint before submission is not only a question of correctness but of trust-building. Anyone who has once seen a report corrected before submission trusts the next report more. Anyone who has once seen an error surface only the following year trusts the automation less. Trust grows through experience — and the experience the system delivers has to be early and visible.

What we learn from this

MiKaDiv is not a pure format topic. It is a call to finally have the custody chain as a visible, maintained dataset in the house — not only for the report, but also for reclaim. Anyone who tackles this now solves two tasks at once. Anyone who postpones it pays the bill later in two processes.

If you are currently working out how to set up MiKaDiv operationally — from the data model to the checkpoint before submission — a first conversation is worthwhile. We look at where the custody chain stands today and what it takes to make it report-ready and reclaim-ready at once.