Tax Point (Time of Supply)

Basic and actual tax points, in HMRC’s terms

The UK rules are the clearest worked example, and HMRC’s VAT Notice 700 lays them out in two layers.

The first layer is the basic tax point. For goods it is usually the date you send them or the customer takes them away. For services it is “the date when the service is performed,” which HMRC says is “normally taken as the date when all the work except invoicing is completed.”

The second layer is the actual tax point, which overrides the basic one in two cases. If you issue a VAT invoice or receive a payment before the basic tax point, the tax point for that amount is the date of the invoice or the payment, whichever comes first. And if you issue a VAT invoice up to 14 days after the basic tax point, the invoice date becomes the tax point. Miss the 14 days without HMRC’s approval and the tax is due at the basic tax point.

Two details trip people up. HMRC says “a tax point cannot be created simply by preparing an invoice”: the invoice has to be sent or given to the customer. And once an invoice creates the tax point, “you cannot delay accounting for VAT until you have received payment,” unless you use the Cash Accounting Scheme, which has its own rules.

Subscriptions and other continuous supplies

Software and other services billed on a schedule raise an obvious problem with the basic rule: there is no single day when “all the work” is done. HMRC’s notice handles services supplied on a continuous basis separately. For those, “there’s a tax point every time you issue a VAT invoice, or receive a payment, whichever happens first.”

HMRC also allows a shortcut for payments due at regular intervals. You can issue one VAT invoice at the start of a period of up to a year that lists each payment, its due date, the VAT-exclusive amount, the rate and the VAT. Then you account for each payment on its due date or when you receive it, whichever is first.

Whether a particular subscription counts as a continuous supply is a question about your contract, and the answer is worth confirming with an adviser. The practical point holds either way: for recurring billing, the tax point is driven by invoices and payments, which are exactly the events Stripe records.

How the rule changes from country to country

The same Stripe invoice can sit in different periods depending on whose law applies, because countries pick different triggers.

Colombia uses an earliest-event rule. Article 429 of its tax code makes IVA on services arise at the earliest of the invoice, the completion of the service, or payment, so a Stripe invoice usually lands in the period Stripe already reports it in. Our Colombian IVA guide, linked below, walks through that article.

Chile and Peru tie the tax point for a foreign digital seller to the payment instead. An invoice that finalizes on the 30th and is paid on the 3rd belongs to the next month there. Our Chilean VAT guide works through that gap in detail, and the Peruvian IGV guide applies the same fix.

Rate changes follow the same logic. A sale whose tax point falls before the change date takes the old rate, even if it is paid afterwards. HMRC’s notice says the tax point rules are “particularly important” for working out which rate to charge when one changes.

Where Stripe’s date and the tax point part ways

Stripe Tax uses one date for everything. Its tax reporting guide says, “We consider transactions effective on the date they finalize and we don’t recalculate taxes afterwards.” Finalizing an invoice, the move from draft to open, increases the tax reported, and Stripe notes that this transition “happens before the invoice is paid.” For Checkout, the trigger is the customer completing the payment.

That date is a reporting convention, not a tax point under anyone’s law. Most of the time it doesn’t matter, because a subscription invoice that finalizes and charges the card in the same minute has every candidate date on the same day. It matters at month end and with manual invoices: a retry that succeeds in the next month, an invoice sent for bank transfer and paid three weeks later, an invoice that is never paid at all.

The last case needs its own fix. Stripe says a failed or canceled payment for a finalized invoice “doesn’t decrease the total tax reported.” To take the tax back out of Stripe’s reports, the invoice has to be voided, marked uncollectible, or reduced with a credit note.

Keeping a cross-period list next to QuickBooks

Where the tax point follows payment, the return and Stripe’s export will disagree by a small, predictable set of invoices. The cheapest control is a short list kept each period: invoices that finalized in this period but were paid in the next, and invoices paid in this period that finalized in an earlier one. Stripe’s itemized tax export gives you the finalized side, and the invoice’s paid date gives you the other.

In QuickBooks, the useful habit is to file from the same list. The VAT you report for the period is Stripe’s figure, minus the invoices on the first half of the list, plus those on the second half. Keep the list with the return so the difference between the filing and the sales tax liability in QuickBooks can be explained line by line.

Refunds and credit notes raise the same question in reverse. Many regimes record the adjustment in the period the credit is issued rather than reopening the original return, but that is a country rule, not a Stripe setting, so check it for each place you file. On the Stripe side, a credit note is one of the three ways to take tax back out of the reported total.