Which reporting obligations do you work on?

Reporting with fixed dates in the environment of capital gains tax and withholding tax: MiKaDiv under sections 45b and 45c EStG, tax reporting and submissions to the BZSt, and looking ahead, the register and reporting obligations under FASTER from 2030. Other regulatory reporting topics we clarify in the initial conversation – and we say honestly where our domain ends.

From when does MiKaDiv apply, and which deadlines have to be met?

MiKaDiv applies to capital income received after 31 December 2026; the procedure starts on 1 January 2027. Reports are due in the following year: certified reports by 31 March, other reports by 30 April, the aggregate report under section 45c EStG by 31 July (source: BZSt).

Who is obliged to report under MiKaDiv – the KVG too?

Those obliged to report are the paying agents and credit institutions under section 45b EStG, central securities depositories under section 45c EStG and domestic issuers under section 45b(9) EStG. KVGs and fund accounting are usually not the reporting party themselves, but they deliver the custody-chain data – and bear the consequences for withholding-tax reclaim if it is incomplete. The legal classification of your firm is for your tax advisers; we design the process.

Are you UX designers or business analysts?

Both, in one role: UX consultant and business analyst with a focus on regulatory reporting. We write functional concepts, user stories and test cases, and we design the workflows in which they are lived. For intermediaries, in keywords: requirements engineering, requirements analysis, process modelling (BPMN), usability testing, Figma.

Do you need access to our production data?

No. We work with observation in the business department, anonymised examples and synthetic test data. For prototypes and UAT, realistic but invented records are sufficient.

How do you handle corrections and rejections?

We model the correction run as a workflow of its own: read the BZSt feedback, assign the error to its business meaning, correct the record, release again, submit again – all within the audit trail. The status model knows the state ‘to be corrected’ explicitly instead of hiding it in an Excel column.

Do you work for the vendor or for us?

Only for one side per project. If a KVG or depositary engages us for the implementation, we work for them – not for the vendor. Information from one engagement does not flow into another.

How quickly do we see results, and how long do you stay?

The as-is analysis delivers a process picture with prioritised risk points within a few weeks. After that, scope follows the effective date and the module – from functional concept to hypercare after the first reporting cycle. We estimate this together in the initial conversation.

Reporting obligations and regulatory reporting

Making reporting obligations usable – UX and implementation for regulatory reporting.

For fund accounting, tax and operations at KVGs, depositaries and custodian banks – and for vendors of reporting modules. We design the workflows behind MiKaDiv, tax reporting and submissions to the BZSt so that expert users can find, check, correct and release records on time. The result: reports that go out punctually, traceably and without a parallel spreadsheet.

Book an initial conversation How we work

In short

Beabstracto is a UX studio in Munich for complex expert systems. For regulatory reporting – MiKaDiv under sections 45b and 45c of the German Income Tax Act (EStG), tax reporting, submissions to the Federal Central Tax Office (BZSt) – we design the workflows in which expert users find, validate, correct, release and track reports. We add implementation support on the client side: as-is analysis, functional concept, test concept and UAT, key-user training, go-live and hypercare. Our clients are KVGs (German asset management companies), depositaries and custodian banks, as well as vendors of reporting modules. An as-is analysis delivers the first reliable results within a few weeks.

We work as UX consultant and business analyst for regulatory reporting at the interface of business department, development and vendor.

At a glance

Role: UX consultant and business analyst regulatory reporting, requirements engineer, implementation and rollout support
Services: UX for reporting workflows (Manage Reports), functional concept and requirements analysis, test concept and UAT, key-user training, go-live and hypercare
Industries: Asset management companies (master KVG, service KVG), depositaries, custodian banks and paying agents, vendors of reporting and withholding-tax software
Systems: MiKaDiv reporting modules, withholding-tax reclaim software, interfaces to fund accounting and back office (vendor-neutral)
Location: Remote, Munich, on site by arrangement
Languages: German, English, Portuguese

Why does reporting fail in daily operations – even when the format is ready?

The format is known, the interface is in place – and it still gets tight on the deadline. These are the situations we hear most often.

Fixed date, loose process
MiKaDiv reports have fixed deadlines in the following year: 31 March, 30 April, 31 July. The path there still runs through Excel, e-mail and word of mouth. Who released what, and when, is recorded nowhere.
Custody chain at the wrong granularity
Data arrives from depositaries and sub-custodians at different depths and with different histories. The chain is supposed to be traceable per holding and per income event – often it exists only in the heads of a few individuals. An error here hits both the report and the reclaim.
Validation errors without translation
The system returns error codes that nobody in the business department can interpret without a developer. Corrections end up in tickets instead of in the workflow. Under SLA pressure, people guess instead of checking.
Four-eyes principle on paper only
The internal policy requires a release, but the tool has no checkpoint. So the file goes out by e-mail and someone replies ‘ok’. For an audit, that is not an audit trail.
New module, no implementation
The vendor delivers the reporting module and the business department is expected to use it productively from January. Functional concept, test cases, key users and training are missing – and nobody translates between business department and development.

Which dates set the pace

Regulatory reporting has no moving targets. These dates are fixed.

1 Jan 2027
Start of the MiKaDiv procedure; it applies to capital income received after 31 December 2026: 31 Mar · 30 Apr · 31 Jul
Reporting deadlines in the following year: certified reports, other reports, aggregate report under section 45c EStG: 1 Jan 2030
Application of the FASTER Directive with a register and reporting obligations for certified financial intermediaries; transposition by 31 December 2028: 11
reusable UX foundations – from glossary to KPI framework – from a MiKaDiv reporting project

What we actually deliver

Three services that can be combined – depending on whether you are introducing a reporting module, building one, or making your existing reporting process robust.

Manage Reports: find, validate, correct, release, track

We design the workflow in which expert users process large volumes of reports under SLA pressure: an explicit status model per record, filters and bulk actions for high-volume operation, an error mapping that translates validation errors into business language, and a four-eyes checkpoint before submission to the BZSt. Every decision remains traceable in the audit trail. For vendors of reporting modules we work as an external UX consultancy on the product; for KVGs and depositaries, on process and configuration.

Status model and state transitions per report (open, under review, released, submitted, accepted, to be corrected)
Error mapping: validation error → business meaning → correction path
Information architecture and main journeys (Manage Reports, report detail, correction run)
Four-eyes checkpoint and release logic before submission
Clickable prototype with realistic data for usability tests with expert users

Manage Reports: find, validate, correct, release, track

Status model and state transitions per report (open, under review, released, submitted, accepted, to be corrected)
Error mapping: validation error → business meaning → correction path
Information architecture and main journeys (Manage Reports, report detail, correction run)
Four-eyes checkpoint and release logic before submission
Clickable prototype with realistic data for usability tests with expert users

From the regulatory text to an implementable functional concept

As business analyst and requirements engineer, we translate the reporting obligation, the communication handbook and internal policies into requirements that development and vendors can implement. We model processes end to end (BPMN), write user stories with acceptance criteria and derive test cases from them. The regulatory mapping – which requirement forces which system behaviour – is documented, not assumed.

As-is analysis and process capture with the business department
Functional concept including regulatory mapping (sections 45b, 45c EStG, communication handbook, internal release rules)
User stories, acceptance criteria and test cases for UAT
Glossary and taxonomy as a shared language for business department, development and vendor
Interface requirements towards fund accounting, back office and depositary

Implementation support until the process runs without us

We support the introduction of a reporting module on the client side – from the test concept through UAT to go-live and hypercare. Key users are involved and trained early so that the knowledge stays in-house. The measures are simple: reports released on time, fewer queries to the vendor, no more parallel spreadsheet.

Test concept and UAT planning with business test cases
Key-user concept, training materials and user training
Go-live checklist, cutover plan for the effective date and hypercare support
Rollout reporting to project management: open items, risks, acceptance
Handover to regular operations with documented work instructions

Domain language

These terms shape everyday reporting work. We speak them so that workshops do not have to start with the basics.

Reporting obligation and reporting deadline
MiKaDiv (sections 45b, 45c EStG)
Federal Central Tax Office (BZSt)
Communication handbook and XML schema
ELMA and transmission channel
Custody chain, sub-custodian, central securities depository
Paying agent and custodian bank
Tax certificate and aggregate report
Granularity and data quality
Validation, correction report, rejection
Four-eyes principle and release
Audit trail and traceability
SLA and status model
FASTER, eTRC, certified financial intermediary

MiKaDiv: The German notification procedure for capital gains tax on dividends from shares and depositary receipts under sections 45b and 45c EStG. Applies to capital income received after 31 December 2026; reports go to the BZSt.
Custody chain (Verwahrkette): The chain of depositaries and sub-custodians between issuer and investor, per holding and per income event. For MiKaDiv it must be reported traceably; for withholding-tax reclaim it is the same data basis.
Communication handbook (Kommunikationshandbuch): The BZSt’s technical specification for the reporting procedure: data format (XML), message structure, size limits and transmission channel. For MiKaDiv there are separate handbooks for financial market participants (FM) and issuers (FB).
Aggregate report (Sammelmeldung): Summary report under section 45c EStG, due by 31 July of the following year. It complements the certified and other reports under section 45b EStG, due by 31 March and 30 April respectively.
Four-eyes checkpoint: A mandatory step before submission in which a second person samples the generated report against the custody chain and releases it. Not a brake on automation but its safety net.
Error mapping: Assignment of every validation or rejection error to its business meaning, the affected data field and the correction path. Turns a code into an action.
Status model: The explicitly defined states of a report – open, under review, released, submitted, accepted, to be corrected – and the permitted transitions between them, including the role allowed to trigger each one.
FASTER: Directive (EU) 2025/50 on faster and safer relief of excess withholding taxes: digital tax residence certificate (eTRC), relief at source or quick refund, a national register of certified financial intermediaries with reporting obligations. Transposition by 31 December 2028, application from 1 January 2030.

How we work

Six steps that recur in every reporting project – on the client side as on the vendor side.

1
As-is analysis in the business department
We observe how the report actually comes into being today: sources, Excel lists, word of mouth, releases. Together with fund accounting, tax and operations we document process, roles and pain points. Output: process picture, risk points, prioritised open questions.
a few weeks
2
Shared language and regulatory mapping
Glossary, taxonomy and the assignment of requirement to system behaviour – sections 45b and 45c EStG, communication handbook, internal policies. Business department, development and vendor agree on the same terms before any screens exist.
3
Functional concept and journeys
End-to-end processes instead of feature lists: Manage Reports, report detail, correction run, release. From these come the status model, error mapping, information architecture and user stories with acceptance criteria.
4
Prototype and usability test with expert users
A clickable prototype with realistic data, tested with the people who will later work against the deadline. We check whether status, errors and release are understood without explanation – and correct before implementation.
5
Test concept, UAT and training
Test cases from the functional concept, UAT with key users, training materials for the business department. Acceptance means: a report runs from data delivery to release without a detour through Excel.
6
Go-live and hypercare
Cutover on the effective date, support through the first reporting cycles, sharpening of statuses and error texts from real operations. Handover to regular operations with work instructions – and proof that the parallel spreadsheet is gone.

What we have learned

From our UX consultancy for the vendor of a withholding-tax reclaim software – and from reporting processes where the format was long settled but the data was not.

01
Language first, screens second
Domain knowledge was spread across developers, product owner and management; personas were implicit and unprioritised. A glossary, a taxonomy and the regulatory mapping (BZSt, ELMA, MiKaDiv, SLAs) brought everyone to the same table. Only then could interface behaviour be argued about productively. Start with screens and you debate opinions; start with terms and you debate decisions.
02
Workflows instead of features
Reporting was initially discussed as a list of functions. When we drew the flow end to end – data delivery, validation, correction, release, submission, feedback – failure points and SLA risks became visible that no single feature would have covered. Failure points became UX tensions, tensions became design principles, principles became interface behaviour.
03
Errors have to become actions
A validation error that appears only as a code creates a ticket. An error that says which field at which depositary is affected and what the correction path looks like creates a correction. The error mapping was one of the foundations that let developers model filters, validation, bulk actions and the report-detail structure concretely.
04
The checkpoint is the safety net of automation
A fully automated submission reports even when the data would actually say ‘no’. A four-eyes checkpoint before submission costs minutes and prevents a systematic error in the custody chain from carrying into the report. Anyone who has once seen a report corrected before submission trusts the next one more – and does not build a parallel spreadsheet.
05
A prototype with realistic data decides more than a concept
A high-fidelity prototype of the Manage Reports journey was treated by stakeholders at large banks as production software. It clarified the MVP scope, gave developers a concrete model for report detail and audit trail, and made every UI decision traceable to persona, risk scenario and principle. Concepts rarely convince experts; experienceable flows do.

Experience

Public cases and articles from the withholding-tax and reporting environment. No names of banks, KVGs or depositaries.

Withholding-tax reclaim software

MiKaDiv reporting module: UX consultancy for the vendor

As an external UX consultancy for the vendor of a withholding-tax reclaim software, we developed the UX foundations for a new MiKaDiv reporting module: shared language, personas, process and error mapping, information architecture and a prototype of the Manage Reports journey. Eleven reusable foundations, from glossary to KPI framework.

→

Article

MiKaDiv: why the custody chain has to become visible now

What is operationally hard about MiKaDiv, why granularity and quality of the custody chain are the sensitive point, and which checklist helps in the months before the effective date.

→

Article

The Excel list as a symptom: back office meets tax

The parallel Excel list arises where deadline, missing document and case status are not in the same place – usually at the interface between back-office and tax system.

→

Professional references

We orient our work on these sources; we claim no certification and no institutional relationship.

Federal Central Tax Office (BZSt) · 2026

MiKaDiv notification procedure – procedure page and communication handbook MiKaDiv FM

Procedure description, FAQ and technical handbook (XML format, message structure, deadlines).

German Bundestag, Federal Law Gazette I p. 1259 · 2021

Act on the Modernisation of Relief from Withholding Taxes and the Certification of Capital Gains Tax (AbzStEntModG), sections 45b, 45c EStG

Introduces the legal basis of MiKaDiv; after postponement by the Annual Tax Act 2024, applicable from 1 January 2027.

Council of the European Union · 2025

Frequently asked questions

Which reporting obligations do you work on?: Reporting with fixed dates in the environment of capital gains tax and withholding tax: MiKaDiv under sections 45b and 45c EStG, tax reporting and submissions to the BZSt, and looking ahead, the register and reporting obligations under FASTER from 2030. Other regulatory reporting topics we clarify in the initial conversation – and we say honestly where our domain ends.
From when does MiKaDiv apply, and which deadlines have to be met?: MiKaDiv applies to capital income received after 31 December 2026; the procedure starts on 1 January 2027. Reports are due in the following year: certified reports by 31 March, other reports by 30 April, the aggregate report under section 45c EStG by 31 July (source: BZSt).
Who is obliged to report under MiKaDiv – the KVG too?: Those obliged to report are the paying agents and credit institutions under section 45b EStG, central securities depositories under section 45c EStG and domestic issuers under section 45b(9) EStG. KVGs and fund accounting are usually not the reporting party themselves, but they deliver the custody-chain data – and bear the consequences for withholding-tax reclaim if it is incomplete. The legal classification of your firm is for your tax advisers; we design the process.
Are you UX designers or business analysts?: Both, in one role: UX consultant and business analyst with a focus on regulatory reporting. We write functional concepts, user stories and test cases, and we design the workflows in which they are lived. For intermediaries, in keywords: requirements engineering, requirements analysis, process modelling (BPMN), usability testing, Figma.
Do you need access to our production data?: No. We work with observation in the business department, anonymised examples and synthetic test data. For prototypes and UAT, realistic but invented records are sufficient.
How do you handle corrections and rejections?: We model the correction run as a workflow of its own: read the BZSt feedback, assign the error to its business meaning, correct the record, release again, submit again – all within the audit trail. The status model knows the state ‘to be corrected’ explicitly instead of hiding it in an Excel column.
Do you work for the vendor or for us?: Only for one side per project. If a KVG or depositary engages us for the implementation, we work for them – not for the vendor. Information from one engagement does not flow into another.
How quickly do we see results, and how long do you stay?: The as-is analysis delivers a process picture with prioritised risk points within a few weeks. After that, scope follows the effective date and the module – from functional concept to hypercare after the first reporting cycle. We estimate this together in the initial conversation.