Colombia RUES Mercantile Registration Form (Registro Mercantil — Personas Naturales y Jurídicas)

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

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

This document remains draft, not verified, pending an independent second reviewer's field-by-field pass, per this registry's convention.

Why this document exists

This is a GovSchema Standard Research cycle (GOV-1588). Colombia (co) was opened as the registry's 19th jurisdiction one cycle prior (GOV-1567) with a single DMV schema (co/runt/formulario-solicitud-tramites-vehiculo); every other vertical — Business Formation, Passport, Visa, Taxes, National ID/Civic — was completely uncovered, the highest-value coverage gap in the registry at the time (every other jurisdiction already had 2+ verticals). This cycle targeted Colombia's Business Formation gap via RUES (Registro Único Empresarial y Social), the mercantile/company registry Colombia's Cámaras de Comercio (Chambers of Commerce) jointly operate nationwide. Two fallback candidates identified going into this cycle — Colombia's online passport wizard (Cancillería) and DIAN's RUT Formulario 001 (previously flagged by GOV-1444, before Colombia was even in the registry, as "viable-but-weak": several unbounded repeating structures) — were not needed; RUES's own core Registro Mercantil form proved to be a well-bounded, fully sourced, current candidate once properly extracted (see below), so neither fallback was pursued this cycle.

Sources examined

• Primary source — Superintendencia de Industria y Comercio (SIC), https://www.sic.gov.co/sites/default/files/files/Normativa/Circular_Unica/Anexo_4_1_INSTRUCCIONES_FORMULARIOS_RUES.pdf ("Anexo 4.1 — Instrucciones para Diligenciar el Formulario del Registro Único Empresarial y Social RUES", 30 pages). Fetched directly via curl (-A "Mozilla/5.0" -k; the host's TLS chain required -k to negotiate in this sandbox — the certificate itself is a standard SIC-issued one, not a MITM indicator, and the PDF's own magic bytes and internal structure confirm a genuine, well-formed PDF 1.5 document, not tampered content). HTTP 200, 595,964 bytes. SIC is the regulator whose Circular Única sets the unified format every Chamber of Commerce nationwide must use for this form, making it the single most authoritative source for the form's content — chosen over any one Chamber's own copy for that reason.
• Cross-check source — Cámara de Comercio de Medellín, https://www.camaramedellin.com.co/Portals/0/Documentos/Formatos/Formulario%20RUES.pdf (the actual fillable two-page "Formulario RUES" template, HOJA 1 / HOJA 2, 549,895 bytes, HTTP 200, PDF 1.7). The SIC document explains the form's fields but is itself instructions prose, not the form; this second document is the actual blank form template, needed to confirm exact box labels, groupings, and physical layout (including the numbered casilla markers 1–11 down the page margin that this document's sourceRefs cite). Both documents independently corroborate the same field set, section numbering, and code tables — no discrepancy found between them.
• Two other candidate mirrors from the initial scouting list (ccoa.org.co, camaramedellin.com.co's "Instrucciones del formulario RUES.pdf") were also fetched successfully (HTTP 200, genuine PDFs) as further corroboration but were not needed as primary sources once the SIC document and the Medellín form template were confirmed sufficient and mutually consistent.

Extraction method

1. Fetched both PDFs directly via curl (see above); confirmed genuine PDF magic bytes (%PDF-1.5, %PDF-1.7) on both, ruling out an HTML error page or redirect-wall response.
2. Extracted text content with pdfjs-dist@3.11.174 (pinned per this registry's established gotcha with later versions) via getDocument({data}).promise → page.getTextContent(), first as line-grouped text (grouping glyphs by y-coordinate) to read the instructions document's prose section-by-section.
3. For the two-page form template, additionally extracted every glyph's raw (x, y) transform coordinates (not just line-grouped text) and grouped items into x-coordinate bands. This was necessary because the template's "INFORMACIÓN DEL REGISTRO" panel (casilla 1) prints three parallel registry tracks side by side on the same page — Registro Mercantil / Vendedores de Juegos de Suerte y Azar / Sociedad Civil (x≈61), Registro Único de Proponentes (x≈413), and Registro de Entidades sin Ánimo de Lucro / Economía Solidaria (x≈238) — and a naive line-grouped read of this region interleaves all three tracks' checkbox labels into a single garbled line. Coordinate-band separation confirmed the Registro Mercantil column has exactly four trámite options (MATRÍCULA/INSCRIPCIÓN, RENOVACIÓN, TRASLADO DE DOMICILIO, AJUSTE DE INFORMACIÓN FINANCIERA) and no CANCELACIÓN option — that option belongs to the neighbouring Registro Único de Proponentes column (x≈413), which does have five options including cancelación. A line-grouped-only read would have risked misattributing that fifth option to Registro Mercantil; this was caught and avoided by checking coordinates before finalizing registryProcedureType's enum. This is the same class of two/three-column same-page field mix-up flagged in this registry's prior work (GOV-1493) and its gov-form-pdf-extraction practice note.
4. Cross-read every field against the SIC instructions document's own numbered section prose (§1 "Información del Registro" through §11 "Protección Social", plus its four numbered code tables: tipo general de organización, tipo específico de organización, Grupo NIIF, and código del estado actual de la persona jurídica) to resolve each field's meaning, scope, and — where the source is explicit — required/optional status. The template's own printed casilla numbers (1 through 11, confirmed via coordinate extraction to align one-to-one with the instructions document's own numbered sections) are cited verbatim in each field's sourceRef.

Scope: what this document models, and what it deliberately excludes

The full RUES form (and its accompanying SIC instructions document) is far broader than a single business-registration schema should responsibly cover in one document. This document is scoped narrowly and explicitly to the Registro Mercantil / Vendedores de Juegos de Suerte y Azar / Sociedad Civil track of the two-page core form (Hoja 1 + Hoja 2) — the actual company/business-registration process this registry's Business Formation vertical is about. Excluded, and not modelled anywhere in this document:

• Registro Único de Proponentes (public-sector-contractor bidder registry) — the form's second parallel track in casilla 1, with its own distinct trámite options (including cancelación, which Registro Mercantil does not have) and its own multi-hoja Anexo 2 (tamaño de empresa, capacidad financiera/organizacional, situación de control y grupos empresariales, clasificador de bienes y servicios, representación legal, experiencia/contratos ejecutados). This is a different registry serving a different purpose (public procurement eligibility), not company formation.
• Registro de Entidades sin Ánimo de Lucro / Economía Solidaria / Veedurías Ciudadanas / ONG's Extranjeras — the form's third parallel track in casilla 1, and its own Anexo 5 (número de asociados, discapacidad/etnia/LGBTI/desplazados demographic questions, entity-type code table 22–43). A distinct non-profit/solidarity-economy registry, not company formation. (The one field from this track's territory that physically appears on the shared Hoja 2 template regardless of which track is selected — Balance Social, parenthetically marked "solamente si es Entidad sin ánimo de lucro" — is retained as an optional field since it is printed unconditionally on the page this document does model; see its own field description.)
• Anexo 1 (Matrícula/renovación of a specific establecimiento de comercio, sucursal o agencia — a business's individual physical storefront/branch, a separate sub-registration from the business entity itself).
• Anexo 3 / Anexo 4 (renewal for a matrícula more than one year overdue, with open-ended per-year repeating financial-statement blocks — the "unbounded repeating structure" pattern this registry avoids per its boundedness bar, the same concern that had weakened the DIAN RUT candidate in a prior cycle).
• Anexo 6 (Registro Nacional de Turismo — tourism-sector operator registration) and Anexo 7 (Registro de Operadores de Libranzas — payroll-deduction lending operator registration) — both entirely separate, sector-specific registries layered onto the same physical RUES form.
• The "Código Cámara y Fecha Radicación" box and the "Espacio para uso exclusivo de la Cámara de Comercio" / "Firma y Sello de la Cámara de Comercio" block — both explicitly marked "Para uso exclusivo de la Cámara de Comercio" (office-only), consistent with this registry's established convention (e.g. co/runt/...'s casilla 1) of excluding fields the source itself marks as filled in by the receiving authority, not the applicant.
• The declarant's signature — a physical-signature mechanic, not a data field, per this registry's standing convention.

Interpretive judgment calls flagged for an independent reviewer

1. personType is a derived gating field, not a literal form checkbox. The form itself has no explicit "tipo de persona" checkbox; instead its own instructions direct the filer to complete one set of fields (razón social/sigla) and omit another (apellidos/nombres/género), or vice versa. This document adds personType as an explicit enum to drive its requiredWhen conditions — a modelling addition, disclosed here rather than presented as a literal source field.
2. documentIssueDate/documentIssuePlace gated only on documentType == cedula_ciudadania. The instructions explicitly pair "fecha y lugar de expedición" with the cédula de ciudadanía case; whether the same pairing is expected for cédula de extranjería, tarjeta de identidad, or pasaporte is not stated with the same explicitness. Left gated narrowly and disclosed, rather than broadened by assumption.
3. nit/nitVerificationDigit required only on renovación, not on matrícula. This is the inverse of the usual pattern: the instructions explicitly state a first-time legal-entity matrícula must leave NIT blank (the Cámara itself obtains it from DIAN), while a renovación must supply it. Modelled exactly as stated, not as a uniform "required for legal entities" rule.
4. womenCapitalParticipationPercent's persona-jurídica scope is inferred, not restated. It is printed directly beneath the "Composición del Capital en Caso de Personas Jurídicas" block without its own restated conditional language. Gated the same as that block by inference, disclosed as such.
5. secondaryActivityStartDate is not machine-gated to "required only if a secondary CIIU code is declared." GovSchema v0.3's Condition grammar (conditionLeaf: equals/notEquals/in/comparison operators against a concrete value) has no "field is present" operator suitable for gating on an optional string field's mere presence — using notEquals: "" against an absent optional field is the same notEquals-empty-string hazard this registry has previously flagged (notequals-empty-string-absent-field-bug). Left unconditionally optional and disclosed rather than encoding an unreliable condition.
6. highestRevenueActivityCiiuCode/highestRevenueActivityShdCode are not gated to renovación-only submissions, even though a brand-new matrícula would typically have no prior-period revenue to report here — the form's own instructions do not state that restriction explicitly, so this document does not invent it.
7. ley1780MaintainsComplianceOnRenewal is gated only on registryProcedureType == "renovacion", not chained to declaresLey1780Compliance. The source's own instruction frames this question as referring back to a different, earlier matrícula submission ("habiéndose acogido a los beneficios... al momento de la matrícula"), which this single-submission document has no way to see. Chaining it to this submission's own declaresLey1780Compliance field (only meaningful at matrícula) would be incorrect; disclosed instead of silently over- or under-gating.
8. CIIU code pattern (^[0-9]{4}$) is asserted as a 4-digit code, per Colombia's DIAN/DANE CIIU Revisión 4 classification (general public knowledge about the coding scheme, not itself printed on the form, which shows only blank "CLASE" boxes without a digit-count mask).
9. Document-number patterns (NIT, cédula, etc.) are left as open strings, consistent with this registry's precedent (co/runt/formulario-solicitud-tramites-vehiculo judgment call 7) that Colombian identity/tax-document lengths vary and the form itself prints no digit-count mask.
10. **realEstateProperty1*/realEstateProperty2* model the form's own printed two-column bounded layout** for casilla 9 (DETALLE DE LOS BIENES RAICES QUE POSEA), not an open-ended repeating array — the template prints exactly two side-by-side property blocks with no "add more rows" affordance, unlike Anexo 3/4's explicitly open-ended per-year blocks (out of scope, see above).
11. Plain "SI/NO" questions without an explicit "(Obligatorio)" annotation are nonetheless modelled as required: true (e.g. hasEstablishmentsAgenciesOrBranches, hasInnovationProcess, isFamilyBusiness, isSocialSecurityContributor) — these are simple, always-answerable binary questions the template prints for every filer with no conditional framing, unlike the genuinely supplementary fields left optional (referencias, bienes raíces, phone numbers beyond the explicitly-mandatory email). This is a disclosed, conservative-but-firm judgment call an independent reviewer may want to revisit field by field.

Test run (Phase 4 — mock data)

Two mock-filled instances were constructed and checked field-by-field against every field's validation (enum/pattern/minimum/maximum/maxLength) and against the conditional-requiredness graph (required/requiredWhen), using a small throwaway Node script (not committed — implements the same condition-evaluation semantics as tools/validate-ajv.mjs's meta-schema validation plus this document's own field-level requiredWhen graph, run ad hoc for this review):

1. matricula_inscripcion, persona natural — a fictional new sole trader ("Camila Andrea Gómez Ramírez", cédula de ciudadanía, a small food retail business in Bogotá D.C., CIIU 4711). Exercises: personType == persona_natural gating (natural-person name/document fields required, razonSocial/sigla correctly absent); nit correctly absent and not required (first-time matrícula); documentIssueDate/documentIssuePlace present (documentType is cédula de ciudadanía); naturalPersonActivityDescription present (required for personas naturales); capital-composition and Empresa Asociativa de Trabajo fields all correctly absent and not required (persona natural; specificOrganizationType is not "09"). Result: valid.
2. renovacion, persona jurídica (SAS) — a fictional software company ("Tecnologías Andinas SAS", NIT 901234567-8, Medellín, CIIU 6201 primary / 6311 secondary, condición Sociedad BIC). Exercises: nit/ nitVerificationDigit required and present (renovación); capital composition percentages and womenCapitalParticipationPercent required and present (persona jurídica), summing nationally+foreign to 100%; currentLegalStatusCode, numberOfWomenInManagementPositions required and present (persona jurídica); numberOfEstablishmentsAgenciesOrBranches required and present (hasEstablishmentsAgenciesOrBranches is true); ley1780MaintainsComplianceOnRenewal required and present (renovación); registrationNumber/renewalYear present (non-matrícula procedure). Result: valid.

Both runs used only fabricated example values, consistent with this document carrying no verbatim worked example from RUES/SIC itself (the instructions document illustrates concepts in prose but includes no filled-in specimen form).

Path to a verified claim (next step)

To advance this document to status: verified, a reviewer needs to (a) independently re-fetch both source PDFs and confirm no newer edition of the SIC Circular Única's Anexo 4.1 has been published, and (b) independently re-derive the coordinate-band column assignment for casilla 1 (the three-parallel-registry-track layout) to confirm this document's registryProcedureType enum (four options, no cancelación) against a fresh extraction, since that is the single highest-value fact this document's correctness depends on getting right.

Re-verification

Per the practice's Cadence, nextReviewBy is set to 2027-01-07 (~6 months): this is the registry's first Colombian Business Formation document, carries several disclosed judgment calls, and its freshness proxy is a PDF fetched without an explicit revision date printed on the document itself — all of which argue for the shorter end of the cadence. Re-check the source and resolve the open judgment calls on or before that date and on any source.url change.