NAV M2M error codes and result codes

Identification

The call stopped where NAV determines who the sender is and on whose behalf they act. Business content is not processed yet.

• Is the access token valid? NAV documentation states that the token has a limited lifetime for security reasons.
• Is the signing key complete? It is assembled from two parts: one comes from the API Key, the other from redeeming the nonce. A missed or repeated redemption produces a bad signature.
• The nonce is single-use and, according to the specification, not suitable for reuse.
• The signature is built from the relevant business content. If the content changed after signing, the signature will not match.
• Sender and taxpayer are two different concepts: one identifies who calls the service, the other on whose behalf.

Authorisation

Identification succeeded, but there is no permission for the operation or the given taxpayer. This is an authorisation question, not a development one.

• NAV’s terms of use require the client-program user to have adequate representation rights for the taxpayer on whose behalf they act.
• Permission may differ by document type: authorisation to submit one type does not cover another.
• For an accounting firm this is a per-client setting, not a one-off step.
• If the response mailbox identifier is not allowed, submission authorisation may still be in place — then the response destination must be clarified.

Data and schema

The submitted file’s structure or content does not match what the given document version expects.

• Document type and document version identify together. The correct type with the wrong version is still rejected.
• According to NAV, new-format documents have a per-document XSD. The schema can be obtained from the form repository at type and version level.
• Validation and calculation are based on XSLT files containing XPath, and according to the specification can also be run on the client machine. It is worth running them before submission.
• For character and encoding errors, check the file encoding first, not the content.

File and attachment

Handling of the file or attachment failed: size, compression, checksum or identifier.

• The file identifier is single-use: after use it cannot be referenced again with the same identifier.
• A checksum error typically means the uploaded content differs from what the hash was computed for. Repeat the upload step.
• According to NAV’s vocabulary, attachments are linked to the document per sub-document. If an attachment is not found, check this assignment first.
• On a virus flag the file cannot be repaired on the sender side: a new, checked file must be produced.

No result

The call was technically fine, but there is no data for the queried scope. In many cases this is not an error but a valid response.

• Check the queried period: it is possible that no data was produced for that period.
• Query identifier and case identifier have separate lifecycles. An expired or incorrectly supplied identifier likewise yields a response with no data.
• The integration should not treat this as a fault. For the user it means there is no such item — not that the service failed.

In progress

The operation started but has not finished. These are not errors, but intermediate states.

• According to the specification a document passes several states — pre-check, check, submission — so the final result must be awaited with a query.
• Keep the query cadence moderate: NAV applies traffic limits, and overly frequent calls themselves cause errors.
• Show the intermediate state to the user as well, otherwise they will resubmit.

Success

The operation completed. On document submission the success response also includes the receipt number.

• Successful schema and pre-check is not the same as the tax content being correct: formal compliance is not tax approval.
• Store the receipt number; it later identifies the submission.

Other

A catch-all category. The specification itself reserves a general error code; traffic limits and unsupported queries also belong here.

• The general error code does not diagnose. Log request data and response identifiers; they are the starting point for a support enquiry.
• The specification treats message identifier and correlation identifier as separate header fields. Without logging them, an error cannot be traced later.
• On traffic limiting it is not the request content that is wrong, but the call cadence.

Is this an official NAV list?

The code list is built from the NAV M2M OpenAPI descriptions, and every code shows which enum it appears in, so it can be checked at the source. Grouping and checklists are editorial additions, because NAV does not publish a per-code explanation in the OpenAPI.

Why is there no separate explanation for every code?

Because without an official source that would be guesswork. Where NAV does not publish an interpretation, neither do we: we group codes by cause and attach checklists to the group.

Are these eVAT error codes?

No. These are result codes of the NAV M2M interface. eVAT M2M is a separate channel, with its own schema and error set. For schema-level checks of eVAT XML, use the free XML checker.

Is the list updated?

Versioned OpenAPI files are published on NAV’s public repository. When a new version appears we regenerate the list, and the page always states which specification versions it was built from.