Norway EHF XML to Excel: AP Field Mapping Guide

To convert a Norway EHF XML invoice to Excel, parse the file as a UBL invoice or credit note, then map the header, supplier, buyer, payment, VAT, totals, and line-item elements into spreadsheet columns. The XML is the source record. A PDF view, if one exists, is only a rendering of the structured invoice data.

For AP teams, the useful output is not a raw XML dump. It is a workbook that keeps invoice meaning intact: invoice number, issue date, due date, supplier name, supplier organisasjonsnummer, MVA identifier, KID payment reference, bank account, currency, VAT breakdown, payable total, and one or more line-item rows. The fields are already in the EHF file, but they sit inside a nested UBL structure rather than in the flat shape Excel users need for review, coding, reconciliation, or posting.

The practical task is to decide the spreadsheet shape first, then map the XML paths into that shape. A control workbook might use one row per invoice, with totals and payment fields. A spend-analysis workbook usually needs one row per InvoiceLine, with invoice-level fields repeated on each line. A payment-review workbook needs KID and account details treated carefully as text, because leading zeros and formatting are part of the data.

Norway's 2027 B2B e-invoicing shift is one reason more finance teams are asking this question. The regulatory timeline belongs in a separate readiness discussion, covered in our guide to Norway B2B e-invoicing requirements. This guide stays on the received-invoice workflow: what is inside an EHF XML file, which fields AP needs, where Norway-specific payment and VAT details live, and which conversion route produces a workbook that finance can actually use.

What is inside a Norwegian EHF invoice file

EHF is not a special Excel format and it is not a PDF with hidden invoice data. EHF Fakturering 3.0 is Norway's implementation of EN 16931 electronic invoicing through Peppol BIS Billing 3.0, and the official EHF Billing 3.0 specification includes UBL invoice, payment, tax, and line-item elements relevant to AP extraction.

The standards relationship matters because it tells you what kind of parser or workbook design you need. EN 16931 defines the business meaning of the invoice fields: invoice number, seller, buyer, VAT breakdown, payment terms, totals, and lines. Peppol BIS Billing 3.0 defines the interoperable e-invoice profile used in the Peppol network. EHF is the Norwegian use of that profile. UBL 2.1 is the XML vocabulary that carries the data, with basic fields in cbc: elements and grouped structures in cac: elements.

In practice, an AP export is reading a UBL document. A standard invoice uses an Invoice root. A credit note uses a CreditNote root. That difference should be detected before the file is flattened into rows, because credit notes need their own document type, amount handling, and posting logic. Treating every XML file as the same invoice shape is how a workbook starts looking complete while carrying wrong accounting meaning.

The useful parts of the file are grouped by invoice role. Supplier details are under cac:AccountingSupplierParty; buyer details are under cac:AccountingCustomerParty; payment instructions are under cac:PaymentMeans; totals are under cac:LegalMonetaryTotal; VAT details are under cac:TaxTotal and repeated cac:TaxSubtotal elements; line items are under repeated cac:InvoiceLine elements. A generic XML-to-Excel flattening can expose those names, but it does not know which fields belong together as one AP record.

That is why the PDF question should stay secondary. Some receiving systems render EHF XML into a human-readable PDF view, and some Peppol deliveries may include attachments. Those are useful for review, but the structured AP export should come from the XML. The XML is where the party identifiers, payment references, VAT subtotals, and line rows have machine-readable meaning.

Decide whether the workbook is invoice-level or line-level

Before mapping fields, choose the row grain of the workbook. EHF invoice line items to spreadsheet output can mean two very different things: one row per invoice for AP control, or one row per invoice line for coding and analysis. Both are valid, but they answer different finance questions.

An invoice-level sheet works when the task is payment review, supplier control, batch reconciliation, or a temporary register before ERP intake. Each row represents one invoice or credit note. The columns usually include source filename, document type, invoice number, issue date, due date, supplier, organisation number, MVA identifier, buyer reference, payment account, KID, currency, net total, VAT total, and payable amount. This shape is easy to reconcile against a folder of received files because every source document should become one control row.

A line-level sheet works when AP needs coding detail, purchase-order matching, line-item spend analysis, project allocation, or VAT review by line. Each row represents one InvoiceLine. Header fields must be repeated on every row: invoice number, supplier, issue date, due date, currency, document type, and source filename. Without those repeated fields, a line export becomes detached from the invoice it came from and is much harder to audit.

VAT breakdowns create a third design decision. A single invoice can contain more than one TaxSubtotal, especially when different tax categories or rates appear in the same document. For an invoice-level sheet, AP may need separate VAT columns by category or a related tax-detail tab. For a line-level sheet, tax details may sit on each line if the source carries line tax data, or in a separate VAT breakdown table keyed by invoice number.

The safest workbook for recurring AP work often has multiple tabs: an invoice header tab, an invoice line tab, and a VAT breakdown tab. Each tab should include the source filename and a stable document identifier so totals can be reconciled between tabs. That design is less pretty than a single flat sheet, but it preserves the parts of the EHF structure that matter for controls.

Core EHF fields to map into Excel columns

An EHF invoice field mapping should translate the XML into AP column names, not simply reproduce the XML tree. The table below uses common AP column names and the UBL paths finance teams usually need. Exact paths can vary slightly with party-identification choices and optional elements, but these are the fields to check first.

AP column	EHF or EN 16931 meaning	Common UBL path	Extraction note
DocumentType	Invoice or credit note	root document name, Invoice or CreditNote	Set before amounts are normalised. Do not infer only from signs.
InvoiceNumber	Invoice number, BT-1	cbc:ID	Store as text to preserve supplier formatting.
InvoiceTypeCode	Invoice type code, BT-3	cbc:InvoiceTypeCode	Useful for separating standard invoices, credit notes, and special invoice types.
InvoiceDate	Issue date, BT-2	cbc:IssueDate	Convert to a consistent date format in Excel.
DueDate	Due date, BT-9	cbc:DueDate	May be absent if payment terms are expressed another way.
BuyerReference	Buyer reference, BT-10 or buyer-side routing reference	cbc:BuyerReference	Often used for PO, department, or internal routing.
Currency	Invoice currency, BT-5	cbc:DocumentCurrencyCode	Preserve currency before comparing totals across suppliers.
SupplierName	Seller name, BT-27	cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName	Some files also carry trading names in other party-name elements.
SupplierOrgnr	Seller legal registration identifier, BT-30	supplier party legal entity cbc:CompanyID or party identification	Preserve schemeID when available, especially 0192 for Norwegian organisation numbers.
SupplierMVA	Seller VAT identifier, BT-31	cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID where tax scheme is VAT	Usually appears in the Norway style NO plus organisation number plus MVA.
BuyerName	Buyer name, BT-44	cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName	Useful for shared-service teams processing several Norwegian entities.
BuyerOrgnr	Buyer legal registration identifier, BT-47	buyer party legal entity cbc:CompanyID or party identification	Keep separate from supplier identifiers.
PaymentMeansCode	Payment means, BT-81	cac:PaymentMeans/cbc:PaymentMeansCode	Helps distinguish bank transfer, SEPA, direct debit, and other payment routes.
PaymentAccount	Payment account, BT-84	cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID	Treat BBAN and IBAN values as text.
KID	Remittance information, BT-83	cac:PaymentMeans/cbc:PaymentID	This is the field AP should inspect before payment matching.
NetTotal	Sum of invoice line net amounts, BT-106	cac:LegalMonetaryTotal/cbc:LineExtensionAmount	Reconcile against line-level export.
TaxExclusiveTotal	Invoice total excluding VAT, BT-109	cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount	Use for net control totals.
TaxInclusiveTotal	Invoice total including VAT, BT-112	cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount	May differ from payable amount if allowances, charges, or rounding apply.
PayableAmount	Amount due for payment, BT-115	cac:LegalMonetaryTotal/cbc:PayableAmount	Payment-review workflows should use this as the due amount.
VATTaxableAmount	VAT breakdown taxable base, BT-116	cac:TaxTotal/cac:TaxSubtotal/cbc:TaxableAmount	Repeat by VAT category or rate.
VATAmount	VAT breakdown amount, BT-117	cac:TaxTotal/cac:TaxSubtotal/cbc:TaxAmount	Preserve currencyID where present.
VATCategory	VAT category, BT-118	cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID	Do not replace category with only the percent.
VATPercent	VAT rate, BT-119	cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:Percent	Can be zero for exempt, reverse charge, or out-of-scope categories.
LineNumber	Invoice line identifier, BT-126	cac:InvoiceLine/cbc:ID	One row per repeated InvoiceLine in a line-level sheet.
ItemName	Item name, BT-153	cac:InvoiceLine/cac:Item/cbc:Name	Usually the most useful line description for AP review.
Quantity	Invoiced quantity, BT-129	cac:InvoiceLine/cbc:InvoicedQuantity	Preserve unit code if the workbook supports it.
UnitPrice	Item net price, BT-146	cac:InvoiceLine/cac:Price/cbc:PriceAmount	Keep separate from line net amount.
LineNetAmount	Line net amount, BT-131	cac:InvoiceLine/cbc:LineExtensionAmount	Reconcile the sum to the invoice-level line extension amount.

The KID column deserves special handling. In EHF, the KID or remittance reference belongs in cbc:PaymentID under cac:PaymentMeans, not in a random note field. Store it as text, keep leading zeros, and validate it separately if the payment process depends on checksum accuracy. The validation logic is covered in more depth in our guide to extracting KID numbers from Norwegian invoices.

For credit notes, apply the same mapping logic to the credit-note-specific paths. A CreditNote document uses fields such as cbc:CreditNoteTypeCode and repeated cac:CreditNoteLine elements rather than the invoice-only line structure. The workbook can still use the same AP column names, but the parser should read from the correct root and line elements.

For supplier identifiers, keep the plain organisation number and the VAT identifier in separate columns. A supplier organisation number with schemeID="0192" identifies the Norwegian legal entity. The MVA identifier is the VAT registration value, commonly represented as NO plus the organisation number plus MVA. Combining those fields into one "supplier ID" column makes downstream checks harder.

The same principle applies to totals. PayableAmount is the payment amount, but it is not a substitute for the net total, tax exclusive total, tax inclusive total, and VAT subtotals. A useful AP workbook lets the reviewer check the invoice total from several angles rather than trusting a single flattened amount.

Norway-specific extraction details that break generic converters

The first Norway-specific field to preserve is the organisation number scheme. Norwegian party identifiers commonly use schemeID="0192". If an XML-to-Excel converter exports only the numeric value and drops the scheme, the workbook loses evidence that the identifier is a Norwegian organisasjonsnummer rather than an account number, customer code, or free-text party reference. A parser for AP use should keep either the scheme in a separate column or a combined identifier such as 0192:987654321.

The MVA identifier is related but not the same field. A Norwegian VAT-registered supplier may carry a VAT company ID in the form NO987654321MVA. That value should not replace the legal organisation number. AP teams often need both: the organisation number for supplier master-data matching and the MVA identifier for VAT registration checks. The supplier-side rules behind these fields are set out in our checklist of mandatory fields on a Norwegian MVA invoice under §5-1-1, which explains why the MVA suffix and locked numbering matter on the issued document. A missing MVA suffix is also meaningful, because it may indicate that the supplier is not VAT registered, that the invoice involves reverse-charge VAT for foreign services in Norway, or that the tax scheme data needs review.

Payment fields have the same problem. cbc:PaymentID is remittance information, and in Norwegian AP work that is where the KID normally appears. The payment account sits elsewhere, under cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID, and can be a BBAN or IBAN depending on the payment route. A generic converter may place all payment children into adjacent columns without telling the AP user which one is the reference to send with the payment and which one is the account to pay.

Currency also needs care. Do not assume every amount in the file belongs to the same currency context just because cbc:DocumentCurrencyCode appears near the top of the invoice. Tax totals and subtotals can carry their own currencyID attributes, and foreign-currency invoices may include a separate NOK tax amount or parallel TaxTotal for Norwegian VAT reporting. A robust export preserves the currency attached to each tax amount instead of stripping it during flattening.

Repeated nodes are the most common reason a converter produces unusable output. A single invoice can have many InvoiceLine elements, several TaxSubtotal elements, more than one payment means, and attachments or references that do not belong in the main AP row. If those repeated nodes are flattened into columns like Line1, Line2, Line3, the workbook becomes fragile as soon as a supplier sends an invoice with more lines than expected. If they are exploded without repeating header fields, the workbook loses traceability.

Credit notes should be handled as their own document type. In EHF, a credit note is not just an invoice with a negative total hidden somewhere in the same node structure. It can arrive under a CreditNote root and carry credit-note-specific semantics. The export should mark the document type explicitly, preserve the supplier's credit note number, and apply any sign-normalisation rules consistently after extraction rather than guessing from one amount column.

Three practical routes from EHF XML to Excel

Excel Power Query is workable for one-off review and small batches. Use Get Data from XML, inspect the loaded tables, expand nested cac: records, and select only the fields needed for the workbook. The difficult part is not opening the file. The difficult part is expanding the right repeated structures without losing the relationship between invoice header, tax subtotal, payment means, and line rows. Namespaces also make the first pass less friendly than a normal CSV import, so this route suits a finance user who is comfortable inspecting data shapes.

Generic XML-to-Excel and EHF-to-CSV converters are useful for inspection. They can show what is inside a file quickly, and they may be enough when the only question is whether a supplier sent a readable EHF invoice. They are a weak fit for routine AP processing. Supplier invoice XML contains personal and commercial data, so uploading it to a free converter deserves a privacy review. The output also tends to be either too flat, with repeated nodes forced into wide columns, or too exploded, with rows that no longer carry the invoice context AP needs.

A developer parser or AP automation parser is the better route for recurring batches. The parser should detect Invoice versus CreditNote, preserve source filenames, map a stable set of UBL paths, repeat header fields on line rows, separate VAT breakdowns where needed, and leave payment references as text. It should also fail visibly when a required field is missing rather than silently producing a blank column. That matters when the workbook feeds posting, supplier checks, or payment review.

This pattern is not unique to Norway. Other Peppol implementations create similar XML-to-spreadsheet problems, with local rules layered on top of the same invoice-data concepts. For comparison, our guide to Peppol XML invoice to Excel mapping covers a Singapore InvoiceNow version of the same structured-invoice problem.

Mixed AP intake needs a clear split by source type. EHF XML should be handled by an XML-aware parser that preserves the standard's structure. PDF and image invoices need separate invoice data extraction workflows that read the visible document and export structured Excel, CSV, or JSON. Keeping those routes separate prevents a false assumption that one converter can process every invoice format with the same field logic.

AP checks before using the exported workbook

Before using an EHF invoice extract in AP, reconcile the workbook back to the source folder. Count the XML files, count invoices and credit notes separately, and confirm every exported row carries the source filename. If the workbook has invoice header, line, and VAT tabs, the same document identifiers should appear across all three.

Check totals at invoice level before trusting line-level analysis. Sum line net amounts back to LineExtensionAmount, compare VAT subtotals to the invoice VAT total, and compare the payable amount to the amount intended for payment review. Differences may be valid because of rounding, allowances, charges, or credit-note sign handling, but they should be visible rather than hidden by the export.

Treat identifiers and payment references as text. Organisation numbers, MVA identifiers, KID values, BBANs, IBANs, invoice numbers, and buyer references can contain leading zeros or formatting that Excel may otherwise alter. A workbook that converts those fields into numbers can pass a visual review and still fail supplier matching or payment processing.

For line-item exports, make sure every row is traceable without looking at the XML again. Each line should carry at least supplier name, supplier organisation number, invoice number, issue date, currency, document type, source filename, line ID, item name, quantity, unit price, and line net amount. Rows that only contain item names and amounts are not enough for AP analysis.

VAT subtotals need their own check. If an invoice contains multiple tax categories or rates, the export should not collapse them into a single VAT percent column. Preserve the taxable amount, tax amount, category, percent, and currency for each subtotal, or put those details in a separate VAT tab keyed to the invoice.

For occasional inspection, Power Query or a converter may be enough. For recurring AP processing, use a mapping that preserves invoice semantics, repeated nodes, document type, source traceability, Norway-specific payment fields, and VAT currency details. The output should look like an AP workbook, not like an XML tree squeezed into Excel.