Registry entry

Rwanda Motor Vehicle Registration Form (RRA-MVD-VRF-E06)

Rwanda Revenue Authority (RRA)'s Motor Vehicle Registration Form (printed form code RRA-MVD-VRF-E06), used to register a motor vehicle with RRA's Motor Vehicle Division — Rwandan law assigns motor-vehicle registration to the tax authority rather than to a separate transport/transit agency, unlike most jurisdictions in this registry. Opens Rwanda as GovSchema's 43rd jurisdiction, via the DMV vertical (1 of 6). The specimen is a single-page, genuine AcroForm/XFA PDF (`form1[0]`) published directly and unauthenticated from rra.gov.rw, covering four applicant-facing sections: Owner Identification (A), Registration Information (B, including customs-regime particulars for an imported vehicle), Vehicle Information (C), and Certification (D). A fifth section, "For RRA Use Only" (E), is a printed office block (cashier/clearance signatures, assigned plate/card numbers, receipt particulars) and is out of scope of `fields[]`; see VERIFICATION.md for the full section-by-section exclusion rationale. The underlying PDF has a genuine authoring defect: a single AcroForm radio-button field object (`RadioButtonList[0]`) is reused across two unrelated printed questions — the Section C "Steering Wheel" selector (Left/Right/N-A) and the Section B "Customs Regime" selector (Consumption/Suspension) — meaning in a real PDF viewer, selecting one of these would silently clear a selection made for the other, since PDF radio widgets sharing one fully-qualified field name are mutually exclusive across their combined kid set. This schema does not preserve that defect: the two questions are modelled as two independent `enum` fields (`steeringWheelPosition`, `customsRegime`), disclosed here and in VERIFICATION.md rather than silently "fixed" without comment, per this registry's established field-name-reuse-across-repeating-elements disclosure precedent (cf. `ng/cac`, `no/brreg`). GovSchema is independent and is not affiliated with, endorsed by, or operated by the Government of Rwanda or the Rwanda Revenue Authority.

Registry entry

rw/rra/vrf-e06-motor-vehicle-registration-form

Jurisdiction
Rwanda · national
Version
1.0.0
Verification
draft
Authority
Rwanda Revenue Authority

Authoritative source "Motor Vehicle Registration Form", form code RRA-MVD-VRF-E06 (Rwanda Revenue Authority, Motor Vehicle Division), 1-page fillable AcroForm/XFA PDF (46 widgets: 37 text, 5 radio-button, 4 signature), Last-Modified 2022-07-25.

Machine access

Schema document
registry/rw/rra/vrf-e06-motor-vehicle-registration-form/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/rw/rra/vrf-e06-motor-vehicle-registration-form/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

28 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

  • ownerTin string required

    The vehicle owner's Tax Identification Number (TIN), issued by RRA.

    classification: pii
  • ownerName string required

    Owner: Name

    classification: pii
  • ownerIdentityCardNumber string required

    Owner: Identity Card Number

    classification: sensitive-pii
  • identityCardIssueDate date required

    The issue date of the identity card cited in ownerIdentityCardNumber; printed immediately beside it on the same row.

  • registrationDate date required

    Registration Date

  • vehicleUsage string optional

    The vehicle's declared use. Printed as an open text box with no enumerated option list anywhere on the form, so modelled as free text rather than an invented enum.

  • amountPaidRwf number optional

    Amount paid, in Rwandan francs (RWF), printed on the same row as Registration Date and Usage in the applicant-facing Registration Information section — distinct from the office-only "Amount Paid"/"Receipt No"/"Payment Date" cluster in Section E (For RRA Use Only), which is excluded. See VERIFICATION.md for this section-boundary judgment call.

    range: 0–∞
  • acquisitionDate date optional

    Acquisition Date

  • invoiceNo string optional

    Purchase invoice number; relevant chiefly to an imported or dealer-sold vehicle. The form gives no boolean gating field for this condition, so this is left optional rather than a fabricated requiredWhen — see VERIFICATION.md.

  • dealerTin string optional

    Dealer's TIN

    classification: pii
  • consumptionDate date optional

    The date of the customs "home use"/consumption entry for an imported vehicle.

  • consumptionEntryNo string optional

    The form prints only a bare "No" caption for this box, immediately beside "Consumption Date"; labelled here by position as the corresponding customs consumption-entry number rather than left as a literal, unhelpful "No" label. Disclosed as an interpretive judgment call in VERIFICATION.md.

  • clearingAgentTin string optional

    TIN of the customs clearing agent who handled the vehicle's import, when applicable. The printed caption wraps across two lines ("Clearing" / "Agent TIN").

    classification: pii
  • customsRegime enum optional

    The customs regime under which an imported vehicle is declared: home use/"Consumption", or a bonded "Suspension" regime. On the underlying PDF, this printed radio-button pair shares one AcroForm field object with the unrelated Section C "Steering Wheel" selector (see this schema's top-level description and VERIFICATION.md for the full defect writeup); modelled here as its own independent enum, not preserving that defect.

    enum: consumption | suspension
  • vehicleType string required

    The vehicle's type/body category. Printed as an open text box with no enumerated option list on this specimen, so modelled as free text.

  • manufacturer string required

    Manufacturer

  • model string required

    Model

  • frameNo string required

    The vehicle's frame/chassis number.

  • engineNo string required

    Engine No.

  • engineVolumeCc number optional

    Engine displacement volume, in cubic centimetres (unit "cc" printed directly beneath the box).

    range: 0–∞
  • yearOfManufacture integer required

    The vehicle's model/manufacture year (unit "AAAA", i.e. a 4-digit year, printed directly beneath the box).

    range: 1900–2100
  • weightKg number optional

    The vehicle's weight, in kilograms (unit "Kg" printed directly beneath the box).

    range: 0–∞
  • powerCv number optional

    The vehicle's engine power, in CV/fiscal horsepower (unit "CV" printed directly beneath the box).

    range: 0–∞
  • steeringWheelPosition enum required

    Whether the vehicle's steering wheel is on the left, right, or not applicable. On the underlying PDF, this printed 3-option radio group shares one AcroForm field object with the unrelated Section B "Customs Regime" selector (see this schema's top-level description and VERIFICATION.md for the full defect writeup); modelled here as its own independent enum, not preserving that defect.

    enum: left | right | na
  • color string required

    Color

  • certificationPlace string optional

    The place where the certification is signed, printed as "Sign in:" directly above the certification date/signature row.

  • certificationDate date required

    Certification date

  • certificationTitle string optional

    The job title/capacity of the person signing the certification, e.g. when the signer is an authorized representative of the owner rather than the owner personally.

Verification record

This file is the source-review record for this document version. It documents the provenance of the published fields/documents and states the current verification claim honestly.

Current claim

  • status: draft
  • verification.method: manual-source-review-v1
  • verification.lastVerifiedAt: 2026-07-12

This is GovSchema Standard Research cycle GOV-2526. It opens Rwanda as GovSchema's 43rd jurisdiction (confirmed by counting registry/ directories before and after — 42 jurisdiction directories before this schema, 43 after), via the DMV vertical (1 of 6), using the Rwanda Revenue Authority (RRA)'s Motor Vehicle Registration Form. A prior scouting pass (GOV-2507) had flagged this form as reachable and cited an HTTP status, byte size, and widget-type breakdown; nothing from that prior report was trusted without an independent re-fetch/re-derivation, and doing so surfaced one material correction (the widget-type breakdown) — see "Sources examined" below.

Sources examined

Source 1 — the RRA Motor Vehicle Registration Form PDF (source.url)
  • URL: https://rra.gov.rw/fileadmin/user_upload/mvregistrationform.pdf — a genuine rra.gov.rw domain, reached directly with no login/CAPTCHA/WAF gate.
  • Fetched directly via curl: HTTP 200, Content-Type: application/pdf, 191,913 bytes, Last-Modified: Mon, 25 Jul 2022 09:16:50 GMT, sha256: 1c580d7766fb2c7dad73aa627d5e634256e27f1475e104fb8e9728137a3337b7. The byte size matches the prior scouting pass's cited figure exactly — a case where the pre-scout held up under independent re-verification.
  • pdfjs-dist's getDocument().promise confirms a genuine single-page AcroForm/XFA PDF (root field form1[0], an Adobe LiveCycle/XFA-authored form; IsAcroFormPresent: true).
Source 2 — pdfjs-dist structural extraction (own re-derivation)
  • page.getAnnotations()/getFieldObjects() on the form's single page found 46 real Widget annotations: 37 Tx (text), 5 Btn (radio button), 4 Sig (signature) = 46. This corrects the prior scouting pass's cited breakdown of "42 text, 3 signature, 1 button/radio" — the actual composition is 37 text + 4 signature + 1 radio-button field object (whose 5 widget kids carry 5 distinct export values, 1–5); the prior pass's total widget count of 46 was exactly right, but its per-type tally undercounted signature widgets by 1 and overcounted text widgets by 5. This was confirmed by two independent passes: getAnnotations()'s per-widget subtype/fieldType tally, and a second getFieldObjects() pass grouping by fully-qualified field name.
  • Nearly every Tx/Sig widget on this specimen carries its own alternativeText tooltip (e.g. "Identity card Number", "Frame No:", "Autorised Signature of the owner") — an unusually complete set of built-in labels for this registry's typical XFA/AcroForm specimen. These tooltips were cross-checked, not simply trusted, against a getTextContent() dump of every printed caption on the page, correlated by matching each widget's rect and each text item's transform x/y coordinates to the nearest printed label — the same coordinate-correlation technique this registry has used repeatedly for generic/ambiguous AcroForms (cf. dk/skattestyrelsen GOV-2253, ng/cac GOV-2518). Every tooltip matched its nearest printed caption; no tooltip was found to be misleading or stale.
  • The form itself prints five lettered section headings directly on the page: A- OWNER IDENTIFICATION, B- REGISTRATION INFORMATION, C- VEHICLE INFORMATION, D- CERTIFICATION, E- FOR RRA USE ONLY. Every widget was assigned to a section by its rect's y-coordinate falling within that section heading's vertical band on the page.
  • Field-name-reuse finding (verified via getFieldObjects(), not merely assumed from a naming pattern): the field form1[0].#subform[0].RadioButtonList[0] is genuinely one shared AcroForm field object with 5 widget kids, spanning two unrelated printed questions: In an actual PDF viewer, since PDF radio-button widgets sharing one fully-qualified field name are mutually exclusive across their entire combined kid set (not just within their own printed row), selecting "Left"/"Right"/"N/A" for the steering wheel would silently clear whichever of "Consumption"/"Suspension" had been selected for the customs regime, and vice versa — a genuine authoring defect in the source PDF (most plausibly an XFA-authoring artefact where two originally-separate radio groups ended up sharing one generated field name), not a rendering artefact. This schema does not preserve that bug: the two questions are modelled as two independent enum fields (steeringWheelPosition, customsRegime), since the printed form unambiguously intends two independent single-select questions — disclosed here rather than silently "fixed" without comment, per the analogous field-name-reuse-across-rows precedent from GOV-2338 (no/brreg) and GOV-2518 (ng/cac).
    • 3 kids (export values 1, 2, 5) sit in Section C beside the printed caption "Steering Wheel :" and its own printed options "Left" (x≈133), "Right" (x≈190), "N/A" (x≈247) — confirmed by matching each radio widget's x-coordinate against the nearest printed option label at the same y-band (y≈382–392).
    • 2 kids (export values 3, 4) sit in Section B beside the printed caption "Customs Regime" and its own printed options "Consumption" (x≈135) and "Suspension" (x≈234) — confirmed the same way at y-band ≈535–545.
  • 28 of the 46 widgets are modelled as fields[] (26 Tx-derived fields covering Sections A–D, plus 2 enum fields derived from the 5 shared radio widgets). No widget is silently dropped without explanation.
Source 3 — Section E ("FOR RRA USE ONLY") and all 4 signature widgets: excluded
  • Section E is entirely office-only and excluded from fields[]: 11 Tx widgets (Yellow Plate Number, White Plate Number, Status, Yellow Card Number, Received, Assessment No., Amount Paid, By, Payment Date, DOC ID, Receipt No) and 3 Sig widgets (two beside a printed "Checked By:" caption at y≈181–232, one more beside the "By"/"Payment Date"/"Receipt No" row at y≈37–90, plausibly the receiving cashier's signature) — all sit strictly below the "E- FOR RRA USE ONLY" heading (y<236), confirmed by checking every widget's rect y-coordinate against that heading's y-position (235.7), the same section-heading-scoping technique this registry used for dk/cpr's "udfyldes af kommunen" boxes (GOV-2260).
  • The one remaining Sig widget — Section D's "Autorised Signature of the owner" — is also excluded from fields[], per this registry's established convention of not modelling raw signature capture as a data field (GovSchema v0.3's own field type enum has no signature value; cf. co/runt's and ng/cac's identical exclusion of their own signature-capture widgets). The certification statement this signature accompanies is instead captured as a documents[] attestation entry (ownerCertificationAttestation), per the ng/cac directorConsentToActAttestation precedent.
  • Total excluded: 11 (Section E text) + 4 (all signature widgets, 3 office + 1 applicant) = 15 widgets. 46 widgets − 15 excluded = 31 widgets feeding 28 logical fields[] entries (the 5-widget shared radio field collapses to 2 logical enum fields) — reconciles exactly.

Field inventory and scoping/disclosure decisions

  1. amountPaidRwf sits in the applicant-facing Section B (Registration Information), on the same printed row as registrationDate and vehicleUsage — distinct from a second, differently-labelled "Amount Paid" Tx widget inside Section E (For RRA Use Only), which is excluded. Both widgets happen to share the same printed caption text ("Amount Paid"); they were told apart by section (y-coordinate), not by name, since both instantiate the AcroForm field name TextField13[0] (office one) vs. NumericField1[0] (Section B one) — genuinely distinct fields, not a reused name.
  2. vehicleUsage and vehicleType are modelled as free-text strings, not enums: both are printed as plain, unruled text boxes with no visible checkbox/option list anywhere on this one-page specimen (unlike, e.g., co/runt's vehicleClass, which has 14 printed checkboxes to read option values from).
  3. consumptionEntryNo — the source prints only a bare "No" caption for this box (TextField5[5]), positioned immediately beside "Consumption Date". Labelled consumptionEntryNo by inference from position/context (a customs consumption-entry reference number) rather than left as an unhelpful literal "No." — disclosed as an interpretive judgment call, not a printed label taken verbatim.
  4. No requiredWhen gating was added for the customs/import-specific fields (invoiceNo, dealerTin, acquisitionDate, consumptionDate, consumptionEntryNo, clearingAgentTin, customsRegime), even though they plainly apply only to an imported (vs. domestically-acquired) vehicle: this one-page specimen has no boolean/enum field anywhere ("is this vehicle imported?") to gate a requiredWhen condition on, so these are left required: false field-by-field with the applicability condition disclosed in each field's own description, per this registry's "spec precision over cleverness" precedent (cf. ng/cac's Section D/D1 secretary disclosure, se/skatteverket's dual-address disclosure).
  5. steeringWheelPosition/customsRegime field-name-reuse defect — see Source 2 above for the full finding; both are modelled as independent enum fields with the underlying PDF's shared-field defect disclosed rather than preserved.
  6. Two of the five radio export values (1=Left, 2=Right, 5=N/A) map to steeringWheelPosition's ["left", "right", "na"]; the other two (4=Consumption, 3=Suspension) map to customsRegime's ["consumption", "suspension"] — verified by the coordinate correlation in Source 2, not assumed from export-value numbering order (which is not sequential per question: Left=1, Right=2, Suspension=3, Consumption=4, N/A=5).
  7. documents[] has exactly one entry: ownerCertificationAttestation, category attestation, required: true, carrying the certification statement printed verbatim in Section D ("I certify that the information provided above is true and correct in accordance with the Motor Vehicle Law articles discussing the registration of Motor Vehicle and that I'm an authorized representative of the vehicle's owner."). This specimen has no separate supporting-document notes page (unlike, e.g., ng/cac's page 4 Notes), so no identity-document/supporting-evidence entries are modelled — not a silent omission, there is simply no such instruction printed anywhere on this one-page form.
  8. No exclusivityGroups are modelled: unlike ng/cac's independently- checkable Btn triplet, this form's only multi-option selectors are the two genuine (if defectively-shared) native radio-button groups, each already expressed as a single closed enum field, which is inherently mutually-exclusive by construction — no separate exclusivityGroups entry is needed.

Rwanda's other 5 verticals — re-checked this cycle, not merely re-cited

Per the prior scouting note (GOV-2507, "NG/RW scouted"), Rwanda's other verticals were flagged as routing through the login/payment-gated IremboGov one-stop portal. This cycle's own re-check via live web search:

  • Business Formation — confirmed dead end. Business registration is performed by RDB's Office of the Registrar General, exclusively online via businessprocedures.rdb.rw/org.rdb.rw/IremboGov, requiring a mobile- number-linked account (OTP login) — no standalone fillable PDF form was found.
  • National ID — confirmed dead end. NIDA's own support documentation ("How to Apply for a National ID", "Frequently Asked Questions About National ID Application") directs all applicants to IremboGov's online application flow; no fillable PDF equivalent was found.
  • Passport — confirmed dead end. NIDA/Directorate General of Immigration and Emigration guidance states e-passport applications are "completed and submitted online through the Irembo Portal only", with a National ID as a prerequisite — no fillable PDF equivalent.
  • Taxes — confirmed dead end (distinct from the DMV form, which is also an RRA form but for a different tax-administration function). RRA's own site states its published income-tax "forms are just samples"; actual declaration forms are obtained in person at RRA offices or filed through RRA's own login-gated online declaration service — no standalone applicant-fillable PDF.
  • Visa — not a clean dead end; flagged as an unresolved candidate for a future cycle rather than force-fitted into this cycle's schema. Two PDF candidates surfaced (a Rwandan-embassy-in-UK mirror, Last-Modified 2021-03-22, and an RDB-hosted "Proposed New visa application form", Last-Modified 2013-11-14) both returned HTTP 200 with Content-Type: application/pdf. Neither was verified this cycle for AcroForm field content, and Rwanda's Directorate General of Immigration and Emigration's own current support article is titled "How to Apply for a Visa on IremboGov", directing applicants to the same online portal as the other verticals — suggesting these PDFs are likely stale embassy-consular mirrors of a superseded paper process rather than the current live form, but this was not conclusively confirmed either way. Disclosed honestly as unresolved rather than asserted as either a confirmed live source or a confirmed dead end.

Test run

No live submission was attempted — this is a structural-reference specimen, completed at (or submitted to) an RRA counter, not a self-service API GovSchema can exercise. Verification here is against the schema's own structural rules (tools/validate.mjs, tools/validate-ajv.mjs) plus a hand-rolled, from-scratch conformance-fixture checker (implementing the Condition grammar directly from spec/v0.3/SPEC.md §8.1) exercising both fields[] requiredness/validation and documents[] requiredness.

Fixtures under conformance/rw/rra/vrf-e06-motor-vehicle-registration-form/1.0.0/:

| Fixture | Scenario | Expected | Actual | |---|---|---|---| | domestic-vehicle-registration.json | Valid: domestically-acquired vehicle, no customs/import fields, certification attestation provided | 0 errors | 0 errors | | imported-vehicle-registration-with-customs.json | Valid: imported vehicle with the full customs/clearing-agent block and customsRegime: "consumption" filled | 0 errors | 0 errors | | mutation-control-missing-required-field.json | Drops frameNo from the first valid fixture | 1 error (MISSING_REQUIRED: frameNo) | 1 error | | mutation-control-enum-violation.json | Sets steeringWheelPosition to "middle" (not in ["left","right","na"]) | 1 error (ENUM_VIOLATION) | 1 error | | mutation-control-missing-required-document.json | Empties documents[], dropping ownerCertificationAttestation | 1 error (MISSING_REQUIRED_DOCUMENT) | 1 error | | mutation-control-numeric-range-violation.json | Sets yearOfManufacture to 1899 (below validation.minimum: 1900) | 1 error (RANGE_VIOLATION) | 1 error |

All 6 fixtures matched their expectation exactly. Both registry validators pass with 0 errors:

``` $ node tools/validate.mjs 381/381 document(s) passed. 3/3 mapping.json companion(s) passed.

$ node tools/validate-ajv.mjs 381/381 document(s) validated against the meta-schema (ajv 2020-12). 3/3 mapping.json companion(s) validated. ```

tools/govschema-client's registry-index.json was regenerated (npm run build-index, after npm ci --include=dev to ensure ajv is actually installed — this registry's own documented gotcha about a local NODE_ENV=production making a bare npm ci skip dev dependencies) and now includes this document.

What was NOT fully resolved (disclosed, not silently guessed)

  • vehicleUsage's exact intended value space (the form gives no printed option list) — modelled as free text rather than an invented enum.
  • consumptionEntryNo's exact meaning is inferred from its position next to "Consumption Date" rather than from its own (bare "No") printed caption.
  • The customs/import-specific fields' applicability is disclosed in prose only, since the form has no boolean/enum "is this vehicle imported?" field to gate a requiredWhen condition on.
  • Rwanda's Visa vertical is left as an open, unresolved candidate (not a confirmed dead end) for a future research cycle — see above.

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 Rwanda Revenue Authority or any government. The authoritative source is always the live government form and its official instructions.