Registry entry

Norway Notification of Move Within Norway (Flyttemelding) — RF-1400B

Skatteetaten's (the Norwegian Tax Administration) form RF-1400B, "Flyttemelding – flytting innen Norge (for personer med fødselsnummer)" ("Notification of moving within Norway, for persons with a fødselsnummer"), used to register a change of residential address in Folkeregisteret (the National Population Register) for a person, or a family group moving together, who already hold a Norwegian fødselsnummer (national identity number). This is the closest analogue this jurisdiction has to a civic-registration/National-ID-vertical form: Norway's actual national ID card ("nasjonalt ID-kort") is issued only via an in-person, biometric-appointment process with no downloadable application form, so — following this registry's established precedent for Nordic jurisdictions whose primary identity-document channel is in-person-only (e.g. Finland's `fi/dvv/registration-of-foreigner`) — this civil-registration form is modelled instead. This schema models the form's own two-page applicant-facing content in full: the sender/notifier block (which supports a joint submission by up to two people, e.g. spouses filing together), the repeating table of up to 7 people the move is being reported for, the mutually-exclusive choice between a street address and a farm-and-use-number ("gårds- og bruksnummer") property address for the new residence, the move date, the optional domestic-or-foreign mailing address (used only if different from the new residential address), the identification-copy requirement, and the signature date. It does not model the physical wet-ink signature itself (the source PDF has no signature widget) or the form's own second-page purely-informational content (an explanation of what a bruksenhetsnummer is, and general rules for determining registered residence), since neither is an applicant-entered field. Submitting this notification is a citizen action performed directly with Skatteetaten (electronically via skatteetaten.no, the form's own stated preferred channel, or by mailing this paper specimen); this schema does not submit the notification itself, and the live source (skatteetaten.no) is always authoritative. GovSchema is independent and is not affiliated with, endorsed by, or operated by the Kingdom of Norway or Skatteetaten.

Registry entry

no/skatteetaten/notification-of-move-within-norway

Jurisdiction
Norway · national
Version
1.0.0
Verification
draft
Authority
Skatteetaten (the Norwegian Tax Administration)

Authoritative source RF-1400B (2019 edition), "Flyttemelding – flytting innen Norge (for personer med fødselsnummer)", a 2-page fillable AcroForm PDF published unauthenticated by Skatteetaten.

Machine access

Schema document
registry/no/skatteetaten/notification-of-move-within-norway/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/no/skatteetaten/notification-of-move-within-norway/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

55 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • senderFullName1 string required

    The full name of the person notifying the move (the notification's primary sender).

    length: 0–200classification: pii
  • senderCivilRegistrationNumber1 string required

    The primary sender's 11-digit Norwegian fødselsnummer (national identity number). This form variant is explicitly scoped, per its own title, to persons who already hold one.

    patternclassification: sensitive-pii
  • senderFullName2 string optional

    If this notification is submitted jointly by two people (e.g. spouses, partners, or cohabitants moving together), the second sender's full name.

    length: 0–200classification: pii
  • senderCivilRegistrationNumber2 string optional

    The second joint sender's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • contactEmail string required

    An email address Skatteetaten can use to contact the sender(s) about this notification.

    length: 0–200classification: pii
  • contactPhone string required

    A phone number Skatteetaten can use to contact the sender(s) about this notification.

    length: 0–30classification: pii
  • addressType enum required

    The form's own mutually-exclusive choice ("Velg én" — "Choose one") between a conventional street address (fill in the street-address block, section D) and a rural property identified only by its farm number/use number (fill in the property-address block, section E). Modelled from two independent Btn (checkbox) widgets that the form's own instruction text and layout make clear are meant as a single either/or choice, not two independently answerable questions.

    enum: street | property
  • moveDate date required

    The date of the move. The form's own instruction states a move may be reported up to 31 days ahead of the actual date. Modelled as a single date field from the source PDF's own three separate day/month/year text widgets.

  • movingPerson1Name string required

    The full name (surname, given names, and middle name) of the first person the move is being reported for. Per the form's own instruction, this can be the sender themselves, a spouse/partner/cohabitant with a common child, and/or a child the sender has parental responsibility for who is moving along.

    length: 0–200classification: pii
  • movingPerson1CivilRegistrationNumber string required

    The first person's 11-digit Norwegian fødselsnummer.

    patternclassification: sensitive-pii
  • movingPerson2Name string optional

    The full name of the second person the move is being reported for, if any (e.g. a spouse or child moving together with person 1).

    length: 0–200classification: pii
  • movingPerson2CivilRegistrationNumber string optional

    The second person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • movingPerson3Name string optional

    The full name of the third person the move is being reported for, if any.

    length: 0–200classification: pii
  • movingPerson3CivilRegistrationNumber string optional

    The third person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • movingPerson4Name string optional

    The full name of the fourth person the move is being reported for, if any.

    length: 0–200classification: pii
  • movingPerson4CivilRegistrationNumber string optional

    The fourth person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • movingPerson5Name string optional

    The full name of the fifth person the move is being reported for, if any.

    length: 0–200classification: pii
  • movingPerson5CivilRegistrationNumber string optional

    The fifth person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • movingPerson6Name string optional

    The full name of the sixth person the move is being reported for, if any.

    length: 0–200classification: pii
  • movingPerson6CivilRegistrationNumber string optional

    The sixth person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • movingPerson7Name string optional

    The full name of the seventh person the move is being reported for, if any.

    length: 0–200classification: pii
  • movingPerson7CivilRegistrationNumber string optional

    The seventh person's 11-digit Norwegian fødselsnummer, if applicable.

    patternclassification: sensitive-pii
  • newStreetMunicipality string optional

    The municipality (kommune) of the new street address, section D.

    length: 0–200classification: pii
  • newStreetName string optional

    The street name of the new residential address.

    length: 0–200classification: pii
  • newStreetHouseNumber string optional

    The house number of the new residential address.

    length: 0–20classification: pii
  • newStreetHouseLetter string optional

    The house letter of the new residential address, if the building has one.

    length: 0–5classification: pii
  • newStreetUnitNumber string optional

    The bruksenhetsnummer (unit number, e.g. "H0301") of the new residential address, required by Skatteetaten whenever the building has more than one dwelling.

    length: 0–10classification: pii
  • newStreetPostalCode string optional

    The postal code of the new residential address.

    patternclassification: pii
  • newStreetPostTown string optional

    The post town of the new residential address.

    length: 0–200classification: pii
  • newStreetAdditionalAddress string optional

    Any additional address information for the new residential address, e.g. a c/o line.

    length: 0–200classification: pii
  • propertyMunicipality string optional

    The municipality (kommune) of the new property address, section E — used when the new residence has only a farm number/use number, not a street address.

    length: 0–200classification: pii
  • propertyPlaceName string optional

    The name of the place or property.

    length: 0–200classification: pii
  • propertyFarmNumber string optional

    The property's gårdsnummer (farm number) in the Norwegian cadastral system.

    length: 0–20classification: pii
  • propertyUseNumber string optional

    The property's bruksnummer (use number) in the Norwegian cadastral system.

    length: 0–20classification: pii
  • propertyLeaseholdNumber string optional

    The property's festenummer (leasehold number), if the property is a leasehold plot.

    length: 0–20classification: pii
  • propertySubNumber string optional

    The property's undernummer (sub-number), if applicable.

    length: 0–20classification: pii
  • propertyUnitNumber string optional

    The bruksenhetsnummer (unit number) of the new property address, if the building has more than one dwelling.

    length: 0–10classification: pii
  • propertyPostalCode string optional

    The postal code of the new property address.

    patternclassification: pii
  • propertyPostTown string optional

    The post town of the new property address.

    length: 0–200classification: pii
  • propertyAdditionalAddress string optional

    Any additional address information for the new property address, e.g. a c/o line.

    length: 0–200classification: pii
  • mailingDomesticMunicipality string optional

    The municipality of a domestic mailing address, used only if the sender(s) want mail sent somewhere other than the new residential address. Fill in either the domestic mailing address block or the foreign mailing address block, not both — this exclusivity is disclosed here rather than enforced structurally, since the source form has no dedicated choice widget for it (unlike the addressType choice in section B, which uses two Btn widgets).

    length: 0–200classification: pii
  • mailingDomesticStreetOrPlaceName string optional

    The street name, PO box, or place/property name of the domestic mailing address.

    length: 0–200classification: pii
  • mailingDomesticHouseNumber string optional

    The house number/letter of the domestic mailing address.

    length: 0–20classification: pii
  • mailingDomesticUnitNumber string optional

    The bruksenhetsnummer of the domestic mailing address, filled in only if the mailing address is itself a residential address.

    length: 0–10classification: pii
  • mailingDomesticPostalCode string optional

    The postal code of the domestic mailing address.

    patternclassification: pii
  • mailingDomesticPostTown string optional

    The post town of the domestic mailing address.

    length: 0–200classification: pii
  • mailingDomesticAdditionalAddress string optional

    The name on the mailbox or PO box for the domestic mailing address, if applicable.

    length: 0–200classification: pii
  • mailingForeignAdditionalAddress string optional

    The name on the mailbox for a foreign mailing address, used only if the sender(s) want mail sent abroad. Fill in either the domestic mailing address block above or this foreign mailing address block, not both.

    length: 0–200classification: pii
  • mailingForeignAddressName string optional

    The street/address name of the foreign mailing address.

    length: 0–200classification: pii
  • mailingForeignBuildingName string optional

    The name of the building at the foreign mailing address, if applicable.

    length: 0–200classification: pii
  • mailingForeignPoBox string optional

    The PO box of the foreign mailing address, if applicable.

    length: 0–50classification: pii
  • mailingForeignPostalCode string optional

    The postal code of the foreign mailing address.

    length: 0–20classification: pii
  • mailingForeignCityOrPlace string optional

    The city or place name of the foreign mailing address.

    length: 0–200classification: pii
  • mailingForeignCountry string optional

    The country of the foreign mailing address.

    length: 0–100classification: pii
  • signatureDate date required

    The date the notification is signed. Per the form's own footnote, when a family moves together only one signature and one identification copy (of the signer) is required, except where two parents with joint parental responsibility for a child under 18 must both sign (e.g. a shared-residence arrangement, or one parent moving out of a shared home with the child).

Verification record

Candidate selection

GOV-2323 ("GovSchema Standard Research") is the latest firing of this registry's recurring standard-research routine. CATALOG.md's own "Known Gaps & Opportunities" section (item 8) had already pre-scouted three open Norway candidates from the GOV-2316 parent cycle (Business Formation opened Norway as the registry's 35th jurisdiction), each confirmed to have a live, unauthenticated, directly-downloadable form:

  • National ID: Skatteetaten's RF-1400B, "Flyttemelding" (move notification), ~63 widgets (pre-scout estimate).
  • DMV: Statens vegvesen's driving-licence application, ~82 widgets.
  • Visa: UDI's form GP7028, ~328 widgets, disclosed by the pre-scout as UDI's legacy/paper fallback rather than its primary online-portal path.

RF-1400B was picked: it is the smallest and most tightly-scoped of the three, closes Norway's National ID & Civic Documents vertical (Norway's actual national ID card is an in-person/biometric-issuance process with no downloadable application form — this civil-registration-of-address-change form is the closest analogue, the same pattern this registry's fi/dvv/registration-of-foreigner precedent established for Finland), and needed no further live-portal-vs-paper-fallback question mark the way GP7028 did.

Source

  • URL: https://www.skatteetaten.no/globalassets/skjema/alltid/rf1400b-flytte-i-norge.pdf
  • Fetched fresh this session with a plain HTTP GET: HTTP 200, 238,950 bytes, genuine %PDF header, served via Cloudflare with no login/CAPTCHA/WAF gate.
  • Edition: the form's own footer prints "RF1400B - 2019" on both pages (the 2019 edition, currently the live download as of this cycle).

Extraction technique

pdfjs-dist v3.11.174 (legacy/build/pdf.js, installed fresh to a disposable /tmp directory) was used via page.getAnnotations() per page:

  • Page 1: 43 Widget annotations (40 Tx text fields, 2 Btn checkbox fields for the street/property address-type choice, all with self-documenting Norwegian fieldNames — no generic/sequential names on this specimen).
  • Page 2: 18 Widget annotations (15 Tx text fields, 3 Btn checkbox fields for the identification-type choice).
  • 61 widgets total, close to but not identical to the GOV-2316 pre-scout's own approximate figure of ~63 — a quick-scout estimate, not a discrepancy requiring reconciliation.

page.getTextContent() was also extracted per page and read in full to recover the form's own section lettering (A through I) and every printed instruction, confirming the semantic grouping used below.

Field mapping (61 widgets → 55 fields + 1 documents[] entry)

The 61 raw widgets were consolidated into 55 schema fields via three disclosed, source-justified collapses (all following this registry's own established precedent for multi-widget/single-concept forms, e.g. dk/cpr/notification-of-entry's single boolean from a Ja/Nej checkbox pair):

  1. Move date (Dag/Måned/År, 3 widgets) → single moveDate date field, matching this registry's own dk/cpr entryDate precedent.
  2. Address-type choice (Gateadresse (fyll ut adresse D) / Stedsadressegårds og bruksnummer fyll ut adresse E, 2 Btn widgets) → single addressType enum field (street / property), gating the street-address block (section D) and property-address block (section E) via visibleWhen/requiredWhen, since the form's own instruction text ("Velg én" — "Choose one") and the mutually-exclusive D/E layout make clear this is a single either/or choice, not two independent questions.
  3. Identification-type choice (Kopi av pass / Kopi av førerkort / Kopi av annen legitimasjon som inneholder, 3 Btn widgets) → single documents[] entry (identificationCopy, category identity-document) with an acceptedTypes array, following this registry's own mx/sre/passport-application precedent for a checkbox-selection group of acceptable ID-document types.

Every other widget maps one-to-one to a schema field. The repeating "Hvem melder du flytting for?" table (up to 7 rows, each a Navn + Fødselsnummer pair) is modelled with this registry's established bounded repeating-group convention (movingPersonN..., matching dk/cpr's entrantN... and fi/migri's equivalent pattern): only movingPerson1's two fields are required: true (the form is always reporting a move for at least one person); movingPerson2 through movingPerson7 are all optional, with no visibleWhen/requiredWhen chaining between rows — matching the dk/cpr precedent exactly, since the source form imposes no such sequencing rule itself (a sender could, in principle, leave row 2 blank and fill row 3, though the form's own top-to-bottom layout makes that unlikely in practice).

The two mailing-address blocks (section G — domestic-in-Norway vs. foreign) are each modelled as fully optional field groups. Unlike the addressType choice in section B, the source form has no dedicated choice widget distinguishing "domestic" from "foreign" mailing address — its own instruction text just says to fill in one block or the other. This schema discloses that mutual exclusivity in each field's own description rather than inventing a synthetic choice field or a crossFieldValidation rule not backed by an actual source widget, consistent with this registry's "spec precision over cleverness" convention of not modelling structure the source form itself does not express.

The signature widget itself (Underskrift(-er), printed in section I) has no corresponding AcroForm field on this specimen — a wet-ink/physical signature line, not a fillable widget — so no schema field models it, matching the same absence in this registry's dk/cpr and dk/um precedents. The form's own confirmation clause ("Jeg/vi bekrefter at informasjonen i skjemaet er riktig") is modelled as an attestation category documents[] entry instead, with the exact clause text preserved verbatim in statement.

Conformance run

Two mock scenarios were authored with valid synthetic (non-real) data and checked against a disposable checker script that evaluates every field's required/requiredWhen/visibleWhen/validation (pattern, enum, maxLength, date format) and every documents[] entry's required/requiredWhen — the latter specifically because a prior cycle on this registry (fi/migri/residence-permit-employed-person, GOV-2280/ GOV-2282) found that a disposable checker limited to fields[] alone can report a false "0 errors" on a schema with unconditionally-required documents:

  • single-person-street-address-minimal.json — one sender, one moving person, the street-address path (section D), no mailing-address override. 0 errors.
  • joint-family-property-address-with-foreign-mailing.json — two joint senders, three moving persons (a couple plus a child), the property-address path (section E, gårdsnummer/bruksnummer), and a foreign mailing address filled in (section G). 0 errors.

Both fixtures also pass node tools/validate.mjs and node tools/validate-ajv.mjs (structural + meta-schema conformance) for the schema document itself; registry-index.json was regenerated via npm run build-index and the full registry re-validated at 354/354 documents passing (up from 353 before this addition).

Disclosed judgment calls

  • Bruksenhetsnummer fields (newStreetUnitNumber, propertyUnitNumber, mailingDomesticUnitNumber) are left optional in every case, even though the form's own footnote states it must be filled in whenever the building has more than one dwelling — a condition this schema has no other field to test against (no unit/dwelling-count field exists on the form itself), so it is disclosed in each field's own description rather than enforced structurally, matching this registry's established pattern for conditions the source form states in prose but provides no gating field for (e.g. fi/dvv's maritalStatus).
  • Mailing-address mutual exclusivity (domestic vs. foreign) is disclosed in prose, not a crossFieldValidation rule, since no source widget expresses the choice structurally (see "Field mapping" above).
  • fødselsnummer pattern (^[0-9]{11}$) follows Norway's standard 11-digit personal-identity-number format (6-digit date of birth + 5-digit personal number), consistent with this registry's existing Nordic precedents' own national-identity-number patterns (e.g. Denmark's 10-digit CPR-nummer, Finland's henkilötunnus format).

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Skatteetaten (the Norwegian Tax Administration) or any government. The authoritative source is always the live government form and its official instructions.