viter.io Start Your Transformation

How do German audit firms run engagements in Jira?

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

From the independence check and the yearly rollover, to chasing the client, der Mandant, for documents and analysing what arrives, these are all complex, interdependent steps that have to be managed together to keep an audit on track. The process is highly structured, but making it easy to follow requires relevant tools. Tailoring Jira Service Management, and building bespoke in-house tools, is Viter’s specialty in supporting the work of Wirtschaftsprüfungsgesellschaften.

Running audits on Excel and email isn’t wrong, but it’s a practice that leaves you scattered and the engagement harder to close.

What follows is an example of how an implementation on Jira Service Management supports an audit with automated, scheduled, pre-built operations that still leave room for the auditor’s judgement.

Key takeaways

  • Most of an audit engagement is a request cycle, and Jira Service Management models it natively: a client portal, a request type per document class, queues, approvals, and a history on every field change.
  • The audit-specific parts are configuration and automation over objects Jira already has, not missing features: the independence check, the questions that change by audit type, and the yearly rollover.
  • Independence is the one with a legal shape. § 319 HGB excludes an auditor where circumstances give rise to a concern of bias, which has to be settled before the mandate is accepted and stay settled for the duration.
  • Delivered for German audit firms: the request portal and its follow-ups, the correct audit form attached per audit type, reminder comments on stalled requests, independence declarations, training and time tracking, and a yearly rollover.
  • Client accounting data stays in Germany. The GDPdU app runs on Forge with every component in Frankfurt, held privately and never used as training material.

How can Jira Service Management be used in an audit?

An audit’s structure already maps closely onto what JSM offers. Consider an audit’s activities:

Independence check. At the beginning of an audit, auditors fill in a form declaring that they have no conflict of interest. Only upon confirmation, every auditor will gain access to work with the audited company. Their confirmed declaration remains as part of the audit’s trail. The legal shape behind it is § 319 HGB, which excludes an auditor where circumstances give rise to a concern of bias (§ 319 HGB).

Audit questions. These can be mapped to tickets with pre-built relevant questions. From a portal that is provided with JSM, or their email, stakeholders can see the status of a request, answer, and see the auditor’s comments for follow-ups. This keeps all relevant communication tight around an audit type within the auditor’s work, and all the different audits are captured within the same yearly cycle’s work.

Yearly cycle of requests. Working on a long engagement, every year, the same questions need to be repeated. This can be supported by JSM’s own capabilities of archiving and duplicating the tickets for a new cycle. While this process guards you against heavy manual labour, it can also be fully automated with in-house developed tools, matched to your tailored specifications.

The JSM solution maintains all the history, and a log for changes and approvals.

What has been built for German audit firms so far?

A JSM portal running the request cycle end to end, and the audit-specific pieces around it. Automation attaches the correct form to a request based on that client’s audit type, so the questions asked are the ones the engagement actually needs. Requests that stall pick up a reminder comment on the request itself rather than an email nobody keeps. The rules run across the projects instead of being copied into each one, which is what stops a near-identical rule piling up in every client file.

With that, requests are also set internally, for the flow of independence declarations, keeping and tracking staff’s training records and time recorded against both the auditor and the client it was spent on. The rollover opens the new year’s file, related to the historical path, allowing auditors to review similar past requests.

In addition to Jira’s main capabilities, we have also built AI agents with full traceability and data privacy in mind, to allow auditors to query the data from the customer in plain language (German or English), saving manual overhead time. For example, the GDPdU agent allows you to query DATEV (and other files) with plain language, directly from within Jira, keeping the entire flow simple and direct, with no context switch to other systems.

Where does the client’s data actually sit?

In Germany. Jira and JSM allow for data residency in Germany on their own infrastructure (data residency). For GDPdU (and other hosted solutions), hosting is done within Germany and the actual data of the customers actually never leaves Germany.

When does this not pay for itself?

When one partner already knows every open item. A portal adds ceremony and removes nothing, and the spreadsheet is genuinely fine right up to the point where two people disagree about what is still outstanding. Wait for the disagreement.

If your audit software already contains the entire flow’s engagement. Moving the request management into Jira splits the record across two systems, and the justification needs to be greater for having a split record. The case for Jira is strongest where the firm is already an Atlassian shop, or where the audit tool has no client-facing side.

And when nobody inside the firm will own the configuration afterwards. The rollover stops the first January nobody presses the button, forms drift out of step with the audit types, and a half-abandoned Jira is harder to reconstruct an engagement from than the mailbox it replaced. Settle who owns it before the build, not after.

Frequently asked questions

Can Jira Service Management run client-facing document requests for an audit?
Yes, and it needs no development to do it. The client gets a portal, each class of document becomes a request type with its own form and due date, and the firm gets queues, approvals and a field-level history without configuring anything unusual. What you should check before committing is the permission model: an audit practice needs one client’s file invisible to the team working another, and that is a scheme decision made at setup rather than a switch flipped later.
How do you stop last year’s audit file from being disturbed when the new one opens?
By making the rollover a mechanism rather than a habit. The closed year stays as it is, permissions and all, and the new year’s file is opened alongside it with the items that genuinely carry over brought across. Doing it by hand works until the January somebody is on leave. Doing it as an automated rollover means the closed file is never the thing being edited, which is the property that matters when the engagement is later reviewed.
How is auditor independence tracked in a system like this?
As a record per staff member per client, with a chase attached to it. § 319 HGB excludes an auditor where circumstances give rise to a concern of bias, and it has to hold from before the mandate is accepted through to the end of the engagement (§ 319 HGB), so a declaration signed once and filed is not really evidence of anything. What makes it workable is that the declaration is a request like any other: it has an owner, a due date, and a follow-up that fires when it is outstanding.
Where does the data live, and can we choose the region?
In your Jira site’s own region, and yes. A Forge app stores what it stores inside Atlassian’s infrastructure, following the region already set for the site (data residency). Germany is available as that region, which is why every component of the GDPdU app sits in Frankfurt. What it reads is held privately and never becomes training material. Ask any vendor the same question in that order: which region, which components, and what happens to the data afterwards.
We already use dedicated audit software. Does this replace it?
No, and it should not try. Audit software owns the methodology, the working papers and the opinion, and none of that belongs in a ticket system. What Jira takes over is the traffic around the engagement: what has been asked for, who owes it, what is late, who signed off, and what the client can see for themselves. If your audit tool already does the client-facing half well, the honest answer is that you do not need a second system for it.
Do these pages mean you only work with German firms?
No, but the audit work described here was built for the German market and the vocabulary follows from that. GDPdU exports, § 319 independence and the annual rollover are shaped by German rules, so a firm outside that regime gets the request cycle, the follow-ups and the tracking without the compliance-specific parts. Worth saying which regime you are in early, because it changes how much of the below is relevant rather than whether any of it is.

Take one engagement that is running now and write down what is still outstanding and where each item is recorded. If the answers all live in one system, you are already fine. If they are spread across a mailbox, a spreadsheet and somebody’s memory, a free call will sort that list into what an administrator can set up next week and what needs building. 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.