What Should a VAT Calculation Record Contain?

This explains the necessary contents of a VAT calculation record and why a lone numeric VAT value is insufficient. Records must capture identity, inputs, and provenance so results remain explainable and reproducible months or years later. Core fields include a stable calculation_id, net/vat/gross amounts stored as integer minor units (avoiding floating point), the vat_rate expressed in basis points, the transaction/supply date, the explicit tax classification used, and a flag for whether the input price included VAT. These basics let teams reconcile reported values, avoid ambiguous reverse‑engineering, and determine which tax context produced a result.

Beyond those fields, the record must carry structured provenance: a rate_provenance object that distinguishes numeric rate from the evidence behind it (with typed evidence_status and effective_at), and a calculation_provenance object that records calculator version, algorithm manifest, execution digest, and replay_status. Replay eligibility is separate from evidence capture; only records marked replay_status: available are eligible for exact replay. Source attribution (non‑sensitive source_id) and idempotency keys prevent misattribution and duplicate mutations. Treat evidence status as a typed state rather than a boolean, and keep calculation records distinct from sales ledgers to preserve auditability and reproducible tax decisions.