Tax point (VAT point date)

What it is

The tax point — formally the time of supply, and in EN 16931 terminology the VAT point date — is the date on which VAT becomes chargeable on a transaction. It determines which VAT period a supply falls into, which VAT rate applies if rates change, and when the supplier must account for the output tax. It is a distinct concept from the invoice issue date, even though the two often coincide.

Under the EU VAT Directive (2006/112/EC), VAT becomes chargeable in general when the goods or services are supplied (the "chargeable event", Articles 63–66), but member states apply specific rules that can move the tax point to the invoice date, the payment date, or a fixed period after the supply. Common situations where the tax point is not the invoice date include: advance payments (tax point = date of payment), continuous supplies, cash (payment-based) accounting schemes, and intra-Community transactions with their own timing rules. Because these rules vary by country and by scheme, the tax point is a frequent source of confusion — and of misposted VAT — for cross-border ERP systems.

How it appears in EN 16931

EN 16931 lets an invoice express the tax point in one of two mutually exclusive ways:

The standard enforces that BT-7 and BT-8 are mutually exclusive — an invoice carries one or the other, never both. This is a business rule (BR-CO style constraint) that validators check, and supplying both is a common rejection cause. If neither is present, the invoice date (BT-2) is typically taken as the effective tax point.

How ERP vendors encounter it

The tax-point fields are optional in the core EN 16931 model, but several national CIUS and tax authorities lean on them. The clearest example is German VAT: for cash-based accounting (Ist-Versteuerung), guidance is to carry the VAT point explicitly via BT-7, or to signal payment-based timing via BT-8 code 432, so that the structured invoice reflects the legally relevant date rather than just the issue date. Getting this wrong does not just risk a validation error — it risks the invoice being booked into the wrong VAT period.

Mapping into the two main syntaxes:

Why it matters

For an EU e-invoicing pipeline, the tax point is where VAT law meets the data model. Three practical rules keep ERP integrations safe: (1) never emit both BT-7 and BT-8; (2) only emit a tax point when it genuinely differs from, or needs to be qualified relative to, the invoice date — otherwise leave both empty and let BT-2 stand; and (3) when consuming inbound invoices, resolve the effective tax point in the order BT-7 → BT-8 (decoded) → BT-2, because the period you post to depends on it. Because tax-point rules are member-state specific, this is exactly the kind of cross-border detail a compliance layer should normalise rather than leave to each integration.