SIGNIFY IBERIA SL

Signify Iberia SL es una sociedad mercantil española con domicilio en Madrid, inscrita en el Registro Mercantil de Madrid (tomo 33739, folio 175, sección 8, hoja M-607302), de acuerdo con los datos registrales que constan en OpenMercantil y en el BORME. La sociedad aparece vinculada al grupo Signify Holding B.V., que consta como apoderado en un acta de 2020.

Conviene advertir de una discrepancia entre los datos recibidos y lo que muestra el registro: los datos califican la empresa de "startup" constituida en 2020, pero la cronología registral incluye actas desde enero de 2020 con números de inscripción elevados (I/A 29, 32, 34, 36, 38), lo que indica que la sociedad ya existía antes de esa fecha. Esta condición de "startup" no se puede sostener con las fuentes disponibles.

No consta en los datos facilitados la fecha de constitución original ni los fundadores iniciales. Lo que sí consta es que en 2020 la sociedad ya operaba como filial del grupo Signify: el acta de 21 de enero de 2020 recoge nombramientos de apoderados (Barallat Sendagorta Pablo y Spee Maurice Paul Catharina Johan), y el de 29 de diciembre de 2020 recoge el nombramiento de Signify Holding B.V. como apoderado, con referencia registral I/A 38.

El 4 de agosto de 2020 consta el cese del consejero Barallat Sendagorta Pablo y el nombramiento de Albertin Roldán David como consejero. El 13 de febrero de 2020 consta el cese del secretario Del Castillo Manibog Federico-Germán y el nombramiento de Schellenberg González Daniela como secretaria no consejera.

Los datos facilitados no describen la actividad económica concreta de la sociedad. El sector que consta en los datos recibidos es "Software y SaaS", pero esta clasificación no se puede verificar con las fuentes registrales disponibles, que solo recogen actas de nombramientos, ceses y revocaciones de cargos. No consta en las fuentes consultadas qué actividad comercial desarrollaba ni a quién se dirigía.

No consta ningún dato financiero, de facturación, de plantilla ni de crecimiento en las fuentes disponibles. Lo que consta es una actividad registral continuada entre 2020 y 2026, con nombramientos frecuentes de apoderados y consejeros, lo que indica una estructura societaria operativa y en funcionamiento durante todo el periodo.

No consta ningún cierre. Según el registro, la sociedad consta activa en la fecha de consulta (11 de junio de 2026). El acta más reciente disponible es del 8 de abril de 2026 y recoge nombramientos de apoderados mancomunados y solidarios (Del Valle Rodríguez Álvaro, Llabrés Quesada Beatriz, Perramon Ramírez Cecilia, entre otros), de acuerdo con el BORME.

Dado que la sociedad no consta cerrada, no se puede hablar de herencia en el sentido de legado de una empresa desaparecida. Lo que consta es una estructura societaria mantenida dentro del grupo Signify, con una rotación notable de cargos y apoderados a lo largo de los años.

Los datos no identifican fundadores en el sentido habitual, sino consejeros y apoderados. De acuerdo con el registro:

• Sergio Muñoz Vázquez consta como consejero desde el nombramiento de 3 de junio de 2024.
• Eduardo Fominaya Muñoz consta como consejero desde el nombramiento de 11 de mayo de 2023.
• David Albertin Roldán consta como consejero desde el 4 de agosto de 2020 y como presidente desde el 3 de junio de 2024, en sustitución de Josep Manel Martínez Andrés.

No consta ninguna información sobre su trayectoria posterior fuera de la sociedad. Para ampliarlo se podrían consultar las notas registrales completas en el Registro Mercantil de Madrid y las memorias anuales depositadas, que no forman parte de las fuentes facilitadas.

• La clasificación de una sociedad como "startup" no se puede asumir sin verificar la fecha de inscripción original: los números de inscripción (I/A 29 a 38 en 2020) indican una sociedad con historial previo, no una constitución ese año.
• En filiales de grupos multinacionales, la rotación de apoderados y consejeros es un indicador de gobierno corporativo interno, no de cambios de propiedad ni de dificultades: hay que leer las actas registrales con esta clave.
• La presencia de una sociedad holding extranjera como apoderada (Signify Holding B.V.) es una señal de dependencia de la matriz que conviene contrastar con las memorias depositadas antes de sacar conclusiones sobre la autonomía de la filial.
• Para cualquier análisis de viabilidad o de cierre, las fuentes registrales de nombramientos son insuficientes: se necesitan cuentas anuales depositadas, que no constan en los datos facilitados.

Segons la font registral [BORME / BOE, 2026-06-11], SIGNIFY IBERIA SL és una societat constituïda el 2020 a Madrid, classificada com a startup de software i SaaS, amb estat registral activa. La cronologia d'actes mostra una activitat societària contínua (nomenaments i revocacions d'apoderats, canvis de consellers i presidència) fins al 2026, cosa que és coherent amb una filial operativa d'un grup industrial, no amb una empresa tancada.

Per tant, la premissa de partida s'ha de corregir: no hi ha evidència registral de tancament. El que sí que es pot fer és imaginar una empresa nova que capturi l'essència del que fa una firma d'aquest perfil: programari per digitalitzar i gestionar infraestructura d'enllumenat, eficiència energètica i actius elèctrics distribuïts.

Proposta (no verificada, és una hipòtesi de treball): un SaaS B2B que connecti sensors i comptadors d'enllumenat públic i d'edificis, calculi estalvis energètics, gestioni manteniment predictiu i generi informes per a licitacions i subvencions. Això encaixa amb el sector declarat (software i SaaS) i amb l'àrea d'activitat del grup de referència, però no consta a les dades verificades quin producte concret oferia la societat.

El mercat rellevant és el de software de gestió d'actius i eficiència energètica per a administracions locals, gestors d'infraestructura i empreses de serveis energètics. És un mercat real i creixent per diverses raons estructurals:

• Renovació massiva de l'enllumenat públic cap a LED i telegestió a municipis europeus.
• Pressió reguladora sobre eficiència energètica i reporting de sostenibilitat.
• Digitalització de manteniment d'infraestructura (bessons digitals, sensors IoT).

Estimació (a validar): a Espanya hi ha al voltant de 8.000 municipis amb enllumenat públic gestionat, i un nombre significatiu de gestors d'edificis i polígons. El nombre de compradors potencials directes és probablement de centenars a pocs milers d'organitzacions, cosa que és un mercat de nínxol però amb contractes recurrents i ticket mitjà alt. Aquestes xifres són estimacions de treball, no dades verificades.

Proposta de model (a validar):

• Subscripció SaaS per actius gestionats (per punt de llum, per comptador, per edifici), amb tiers per volum.
• Mòdul d'informes i compliment (subvencions, auditories, reporting ESG) com a complement de pagament.
• Serveis d'implantació i integració amb sistemes existents (SCADA, ERP municipal, plataformes de telegestió).
• Possibles acords de canal amb instal·ladors i empreses de serveis energètics que revenguin la plataforma.

El punt feble és la dependència de licitacions públiques (cicles llargs, pagaments lents). Caldrà un mix amb clients privats (gestors d'edificis, indústria) per esmorteir-ho.

Proposta en fases (estimacions de temps, a validar):

1. Fase 0 — validació (mesos 0-3): entrevistes amb 15-25 gestors d'enllumenat i facility managers; definir un MVP centrat en un sol cas d'ús (p. ex. inventari i consum d'enllumenat).
2. Fase 1 — MVP (mesos 3-9): producte mínim amb ingesta de dades, dashboard de consum i informes bàsics. 2-3 pilots amb un ajuntament mitjà i un gestor privat.
3. Fase 2 — primers contractes (mesos 9-18): convertir pilots en contractes de pagament; construir el mòdul de compliment i integracions.
4. Fase 3 — escalat (mesos 18-36): canal de partners, expansió a Portugal i a gestors d'edificis.

Totes les xifres són estimacions de rang, a validar, no dades de l'empresa original:

• Equip fundacional (2-3 persones, 12 mesos): rang de 150.000–300.000 € en sous i càrregues.
• Desenvolupament del MVP (extern o intern): rang de 60.000–150.000 €.
• Infraestructura cloud i eines: rang de 6.000–20.000 €/any.
• Legal, constitució, protecció de dades (RGPD) i contractes: rang de 10.000–25.000 €.
• Comercial i màrqueting inicial: rang de 20.000–60.000 €.
• Total orientatiu per als primers 12 mesos: rang aproximat de 250.000–550.000 €, segons si es prioritza equip intern o desenvolupament extern.

Aquestes xifres no inclouen capital de treball per cobrir el cicle de cobrament de clients públics, que pot afegir un 20-40% addicional segons el cas.

• Risc de premissa: l'empresa de referència no consta com a tancada al registre; qualsevol narrativa de "reconstrucció" ha de tractar-se com a exercici especulatiu, no com a fet.
• Risc de mercat: vendre a administracions públiques implica cicles de venda llargs i dependència de pressupostos.
• Risc competitiu: hi ha operadors grans (utilities, integradors, fabricants d'enllumenat) amb capacitat d'absorbir aquest nínxol.
• Risc de producte: la integració amb sistemes antics de telegestió és tècnica i costosa; sobreestimar la facilitat d'integració és un error habitual.
• Risc financer: el capital inicial estimat pot quedar curt si el cicle de venda s'allarga.

De l'informe original (les dades registrals), les lliçons útils són:

• La governança importa: la cronologia mostra molts nomenaments i revocacions d'apoderats i consellers. Una empresa nova hauria de fixar un marc de govern clar des del dia 1 per evitar soroll i pèrdua de focus.
• L'apoderament formal no substitueix l'equip operatiu: els actes registrals diuen qui pot signar, no qui construeix el producte. Cal separar explícitament les dues coses.
• L'essència aprofitable és el nínxol, no l'estructura: el valor rau a resoldre un problema concret de gestió d'infraestructura amb software; replicar l'estructura societària d'un grup gran no té sentit per a una startup independent.
• Qui ho hauria de fer: un equip petit (2-4 persones) amb un fundador tècnic (producte/dades), un fundador de domini (enllumenat/energia o venda a sector públic) i suport comercial. No cal replicar el consell dens de l'original; cal un equip que vengui i construeixi alhora.

Nota final: aquest informe parteix de dades registrals verificades (font BORME/OpenMercantil) i marca explícitament com a proposta o estimació tot allò que no ho és. No s'atribueix a SIGNIFY IBERIA SL cap producte, xifra de facturació ni tancament que no consti a les fonts citades.

La ficha registral de SIGNIFY IBERIA SL mostra un patró que és habitual en filials espanyoles de grups estrangers: entre 2020 i 2026 hi ha més de 20 actes registrals, gairebé tots de nombramientos i revocaciones d'apoderats i consellers, amb solapaments (per exemple, el 2024-08-08 hi ha tres actes el mateix dia amb nomenaments i revocacions creuades). El resultat és que la pregunta operativa "qui pot signar un contracte en nom d'aquesta societat avui?" no té una resposta fiable sense llegir manualment l'historial complet i aplicar-hi la lògica de vigència.

Això genera tres costos concrets:

1. Risc legal i financer: signar amb un apoderat revocat o amb un poder mancomunat quan calien dues signatures.
2. Fricció operativa: cada contracte, alta bancària o licitació requereix una cerca manual al BORME i una consulta a l'assessoria.
3. Pèrdua de memòria institucional: els canvis de consellers i apoderats no queden traçats en un sistema propi, només al registre mercantil.

RegiCargo no substitueix el Registre; indexa i interpreta el que ja és públic (BORME) i el creua amb els documents interns de la societat (poders notarials, actes de consell) per donar una resposta única i auditable.

Arquitectura de microserveis moderada, desplegada a AWS eu-west-1 (Irlanda) per compliment RGPD i latència a la península. Es descarta un monòlit perquè la ingesta de BORME té pics molt marcats (publicació diària) i ha de poder escalar independentment de l'API de consulta.

``` [Fonts externes] [Plataforma RegiCargo] BORME (PDF/XML) ──┐ OpenMercantil ────┼──► Ingest Worker (Python, Celery) Registre Mercantil┘ │ ▼ Normalitzador d'actes │ ▼ Postgres (actes, persones, càrrecs) │ Motor de vigència (regles) │ ▼ API REST (FastAPI) ──► Web (Next.js) │ ▼ Audit log append-only (S3 + hash chain) ```

Decisions i motius:

• Python + Celery per a la ingesta: el parsing de PDF del BORME i la normalització de noms (accents, ordre cognoms) és molt més àgil amb llibreries de NLP que amb un runtime JVM.
• PostgreSQL com a font de veritat: les relacions temporals (acte → persona → càrrec → vigència) encaixen en un model relacional amb rangs de dates; s'evita NoSQL perquè les consultes de vigència requereixen joins i constraints.
• Audit log append-only amb hash chain (cada entrada inclou el hash de l'anterior): qualsevol consulta "qui signava el 2024-08-08" ha de ser reproduïble i no manipulable, requisit habitual en auditories internes de grup.
• Multi-tenant per schema a Postgres (un schema per societat client): aïllament fort entre filials de grups diferents amb cost operatiu baix.

Model relacional amb temporalitat explícita (no bitemporal complet, perquè el BORME ja és la font d'"efectiu" i l'usuari només necessita "vigent / no vigent").

```sql -- Persones físiques o jurídiques que apareixen en actes CREATE TABLE persona ( id UUID PRIMARY KEY, nom_canon TEXT NOT NULL, -- nom normalitzat per deduplicar nom_original TEXT NOT NULL, tipus TEXT CHECK (tipus IN ('fisica','juridica')), nif_hash TEXT -- hash, mai NIF en clar );

-- Societat client (tenant) CREATE TABLE societat ( id UUID PRIMARY KEY, schema_name TEXT UNIQUE NOT NULL, rao_social TEXT NOT NULL, cif_hash TEXT, registre_dades TEXT -- "T 33739, F 175, S 8, H M 607302" );

-- Acte registral (un registre del BORME) CREATE TABLE acte ( id UUID PRIMARY KEY, societat_id UUID REFERENCES societat(id), data_publicacio DATE NOT NULL, -- data BORME data_acte DATE, -- data efectiva si consta tipus TEXT NOT NULL, -- 'nombramiento','revocacion','cese' font_url TEXT NOT NULL, -- enllaç al PDF BORME hash_pdf TEXT NOT NULL, raw_text TEXT );

-- Assignació de càrrec derivada d'un acte CREATE TABLE carrec ( id UUID PRIMARY KEY, acte_id UUID REFERENCES acte(id), persona_id UUID REFERENCES persona(id), tipus_carrec TEXT NOT NULL, -- 'consejero','presidente','apoderado',... modalitat TEXT, -- 'solidario','mancomunado' vigent_des DATE NOT NULL, vigent_fins DATE, -- NULL = vigent revocat_per UUID REFERENCES acte(id) );

-- Regla de signatura per societat (configurable pel client) CREATE TABLE regla_signatura ( id UUID PRIMARY KEY, societat_id UUID REFERENCES societat(id), tipus_carrec TEXT NOT NULL, signatures_requerides INT NOT NULL DEFAULT 1, actiu BOOLEAN DEFAULT true ); ```

Motius:

• `vigent_fins` com a columna mutable (no append-only) perquè la revocació és un acte que tanca el rang; l'històric es reconstrueix des de `acte`.
• `nif_hash` en lloc del NIF en clar: minimitza dades personals (RGPD) i permet deduplicar sense emmagatzemar identificadors sensibles.
• `regla_signatura` separada perquè la llei no fixa el nombre de signatures; cada grup ho configura (p. ex. "apoderat mancomunat = 2 signatures").

API REST versionada (`/v1`), autenticació OAuth2 client credentials per a integracions i JWT per a usuaris.

Endpoints principals:

• `GET /v1/societats/{id}/signants?data=2026-04-08` → llista de persones amb poder vigent en aquella data, amb el càrrec i la modalitat. Resposta:

```json { "societat": "SIGNIFY IBERIA SL", "data": "2026-04-08", "signants": [ {"persona": "DEL VALLE RODRIGUEZ ALVARO", "carrec": "apoderado_mancomunado_solidario", "signatures_requerides": 2, "acte_origen": "BORME-A-2026-66-28"} ] } ```

• `GET /v1/societats/{id}/historial?carrec=apoderado` → línia temporal d'actes.
• `POST /v1/societats/{id}/actes` → alta manual d'un acte (per a documents interns no publicats).
• `GET /v1/audit/{entitat}/{id}` → traça de canvis amb hash chain.

Integracions:

• Ingesta BORME: job diari a les 06:00 CET que descarrega els PDF del dia, fa OCR si cal i extreu actes. Font citada: BOE/BORME.
• OpenMercantil com a font complementària per a metadades de societat (ficha).
• Webhook sortint `signant.revocat` perquè els sistemes de contractació del client bloquegin signants automàticament.
• Exportació CSV/PDF del certificat de signants per a licitacions.

Ordre d'implementació, amb criteri de "mínim que ja aporta valor":

1. Ingestor BORME + normalitzador (2-3 setmanes): descàrrega diària, parsing de PDF, extracció d'actes de nombramiento/revocación/cese. És el coll d'ampolla tècnic i sense ell no hi ha producte.
2. Model de dades + motor de vigència (2 setmanes): resoldre `vigent_des`/`vigent_fins` a partir dels actes, amb tests sobre l'historial real de SIGNIFY IBERIA SL com a golden dataset (20+ actes amb solapaments).
3. API de consulta `signants?data=` (1 setmana): és el valor immediat per a l'usuari.
4. Panell web "qui signa avui" (2 setmanes): cerca per societat, llista de signants, enllaç a l'acte d'origen.
5. Audit log amb hash chain (1 setmana): abans de qualsevol client real, perquè és requisit d'auditoria.

Es deixa per a la fase 2: alta manual d'actes, webhooks, exportació PDF, multi-idioma.

Mides orientatives:

• Ingesta: ~1.500-3.000 actes/dia a tot Espanya; amb filtre per societats client, molt menys. Un worker Celery amb 2 CPU gestiona el volum diari en <30 min.
• Emmagatzematge: Postgres <5 GB per a 10.000 societats amb 6 anys d'historial; PDFs a S3 (~50 MB/dia).
• Latència API: objectiu p95 < 200 ms per a `signants?data=` (índex compost `(societat_id, vigent_des, vigent_fins)`).

Riscos tècnics i mitigació:

• Qualitat del parsing BORME: els PDF varien de format. Mitigació: golden dataset amb els 20+ actes de SIGNIFY IBERIA SL i alerta quan el parser no extreu cap acte d'un PDF que en conté.
• Ambigüitat de noms: "MUÑOZ VAZQUEZ SERGIO" vs "SERGIO MUÑOZ VÁZQUEZ". Mitigació: normalització + revisió humana en cas de dubte, mai deduplicació automàtica agressiva.
• Actes no publicats: poders notarials interns que no arriben al BORME. Mitigació: alta manual (fase 2) i marcatge explícit de "font interna" a l'audit log.
• Dependència de fonts públiques: canvis d'URL o format del BOE. Mitigació: capa d'abstracció `FontProvider` amb dos proveïdors (BOE directe + OpenMercantil) i fallback.

Validació en tres nivells:

1. Golden dataset registral: es reconstrueix l'historial complet de SIGNIFY IBERIA SL a partir dels actes