Trust Center
VAT compliance your clients can trust — and you can defend. GDPR by design · Encrypted · Tenant-isolated · ISO 27001 programme underway.
The figures that reach a VAT return are produced by a deterministic engine — not by an LLM
Most AI tools an accountant evaluates put a large language model on the critical path: the model produces the number the practice then relies on. That is where “probably correct” becomes professional exposure.
eVAT is built the opposite way. Core VAT determination runs through rule engines tied to primary legislation — directive articles, national VAT acts, and tax-authority specifications, each carried with its citation. AI is confined to assistive tasks (reading documents, suggesting classifications, drafting narratives, screening for AML risk), and a hard architectural rule applies: a machine-learning, LLM, or OCR-derived value must pass a deterministic validator or a named human before it can influence a filing. When grounding is unavailable, the system fails closed and asks — it does not guess.
- Grounded in authoritative content. VAT logic is sourced from and tied to primary legislation; country coverage expands only once the rule chain is verified end to end.
- Accountable by design. Determinations are traceable to the rules that produced them; high-stakes decisions keep a human in the loop.
- Benchmarked, not asserted. Golden data sets of real-world cases are locked into the release pipeline — a regression in determination output blocks the release.
- Official APIs only. Tax-authority calls (including HMRC Making Tax Digital) use official OAuth-scoped APIs. We do not screen-scrape and we never store or replay Government Gateway credentials.
AI governance, by architecture
Every AI agent action on the platform:
- Is risk-classified before it executes — every AI system is classified under the EU AI Act risk taxonomy (minimal / limited / high / unacceptable), with a formal Article 6(3) self-assessment on record.
- Is permission-checked before any side effect — against tenant isolation, a never-AI prohibition list, autonomy ceilings, and human-approval requirements. The AI governance master switch defaults to OFF.
- Carries a named human initiator — recorded with tenant context in a tamper-evident, hash-chained audit log retained for 7 years, able to answer “what did the system do for client X on date Y”.
- Keeps a human in the loop for high-risk operations — EU AI Act Article 14 human oversight is enforced in the request path, not written in a policy binder.
- Can be revoked in under 5 minutes — a layered kill-switch hierarchy stops a misbehaving agent or token without waiting for a deploy.
Your data is not training material. Client data is not used to train third-party foundation models — this is a contractual commitment across our AI providers, not an assumption: our primary AI provider processes prompts inside the EU Data Boundary and contractually excludes them from model training, and fallback routes run under zero-data-retention or no-training terms. AI provider choices are evaluated against a 10-dimension framework covering residency, data-protection agreements, and each provider's own sub-processor chain.
Certifications & frameworks — where we actually stand
We state certification status exactly as it is. A platform that hides its gaps is less safe to buy than one that names them.
Certification programme underway with continuous control-evidence collection, targeting a Q4 2026 audit window. We will not describe ourselves as certified until the attestation lands.
On the roadmap following ISO 27001. No audit period has started, so no report exists yet — and we won't imply one does.
Not a certificate — an operating programme: an Article 30 record of processing, an Article 28 sub-processor register (published below), and data-protection impact assessments for high-risk processing.
Every AI system risk-classified, Article 6(3) self-assessment on record, Article 13 transparency disclosures, and Article 14 human oversight enforced in code.
Data protection (GDPR)
- Controller of record: eVAT OÜ (Estonia). Lead supervisory authority under the one-stop-shop: the Estonian Andmekaitse Inspektsioon (AKI).
- EU-resident by default: tenant data is held in EU infrastructure, with tenant-level isolation and a complete access audit trail.
- Retention follows tax law, not convenience: retention periods are driven by statutory obligations (e.g. EU VAT Directive record-keeping, German AO §§146–147, HMRC's 6-year rule) — and data past its purpose is anonymised or deleted on schedule.
- Data-subject rights supported, including erasure where legally permitted — erasure is gated against live statutory retention obligations (a filing-relevant record cannot be silently destroyed mid-obligation), and subject-access exports apply the AML tipping-off redactions the law requires.
- PII minimisation across non-production environments.
Our full Article 30 record of processing activities, data-protection impact assessments, and signed data-processing agreements are available to customers and prospects under NDA — request them from our DPO.
Sub-processors
Third-party processors engaged under GDPR Article 28, projected live from our internal sub-processor register. Our client agreements reserve sub-processor changes to a 30-day advance notice, and any material change triggers client notification.
Security practices
- Encryption: sensitive material (tokens, signing certificates, AML/KYB records) is AES-256 encrypted at rest; all traffic is TLS in transit.
- Access control: role-based access control with tenant-level isolation; administrative access is audit-logged.
- Audit trail: platform actions are recorded with actor and tenant context; compliance-relevant logs are immutable and retained to statutory horizons.
- Continuous testing: static analysis, secret scanning, and dynamic web scanning run on every change; penetration testing complements the automated pipeline.
Published remediation SLAs
When a vulnerability is found — by our pipeline, a researcher, or an auditor — these are the deadlines we hold ourselves to, projected live from our vulnerability-management process:
Our remediation SLA table is available on request from our DPO.
Report a vulnerability
We welcome good-faith security research. If you believe you have found a vulnerability
in eVAT, email dpo@evat.com
with enough detail to reproduce the issue. Machine-readable contact details are published
at /.well-known/security.txt (RFC 9116).
Confirmed findings are classified by CVSS severity and remediated within the published SLAs above. Please do not access, modify, or exfiltrate data that is not yours while researching; we ask for a reasonable disclosure window and will keep you informed of remediation progress.
Questions from your security or compliance team?
Request our DPA, DPIA summaries, or the full procurement diligence pack (available under NDA): dpo@evat.com. Developers can explore the public API reference and API changelog.