Designing the Intelligence Layer Before the Auditor Arrives
DVAA is a pre audit AI intelligence layer that sits between a company's financial data and its external audit firm. The platform is live with two pilot clients in the German mid market, built by InfinitiBit.
I led UX across the full discovery phase in collaboration with internal stakeholders: structuring the problem space, defining personas and journey maps, framing the two layer AI architecture from a UX perspective, and iterating on the evaluation model based on direct client and domain expert feedback.
My Role & team
Senior UX Consultant (me), UI Designer, Product Owner, Product Manager, 2 AI Engineers
Tools
Claude, Figma
Results
Live with 2 pilot clients, validating against real filing cycles
MVP now used as InfinitiBit's commercial demo build
Timeline
3 months, discovery to developer handoff
01 / Context
The problem was worth solving
German mid-market companies reconcile VAT across thousands of transactions manually in Excel, with no institutional memory and no CFO visibility, until an external auditor delivers findings at the worst possible moment. Standard rules resolve roughly 80% of cases, the remaining 20%, cross-border and intra-group scenarios, fall into a grey zone that gets escalated to expensive consultants or missed entirely.
Six pain points, validated with domain input
Regulatory moving target
No live knowledge layer. Every audit cycle opens with a manual scramble to understand current rules.
CFO visibility gap
No dashboard, no confidence score. Issues surface only when auditors flag them.
Manual validation bottleneck
Finance teams reconcile VAT transactions in Excel: slow, error prone, and unable to scale.
The edge case problem
Standard rules resolve about 80 percent of cases. Cross border and intra group scenarios consume disproportionate time.
Knowledge retention
When a team member leaves, their regulatory interpretations leave too. The same edge cases get resolved from scratch every cycle.
Audit relationship cost
Arriving unprepared at an external audit firm means longer engagements, higher fees, and damaged trust.
02 / Validation Scope
What DVAA validates, and how
Before I designed any interface, I had to answer a foundational question: what does the system actually need to check? German VAT compliance is not a single calculation. It is a layered set of obligations spanning transaction level accuracy, period level aggregation, and regulatory currency. Defining the validation scope was an information architecture decision before it was a UI decision.
Validation journey
Layer 1
Deterministic Rule Validation from Rulebook
Runs versioned rules against each transaction and returns pass, fail with reason, or escalate, covering roughly 80% of volume.
Layer 2
LLM-Assisted Rule Discovery
Triggers on cases Layer 1 can't resolve, cross-border, intra-group, or novel types. Three LLMs independently review the rulebook and propose a candidate rule with reasoning and a regulatory reference. A proposal, not a verdict.
Layer 3
Human Expert Review (Tax Expert)
A tax expert reviews the proposed rule, reasoning, and citation, then approves or rejects it. Approved rules convert into deterministic Layer 1 rules, enriching the library permanently.
03 / Design Process
Not just designing for AI. Designing with it.
Designing alongside an AI collaborator introduced a challenge conventional UX process does not prepare you for: the outputs are non deterministic. I did not know what the model would surface until I ran it. Three things had to happen before I could hand anything to engineering.
Chasing the black box
First, I mapped the model's actual output range. Claude's early outputs were accurate and domain-correct but arrived in machine format, illegible to a CFO, with no existing template for what an AI-generated VAT audit result should look like.
Signal versus noise
Second, the problem became editorial, not technical: what does a CFO need to see, and what creates overload. Explainable AI was the governing principle, every output had to trace to a rule and regulatory source, defensible in a board meeting without extra context.
Translate for human
Third, I translated results into boardroom language: rule codes became euro exposure amounts, confidence decimals became clean percentage scores, regulatory citations became one-line risk descriptions readable in under five minutes.
Working this way against a live AI collaborator gave me a few advantages a conventional UX process does not:
Explored dozens of real output structures in hours, instead of waiting on engineering to expose sample data.
Iterated on hierarchy and language directly against real transaction content and regulatory citations, not placeholder copy.
I could test whether an explanation landed with a non-technical reader before a single line of production code existed.
Stayed the editor of what a CFO sees, rather than handing that judgment to whichever team touched the model output last.
04 / MVP Strategy
One persona. Maximum clarity.
With a six month MVP horizon, we made a deliberate scoping call: target the CFO persona exclusively and defer the finance operator to a later phase. Dr. Sabine Krüger is the procurement decision maker, the board level accountability holder, and the user whose pain translates most directly into product value. Narrowing to one persona gave every feature decision a single test to pass.
Scope decision
Product Owner wanted both personas designed in parallel to fill the roadmap faster. The design and Engineering team argued that splitting attention across two surfaces in six months would leave both shallow; we agreed to sequence the operator persona after the CFO MVP shipped.
Defined personas
P01 · Deferred post MVP
Markus Bauer
Senior Tax Accountant, Stuttgart
Daily operator. Runs validation, reviews verdicts, initiates escalations. Works in DATEV and SAP, low tolerance for false positives.
Deferred by negotiated agreement, not oversight, see the friction note above.
P02 · MVP target
Dr. Sabine Krüger
CFO / Finance Director, Munich
Governance user. Weekly check ins, board level accountability, PE sponsor reporting.
Primary procurement decision maker. Approved the exploration of internal tooling after two consecutive audit cycles produced late stage surprises.
05 / Design Iteration
Two phases. One decisive pivot.
The evaluation model went through two distinct design phases, separated by a client and domain expert review that fundamentally changed the information architecture. I am documenting both phases as they happened, including the version I later rejected, because the reasoning behind that rejection is what the outcome at the top of this case study is actually built on.
Ideation and exploration happened directly in Claude, using it as a design partner to validate that AI-generated outputs stayed accurate to the VAT domain while becoming digestible for a CFO, not just simplified out of context.
V1: Rulebook based transaction validation
The first version of the audit evaluation was built around raw transaction rows extracted directly from the client's ERP. Each line item was surfaced individually, validated against the rule engine, and flagged with a pass, fail, or escalate verdict. My hypothesis was that complete transaction level visibility would give the finance team maximum granularity, and give the CFO a comprehensive audit trail.
Overview - Filing period summary dashboard
Overview surfaced transaction counts with a pass/fail breakdown, rows checked, rows failed, but no financial exposure for the upcoming filing period.
Screen: V1 - Filing Period Overview (Vibe-Coded)
Problem identified:
The client showed more interest in exposure and items needing attention. Confidence score over time and transaction outcomes were signaling the same state, redundant information.
Validation overview - Error log with rule codes
Validation failures were presented as a flat list of failed transactions, each showing a technical rule code, a match confidence decimal, and the raw transaction data.
Screen: V1 - Transaction details (Vibe-Coded)
Problem identified:
A lot of technical details for validation justification, not understandable The detail panel diagnosed the issue but did not guide the CFO toward a decision.
Screen: Validation trace concepts
Problem identified:
No recommended action, no € exposure, no escalation path. The detail panel diagnosed but did not guide.
Regulatory Updates Tracker - Chronological regulatory feed
Regulatory changes were surfaced as a chronological list: publication date, rule reference number, and a brief description.
Screen: V1 - Regulatory updates (Vibe-Coded)
Problem identified:
Nothing distinguished "requires immediate action" from "informational," and most updates were irrelevant to this company's compliance profile.
Client review - Platform Pivot
The review session was decisive. I learned that the evaluation had to mirror the CFO's mental model, not the system's internal logic. In any transaction, financial exposure, not a rule identifier, is what tells Sabine whether she needs to act. Four things came out of that session, from the client and from the domain experts we brought in, a finance director and a VAT auditor:
Lead with financial exposure, the euro amount, not the rule reference. Rule detail is secondary context, not the headline.
Give the overview a clear compliance posture signal. A raw count is not a status.
Filter the regulatory feed to what is relevant to this company, and rework the AI outputs extensively, since in their raw form they were not digestible and did not track the CFO's actual goal.
Add a filing period selector, and define a modular design approach so the experience stays coherent as the platform grows.
V2: Humanizing the AI solution
Version 2 did not change what the system validates. It changed how the system speaks. I restructured, connected, and translated the AI outputs into language a CFO can act on without a tax background, using three design moves the review session and expert feedback shaped directly.
Structure AI outputs
Every piece of AI generated content is organized into a predictable, scannable structure rather than surfaced as raw output. The CFO always knows what she is looking at and where to find it.
Progressive disclosure
The interface leads with what matters to a CFO: a high level summary first, supporting detail available on demand rather than forced on the first read.
Make AI outputs explainable
I emphasized why over how. Technical process detail is not valuable to this user. What matters is the reasoning, stated in natural language she can defend to a board.
Screen: V2 - Filing Period Overview (Vibe-Coded)
Before
Overview surfaced transaction counts with a pass/fail breakdown, rows checked, rows failed, but no financial exposure for the upcoming filing period.
After
Overview became a per-period comparable dashboard, adding transaction distribution by category alongside the pass/fail summary.
Risk list prioritized by financial consequence, in plain language first.
Validation results are restructured as a prioritized risk list. Each item leads with a plain language summary of the issue and its estimated financial exposure. The AI reasoning is translated, not surfaced verbatim.
Screen: V2 - Transactions (Vibe-Coded)
Design rationale:
I sorted the list by financial consequence, not rule ID or processing order. A CFO scanning 86 failed items needs the costliest exposure first, not the most recent transaction. The rule reference moved from the header into a secondary column, available, not leading.
The reasoning trace: making AI judgment explainable & auditable
Each transaction detail view also carries the reasoning trace: the specific regulatory checks Layer 2's three AI evaluators ran, their individual verdicts and confidence scores, and the corrective action required. I gave this screen its own space rather than folding it into a generic detail panel, because it is the artifact that lets a tax expert or auditor verify the AI's reasoning against the actual regulation, not just trust a summary.
Screen: V2 - Transaction details (Vibe-Coded)
Screen: V2 - Transaction details scenarios
Design rationale:
Each transaction validation opens with a plain-language summary and financial exposure, if any. A second level exposes supporting detail and breakdown. One consistent pattern across every case, so the experience stays perceivable and easy to remember.
Closing the loop between regulation and risk
Showing all 40 plus regulatory updates was technically comprehensive but practically useless for governance. I applied the same principle here as in the risk list redesign: filter first to company relevant impact, then express each update by what it actually touches, the impacted rule, its potential impact on transactions, and its effective from date. The result behaves as an early warning system, not a news feed.
Screen: V2 - Regulatory updates (Vibe-Coded)
Design rationale:
Based on the frequency of the updates, made it like a timeline based log with effective date and probable impact.
06 / Handoff
Turning AI output into a shippable product
Once I validated the V2 direction with the stakeholders initially then with the client, the work shifted from exploration to production: a Figma design system, modular component patterns, a vibe coded prototype for functional and interactive reference, and a developer handoff package that gave engineering two complementary artifacts instead of one.
Prototype with Claude
AI assisted artifacts: personas, journeys, V1 and V2 screens, and the content logic behind each decision.
Figma + design system
Applied design system, defined modular components and reusable patterns on top of the Claude produced screens.
Developer handoff
Figma specs and design patterns paired with a functional prototype as the interaction reference.
Why the functional prototype mattered
A Figma click through cannot demonstrate AI behavior. I vibe coded the prototype in HTML and JavaScript with real data references, which made the AI behavior observable instead of merely described. That was the difference between telling engineering "we think this is how it will work" and showing them "this is how it works."
Figma: design patterns and a modular approach
After validating the V2 direction, I transferred the Claude produced screens into Figma and applied a full design system: typography scale, color tokens, spacing system, elevation model, and component states.
Screen: Account view
Fewer Screens, More Coverage
I built the system modular, so components were reused across surfaces instead of redesigned per screen. That kept full Figma treatment limited to a small set of genuinely unique screens, cutting design effort without losing visual quality. Developers used the vibe-coded prototype directly as an interactive reference at handoff, less friction than a static spec alone.
Figma design file
Full design system: tokens, components, states.
Four modular patterns with variant documentation.
Annotated screen flows for the CFO dashboard, matching status, regulatory tracker, and executive summary.
Redline specs per component.
Functional prototype
Real rule & data references throughout.
Live confidence score with state changes.
The full Layer 2 escalation flow, end-to-end.
Alert trigger behavior tied to materiality thresholds.
AI behavior logic is observable before production implementation.
07 / Outcomes
What shipped, and where it stands today
The platform is built and live with two pilot clients, onboarded and currently evaluating its performance in production. InfinitiBit continues to run demos for potential customers and partners, using the V2 direction and the handoff artifacts from this engagement as the reference build.
2 pilot clients
Live in production, onboarded and running the platform against real filing cycles.
3-month window
Pass-rate and time-to-resolution data currently being collected with InfinitiBit before the first measured result is reported.
What's next
Defining experience for other persona
Defining Markus Bauer's journey maps now, so the finance operator surface gets full rigor, not a scaled-down copy of the CFO view.
Validating against real cases
Gathering structured feedback from prospect demos and the two live pilot teams, to test whether the exposure-led hierarchy holds across a broader range of company profiles before it locks into the operator persona's IA.
08 / Learnings
What this project taught me
Scope held on one test question, not a scope preference
Every ambiguous call resolved against: does this help Sabine govern with confidence? That question, not a belief in narrow scope, kept it to one persona.
V2's hierarchy came from experts, not heuristics
Financial consequence before rule reference was the auditor's ordering, not mine. My job was building to their sequencing.
Translating AI reasoning was the real design work
Every line had to stay accurate to a tax expert and readable to a non-expert. That tension, not the redesign, took the effort.
The timeline forced a better pattern than I'd planned
Four screens didn't fit six months. The modular four-state view exists because of that constraint, not by design intent.
