VAT filing automation: 20 min to 2 min, 2+ years, zero errors

Client

Ganado is a Czech accounting company managing recurring DPH (VAT) filing workflows under monthly deadline pressure. The team needed a filing process that was not only fast, but deterministic and safe to rerun.

Problem

Before automation, DPH preparation followed a manual operator flow across exports, spreadsheets, and filing templates. The process was technically repeatable, but fragile under real operating conditions.

Baseline workflow per cycle:

1. export period transactions,
2. normalize tax fields and categories,
3. reconcile totals against accounting source data,
4. map values into filing structure,
5. run manual spot checks before submission.

In standard months, this took around 20 minutes per cycle. Under corrections, re-exports, or late updates, it took longer and introduced avoidable risk close to filing deadline.

The key problems were reliability defects, not only time cost:

• duplicate rows after repeated imports or retries,
• inconsistent manual normalization decisions,
• reconciliation mismatches discovered too late,
• no run-level audit trail for fast investigation.

For an accounting company, this directly impacts submission confidence and operational predictability.

What I Built

I implemented a production DPH automation pipeline in Python with a reliability-first design.

Architecture

The pipeline was split into deterministic stages:

1. Ingest: pull approved source data for the target filing period.
2. Validate: enforce schema and business-rule constraints before transform.
3. Transform: map source values into DPH filing structure using versioned logic.
4. Reconcile: compare computed totals against control totals and block on mismatch.
5. Publish: generate submission-ready output plus operator review artifact.
6. Notify: send status and exception context to responsible owners.

Each stage emits structured run metadata, so every filing cycle is traceable.

Reliability controls

The reliability layer included:

• Period-level idempotency: rerunning the same legal entity + period scope cannot create duplicate outputs.
• Record deduplication: repeated source rows are fingerprinted and filtered safely.
• Validation gates: mandatory fields and allowed tax categories are enforced before output generation.
• Deterministic mappings: versioned logic prevents behavioral drift month to month.
• Exception routing: non-blocking anomalies go to owner-tagged queue with reason codes.
• Run-level visibility: pass/fail state and error context are published for each cycle.

Production operating model

Beyond pipeline logic, I formalized how Ganado operates this flow month to month:

• Pre-run checklist: confirm period boundary, source availability, and control totals.
• Execution checkpoint: block submission package creation on failed reconciliation.
• Exception triage: classify anomalies by severity and owner before any manual override.
• Replay protocol: rerun only the affected period scope with idempotent safeguards enabled.
• Post-run signoff: archive run summary with timestamped status and reconciliation evidence.

This model matters because filing reliability is not only a coding problem. It is an operations discipline problem. The combination of deterministic code + explicit operator procedure is what keeps quality stable after go-live.

Delivery model

Execution followed the fixed-scope model:

• week 1: workflow audit and failure-mode mapping,
• week 2: build, historical testing, and UAT,
• go-live: runbook handoff and controlled production rollout.

Goal: remove manual fragility while preserving accounting control discipline.

Implementation detail: why this stayed stable in production

Many VAT/DPH automations work in their first two months and then degrade when source formats change or retry events appear. In this case, long-term stability came from three explicit design choices:

1. Strict input contract Every source field used for filing logic had a clear type and validation rule. If upstream data did not satisfy the contract, the run failed safely instead of writing partial artifacts.

2. Deterministic transform layer Mapping rules were handled as versioned logic, not ad-hoc spreadsheet edits. This removed operator variance and made month-over-month behavior predictable.

3. Controlled failure handling Failures were not hidden. They were routed with reason codes, ownership, and replay steps. This cut investigation time and prevented deadline panic.

These controls are exactly why the case achieved both speed and submission quality instead of trading one for the other.

Result

The Ganado DPH workflow has been running in production for 2+ years with stable outcomes.

KPI snapshot

Metric	Before	After
Preparation time per DPH cycle	~20 min	~2 min
Time reduction	—	~90%
Submission rejection rate	Non-zero risk with manual flow	0 rejected submissions
Operating model	Manual stitching under deadline pressure	Deterministic run with explicit controls

Additional context:

• recurring monthly cycles remained stable with no reliability regressions,
• operator onboarding improved due to runbook and structured run outputs,
• period-close stress reduced because mismatches were caught pre-submit.

For leadership, this changed DPH filing from a fragile “heroic” process into a repeatable production workflow.

Reliability layer pattern from this case

This Ganado case demonstrates a reusable production pattern:

1. design retries in from day one (idempotency before speed),
2. separate blocking data-integrity failures from queueable exceptions,
3. keep mapping logic versioned and reviewable,
4. publish run-level evidence for each filing cycle.

If your finance team still prepares DPH/VAT manually, this is usually the highest-ROI lane to stabilize first.

See delivery structure on How It Works, related implementation scope on Finance Ops Automation, and retry-safe write design in Webhook Retry Logic.

Need the same result for your accounting workflow? Book a free 30-minute discovery call. If fit is confirmed, paid reliability audit starts from €500.