Norway MVA Invoice Mandatory Fields: §5-1-1 Checklist

A Norwegian B2B invoice — the salgsdokument, in regulatory language, or faktura in everyday use — is governed by Bokføringsforskriften §5-1-1, which sets the mandatory contents. Under that provision, sales documentation must minimally contain the document number and date, the parties, the nature and scope of the goods or services, the time and place of delivery, the consideration and payment due date, and any value-added tax and other levies.

In practitioner shorthand, that translates into the Norway MVA invoice mandatory fields a working AP team or issuer actually thinks in: seller and buyer identification (with the seller's organisasjonsnummer carrying the literal "MVA" suffix when VAT is charged), an invoice number drawn from a controlled sequence, the dokumentasjonsdato and the supply date (leveringsdato), a description of what was supplied at art og omfang granularity, the vederlag and the forfallsdato, and the VAT amount per rate. This article walks each field with a four-part treatment: what the rule says, what the field looks like on a real Norwegian invoice, what the AP-side red flag is when it is missing or wrong, and the extraction note when the article's reader is working from a digital document rather than paper. The framing is dual — most readers arrive with a Norwegian supplier's PDF on screen and need to decide whether the document is acceptable to post and pay; a smaller share are Norwegian SMB owners, bookkeepers, or software implementers building or auditing an invoice template — and the field treatments serve both.

Scope is narrow on purpose. The article covers what an invoice must contain. It does not cover how invoices must be transmitted under Norway's 2027 B2B e-invoicing mandate, which is a separate regime governing the EHF format and the Peppol network rather than the field list itself. It also does not deep-dive Bokføringsloven retention, the Brønnøysund verification workflow, or the operational mechanics of reverse charge — those are flagged in passing where they touch a §5-1-1 field, with cross-links where the reader needs them.

A note on positioning: Norway sits in the EEA rather than the EU, and although §5-1-1 is broadly aligned in shape with the EU VAT Directive's content rules, four pieces are distinctly Norwegian and account for most of the SERP confusion. The MVA suffix on the organisasjonsnummer is its own verification mechanic. §5-1-3 makes invoice numbering stricter than the EU's "sequential number" requirement. Foreign-currency invoices must display the VAT amount in NOK alongside the invoice currency. And exempt or zero-rated lines carry a citation to the exempting provision in the jf. mval. form. Each of those gets its own section below, after the field-by-field walk.

The MVA Suffix on the Organisasjonsnummer: What It Signals and Why It Matters

A Norwegian organisasjonsnummer is a nine-digit identifier that Brønnøysundregistrene assigns to every registered legal entity. The literal three letters "MVA" appended to that number on an invoice are not decorative. They signal that the seller is entered in the Merverdiavgiftsregisteret (the VAT register) and is therefore entitled to charge merverdiavgift on the supply. The suffix is the visual contract between the invoice and the VAT register: present means registered, absent means not.

In practice the rendering varies more than you might expect across templates. The most common forms are:

• 987 654 321 MVA
• NO 987 654 321 MVA
• Org.nr. 987 654 321 MVA

The spacing inside the digits, the optional "NO" prefix used on cross-border invoices, and the leading label all drift between accounting systems. The constant is the literal "MVA" suffix at the end. If you train your eye for that final token, you can clear most invoices in a glance.

Three failure modes are worth recognising on the AP side, because they each point to a different problem.

MVA is charged but the orgnr has no MVA suffix. This is non-compliant on the issuer side. Either the supplier has produced a template that omits required content, or — the more concerning case — the supplier is not actually VAT-registered and is charging VAT they have no authority to charge. The right response is to hold the invoice and query the supplier before paying. Input VAT claimed against an unregistered supplier is exposed under Skatteetaten audit, and the buyer is the one left carrying it.

The MVA suffix is present but the entity is not actually VAT-registered. This is fraud-adjacent. The suffix is asserting registration that does not exist; the underlying VAT charge has no legal basis. The buyer's input-VAT deduction is at risk in the same way as the previous case, but the issuer's posture is materially worse — the invoice itself is making a representation that is false. Brønnøysund's open data shows the registration status of every Norwegian entity, and a quick lookup is the right next step when something looks off. The verification workflow itself is its own topic and is not walked here; the point for this section is that the suffix invites verification, not that it constitutes verification.

No MVA charged and no MVA suffix on the orgnr. This is legitimate when the seller is below the registration threshold (currently NOK 50,000 of taxable turnover in twelve months) or operates only in exempt activities. There is nothing to query, but a clear note on the invoice that VAT does not apply — and why — saves the buyer's AP team a phone call.

For Norwegian sellers issuing invoices, the issuer-side consequence is plain. If the entity is registered in the Merverdiavgiftsregisteret, every invoice that charges MVA must render the suffix on the orgnr. Templates that show only the bare digits need fixing; this is one of the items a new bookkeeper inheriting a client should check on the first invoice they review.

For systems reading invoices, the MVA-suffixed orgnr is usually captured as a single string by an extraction tool. Splitting the registration flag from the digits at extraction time — capturing the orgnr as a clean nine-digit field and the MVA suffix as a separate boolean — lets downstream AP logic flag VAT-charging invoices whose orgnr lacks the suffix, which is the exact mismatch that points to either non-compliance or fraud.

Walking the §5-1-1 Field List, One Field at a Time

The fields below are what §5-1-1 requires on every Norwegian B2B invoice. Norwegian field labels are italicised on first use; after that they read as plain text.

Seller identification. The invoice must carry the seller's legal name, business address, and organisasjonsnummer. Where VAT is charged, the orgnr carries the literal MVA suffix as covered above. The address shown should be the registered business address, not just a billing PO box. AP red flag: a missing trading name or a missing address is unusual on legitimate Norwegian invoices and worth a query; suffix issues belong to the section above. Extraction note: capture name, address, and orgnr as separate fields rather than as one concatenated header block — downstream reconciliation needs the orgnr in isolation.

Buyer identification, including the buyer organisasjonsnummer for B2B sales. The invoice must identify the buyer by name and address, and on B2B sales it must include the buyer's organisasjonsnummer. This is the single most-missed field on foreign-supplier invoices issued into Norway. A US, UK, or German supplier who has been issuing invoices for years without a buyer-orgnr field on their template will continue to do so until a Norwegian customer's AP team pushes back, because their template was never designed for the Norwegian buyer-orgnr requirement.

From the Norwegian buyer's side, an inbound invoice that omits your own orgnr is technically incomplete and the supplier should reissue; in practice many AP teams accept the omission and update the supplier master data themselves, but the rigorous response is the reissue. From the foreign supplier's side, a Norwegian customer asking you to add their orgnr to your invoice is not making a courtesy request — it is asking you to bring the document into compliance with Norwegian rules so their bookkeeping can post it. Treat the request that way and add a buyer-orgnr field to the template.

Extraction note: pull the buyer orgnr as a discrete field; an extraction prompt that calls out "buyer organisasjonsnummer (Norwegian 9-digit)" will surface its absence cleanly across a batch.

Document date and supply date. §5-1-1 requires both — the dokumentasjonsdato (the date the document is issued) and the supply date (leveringsdato for goods, ytelsestidspunkt for services). For service periods that span days or weeks, the field is often labelled tjenesteperiode and carries a start and end date rather than a single point. The two dates are conceptually distinct and frequently differ: an invoice dated 5 October 2026 for services delivered across September 2026 is the routine case. AP red flag: a single date field where a period or a separate supply date should appear, particularly where a VAT-rate change falls between issuance and delivery — that situation needs an unambiguous supply date to determine which rate applies. Extraction note: extract both dates as separate fields and label the difference; collapsing them at extraction time loses information needed for VAT period assignment.

Place of supply. For goods, the place of supply is the delivery location. For remotely delivered services, it is typically the buyer's place of business, with sector-specific rules layered on top for cases like real estate, passenger transport, and digital services. AP red flag: missing place of supply on a cross-border services invoice is more than a clerical gap — it is what determines whether VAT should be charged at all and, if so, at what rate or under what reverse-charge regime. Query before posting. Extraction note: place of supply is often buried in a delivery-address line or in a footer notice; a dedicated extraction field forces it to surface even when the template treats it as boilerplate.

Description of the goods or services — the art og omfang requirement. The line items must describe what was supplied at sufficient granularity to identify the nature and scope of the supply. A single-line "Consulting services — September" with a flat fee does not meet the standard if "consulting services" was actually a project with discrete deliverables. The expectation is itemised lines with descriptions specific enough that a tax inspector reading the invoice would understand what was sold. AP red flag: a high-value invoice with a single uninformative line item is not just an audit issue — it makes downstream cost classification (project, department, expense category) impossible. Push back on the supplier and ask for an itemised reissue or a supplementary breakdown. Extraction note: line-level extraction routinely produces one row per line item, but invoice templates that compress everything into one line will produce one row with one description, and there is nothing the extraction tool can manufacture from text that is not there.

Consideration and payment due date. The vederlag is the agreed price; the forfallsdato is the date payment is owed. Norwegian convention typically shows forfallsdato in the header or footer area alongside the KID payment reference, sometimes labelled "betalingsfrist" or "forfall". AP red flag: a missing forfallsdato slows payment scheduling and is non-compliant content; a forfallsdato in the past on a freshly received invoice usually means the supplier set the due date relative to the invoice date and the document took time to arrive — query the date if the supplier expects on-time payment from the buyer's receipt date. Extraction note: capture forfallsdato as a date type rather than a string; payment-scheduling logic downstream will sort and bucket on the parsed date.

VAT amount per rate. Each VAT rate that applies on the invoice — 25, 15, 12, or 0 percent under the standing inventory, plus any reduced rate currently in force — must be shown separately, with its own net subtotal, VAT amount, and gross subtotal. A mixed-rate invoice (a hotel stay billed alongside a meal, say) needs the 12 percent and 15 percent components shown in their own rows or in a clearly delineated VAT summary, not blended into a single VAT line. AP red flag: a single VAT line on a multi-rate invoice obscures whether the rates were correctly applied and prevents the buyer from validating either component independently. Query the supplier for a rate-broken-out reissue rather than accepting the blended figure. Extraction note: capture VAT as an array of rate / net / VAT / gross records, not as a single VAT amount — a rate-aware extraction makes downstream tax coding straightforward and exposes the blended-line problem at a glance.

The KID payment reference, where present. The KID (kundeidentifikasjon) is a structured payment reference used in the Norwegian banking system to attach an incoming payment to the specific invoice it pays. It is not a §5-1-1 mandatory field — it is a banking convention rather than a regulatory requirement — but it appears on essentially every B2B invoice issued through a Norwegian banking arrangement, and it is what Norwegian AP and supplier-side reconciliation systems use to tie payment to invoice. Buyers paying without a KID where one is shown will trigger manual reconciliation work on the supplier side. The detail of how KIDs are validated and parsed sits in extracting the KID payment reference from a Norwegian invoice; for the field-list purposes of this article, the relevant point is that the KID belongs in the structured fields the AP system captures, not in a free-text "reference" field.

When AP systems read these fields off received Norwegian invoices, the §5-1-1 list above is essentially the field map an invoice data extraction tool runs against the document — the same field labels, in the same Norwegian and English forms, with the same validation expectations. Treating the regulatory list as the extraction schema is the cleanest way to keep what the tool captures and what the regulator expects to find on the same page.

§5-1-3 and the Locked, Gap-Free Invoice Numbering Rule

§5-1-3 of Bokføringsforskriften adds something to the §5-1-1 content list that the EU equivalent does not. Invoice numbering must be machine-controlled, pre-allocated, and unbroken. Each invoice number must be unique within the seller's bookkeeping, and the sequence as a whole must be auditable end to end — no gaps, no reused numbers, no manually-typed sequence that can be rewritten after the fact.

The contrast with the EU regime is the easiest way to understand the strictness. Article 226(2) of the EU VAT Directive requires "a sequential number, based on one or more series, which uniquely identifies the invoice" — it specifies the shape of the sequence but not the source of the allocation. A German seller can satisfy German VAT invoice requirements under §14 UStG with a sequence that is sequential and unique even if the seller types the next number into a Word template by hand. Norway's §5-1-3 layers an operational requirement on top of the same shape: the numbering source itself must be tamper-resistant. The point is not just that the numbers are sequential — it is that the seller can prove, at audit, that no number was issued and then deleted.

For issuers, the practical effect is that out-of-the-box Norwegian accounting systems do this for you. Tripletex, Visma, Conta, Fiken, PowerOffice, and the rest of the established stack each allocate invoice numbers from a controlled sequence and refuse to delete an invoice once it has been issued. A void becomes a credit note that draws its own number from the same sequence (or from a parallel sequence that is itself gap-free); the original invoice and its credit note both remain on the audit trail. Manual invoicing in Word or Excel is technically non-compliant unless the seller can evidence a gap-free audit trail through their own controls — which in practice means a manually-maintained register that survives audit scrutiny, and very few small businesses actually keep one. A bookkeeper inheriting a client who invoices through Word should treat moving to a controlled-numbering tool as one of the early housekeeping items, before the next year-end audit raises the question.

For AP teams, the rule turns invoice numbering into a real signal rather than a clerical curiosity. Receiving consecutive invoices 2026-1057 and 2026-1059 from the same supplier with no 2026-1058 in between is not noise — it is a gap in a sequence that the supplier is required to keep gap-free. The missing invoice exists somewhere: it was issued and either lost in transmission, sent to a different customer (or a different cost centre at the same customer), or improperly voided. Each of those possibilities matters. If you are missing documentation that should have reached you, you want it. If a sister entity received the missing invoice and posted it under a different vendor record, you want to know. And if the supplier voided the invoice without a credit note, that is a §5-1-3 issue on the supplier side that is worth flagging through your own AP commentary so it gets caught.

Honest about the grey area: enforcement of the audit-trail requirement is rare in practice on small-volume manual issuers, and a small Norwegian sole proprietor invoicing through a Word template will not usually attract a Skatteetaten audit on numbering grounds alone. The rule is the rule, however, and the audit posture for any seller above casual scale is that controlled numbering is what defensible bookkeeping looks like. The discipline does not become important only when the audit arrives; it becomes important the moment the volume of invoicing makes a manual register infeasible to reconstruct, which is sooner than most issuers expect.

Foreign Currency Invoices and the NOK VAT Display Rule

A Norwegian seller invoicing a foreign customer in EUR, USD, GBP, or any other non-NOK currency must still display the VAT amount in Norwegian kroner on the invoice itself, using a defensible exchange rate. The bookkeeping entry is in NOK regardless of the invoice display currency — the foreign-currency total is what the buyer pays, but the seller's books, the MVA-melding, and the audit trail all run in NOK.

Three exchange-rate sources are accepted in Norwegian practice: Skatteetaten's published rates, Norges Bank's daily fixings, and Norwegian Customs' valuation rates. The constraint is consistency. The chosen source must be applied consistently across periods — switching between sources between invoices to optimise VAT outcomes is not acceptable, and an audit that spots invoice-by-invoice rate-shopping will treat it as a real finding. Most issuers settle on Norges Bank as the default because it is the most accessible daily reference; what matters is that the choice is documented and stable.

A compliant template typically renders the two currencies side by side. Line-item amounts and the VAT figure appear in the invoice currency, with the NOK VAT amount and often the NOK total displayed alongside in their own column or in a clearly labelled supplementary section. The exchange rate and the rate date — the date the rate was sourced — sit in the footer or near the totals, so a reader can reconstruct the conversion without leaving the document. Some templates show the full NOK conversion of every line; others show only the NOK VAT amount and the NOK gross. Either is acceptable as long as the NOK VAT figure is unambiguous and the rate is disclosed.

For an AP team receiving such an invoice, the red flag is plain: an EUR or USD invoice from a Norwegian supplier that shows VAT only in the invoice currency, with no NOK equivalent and no exchange-rate disclosure, is non-compliant. The instinct to treat the omission as harmless because the foreign-currency figure is internally consistent is the wrong instinct — the supplier's books need the NOK figure to post correctly, and the absence on the invoice often points to the same absence in the supplier's underlying ledger. Query the supplier and ask for a reissue with the NOK VAT and the rate disclosed. If the supplier is using rate inconsistency rather than a missing rate, the reissue request itself usually surfaces the inconsistency.

The issuer-side discipline is the mirror image. The rate used for VAT display on the invoice should match the rate used for the bookkeeping entry. A template that pulls a live FX rate at invoice generation and a bookkeeping entry that pulls a different rate at posting time produces reconciliation drift at month-end and audit findings at year-end. The remedy is to fix the rate at invoice issuance — Norges Bank's morning fixing for the issue date, say — and use the same rate for both the invoice display and the bookkeeping entry on that document.

For currencies that are inconvertibly pegged or for which the published rate sources do not provide a daily fixing, practitioner convention is to use the most defensible available rate (typically a major-bank quote or an interbank fixing) and document the choice in the supporting workpapers. Skatteetaten guidance allows reasonable judgment in edge cases; what is not allowed is opaque rate selection without a documented basis. Retroactive corrections to the displayed NOK VAT after the invoice has been sent are handled through a credit note plus a corrected reissue, not through editing the original document.

For systems reading these invoices, the practical extraction note is to capture both the invoice-currency total and the NOK VAT amount as separate fields, alongside the rate and rate date. AP downstream systems that post the bookkeeping entry use the NOK figure; reconciliation against the foreign-currency payment uses the invoice-currency figure; auditors looking at the conversion later use the rate and date. Each consumer needs a different field, and a single "amount" field will not serve any of them well.

VAT Rates and the Exemption-Provision Reference Convention

The standard Norwegian VAT rate is 25 percent and applies to most goods and services. 15 percent applies to food and non-alcoholic beverages. 12 percent is the rate for passenger transport, cinema admission, and accommodation. 0 percent applies to specific exports, books, and newspapers. Reduced rates for narrow categories have come and gone across budget cycles — a 6 percent rate has appeared and lapsed in past years for sector-specific reductions — so a reader making a current-period decision should confirm against Skatteetaten's published rates rather than relying on any article. The figures above reflect the standing rates at time of writing.

Within the regime, two treatments produce no VAT charge but they are not interchangeable. Zero-rated supplies (nullsats) are inside the VAT system at a 0 percent rate — the supplier is registered, the supply is taxable, and input VAT on related costs remains deductible. Exempt supplies (fritak) sit outside the VAT system entirely — the supply is not taxable, and input VAT on related costs is generally not deductible. The buyer reading an invoice does not always need to distinguish the two, because the line shows no VAT either way; the supplier producing the invoice does need to distinguish them, because the citation that justifies the treatment differs.

That citation is the convention worth knowing in detail. Any invoice line that is exempt or zero-rated must carry a reference to the provision in Merverdiavgiftsloven (the VAT Act, abbreviated mval.) that authorises the treatment. The standard form is a short prefatory phrase plus the section reference. The export exemption looks like this on an invoice line: Fritatt for merverdiavgift, jf. mval. § 6-21. The healthcare-services exemption looks like Fritatt for merverdiavgift, jf. mval. § 3-3. The export-of-goods provision is mval. § 6-1. The literal jf. is the Norwegian abbreviation for jamfør — "compare" or "see also" — and is the practitioner-standard way of pointing to the section being relied on. Issuers substitute the section number that fits the specific supply; the convention is the prefix and the citation form, not any one section.

For an AP team reviewing a zero-rated or exempt invoice line, the citation is what closes the loop. A line showing 0 percent VAT or no VAT at all, without a citation to the exempting or zero-rating provision, is incomplete. The buyer's records inherit the supplier's missing citation, which becomes an audit issue downstream when a tax inspector asks why a line was not charged at the standard rate. The right response is to query the supplier for the citation rather than accepting the line as it stands; in most cases the supplier knows the section but their template does not surface it, and a reissue with the citation in place fixes the document for both parties.

For issuers, the operational requirement is that any invoice template that can produce a zero-rated or exempt line needs a free-text citation field on that line — a place for the jf. mval. § X-Y string to be entered or auto-populated based on the product or service category. Modern Norwegian accounting systems handle this through a chart of VAT codes that maps each supply type to its citation; manual templates often do not, and the omission is one of the most common compliance gaps on small-issuer invoices. The fix is structural rather than per-invoice: build the citation into the template once, mapped to the supply category, rather than relying on the issuer to remember to type it.

For systems extracting from invoices that mix standard-rated, zero-rated, and exempt lines, capturing the citation as a field alongside each line is what gives downstream tax classification a clean handle. A line with VAT amount zero and a populated citation field is exempt or zero-rated under a known provision; a line with VAT amount zero and an empty citation field should flag for review. The same extraction logic that surfaces a missing MVA suffix on a VAT-charging seller can surface a missing exemption citation on a zero-VAT line — the underlying check is the same shape: a value the regulation requires that the document does not carry.

Reverse Charge and Credit Notes — Two Annotations Worth Knowing

Two adjacent topics inherit most of their content from §5-1-1 and add only a small annotation each. They are short on purpose.

Reverse charge. When a Norwegian buyer of foreign services accounts for the VAT itself — self-assessing both output and input VAT in the same MVA-melding rather than receiving an invoice with VAT charged on the face — the invoice from the foreign supplier should carry an explicit reverse-charge annotation. The Norwegian convention is Snudd avregning (literally "reversed accounting"), and the EU-aligned form Reverse charge, VAT Directive 2006/112/EC art. 44 is also accepted on cross-border invoices. The annotation tells the buyer's AP system that the line carries no VAT to deduct because none was charged at source — the buyer is the one accounting for it. AP red flag from the buyer's side: a foreign-services invoice that arrives with no VAT charged and no reverse-charge annotation is ambiguous, because the absence of VAT could mean either reverse charge applies or the supplier has misunderstood the supply place. The annotation removes the ambiguity. The mechanics — when reverse charge applies, what services it covers, how it is reported on the MVA-melding — are out of scope here; the annotation convention is the field-list piece.

Credit notes (kreditnota). A Norwegian credit note inherits the full §5-1-1 mandatory content list — the same seller and buyer identification, the same date fields, the same descriptions, the same rate-by-rate VAT treatment. Two specific additions distinguish a credit note from an invoice. First, the credit note must carry an explicit reference to the original invoice number being credited; without it, the credit cannot be tied to the underlying transaction in either party's bookkeeping. Second, amounts are shown as negative or labelled clearly as a credit, so the document is unambiguous on its face. The same numbering discipline applies as for invoices: credit notes draw from the same gap-free sequence as invoices, or from a parallel sequence that is itself gap-free, with no reuse and no deletion. AP red flag: a credit note that does not reference the original invoice number is incomplete and the supplier should reissue with the reference attached; posting a credit against a guess at the original invoice creates reconciliation drift that surfaces later as an unexplained variance. Retention discipline for credit notes follows the same rules as for invoices, with the broader Bokføringsloven storage timeline covered in Norway SAF-T requirements and Bokføringsloven retention.

AP Gotchas Checklist for Norwegian Supplier Invoices

A Norwegian supplier invoice that fails any of the items below should be queried before posting. This is the consolidated valid Norwegian invoice AP checklist that lifts the field-by-field treatment above into a single working tool.

• Seller MVA suffix. Is the seller's organisasjonsnummer rendered with the literal "MVA" suffix on every invoice that charges VAT? Absence on a VAT-charging invoice points to non-compliance or an unregistered seller, and the buyer's input-VAT claim is exposed.
• Buyer organisasjonsnummer. Is your own orgnr present on B2B sales? Foreign-supplier invoices issued into Norway routinely omit this; ask the supplier to add the buyer-orgnr field to the template rather than accepting the omission invoice by invoice.
• Document date and supply date. Are both dates present and distinct where they differ? Service periods need an unambiguous start and end, particularly where a VAT-rate change falls inside the period.
• Place of supply. Is the place of supply stated, particularly on cross-border services where it determines whether VAT applies, at what rate, and under whose regime? Missing place of supply on a cross-border services invoice is more than a clerical gap.
• Line-item description granularity. Do the line items meet the art og omfang standard, or does a high-value invoice collapse into a single uninformative line? Push back on a flat-fee single-line invoice and ask for an itemised reissue.
• Vederlag and forfallsdato. Is the agreed price clearly stated and the payment due date present? KID where the supplier's banking arrangement uses one — captured into a structured field rather than a free-text reference.
• VAT amount per rate. On a multi-rate invoice, is the VAT broken out per rate with its own net subtotal, VAT amount, and gross subtotal, or is it blended into a single VAT line? A blended line obscures whether the rates were correctly applied.
• Sequential numbering across invoices from the same supplier. Is the invoice number sequence intact, or is there a gap? A missing number between two consecutive invoices is a real signal under §5-1-3 — raise the missing number as a query rather than treating it as noise.
• Foreign-currency NOK display. On non-NOK invoices, is the VAT amount shown in NOK alongside the invoice currency, with the exchange-rate source disclosed? An EUR or USD invoice that shows VAT only in the invoice currency is non-compliant.
• Exemption-provision citation. Do zero-rated or exempt lines carry the jf. mval. § X-Y citation? A zero-VAT line with no citation is incomplete; the buyer's records inherit the supplier's audit gap.
• Reverse-charge annotation. Do reverse-charge lines carry the Snudd avregning annotation, or the EU-directive-equivalent form? Without the annotation, a no-VAT line on a foreign-services invoice is ambiguous as to whether reverse charge applies or the supplier has misclassified the supply place.
• Credit-note cross-reference. Do credit notes reference the original invoice number being credited, with amounts shown as negative or clearly labelled? Posting a credit against a guess at the original invoice creates reconciliation drift that surfaces later.

For an AP team building this checklist into a tool rather than working through it by hand, the operational adjacency is that an extraction system reading these fields off received invoices can surface most of the failures above as automated flags — missing MVA suffix, missing buyer orgnr, missing forfallsdato, blended VAT line, missing exemption citation, foreign-currency invoice without NOK VAT — leaving the AP team to focus its attention on the queries that actually matter rather than reading every invoice from scratch. EHF XML received over Peppol is the structured-format equivalent of the same field list, and mapping EHF XML invoice fields to Excel for AP review covers the conversion when the AP team is working from XML rather than PDF.