Knox for Craft CMS
VAT
Three facts, nothing else
Swedish VAT on a webshop sale turns on three things: where the goods go, whether the buyer gave a VAT number, and whether you are registered for the One Stop Shop. Knox reads those three and picks the Fortnox VAT type.
| Destination | Buyer | Fortnox VAT type | Default account |
|---|---|---|---|
| Sweden | anyone | SEVAT | 3001 / 3002 / 3003 / 3004 by rate |
| EU | gave a VAT number | EUREVERSEDVAT | 3108 goods, 3308 services |
| EU | consumer, OSS on | EUVAT | 3106 |
| EU | consumer, OSS off | SEVAT | as domestic |
| Outside the EU | anyone | EXPORT | 3105 goods, 3305 services |
For goods, "where the goods go" is the shipping address — VAT follows the goods, not the invoice. If you sell services, switch on Selling services, not goods and the decision moves to the billing address, which is the correct rule for a service.
The reasoning is stored
Every invoice carries the sentences that produced its VAT treatment, visible in the control panel:
The buyer is in DE and gave the VAT number DE123456789, so the sale is reverse-charged and reported in the periodisk sammanställning. Knox has checked the number's format only — confirm it in VIES before relying on it.
This is not decoration. EUREVERSEDVAT is a claim to Skatteverket that lands in your periodisk
sammanställning with the buyer's VAT number attached. When it turns out to be wrong, you owe the
tax — and you need to see why it was chosen, from the order as it was at the time rather than as it
is now.
Why non-domestic sales need Pro
Fortnox stores the VAT type on the customer record, not on the invoice.
That single fact shapes the whole plugin. An invoice booked against a collective "Webbkund" whose
VATType is SEVAT is reported as a domestic Swedish sale, whatever the rows say. A reverse-charged
sale booked that way shows 0% VAT on its rows and files as domestic — which looks right and is
wrong, the worst combination available.
So Knox refuses. On Lite, or with customer syncing off, an order that needs a non-SEVAT treatment
is blocked with the reason on it, rather than invoiced as a domestic sale. Turn on Sync
customers and it goes through.
The two things Knox will not do
It does not validate VAT numbers. Knox checks the shape — two letters, the right country prefix, plausible length — and says so in the reasoning. Confirming that a number is actually registered is a VIES lookup and your responsibility. A plugin that quietly asserted otherwise would be asserting something it cannot know, and the liability for getting it wrong is yours, not its.
It does not turn on OSS for you. Below the SEK 99,680 distance-sales threshold, charging Swedish VAT on an EU consumer sale is correct. Above it, it is not. Knox tells you which one it is doing:
The buyer is a consumer in DE and this shop is not using the One Stop Shop, so Swedish VAT is charged as on a domestic sale. Above the SEK 99,680 distance-sales threshold this stops being correct — turn on One Stop Shop in Knox once you are registered for it.
Where the buyer's VAT number comes from
Commerce has no VAT-number field of its own. Knox reads, in order:
- the address's
organizationTaxId, which is where Commerce's own EU VAT integrations put it - a custom field on the address named
vatNumber,vatIdormomsnummer
If your shop keeps it somewhere else, copy it onto organizationTaxId when the order completes.
For a Swedish VAT number, Knox also derives the organisation number Fortnox wants on a company
customer — SE556036079301 becomes 556036-0793, which is exactly how Skatteverket derives one
from the other.
Rates
A Fortnox invoice row carries VAT as a whole percentage from your company's configured rates: in Sweden, 25, 12, 6 or 0.
An order taxed at a rate Fortnox cannot represent — 8.5%, say — is refused rather than rounded into a different tax. So is an order line carrying two different rates, because a Fortnox row has exactly one.
VAT included or added
VATIncluded is an invoice-level flag in Fortnox, not a per-row one. Knox reads which one your
order uses from its own tax adjustments.
An order with VAT both included in some prices and added on top of others has no honest mapping, so Knox refuses it. Getting this backwards produces an invoice that is 25% wrong and still looks entirely plausible, which is the kind of error worth failing loudly over. Pin it in the settings if your shop is consistent and the adjustments are not.
Accounts
The defaults are the BAS chart's own numbers, which is what a Swedish Fortnox company starts with. Change any of them under Accounts in the settings, and press Check these exist in Fortnox — a row posted to an account that is not in the chart is rejected.
Leave one empty to let Fortnox decide, which falls back to the article's or the company's predefined sales account.
Cross-border freight follows the goods it carries rather than going to 3520, because 3520 Fakturerade frakter is a Swedish-VAT account.
The VAT-free note
Swedish law requires an invoice that carries no VAT to reference the provision that makes it so.
Fortnox adds nothing of its own to an API-created invoice, so Knox puts it in Remarks:
- Reverse charge — Omvänd betalningsskyldighet — Reverse charge. Article 138 VAT Directive 2006/112/EC.
- Export — Export, omsättning utanför EU — Export, outside the scope of EU VAT.
Override either in the settings if your accountant prefers different wording. An invoice without one is not a complete invoice.