What is VAT collected?
VAT collected is the tax you charged customers on their orders — money passing through the business on its way to a tax office, not revenue. The KPI totals it for the selected period; the VAT summary lays it out by month next to the excl-tax and incl-tax revenue it sits between.
Formula
VAT collected = Σ order tax totals (booked orders) − Σ VAT reversed by refunds
incl-tax revenue = excl-tax revenue + VAT collected
A refund's VAT reverses in the month the refund happened, not the month of the original order — the same credit-note timing an accountant would use. A partially refunded order keeps its VAT in the order's month and loses only the refunded share, in whichever month the refund landed; a fully refunded order nets to exactly zero VAT once its refund is booked.
Worked example
A month shows €96,000 excl-tax revenue and €17,300 of VAT collected — a blended 19.5% effective rate, between Germany's 19% standard rate and higher-rate countries in the mix. The blend shifts with country mix and product mix (reduced rates), so a moving effective rate is expected; a jump in it usually means the country mix moved, which the per-country revenue split will confirm.
How Saldo Metrics computes it
Each order stores its tax total (tax_amount_base, EUR at the order date, with
the original amount preserved). v_vat_summary sums it over every booked order
(everything but cancelled orders, so a fully refunded order still contributes
its VAT the day it was invoiced) and reverses each refund's share of that VAT
in the refund's own month. When the platform reports the refund's own tax
(today, PrestaShop credit slips), the reversal uses that refund's rate, so a
reduced-rate line refunded on a mixed-rate order reverses at its own rate. When
it does not (WooCommerce, Shopware, Amazon, and refunds synced before that tax
was captured), the reversal falls back to the order's own effective VAT rate
applied to what actually came back — the same order-level-basis limitation
described below. Every consumer reads that one reversal definition
(canonical.v_vat_refund_reversal): the KPI for an arbitrary period,
canonical.v_country_revenue all-time per country, and the "Revenue by Country"
table you see in the app through canonical.v_country_revenue_ledger. That table
takes its revenue and its VAT from the same population — booked orders at their
order date, minus refunds at their refund date — so on it, too, incl-tax revenue
equals excl-tax revenue plus VAT for any period.
The basis is otherwise order-level: the canonical schema does not store per-line VAT rates, so the views report what was collected, not a rate-by-rate breakdown — enough for monitoring and reconciliation, not a substitute for the store platform's tax report when a filing needs per-rate detail.
Why it matters
VAT is the most common way store owners overestimate their business: platform dashboards love incl-tax totals, and a fifth of those never belonged to you. Keeping VAT visible but separated is what keeps every performance metric on the excl-tax basis — and the monthly series is a useful liability preview between filings, since collected VAT is money already owed.
Common mistakes
- Reading incl-tax figures as revenue. The margin you live on is a percentage of the excl-tax base; mixing bases overstates the business by the VAT rate.
- Using this for a filing's per-rate breakdown. Order-level totals cannot split standard from reduced rates; the store platform's tax report owns that.
- Ignoring cross-border rate effects. OSS thresholds and destination-country rates change the blend as you grow abroad; the effective rate drifting is geography, not error.
Where you see this in the app
The VAT Collected KPI, the VAT-by-month summary widget, and the VAT column of the country revenue table.