viter.io Start Your Transformation

How can you query GDPdU in German (or any other language)?

Written by Ben Friedman, Atlassian expert & builder of JAMEs, the AI Jira administrator · Published

AI provides incredible flexibility to query data, GDPdU included, allowing the work to meet German regulations of data residency and privacy.

Answering one question, such as what was posted to an account after the balance sheet date, has normally meant importing the entire export into an analysis tool and writing formal queries. On top of that, answers to complex questions had to be broken into single-step queries.

Our GDPdU agent allows you to ask complex questions in plain language (German, or any other), queries on your behalf, and provides the tracking behind its answer so you can verify it.

Key takeaways

  • GDPdU over a Jira implementation meets German regulatory requirements.
  • In place of the auditor, the agent maps all the data based on the index file, and can support complex questions.
  • Auditors can query the data using spoken language, German or English.
  • Answers and the agent’s work can be tracked and reviewed.
  • The AI component is never exposed to the full data set and never trains on the data.

What is actually inside a GDPdU export?

Flat files, and a description of those files. A GDPdU export is Germany’s standard way of handing accounting records over in machine-readable form: a folder of flat text files plus an index.xml that says what every column in them means. The format exists because German tax law gives the authority a choice about how it inspects a company’s books during an audit: read them on the company’s own system, have the company run the queries and hand over the results, or take the data away on a machine-readable carrier (§ 147 Abs. 6 AO). The third route is the one that gets used. DATEV produces the export as routine, and other accounting systems, ADDISON among them, produce their own conformant version of the same thing.

Audit firms end up with the same file for a different reason. It is the one extract a client’s accounting system already knows how to produce in full, so asking for it is easier and less error-prone than asking for a list of specific reports and hoping the definitions match.

Why does one question about it take so long?

The question is rarely the hard part. Getting into a position to answer it is. The files are one row per record with coded columns, and what those columns mean lives in the index.xml rather than in the data. The working method has been to load the whole thing into an analysis tool built for the job, map the fields by hand, and write a formal query there.

A second cost sits on top of that one, and it is the one auditors feel more often. An analysis tool answers a query, not a question, so anything with several parts to it has to be taken apart first: run one query, read the result, use it to write the next, and reconcile the pieces yourself at the end. Ask which accounts carry postings after the balance sheet date that were not present at the interim review, and you are writing three queries and joining them by hand.

Keep working where your auditors are

Using the agent to meet the auditors where they are helps avoid context switching and keeps all the information tight around the audit itself. An auditor asks inside the Jira issue, gets the answer, and when it is approved the answer is saved in the stream of the ticket.

Later, a reviewer can see exactly what was analyzed, how and why, in the full context of the audit’s data.

Jira is one interface onto the agent rather than the whole of it. The flow set out here is a selected user interface, and the agent can sit behind a different front end. What does not move is the part underneath: the files, the queries, and the trail they leave.

How does the GDPdU agent work?

What follows is the Jira interface example, and it can generally be expanded to meet additional requirements. Four moving parts, in order. It is a Forge app, so it runs on Atlassian’s own infrastructure inside your site. A trigger picks up the export when it arrives and reads the data files and the index file describing them, which is how the agent knows what data it can be asked about.

When a question comes in, the model turns it into queries and those queries run against the loaded data and not inside the model. Results come back capped, and the model reads the capped set to judge whether it has satisfied the question or if more queries are needed. That loop is what answers a multi-part question without an auditor stepping through it manually, and it is also why the model never has the whole file in front of it. The answer, and the queries behind it, are written back into the issue through Forge.

The loading of the files that used to take a couple of hours happens automatically on the GDPdU agent’s side, once, with nobody mapping fields. Formats follow from the standards available in the market, and more can be added.

What are the security measures for the GDPdU agent?

Four of them, and the first matters most to an auditor. Every answer arrives with the queries that produced it, so the reasoning is reviewable rather than asserted. Anyone who doubts a figure can read what was asked of the data and put the same question again. A number with no working behind it does not belong in an audit file, whatever produced it.

The models are Anthropic’s, picked for the terms attached to them. Anthropic’s published commercial terms rule out training on customer content, and nothing from an exchange is held by the model once the conversation is over. A client’s records are read in order to answer the question in front of them and are not accumulated on the model side afterwards.

On a longer run the agent keeps track of its own behaviour. Where the work starts to stretch, it goes back to the auditor to confirm it is still answering the question that was asked, which is the mechanism that keeps it from drifting off the question or hallucinating an answer.

Hosting stays in Germany. Every component of the app is pinned to Frankfurt (data residency), and the infrastructure behind it sits in Germany too, so a client’s accounting records are not leaving the country in the course of being queried. For a practice holding those records under § 147 that is a requirement rather than a preference, and it deserves asking of any tool that touches a client’s books, together with which models see the data and what their provider is permitted to do with it.

What can it not answer?

Anything outside the export. The file is a snapshot of what the client’s system held on the day it was produced, so a question about a posting made since then needs a fresh one. It carries the accounting records and their field descriptions, not the contracts, the correspondence or the minutes those records refer to, and no amount of asking well will conjure those in.

It does not form a judgment either. Returning the entries posted after the cut-off is a query. Deciding whether those are a cut-off error, a legitimate adjustment, or a reason to widen the sample is audit work, and the argument for getting the query back in seconds is that more of the day is left for the part that needs an auditor.

And it does not replace the analysis tool where a real programme of tests is being run. The gain is concentrated on the question asked in passing, which is precisely the class of question that currently gets dropped. If your practice runs mostly structured, repeatable test programmes over these exports, you already have the right tool and this changes little.

Frequently asked questions

Which language do you ask the question in?
Whichever one the engagement runs in. German and English are what the delivered work has used, and the question is read as a sentence rather than matched against a list of accepted phrasings, so the language is not a setting anybody configures. One thing does not follow your choice: the field descriptions inside the export come from the client’s accounting system and are usually German whatever you type.
What files does the agent require?
The export as the accounting system produced it, complete, which means the flat data files together with the index file that came alongside them.
How does it handle incomplete data?
An export is a snapshot of one moment, so incompleteness is usually a gap in the file rather than a fault in the query. Where a period is only partly covered, or the index.xml describes a field the data files never populate, the answer reports what was found and names what was missing instead of reasoning across the gap. A figure quietly assembled from partial data is worse than no figure at all in audit work. If the gap is material, the fix is a fresh export rather than a cleverer question.
How can an auditor verify the answer is correct?
By reading the queries that produced it. Each answer carries the steps behind it, so the check is an ordinary one: does the query ask what you meant, over the right period, against the right accounts. Auditors are already trained to do exactly that review, which is why the trail is worth more than the speed. It is also what lets the exchange stand as working papers rather than as a note somebody happened to take.
How does the agent know what it can query about?
From the index.xml, which is the export describing itself: which files exist, which columns each of them holds, and what those columns mean. Reading that description first is what lets the agent map a question about postings after the balance sheet date onto the real field names in one client’s file. Accounting systems name things differently from each other, and the description is how the difference stops mattering to whoever is asking.
How long is the data kept?
On the model side, not at all: the records are read to answer the question in front of them and nothing from the exchange survives it. On your side, the export sits with the engagement it belongs to, in your own Jira and on infrastructure inside Germany, for as long as that engagement needs it, and it goes when you remove it. Retention is a decision your practice makes under its own rules rather than one the tool makes for you.
Can I use my own AI engine with the agent?
It is possible, but strongly advised against. The most important part of the audit is its quality, and bringing in an agent from the outside risks the testing and assurance that was built into using the adopted Anthropic models.
How does the agent avoid high token spend and AI slop?
The index file defines the search limits for the agent, with the user’s query guiding the search inside them. Slop is kept out by grounding the agent in the actual data through an intermediary layer that steers the search from what the index describes. If a query starts to run the agent into a drift, there is a mechanism in place to pause and re-check with the auditor.
Is GDPdU still the correct name for this export?
In practice yes, in the rules no. The GDPdU were superseded by the GoBD in 2015 and the GoBD have been amended since, most recently in July 2025 (BMF). The export itself did not change name in everyday use, so auditors, tax advisers and software vendors all still say GDPdU export, and the same file also answers to Z3 export and Datenträgerüberlassung. Worth knowing when searching for documentation, because the three terms return different results.
Why do auditors receive a format designed for the tax authority?
Because it is the most complete thing a client’s system will produce on request. The format exists to serve the authority’s right to take accounting data away on a machine-readable carrier during an audit (§ 147 Abs. 6 AO). An audit firm asking for the same export inherits that completeness and a published field description, rather than negotiating over which reports to run and what the columns in them mean. It also means the client’s side of the work is one export they already know how to produce.

If there is a GDPdU export in a folder somewhere and a question you never asked of it because the setup was not worth it, that is the case this was built for. Send the question and the shape of the export and it can be checked against a real file. hello@viter.io

Sources

External claims on this page were checked against these documents in August 2026:

About the author

Ben Friedman is an Atlassian consultant and Forge developer with over 8 years of hands-on Jira work, certified ACP-610, ACP-620 and ACP-120. He has delivered for hundreds of customers across all business verticals, supporting their configuration, administration, and ongoing support and maintenance. Ben is building JAMEs, the AI Jira admin.