Norway invoice requirements: the practical rules behind a trustworthy invoice

1. Norwegian invoice numbers are more than a text field

Altinn explains that invoice numbers should be assigned by the invoicing program or come from pre-numbered forms so the issuer cannot simply choose the number. Skatteetaten guidance also emphasizes a controllable sequence for the individual bookkeeping entity.

This matters because many lightweight invoice generators treat the visible invoice number as an ordinary editable input. A Norway-focused flow needs the opposite approach: the numbering system, not the text box, should be authoritative.

InvoiceCraftly design response: the Norway workflow uses a per-business numbering ledger with serialized allocation and reserved, issued and void states. The visible number is derived from that state rather than accepted as a user override. If the local ledger is missing, InvoiceCraftly does not silently restart from 1: the issuer must restore a trusted Workspace backup or establish the previous sequence before the system assigns the next number.

Sources: Altinn — Faktura (salgsdokumentasjon) and Skatteetaten — Inntekter.

2. “Delete invoice” is the wrong mental model for an allocated number

When a numbered sales document is unused or erroneous, the history cannot behave like a disposable draft list where the record simply disappears. Norwegian guidance describes keeping the invoice in the number series and marking it as void.

That is why InvoiceCraftly's Norway workflow uses an explicit Makuler transition for an unissued invoice. The number remains in the ledger, the document is retained as void, and a reason is recorded. Once an invoice has been issued/exported, the correction path is a credit note rather than Makuler.

3. MVA after the organisation number is a registration fact, not a tax-rate guess

Norwegian business-document guidance says that when an enterprise is registered in Merverdiavgiftsregisteret, MVA must follow the organisation number. A 25% line-item tax rate is not proof that the enterprise is actually registered.

A safer product therefore asks the seller to declare the registration status explicitly and makes the presentation follow that declaration. InvoiceCraftly does not claim to verify the seller against Brønnøysundregistrene or Merverdiavgiftsregisteret.

Source: Altinn — company information on websites and business documents.

4. AS and ASA need more company identity than just an organisation number

For Norwegian limited companies, business documents carry additional identity requirements. The company form and head-office address matter, Foretaksregisteret presentation is relevant, and a company under liquidation must identify that status. The current Foretaksregister Act also contains additional requirements for a Norwegian branch of a foreign enterprise (NUF).

InvoiceCraftly's Norway workflow therefore models legal form, Foretaksregisteret status and liquidation status separately. NUF remains deliberately outside the complete supported identity contract because the foreign-enterprise details deserve their own data model instead of being squeezed into a generic seller field.

Sources: Altinn and Foretaksregisterloven § 7-2.

5. Foreign-currency invoices need the VAT amount itself in NOK

A Norwegian invoice can have commercial amounts in another currency, such as EUR or USD. Where Norwegian VAT applies, however, Skatteetaten guidance says the VAT amount itself must also be stated in Norwegian kroner. Merely printing an exchange rate does not replace the NOK VAT amount.

The practical workflow is therefore:

1. calculate the VAT in the invoice currency;
2. use a documented exchange rate appropriate to the invoice time;
3. store the rate, date and source used;
4. calculate and display a separate MVA i NOK amount on the document.

InvoiceCraftly does not silently fetch or choose a rate on behalf of the seller. The Norway workflow keeps the rate evidence on the document and calculates the separate NOK VAT amount from that explicit input. A source such as a relevant Norges Bank rate may be used when appropriate, but the issuer remains responsible for the accounting treatment and the rate chosen.

Source: Skatteetaten — Salgsdokumentets innhold – merverdiavgift.

6. PDF and EHF solve different jobs

A PDF may be a useful visual sales document, but it is not an EHF electronic invoice. Norwegian public-sector invoicing can require EHF/Peppol-compatible delivery. InvoiceCraftly creates downloadable visual/structured artifacts but does not generate or transmit EHF.

If the recipient requires EHF, use an EHF-capable accounting/invoicing system or an appropriate portal. InvoiceCraftly should not be presented as the transmission system for that workflow.

Sources: DFØ / Anskaffelser.no — Fakturering og betaling and Digitaliseringsdirektoratet — EHF requirement.