Which VAT Category Code Carries Each Norwegian Rate in an EHF Invoice

All four of Norway's positive VAT rates — 25%, 15%, 12% and 11.11% — are carried by the same VAT category code, S. The reduced rates are not separate codes. The code says how a supply is treated for VAT; the rate field says how much. An EHF invoice that puts "reduced" into the category code instead of putting the number into the rate fails validation with BR-CL-17, and never reaches the buyer.

We know this precisely because we got it wrong. Our own renderer mapped a reduced rate to the code AA, and the official EHF validator rejected it on 16 September 2026. This page sets out the full code set Norway uses, what each one requires, and how to read a rejection report so the next one takes a minute rather than an afternoon.

Which VAT category code carries each Norwegian rate?

Code S carries every rate above zero. The zero and no-tax treatments each have their own code.

The Norwegian Tax Administration publishes 25%, 15% and 12% as the general rates. The 11.11% raw-fish rate is a sector rate that does not appear on that general page; it appears in the EHF guidance, and we validated an invoice at each of the four rates against the official validator on 16 September 2026.

Two points of care for anyone building this. First, Z and E both produce zero tax and are not interchangeable — exemption and zero-rating are different treatments in the Norwegian VAT Act, and the reason text you must supply differs accordingly. Second, K is not emission allowances: in EN 16931 it is the intra-community supply within the EEA, used at 0% with the exemption reason VATEX-EU-IC. Export outside the EEA is G.

Why are the reduced rates not separate codes?

Because the category code classifies the treatment, and the standard deliberately keeps the amount out of it.

EN 16931 — the European semantic standard that EHF and Peppol BIS Billing 3.0 both implement — takes a subset of the United Nations code list UNCL5305 and permits exactly ten values: AE, B, E, G, K, L, M, O, S and Z. None of them means "reduced". A reduced rate is a standard-rated supply at a lower percentage, so it is S with a smaller number in the rate field.

You can see the design in the rules themselves. BR-S-08 reads: "For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is 'Standard rated', the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts…" The rule is written on the explicit assumption that one invoice can carry several different rates under S, each with its own VAT breakdown group. That is the mechanism that makes a Norwegian invoice with 25% consultancy and 15% catering on it perfectly ordinary.

The practical consequence for an integration is a mapping decision, not a code hunt. Your ERP almost certainly has a tax code per rate; those codes map to the pair (category, percentage), and for everything Norway charges VAT on the category half of that pair is the same letter.

What does a BR-CL-17 error actually mean?

That the category code you sent is not in the permitted ten.

The rule's own text is short: "Invoice tax categories MUST be coded using UNCL5305 code list", and the test behind it checks membership of the set AE L M E S Z G O K B. BR-CL-18 is the identical check applied to the VAT breakdown rather than the invoice line, which is why the two usually appear together — a bad code on a line produces a bad code in the breakdown that summarises it.

The error message is unhelpfully generic, so the useful reflex is to look at the code you sent rather than at the rule. In our experience three causes account for nearly all of them:

• A code invented for a rate. AA for "reduced", H for "lower rate", or a two-letter code from a national tax table. AA is the most dangerous of these because it is a genuine UNCL5305 entry and therefore looks right in a code-list lookup; it is simply not in the EN 16931 subset.
• A tax code copied from the accounting system. ERP tax codes are internal identifiers, not UNCL5305 values, and a direct pass-through sends something like MVA25 into a field expecting one letter.
• Case and whitespace. The test normalises space but not case, so a lower-case s is not the code S.

Which rate does each code require, and what fails?

The rate is not free. Each category pins it.

• S requires a rate greater than zero — BR-S-05 at line level, BR-S-06 for a document-level allowance. A 0% line sent as S fails, which is the mirror image of the reduced-rate mistake.
• E, Z, AE, G and K require a rate of exactly zero — BR-E-05, BR-Z-05, BR-AE-05, BR-G-05 and BR-IC-05 all test Percent = 0. An absent rate fails these as surely as a wrong one, because "nothing" is not "zero" to the test.
• O requires no rate element at all — BR-O-05 tests not(cbc:Percent). This is the one that catches careful implementers out, because writing 0 looks like the safe thing to do and is precisely what the rule forbids.

This last one was our own defect. Until 16 September 2026 our renderer wrote a zero rate on outside-scope lines; it now writes no rate element for category O, and the invoice passes.

Then there is the reason text, which is a separate failure from the code and the rate. A VAT breakdown using E, G, K or O must carry a VAT exemption reason code or reason text — BR-E-10, BR-G-10 and BR-O-10 each require one. Category K carries more than that: both parties' VAT identifiers (BR-IC-02), a delivery date or invoicing period (BR-IC-11), and a deliver-to country (BR-IC-12).

Is any of this specific to Norway?

The codes are not. The rates are, and so is one identifier rule.

EHF Billing 3.0 is Peppol BIS Billing 3.0 with Norwegian rules layered on, and the VAT category list comes from the European layer rather than the Norwegian one. So the same ten codes apply in Belgium, Germany and the Netherlands; only the rates and the national rules change. That is worth knowing because it means a correct European mapping is already most of a correct Norwegian one.

What is Norwegian is the seller's tax identifier. Rule NO-R-001 requires it in the form NO + nine-digit organisation number + MVA — NO123456789MVA — and it is fatal, not a warning. A limited company is additionally expected to state Foretaksregisteret under NO-R-002. These national rules sit inside the Peppol rulebook rather than beside it: section 6 of the Norway Peppol Authority Specific Requirements, which OpenPeppol approved on 17 September 2025, points implementers at DFØ's local specifications for exactly this layer. Neither of these is a routing value: the Peppol address is the bare nine digits under scheme 0192, and how a Norwegian business becomes reachable for EHF invoices explains why the two are different things and who publishes which.

What is still unsettled

We cannot show you a Norwegian production invoice. Norwegian delivery went live for us on 16 September 2026 and we have carried no Norwegian production traffic since. Everything on this page is from the official rule packs and from our own validated test invoices, and we would rather say that than imply volume we do not have.

Category K is not in our public API's Norwegian guidance yet. The renderer supports it and maps the canonical value intra_community to K with the intra-community rules applied, but our internal Norway requirements file describes K as emission allowances, which is wrong. That file is being corrected; this page is the accurate version.

The 2027 B2B mandate changes none of this. In March 2026 the Norwegian government moved mandatory B2B e-invoicing from 2028 to 1 January 2027 and put the bill before the Storting. Until Parliament passes it that is a government proposal, and nothing published so far touches the VAT category rules. We read their status as unchanged rather than as confirmed — that is inference, marked as inference.

What this page does not cover

Which rate applies to a supply. That is a tax question for your accountant and the Norwegian VAT Act, not an invoicing-format question. This page is about expressing a rate you have already determined.

Registration and identifiers. Who publishes a Norwegian participant, why a private company files nothing with ELMA, and which of the numbers on a Norwegian letterhead is the Peppol address are all in how a Norwegian business becomes reachable for EHF invoices.

The EHF documents beyond the invoice. Reminder, Forward Billing and Payment Request each have their own rules and their own registration, and they are covered in the three Norwegian billing documents Peppol does not have. The reminder fee, incidentally, carries a VAT category of its own as a document-level charge, so everything on this page applies there too.

Payment details. The KID reference and the IBAN-versus-BBAN question are the next page in this set, not this one.

What to do next

Map your ERP tax codes to the pair, not to a code. Write out every tax code your system uses, and against each one record the EN 16931 category letter and the percentage. If any row has a letter outside the permitted ten, you have found a rejection before it happened.

If you are building the integration, the category field, the rate field and the validation responses are documented in the developer documentation, and the country rules we apply for Norway — EHF, scheme 0192, the register check and these VAT categories — are set out on our Norway page. Recorded walkthroughs of the ERP connectors are on tutorials. The other avoidable rejections, across countries, are in invoice validation errors you can prevent. If you would rather have somebody sit with your tax-code table and map it with you, book a session.

Next read: the three Norwegian billing documents Peppol does not have, which covers the EHF documents that sit outside Peppol BIS Billing entirely.

Sources: the EN 16931 and Peppol BIS Billing 3.0 Schematron rules running in GoRoute's own validation pack for the texts of BR-CL-17, BR-CL-18, BR-S-05, BR-S-06, BR-S-08, BR-E-05, BR-E-10, BR-Z-05, BR-AE-05, BR-G-05, BR-G-10, BR-IC-05, BR-O-05, BR-O-09 and BR-O-10, read 4 October 2026; UNCL5305 as published by OpenPeppol for the permitted category set, and the Peppol BIS Billing 3.0 rule list for the rule identifiers; the Norway PA Specific Requirements (OpenPeppol, approved 17 September 2025), section 6, for the national specification layer; anskaffelser.dev, DFØ's specification site, for EHF Billing 3.0 and its usage in Norway, including the four rates carried by category S; the Norwegian Tax Administration's VAT rate page for the 25%, 15% and 12% general rates, read 4 October 2026. GoRoute's own release record is the source for the renderer correction of 16 September 2026 and for the four rates validated against the official EHF validator the same day. The 1 January 2027 B2B date is the Norwegian government's March 2026 announcement, with the legislative proposal before the Storting. Last reviewed 2026-10-04.